Skip to main content
Minimal example of distributed training with MLForecast
The DistributedMLForecast class is a high level abstraction that encapsulates all the steps in the pipeline (preprocessing, fitting the model and computing predictions) and applies them in a distributed way. The different things that you need to use DistributedMLForecast (as opposed to MLForecast) are:
  1. You need to set up a cluster. We currently support dask, ray and spark.
  2. Your data needs to be a distributed collection (dask, ray or spark dataframe).
  3. You need to use a model that implements distributed training in your framework of choice, e.g. SynapseML for LightGBM in spark.

Dask

Client setup

Here we define a client that connects to a dask.distributed.LocalCluster, however it could be any other kind of cluster.

Data setup

For dask, the data must be a dask.dataframe.DataFrame. You need to make sure that each time series is only in one partition and it is recommended that you have as many partitions as you have workers. If you have more partitions than workers make sure to set num_threads=1 to avoid having nested parallelism. The required input format is the same as for MLForecast, except that it’s a dask.dataframe.DataFrame instead of a pandas.Dataframe.
unique_iddsystatic_0static_1sin1_7sin2_7cos1_7cos2_7
npartitions=10
id_00objectdatetime64[ns]float64int64int64float32float32float32float32
id_10
id_90
id_99

Models

In order to perform distributed forecasting, we need to use a model that is able to train in a distributed way using dask. The current implementations are in DaskLGBMForecast and DaskXGBForecast which are just wrappers around the native implementations.

Training

Once we have our models we instantiate a DistributedMLForecast object defining our features. We can then call fit on this object passing our dask dataframe.
Once we have our fitted models we can compute the predictions for the next 7 timesteps.

Forecasting

unique_iddsDaskXGBForecastDaskLGBMForecast
0id_002002-09-27 00:00:0021.72284121.725511
1id_002002-09-28 00:00:0084.91819484.606362
2id_002002-09-29 00:00:00162.067624163.36802
3id_002002-09-30 00:00:00249.001477246.422894
4id_002002-10-01 00:00:00317.149512315.538403

Saving and loading

Once you’ve trained your model you can use the DistributedMLForecast.save method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. mlforecast uses fsspec to handle the different filesystems, so if you’re using s3 for example you also need to install s3fs. If you’re using pip you can just include the aws extra, e.g. pip install 'mlforecast[aws,dask]', which will install the required dependencies to perform distributed training with dask and saving to S3. If you’re using conda you’ll have to manually install them (conda install dask fsspec fugue s3fs).
Once you’ve saved your forecast object you can then load it back by specifying the path where it was saved along with an engine, which will be used to perform the distributed computations (in this case the dask client).
We can verify that this object produces the same results.

Converting to local

Another option to store your distributed forecast object is to first turn it into a local one and then save it. Keep in mind that in order to do that all the remote data that is stored from the series will have to be pulled into a single machine (the scheduler in dask, driver in spark, etc.), so you have to be sure that it’ll fit in memory, it should consume about 2x the size of your target column (you can reduce this further by using the keep_last_n argument in the fit method).

Cross validation

unique_iddsDaskXGBForecastDaskLGBMForecastcutoffy
61id_042002-08-21 00:00:0068.341868.9445392002-08-15 00:00:0069.699857
83id_152002-08-29 00:00:00199.315403199.6635552002-08-15 00:00:00206.082864
103id_172002-08-21 00:00:00156.822598158.0182462002-08-15 00:00:00152.227984
61id_242002-08-21 00:00:00136.598356136.5768652002-08-15 00:00:00138.559945
36id_332002-08-24 00:00:0095.607296.2493542002-08-15 00:00:00102.068997

Spark

Session setup

Data setup

For spark, the data must be a pyspark DataFrame. You need to make sure that each time series is only in one partition (which you can do using repartitionByRange, for example) and it is recommended that you have as many partitions as you have workers. If you have more partitions than workers make sure to set num_threads=1 to avoid having nested parallelism. The required input format is the same as for MLForecast, i.e. it should have at least an id column, a time column and a target column.

Models

In order to perform distributed forecasting, we need to use a model that is able to train in a distributed way using spark. The current implementations are in SparkLGBMForecast and SparkXGBForecast which are just wrappers around the native implementations.

Training

Forecasting

unique_iddsSparkLGBMForecastSparkXGBForecast
0id_002002-09-2715.05357718.631477
1id_002002-09-2893.01003793.796269
2id_002002-09-29160.120148159.582315
3id_002002-09-30250.445885250.861651
4id_002002-10-01323.335956321.564089

Saving and loading

Once you’ve trained your model you can use the DistributedMLForecast.save method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. mlforecast uses fsspec to handle the different filesystems, so if you’re using s3 for example you also need to install s3fs. If you’re using pip you can just include the aws extra, e.g. pip install 'mlforecast[aws,spark]', which will install the required dependencies to perform distributed training with spark and saving to S3. If you’re using conda you’ll have to manually install them (conda install fsspec fugue pyspark s3fs).
Once you’ve saved your forecast object you can then load it back by specifying the path where it was saved along with an engine, which will be used to perform the distributed computations (in this case the spark session).
We can verify that this object produces the same results.

Converting to local

Another option to store your distributed forecast object is to first turn it into a local one and then save it. Keep in mind that in order to do that all the remote data that is stored from the series will have to be pulled into a single machine (the scheduler in dask, driver in spark, etc.), so you have to be sure that it’ll fit in memory, it should consume about 2x the size of your target column (you can reduce this further by using the keep_last_n argument in the fit method).

Cross validation

unique_iddsSparkLGBMForecastSparkXGBForecastcutoffy
0id_032002-08-183.2729223.3488742002-08-153.060194
1id_092002-08-20402.718091402.6225012002-08-15398.784459
2id_252002-08-2287.18981186.8916322002-08-1582.731377
3id_062002-08-2120.41679020.4785022002-08-1519.196394
4id_222002-08-23357.718513360.5020242002-08-15394.770699

Ray

Session setup

Data setup

For ray, the data must be a ray DataFrame. It is recommended that you have as many partitions as you have workers. If you have more partitions than workers make sure to set num_threads=1 to avoid having nested parallelism. The required input format is the same as for MLForecast, i.e. it should have at least an id column, a time column and a target column.

Models

The ray integration allows to include lightgbm (RayLGBMRegressor), and xgboost (RayXGBRegressor).

Training

To control the number of partitions to use using Ray, we have to include num_partitions to DistributedMLForecast.

Forecasting

unique_iddsRayLGBMForecastRayXGBForecast
0id_002002-09-2715.23245510.38301
1id_002002-09-2892.28899492.531502
2id_002002-09-29160.043472160.722885
3id_002002-09-30250.03212252.821899
4id_002002-10-01322.905182324.387695

Saving and loading

Once you’ve trained your model you can use the DistributedMLForecast.save method to save the artifacts for inference. Keep in mind that if you’re on a remote cluster you should set a remote storage like S3 as the destination. mlforecast uses fsspec to handle the different filesystems, so if you’re using s3 for example you also need to install s3fs. If you’re using pip you can just include the aws extra, e.g. pip install 'mlforecast[aws,ray]', which will install the required dependencies to perform distributed training with ray and saving to S3. If you’re using conda you’ll have to manually install them (conda install fsspec fugue ray s3fs).
Once you’ve saved your forecast object you can then load it back by specifying the path where it was saved along with an engine, which will be used to perform the distributed computations (in this case the ‘ray’ string).
We can verify that this object produces the same results.

Converting to local

Another option to store your distributed forecast object is to first turn it into a local one and then save it. Keep in mind that in order to do that all the remote data that is stored from the series will have to be pulled into a single machine (the scheduler in dask, driver in spark, etc.), so you have to be sure that it’ll fit in memory, it should consume about 2x the size of your target column (you can reduce this further by using the keep_last_n argument in the fit method).

Cross validation

unique_iddsRayLGBMForecastRayXGBForecastcutoffy
0id_052002-09-21108.285187108.6196982002-09-12108.726387
1id_082002-09-1626.28795626.5896032002-09-1227.980670
2id_082002-09-2583.21094584.1949622002-09-1286.344885
3id_112002-09-22416.994843417.1065062002-09-12425.434661
4id_162002-09-14377.916382375.4216002002-09-12400.361977