Big Data на собеседовании (FAANG)

Data Engineer в Meta получает 300K+ в год. Но на финальном интервью 60% кандидатов срезаются не на знании Spark или Kafka - а на system design: не могут объяснить почему выбрали именно этот инструмент и какие trade-offs приняли.

• **Google** использует Dataflow (Apache Beam) для обработки 20+ экзабайт в день - на интервью спрашивают именно про unified batch/streaming модель Beam и когда она оправдана
• **Meta** обрабатывает 1+ триллион событий в сутки через Scribe (Kafka-like) + Spark. Вопрос на интервью: как обеспечить exactly-once при такой нагрузке
• **Airbnb** опубликовала блог о переходе с Lambda на Kappa архитектуру - реальный кейс про то как избавились от двойной логики в batch и stream и что потеряли в процессе

Дизайн пайплайна данных

Вопрос "Спроектируй пайплайн для X" - самый частый на Data Engineer System Design. Интервьюер оценивает не столько итоговую схему, сколько процесс мышления: как уточняются требования, как выбирается инструментарий, как обосновываются компромиссы.

Структура ответа на design question: 1) уточнить scale и SLA, 2) нарисовать high-level схему (ingestion - processing - serving), 3) выбрать инструменты с обоснованием, 4) назвать bottleneck и как его mitigation.

Uber строил именно такую систему для подсчёта активных водителей и пассажиров. В 2019 они перешли с Kafka Streams на Apache Flink из-за необходимости сложных stateful операций: join потоков событий с историческими данными из Hive.

• **Lambda Architecture** (batch + speed layer) - Airbnb использовала до 2020, потом перешла на Kappa
• **Kappa Architecture** (только streaming) - Kafka + Flink как single source of truth
• **Medallion** (Bronze/Silver/Gold) - Delta Lake паттерн, Databricks推广ил в 2021
• **Data Mesh** - federated ownership, Zalando и Netflix переходят с 2022

Оптимизация медленных запросов

Вопросы об оптимизации запросов проверяют понимание того, как движок выполняет запрос под капотом. Типичная задача: "Запрос в Spark занимает 3 часа, как ускорить?" Системный подход - важнее знания конкретных флагов.

Алгоритм диагностики медленного запроса: 1) посмотреть Spark UI - stages, tasks, shuffle read/write, 2) найти данные skew (один executor обрабатывает 90% данных), 3) посмотреть на join стратегию (Sort-Merge vs Broadcast), 4) проверить partition count и размер файлов.

Netflix в 2021 опубликовал кейс: запрос ранжирования контента для 220M пользователей занимал 8 часов. После обнаружения skew на NULL user_id (гости без регистрации) и применения salting - время сократилось до 40 минут. Ключевое - skew не был виден в среднем времени task, только в max task duration в Spark UI.

• **Partition pruning** - WHERE по partition column сокращает scan в 10-100x
• **Predicate pushdown** - фильтрация до JOIN, а не после (Catalyst оптимизатор делает автоматически)
• **Columnar formats** - Parquet/ORC читают только нужные колонки (vs row-based CSV)
• **Z-ordering** - Delta Lake кластеризует данные по нескольким полям, ускоряет range queries
• **Materialized views** - Databricks и Snowflake поддерживают incremental refresh

Отладка инцидентов в production

Вопросы об отладке проверяют системное мышление под давлением. "Дашборд показывает нулевые метрики с 3:00 утра, что делаешь?" Ответ должен быть структурированным: изоляция - гипотезы - проверка - mitigation - root cause.

Типичные паттерны инцидентов в Big Data: 1) schema drift - upstream добавил обязательное поле, 2) late data - события приходят с задержкой и не попадают в window, 3) cascading failure - один DAG занял весь YARN cluster, 4) silent corruption - данные есть, но неверные (дубли от retry без idempotency).

Stripe в постмортеме 2022 описывал инцидент с "тихой" потерей 0.3% транзакций: pipeline продолжал работать, метрики выглядели нормально, но конкретный merchant_category_code не обрабатывался из-за edge case в парсере. Обнаружили только через reconciliation с банковскими выписками через 2 недели. Решение: automated reconciliation job ежечасно сравнивает агрегаты из двух независимых источников.

Обоснование архитектурных компромиссов

Staff-уровень отличается от Senior именно умением обосновывать tradeoffs числами и контекстом. Не "Kafka лучше RabbitMQ", а "Kafka дает нам retention и replay за счёт disk I/O и операционной сложности - это оправдано при 500K eps и нужде в event sourcing".

• **Batch vs Streaming**: batch проще и дешевле, streaming даёт свежесть - выбор зависит от бизнес-SLA, не от технических предпочтений
• **Managed vs Self-hosted**: Databricks/Snowflake стоят 3-5x дороже EC2, но экономят 2+ инженеров - считать TCO, не unit cost
• **Consistency vs Availability**: в распределённых системах нельзя иметь оба (CAP теорема) - Analytics системы обычно выбирают availability + eventual consistency
• **Storage cost vs Query performance**: больше партиций = быстрее queries, но больше файлов = медленнее listing - Iceberg/Delta решают через metadata layers
• **Normalization vs Denormalization**: в OLTP нормализуем для consistency, в OLAP денормализуем в wide tables для скорости агрегаций

Snowflake vs Databricks - один из самых популярных вопросов на Staff интервью в 2024. Правильный ответ: Snowflake лучше для SQL-heavy workloads, BI и data sharing между организациями. Databricks лучше для ML, streaming и code-first teams. Многие FAANG компании используют оба: Snowflake для бизнес-аналитики, Databricks для feature engineering и ML pipelines.

Ключевые идеи

• **Design-вопросы**: начинать с уточнения scale и SLA, рисовать ingestion-processing-serving схему, обосновывать инструменты через конкретные характеристики
• **Оптимизация**: диагностировать через Spark UI (stages, tasks, shuffle), искать skew через max vs median task duration, решать через broadcast hint, salting или AQE
• **Инциденты**: структура ответа - изоляция, гипотезы, проверка, mitigation, root cause, prevention. Silent failures опаснее явных - добавлять reconciliation
• **Tradeoffs**: Staff-уровень говорит числами и контекстом (TCO, SLA, team constraints), не общими словами про "популярность" или "зрелость"

Связанные темы

Этот урок завершает курс Big Data, объединяя все предыдущие темы в контексте реальных интервью:

• Архитектура Data Platform — Основа для design-вопросов на интервью: Lakehouse, Medallion, Data Mesh
• Data Quality и Observability — Инструменты для prevention раздела после инцидента: Great Expectations, data contracts
• Apache Spark оптимизация — Детальный разбор механик оптимизации: catalyst, tungsten, AQE

Вопросы для размышления

• Если бы нужно было спроектировать пайплайн для подсчёта retention пользователей за 30 дней с задержкой 1 час - какие инструменты выбрать и почему именно они?
• Как объяснить non-technical менеджеру почему "просто добавить индекс" не решает проблему медленного запроса в распределённой системе?
• Какой последний инцидент с данными наиболее запомнился - что пошло не так и что изменилось в архитектуре после него?

Связанные уроки

• sd-01-intro