Привет, справедливо. Живем, обрастаем сущностями, хотя чистым 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