ELT vs ETL: тест с выбором ответа
Синтез всего юнита ELT vs ETL в формате выбора: где идёт Transform, воспроизводимость данных, стоимость warehouse, идемпотентность и контракт medallion.
Шесть вопросов сквозь весь юнит. Каждый — решение, которое ты реально принимаешь при проектировании пайплайна: не определение для зубрёжки, а компромисс, который надо взвесить против цены, реплея и комплаенса.
Убедись, что связываешь, где идёт Transform, с его последствиями вниз по потоку: воспроизводимость данных, счёт warehouse, дисциплина схемы и идемпотентность, которая не даёт повтору удвоить данные.
Какое одно архитектурное изменение в облачных warehouse (Snowflake, BigQuery) — настоящая причина, по которой индустрия перешла от ETL к ELT?
Ты находишь баг таймзоны в трансформации, которая полгода выдавала неверные числа. При ELT с medallion-архитектурой какой быстрый и правильный фикс?
dbt-модель поставили на full-refresh по умолчанию и расписание ежечасно; она пересобирает фактовую таблицу на 2 ТБ с нуля каждый запуск, и счёт Snowflake вырос на 40%. Вывод корректен. Где баг и каков фикс?
Регулируемый финтех принимает платёжные события с PAN-ами карт, и комплаенс запрещает сырым данным держателя карты когда-либо лежать в аналитическом warehouse. Какой паттерн подходит и почему современный дефолт ELT здесь неверен?
EL-инструмент повторил частично-успешную загрузку, и твоя фактовая таблица выручки теперь показывает завышенные итоги. Какого свойства не хватало и каков надёжный дизайн-фикс?
Кто-то называет schema-on-read «чистой свободой — никакой схемы, с которой надо драться на загрузке». Что, по версии юнита, он упускает?
Сквозная нить: где идёт Transform — решает всё ниже по потоку. Разделённые storage/compute сделали посадку сырья дешёвой, что покупает воспроизводимость через контракт medallion (неизменный bronze, очищенный silver, готовый к бизнесу gold). Но T теперь тарифицируется на счёте warehouse, поэтому идёшь инкрементально по умолчанию. А поскольку загрузчики повторяют, каждая загрузка обязана быть идемпотентной — merge по unique_key — иначе повтор удвоит данные. ELT — дефолт; ETL всё ещё побеждает, когда жёсткое правило говорит, что сырая PII не должна касаться warehouse. Теперь, когда ревьюишь дизайн пайплайна или dbt-модель, задаёшь себе три вопроса: где идёт трансформ, инкрементальна ли модель и есть ли у неё unique_key — эти три ответа предсказывают счёт, качество данных и безопасность повтора.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.