Data engineering
Дата-платформа: проектируем от ингеста до отдачи
Читать про семь хранилищ, согласных друг с другом, — не то же, что заставить их согласиться. Собери небольшую сквозную платформу для одного продуктового домена — от ингеста через склад к отдаче — выбери верное хранилище, формат и индекс под каждую нагрузку, потом нарочно сломай стык и докажи, что твои контракты это ловят.
Преврати весь трек в одну связную систему: направь каждую нагрузку в подходящие хранилище и раскладку, соедини их контрактом доставки, переживающим падение, и покажи, что консистентность, свежесть и lineage — свойства, которые ты спроектировал на стыках, а не допущения.
Спроектируй и собери небольшую дата-платформу для одного продуктового домена (например, e-commerce каталог товаров + заказы), охватывающую ингест, склад и отдачу. Выбери верное хранилище, файловый формат и индекс под каждую нагрузку, свяжи их надёжным контрактом интеграции и докажи, что система остаётся корректной при отказе стыка.
- Одностраничная диаграмма архитектуры, маркирующая каждое хранилище нагрузкой, которую оно обслуживает, и почему выбрана эта раскладка (строковая vs колоночная vs inverted vs векторная) — ни одно хранилище не делает работу, под которую оно неверно.
- Таблица дата-контракта на каждый стык: каноничная схема + владелец, гарантия доставки (и потому идемпотентность консьюмера), freshness SLA и реконсиляция, чинящая дрейф.
- Продемонстрированный сквозной поток: обновление товара в OLTP становится видимым в складе, MV дашборда, поиске и векторном индексе — с показанными путём распространения и лагом.
- Доказательство, что chaos-тест сработал: пойманный дрейф (удалённый товар всё ещё в поиске) и пойманный ремонт (дифф реконсиляции + фикс), плюс freshness-проверка, валящаяся на заглохшем фиде.
- Разбор обхода lineage: при неверном числе на дашборде — обратный путь gold к silver к bronze к CDC-офсету к OLTP, с point-in-time / time-travel запросом, доказывающим, какой слой заглох.
- Добавь гибридный поиск: объедини лексические оценки BM25 и векторное сходство в один ранжированный результат и измерь прирост релевантности над каждым по отдельности на небольшом размеченном наборе запросов.
- Добавь event-sourced аудит-поток для одной сущности (append-only лог с event id + версией) и пересобери read-модель его переигрыванием, доказав, что текущее состояние — свёртка над логом.
- Добавь CI-гейт, гоняющий freshness-проверки и образцовую реконсиляцию на canary-датасете, валящий билд на необъявленном устаревании или нечинёном дрейфе.
- Настрой векторный индекс (ef_search / HNSW M) и построй кривую recall-vs-latency, потом выбери рабочую точку против заявленного SLO по recall, а не дефолт.
Это и есть система, которую тебя реально попросят спроектировать: ингест из строкового OLTP-источника истины, надёжный стриминг через outbox вместо dual-write, колоночное приземление ради дешёвых prunable-сканов, трансформация сквозь переигрываемые medallion-слои поверх сохранённого сырого и отдача каждой нагрузки из хранилища, построенного под неё — MV для дашбордов, inverted index для ключевого поиска, векторный ANN для семантики. Каждое хранилище корректно по отдельности; платформа корректна только потому, что ты спроектировал контракт, гарантию доставки, freshness SLA и реконсиляцию на каждом стыке — и доказал это, сломав один нарочно.