В BigQuery факт событий в dbt получает 6 ТБ в день, хранит данные за 24 месяца и должен обновлять дашборд каждые 15 минут. Как бы вы спроектировали инкрементальную модель?

Сначала я сделал бы модель с учетом партиций и только потом оптимизировал SQL-выражения. - Разбил бы таблицу на партиции по event_date и кластеризовал по tenant_id и event_type, чтобы обычные запросы отсекали большую часть таблицы объемом 4 ПБ. - Использовал бы event_id как unique_key и merge в BigQuery с просмотром исходных данных за последние 72 часа для поздних событий. - Добавил бы incremental predicate, который ограничивает сопоставление в целевой таблице теми же тремя партициями по датам, а не сканирует всю историю. - Проверял бы уникальность event_id в каждой обработанной партиции и сравнивал дневное число строк с сырой таблицей перед публикацией.

В таблице заказов Snowflake 2 миллиарда строк, ежедневно добавляется 40 миллионов строк, а из Kafka до 14 дней приходят дублирующиеся обновления. Каким должен быть unique_key инкрементальной модели dbt и как обрабатывать дубли?

Я определил бы ключ из бизнес-гранулярности, а не из записи о доставке Kafka. - Задал бы unique_key как составной ключ из source_system и order_id, потому что order_id уникален только внутри одного источника. - Удалял бы дубли во входной порции через row_number по этому ключу с сортировкой по updated_at и смещению Kafka по убыванию. - Отклонял бы или помещал в карантин строки с null в компонентах ключа, потому что merge в Snowflake не сможет надежно сопоставить такие значения как один бизнес-ключ. - Через merge записывал бы строку-победителя и после каждого запуска проверял уникальность составного ключа в данных за 14-дневное окно.

Факт dbt в BigQuery занимает 18 ТБ, каждая дневная партиция около 600 ГБ, а источник заново публикует полные исправленные партиции за последние 2 дня. Вы выберете merge или insert_overwrite?

Я выбрал бы insert_overwrite, потому что источник является эталоном на уровне целой партиции. - Построил бы во временном отношении только две исправленные партиции event_date и атомарно заменил бы их. - Настроил бы стратегию BigQuery insert_overwrite в dbt с явным списком партиций, когда даты запуска известны. - Оставил бы merge для точечных исправлений отдельных строк, когда перезапись 1,2 ТБ дороже сопоставления небольшого набора изменений. - Проверил бы число строк и итоговую выручку для обеих дат до передачи замены нижележащим моделям.

В Amazon Redshift модель кликов dbt обрабатывает 4 миллиарда строк в месяц: 99,7% поступают в течение 48 часов, а оставшиеся 0,3% могут задержаться до 10 дней. Как настроить окно просмотра для инкрементальной обработки с SLA в 1 час?

Я оставил бы почасовой путь коротким, а длинный хвост обрабатывал бы отдельно по ограниченному расписанию. - При каждом почасовом запуске перечитывал бы 72 часа, что покрывает измеренное 48-часовое окно с запасом в один день. - Выполнял бы merge по click_id, чтобы повторное чтение тех же трех дней обновляло существующие клики, а не создавало дубли. - Раз в неделю запускал бы ограниченный бэкфилл за 10 дней для хвоста в 0,3%, с фильтром по event_date и разбивкой на дневные пакеты. - Еженедельно отслеживал бы перцентили задержки и расширял 72-часовое окно только тогда, когда 99,7-й перцентиль выйдет за его границу.

Пайплайн Databricks Delta записывает 80 миллионов платежных событий в час, а повторная попытка Airflow может заново воспроизвести любое 2-часовое окно. Как сделать инкрементальную модель dbt идемпотентной?

Я сделал бы так, чтобы повторная обработка приводила к тому же состоянию целевой таблицы, а не пытался бы запретить повторы. - Использовал бы payment_event_id как unique_key и Delta merge с ограничением по event_time на повторно обрабатываемое 2-часовое окно. - Удалял бы дубли пакета по payment_event_id, выбирая победителя детерминированно по source_sequence, а не по порядку загрузки. - Вычислял бы суммы, статусы и временные метки только из полей источника, чтобы время перезапуска не меняло сохраненные значения. - Записывал бы batch_start, batch_end, input_count и output_count в таблицу аудита и принимал повтор только после сверки этих счетчиков.

Модель dbt в Snowflake обрабатывает 12 ТБ телеметрии в день, а один дневной инкрементальный запуск занимает 100 минут при SLA в 90 минут. Как применить микробатчи dbt?

Я разделил бы работу по event_time, чтобы каждый пакет имел фиксированные границы сканирования и мог быть перезапущен независимо. - Настроил бы микробатчи dbt с event_time и batch_size в 1 час, получив примерно 500 ГБ на пакет. - Запускал бы параллельно до 6 часовых пакетов после замера конкурентной нагрузки на warehouse, а не все 24 сразу. - Установил бы lookback в 2 пакета, чтобы повторно обрабатывать предыдущие 2 часа, и выполнял merge по telemetry_id для поздних событий. - Сохранял бы статус пакетов, повторял только неуспешные часы и затем сравнивал сумму 24 почасовых счетчиков с итогом в слое загрузки.

В Databricks есть факт кликов объемом 25 ТБ с 90 миллиардами строк и измерение клиентов на 300 миллионов строк; аналитикам нужны дневные метрики кампаний менее чем за 10 секунд. Как бы вы смоделировали это в dbt?

Я сохранил бы атомарный факт для детализации, а дашборды обслуживал бы из меньшего агрегата с явно заданной гранулярностью. - Определил бы fct_clicks на уровне одной строки на click_id, а dim_customer на уровне одной строки на customer_id, с проверками связей на свежих партициях. - Инкрементально строил бы agg_campaign_day на уровне campaign_id, event_date и customer_segment, а не соединял 90 миллиардов строк во время запроса. - Разбил бы факт и агрегат на партиции по event_date, а факт кластеризовал бы по campaign_id и customer_id для отсечения данных. - Пересчитывал бы последние 3 дня агрегата и сверял клики и расходы с атомарным фактом перед публикацией.

Таблица фактов в BigQuery занимает 400 ТБ, ее дневные партиции имеют размер 500 ГБ, а изменение налогового правила требует пересчитать ровно предыдущие 90 дней. Как выполнить ограниченный бэкфилл dbt без полного обновления?

Я задал бы диапазон дат явно и заменял только затронутые партиции перезапускаемыми порциями. - Передавал бы backfill_start и backfill_end как переменные dbt и отклонял в логике модели любой диапазон длиннее 90 дней. - Обрабатывал бы по 7 дневных партиций за запуск через BigQuery insert_overwrite, чтобы каждая порция перезаписывала около 3,5 ТБ. - Сохранял бы завершенные диапазоны дат в таблице аудита и перезапускал только неуспешную порцию, поскольку каждая замена идемпотентна. - Сверял бы число строк, taxable_amount и tax_amount по каждой дате, а затем запускал обычную инкрементальную обработку начиная с 91-го дня.

Поток PostgreSQL Debezium загружает в Snowflake 5 миллионов изменений подписок в час, включая вставки, обновления и удаления, а таблица текущего состояния содержит 3 миллиарда строк. Как построить инкрементальную модель dbt?

Я моделировал бы одну текущую строку на subscription_id и явно сохранял состояние удаления. - Удалял бы дубли каждого пакета по subscription_id с сортировкой по PostgreSQL LSN по убыванию, чтобы побеждало последнее изменение базы данных. - Выполнял бы merge по subscription_id и для записей удаления сохранял deleted_at и is_deleted вместо неотслеживаемого физического удаления. - Ограничивал бы источник значениями LSN выше последней успешной контрольной точки с перекрытием в 1 час для повторной доставки. - Проверял бы уникальность subscription_id и для каждого пакета сравнивал с Debezium число операций вставки, обновления и удаления.

Кликстрим в BigQuery получает 14 ТБ в день, сессии закрываются после 30 минут бездействия, а события могут опаздывать на 36 часов. Как инкрементально построить факт сессий dbt без сканирования всей истории?

Я пересчитывал бы только пользователей, чьи недавние события могут изменить границу сессии. - Читал бы события за 48-часовое окно по event_time и собирал уникальные user_id, затронутые в этом окне. - Загружал бы предыдущее граничное событие этих пользователей, заново строил затронутые сессии и создавал детерминированный session_id из user_id и session_start. - Заменял бы только партиции event_date с перестроенными сессиями, жестко ограничив запуск максимум 3 дневными партициями. - Сверял бы число событий между перестроенными сессиями и источником, а события старше 48 часов направлял бы в ограниченную задачу исправления.

dbt snapshot в Snowflake отслеживает таблицу подписок на 4 миллиарда строк. Он запускается каждый час, но MERGE теперь сканирует терабайты и не укладывается в SLA 45 минут. Как бы вы изменили решение, не потеряв историю?

Я бы сохранил историю SCD, но перестал бы передавать все 4 миллиарда исходных строк в каждый запуск snapshot. - Собрал бы набор кандидатов из CDC-потока источника или из строк, чей timestamp загрузки больше сохраненного high-water mark, с запасом по времени для опоздавших записей. - Оставил бы dbt snapshot поверх этого набора и кластеризовал snapshot-таблицу по бизнес-ключу и dbt_valid_from, чтобы Snowflake отсекал лишние данные на целевой стороне MERGE. - Обрабатывал бы ограниченные микробатчи, например по 15 минут или 5 миллионов ключей, и сдвигал high-water mark только после успешного завершения батча snapshot. - Ежедневно сверял бы измененные партиции источника и отслеживал число кандидатов, добавленных версий, обновленных версий, время работы и объем сканирования.

Таблица клиентов на 80 миллионов строк в PostgreSQL поступает в dbt snapshot. Поле updated_at индексировано, но старая синхронизация иногда меняет status, не обновляя его, а неважные метаданные меняются каждые несколько минут. Вы выберете стратегию timestamp или check?

Я бы не доверял стратегии timestamp, пока updated_at не отражает каждое бизнес-изменение, историю которого нужно сохранить. - Сначала проверил бы контракт с командой источника и сопоставил неделю данных PostgreSQL WAL или аудита с бизнес-изменениями, при которых updated_at не поменялся. - Если updated_at можно исправить и сделать монотонным, выбрал бы timestamp, потому что индексированное поле дает дешевую инкрементальную фильтрацию при таком объеме. - До исправления использовал бы check с явным списком полей, например status, plan_id, owner_id и billing_country, исключив шумные метаданные вместо check_cols: all. - Добавил бы поток изменений на стороне источника или watermark загрузки, чтобы dbt хешировал только строки-кандидаты, и тестировал бы, что выбранные изменения из WAL создают новую версию snapshot.

Snapshot аккаунтов Salesforce в BigQuery содержит 600 миллионов версий, но коннектор не передает события удаления. По требованиям комплаенса удаленные аккаунты нужно помечать в течение 24 часов. Как бы вы фиксировали hard delete?

Я бы определял удаления по проверенному полному набору ключей, потому что отсутствие строки в инкрементальном батче ничего не доказывает. - Ежедневно загружал бы в BigQuery полный набор ID активных аккаунтов Salesforce с партиционированием по дате выгрузки и отклонял его при падении полноты ниже согласованного порога. - Запускал бы отдельный ежедневный dbt snapshot по этому полному текущему набору с hard_deletes в режиме new_record, чтобы пропавшие ключи закрывали активные версии и получали явную запись удаления. - Сохранял бы предыдущие версии с dbt_valid_from и dbt_valid_to и публиковал dbt_is_deleted, чтобы потребители отличали удаление от изменения атрибутов. - До публикации сверял бы число активных ключей, найденных удалений и возраст выгрузки, измеряя требование 24 часов от успешной выгрузки источника.

В Snowflake SCD2-измерение клиентов на 900 миллионов строк получает исправления CRM задним числом, иногда с опозданием на шесть месяцев. Аналитики находят пересекающиеся версии и две текущие строки для одного клиента. Как бы вы исправили модель и не допустили повторения?

Я бы перестроил временные линии затронутых клиентов из упорядоченных событий изменений, а не исправлял отдельные даты окончания. - Для каждого затронутого бизнес-ключа удалил бы дубли событий с детерминированным разрешением совпадений по source_updated_at, ingestion_sequence и event_id. - Рассчитал бы valid_from из времени фактического действия изменения, а valid_to через LEAD(valid_from), используя полуоткрытый интервал с включенным valid_from и исключенным valid_to. - Заменил бы все версии только для затронутых ключей в одной транзакции Snowflake, чтобы читатели не увидели частично исправленную временную линию. - Добавил бы dbt-тесты на одну текущую строку для ключа, отсутствие пересечений интервалов, valid_to больше valid_from и уникальность ключа версии измерения.

Kafka доставляет 25 миллионов фактов покупок в день в Databricks, но до 3 процентов приходят раньше соответствующего события измерения клиента, а некоторые изменения измерения опаздывают на два дня. Как сохранить доступность фактов и историческую корректность?

Я бы сразу загружал факты с контролируемым неразрешенным ключом, а после прихода измерения пересчитывал только затронутые факты. - Сохранял бы бизнес-ключ клиента и event_time в промежуточной Delta-таблице фактов, назначая surrogate key 0 неразрешенным клиентам вместо удаления строки или подбора сомнительного соответствия. - Вел бы таблицу повторных попыток по бизнес-ключу клиента и затронутым партициям даты события, затем искал бы версию SCD2, действовавшую в event_time факта. - Через Databricks MERGE обновлял бы только неразрешенные или новые затронутые строки фактов, сохраняя исходное время события и метаданные загрузки. - Отслеживал бы число и возраст неразрешенных фактов по источникам, предупреждал до нарушения двухдневного ожидания и помещал в карантин факты, которые не разрешились за установленный срок.

Маркетплейс обрабатывает 20 миллионов заказов в день в BigQuery. В заказе может быть несколько товаров, одна стоимость доставки, купоны уровня заказа и частичные возвраты. Какую гранулярность вы выберете для основного факта продаж и как не допустите расхождения итогов?

Я бы зафиксировал гранулярность основного факта продаж как одну строку на order_item_id, а суммы моделировал бы на том уровне, где они возникают. - Хранил бы количество товара, валовую сумму товара и его налог в факте товарной позиции, используя order_id как вырожденное измерение для группировки. - Хранил бы доставку, купоны и платежи в фактах уровня заказа, если бизнес не утвердил детерминированное распределение, например пропорционально чистой стоимости товаров. - Моделировал бы возвраты с одной строкой на refund_line_id, потому что один товар можно возвращать несколько раз, и агрегировал бы их до соединения с уровнем товарной позиции. - Добавил бы dbt-тест на уникальность order_item_id и сверку суммы товарных и заказных фактов с ежедневными контрольными итогами платежного провайдера.

Looker Explore соединяет 120 миллионов заказов с order_items и payments в BigQuery. В заказе в среднем 4 товара и 1,5 платежной записи, а выручка получается примерно в 6 раз выше. Как бы вы нашли и устранили fanout?

Я бы сначала доказал мультипликативное соединение, а затем привел каждую присоединяемую метрику к гранулярности запроса. - Сравнил бы число строк и SUM(order_revenue) после каждого JOIN и посчитал дочерние строки на заказ, чтобы показать умножение 4 на 1,5. - Агрегировал бы order_items до одной строки на заказ и payments до одной строки на заказ в отдельных моделях dbt до соединения любого результата с orders. - В LookML указал бы реальные relationships и primary keys, но не полагался бы на symmetric aggregates как способ скрыть неверную гранулярность SQL. - Добавил бы тесты гранулярности для каждой агрегированной модели и сверку выручки Explore с доверенным итогом уровня заказа.

У ритейлера есть 30 миллионов заказов на доставку с этапами, которые меняются в течение 45 дней, а также остатки для 8 000 магазинов и 60 000 SKU. Когда в Snowflake вы примените accumulating snapshot, а когда periodic snapshot?

Я бы использовал два факта, потому что процессы отвечают на разные вопросы и обновляются по-разному. - Для accumulating snapshot сделал бы одну строку на fulfillment_order_id с полями ordered_at, packed_at, shipped_at, delivered_at и current status, обновляя строку по мере прохождения этапов. - Рассчитывал бы длительность циклов по этим полям этапов, а исходный факт событий хранил бы отдельно, если аналитикам нужны все переходы или исправления. - Для periodic snapshot сделал бы одну строку на store_id, sku_id и snapshot_date с ежедневными значениями on-hand, reserved и available inventory, даже если ничего не изменилось. - Настроил бы кластеризацию и срок хранения под способ чтения каждой таблицы, а также проверял уникальность уровня заказа для accumulating fact и уровня магазин-SKU-дата для periodic fact.

Проект dbt в BigQuery должен перестроить SCD2-измерение товаров на 700 миллионов строк в другом окружении. Текущая модель использует автоинкрементный ID, поэтому после перестроения меняются все внешние ключи фактов. Как бы вы спроектировали surrogate keys?

Я бы заменил идентификаторы, зависящие от sequence, на детерминированные хеши и разделил идентичность товара и его исторической версии. - Создал бы постоянный ключ товара, хешируя каноническое представление исходной системы и бизнес-ключа товара через dbt_utils.generate_surrogate_key. - Создал бы ключ версии из постоянного ключа товара, valid_from и стабильного ID исходного события, чтобы две версии SCD2 не получили одинаковый ключ. - Нормализовал бы типы, часовые пояса, пробелы, регистр и обработку null до хеширования и не объединял бы исходные поля без разделителей или маркеров null. - Проверял бы уникальность и отсутствие null, сохранял естественные ключи для отладки и сравнивал выборку ключей между production и перестроенным окружением.

Нужно точно воспроизвести витрину выручки за 12 месяцев объемом 18 ТБ в Spark и dbt после изменения бизнес-логики. Сырые события лежат в Apache Iceberg, опоздавшие файлы могут приходить 14 дней, а события Kafka иногда имеют одинаковое время события. Что обеспечит детерминированное перестроение?

Я бы зафиксировал и состояние входных данных, и версию преобразований до пересчета любой партиции. - Записал бы Apache Iceberg snapshot ID для каждой исходной таблицы и явно читал эти snapshots, чтобы файлы, пришедшие во время запуска, не меняли набор входных данных. - Запускал бы проект dbt с фиксированного Git SHA, закрепленными версиями пакетов, настройками хранилища, часовым поясом, версией валютных курсов и другими внешними справочниками. - Удалял бы дубли с полным порядком по event_time, Kafka partition, offset и event_id и не использовал бы недетерминированные функции или выбор первого значения без сортировки. - Идемпотентно записывал бы каждый месяц во временную таблицу, сверял число строк и денежные контрольные суммы с манифестом запуска, а затем атомарно заменял целевые партиции.

Вопросы на собеседовании: Analytics Engineer / Инженер аналитики

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.

Смотреть пример резюме: Analytics Engineer / Инженер аналитики →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

bigquerydesigndbt

Сначала я сделал бы модель с учетом партиций и только потом оптимизировал SQL-выражения.

Разбил бы таблицу на партиции по event_date и кластеризовал по tenant_id и event_type, чтобы обычные запросы отсекали большую часть таблицы объемом 4 ПБ.
Использовал бы event_id как unique_key и merge в BigQuery с просмотром исходных данных за последние 72 часа для поздних событий.
Добавил бы incremental predicate, который ограничивает сопоставление в целевой таблице теми же тремя партициями по датам, а не сканирует всю историю.
Проверял бы уникальность event_id в каждой обработанной партиции и сравнивал дневное число строк с сырой таблицей перед публикацией.

Зачем это спрашивают: Такой дизайн ограничивает сканирование источника и целевой таблицы, сохраняя исправления для недавно поступивших событий.

snowflakekafkadbt

Я определил бы ключ из бизнес-гранулярности, а не из записи о доставке Kafka.

Задал бы unique_key как составной ключ из source_system и order_id, потому что order_id уникален только внутри одного источника.
Удалял бы дубли во входной порции через row_number по этому ключу с сортировкой по updated_at и смещению Kafka по убыванию.
Отклонял бы или помещал в карантин строки с null в компонентах ключа, потому что merge в Snowflake не сможет надежно сопоставить такие значения как один бизнес-ключ.
Через merge записывал бы строку-победителя и после каждого запуска проверял уникальность составного ключа в данных за 14-дневное окно.

Зачем это спрашивают: Стабильный бизнес-ключ и детерминированное удаление дублей сводят повторные доставки Kafka к одной строке заказа.

partitioningbigquerydbt

Я выбрал бы insert_overwrite, потому что источник является эталоном на уровне целой партиции.

Построил бы во временном отношении только две исправленные партиции event_date и атомарно заменил бы их.
Настроил бы стратегию BigQuery insert_overwrite в dbt с явным списком партиций, когда даты запуска известны.
Оставил бы merge для точечных исправлений отдельных строк, когда перезапись 1,2 ТБ дороже сопоставления небольшого набора изменений.
Проверил бы число строк и итоговую выручку для обеих дат до передачи замены нижележащим моделям.

Зачем это спрашивают: Замена двух полных партиций исключает дорогое сопоставление ключей и точно повторяет контракт исправлений источника.

redshiftconcurrencydbt

Я оставил бы почасовой путь коротким, а длинный хвост обрабатывал бы отдельно по ограниченному расписанию.

При каждом почасовом запуске перечитывал бы 72 часа, что покрывает измеренное 48-часовое окно с запасом в один день.
Выполнял бы merge по click_id, чтобы повторное чтение тех же трех дней обновляло существующие клики, а не создавало дубли.
Раз в неделю запускал бы ограниченный бэкфилл за 10 дней для хвоста в 0,3%, с фильтром по event_date и разбивкой на дневные пакеты.
Еженедельно отслеживал бы перцентили задержки и расширял 72-часовое окно только тогда, когда 99,7-й перцентиль выйдет за его границу.

Зачем это спрашивают: Разделение основного окна поступления и редкого длинного хвоста защищает почасовой SLA и не теряет поздние клики.

dbtairflowci-cd

Я сделал бы так, чтобы повторная обработка приводила к тому же состоянию целевой таблицы, а не пытался бы запретить повторы.

Использовал бы payment_event_id как unique_key и Delta merge с ограничением по event_time на повторно обрабатываемое 2-часовое окно.
Удалял бы дубли пакета по payment_event_id, выбирая победителя детерминированно по source_sequence, а не по порядку загрузки.
Вычислял бы суммы, статусы и временные метки только из полей источника, чтобы время перезапуска не меняло сохраненные значения.
Записывал бы batch_start, batch_end, input_count и output_count в таблицу аудита и принимал повтор только после сверки этих счетчиков.

Зачем это спрашивают: Стабильные ключи, детерминированные победители и вычисления заставляют повторную обработку сходиться к исходному результату.

snowflakeconcurrencydbt

Я разделил бы работу по event_time, чтобы каждый пакет имел фиксированные границы сканирования и мог быть перезапущен независимо.

Настроил бы микробатчи dbt с event_time и batch_size в 1 час, получив примерно 500 ГБ на пакет.
Запускал бы параллельно до 6 часовых пакетов после замера конкурентной нагрузки на warehouse, а не все 24 сразу.
Установил бы lookback в 2 пакета, чтобы повторно обрабатывать предыдущие 2 часа, и выполнял merge по telemetry_id для поздних событий.
Сохранял бы статус пакетов, повторял только неуспешные часы и затем сравнивал сумму 24 почасовых счетчиков с итогом в слое загрузки.

Зачем это спрашивают: Часовые микробатчи ограничивают каждый запрос, позволяют управлять параллельностью и снижают стоимость повторной обработки ошибок.

monitoringdbt

Я сохранил бы атомарный факт для детализации, а дашборды обслуживал бы из меньшего агрегата с явно заданной гранулярностью.

Определил бы fct_clicks на уровне одной строки на click_id, а dim_customer на уровне одной строки на customer_id, с проверками связей на свежих партициях.
Инкрементально строил бы agg_campaign_day на уровне campaign_id, event_date и customer_segment, а не соединял 90 миллиардов строк во время запроса.
Разбил бы факт и агрегат на партиции по event_date, а факт кластеризовал бы по campaign_id и customer_id для отсечения данных.
Пересчитывал бы последние 3 дня агрегата и сверял клики и расходы с атомарным фактом перед публикацией.

Зачем это спрашивают: Проверенный атомарный слой и узкий дневной агрегат сохраняют детализацию и укладываются в целевое время дашборда.

partitioningmodelingbigquery

Я задал бы диапазон дат явно и заменял только затронутые партиции перезапускаемыми порциями.

Передавал бы backfill_start и backfill_end как переменные dbt и отклонял в логике модели любой диапазон длиннее 90 дней.
Обрабатывал бы по 7 дневных партиций за запуск через BigQuery insert_overwrite, чтобы каждая порция перезаписывала около 3,5 ТБ.
Сохранял бы завершенные диапазоны дат в таблице аудита и перезапускал только неуспешную порцию, поскольку каждая замена идемпотентна.
Сверял бы число строк, taxable_amount и tax_amount по каждой дате, а затем запускал обычную инкрементальную обработку начиная с 91-го дня.

Зачем это спрашивают: Явные границы и замена партиций ограничивают стоимость сканирования и позволяют безопасно продолжить с последней завершенной порции.

postgressnowflakedbt

Я моделировал бы одну текущую строку на subscription_id и явно сохранял состояние удаления.

Удалял бы дубли каждого пакета по subscription_id с сортировкой по PostgreSQL LSN по убыванию, чтобы побеждало последнее изменение базы данных.
Выполнял бы merge по subscription_id и для записей удаления сохранял deleted_at и is_deleted вместо неотслеживаемого физического удаления.
Ограничивал бы источник значениями LSN выше последней успешной контрольной точки с перекрытием в 1 час для повторной доставки.
Проверял бы уникальность subscription_id и для каждого пакета сравнивал с Debezium число операций вставки, обновления и удаления.

Зачем это спрашивают: Сортировка по позиции в журнале базы данных дает детерминированное текущее состояние при дублирующихся и пришедших не по порядку изменениях.

bigquerysessionsdbt

Я пересчитывал бы только пользователей, чьи недавние события могут изменить границу сессии.

Читал бы события за 48-часовое окно по event_time и собирал уникальные user_id, затронутые в этом окне.
Загружал бы предыдущее граничное событие этих пользователей, заново строил затронутые сессии и создавал детерминированный session_id из user_id и session_start.
Заменял бы только партиции event_date с перестроенными сессиями, жестко ограничив запуск максимум 3 дневными партициями.
Сверял бы число событий между перестроенными сессиями и источником, а события старше 48 часов направлял бы в ограниченную задачу исправления.

Зачем это спрашивают: Пересчет по затронутым пользователям учитывает границы сессий между окнами и ограничивает обычное сканирование свежими партициями.

snowflakesnapshotdbt

Я бы сохранил историю SCD, но перестал бы передавать все 4 миллиарда исходных строк в каждый запуск snapshot.

Собрал бы набор кандидатов из CDC-потока источника или из строк, чей timestamp загрузки больше сохраненного high-water mark, с запасом по времени для опоздавших записей.
Оставил бы dbt snapshot поверх этого набора и кластеризовал snapshot-таблицу по бизнес-ключу и dbt_valid_from, чтобы Snowflake отсекал лишние данные на целевой стороне MERGE.
Обрабатывал бы ограниченные микробатчи, например по 15 минут или 5 миллионов ключей, и сдвигал high-water mark только после успешного завершения батча snapshot.
Ежедневно сверял бы измененные партиции источника и отслеживал число кандидатов, добавленных версий, обновленных версий, время работы и объем сканирования.

Зачем это спрашивают: Так история версий сохраняется, а объем часовой обработки зависит от числа измененных ключей, а не от размера всей таблицы.

indexespostgressnapshot

Я бы не доверял стратегии timestamp, пока updated_at не отражает каждое бизнес-изменение, историю которого нужно сохранить.

Сначала проверил бы контракт с командой источника и сопоставил неделю данных PostgreSQL WAL или аудита с бизнес-изменениями, при которых updated_at не поменялся.
Если updated_at можно исправить и сделать монотонным, выбрал бы timestamp, потому что индексированное поле дает дешевую инкрементальную фильтрацию при таком объеме.
До исправления использовал бы check с явным списком полей, например status, plan_id, owner_id и billing_country, исключив шумные метаданные вместо check_cols: all.
Добавил бы поток изменений на стороне источника или watermark загрузки, чтобы dbt хешировал только строки-кандидаты, и тестировал бы, что выбранные изменения из WAL создают новую версию snapshot.

Зачем это спрашивают: Выбор сначала зависит от корректности фиксации изменений и только потом от стоимости сканирования.

soft-deletebigquerysnapshot

Я бы определял удаления по проверенному полному набору ключей, потому что отсутствие строки в инкрементальном батче ничего не доказывает.

Ежедневно загружал бы в BigQuery полный набор ID активных аккаунтов Salesforce с партиционированием по дате выгрузки и отклонял его при падении полноты ниже согласованного порога.
Запускал бы отдельный ежедневный dbt snapshot по этому полному текущему набору с hard_deletes в режиме new_record, чтобы пропавшие ключи закрывали активные версии и получали явную запись удаления.
Сохранял бы предыдущие версии с dbt_valid_from и dbt_valid_to и публиковал dbt_is_deleted, чтобы потребители отличали удаление от изменения атрибутов.
До публикации сверял бы число активных ключей, найденных удалений и возраст выгрузки, измеряя требование 24 часов от успешной выгрузки источника.

Зачем это спрашивают: Проверенная сверка полного набора ключей отличает настоящее удаление от неполной загрузки коннектора.

snowflake

Я бы перестроил временные линии затронутых клиентов из упорядоченных событий изменений, а не исправлял отдельные даты окончания.

Для каждого затронутого бизнес-ключа удалил бы дубли событий с детерминированным разрешением совпадений по source_updated_at, ingestion_sequence и event_id.
Рассчитал бы valid_from из времени фактического действия изменения, а valid_to через LEAD(valid_from), используя полуоткрытый интервал с включенным valid_from и исключенным valid_to.
Заменил бы все версии только для затронутых ключей в одной транзакции Snowflake, чтобы читатели не увидели частично исправленную временную линию.
Добавил бы dbt-тесты на одну текущую строку для ключа, отсутствие пересечений интервалов, valid_to больше valid_from и уникальность ключа версии измерения.

Зачем это спрашивают: Полный пересчет временной линии ключа делает поздние исправления и границы интервалов детерминированными.

querieskafka

Я бы сразу загружал факты с контролируемым неразрешенным ключом, а после прихода измерения пересчитывал только затронутые факты.

Сохранял бы бизнес-ключ клиента и event_time в промежуточной Delta-таблице фактов, назначая surrogate key 0 неразрешенным клиентам вместо удаления строки или подбора сомнительного соответствия.
Вел бы таблицу повторных попыток по бизнес-ключу клиента и затронутым партициям даты события, затем искал бы версию SCD2, действовавшую в event_time факта.
Через Databricks MERGE обновлял бы только неразрешенные или новые затронутые строки фактов, сохраняя исходное время события и метаданные загрузки.
Отслеживал бы число и возраст неразрешенных фактов по источникам, предупреждал до нарушения двухдневного ожидания и помещал в карантин факты, которые не разрешились за установленный срок.

Зачем это спрашивают: Факт доступен сразу после поступления, а позже получает версию измерения, действовавшую в момент события.

bigqueryconcurrencyiac

Я бы зафиксировал гранулярность основного факта продаж как одну строку на order_item_id, а суммы моделировал бы на том уровне, где они возникают.

Хранил бы количество товара, валовую сумму товара и его налог в факте товарной позиции, используя order_id как вырожденное измерение для группировки.
Хранил бы доставку, купоны и платежи в фактах уровня заказа, если бизнес не утвердил детерминированное распределение, например пропорционально чистой стоимости товаров.
Моделировал бы возвраты с одной строкой на refund_line_id, потому что один товар можно возвращать несколько раз, и агрегировал бы их до соединения с уровнем товарной позиции.
Добавил бы dbt-тест на уникальность order_item_id и сверку суммы товарных и заказных фактов с ежедневными контрольными итогами платежного провайдера.

Зачем это спрашивают: Явная гранулярность не дает суммам уровня заказа повторяться в каждой строке товара.

joinsbigquerybi

Я бы сначала доказал мультипликативное соединение, а затем привел каждую присоединяемую метрику к гранулярности запроса.

Сравнил бы число строк и SUM(order_revenue) после каждого JOIN и посчитал дочерние строки на заказ, чтобы показать умножение 4 на 1,5.
Агрегировал бы order_items до одной строки на заказ и payments до одной строки на заказ в отдельных моделях dbt до соединения любого результата с orders.
В LookML указал бы реальные relationships и primary keys, но не полагался бы на symmetric aggregates как способ скрыть неверную гранулярность SQL.
Добавил бы тесты гранулярности для каждой агрегированной модели и сверку выручки Explore с доверенным итогом уровня заказа.

Зачем это спрашивают: Предварительная агрегация независимых связей один-ко-многим убирает декартово умножение, которое дублирует метрики.

milestonessnapshotsnowflake

Я бы использовал два факта, потому что процессы отвечают на разные вопросы и обновляются по-разному.

Для accumulating snapshot сделал бы одну строку на fulfillment_order_id с полями ordered_at, packed_at, shipped_at, delivered_at и current status, обновляя строку по мере прохождения этапов.
Рассчитывал бы длительность циклов по этим полям этапов, а исходный факт событий хранил бы отдельно, если аналитикам нужны все переходы или исправления.
Для periodic snapshot сделал бы одну строку на store_id, sku_id и snapshot_date с ежедневными значениями on-hand, reserved и available inventory, даже если ничего не изменилось.
Настроил бы кластеризацию и срок хранения под способ чтения каждой таблицы, а также проверял уникальность уровня заказа для accumulating fact и уровня магазин-SKU-дата для periodic fact.

Зачем это спрашивают: Accumulating snapshot отслеживает конечный процесс, а periodic snapshot сохраняет состояние в регулярные моменты наблюдения.

foreign-keysbigquerydesign

Я бы заменил идентификаторы, зависящие от sequence, на детерминированные хеши и разделил идентичность товара и его исторической версии.

Создал бы постоянный ключ товара, хешируя каноническое представление исходной системы и бизнес-ключа товара через dbt_utils.generate_surrogate_key.
Создал бы ключ версии из постоянного ключа товара, valid_from и стабильного ID исходного события, чтобы две версии SCD2 не получили одинаковый ключ.
Нормализовал бы типы, часовые пояса, пробелы, регистр и обработку null до хеширования и не объединял бы исходные поля без разделителей или маркеров null.
Проверял бы уникальность и отсутствие null, сохранял естественные ключи для отладки и сравнивал выборку ключей между production и перестроенным окружением.

Зачем это спрашивают: Детерминированные ключи идентичности и версии сохраняют соединения фактов при полном перестроении и переносе между окружениями.

kafkadbt

Я бы зафиксировал и состояние входных данных, и версию преобразований до пересчета любой партиции.

Записал бы Apache Iceberg snapshot ID для каждой исходной таблицы и явно читал эти snapshots, чтобы файлы, пришедшие во время запуска, не меняли набор входных данных.
Запускал бы проект dbt с фиксированного Git SHA, закрепленными версиями пакетов, настройками хранилища, часовым поясом, версией валютных курсов и другими внешними справочниками.
Удалял бы дубли с полным порядком по event_time, Kafka partition, offset и event_id и не использовал бы недетерминированные функции или выбор первого значения без сортировки.
Идемпотентно записывал бы каждый месяц во временную таблицу, сверял число строк и денежные контрольные суммы с манифестом запуска, а затем атомарно заменял целевые партиции.

Зачем это спрашивают: Зафиксированные данные, код, порядок и атомарная публикация дают одинаковый исторический результат при повторном перестроении.

Закрытые вопросы

21
Нужно опубликовать метрику paid_orders по таблице orders на 10 миллионов строк. Каждая строка соответствует одному заказу, order_id уникален, account_id обязателен, время хранится в UTC, а аналитикам нужны дневные значения по аккаунтам. Какой точный семантический контракт вы зададите?
22
В модели order_items 35 миллионов строк, по одной на позицию заказа. В таблице-связке тегов 80 миллионов строк, потому что у позиции может быть до 5 тегов. Продукту нужна выручка по тегам, причем сумма по тегам должна точно совпадать с общей выручкой. Как смоделировать это в MetricFlow или другом семантическом слое без размножения строк?
semantic-layermonitoring
23
Определите метрику конверсии из сессии в покупку за 7 дней для 12 клиентских аккаунтов. События приходят в UTC, у каждого аккаунта есть часовой пояс IANA, в одной сессии может быть несколько покупок, а дашборд группирует когорты по локальному календарному дню начала сессии. Какие точные правила времени и гранулярности вы используете?
cohortsmonitoringsessions
24
Финансы используют фискальный календарь 4-4-5: неделя начинается в понедельник, финансовый год начинается в ближайший к 1 февраля понедельник, а в некоторых годах есть 53-я неделя. Семантический слой должен поддерживать фискальные неделю, квартал и год для дневной выручки с 2022 по 2032 год. Как вы это реализуете?
semantic-layer
25
Ежедневный снимок содержит остатки 2 миллионов аккаунтов в EUR, USD и GBP. Финансам нужен общий остаток на конец месяца в USD. Складывать все дневные остатки за месяц нельзя, у части аккаунтов нет строки в последний день, а курсы валют публикуются раз в день. Как вы определите метрику?
snapshotmonitoring
26
Текущая метрика active_accounts означает хотя бы один вход за последние 30 дней. Теперь продукт хочет считать хотя бы один экспорт отчета за последние 28 дней. Метрика используется в 14 дашбордах, 3 API-клиентах и двух квартальных целях. Как вы версионируете семантическое определение?
monitoringapi
27
За апрель Looker показывает чистую выручку 8,42 миллиона USD, а Tableau 8,57 миллиона USD, разница составляет 1,8%. Оба инструмента должны использовать одну семантическую метрику, но Tableau обновляет выгрузку ночью, а Looker обращается к данным напрямую. Как установить и обеспечить совпадение?
monitoringbiqueries
28
Постройте недельное удержание аккаунтов для B2B-продукта. Аккаунт попадает в когорту после первой успешной синхронизации данных, считается удержанным за неделю при хотя бы одной успешной синхронизации, события могут опаздывать на 72 часа, а график показывает недели с 0-й по 12-ю. Какие точные правила когорты и знаменателя вы зададите?
retentioncohorts
29
Семантическая метрика показывает ARR для 40 000 клиентских аккаунтов в 4 регионах. Менеджеры по продажам могут видеть только назначенные им аккаунты, региональные руководители свой регион, финансы все регионы, а названия клиентов не должны попадать в BI-выгрузки для ролей продаж. Как обеспечить доступ, не дублируя метрику?
monitoring
30
Нужно посчитать MRR на конец месяца по сегментам клиентов. В mrr_snapshots хранится одна строка на подписку и конец месяца, а customer_segment_history представляет SCD Type 2 с полями valid_from и valid_to. Около 6% клиентов меняют сегмент каждый год. Как смоделировать связь сущностей, чтобы исторический MRR не переписывался?
joins
31
Запрос дашборда в BigQuery сканирует 4,2 ТБ и стоит около $21 за одно обновление, хотя пользователи смотрят только последние 7 дней таблицы событий за 2 года. Как сократить сканируемые байты и доказать результат?
queriesbigquery
32
Таблица BigQuery объёмом 6 ТБ уже разбита на дневные партиции, но дашборд одного клиента всё равно сканирует 180 ГБ одной партиции ради 2000 строк. Обычно фильтры используют tenant_id и event_name. Что вы измените?
partitioningbigquery
33
В Snowflake запрос фильтрует 90 дней таблицы orders за 5 лет объёмом 14 ТБ, но сканирует 82% её микропартиций. Таблица получает обновления не по порядку. Как диагностировать и улучшить pruning?
queriespartitioningsnowflake
34
Модель dbt в Snowflake выполняется 38 минут на warehouse X-Small и 7 минут на Large. Запуск на Large расходует 0,93 кредита против 0,63 на X-Small. Какой размер вы выберете и что сначала изучите?
warehousesnowflakedbt
35
BI warehouse в Snowflake обслуживает 900 коротких запросов в день в 15 предсказуемых окнах активности. При AUTO_SUSPEND в 60 секунд он возобновляется 140 раз в день, а каждое возобновление имеет минимальную оплату за 60 секунд. Как это настроить?
querieswarehousesnowflake
36
В 9 утра 40 запросов дашбордов стоят в очереди за 20-минутной трансформацией Snowflake на одном Medium warehouse. Увеличение до Large ускоряет трансформацию, но p95 дашбордов остаётся 70 секунд. Что вы измените?
querieswarehousesnowflake
37
В таблице фактов Redshift 2 миллиарда строк, и одному клиенту принадлежит 42% из них. Таблица распределена по tenant_id, узлы показывают перекос строк в 4,8 раза, а joins сбрасывают данные на диск. Как изменить дизайн таблицы?
joinsmodelingredshift
38
Инкрементальный merge в dbt читает 40 ГБ изменённых данных источника, но сканирует таблицу назначения объёмом 12 ТБ и выполняется 52 минуты. Поздние обновления приходят в течение 5 дней. Как сократить работу без потери исправлений?
dbt
39
Переиспользуемую модель revenue ежедневно используют 18 дашбордов. В виде view каждое использование сканирует около 900 ГБ, а материализация в таблицу требует часового обновления со сканированием 120 ГБ. Как выбрать материализацию?
40
Расходы на warehouse выросли с $48 000 до $71 000 в месяц, но финансовая команда не может определить, какой домен dbt или дашборд вызвал рост. Как построить атрибуцию хотя бы 90% расходов?
warehousedbt
41
В dbt-проекте 2 400 моделей и 12 000 связей, а ночная сборка занимает 75 минут. Как за две секунды показать все затронутые модели выше и ниже по графу после изменения одной модели, не обращаясь к хранилищу?
querieswarehousedependencies
42
У вас 500 dbt-моделей, 18 BI-exposures и финансовый дашборд, который должен быть готов к 07:30 после 70-минутного окна трансформаций. Как с помощью exposures расставить приоритеты и проверить этот SLA?
dbt
43
В хранилище 900 dbt-моделей и 14 000 столбцов, а для планируемого переименования customer_id нужно за 15 минут подготовить отчёт о влиянии. Как построить надёжный column lineage, если dbt manifest в основном описывает зависимости на уровне моделей?
schemawarehousedependencies
44
Платформа запускает 1 200 dbt-моделей внутри Airflow, а также 6 000 ежедневных Spark-задач и задач загрузки данных, при этом полное окно обработки равно 90 минутам. Как с помощью OpenLineage связать эти системы без дублирующихся и неоднозначных запусков?
dbtairflowsystem-design
45
В dbt-репозитории 1 100 моделей, таблица событий на три миллиарда строк, 180 измерений и лимит CI в 22 минуты. Как распределить проверки между generic и singular tests, не сканируя всю таблицу событий в каждом pull request?
coveragegenericscode-review
46
Модель dbt на 260 строк обрабатывает курсы валют с периодом действия, пустую валюту и платежи, пришедшие с опозданием, но каждая проверка в хранилище занимает восемь минут. Как создать набор unit tests, который завершится меньше чем за 60 секунд?
hypothesis-testingvalidationfundamentals
47
Вы заменяете модель выручки с полным обновлением на 2,4 миллиарда строк инкрементальной версией, которая должна завершаться за 45 минут. Какие reconciliation tests вы запустите, если построчное сравнение слишком дорого?
reacttesting
48
Production-сборка 1 800 dbt-моделей занимает 70 минут, но CI для pull request ограничен 12 минутами. Как применить state selection и deferral, не позволив CI скрыть проблемы зависимостей?
dependenciesbuilddbt
49
Модель с контрактом на 60 столбцов питает 36 дашбордов к 08:00, а вам нужно за два релиза переименовать customer_segment и добавить обязательный segment_source. Как изменить схему, не требуя одновременного обновления всех потребителей?
schemafundamentals
50
Пять dbt-проектов независимо выпускаются каждую неделю, предоставляют 40 общих моделей и содержат 300 межпроектных ссылок. Как обеспечить совместимость, если потребители не могут обновиться в одном релизе?
dbt
51
В 10:05, через двадцать минут после merge dbt, финансы сообщают, что сегодняшняя чистая выручка на 18,4% выше данных платежного провайдера по 2,1 млн транзакций за день, а в 11:00 начинается встреча руководства с этим дашбордом. Что вы сделаете?
transactionsconcurrencydbt
52
После изменения модели число активных пользователей за неделю на дашборде роста увеличивается с 420 000 до 687 000 при join 900 млн событий с таблицей истории аккаунтов на 14 млн строк, а распределение рекламного бюджета начнется через 90 минут. Как вы поступите?
soft-skillsjoins
53
В 08:30 операционная команда сообщает, что дашборд все еще показывает вчерашние 3,8 млн заказов, хотя в хранилище уже 4,1 млн, каждое утро его открывают 600 менеджеров, а SLA свежести установлен на 07:00. Как вы ответите?
warehouse
54
Релиз в 14:00 меняет общую dbt-модель измерения, и к 14:25 падают двенадцать зависимых моделей, при этом часовой pipeline выручки должен завершиться в 15:00 и обслуживает бизнес с оборотом $9 млн в день. Вы откатитесь или будете исправлять вперед?
rollbackdbtci-cd
55
В 16:00 платежный источник присылает исправление, которое переносит €1,7 млн выручки с 30 июня на 1 июля в 82 000 записей, хотя июньские цифры для совета директоров уже выгрузили в 09:00. Как вы обработаете исправление?
concurrency
56
В 02:10 upstream-релиз переименовывает customer_id в customer_uuid в ежедневном источнике на 35 млн строк и ломает 27 dbt-моделей; отчетность поддержки открывается в 07:00 и нарушит четырехчасовой SLA, если восстановление займет больше 50 минут. Что вы сделаете?
deploymentdbt
57
Пересчет за шесть месяцев и 4,6 млрд событий завершается через 11 часов, но конверсия падает с 4,8% до 3,1%, а число платных конверсий уменьшается на 210 000; маркетинг представляет результат через два часа. Как вы отреагируете?
conversionbackfill
58
После деплоя инкрементальной модели ежедневная выручка от подписок ровно на 7,2% выше нормы три дня подряд, обработано 19 млн строк, а через 70 минут будут сформированы счета на $640 000. Расследование показывает, что повторные запуски могли вставить дубли событий подписки. Что вы сделаете?
deploymentconcurrency
59
В 12:15 дашборд CEO показывает выручку с начала месяца $12,6 млн, а финансы сообщают $11,9 млн, при этом встреча совета директоров начинается в 13:00 и спорные $700 000 относятся к 48 000 заказов. Обе команды утверждают, что их запрос верен. Как вы возглавите инцидент?
incidentsqueries
60
В 09:20 задание хранилища перезаписывает 31 день таблицы статусов клиентов только последним днем, сокращая ее с 780 млн до 26 млн строк; затронуты 34 дашборда и экспорт оттока со сроком в 10:30. Как вы восстановитесь?
churnwarehouse
61
Ночной dbt run вырос с 41 до 89 минут после одного merge и теперь нарушает SLA в 60 минут. Как вы проведёте диагностику и решите, нужен ли rollback?
rollbackdbt
62
В 05:45 прогноз завершения dbt DAG из 1500 моделей составляет 82 минуты, но payroll dashboard должен обновиться к 06:30 и зависит от 96 upstream models. Запустите ли вы только часть DAG?
dbt
63
Snowflake dbt build теперь занимает 64 минуты: 17 минут проходят в очереди, а одна модель сбрасывает 1,6 ТБ в remote storage, пока dashboards на 09:00 используют тот же warehouse. Что вы сделаете?
warehousesnowflakedata-structures
64
Оператор случайно запустил full refresh для 70 ТБ dbt models; через 18 минут заменены 23 из 140 relations, а прогноз стоимости составляет 4800 долларов. Как вы отреагируете?
dbt
65
dbt CI job со state и defer выбирает 8 моделей, но diff manifest с production показывает 312 затронутых descendants, а одна пропущенная модель обращается к удалённой колонке. Как вы проведёте расследование и containment?
schemadbt
66
Критичная dbt model падает в 4 из 12 запусков через 27-35 минут, а затем обычно проходит retry без изменения кода. Как вы разберётесь с flaky behavior, не превращая retries в норму?
normalizationresiliencedbt
67
Orchestrator завершился по timeout через 29 минут, хотя dbt query успел сделать commit, а retry затем добавил ещё 14 миллионов строк и завысил revenue на 2,3%. Что вы сделаете?
resilienceorchestrationqueries
68
Refactor затрагивает 960 узлов в dbt DAG из 1800 моделей, representative build занимает 52 минуты, а CI для pull request имеет жёсткий лимит 15 минут. Как вы примете решение о release?
refactoringdbt
69
После крупного DAG refactor production build из 1600 моделей вырос с 52 до 76 минут и нарушил SLA в 60 минут, хотя общие warehouse credits не изменились. Как вы восстановитесь и оцените refactor?
refactoringbuildwarehouse
70
Нужно сделать backfill за 120 дней по 5 ТБ в день за 72 часа; benchmark показывает 15 ТБ в час на выделенном warehouse, но production потребляет 65% общей capacity. Какой план вы одобрите?
capacitybackfillwarehouse
71
Finance показывает квартальную выручку 24,6 млн долларов, Product показывает 25,0 млн, расхождение составляет 1,8%, а CFO нужен один показатель через 90 минут. Что вы сделаете?
72
Число оплаченных заказов за ночь выросло на 7,4%, но суммы расчётов платёжного провайдера не изменились; новое соединение с промоакциями могло задвоить заказы с двумя купонами. Как вы проведёте расследование и решите, нужен ли откат?
joinsrollback
73
Finance считает ARR равным 82,3 млн долларов, Sales считает 86,1 млн, и оба значения используются в материалах для совета директоров, которые нужны завтра. Как вы разрешите конфликт?
74
Growth показывает retention на 30-й день 41%, а Product показывает 36% для одной и той же январской когорты из 120 000 пользователей. Как определить, какое определение когорты должно использоваться в планировании?
retentioncohorts
75
Три продуктовые команды отказываются от общей метрики активных пользователей: их показатели за 28 дней равны 9,2 млн, 8,5 млн и 7,9 млн. Как вы сдвинете организацию с места?
monitoring
76
Изменение определения churn снижает месячный показатель с 4,7% до 4,1% и меняет предыдущие 18 месяцев. Как вы решите, нужно ли пересчитать историю?
churn
77
Live-дашборд BI показывает 3,42 млн заказов за неделю, его CSV-экстракт на 06:00 показывает 3,31 млн, и руководитель уже переслал CSV. Как вы проведёте расследование и отреагируете?
78
В 15:30 CEO спрашивает, нужно ли остановить запуск к 16:00, потому что conversion составляет 12,4% в одном дашборде и 11,1% в другом на 48 000 сессий. Что вы порекомендуете?
sessions
79
Finance исключает возвраты, оформленные после закрытия месяца, а Product относит их к исходному заказу, из-за чего net revenue за март расходится на 2,6%. Как вы решите, что должен показывать каждый отчёт?
80
Новое семантическое определение повышает gross margin с 31,8% до 33,0% за два дня до публикации прогноза, а 14 дашбордов всё ещё используют старую формулу. Как вы управляете решением и переключением?
css
81
Месячный счёт за warehouse вырос со $180 000 до $310 000, хотя объём данных увеличился только на 8%. Как вы расследуете и остановите рост и докажете экономию?
warehouse
82
Backfill, запущенный одним аналитиком, потратил $28 000 за три часа и по прогнозу будет работать ещё 14 часов. Что вы сделаете сейчас и как решите, возобновлять ли его?
backfill
83
Потребление Snowflake выросло с 9 000 до 16 000 кредитов в неделю, хотя объём строк и трафик дашбордов не изменились. Как вы проведёте расследование и отреагируете?
zero-to-onesnowflake
84
Дашборд BigQuery сканирует 1,15 ТБ за обновление, обновляется 96 раз в день и теперь стоит около $690 в день. Как вы ограничите расходы и проверите устойчивое исправление?
bigqueryvalidation
85
Конкуренция дашбордов выросла со 120 до 900 пользователей в 9 утра, p95 latency увеличилась с 6 до 42 секунд, а autoscaling поднял стоимость compute на 70%. Как восстановить сервис и не закрепить высокий счёт?
lockinglatencyconcurrency
86
Продуктовая команда оспаривает chargeback на $74 000 из общего счёта warehouse в $110 000 и утверждает, что её помеченные запросы стоят только $29 000. Как разрешить спор и исправить модель?
querieswarehouse
87
Счёт вендора observability вырос при продлении с $240 000 до $390 000, потому что число наблюдаемых активов увеличилось с 18 000 до 31 000. Как решить, за что платить, и доказать ценность?
observabilitymonitoringprocurement
88
Хранение 7 ПБ аналитических данных стоит $161 000 в месяц, но закон требует семь лет для части записей, а аналитики используют только 12% таблиц после 90 дней. Какое решение по retention вы примете?
retention
89
Руководство требует сократить квартальный счёт warehouse в $400 000 на 25%, но свежесть finance должна оставаться в пределах 30 минут, p95 дашбордов ниже 5 секунд, а доступность на уровне 99,5%. Как вы выберете сокращения?
warehouse
90
Команда заявляет о годовой экономии warehouse в $420 000 после оптимизации, но за тот же период трафик запросов упал на 18%, а провайдер снизил цены на 7%. Как доказать вклад инженерных изменений?
querieswarehouseoptimization
91
Вам нужно мигрировать 180 production marts в новый namespace с простоем записи менее 10 минут. Как вы спланируете переключение и откат?
rollbackkubernetes
92
Компания переносит 80 ТБ, 420 моделей и 600 dashboards в новый cloud warehouse за 12 недель. Как вы выстроите миграцию без заморозки аналитики?
migrationswarehouse
93
Вам нужно перенести 650 dashboards и 1 800 пользователей с одной BI-платформы на другую до истечения лицензии через 90 дней. Что вы сделаете?
94
Вам нужно мигрировать 900 аналитических задач по расписанию в новый orchestrator, сохранив SLA, retries и состояние backfill. Как вы это выполните?
orchestrationbackfill
95
DAG из 2 400 узлов выполняется 86 минут при SLA 90 минут, но на рефакторинг есть только 3 инженера и 6 недель. Как вы снизите риск и runtime?
refactoring
96
Инцидент с данными завысил недельную выручку на 8% на 36 часов, и руководители продаж больше не доверяют dashboards. Как вы восстановите доверие бизнеса?
incidents
97
Через 2 часа после заседания совета директоров вы обнаружили, что валовая маржа составляла 31,4%, а не 34,1%. Как вы исправите отчёт и исходный процесс?
cssconcurrency
98
В вашем dbt-проекте 1 300 моделей, и данные использования показывают, что сотни устарели. Как вы выведете их из эксплуатации, не сломав неизвестных потребителей?
dbt
99
Команда источника удалит customer key через 10 дней, нарушив контракт, который используют 14 команд и 75 downstream-моделей. Как вы обработаете межорганизационную поломку?
100
Через 90 минут после начала переключения миграции warehouse 22% сертифицированных метрик не проходят паритет, а задержка dashboards выросла втрое. Что вы сделаете?
migrationswarehouselatency

Вопросы

1В BigQuery факт событий в dbt получает 6 ТБ в день, хранит данные за 24 месяца и должен обновлять дашборд каждые 15 минут. Как бы вы спроектировали инкрементальную модель?

6Модель dbt в Snowflake обрабатывает 12 ТБ телеметрии в день, а один дневной инкрементальный запуск занимает 100 минут при SLA в 90 минут. Как применить микробатчи dbt?

Закрытые вопросы