Как стать автором
Обновить
6
0
Марк @p0mami

Data Scientist

Отправить сообщение

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

Привет, если нужно получать эти параметры в realtime, dbt возможно не лучший вариант. Возможно подойдут какие то потоковые решения, например spark

Привет, у нас максимум было 5-8 джоинов таблиц по 10кк строк и гп справлялся. Бывало падало по спил файлам, но это отдельная тема. Но у нас и сам кластер был не большой.

Спасибо, буду знать

Мне кажется, что плюсом dbt является возможность интеграции с Airflow/Dagster/Meltano и т.д. Благодаря этому нам во многом удалось автоматизировать elt

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность