Data engineering
Дата-платформа: тест с выбором ответа
Суть Сквозной синтез: выбери правильное хранилище, формат и индекс под нагрузку — через OLTP/OLAP, ELT, Parquet, MV, event sourcing, поиск и векторы.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, прошивающих весь трек. Каждый — проектное решение, которое ты принимаешь, когда один факт обязан жить сразу в нескольких хранилищах: не определение, а выбор хранилища, формата или контракта под реальную нагрузку.
Цель
Убедись, что умеешь направить нагрузку в подходящее хранилище и раскладку и рассуждать о стыках между ними — к этому синтезу вели юниты про OLTP/OLAP, ELT, Parquet, MV, event sourcing, поиск и векторы.
Викторина
Completed
Один факт о товаре должен обслуживать точечные lookups на пути оформления заказа И полный скан таблицы для подсчёта выручки в аналитике. Какая архитектура верна для senior?
Heads-up Колоночное расширение помогает сканам, но ты по-прежнему платишь write amplification строкового стора на OLTP-пути и привязываешь аналитическую нагрузку к транзакционной БД. Первый юнит трека ровно об этом: одна раскладка не оптимизирует и крошечные индексированные записи, и огромные колоночные сканы.
Heads-up Реплика копирует ту же строковую раскладку, так что скан выручки всё равно читает каждую колонку каждой строки с диска. Реплики изолируют нагрузку, а не паттерн доступа — скан остаётся медленным, потому что раскладка под него неверная.
Heads-up Колоночные сторы отвечают на одно-строчный lookup, трогая множество row groups и реконструируя колонки — высокая задержка на строку и отсутствие настоящего точечного индекса. Путь оформления требует OLTP; склад — для сканов.
Викторина
Completed
Команда выбирает между ETL (трансформация в отдельном движке до загрузки) и ELT (загрузка сырого, трансформация внутри склада через dbt). Данные грязные, а бизнес постоянно меняет определение «активного пользователя». Что подходит и почему?
Heads-up Трансформация до загрузки выбрасывает сырые данные, поэтому при смене определения «активного пользователя» переиграть нельзя — придётся переподтягивать из источника, если он ещё хранит данные. ELT держит сырой bronze именно ради того, чтобы переопределение было re-run, а не re-ingest.
Heads-up Современные склады + dbt выражают сколь угодно сложные SQL/UDF-трансформации. Индустрия перешла на ELT, потому что вычисления склада стали дёшевы и эластичны; где исполняется T — это решение про cost/replay/fidelity, а не потолок возможностей.
Heads-up Перенос логики бизнес-определений в приложение привязывает её к деплоям и полностью теряет сырой аудит-след. Смысл разбиения bronze/silver/gold в том, что определения живут в версионируемых, переигрываемых трансформациях поверх сохранённых сырых данных.
Викторина
Completed
Ночной запрос дашборда фильтрует event_date = '2026-05-01' AND country = 'US' по таблице Parquet/Iceberg на 2 ТБ и всё равно сканирует почти все данные. Что даёт наибольший рычаг?
Heads-up У Parquet нет построчного B-tree индекса; pruning делается раскладкой партиций плюс статистикой футера по row group. Инстинкт индексирования из OLTP не переносится — ты делаешь предикаты prunable, а не индексируешь.
Heads-up Строковый формат делает колоночный скан хуже: читаешь каждую колонку каждой строки. Колоночный плюс статистика футера — это и есть то, что позволяет движку читать только event_date/country и пропускать несовпадающие row groups.
Heads-up 2 ТБ редко влезают в память, и ты всё равно просканируешь всё; кэширование маскирует настоящую проблему. Pruning означает вообще не читать ненужные 99%, что и дают статистика футера плюс партиционирование.
Викторина
Completed
Gold materialized view, обслуживающая дашборд, обновляется каждые 6 часов. Финансовый лид жалуется, что число «неверное» против живого SQL-подсчёта. Оба внутренне корректны. Что в дизайне сделано не так?
Heads-up Если оба числа внутренне корректны, разрыв — во времени, а не в логике. MV права для своего 6-часовой давности снимка, а живой подсчёт прав для «сейчас» — проверь и объяви свежесть прежде, чем подозревать трансформацию.
Heads-up MV нормальны для финансов, когда устаревание подходит под вопрос. Провал — оставить устаревание необъявленным и без мониторинга, а не сам факт использования MV: управляемая цена — это refresh и устаревание, которое он протекает.
Heads-up Refresh на каждую запись убивает смысл MV и может стоить дороже исходного запроса. Senior-ход — объявить SLA под нужную вопросу свежесть, а не гнаться за нулевым устареванием.
Викторина
Completed
Сервис пишет заказ в Postgres, потом публикует 'OrderPlaced' в Kafka, чтобы среагировали поиск и аналитика. Иногда поисковый индекс так и не узнаёт о заказе. В чём корневая причина и фикс?
Heads-up Событие теряется до того, как достигнет Kafka — процесс умер после коммита в Postgres, но до публикации. Durability брокера не спасёт событие, которое никогда не было отправлено; нужно сделать запись и событие атомарными через outbox.
Heads-up Это лишь инвертирует dual-write: теперь падение после публикации, но до коммита, испускает событие для заказа, которого нет. Перестановка двух не-транзакционных записей никогда не закрывает разрыв — только одна атомарная запись (outbox) плюс реконсиляция.
Heads-up Поллинг вручную пересобирает CDC, ограничивает свежесть интервалом опроса и пропускает удаления, если не опрашивать ещё и tombstones. Фикс — сделать путь событий надёжным (outbox плюс идемпотентный консьюмер), а реконсиляцию оставить как страховку.
Викторина
Completed
Поиск по каталогу должен находить опечатанные названия товаров, А RAG-ассистент — отвечать на «ноутбук, хороший для видеомонтажа». Одна команда предлагает использовать векторный индекс для обоих. Какое разделение верно?
Heads-up Эмбеддинги ловят семантику, но размывают точные токены, SKU и редкие термы, так что точный запрос по номеру модели деградирует. Inverted index силён в точном/лексическом совпадении и ранжировании BM25; векторы — в смысле. Они решают разные половины релевантности.
Heads-up BM25 ранжирует по перекрытию термов, так что «хороший для видеомонтажа» не совпадёт с описанием «высокопроизводительный GPU и 32 ГБ RAM» без общих слов. Семантический retrieval требует векторного сходства, а не частоты термов.
Heads-up Скан по подстроке не ранжирует, не терпит опечаток, не совпадает семантически и полностью сканирует OLTP-стор. Поиск — это совпадение плюс ранжирование, а семантический retrieval — это сходство; ни то ни другое не SQL LIKE.
Итог
Сквозная нить трека — одна привычка: направь каждую нагрузку в подходящие хранилище и раскладку, а потом спроектируй контракт на каждом стыке. Строковое OLTP для точечных записей, колоночный Parquet для сканов (с pruning по статистике футера), ELT поверх сохранённого сырого ради переигрываемых определений, MV ради задержки чтения с объявленным freshness SLA, outbox против dual-write, inverted index для лексического поиска и векторный ANN для семантического retrieval. Каждое хранилище корректно для своей задачи; система остаётся корректной, только когда ты владеешь схемой, гарантией доставки, freshness SLA и реконсиляцией между ними.