MRT/YaraScan is a MacOS prodvided antivirus-copyright tool. The reason for it's obscene memory usage is basically why OSX doesn't have a formal 'antivirus'.
More simply, YaraScan is one part of the 'volatility suite' here; https://www.volatilityfoundation.org/about
Do realise that a virus and illegally pirated material both are only detected by a 'signature' set of code paths and both often reliant on bugs, exploits and weak patching, so it's only to be expected that the strongest modern antivirus was grown from a copyright infringement detection tool.
YaraScan runs once after Mojave update, and then deletes itself. It has also been seen to persist on certain MacOS systems within MRT. The reason it uses so much memory is because unless otherwise programmed (as in it's an opt-out), a process that has to scan an large amount of files for an unknown sized file that might be encrypted into said searched files will use a large amount of inactive memory to save all decrypted scanned files for a limited amount of time incase they are needed again. Why? Because empty RAM is wasted RAM, I mean you still have to give it watts so why delete the stuff on it when something else doesn't want to be there? It takes 100x longer to get it back.
More importantly, if you Filevault or APFS, ALL of that data is encrypted and must be decrypted to be read. Many apps actually need launching and then scanning when they are loaded as many files can come together to form a threat in memory space as a single 'concurrent file'. Viruses can be partially stored in a dylib for a completely unrelated app.
The amount of time is actively decided by Grand Central Dispatch in your mac and as soon as you attempt to use a program that needs that logical RAM it will try to clear it. Note that Virtual Memory in this case should be large, as all that decrypted stuff is better stored there until you're literally out of space than deleted on a secondary pass shortly after creation repeatedly.
This is new behavior in the age of SSDs to maximize drive life over responsiveness. Current GCD behavior suggests that the slowdowns are from a fast CPU creating decrypted data faster than it can be written to disk and other requests to RAM having to wait for SSD/HDD to finish.