Finn continues to get updated on a regular basis. A best practice is to ensure you are using a specific version of Finn for your production forecast. This can be done through the use of the renv package while using Finn on your local machine, or using docker containers for running Finn in the cloud.
Finn was built to run at scale in Azure, leveraging spark as the parallel back end. Check out the parallel processing vignette to learn how to get Finn running on Azure services like Databricks. The best way to run Finn in production is through the use of Azure Machine Learning, specifically Azure ML Pipelines.
Below are a few tips for leveraging Azure ML Pipelines
forecast_time_series() so you can have different pipeline
steps ran for each step of the Finn forecast process.add_unique_id to FALSE within set_run_info().
That will let you call the exact same run info in each separate pipeline
step. Make sure that you are using your own unique run_name
within set_run_info(), one that is different than previous
Finn runs but the same name when using set_run_info() in
each pipeline step.prep_data() and prep_models(), use the
default spark cluster settings. Where each spark task gets sent to a
specific core on an executor.train_models(),
ensemble_models(), and final_models() consider
adjusting the spark cluster settings like “spark.executor.cores” equal
to 1 and set inner_parallel to TRUE within each function.
That way only a single task/time series gets sent to each spark executor
node, and all cores within that node can be used during the modeling
process for that task/time series. Use num_cores within
each function to control how many cores on the executor to use, with the
default being all available cores minus one. This can significantly
speed up run time, but if you have many time series and want to run all
of the models within Finn ensure that you have a spark cluster that can
scale to many VM’s.