Декларативный Data Pipeline

[levge]

Интересно, спасибо!

Но вот это немного смущает

«primary_key=True, nullable=True)»

Ключ присутствовать должен всегда, иначе зачем он

[eager_igor]

Согласен, крипово) но ладно, это только пример)

[Ninil]

Декларативный подход имеет очень много неявных ограничений если его применять везде. Эти ограничения каждое по отдельности не критично в каждом конкретном случае, но в enterprise-grade платформе данных накапливаются и в какой то момент, по достижении критической массы становится очень больно.

Ну и стоить трансформации на каскадах temp view … Это верх непрофессионализма дата инженера.

…иногда проекты представляют собой набор модулей без логики и без общего подхода…

Это проблема организационная и управленческо-архитектурная. И она не решается придумыванием (N+1)-го подхода.

[eager_igor]

Конечно, каждый подход имеет плюсы/минусы. Насчет N+1 - мне все же кажется наоборот это плюс, можно выбирать, комбинировать и т.д. Насчет каскадов - да, спасибо, что подсветили, в статье не упоминал этого. Конечно, надо как-то materialization делать, абсолютно согласен, для каких-то шагов, декларативно или ручками

[Ninil]

Для промежуточных шагов не нужна никакая materialization. Архитектура дата-слоев должна оставаться чистой и не зависеть от того, как и чем вы эти слои заполняете. Каким бы маркетинговым термином ее не назвали, есть по большому счету всего 3 слоя: stage - core - marts (последний иногда ещё делят на два подслоя: базовые и прикладные витрины, есть в этом есть реальная потребность),и материлизоваться должны только объекты этих слоев. Широкое использование каскадов промежуточных объектов говорит о нехватки компетенций команды, непродуманой архитектуре или бездумному использованию какого-то фреймворка (например dbt, DLT и т.п.).

[eager_igor]

Нет, тут нет привязки шагов к слоям\архитектурам, шаг - квант трансформаций и все, Есть ооочень сложные трансформации/вычисления, поэтому и разбивка на шаги и возможность их переиспользования

[Ninil]

я указыыаю на то, что все это можно (и нужно) делать без создания промежуточных (временных) объектов. Особенно если используете Spark. Если какой-то шаг предполагается для переиспользования - это отлично ложится в концепт “базовых и прикладных витрин”. Но если у вас появляется “многослойный пирог” из “промежуточных переиспользуемых объектов” - это повод задуматься о гапах в аналитике и архитектуре. В 90% двух слоев витрин: базовые (переиспользуемые) и прикладные (финальная аналитика) - хватает за глаза. Оставшиеся 9% решаются просто добавлением некоторых зависимостей между прикладными (что тоже нормально). Ну и 1% - очень сложные случаи, которые очень редки.