как S3 сделал наш Dask строго последовательным

Мы мигрировали проект обрабатывающий петабайты сейсмо-данных из Google Cloud Platform на Amazon Web Services.

То что теоретически могло быть просто заменой нескольких символов в пути к файлам (чтобы вместо gcsfs использовался s3fs) превратилосьв масштабное переписывание кода.

После первого шока когда мы увидели что с файлами на s3 код работает в 100 раз медленнее, мы довольно быстро нашли причину - boto3 на котором базируется s3fs приводил к практически последовательной работе dask workers, которые до этого работалли параллельно с gcsfs и не блокировались ожиданием IO.

Признаюсь, в этот момент я дал опрометчивое обещание быстро все исправить - я был уверен что мне достаточно изменить кластер по умолчанию работающий на потоках на кластер использующий процессы.

Сказался недостаток опыта работы с DASK - опытный инженер сразу бы подумал о разнице работы с памятью и вероятных проблемах.

В итоге когда я переключил на process-based cluster кластер вообще перестал работать - все воркеры уходили в бесконечный shuffle который в итоге завершался OOM.

Буквально год назад это обрекло бы меня на месячное переписывание логики работы с занными, чтобы локализовать оперции внутри воркеров - об этом никто не думал когда они просто использовали общие данные.

Но поскольку случилось это уже в 2026 году я просто сделал десток итераций plan / review plan и implement / review implementation и получил новую реализациюс лучшей локализацией.