Привет, справедливо. Живем, обрастаем сущностями, хотя чистым datavault это назвать сложно. Ждем статью "никогда не делайте data vault", а главное что делать в таком случае.
В случае материализации table, вы можете попробовать с помощью jinja инъекций реализовать логику создания партиций, хотя я не понимаю в каком случае это может понадобится. Если у вас остались вопросы, можем списаться в тг @Maaaaark)
Привет! Создавать таблицы руками не обязательно, хоть и возможно, dbt - сам справится при первом вызове в случае инкрементальной материализации. Лучше всего взять pg, создать тестовый проект и посмотреть логику работы dbt. Если вызывать dbt -d run... он покажет все sql запросы, которые вызывает) По поводу партиций - да, dbt сам не догадается, что надо добавлять партиции, к тому же у вас может быть "default" партиция, в которую уже greenplum будет складывать все данные для которых не нашлось конкретной партиции. Приглашаю улучшать адаптер)
Привет, dbtvault использует материализацию incremental и при первой загрузке генерит один sql запрос (просто раскидывает по сущностям), при повторной загрузке он уже загружает - только новые хабы - только новые линки - только те сателлиты у которых другой hash_diff Конкретно в мы отказались от версионности сателлитов и подправили sql запрос, чтобы сохранялась только первая версия, связано это с тем, что это раздувает таблицу и усложняет запросы(надо выбрать самые актуальные), а в нашем случае профита не приносит.
Если говорить про архитектуру, то "грязные" данные хранились на кластере кликхауса и мы с помощью Dagster'a создавали в нем витрину с теми данными, которые хотим залить в datavault. На стороне гринплама была external table на эту витрину. И тем же дагстером запускали все стадии построения DataVault
Те пайплан выглядит примерно следующим образом: clickhouse->pure_greenplum->raw_greenplum->stage_greenplum->raw_vault_greenplum
Лучше всего попробовать запустить на синтетических данных и посмотреть в target какие sql запросы получились
Приведу пример для хаба:
-- Generated by dbtvault.
WITH row_rank_1 AS (
SELECT * FROM (
SELECT PRODUCT_PK, productname, LOAD_DATE, RECORD_SOURCE,
ROW_NUMBER() OVER(
PARTITION BY PRODUCT_PK
ORDER BY LOAD_DATE ASC
) AS row_number
FROM src_table
) as h
WHERE row_number = 1
),
records_to_insert AS (
SELECT a.PRODUCT_PK, a.productname, a.LOAD_DATE, a.RECORD_SOURCE
FROM row_rank_1 AS a
LEFT JOIN "dvault"."dv_raw_vault"."h_product" AS d
ON a.PRODUCT_PK = d.PRODUCT_PK
WHERE d.PRODUCT_PK IS NULL
)
SELECT * FROM records_to_insert
Привет, у нас максимум было 5-8 джоинов таблиц по 10кк строк и гп справлялся. Бывало падало по спил файлам, но это отдельная тема. Но у нас и сам кластер был не большой.
Мне кажется, что плюсом dbt является возможность интеграции с Airflow/Dagster/Meltano и т.д. Благодаря этому нам во многом удалось автоматизировать elt
Привет, справедливо. Живем, обрастаем сущностями, хотя чистым datavault это назвать сложно. Ждем статью "никогда не делайте data vault", а главное что делать в таком случае.
В случае материализации table, вы можете попробовать с помощью jinja инъекций реализовать логику создания партиций, хотя я не понимаю в каком случае это может понадобится. Если у вас остались вопросы, можем списаться в тг @Maaaaark)
Привет! Создавать таблицы руками не обязательно, хоть и возможно, dbt - сам справится при первом вызове в случае инкрементальной материализации. Лучше всего взять pg, создать тестовый проект и посмотреть логику работы dbt. Если вызывать
dbt -d run...
он покажет все sql запросы, которые вызывает)По поводу партиций - да, dbt сам не догадается, что надо добавлять партиции, к тому же у вас может быть "default" партиция, в которую уже greenplum будет складывать все данные для которых не нашлось конкретной партиции.
Приглашаю улучшать адаптер)
Может вы станете тем самым героем, кто спасет миллионы?
Привет, dbtvault использует материализацию
incremental
и при первой загрузке генерит один sql запрос (просто раскидывает по сущностям), при повторной загрузке он уже загружает- только новые хабы
- только новые линки
- только те сателлиты у которых другой hash_diff
Конкретно в мы отказались от версионности сателлитов и подправили sql запрос, чтобы сохранялась только первая версия, связано это с тем, что это раздувает таблицу и усложняет запросы(надо выбрать самые актуальные), а в нашем случае профита не приносит.
Если говорить про архитектуру, то "грязные" данные хранились на кластере кликхауса и мы с помощью Dagster'a создавали в нем витрину с теми данными, которые хотим залить в datavault. На стороне гринплама была
external table
на эту витрину. И тем же дагстером запускали все стадии построения DataVaultТе пайплан выглядит примерно следующим образом:
clickhouse->pure_greenplum->raw_greenplum->stage_greenplum->raw_vault_greenplum
Лучше всего попробовать запустить на синтетических данных и посмотреть в target какие sql запросы получились
Приведу пример для хаба:
Привет, если нужно получать эти параметры в realtime, dbt возможно не лучший вариант. Возможно подойдут какие то потоковые решения, например spark
Привет, у нас максимум было 5-8 джоинов таблиц по 10кк строк и гп справлялся. Бывало падало по спил файлам, но это отдельная тема. Но у нас и сам кластер был не большой.
Спасибо, буду знать
Мне кажется, что плюсом dbt является возможность интеграции с Airflow/Dagster/Meltano и т.д. Благодаря этому нам во многом удалось автоматизировать elt