8 вопросов по теме «Data Engineering: Архитектура» на собеседовании

Короткий ответ: Сначала уточняю требования (объём, скорость поступления, требуемая латентность, SLA, паттерны доступа), и только потом иду по слоям: приём → хранение → обработка → отдача, добавляя качество и стоимость. Инструменты выбираю в самом конце.

Подробно:

1. Уточнить требования — объём (ГБ/ТБ/ПБ в сутки), velocity (событий/сек), нужная латентность на чтении (секунды vs часы), кто потребитель (BI-аналитик, ML, приложение), требования к консистентности и retention.
2. Приём (ingestion) — батч или стриминг, pull или push, буфер (Kafka) для развязки продюсеров и консюмеров, схема и её эволюция.
3. Хранение — сырой слой в дата-лейке (дёшево, любые данные), витрины в warehouse/лейкхаусе; выбор формата (Parquet), партиционирование.
4. Обработка — трансформации (dbt/Spark/Flink), модель данных (звезда, medallion), идемпотентность и обработка поздних данных.
5. Отдача (serving) — BI поверх warehouse, низколатентный OLAP/KV для приложений, реверс-ETL в операционные системы.
6. Качество и стоимость — тесты данных, контракты, мониторинг свежести; оценка стоимости сканируемых байт и простаивающих вычислений.

Требования (объём · latency · SLA · доступ)
        │
        ▼
 Приём ──► Хранение ──► Обработка ──► Отдача
(Kafka)   (лейк →       (dbt/Spark/  (BI · OLAP ·
          warehouse)     Flink)       реверс-ETL)
        └──── качество данных · стоимость ────┘

⚠️ Частая ошибка: прыгать сразу к инструментам («возьмём Kafka и Spark»), не выяснив объём, латентность и паттерны доступа — под дневной батч стриминг не нужен.

Короткий ответ: Lambda держит два пути — батч-слой для точных полных пересчётов и speed-слой для свежести, объединяя их на отдаче; Kappa убирает батч и обрабатывает всё как единый стрим, переигрывая лог при необходимости. Kappa проще в эксплуатации, Lambda даёт устойчивый батч-пересчёт.

Подробно:

• Lambda — три слоя: batch layer (полный пересчёт по всему датасету, источник истины), speed layer (стрим для актуальных данных), serving layer (объединяет оба). Минус — дублирование логики в двух кодовых базах.
• Kappa — только стриминг: всё пишется в durable-лог (Kafka), обработка одна, историю получаем реплеем лога. Минус — тяжёлые исторические пересчёты и большие окна упираются в стрим-движок.
• Когда Lambda — есть тяжёлая батч-аналитика, где важны точность и полный reprocessing, а стрим лишь подмешивает свежесть.
• Когда Kappa — стриминг-first продукт, одна логика, движок (Flink) тянет и реплей; меньше операционных издержек.

Lambda:  источник ─┬─► batch layer ─┐
                   └─► speed layer ─┴─► serving

Kappa:   источник ──► лог (Kafka) ──► стрим-обработка ──► serving
                          ▲ реплей │

⚠️ Частая ошибка: тянуть Lambda с двумя кодовыми базами там, где хватает Kappa — двойная логика расходится и даёт разные числа в батче и стриме.

Короткий ответ: SDK/коллектор шлёт события в Kafka как буфер, развязывающий продюсеров и потребителей; фиксируем схему (Avro/Protobuf) в Schema Registry, партиционируем по ключу, а из топика грузим в сырой слой дата-лейка и дальше в warehouse. Kafka сглаживает пики и даёт переигровку.

Подробно:

1. Сбор — клиентский SDK/edge-коллектор батчит события, шлёт по HTTP/gRPC; на входе валидация и обогащение (гео, user-agent).
2. Буфер — Kafka — развязывает скорость продюсеров и потребителей, держит всплески, даёт replay. Партиционирование по user_id/session_id для порядка в рамках ключа.
3. Схема — Avro/Protobuf + Schema Registry, backward-compatible эволюция; «битые» события в dead-letter топик.
4. Landing в лейк — консюмер (Kafka Connect/Flink) пишет в объектное хранилище в Parquet, партиции по дате/часу; это сырой (bronze) слой.
5. Дальше — обработка в curated-слой и загрузка витрин в warehouse; идемпотентность по event_id, дедупликация.

SDK/коллектор ─► Kafka (партиции по user_id) ─► консюмер
                   │  replay, буфер                 │
                   │                                ▼
             Schema Registry          лейк (Parquet, /dt=YYYY-MM-DD/hh)
                                                    │
                                                    ▼
                                          warehouse / витрины

⚠️ Частая ошибка: писать события напрямую в warehouse синхронно из приложения — при всплеске трафика бэкенд ложится; буфер (Kafka) обязателен для развязки и сглаживания пиков.

Короткий ответ: Выбор диктует нужная латентность и ценность свежести: если бизнесу хватает данных раз в час/сутки — батч (дешевле, проще); если решения принимаются за секунды (фрод, алерты, персонализация) — стриминг. Современная платформа совмещает: Kafka + warehouse + dbt для батча и Flink для стриминга.

Подробно:

• Батч — обработка по расписанию (ELT: Fivetran/Airbyte → warehouse → dbt). Дёшево, легко тестировать и пересчитывать, проще идемпотентность. Латентность — минуты-часы.
• Стриминг — обработка событие за событием / микро-окнами (Flink, Kafka Streams). Латентность — суб-секунды; сложнее: состояние, поздние данные, exactly-once.
• Правило выбора — начинать с вопроса «сколько стоит задержка данных?». Нет ценности в суб-секундной свежести → батч.
• Гибрид — один durable-лог (Kafka) кормит и стрим-путь (Flink для realtime-витрин), и батч-путь (выгрузка в лейк/warehouse, dbt-модели).

⚠️ Частая ошибка: строить стриминг «на будущее», когда бизнесу хватает дневного батча — платите за сложность и состояние, не получая ценности от свежести.

Короткий ответ: Лейкхаус кладёт данные в объектное хранилище (S3/GCS) в открытом табличном формате (Iceberg/Delta/Hudi), который даёт ACID-транзакции, эволюцию схемы и time travel поверх файлов, а сверху работает движок запросов (Trino/Spark/Databricks). Слои организуем по medallion: bronze → silver → gold.

Подробно:

1. Хранение — объектное хранилище: дёшево, практически бесконечно масштабируется, разделяет хранение и вычисления.
2. Табличный формат — Iceberg/Delta/Hudi поверх Parquet: ACID, snapshot-изоляция, эволюция схемы/партиций, time travel, компакция мелких файлов.
3. Слои (medallion) — bronze (сырые данные как есть), silver (очищенные, типизированные, дедуп), gold (агрегаты и витрины под бизнес).
4. Движок — Trino/Spark/Databricks читают тот же формат; BI ходит в gold. Один экземпляр данных для SQL, ML и стрима.
5. Управление — каталог (Glue/Unity), контроль доступа, эволюция без переписывания данных.

        Объектное хранилище (S3/GCS)
   ┌───────────┬───────────┬───────────┐
   │  bronze   │  silver   │   gold    │ ← Iceberg/Delta (ACID, time travel)
   │  сырые    │ очищенные │  витрины  │
   └───────────┴───────────┴───────────┘
        ▲ ingest        ▲ Trino/Spark/dbt ─► BI · ML

⚠️ Частая ошибка: свалить всё в «дата-лейк» из голых Parquet-файлов без табличного формата — получаете болото данных без ACID, без эволюции схемы и с проблемой мелких файлов.

Короткий ответ: Разделяйте хранение и вычисления, чтобы платить за них независимо; главные драйверы затрат — объём сканируемых байт и простаивающие вычисления. Управляют этим партиционированием, кластеризацией, колоночными форматами и авто-суспендом кластеров.

Подробно:

1. Разделение хранения и вычислений — хранилище дешёвое и растёт отдельно; вычисления поднимаем под нагрузку и гасим. Масштабирование — горизонтальное.
2. Меньше сканируемых байт — партиционирование по дате/ключу, partition pruning, кластеризация, колоночный Parquet, чтение только нужных колонок. В pay-per-scan (BigQuery) это прямые деньги.
3. Простаивающие вычисления — авто-suspend варехаусов/кластеров, right-sizing, спот-инстансы для батча, отдельные варехаусы под разные нагрузки.
4. Материализация — предагрегаты/инкрементальные модели вместо пересчёта всего; кэш результатов.
5. FinOps — мониторинг стоимости по запросам/командам, лимиты, аллокация затрат.

⚠️ Частая ошибка: игнорировать объём сканируемых байт — SELECT * по непартиционированной таблице в pay-per-scan движке сжигает бюджет и не масштабируется.

Короткий ответ: Подбирайте хранилище отдачи под паттерн доступа: warehouse (Snowflake/BigQuery) под BI и аналитические сканы; низколатентный OLAP (ClickHouse/Druid) под интерактивные дашборды и аналитику в приложении; key-value под точечные lookups; а реверс-ETL толкает данные обратно в операционные системы (CRM и т.п.).

Подробно:

• Warehouse — колоночный, под сложные аналитические запросы и BI; латентность секунды, конкурентность ограничена. Не для user-facing запросов на тысячи RPS.
• Низколатентный OLAP — ClickHouse/Druid/Pinot: суб-секундные агрегаты при высокой конкурентности, для in-app аналитики и realtime-дашбордов.
• Key-value / кэш — Redis/DynamoDB под точечные чтения по ключу (профиль, фичи для ML) с латентностью в миллисекунды.
• Реверс-ETL — из warehouse обратно в SaaS/операционные системы (Hightouch/Census), чтобы данными пользовались продажи и маркетинг.

⚠️ Частая ошибка: сажать user-facing фичу с тысячами запросов в секунду напрямую на аналитический warehouse — он не про высокую конкурентность и низкую латентность; нужен OLAP или KV-слой.

Короткий ответ: Модерн дата стек — это набор управляемых модульных сервисов: коннекторы (Fivetran/Airbyte) → облачный warehouse/лейкхаус → трансформации (dbt) → BI, плюс реверс-ETL и оркестрация. Покупать готовое стоит ради скорости, кастомить — когда объём/специфика делают вендора слишком дорогим или невозможным.

Подробно:

1. Слои стека — extract-load (Fivetran/Airbyte), storage (Snowflake/BigQuery/лейкхаус), transform (dbt), BI (Looker/Metabase), оркестрация (Airflow/Dagster), реверс-ETL.
2. Buy — быстрый time-to-value, готовые коннекторы, меньше команды на поддержку; минус — стоимость растёт с объёмом, меньше контроля.
3. Build — под большие объёмы/нестандартные источники и жёсткие требования; минус — нужна команда, дольше, вы владеете эксплуатацией.
4. Практика — на старте покупать (managed ELT + warehouse + dbt), кастомить точечно узкие места (например, свой ingest под экстремальный кликстрим), не строить всё с нуля.

⚠️ Частая ошибка: строить собственные коннекторы и оркестрацию «чтобы сэкономить», пока объёмы малы — на старте managed-стек почти всегда дешевле по совокупной стоимости владения, чем содержать команду на поддержку самописного.