Following on @alanning, in terms of scaling and a queue. I'm in a situation with multiple app instances across multiple servers with jobs executing most frequently based on a schedule, but that only need to run once. I just needed a quick solution and so I use synced-cron to fire off a job which runs on whichever instance. The result of those jobs write back to mongo. It was quick, and worked and didn't require much extra setup.
If I were to do it again, or possibly even now, I would look at cluster and set up a microservice to receive requests and provide the analytics services and return the result. This would allow to have dedicated instances to analytics that could be scaled separately and or simpler changes if I were to change the analytics pipeline.
Edit: It looks like job-collection provides pretty much the whole suite of job management and allows you to run your jobs anywhere (meteor client, server or as a separate node.js/system worker).
Also, there is a node-julia package which you could integrate directly into meteor and just wrapAsync the call to avoid blocking the event loop. If you're just looking for low volume, on demand running of julia scripts. That's a pretty straightforward solution.