To be specific I want to parallelize xgboost cross-validation
Please help me design such Dask application. Let's say I have a dask cluster. I want to do a 10-fold cross-validation for xgboost.
Let's say Scheduler needs to keep track of the current state of the job. It launches 10 xgboost tasks on 10 different workers(for each of the folds), with say 10000 iterations for each task maximum.
After each iteration is finished, there is a callback that reports current metric like rmse. So, worker would send that to Scheduler and receive an answer whether to continue or wrap up.
The main scheduler keeps periodically receiving those updates asynchronously. When all workers report a metric at a particular iteration, the scheduler aggregates them (just calculates mean) and pushes it to the current result stack. It also checks whether the result hasn't been improved in the last say 50 iterations, the scheduler tells all workers to wrap up (maybe at the next communication) and report back the result (which is a tree object).
After it gets them all, it returns all trees (and maybe metrics too).
To me it sounds like you're describing something similar to Hyperband, which is currently implemented in Dask-ML. You might want to look at these docs:
https://ml.dask.org/modules/generated/dask_ml.model_selection.HyperbandSearchCV.html?highlight=hyperband
If you want to implement something on your own, some of the pieces for that code may be of use to you as well. Dask-ML lives on Github at https://github.com/dask/dask-ml
Related
I have a process in which an optimiser which runs thousands of iterations with different inputs.
optimizer = ng.optimizers. NGOpt (parametrization=instrum, budget=10000, num workers = 25)
with futures. ProcessPoolExecutor (max workers=optimizer.num_workers) as executor:
recommendation optimizer.minimize (run_model, verbosity = 0, executor = executor, batch_mode=False)
Here I'm trying to minimise the return value of the function run model which is having the dataframes I want to log. The optimiser is using 25 workers as shown in the code
Currently multiprocessing is integrated with this process to reduce run time and also scale up the number of iterations.
The problem I have here is that, during each of the process I need to log the dataframes in a consolidated form so that I can monitor the performance of the optimiser in real time.
I keep running into process failures when if I use any I/o files
Created a sqllite3 database and append values to the tables in them as an interim solution .Although I'm aware this is not a full proof answer but is the only solution that I could think off.
Not able to incorporate multithreading as well due to compatibility issues and encountering GIL
Looking for any suggestions or methods to store these multiple dataframes during multipreocessing
Given a pipeline / conveyor with two steps:
a processing step
a writing step, which cannot be executed in parallel due to e.g. a filelock and is thus the bottleneck
How can define the optimal number of workers for the processing step?
If we choose too few workers, the writing step may become idle.
If we choose too many workers, the processing step may result in a large memory spike at the beginning.
If believe we want to aim for time_processing_step / number_workers ~= time_writing_step. However, we don't know these times upfront. And maybe the time is not even constant for each input item. Hence: Is there a way to automatically balance such a pipeline?
Notes:
I'm thinking of a pipeline implemented in the form of e.g. a ThreadPoolExecutor or ProcessPoolExecutor.
I found this relevant SO thread, but it's already 12 years old, so maybe something changed since then.
I am using Dask Bag to run some simple map-reduce computation on a special cluster:
import dask.bag as bag
summed_image = bag.from_sequence(my_ids).map(gen_image_from_ids).reduction(sum, sum).compute()
This code generates a chained computation, starts mapping from from_sequence and gen_image_from_ids, and then reduces all results into one with sum's. Thanks to Dask Bag's feature, the summation is done in parallel in a multi-level tree.
My special cluster setting has higher failure rate because my worker can be killed anytime and the CUP is taken over by other higher-order processes and then released after a while. The kill may occur once on only a single node per 5 minutes, but my total reduction job may take more than 5 minutes.
Although Dask is good at failure recovery, my job sometimes just never ends. Consider if any internal node in the job tree gets killed, the temporary intermediate results from all previous computations are missing. And the computation should restart from beginning.
There is replicate for Dask Future objects but I could not find similar feature on higher-level Dask Bag or Dataframe to ensure data resiliency. Please let me know if there is a common treatment to keep intermediate results in a Dask cluster with super-high failure rate.
Update - My workaround
Maybe any distributed computing system will suffer from frequent failures even though the system can recover from them. In my case the worker shutdown is not essentially system failure, but is triggered by the higher-order process. So instead of directly killing my workers, the higher-order process now launches a small python script to send retire_worker() command, when it starts running.
As documented, by retire_worker() scheduler will move data from the retired worker to another one available. So my problem is temporarily solved. However, I sill leave the question open since I think replicated, redundant computing would be a faster solution, and better use idle nodes in the cluster.
This might not be the solution you are looking for, but one option is to divide up the task sequence into small-enough batches that can ensure that the task will complete in time (or will be quick to re-do from scratch).
Something like this perhaps:
import dask.bag as db
from toolz import partition_all
n_per_chunk = 100 # just a guess, the best number depends on the case
tasks = list(partition_all(n_per_chunk, my_ids))
results = []
for t in tasks:
summed_image = (
db
.from_sequence(my_ids)
.map(gen_image_from_ids)
.reduction(sum, sum)
.compute()
)
results.append(summed_image)
summed_image = sum(results) # final result
There are other things to keep in mind here regarding re-starting the workflow on failure (or potentially launching smaller tasks in parallel), but hopefully this gives you a starting point for a workable solution.
Update: More trials later -- this answer is not ideal because client.replicate() command is blocking. I suspect it requires all futures to be done before making replica -- this is unwanted because 1. any intermediate node can disconnect before all are ready, and 2. it prevents other tasks to run asynchronously. I need other way to make replica.
After lots of trials, I found one way to replicate the intermediate results during chained computation to realize data redundancy. Note the parallel reduction function is a Dask Bag feature, which does not directly support replicate facility. However, as Dask document states, one can replicate low-level Dask Future objects to improve resiliency.
Following #SultanOrazbayev's post to manually perform partial sums, with persist() function to keep partial sums in cluster memory as in the comment, the returned item is essentially a Dask Future:
import dask.bag as db
from dask.distributed import futures_of
from toolz import partition_all
n_per_chunk = 100 # just a guess, the best number depends on the case
tasks = list(partition_all(n_per_chunk, my_ids))
bags = []
for t in tasks:
summed_image = (
db
.from_sequence(my_ids)
.map(gen_image_from_ids)
.reduction(sum, sum)
.persist()
)
bags.append(summed_image)
futures = futures_of(bags) # This can only be called on the .persist() result
I can then replicate these remote intermediate partial sums and feel safer to sum the futures to get final result:
client.replicate(futures, 5) # Improve resiliency by replicating to 5 workers
summed_image = client.submit(sum, futures).result() # The only line that blocks for the final result
Here I feel replica of 5 is stable for my cluster, although higher value will incur higher network overhead to pass the replica among workers.
This works but may be improved, like how to perform parallel reduction (sum) on the intermediate results, especially when there are lots of tasks. Please leave me your suggestions.
I have been using Optuna to tune my hyperparameters for Catboostregressor. However I have set it to 100 iterations, due to having a large dataset it's taking a very long time to tune.
My code can be found here in my previous post: Optuna for Catboost outputs "trials" in random order?
Now it has reached 50 iterations, and I wish to stop it. I was wondering if I were to hit the "stop" button on jupyter notebook now, will I still be able to call my tuning params/output in my next cell using study.best_params and study.best_trials? Or it will throw me an error because I interrupted the tuning before 100% completion (keyboard interruption)?
I don't want to risk re-running everything again if it doesn't work because it took me almost a day to tune 50 trials, so I can't risk stopping it if I won't be able to generate call the params and trials from study in my next cell. I wanted to test this out myself but my tuning is still running on all CPUs so I'm afraid opening a new script will cause my whole system to crash. Appreciate if anyone knows the answer.
No it won't save the results anywhere as these results are stored in ephemeral storage. What you would need is a persistent storage of the studies which can be achieved using the RDB backend. This option allows you to make use of a database to store the study results such as the best_params, best_trial, best_value, and trials. Think of it as an experiment tracking tool builtin to optuna.
I have a Random Forest, and using K-fold validation I'm trying to find optimal values for depth lenght and some other parameters.
I am running a QuadCore CPU thus I am trying to figure out, how i can iterate over say max_depth = range(50,101), such that when one of the cores is done fitting its forest with its max_depth it automatically takes the next max_depth in the list.
Or is it better splitting max_depth in 4 equal sizes and just make 4 processes manually?
IMHO, the best solution would be using queues and manual process-creation. That way, you have full control over the processes.
Create your function that does the Random forest after getting its max_depth from an input queue. Push the result in an output queue.
You put all your max_depthvalues in the input queue
You create a number of processes that best fit your architecture. Typically, 8 processes for 4 cores (with Hyperthreading) is a goot starting point
Start the processes.
After starting the processes each one will take one argument from the input queue and does your RandomForest. After one process has finished, it puts the result in another queue and retrieves another argument from the input queue. Using the queue, you don't have to care which process is finishing first etc. as the queues are thread-safe, so that only one process can access them. Any other will wait for access. You also wouldn't have to worry what your best split of the max_depth-list is. As soon as one process is finished it automatically gets a new value for the calculation. If nothing is in the queue, it stops.
I usually prefer this type of multiprocessing over Pool as I have a bit more control. Here is a small example.