Комментарии 6
Не имею ничего против самой технологии, но, собеседуя ML-инженеров, заметил какую особенность: опыт работы с dask сильно коррелирует со слабыми знаниями SQL.
На первый взгляд, идея пандаса на стероидах, который позволит взять тестовый файлик на 10 МБ, написать скрипт в питоне, а потом просто взять и запустить его на 10ТБ, ничего не меняя, выглядит заманчиво. Примерно, как идея сделать облачный Excel для больших данных, уверен, зайдет многим менеджерам среднего звена:)
Более того, идея быть уважаемым высокоплачиваемым ML-инженером, не зная SQL, выглядит заманчиво тоже.
Лично для меня, все же, Dask/H2O/любой другой турбо-датафрейм с Pandas-совместимой сигнатурой выглядит какой-то тупиковой веткой развития. Pandas изначально пошёл путем, который не дружит с большими данными. Его императивная парадигма даёт куда меньше свободы оптимизатору, чем декларативный SQL. А использование аналитической БД для подготовки данных, а Pandas лишь, как клея, который позволяет приклеить result set к библиотекам ML/визуализации, выглядит, как то, что отлично работает, и не требует починки
Если уж большие данные, то что-то среднее между Pandas и SQL - это будет Spark тогда. Dask как-то ни туда ни сюда. Сколько с ним пытался работать, если память есть, то и Pandas справится, а если памяти нет, то и Dask не поможет, обязательно какие-то косяки будут. Ну и потом же Vaex придумали, ещё лучше, чем Dask, и какие-то ещё либы наподобие.
А если сравнить не только с Pandas, а например с SciPy или Scikit-learn?
Dask работает с GPU?
Dask для анализа временных рядов