Комментарии 11
Привет, спасибо за статью. Как реализовали инкрементальную загрузку, на основе снепшотов или что-то своё накрутили? Формируете ли таблицу ключей, на основе которой строится таблица сравнения для последующего инкрементельного обновления? Если да, то очень интересно, как реализовывали на dbt.
Привет, 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
Когда-нибудь наступит время когда кто-нибудь соберётся с силами и найдет достаточно времени чтобы наконец-то написать большую развернутую статью на тему "никогда не делайте data vault" :)
Проблема только в том что большинству из тех кто это понимает не хватает времени, тк они все эти датавольты переделывают
Марк, спасибо за статью и отдельно за адаптер dbt-greenplum)
Правильно же понял, что DDL-обвёртка для dbtvault-моделей по сути будет выполняться один раз, так как там инкрементальная материализация? Ну и DDL достаточно разово сделать напрямую в базе и тогда dbt вообще не будет выполнять код создания инкременатальной таблицы? Тем более когда партиции, нарезанные из dbt, закончатся, то "донарезать" все равно же в базе будете не через dbt?
А вот для материализации 'table' (или какой-нибудь хитрой кастомной)- это прям то, что нужно.
Привет! Создавать таблицы руками не обязательно, хоть и возможно, dbt - сам справится при первом вызове в случае инкрементальной материализации. Лучше всего взять pg, создать тестовый проект и посмотреть логику работы dbt. Если вызывать dbt -d run... он покажет все sql запросы, которые вызывает)
По поводу партиций - да, dbt сам не догадается, что надо добавлять партиции, к тому же у вас может быть "default" партиция, в которую уже greenplum будет складывать все данные для которых не нашлось конкретной партиции.
Приглашаю улучшать адаптер)
развитие Airflow от его же создателей
Не верно. Dagster - это продукт Nicholas Schrock и его команды в Elementl. Бывший сотрудник Facebook, со-создатель GraphQL. Airflow вырос из Airbnb, одним из основных первых авторов был Maxime Beauchemin. Кажется что они никак не связаны.
Спасибо за статью. Как вам живется с Data Vault?
DataVault на Greenplum с помощью DBT