Comments 6
Почему Dagster вместо Airflow именно в вашем кейсе был предпочтителен?
Проблема ВСЕях аналогичных статей много как и ничего о том для чего. Да понятно, много источников, много данных, плюс s3 для данных ml. Но к этому можно свести примерно все задачи, в том числе те для которых данная архитектура не подходит. Нет ничего о характере и демографии данных, нет ничего о способах обработки. Есть ли например потребность в массовых ad-hoc запросов, надо ли например над этим строить какую то сложную регуляную аналитику, есть ли потребность в ретроспективных выборках (получить данные по состоянию как было 3 мес. назад и так далее). Не скажу за всех, я ничего интересного не увидел
Подход у ребят совершенно правильный. Просто не хватает нормальных движков поверх с3. На одном спарке далеко не уехать с указанными вами кейсами. Но то что осознали что гринплам особенно в облаке это дорого и медленно это уже большой плюс
Для массовых ad-hoc запросов подходят несколько решений по убыванию удобности: spark-connect с динамической аллокацией экзекьюторов (с шардированием если нужно), локальный спарк (в докере), выделенный сервер с поднятым spark shell.
Дельта таблицы позволяют делать time-travel также, за счет чего можно получать ретроспективные выборки. На мой взгляд, цель данной статьи не столько осветить детали имплементации решения, сколько продемонстрировать, что для не самых нагруженных пайплайнов гринплам в облаке, это как из пушки по воробьям.
P.S. Я похоже не в ту ветку ответ написал, прошу понять и простить! не особо часто использую хабр.
"Переход с архитектуры Data Vault 2.0 на архитектуру Delta Lake" - Зачем сравнивать несравнимые понятия? Предполагаю, что имелось ввиду, но мысль сформулирована неверно
Как мы переехали с Greenplum на Delta Table