Data engineering
ELT vs ETL: тест с выбором ответа
Суть Синтез всего юнита ELT vs ETL в формате выбора: где идёт Transform, реплейабельность, стоимость warehouse, идемпотентность и контракт medallion.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов сквозь весь юнит. Каждый — решение, которое ты реально принимаешь при проектировании пайплайна: не определение для зубрёжки, а компромисс, который надо взвесить против цены, реплея и комплаенса.
Цель
Убедись, что связываешь, где идёт Transform, с его последствиями вниз по потоку: реплейабельность, счёт warehouse, дисциплина схемы и идемпотентность, которая не даёт повтору удвоить данные.
Викторина
Completed
Какое одно архитектурное изменение в облачных warehouse (Snowflake, BigQuery) — настоящая причина, по которой индустрия перешла от ETL к ELT?
Heads-up Чистая скорость запросов — не драйвер: Spark всё ещё выигрывает многие тяжёлые джобы. Переход был экономическим и архитектурным: дешёвый разделённый storage сделал посадку сырья доступной, чего ETL никогда не мог.
Heads-up dbt оседлал волну, а не создал её. Включающим изменением было разделение storage/compute. dbt — лишь доминирующий способ писать in-warehouse T после того, как это стало возможным.
Heads-up Объёмы выросли, а не упали. ELT стал жизнеспособен вопреки бо́льшим объёмам именно потому, что разделённый storage сделал хранение всего этого дешёвым.
Викторина
Completed
Ты находишь баг таймзоны в трансформации, которая полгода выдавала неверные числа. При ELT с medallion-архитектурой какой быстрый и правильный фикс?
Heads-up Это режим провала ETL — re-extract нужен только когда сырьё выброшено. ELT держит сырьё в bronze постоянно ровно для того, чтобы переигрывать трансформы, не трогая источник, который мог измениться или заблокировать тебя по rate-limit.
Heads-up Ручная мутация gold ломает контракт пересобираемости и невоспроизводима — следующий полный запуск тихо откатит твой патч. Чини трансформацию, а не вывод.
Heads-up Это верно только в ETL, где сырьё выбросили. Вся суть ELT в том, что bronze сохранён, поэтому трансформированная история всегда переигрываема.
Викторина
Completed
dbt-модель поставили на full-refresh по умолчанию и расписание ежечасно; она пересобирает фактовую таблицу на 2 ТБ с нуля каждый запуск, и счёт Snowflake вырос на 40%. Вывод корректен. Где баг и каков фикс?
Heads-up Корректность и стоимость — независимые оси в ELT. Идеально корректный трансформ, материализованный как ежечасная полная пересборка, — это четырёхзначный пункт счёта; счёт и есть баг, даже когда числа верны.
Heads-up Тарификация работает как задумано — ты платишь за warehouse-секунду за compute, который запросил. Фикс на твоей стороне: перестань пересканировать 2 ТБ ежечасно, перейдя на инкрементальность.
Heads-up Бо́льший warehouse завершает быстрее, но тарифицирует больше кредитов в секунду; суммарная стоимость того же полного скана почти не меняется. Рычаг — сканировать меньше данных (инкрементально), а не сканировать те же данные быстрее.
Викторина
Completed
Регулируемый финтех принимает платёжные события с PAN-ами карт, и комплаенс запрещает сырым данным держателя карты когда-либо лежать в аналитическом warehouse. Какой паттерн подходит и почему современный дефолт ELT здесь неверен?
Heads-up Это правильный дефолт для большинства данных, но проигрывает по жёсткому ограничению: сырые PAN физически садятся в bronze до любой маскировки, поэтому данные держателя карты лежат в warehouse — ровно то, что комплаенс запрещает.
Heads-up Динамическая маскировка прячет PII от читателей, но сырые значения всё равно физически хранятся в bronze. Маскировка — контроль на момент view, а не контроль хранения; хранимое-но-скрытое всё равно нарушает «никогда не лежит в warehouse».
Heads-up Политики доступа управляют тем, кто читает данные, а не тем, хранятся ли они. Правило здесь о хранении, поэтому ни один in-warehouse контроль его не удовлетворит — маскировка должна идти до загрузки.
Викторина
Completed
EL-инструмент повторил частично-успешную загрузку, и твоя фактовая таблица выручки теперь показывает завышенные итоги. Какого свойства не хватало и каков надёжный дизайн-фикс?
Heads-up Повторы при временном сбое — корректное поведение, и нельзя полагаться на то, что повтора не будет. Фикс — сделать загрузку безопасной к перезапуску (идемпотентной), а не запретить перезапуск.
Heads-up У append-загрузки нет ключа для дедупликации, поэтому warehouse спокойно хранит дубли. Дедупликация — твой дизайн-выбор (unique_key с merge), а не автоматическая гарантия.
Heads-up Джоб-чистильщик — пластырь, который гонится за каждой новой загрузкой и может удалить легитимные строки. Идемпотентные загрузки не дают дублю записаться вообще — это и есть настоящий фикс.
Викторина
Completed
Кто-то называет schema-on-read «чистой свободой — никакой схемы, с которой надо драться на загрузке». Что, по версии юнита, он упускает?
Heads-up Он убирает работу со схемой только на момент загрузки. Работа возвращается ниже по потоку: ты обязан обеспечить структуру в silver тестами, иначе плохие данные тихо испортят gold.
Heads-up Дело не в скорости запросов, а в том, когда происходит валидация. Цена пропуска валидации на загрузке — тихие баги качества данных, всплывающие поздно, а не медленные чтения.
Heads-up Он применим к любому формату, посаженному сырьём. Суть в отсрочке обеспечения до момента чтения/трансформа независимо от формы источника.
Итог
Сквозная нить: где идёт Transform — решает всё ниже по потоку. Разделённые storage/compute сделали посадку сырья дешёвой, что покупает реплейабельность через контракт medallion (неизменный bronze, очищенный silver, готовый к бизнесу gold). Но T теперь тарифицируется на счёте warehouse, поэтому идёшь инкрементально по умолчанию. А поскольку загрузчики повторяют, каждая загрузка обязана быть идемпотентной — merge по unique_key — иначе повтор удвоит данные. ELT — дефолт; ETL всё ещё побеждает, когда жёсткое правило говорит, что сырая PII не должна касаться warehouse.