Вопросы на собеседовании: Дата-инженер
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.
Смотреть пример резюме: Дата-инженер →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Я бы использовал единый вход через Kafka и отдельные контуры Flink и Spark поверх lakehouse на Iceberg.
- Kafka получает 384 партиции примерно по 6 МБ/с каждая, ключ account_id, хранение 24 часа и replication factor 3 между зонами.
- Flink каждые 30 секунд коммитит dashboard-таблицы в Iceberg, а Spark компактирует и пересобирает сертифицированные дневные факты до 06:00 UTC.
- Сырые Parquet-данные остаются неизменными 90 дней, поэтому оба контура можно переиграть без второго контракта ingestion.
Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат разделить классы задержки, сохранив единый источник истины с возможностью повторной обработки.
Я бы построил Spark-джобу с отсечением партиций и рассчитал кластер по измеренной пропускной способности, а не по привычному числу узлов.
- Для окна в 2 часа нужно не менее 2,8 ГБ/с полезного чтения, поэтому я бы нагрузочно проверил 5% данных и добавил 30% запаса.
- Манифесты Iceberg выбирают только дату обработки, а Spark пишет Parquet-файлы по 512 МБ с row group по 128 МБ, сокращая листинг и shuffle.
- Первый запуск использует 80 воркеров r7gd.4xlarge с dynamic allocation; 60% мощности можно взять на spot, потому что упавшие стадии повторяемы.
Зачем это спрашивают: Интервьюер оценивает расчёт мощности, физическую раскладку и конкретный компромисс по надёжности.
Я бы считал алерты во Flink и хранил данные в Kafka достаточно долго, чтобы replay был штатной операцией.
- Kafka использует device_id как ключ в 192 партициях и хранит 72 часа, покрывая 48-часовой replay и запас в 24 часа.
- Flink выдаёт предварительные алерты за 10 секунд, закрывает event-time окна по watermark 2 минуты и делает checkpoint на S3 каждые 30 секунд для восстановления быстрее 5 минут.
- Алерты идут в compacted Kafka topic с alert_id как ключом идемпотентности, а сырые события попадают в часовые партиции Iceberg.
Зачем это спрашивают: Интервьюер проверяет, спроектированы ли вместе низкая задержка, восстановление состояния и ограниченный replay.
Я бы разделял метаданные и хранение, но обеспечил изоляцию клиентов и в авторизации, и в вычислениях.
- Таблицы Iceberg партиционируются по event_date, а не tenant_id, и сортируются по tenant_id и event_time, чтобы не создать 200 деревьев мелких партиций.
- Строчные фильтры Lake Formation и отдельные IAM-роли ограничивают tenant_id при запросе, а каждый релиз содержит 20 негативных тестов доступа.
- Пять тяжёлых клиентов получают отдельные очереди Spark и лимит 40% конкурентной мощности на каждого, чтобы один клиент не исчерпал общий кластер.
Зачем это спрашивают: Интервьюер оценивает баланс физической эффективности, безопасности и защиты от шумного соседа.
Я бы сделал потоковый результат предварительным, а дневной batch назначил проверенным источником поверх тех же неизменных событий заказов.
- Flink считает 30-секундные операционные агрегаты из Kafka и помечает их как предварительные вместе с диапазоном исходных offset.
- Spark пересобирает дневной факт выручки из сырых событий Iceberg и CDC-корректировок, затем сверяет итог с платёжным реестром до $0,01.
- Оба результата используют одну SQL-логику метрик в макросах dbt, но для финансов сертифицируется только дневная таблица.
Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат сочетать быстрый результат с явно назначенным источником корректных данных.
Я бы стандартизировал извлечение через managed-сервис, а преобразование и хранение оставил в собственной платформе.
- Airbyte Cloud или Fivetran обслуживает 120 коннекторов, только если 30-дневный тест объёма укладывается в $30 000 с учётом исторических синхронизаций.
- Каждый источник без изменений попадает в Iceberg-таблицу source/date вместе с курсором коннектора, временем извлечения и сырым payload для replay.
- Airflow создаёт один параметризованный DAG на класс источников и ограничивает одновременные синхронизации числом 20, чтобы не перегрузить API и слоты warehouse.
Зачем это спрашивают: Интервьюер оценивает ограниченный ресурсами ingestion-дизайн, а не абстрактное мнение о покупке или собственной разработке.
Я бы один раз вычислял признаки по event time и публиковал версионированные online и offline представления.
- Flink обновляет online-ключи Redis или Feast в пределах SLA 2 секунды и записывает feature_name, версию и timestamp события с каждым значением.
- Те же определения признаков пишут append-only таблицы Iceberg с партицией event_date и бакетированием по entity_id для point-in-time join за 180 дней.
- Ежедневная Spark-джоба сравнивает 1 миллион сущностей и блокирует публикацию, если online и offline значения расходятся больше чем на 0,1%.
Зачем это спрашивают: Интервьюер проверяет корректность на выбранный момент времени и согласованность online и offline данных при заданных задержке и глубине истории.
Я бы хранил сырые и идентифицируемые данные внутри региона, а глобально реплицировал только разрешённые агрегаты.
- В каждом регионе свои Kafka, объектное хранилище, каталог Iceberg и KMS-ключи, а политики EU-бакета запрещают репликацию за пределы eu-west-1.
- Региональные Spark-джобы строят 15-минутные агрегаты без прямых идентификаторов и публикуют их через межрегиональные Kafka topics.
- Глобальный каталог Iceberg читает только агрегаты, а ежедневная проверка из 100 строк подтверждает отсутствие EU-идентификаторов за пределами региона.
Зачем это спрашивают: Интервьюер проверяет, является ли резидентность архитектурной границей, а не обещанием в документации.
Я бы унифицировал транспорт, а не бизнес-схемы, пропуская каждую CDC-запись через Kafka в сырые Iceberg-таблицы.
- Debezium запускает отдельный коннектор на каждую базу, а topics хранят 7 дней, чтобы минутные потребители и упавшие sink-джобы переигрывались независимо.
- Flink каждую минуту пишет в Iceberg исходный LSN, операцию и версию схемы, сохраняя удаления, а не скрывая их.
- Шестичасовые Spark-джобы читают snapshots Iceberg, а не базы, поэтому 40 production-систем исчезают из критического пути batch.
Зачем это спрашивают: Интервьюер оценивает, может ли единая основа ingestion обслужить два класса задержки без привязки к исходным базам.
Я бы рассчитал реплицируемые байты, пропускную способность партиций и запас на отказ до выбора числа брокеров.
- Входящий поток равен примерно 1,08 ГБ/с и 93 ТБ сырых данных в день, поэтому при replication factor 3 нужно около 280 ТБ до учёта лимита 70%.
- При 10 МБ/с на партицию я бы начал со 120 партиций, затем поднял до 180 для равномерной нагрузки при недоступности одного брокера.
- Двенадцать брокеров по 40 ТБ полезного места дают 480 ТБ, а нагрузочный тест должен подтвердить около 300 МБ/с на брокер во время rebalance.
Зачем это спрашивают: Интервьюер оценивает количественный расчёт мощности и партиционирование Kafka с учётом отказа.
Я бы партиционировал по дню и сортировал файлы по customer_id и event_time.
- Дневные партиции ограничивают 7-дневный запрос примерно 840 ТБ до дальнейшего отсечения и не создают отдельную партицию на перекошенного клиента.
- Скрытое партиционирование Iceberg и sort order по customer_id позволяют манифестам и статистике Parquet пропускать файлы без служебных колонок в запросах.
- Я бы целился в файлы по 1 ГБ и переписывал только партиции с долей мелких файлов выше 10%, обменивая стоимость compaction на предсказуемое чтение.
Зачем это спрашивают: Интервьюер проверяет, учитывает ли партиционирование одновременно форму запросов и сильный перекос ключей.
Я бы оптимизировал раскладку под column pruning и ограниченный блок чтения, а не под максимальный размер файла.
- Размер файла составляет от 512 МБ до 1 ГБ, а row group по 128 МБ удерживает распакованный рабочий набор заметно ниже 16 ГБ.
- По умолчанию я выберу ZSTD level 3, потому что он обычно сильнее Snappy сокращает хранение и чтение при приемлемой цене CPU для batch.
- Я бы сортировал по двум самым селективным фильтрам и проверил на 1 ТБ, что min/max статистика Parquet отсекает не менее 80% row groups.
Зачем это спрашивают: Интервьюер оценивает, связывает ли кандидат внутреннее устройство Parquet с памятью, CPU и стоимостью чтения.
Я бы предотвращал мелкие файлы на стороне writer и запускал ограниченный compaction как сервис таблиц.
- Flink накапливает в каждой партиции 256 МБ или 5 минут, что наступит раньше, вместо одного файла на task checkpoint.
- Iceberg rewrite_data_files каждый час объединяет файлы меньше 64 МБ до цели 512 МБ с lookback 30 минут.
- Сервис использует не более 20% кластера и подаёт алерт при 1 000 файлов в партиции, сохраняя p95 запросов без голодания ingestion.
Зачем это спрашивают: Интервьюер проверяет, встроено ли управление мелкими файлами в штатную эксплуатацию с явными лимитами ресурсов.
Я бы использовал схему звезды с фактом строк заказов и согласованными измерениями, а широкие пути материализовал только под доказанные запросы.
- Факт хранит числовые меры и surrogate keys, партиционируется по order_date и кластеризуется по customer_key на всю 6-летнюю историю.
- Двести атрибутов остаются в измерениях product, customer и channel, поэтому исправление названия не переписывает 10 миллиардов строк факта.
- Для 30 дашбордов dbt строит дневные агрегаты и один избирательный широкий mart с freshness-тестами в 06:15 UTC.
Зачем это спрашивают: Интервьюер оценивает баланс семантической согласованности, цены обновлений и производительности дашбордов.
Я бы преобразовал упорядоченные CDC-изменения в непересекающиеся интервалы действия и обновлял только затронутые ключи.
- Iceberg-таблица использует bucket(256, customer_id) и хранит customer_key, valid_from, valid_to, is_current, source_lsn и hash отслеживаемых атрибутов.
- Стадия Flink или Spark сортирует 20 миллионов дневных изменений по customer_id и source_lsn и отбрасывает обновления без изменения hash.
- Iceberg MERGE переписывает бакеты изменённых клиентов, а тест запрещает пересечение интервалов и больше одной текущей строки на ключ.
Зачем это спрашивают: Интервьюер проверяет временную корректность, порядок CDC и write amplification на крупном измерении.
Я бы партиционировал по event_date, кластеризовал по account_id и ввёл лимиты чтения на границе запросов.
- require_partition_filter блокирует полное чтение, а авторизованные dashboard views по умолчанию ограничены 30 днями и 180 ТБ до кластеризации.
- Кластеризация по account_id остаётся только если dry run показывает сокращение байтов не менее 50% для 20 главных production-запросов.
- Общие custom query quotas составляют 120 TiB в день, около $22 500 в месяц при $6,25 за TiB, оставляя 10% бюджета $25 000 на исключения.
Зачем это спрашивают: Интервьюер оценивает, привязаны ли физический дизайн и контроль затрат к измеренному поведению запросов.
Я бы выбрал Iceberg, потому что сочетание движков и запрет lock-in важнее удобства только для Spark.
- У Iceberg полноценные коннекторы Spark, Trino и Flink, поэтому все три движка могут коммитить через единый открытый каталог.
- До решения я бы проверил 10 типичных MERGE и scan нагрузок на 50 ТБ, поскольку зрелость коннекторов зависит от версии движка.
- Компромисс состоит в отказе от части оптимизаций Delta для Databricks, что приемлемо при обязательном 5-летнем multi-engine пути.
Зачем это спрашивают: Интервьюер проверяет выбор формата таблиц на основе заданных движков и организационных ограничений.
Я бы использовал эволюцию схемы по field ID и окно совместимости на два релиза.
- Iceberg сохраняет field ID при переименовании, поэтому readers по ID не требуют переписи 40 ТБ, но я всё равно проверю каждый движок на доступ по имени.
- Релиз 1 держит старые и новые views 14 дней и фиксирует, какие из 60 jobs ещё читают прежнее имя.
- Релиз 2 удаляет aliases только при нулевом использовании и атомарно переключает view в пределах 5-минутного лимита простоя.
Зачем это спрашивают: Интервьюер оценивает безопасную эволюцию схемы для разных потребителей без лишней переписи данных.
Я бы вывел начальный размер кластера из теста пропускной способности и сделал сокращение shuffle главным рычагом затрат.
- Цель равна 5,6 ГБ/с полезной обработки, поэтому я бы проверил выборку 1,5 ТБ и начал со 100 воркеров r7gd.4xlarge плюс 25% запаса.
- Adaptive Query Execution использует целевые партиции по 256 МБ, а частичная агрегация на map-side сокращает shuffle 30 ТБ до широкой стадии.
- При цене около $1,20 за worker-hour запуск 125 воркеров на 90 минут стоит примерно $225 до наценки сервиса, оставляя запас до $2 000 на повторы.
Зачем это спрашивают: Интервьюер проверяет расчёт throughput, знание выполнения Spark и проверку стоимости.
Я бы изолировал горячий ключ и применил к нему отдельную стратегию join вместо salting всех строк.
- Метрики Spark сначала подтверждают ключ с долей 35% и две отстающие партиции; оставшиеся 65% идут через обычный sort-merge join.
- Горячий клиент делится на 64 детерминированных salt-бакета, а его строка измерения размножается только 64 раза, а не вся таблица 600 ГБ.
- AQE skew splitting остаётся включённым с порогом 256 МБ, а 5% production-выборка должна показать p95 task time меньше 3 минут до полного запуска.
Зачем это спрашивают: Интервьюер оценивает точечную работу с перекосом при фиксированном времени вместо общего repartition.
Закрытые вопросы
- 21
Spark-пайплайн соединяет 8 ТБ событий со справочником 6 ГБ на executors с 16 ГБ памяти; решите, делать ли broadcast, и задайте ограничения.
joinsmemoryci-cd - 22
Обрабатывайте дневной инкремент факта 4 ТБ, если 8% событий опаздывают до 72 часов, а исправленные дашборды должны появляться за 30 минут.
concurrency - 23
Flink-джоба антифрода держит 15 ТБ keyed state, обязана делать checkpoint каждые 60 секунд и восстанавливаться за 10 минут; спроектируйте state и checkpointing.
design - 24
Соедините клики и покупки при 800 000 событий в секунду, если покупка может случиться через 6 часов после клика, а state Flink ограничен 8 ТБ.
joins - 25
Выберите Spark Structured Streaming или Flink для 300 000 событий в секунду, p99 меньше 3 секунд, keyed sessions по 6 часов и exactly-once записи в Iceberg.
sessionslatencystreaming - 26
Спроектируйте Airflow для 2 000 DAG и 100 000 task runs в день с failover scheduler быстрее 2 минут и p95 ожидания task в очереди меньше 30 секунд.
designdata-structuresairflow - 27
Выполните backfill 730 дневных партиций общим объёмом 400 ТБ за 5 дней, пока live-пайплайны сохраняют 70% Spark-пула на 1 000 cores.
partitioningbackfillci-cd - 28
Спроектируйте идемпотентный дневной пайплайн, который читает 2 ТБ, пишет 12 партиций и может повториться 3 раза после любой границы task.
partitioningidempotencydesign - 29
Airflow DAG должен обработать 50 000 клиентских файлов каждый час, но executor допускает только 2 000 параллельных tasks, а задержка scheduler должна быть меньше 20 секунд.
concurrencyairflow - 30
Пятьдесят producer DAG питают 120 consumer DAG, данные приходят с 02:00 до 05:00 UTC, а consumers должны стартовать не позже 5 минут после готовности.
health-checks - 31
Task Airflow вызывает billing API для 10 миллионов строк и может повториться 4 раза, но дублирующиеся списания запрещены.
resilienceapiairflow - 32
В Airflow есть 300 критичных tasks со сроком 07:00 и 20 000 некритичных tasks, но в пик 05:00 доступно только 5 000 worker slots; спроектируйте admission control.
schedulingdesignairflow - 33
Внедрите data contracts для 80 producing services и 300 consuming pipelines: несовместимые схемы блокируются до деплоя, а проверка занимает меньше 10 минут.
deploymentci-cdschema - 34
Спроектируйте контроль качества для 1 000 таблиц, где только 100 критичны для бизнеса, а бюджет validation-кластера ограничен 500 core-hours в день.
qualitydesigncoverage - 35
Таблица выручки должна быть свежей к 06:15 UTC в 99,9% дней и полной с отклонением не более 0,05%; определите SLA и путь enforcement.
- 36
Общий Kafka topic имеет 45 consumers на 6 языках; схемы меняются еженедельно, и ни один consumer не должен сломаться без предупреждения за 30 дней.
schemakafka - 37
Проверьте дневной факт выручки на 4 миллиарда строк по данным 3 платёжных процессоров с допуском $0,01 на транзакцию и бюджетом теста 20 минут.
transactionsvalidationconcurrency - 38
Проект dbt содержит 400 models, но проверка pull request должна занимать меньше 10 минут при 200 ТБ production-данных.
validationdbt - 39
Пайплайн принимает 2 миллиарда записей в день, до 0,2% могут не пройти validation; хорошие данные публикуются за 15 минут, плохие остаются доступными для replay 30 дней.
validationci-cd - 40
Захватывайте 20 000 PostgreSQL-транзакций в секунду из базы 12 ТБ в Iceberg с p95 lag меньше 60 секунд и без простоя источника.
databasetransactionspostgres - 41
Запустите CDC для PostgreSQL-базы 15 ТБ, пока запись продолжается со скоростью 5 ТБ в день, а retained WAL не может превышать 1 ТБ.
databasepostgres - 42
Реплицируйте 60 таблиц PostgreSQL в lakehouse на 5 лет, сохраняя удаления и 2 изменения схемы в неделю без переписи больше 1 ТБ за изменение.
postgresschemareplication - 43
Реплицируйте orders и order_items из PostgreSQL при 50 000 изменений строк в секунду и гарантируйте, что item не виден раньше order дольше 5 секунд.
postgresreplication - 44
Read replica питает аналитику при 30 000 writes в секунду; production требует replication lag меньше 20 секунд, а аналитика может использовать не больше 25% I/O реплики.
replication - 45
CDC-поток доставляет дубли после failover, но Iceberg-таблица текущего состояния на 6 миллиардов строк должна содержать ровно одну версию primary key за 2 минуты.
primary-keys - 46
События приходят со скоростью 600 000 в секунду: 95% за 2 минуты, 4,9% за 30 минут и 0,1% за 24 часа, но дашборды можно исправлять только 1 час.
- 47
Удаляйте дубли 1 миллиона событий в секунду по event_id, если они возможны 7 дней, а state Flink ограничен 12 ТБ.
queries - 48
Спроектируйте exactly-once обработку из Kafka через Flink в Iceberg для 400 000 событий в секунду с восстановлением за 8 минут и без дублей бизнес-ключей.
kafkadesignconcurrency - 49
Iceberg-таблица 1 ПБ обслуживает 2 000 запросов в день, но месячный счёт движка нужно снизить со $180 000 до $90 000, сохранив p95 меньше 12 секунд.
queries - 50
Платформа обрабатывает 300 ТБ в день: для 10% результат нужен за 1 минуту, для 90% за 6 часов, а годовые расходы compute ограничены $4 миллионами.
concurrency - 51
В 04:00 дневной Spark-пайплайн отстаёт на 3 часа от SLA свежести к 06:00 после роста входа с 8 до 13 ТБ; что вы делаете?
ci-cd - 52
Airflow DAG уже 70 минут ждёт одну из 240 часовых партиций источника, а SLA потребителя истекает через 20 минут; как вы реагируете?
partitioningairflow - 53
После релиза Spark-агрегация вместо обычных 95 минут прогнозируется на 6 часов и нарушит SLA на 4 часа; проведите по своим действиям?
aggregation - 54
Скорость ingestion из S3 внезапно падает с 9 до 2 ГБ/с, отставание достигает 2 часов, а каждую минуту приходит 18 000 новых файлов; что вы проверите и измените?
aws - 55
В полдень API вендора снижает квоту с 20 000 до 5 000 запросов в час, ставя под угрозу 4-часовой SLA загрузки для 60 клиентов; что вы делаете?
procurementapi - 56
В 05:20 модель dbt не укладывается в SLA к 06:00, потому что вышестоящая команда добавила 14 колонок и время выросло с 8 до 55 минут; как вы восстановитесь?
schemadbt - 57
Spark-джоба в Kubernetes перезапустила 38 экзекьюторов из-за OOM за 25 минут и пропустит 2-часовой SLA; что вы сделаете до увеличения памяти?
memorykubernetes - 58
Один клиент за ночь вырастает с 4% до 46% строк, и 12 Spark-задач работают ещё 90 минут после завершения остальных 3 000; как вы восстановитесь и предотвратите повтор?
- 59
Чтение 7 ТБ в Spark падает на 23 повреждённых Parquet-файлах после обработки 96%, до дедлайна 45 минут; что вы делаете?
estimationconcurrency - 60
Двадцать Flink writer создают 140 конфликтов коммита Iceberg за 10 минут, а свежесть уже на 35 минут хуже SLA в 15 минут; как вы стабилизируете систему?
- 61
В 09:00 checkout-дашборд прыгает на 18%, а проверка качества находит 42 миллиона дублей заказов за последние 6 часов; что вы делаете?
- 62
За 2 часа до закрытия месяца финансы находят на 7% меньше счетов, чем в биллинговой системе; как вы ограничите и исправите инцидент?
incidentssystem-design - 63
После деплоя dbt выручка завышена на 4,6% в 11 дашбордах руководства; что вы делаете в первые 30 минут?
deploymentdbt - 64
Доля null в customer_country растёт с 0,2% до 12% за час, но блокировка публикации задержит 40 дашбордов на 3 часа; какое решение вы примете?
- 65
Join со справочником превращает 900 миллионов фактов в 2,7 миллиарда и завышает 6 метрик в 3 раза; как вы отладите и откатите это?
monitoringrollbackjoins - 66
После перехода на летнее время почасовой спрос сдвинут на 2 часа для 9 миллионов европейских событий, а кадровые решения начинаются через 90 минут; что вы делаете?
- 67
Продуктовый дашборд ошибается на 9%, потому что customer dimension не обновлялся 36 часов, хотя все Airflow-задачи зелёные; как вы реагируете?
airflow - 68
CDC sink не применял удаления 14 часов, оставив 2,4 миллиона отменённых аккаунтов активными в аналитике; что вы делаете?
- 69
Статистическая проверка качества блокирует batch на 5 ТБ за 25 минут до SLA, но сдвиг распределения на 22% может быть реальной промоакцией; что вы делаете?
distributionsbatch - 70
Продажи считают дашборд заниженным на 12%, финансы считают его верным, а презентация совету директоров готовится через 3 часа; что вы выпускаете?
- 71
Backfill случайно перезаписал 180 миллионов валидных строк в 12 дневных партициях Iceberg; как вы их восстановите?
partitioningbackfill - 72
Retry дважды добавил backfill на 1,2 миллиарда строк, удвоив 45 дней событий клиентов; что вы делаете без перезаписи таблицы на 9 ПБ?
resiliencebackfill - 73
Backfill на 400 ТБ падает после 63% из-за исчезновения spot-мощности и должен закончиться за 36 часов без повтора готовой работы; что вы делаете?
capacitybackfill - 74
Вы обнаружили, что 90-дневный backfill использовал неверное налоговое правило и изменил 640 миллионов строк, потребляемых финансами; как вы его отмените?
backfill - 75
Backfill занимает 82% общего Spark-кластера и заставляет 17 production-пайплайнов нарушить свежесть на 50 минут; что вы делаете?
backfillci-cd - 76
Kafka consumer group отстаёт на 12 миллионов сообщений за 18 минут при стабильных 700 000 событий в секунду от producer; как вы диагностируете проблему?
kafkathroughput - 77
Kafka lag достигает 9 миллионов на 3 из 96 партиций, а остальные 93 остаются около нуля; что вы делаете при SLA алерта 20 минут?
partitioningkafkaalerting - 78
Checkpoint Flink растёт с 40 секунд до 7 минут, падает 6 раз и угрожает цели восстановления 10 минут; что вы делаете?
- 79
Consumer group делает 28 rebalance за 15 минут, throughput падает на 65%, а в очереди накапливается 4 миллиона событий; как вы стабилизируете систему?
throughputdata-structures - 80
Шторм повторов producer создаёт 6,5 миллиона дублей платёжных событий за 12 минут, а дашборды должны восстановиться за 30 минут; что вы делаете?
resilience - 81
После сбоя мобильного приложения 8% рекламных конверсий приходят на 5 часов позже, но дашборды кампаний допускают исправления только 2 часа; что вы делаете?
- 82
После failover CDC-обновления 14 миллионов заказов приходят не по порядку, и 3% строк текущего состояния откатываются на старые статусы; как вы их исправите?
- 83
Из-за ошибки схемы 2,2 миллиона событий попадают в dead-letter topic за 25 минут, а его 3-часовое хранение почти заполнено; что вы делаете?
retentionschema - 84
Producer событий меняет price из центов int в доллары string, ломая 17 consumer и создавая lag 5 миллионов сообщений; как вы восстановите сервис без простоя?
- 85
Счётчики источника показывают 1,8 миллиарда событий, но после сбоя broker в Kafka и lake есть 1,76 миллиарда; как вы расследуете пропавшие 40 миллионов?
incidentskafka - 86
Расходы Snowflake прыгают с $85 000 до $260 000 за 9 дней при росте числа запросов лишь на 12%; что вы сделаете за эту неделю?
queriessnowflake - 87
Новый дашборд BigQuery сканирует 900 ТБ в день и добавляет $5 600 ежедневных расходов на 1 200 просмотров; как вы исправите это за 24 часа?
estimationbigquery - 88
EMR Spark-пайплайн становится в 3,4 раза дороже после autoscaling с 60 до 240 воркеров, но ускоряется только на 8%; что вы измените?
scalingci-cd - 89
Хранилище Iceberg вырастает на 140 ТБ за неделю, хотя новых бизнес-данных лишь 18 ТБ; как безопасно остановить рост расходов?
- 90
Межрегиональный egress Kafka растёт с $12 000 до $74 000 в месяц после деплоя 6 consumer, а финансы требуют сократить его на 40% за 2 недели; что вы делаете?
kafkadeployment - 91
Переименование 4 колонок ломает 27 production-джоб, а на восстановление без окна деплоя потребителей есть 45 минут; что вы делаете?
schemadeployment - 92
order_id меняется с 32-битного на 64-битный, 0,4% новых значений переполняются в 9 consumer, а lag достигает 3 миллионов; как вы это исправите?
- 93
Protobuf producer делает поле обязательным, 11 старых consumer отклоняют 2,8 миллиона сообщений, а SLA инцидента равен 30 минутам; что вы делаете?
incidents - 94
Колонка dbt сохраняет имя, но меняет смысл с gross на net revenue, сдвигая 23 дашборда на 6%; релиз уже в продакшне; что вы делаете?
schemadbt - 95
Обновление Parquet writer меняет кодировку timestamp, и 8 из 35 Trino-джоб падают на 6 ТБ новых файлов; как вы восстановите чтение без простоя?
- 96
Во время 45-минутного инцидента свежести мидл-инженер хочет увеличить Spark со 100 до 400 воркеров, не проверив единственную зависшую задачу; как вы наставляете его в моменте?
mentoringproblem-solvingincidents - 97
Backfill джуниор-инженера создаёт 320 миллионов дублей за 2 часа до финансового дедлайна; как вы проводите ремонт и работаете с инженером?
soft-skillsestimationbackfill - 98
Продукт требует непроверенный 48-часовой backfill для запуска через 6 часов, но выборка 2% расходится с продакшном на 7%; что вы решаете?
backfill - 99
Дежурный инженер обработал 14 вызовов за 3 часа и пропустил второй сбой пайплайна, из-за которого данные устарели на 90 минут; что вы делаете?
on-callci-cd - 100
Дата-инженер вызвал 3 инцидента схемы за 6 недель у 22 потребителей несмотря на обычные code review; какой конкретный план наставничества вы примените?
mentoringcode-reviewincidents