Какая связь между Blazing SQL и dask?

Question

Я пытаюсь понять, является ли Blazing SQL конкурентом или дополнением к dask.

У меня есть данные среднего размера (10-50 ГБ), сохраненные в виде файлов паркета в Azure хранилище больших двоичных объектов .

IIU C Я могу запрашивать, объединять, агрегировать, группировать с помощью Blazing SQL, используя синтаксис SQL, но я также могу читать данные в CuDF, используя dask_cudf, и выполнять все те же операции, используя синтаксис python / dataframe.

Итак, мне кажется, что они являются прямыми конкурентами?

Правильно ли то, что одно из преимуществ использования dask заключается в том, что он может работать на разделах поэтому он может работать с наборами данных, большими, чем память GPU, тогда как Blazing SQL ограничен тем, что может уместиться на GPU?

Почему лучше использовать Blazing SQL, а не dask?

Редактировать:
Документы говорят о dask_cudf, но фактическое репо заархивировано, сообщая, что поддержка dask теперь доступна cudf сам. Было бы хорошо узнать, как использовать dask для работы с наборами данных больше, чем у gpu-memory, с cudf

Answer 1

Полное раскрытие информации Я являюсь соучредителем Blazing SQL.

Blazing SQL и Dask не являются конкурентоспособными, на самом деле вам нужен Dask для использования Blazing SQL в распределенном контексте. Все выдающиеся результаты Blazing SQL возвращают наборы результатов dask_cudf, так что вы можете затем продолжить операции над этими результатами в синтаксисе python / dataframe. На ваш взгляд, вы правы по двум причинам:

1. Blazing SQL в настоящее время ограничен памятью GPU и фактически некоторой системной памятью, используя Unified Virtual CIMA . Это изменится в ближайшее время, мы оцениваем около v0.13, который запланирован на начало марта. После этого релиза память будет разливаться и кэшироваться в системную память, локальные диски или даже в наши поддерживаемые подключаемые модули хранения, такие как AWS S3, Google Cloud Storage и HDFS.
2. Вы можете полностью записать SQL операции как функции dask_cudf, но пользователь обязан знать все эти функции и оптимизировать их использование. SQL имеет ряд преимуществ в том, что он более доступен (больше людей знают об этом, и его очень легко освоить), и существует множество исследований, посвященных оптимизации SQL (например, оптимизаторам на основе затрат) для выполнение запросов в масштабе.

Если вы хотите sh сделать RAPIDS доступным для большего числа пользователей SQL - это довольно простой процесс регистрации, и его очень легко оптимизировать из-за необходимости сокращения объема оптимизировать SQL операций над Dask, что имеет множество других соображений.