Data engineering
ELT vs ETL: собери реплейабельный, идемпотентный пайплайн
Читать про идемпотентность и инкрементальные модели — не то же, что увидеть, как повтор удваивает твою выручку, а потом починить это навсегда. Собери небольшой ELT-пайплайн, доведи его до двух каноничных провалов — взрыва счёта на full-refresh и дубля на повторе — и устрани их инженерно, с доказательством на каждом шаге.
Преврати ментальную модель юнита в работающий пайплайн: посади сырьё в раскладку medallion, трансформируй вперёд в SQL, сделай загрузку инкрементальной и идемпотентной, докажи, что повтор не дублирует, и прогони перезапускаемый backfill — измеряя стоимость до и после.
Собери небольшой ELT-пайплайн (dbt + warehouse вроде Snowflake, BigQuery или DuckDB локально), который принимает поток событий или заказов в раскладку medallion, затем докажи три свойства измерениями: инкрементальные загрузки сканируют только дельту, загрузка идемпотентна при повторе, а 90-дневный backfill перезапускаем по батчам.
- Таблица до/после для перевода на инкрементальность: просканированные байты (или обработанные строки) и время на запуск, измеренные на одних и тех же данных, не оценочно. Запуск по дельте должен сканировать на один-два порядка меньше полной пересборки.
- Воспроизводимое доказательство идемпотентности: одна и та же загрузка, прогнанная дважды, даёт идентичные row-count и идентичные агрегатные итоги (например, SUM(amount)), с показанным конфигом merge.
- Задокументированный контраст сломанного конфига (без unique_key / без is_incremental()) и правильного, с доказательством дубль-строк из сломанного прогона.
- Лог backfill, показывающий запуски по батчам, намеренно упавший батч и чистое возобновление только с этого батча — доказывающий, что backfill перезапускаем и ограничен, а не всё-или-ничего.
- Письменный разбор на абзац: где в твоём пайплайне идёт Transform, почему bronze остаётся неизменным и какое свойство (инкрементальность или идемпотентность) защищает от какого провала (взрыв стоимости или дублирующиеся данные).
- Добавь провал schema-on-read: посади кривую/с лишним полем строку в bronze, покажи, что она проходит загрузку тихо, и пусть dbt-тест в silver её поймает — сделав отложенный счёт за схему конкретным.
- Добавь PII-колонку в источник и реализуй оба контроля: ETL-style маску до загрузки (сырьё не садится) и ELT-style маску в warehouse, затем разбери, какой удовлетворяет правилу «сырая PII не должна лежать в warehouse» и почему.
- Подключи cost-панель: отслеживай credits warehouse / просканированные байты на модель за неделю и алерти, если скан любой модели вырос больше чем в 2 раза от запуска к запуску — канарейка, ловящая регрессию full-refresh до того, как это сделает счёт.
- Добавь изоляцию warehouse на команду и auto-suspend на простое, затем покажи, что тяжёлый backfill на одном warehouse не тормозит запросы на BI-warehouse и что простаивающий compute перестаёт тарифицироваться.
Это цикл, который ты гоняешь, собирая любой реальный ELT-пайплайн: посади сырьё в неизменный bronze, трансформируй вперёд в silver и gold, иди инкрементально, чтобы каждый запуск сканировал только дельту (а не полную пересборку на тарифицируемом warehouse), сделай загрузку идемпотентной через merge по unique_key, чтобы повторы делали upsert, а не дублировали, и структурируй backfill как независимые перезапускаемые батчи. Сделав это один раз на малом датасете — и увидев, как сломанные конфиги падают, — ты доводишь продакшен-версию до мышечной памяти.