У ритейлера 180 систем-источников, 14 бизнес-направлений, 6 000 отчетов и бюджет модернизации $12 млн на три года. Как определить целевую корпоративную архитектуру данных и очередность возможностей?

Я бы определил целевую архитектуру как карту возможностей, связанную с измеримыми бизнес-сценариями, а финансирование выстроил бы по зависимостям. - Я бы связал видимость запасов, идентификацию клиентов, финансовое закрытие и регуляторную отчетность с возможностями ingestion, governance, моделирования, выдачи и эксплуатации, назначив одного ответственного за каждую. - В первые 12 месяцев я бы профинансировал общую идентификацию, метаданные, CDC и контроль качества до переноса ценных отчетов, поскольку этот фундамент убирает повторную работу в 14 направлениях. - К квартальным инвестиционным воротам я бы привязал критерии выхода: 95% покрытия lineage, свежесть запасов до 5 минут и вывод из эксплуатации 1 500 отчетов.

Производитель хранит 4 ПБ файлов с датчиков, выполняет 20 000 SQL-дашбордов и обучает 80 моделей при SLA аналитики 15 минут. Вы выберете warehouse, lakehouse или оба варианта?

Я бы использовал lakehouse для датчиков и ML-нагрузок, а управляемый SQL-слой выдачи для дашбордов. - Объектное хранилище с Iceberg или Delta экономично хранит 4 ПБ и позволяет Spark обрабатывать сырые временные ряды без предварительного копирования в warehouse. - Курированные размерные таблицы я бы публиковал в Snowflake или SQL endpoint lakehouse, рассчитанный на 20 000 дашбордов и изолированный от вычислений для обучения моделей. - Я бы сохранил единый каталог, стабильные контракты продуктов и сверки между слоями, чтобы гибридный выбор не создал два определения истины.

В финансовой компании 900 аналитиков, 12 000 управляемых SQL-запросов в час, мало специалистов по Spark и запуск через шесть месяцев. Вы выберете Snowflake или Databricks?

Для такой управляемой BI-нагрузки и ограничения в шесть месяцев я бы выбрал Snowflake. - Разделенные virtual warehouses позволят изолировать параллельную работу финансов, рисков и ad hoc пользователей без постоянной настройки Spark-кластеров небольшой платформенной командой. - Dynamic masking, row access policies и зрелые SQL-инструменты подходят управляемой аудитории аналитиков, а dbt сохранит проверяемые трансформации. - Выбор я бы подтвердил двухнедельным тестом пиковой параллельности, типовой схемы на 20 ТБ и прогнозируемых годовых credits, а не списком функций.

Медиакомпания загружает 25 ТБ в день, выполняет 300 Spark-пайплайнов, обучает рекомендательные модели на GPU и требует стриминговые признаки не старше 60 секунд. Вы выберете Snowflake или Databricks?

Я бы выбрал Databricks, потому что в этой нагрузке доминируют Spark-разработка, стриминг и ML. - Auto Loader и Structured Streaming смогут загружать 25 ТБ в день в Delta-таблицы, которыми совместно пользуются batch-пайплайны и генерация признаков. - Job clusters и GPU pools изолируют 300 пайплайнов и обучение моделей, а Unity Catalog даст централизованный доступ и контроль lineage. - Я бы измерил сквозную свежесть признаков, восстановление из checkpoints и стоимость DBU с облачными ресурсами, а BI-выдачу отделил бы, если позже начнет доминировать параллельность дашбордов.

Компания должна открыть 2 ПБ lake-таблиц для Spark, Trino, Flink и двух облачных провайдеров без привязки к поставщику. Вы стандартизируете Delta Lake или Apache Iceberg?

Я бы стандартизировал Apache Iceberg, потому что переносимость между движками и облаками является жестким ограничением. - Iceberg широко поддерживается Spark, Trino, Flink и управляемыми облачными каталогами, поэтому таблице не требуется путь выполнения, завязанный на Databricks. - Скрытое партиционирование и эволюция партиций позволяют менять физическую раскладку без поломки потребителей по мере роста 2 ПБ данных. - До глобального внедрения одного формата я бы все равно проверил на наших движках скорость построчных изменений, отказоустойчивость каталога и поведение конкурентных записей.

Тридцать команд публикуют 600 таблиц через bronze, silver и gold слои, а потребителям нужен SLO свежести 99,5%. Какие контракты вы зададите между слоями medallion?

Я бы сделал каждый слой ответственным контрактом с разными гарантиями, а не соглашением об именах папок. - Bronze сохраняет исходную нагрузку, время загрузки, offset источника и возможность повторного проигрывания за 30 дней, а дрейф схемы помещает в карантинные поля. - Silver гарантирует типизированные ключи, дедупликацию, классификацию PII и заявленное опоздание, gold гарантирует бизнес-гранулярность, определения метрик и SLO свежести 99,5%. - Продвижение требует автоматических проверок контракта, сверки и lineage, а при неуспешной сборке gold потребителям остается доступен последний корректный снимок.

E-commerce платформа обрабатывает 120 000 событий в секунду, требует fraud-признаки за 3 секунды и финансовые итоги к 06:00, сохраняя данные 7 лет. Спроектируйте платформу реального времени и batch.

Я бы использовал единый долговечный событийный backbone с отдельными стриминговыми и batch-продуктами на общих управляемых контрактах хранения. - Kafka партиционировал бы данные по счету или заказу, а Flink рассчитывал бы fraud-признаки за 3 секунды с checkpoints и идемпотентными sinks. - Сырые события и CDC попадали бы в объектное хранилище Iceberg на семь лет, где Spark строил бы финансовые снимки со сверкой от источника до ledger до 06:00. - Общий schema registry, каталог и бизнес-ключи связывали бы оба пути, но вычисления и домены отказа оставались бы изолированными.

У логистической компании 40 типов событий, опоздание данных до 15 минут, SLA трекинга 5 секунд и всего восемь платформенных инженеров. Вы выберете Lambda или Kappa?

Я бы выбрал Kappa с повторно проигрываемыми потоками, потому что единая модель обработки соответствует SLA и размеру команды из восьми человек. - Kafka хранит неизменяемые события достаточно долго для исправлений, а окна event time и watermarks во Flink обрабатывают опоздания до 15 минут. - Исторический перерасчет выполняется повторным проигрыванием ограниченного потока Kafka или объектного хранилища в новую версию результата вместо поддержки отдельной batch-логики. - Lambda я бы выбрал только тогда, когда обязательные перерасчеты превышают практическую скорость stream replay или финансы требуют отдельно реализованный контрольный batch-путь.

Нужно захватывать изменения из 220 баз PostgreSQL и Oracle со скоростью 70 000 строк в секунду, свежестью до 2 минут и без остановки источников. Какую CDC-архитектуру вы выберете?

Я бы использовал CDC на основе журналов в партиционированный событийный backbone, сохраняя позиции источника до каждого sink. - Debezium или нативный захват Oracle читает журналы транзакций без сканирования таблиц, а коннекторы группируются по критичности, чтобы одна шумная база не вытеснила остальные 219. - Kafka хранит LSN или SCN источника, идентификатор транзакции, версию схемы и tombstones, а потребители дедуплицируют по позиции и применяют изменения идемпотентно. - Начальные снимки используют порционные согласованные чтения, затем переключаются с зафиксированной позиции журнала, а до подключения потребителей проходят сверку количества и контрольных сумм.

Kafka-платформа переносит 300 000 событий в секунду для 25 доменов, порядок по клиенту обязателен, и ни один tenant не может занимать более 5% мощности. Как спроектировать topics и partitions?

Я бы партиционировал принадлежащие доменам topics по стабильному ключу клиента, а identity tenant передавал отдельно для квот и справедливого распределения. - Границы topics следуют продуктам данных и классам хранения, а количество partitions определяется измеренной пропускной способностью brokers и consumers с запасом 30%. - Ключ клиента сохраняет порядок только для событий этого клиента, но не всего tenant; идемпотентный producer и schema registry задают доставку и совместимость. - Доверенная identity tenant управляет квотами, отдельными consumer groups и выделенными topics для крупнейших tenant, обеспечивая лимит 5% без изменения порядка клиента.

Платежный поток идет со скоростью 45 000 событий в секунду и должен создавать одну запись ledger на транзакцию при p99 SLA 4 секунды. Какой контракт согласованности Kafka и Flink вы спроектируете?

Я бы зафиксировал контракт: каждая принятая Kafka-транзакция становится одной видимой записью ledger за 4 секунды по p99 через идемпотентный sink, не ожидающий checkpoint. - Kafka producers используют идемпотентность и transaction IDs, а Flink сохраняет offsets и keyed state каждые 10-30 секунд только для восстановления. - Sink сразу выполняет upsert по transaction ID с уникальным ограничением, поэтому replay после checkpoint восстанавливает ту же строку, а не создает второй эффект. - Контракт задает уникальность на транзакцию, область порядка, видимость за 4 секунды по p99, максимальную задержку восстановления и сверку transaction IDs Kafka с ledger.

Spark каждую ночь уплотняет 80 ТБ Iceberg-таблиц, Flink записывает 20 000 обновлений в секунду, а читателям нужны согласованные снимки. Как скоординировать топологию?

Я бы разрешил обоим движкам фиксировать изменения через каталог Iceberg, разделив области записи и обрабатывая конфликты повтором commit на новом snapshot. - Flink пишет небольшие equality deletes и data files в ограниченные partitions, а Spark уплотняет data files и delete files только в partitions старше окна опоздания стриминга. - Каталог атомарно публикует snapshot, поэтому читатели закрепляются на одном снимке и не видят частично уплотненные файлы. - Обслуживание использует повторы commit, очистку orphan files после безопасного срока и метрики количества файлов, конфликтов и возраста snapshot.

Банк работает в ЕС, США и Сингапуре, обрабатывает 8 ТБ в день и запрещает вывоз сырых клиентских данных из юридического региона. Спроектируйте межрегиональную архитектуру.

Я бы оставил сырые и идентифицированные данные в региональных data planes, а в глобальный слой реплицировал только одобренные агрегаты или токенизированные записи. - У каждого региона свои ingestion, ключи шифрования, граница политик каталога и вычислительные мощности, а residency tags проверяются до любого экспорта. - Глобальные продукты получают одобренные контрактом колонки с необратимыми региональными токенами или k-анонимными агрегатами, но не прямые идентификаторы. - Центральный control plane распространяет шаблоны политик и метаданные, но не хранит запрещенную нагрузку, а residency-тесты блокируют несоответствующие пайплайны до развертывания.

Страховая компания должна выполнять аналитику в AWS и Azure, перемещать между облаками не более 50 ТБ в месяц и восстанавливаться после потери провайдера за 8 часов. Какую multi-cloud архитектуру выбрать?

Я бы использовал переносимые объектные табличные форматы с региональными вычислениями и реплицировал только критичные для восстановления продукты в пределах лимита 50 ТБ. - Iceberg-таблицы, открытые Parquet-файлы и переносимый слой трансформаций исключают обычные чтения через границу облаков. - Продукты классифицируются по уровню восстановления, и только наборы для цели 8 часов получают инкрементальную межоблачную репликацию и манифесты восстановления каталога. - Квартальные тесты failover восстанавливают identity, каталог, оркестрацию и приоритетные продукты во втором облаке, а бюджеты egress отклоняют неодобренную репликацию.

Маркетплейсу нужны чтения профиля быстрее 20 мс, ad hoc анализ 3 ПБ, полнотекстовый поиск по 500 млн объявлений и неизменяемый аудит. Как выбрать технологии хранения?

Я бы использовал polyglot storage, потому что четыре паттерна доступа имеют несовместимые требования к задержке и хранению. - Key-value хранилище обслуживает профили быстрее 20 мс, объектные Iceberg-таблицы держат 3 ПБ для аналитических сканов, а OpenSearch отвечает за текстовый поиск объявлений. - Выделенный audit bucket использует WORM или Object Lock с заблокированным сроком хранения, а подписанные хеши и регулярная проверка целостности выявляют изменения; одного append-only режима недостаточно. - Архитектура назначает одно авторитетное хранилище для каждого факта, определяет восстановление поиска и кэшей и исключает dual write через события или outbox.

Глобальному дистрибьютору нужно интегрировать 140 изменчивых источников, хранить историю 10 лет и подключать приобретенные компании за 30 дней. Как спроектировать ядро Data Vault 2.0?

Я бы использовал raw core Data Vault 2.0, чтобы быстро принимать изменения источников и сохранять аудируемую историю. - Hubs представляют стабильные бизнес-ключи клиентов и продуктов, links фиксируют связи, а satellites хранят специфичную для источника описательную историю со временем загрузки и record source. - Hash keys позволяют параллельно загружать 140 источников, а правила коллизий бизнес-ключей и same-as links управляются централизованно, а не скрываются в loaders. - Приобретенные компании сначала сопоставляют ключи и метаданные источников с raw vault за 30 дней, а бизнес-правила остаются в business vault и последующих витринах.

Ядро Data Vault содержит 12 лет истории продаж, но 1 200 аналитикам нужны ежедневные запросы выручки быстрее 5 секунд. Как построить размерные витрины без второй истины?

Я бы публиковал звездные витрины как версионируемые проекции vault, а не как независимо мастеренные данные. - Point-in-time и bridge tables в Business Vault эффективно разрешают историю, затем витрины предоставляют заявленную гранулярность строки заказа, согласованные измерения и поведение SCD. - Инкрементальные сборки используют load timestamps vault и при каждом выпуске сверяют выручку, количество строк и покрытие ключей с raw core. - Определения метрик и контракты витрин живут в семантическом каталоге, а 12-летний vault остается аудируемым источником для восстановления.

В компании 18 продуктовых команд в commerce, fulfillment, finance и customer support с общими данными клиентов и заказов. Как провести границы доменов data mesh?

Я бы проводил границы по бизнес-возможностям и правам принятия решений, а не по существующим базам приложений. - Commerce владеет предложением и намерением заказа, fulfillment владеет исполнением доставки, finance владеет проведенными денежными событиями, customer владеет мастер-атрибутами идентичности клиента. - Общие идентификаторы и события жизненного цикла пересекают границы через версионируемые продукты, где указаны гранулярность, авторитетность, свежесть и допустимое использование. - Я бы проверил карту на пяти реальных аналитических сценариях и делил домен только тогда, когда один владелец не может обеспечить разные темпы изменений или политики.

Восемь доменов публикуют 240 продуктов данных для 600 потребителей, а о ломающих изменениях нужно предупреждать за 90 дней. Что должен содержать контракт продукта, контролируемый платформой?

Я бы сделал контракт машиночитаемым и проверял идентичность, семантику, уровни сервиса, политики и совместимость при публикации. - Для каждого из 240 продуктов он объявляет владельца, гранулярность, ключи, схему, классификацию, свежесть, доступность, retention и канал поддержки. - Registry проверяет обратную совместимость, пороги качества, lineage и метаданные 90-дневного вывода в CI до публикации producer. - Телеметрия потребителей показывает затронутых пользователей, а несовместимое изменение требует параллельной major-версии с доказательством миграции вместо правки на месте.

Двенадцать доменов работают независимо, но регулятор требует единую политику классификации PII и аудиторские доказательства за 48 часов. Как внедрить федеративное governance?

Я бы централизовал обязательные политики и стандарты доказательств, а решения по продуктам и исправления делегировал владельцам доменов. - Центральный совет определяет таксономию PII, классы хранения, шаблоны контроля и формат доказательств за 48 часов, а legal и security имеют право вето. - Доменные stewards классифицируют активы, одобряют доступ и отвечают за SLO через policy-as-code в своих delivery pipelines. - Платформа собирает результаты контролей, lineage, исключения и владение в единое аудиторское представление, а временное исключение требует именованного владельца риска.

Вопросы на собеседовании: Архитектор данных

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

Смотреть пример резюме: Архитектор данных →

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

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

Вопросы

system-design

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

Я бы связал видимость запасов, идентификацию клиентов, финансовое закрытие и регуляторную отчетность с возможностями ingestion, governance, моделирования, выдачи и эксплуатации, назначив одного ответственного за каждую.
В первые 12 месяцев я бы профинансировал общую идентификацию, метаданные, CDC и контроль качества до переноса ценных отчетов, поскольку этот фундамент убирает повторную работу в 14 направлениях.
К квартальным инвестиционным воротам я бы привязал критерии выхода: 95% покрытия lineage, свежесть запасов до 5 минут и вывод из эксплуатации 1 500 отчетов.

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

sqlwarehouselakehouse

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

Объектное хранилище с Iceberg или Delta экономично хранит 4 ПБ и позволяет Spark обрабатывать сырые временные ряды без предварительного копирования в warehouse.
Курированные размерные таблицы я бы публиковал в Snowflake или SQL endpoint lakehouse, рассчитанный на 20 000 дашбордов и изолированный от вычислений для обучения моделей.
Я бы сохранил единый каталог, стабильные контракты продуктов и сверки между слоями, чтобы гибридный выбор не создал два определения истины.

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

sqlqueriessnowflake

Для такой управляемой BI-нагрузки и ограничения в шесть месяцев я бы выбрал Snowflake.

Разделенные virtual warehouses позволят изолировать параллельную работу финансов, рисков и ad hoc пользователей без постоянной настройки Spark-кластеров небольшой платформенной командой.
Dynamic masking, row access policies и зрелые SQL-инструменты подходят управляемой аудитории аналитиков, а dbt сохранит проверяемые трансформации.
Выбор я бы подтвердил двухнедельным тестом пиковой параллельности, типовой схемы на 20 ТБ и прогнозируемых годовых credits, а не списком функций.

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

snowflakestreamingci-cd

Я бы выбрал Databricks, потому что в этой нагрузке доминируют Spark-разработка, стриминг и ML.

Auto Loader и Structured Streaming смогут загружать 25 ТБ в день в Delta-таблицы, которыми совместно пользуются batch-пайплайны и генерация признаков.
Job clusters и GPU pools изолируют 300 пайплайнов и обучение моделей, а Unity Catalog даст централизованный доступ и контроль lineage.
Я бы измерил сквозную свежесть признаков, восстановление из checkpoints и стоимость DBU с облачными ресурсами, а BI-выдачу отделил бы, если позже начнет доминировать параллельность дашбордов.

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

procurement

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

Iceberg широко поддерживается Spark, Trino, Flink и управляемыми облачными каталогами, поэтому таблице не требуется путь выполнения, завязанный на Databricks.
Скрытое партиционирование и эволюция партиций позволяют менять физическую раскладку без поломки потребителей по мере роста 2 ПБ данных.
До глобального внедрения одного формата я бы все равно проверил на наших движках скорость построчных изменений, отказоустойчивость каталога и поведение конкурентных записей.

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

slo

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

Bronze сохраняет исходную нагрузку, время загрузки, offset источника и возможность повторного проигрывания за 30 дней, а дрейф схемы помещает в карантинные поля.
Silver гарантирует типизированные ключи, дедупликацию, классификацию PII и заявленное опоздание, gold гарантирует бизнес-гранулярность, определения метрик и SLO свежести 99,5%.
Продвижение требует автоматических проверок контракта, сверки и lineage, а при неуспешной сборке gold потребителям остается доступен последний корректный снимок.

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

designbatchconcurrency

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

Kafka партиционировал бы данные по счету или заказу, а Flink рассчитывал бы fraud-признаки за 3 секунды с checkpoints и идемпотентными sinks.
Сырые события и CDC попадали бы в объектное хранилище Iceberg на семь лет, где Spark строил бы финансовые снимки со сверкой от источника до ledger до 06:00.
Общий schema registry, каталог и бизнес-ключи связывали бы оба пути, но вычисления и домены отказа оставались бы изолированными.

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

lambda

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

Kafka хранит неизменяемые события достаточно долго для исправлений, а окна event time и watermarks во Flink обрабатывают опоздания до 15 минут.
Исторический перерасчет выполняется повторным проигрыванием ограниченного потока Kafka или объектного хранилища в новую версию результата вместо поддержки отдельной batch-логики.
Lambda я бы выбрал только тогда, когда обязательные перерасчеты превышают практическую скорость stream replay или финансы требуют отдельно реализованный контрольный batch-путь.

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

databasepostgresarchitecture

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

Debezium или нативный захват Oracle читает журналы транзакций без сканирования таблиц, а коннекторы группируются по критичности, чтобы одна шумная база не вытеснила остальные 219.
Kafka хранит LSN или SCN источника, идентификатор транзакции, версию схемы и tombstones, а потребители дедуплицируют по позиции и применяют изменения идемпотентно.
Начальные снимки используют порционные согласованные чтения, затем переключаются с зафиксированной позиции журнала, а до подключения потребителей проходят сверку количества и контрольных сумм.

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

kafkadesigncapacity

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

Границы topics следуют продуктам данных и классам хранения, а количество partitions определяется измеренной пропускной способностью brokers и consumers с запасом 30%.
Ключ клиента сохраняет порядок только для событий этого клиента, но не всего tenant; идемпотентный producer и schema registry задают доставку и совместимость.
Доверенная identity tenant управляет квотами, отдельными consumer groups и выделенными topics для крупнейших tenant, обеспечивая лимит 5% без изменения порядка клиента.

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

kafkadesignconsistency

Я бы зафиксировал контракт: каждая принятая Kafka-транзакция становится одной видимой записью ledger за 4 секунды по p99 через идемпотентный sink, не ожидающий checkpoint.

Kafka producers используют идемпотентность и transaction IDs, а Flink сохраняет offsets и keyed state каждые 10-30 секунд только для восстановления.
Sink сразу выполняет upsert по transaction ID с уникальным ограничением, поэтому replay после checkpoint восстанавливает ту же строку, а не создает второй эффект.
Контракт задает уникальность на транзакцию, область порядка, видимость за 4 секунды по p99, максимальную задержку восстановления и сверку transaction IDs Kafka с ledger.

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

snapshot

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

Flink пишет небольшие equality deletes и data files в ограниченные partitions, а Spark уплотняет data files и delete files только в partitions старше окна опоздания стриминга.
Каталог атомарно публикует snapshot, поэтому читатели закрепляются на одном снимке и не видят частично уплотненные файлы.
Обслуживание использует повторы commit, очистку orphan files после безопасного срока и метрики количества файлов, конфликтов и возраста snapshot.

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

designconcurrency

Я бы оставил сырые и идентифицированные данные в региональных data planes, а в глобальный слой реплицировал только одобренные агрегаты или токенизированные записи.

У каждого региона свои ingestion, ключи шифрования, граница политик каталога и вычислительные мощности, а residency tags проверяются до любого экспорта.
Глобальные продукты получают одобренные контрактом колонки с необратимыми региональными токенами или k-анонимными агрегатами, но не прямые идентификаторы.
Центральный control plane распространяет шаблоны политик и метаданные, но не хранит запрещенную нагрузку, а residency-тесты блокируют несоответствующие пайплайны до развертывания.

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

design

Я бы использовал переносимые объектные табличные форматы с региональными вычислениями и реплицировал только критичные для восстановления продукты в пределах лимита 50 ТБ.

Iceberg-таблицы, открытые Parquet-файлы и переносимый слой трансформаций исключают обычные чтения через границу облаков.
Продукты классифицируются по уровню восстановления, и только наборы для цели 8 часов получают инкрементальную межоблачную репликацию и манифесты восстановления каталога.
Квартальные тесты failover восстанавливают identity, каталог, оркестрацию и приоритетные продукты во втором облаке, а бюджеты egress отклоняют неодобренную репликацию.

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

searchimmutability

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

Key-value хранилище обслуживает профили быстрее 20 мс, объектные Iceberg-таблицы держат 3 ПБ для аналитических сканов, а OpenSearch отвечает за текстовый поиск объявлений.
Выделенный audit bucket использует WORM или Object Lock с заблокированным сроком хранения, а подписанные хеши и регулярная проверка целостности выявляют изменения; одного append-only режима недостаточно.
Архитектура назначает одно авторитетное хранилище для каждого факта, определяет восстановление поиска и кэшей и исключает dual write через события или outbox.

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

designdata-vaultonboarding

Я бы использовал raw core Data Vault 2.0, чтобы быстро принимать изменения источников и сохранять аудируемую историю.

Hubs представляют стабильные бизнес-ключи клиентов и продуктов, links фиксируют связи, а satellites хранят специфичную для источника описательную историю со временем загрузки и record source.
Hash keys позволяют параллельно загружать 140 источников, а правила коллизий бизнес-ключей и same-as links управляются централизованно, а не скрываются в loaders.
Приобретенные компании сначала сопоставляют ключи и метаданные источников с raw vault за 30 дней, а бизнес-правила остаются в business vault и последующих витринах.

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

queriessecretsdata-vault

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

Point-in-time и bridge tables в Business Vault эффективно разрешают историю, затем витрины предоставляют заявленную гранулярность строки заказа, согласованные измерения и поведение SCD.
Инкрементальные сборки используют load timestamps vault и при каждом выпуске сверяют выручку, количество строк и покрытие ключей с raw core.
Определения метрик и контракты витрин живут в семантическом каталоге, а 12-летний vault остается аудируемым источником для восстановления.

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

data-mesh

Я бы проводил границы по бизнес-возможностям и правам принятия решений, а не по существующим базам приложений.

Commerce владеет предложением и намерением заказа, fulfillment владеет исполнением доставки, finance владеет проведенными денежными событиями, customer владеет мастер-атрибутами идентичности клиента.
Общие идентификаторы и события жизненного цикла пересекают границы через версионируемые продукты, где указаны гранулярность, авторитетность, свежесть и допустимое использование.
Я бы проверил карту на пяти реальных аналитических сценариях и делил домен только тогда, когда один владелец не может обеспечить разные темпы изменений или политики.

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

versioning

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

Для каждого из 240 продуктов он объявляет владельца, гранулярность, ключи, схему, классификацию, свежесть, доступность, retention и канал поддержки.
Registry проверяет обратную совместимость, пороги качества, lineage и метаданные 90-дневного вывода в CI до публикации producer.
Телеметрия потребителей показывает затронутых пользователей, а несовместимое изменение требует параллельной major-версии с доказательством миграции вместо правки на месте.

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

classificationpiidata-governance

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

Центральный совет определяет таксономию PII, классы хранения, шаблоны контроля и формат доказательств за 48 часов, а legal и security имеют право вето.
Доменные stewards классифицируют активы, одобряют доступ и отвечают за SLO через policy-as-code в своих delivery pipelines.
Платформа собирает результаты контролей, lineage, исключения и владение в единое аудиторское представление, а временное исключение требует именованного владельца риска.

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

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

21
У предприятия 2 500 наборов данных на пяти платформах, и за девять месяцев нужна автоматизированная обнаруживаемость, но бизнес-владение должно остаться в 20 доменах. Это data fabric, data mesh или оба подхода?
ownershipdata-mesh
22
У медицинской группы 65 млн записей пациентов, 14 систем-источников и требование создать golden record с долей ложных объединений ниже 0,1%. Как спроектировать MDM?
system-designdesign
23
Статус заказа расходится между операционной системой, warehouse и MDM hub для 3% из 40 млн заказов. Какая система должна определять истину при SLA отчетности 10 минут?
warehousesystem-design
24
У компании 7 000 таблиц, 1 500 пользователей и три рассматриваемых продукта каталога, при этом за шесть месяцев нужно достичь 90% покрытия владельцами. Как выбрать и внедрить каталог метаданных?
metadata-managementdata-catalogcoverage
25
Регулятор требует column-level lineage от 35 систем-источников через 900 трансформаций до 120 отчетов с выдачей доказательств за 24 часа. Как построить архитектуру?
system-designlineageschema
26
Команды finance и product используют шесть определений активного клиента в 400 дашбордах, а запросы метрик должны отвечать за 3 секунды. Как спроектировать semantic metrics layer?
queriesdesignmonitoring
27
Десять команд эксплуатируют 320 критичных наборов, руководство требует 99,7% своевременной доставки и обнаружения существенных ошибок качества за 10 минут. Спроектируйте observability и модель SLO.
designsloobservability
28
Двадцать доменных команд публикуют клиентские продукты, но в платформенной команде всего шесть инженеров, и она не может писать каждое правило качества. Как разделить ответственность при SLO 99,5%?
slo
29
Клиент требует удаление по GDPR из 60 систем и 1,2 ПБ lake-данных, но неизменяемые финансовые записи должны храниться семь лет. Спроектируйте удаление со сроком 30 дней.
system-designdesignimmutability
30
Телеком-ландшафт растет на 90 ТБ в месяц за счет сырых событий, курированных таблиц, логов и резервных копий с правилами хранения 30 дней, 2 года и 7 лет. Как построить retention?
retentionbackups
31
Глобальный HR warehouse обслуживает 30 стран и 4 000 менеджеров, которые могут видеть только свою иерархию и не могут читать колонки зарплат вне compensation-команд. Как спроектировать IAM?
schemawarehousedesign
32
Пяти аналитическим платформам нужно соединять поведение клиентов без раскрытия email и телефона, а security требует отзыва токена за один час. Как спроектировать токенизацию?
design-systemjoinsdesign
33
Сорок producers обслуживают 600 consumers, схемы меняются еженедельно, и потребителям нужно 90 дней на миграцию. Какую политику эволюции схем вы введете?
schema
34
Банк публикует 75 типов событий для 160 приложений, и история должна оставаться доступной для replay семь лет несмотря на изменения контрактов. Как развивать event contracts?
35
Airflow должен планировать 6 000 ежедневных jobs для 25 команд, finance обязан завершаться к 06:00, а research может потреблять только 20% вычислений. Как спроектировать оркестрацию и изоляцию?
designorchestrationairflow
36
Общая платформа обслуживает 700 BI-пользователей, 120 ELT jobs и 40 ML-команд при p95 дашбордов до 4 секунд и фиксированном месячном бюджете вычислений. Как изолировать нагрузки?
etlelt
37
Платформа страховых случаев хранит 600 ТБ, требует RPO 15 минут и RTO 2 часа и должна пережить потерю целого региона. Какую disaster recovery архитектуру вы одобрите?
architecture
38
Локальный Oracle warehouse хранит 450 ТБ, поддерживает 3 200 отчетов и должен переехать в облако за 18 месяцев без перерыва отчетности более 30 минут. Как разбить миграцию?
migrationswarehouse
39
Mainframe каждую ночь выдает 8 млн fixed-width записей, имеет batch-окно четыре часа и содержит 30 лет бизнес-правил COBOL, которые нельзя переписать за первый год. Как модернизировать его архитектуру данных?
batch
40
У двух объединившихся компаний 9 ПБ данных, пересекающиеся customer IDs, 11 BI-инструментов и срок совета директоров 12 месяцев для консолидированной отчетности по выручке. Как объединить ландшафты?
estimation
41
SaaS-аналитика обслуживает 12 000 tenants размером от 20 ГБ до 80 ТБ, требует p95 до 6 секунд и запрещает межклиентское раскрытие. Как спроектировать изоляцию?
designcloud
42
Домены commerce, inventory и finance асинхронно обновляют один заказ, но ежедневная выручка должна сходиться с точностью $10 на 50 млн заказов. Как спроектировать междоменную согласованность?
designconsistencyasync
43
Сорока ML-командам нужны online-признаки быстрее 25 мс, offline-обучение на двух годах истории и point-in-time корректность при 5 ТБ новых данных признаков в день. Как построить архитектуру?
44
Новая платформа вырастет с 60 ТБ до 1,5 ПБ и с 2 000 до 80 000 событий в секунду за 24 месяца, а procurement требует план мощности сейчас. Как ее рассчитать?
procurementcapacity
45
Расходы облачной платформы ограничены $350 000 в месяц для 30 команд, включая 4 ПБ хранения и 18 млн минут запросов. Как построить FinOps-контроли без блокировки поставки?
queriesdesignfinops
46
Двадцати командам нужны dev, test и prod среды data-платформы в двух регионах, а регулируемые ресурсы требуют воспроизводимых доказательств одобрения. Как структурировать Terraform?
reproducibilityterraform
47
Шесть команд спорят о Delta и Iceberg для multi-engine lake на 3 ПБ, решение нужно за три недели. Как провести процесс RFC и ADR?
conflictdecision-makingconcurrency
48
Новая платформа контрактов технически готова, но ее используют только 3 из 16 доменов, а за два квартала нужно достичь 80% миграции. Какой план архитектурного внедрения вы возглавите?
decision-makingmigrationsarchitecture
49
На ревью предлагаемого customer lake на 500 ТБ три архитектора уровня middle выбрали разные стратегии партиционирования и identity, а дизайн нужно одобрить за пять дней. Как провести менторство в ревью?
mentoringdesignpartitioning
50
Продукт customer-360 должен обслуживать 1 000 аналитиков и 35 операционных APIs с аналитическими запросами до 5 секунд и API-чтениями до 100 мс по 2 млрд профилей. Как спроектировать serving architecture?
designapiqueries
51
Счет за lakehouse за месяц вырос со $180 000 до $410 000, хотя объем запросов увеличился всего на 12%; что вы сделаете в первые сутки?
querieslakehouse
52
В 09:00 задержка дашбордов Snowflake выросла с 8 до 95 секунд, а расход кредитов утроился для 300 аналитиков; как вы отреагируете?
snowflakelatency
53
Новый дашборд BigQuery после релиза сканирует 1,6 ПБ в день и добавляет $8 000 к ежедневному счету; какие доказательства и ограничения вы используете?
bigquery
54
В кластере Redshift из 12 узлов диск на двух узлах заполнен на 100%, а на остальных менее чем на 45%, и ночная загрузка нарушает SLA к 06:00; как вы поступите?
soft-skillsredshift
55
Lag Kafka consumer на топике заказов вырос с 20 000 до 14 миллионов записей за 25 минут, хотя producer throughput не изменился и составляет 90 000 событий в секунду; каков ваш план?
zero-to-onekafkathroughput
56
Одна из 120 партиций Kafka получает 38% всех платежных событий после запуска крупного продавца, а задержка достигает 11 минут; как устранить hot partition без потери порядка?
partitioningkafkalatency
57
Группа Kafka consumer на 240 партиций после деплоя выполняет rebalance каждые 3 минуты, а доступность обработки падает до 62%; что вы проверите и измените?
partitioningkafkadeployment
58
После failover базы данных в CDC возник разрыв на 47 минут, затронувший около 6,2 миллиона обновлений клиентов; как восстановить данные, не перезаписав более новое состояние warehouse?
databasewarehouse
59
Перезапуск коннектора продублировал 18 миллионов CDC-событий и завысил дневную выручку на 7%; как локализовать и исправить инцидент?
incidents
60
CDC-пайплайн 12 дней игнорировал удаления, и в аналитике осталось 3,4 миллиона якобы удаленных профилей; как вы отреагируете?
ci-cd
61
Слоты репликации Debezium удерживают 4,8 ТБ WAL PostgreSQL, а production-диск заполнится через 3 часа; что вы сделаете?
postgresreplication
62
Изменение watermark Flink с 30 до 5 минут отбрасывает 2,1% мобильных событий в регионах с плохой связью; как восстановить корректность?
63
Spark join обрабатывает 9 ТБ, но одна задача выполняется 74 минуты при медиане в 80 секунд; как вы диагностируете и исправите это?
joinsconcurrency
64
После роста входных данных с 3 до 5 ТБ Spark-пайплайн теряет executor из-за OOM, а три retry уже потратили 900 core-hours; каков ваш следующий шаг?
ci-cd
65
Планирование запроса Iceberg теперь занимает 42 секунды, потому что в таблице 310 000 snapshot и 18 миллионов записей manifest; как безопасно восстановить производительность?
queriessnapshotperformance
66
Стриминговые job ежедневно записывают в таблицу Iceberg 40 миллионов файлов по 20 КБ, из-за чего p95 запросов вырос с 12 секунд до 4 минут; что вы измените?
queriesstreaming
67
Два job Delta Lake одновременно обновляют одни и те же 60 партиций, создают 1 900 конфликтов commit в час и задерживают балансы клиентов; как решить проблему?
partitioningconcurrency
68
Обновление формата таблиц на 900 ТБ данных lake приводит к ошибке разрешения схемы у 14% legacy-reader; как управлять инцидентом?
incidentsschema
69
Ошибочная трансформация записала отрицательное количество в 28 миллионов строк запасов за шесть часов, и downstream пополнение начинает создавать неверные заказы; что вы сделаете?
70
После частичного перезапуска в SCD2-измерении клиентов появилось 640 000 пересекающихся диапазонов действия, из-за чего заказы присоединяются дважды; как это исправить?
joins
71
После добавления новой CRM в hub Data Vault появились 2,3 миллиона дублей клиентов, потому что новый источник иначе нормализует бизнес-ключи; как вы отреагируете?
normalizationbusiness-keyssecrets
72
Загрузка satellite Data Vault каждую ночь создает новую версию для 92% строк, хотя источник меняет в среднем 3%; как вы это диагностируете?
secretsdata-vault
73
Таблица PIT Data Vault отстает на восемь часов после того, как incremental job пропустил поздние записи satellite, и 70 финансовых marts показывают старый статус счетов; как восстановиться?
secretsdata-vault
74
Частичное обновление dbt изменило только 4 из 11 upstream-партиций, оставив месячную модель маржи внутренне несогласованной на $2,7 миллиона; что вы сделаете?
dbtpartitioningcss
75
Producer меняет order_id со string на integer, и 23 модели dbt нарушают контракты за два часа до отчета руководству; как вы отреагируете?
dbt
76
В Airflow накопилось 18 000 задач в очереди после замедления базы scheduler, а до SLA отчетности в 07:00 осталось 90 минут; как расставить приоритеты восстановления?
airflowdatabaseprioritization
77
Команда запускает Airflow backfill за 180 дней, создающий 240 000 задач и лишающий ресурсов ежедневные пайплайны восьми доменов; что вы сделаете?
airflowci-cdbackfill
78
Финансы показывают квартальную выручку $84,2 миллиона, а продуктовый семантический слой показывает $87,9 миллиона за пять часов до обзора результатов; как вы организуете устранение расхождения?
semantic-layer
79
Команда checkout без предупреждения удаляет nullable-поле promotion, ломая 31 потребителя в четырех доменах во время кампании с 22 000 заказов в минуту; что вы сделаете?
80
В регуляторном отчете обнаружена неверная сумма, но column lineage обрывается на хранимой процедуре, которую используют 46 downstream-моделей, а срок подачи завтра; что вы сделаете?
schemastored-proceduresestimation
81
У критичной таблицы клиентов нет владельца в каталоге, есть 17 устаревших определений, а upstream-команда планирует удалить ее через 48 часов; как устранить провал governance?
data-governancesoft-skills
82
Маркетинговый экспорт случайно включает email и дату рождения 1,8 миллиона пользователей и остается доступным 37 минут; каковы ваши первые действия?
83
Регрессия row access policy Snowflake позволяет 14 региональным менеджерам запрашивать записи всех 26 регионов в течение 22 минут; как вы отреагируете?
queriessnowflake
84
Аудит GDPR-удалений обнаруживает 4 200 пользователей, которые удалены из операционных баз, но через 45 дней остаются в snapshot Iceberg и трех производных marts; что вы сделаете?
databasesnapshotgdpr
85
После изменения порога MDM-модель ошибочно объединяет 62 000 домохозяйств, из-за чего бонусные баллы переходят между клиентами; как восстановиться?
86
Домен data mesh четвертую неделю публикует данные о запасах с опозданием на шесть часов, нарушая продуктовый SLA в 30 минут для 12 команд; как вы вмешаетесь?
data-mesh
87
Репликация warehouse между регионами отстает на 9 часов из-за деградации сети, а secondary-регион служит источником регуляторной отчетности; что вы сделаете?
replicationwarehouse
88
Квартальный DR-тест провален: каталог lake восстанавливается за 18 минут, но 27% путей таблиц указывают на недоступное региональное хранилище при RTO в 60 минут; что вы измените?
89
Мультиоблачный пайплайн начинает перемещать 2,4 ПБ в месяц между провайдерами, а стоимость egress вырастает до $190 000, в шесть раз выше прогноза; как это сдержать?
ci-cd
90
Общий warehouse использует 92% compute в рабочее время, спрос растет на 8% ежемесячно, а закупке нужно 10 недель для расширения; какое решение вы примете на этой неделе?
procurementcapacitywarehouse
91
Во время переключения с on-premises на cloud число строк в cloud ниже на 0,4% среди 18 миллиардов транзакций, а окно остановки заканчивается через 70 минут; продолжите ли вы?
transactions
92
После слияния два customer master связывают один national ID с 11 000 конфликтующих юридических лиц, а отдел продаж хочет единое представление через две недели; что вы сделаете?
93
Провайдер managed data catalog недоступен 11 часов и блокирует согласование схем для 140 пайплайнов, хотя runtime-данные исправны; как продолжить работу?
data-catalogschemaci-cd
94
Провайдер предлагает proprietary-функцию стриминга, снижающую задержку с 8 минут до 20 секунд, но она привяжет 260 пайплайнов к его формату перед запуском через девять месяцев; одобрите ли вы ее?
procurementlatencystreaming
95
Стриминговое представление балансов расходится с ночным ledger на $1,3 миллиона по 0,06% счетов после изменения retry policy; как провести сверку?
resiliencestreaming
96
Источник незаметно перестает передавать один код страны, из-за чего теряется 9% дневных заказов, но data-quality алерт не срабатывает 14 часов; что вы измените?
alerting
97
Новый observability rollout отправляет 6 800 алертов качества данных в день, 97% из них исчезают сами, и on-call пропускает реальный дефект payroll; как исправить систему?
observabilityalertingsystem-design
98
На review за два дня до запуска вы находите Python ingestion service, который загружает 600 миллионов строк через SQL, собранный строками, без границы транзакции и идемпотентности; команда говорит, что тесты проходят, какое решение вы примете?
sqltransactionsidempotency
99
Архитектор данных middle-уровня одобряет изменение партиционирования, после которого таблица на 90 ТБ недоступна для запросов 40 минут; как вы будете его менторить при восстановлении сервиса?
mentoringpartitioning
100
CFO просит пропустить сверку и запустить мигрированную платформу выручки к закрытию квартала, принимая расхождение до 1% от $420 миллионов; что вы скажете и сделаете?
react

Вопросы

2Производитель хранит 4 ПБ файлов с датчиков, выполняет 20 000 SQL-дашбордов и обучает 80 моделей при SLA аналитики 15 минут. Вы выберете warehouse, lakehouse или оба варианта?

3В финансовой компании 900 аналитиков, 12 000 управляемых SQL-запросов в час, мало специалистов по Spark и запуск через шесть месяцев. Вы выберете Snowflake или Databricks?

5Компания должна открыть 2 ПБ lake-таблиц для Spark, Trino, Flink и двух облачных провайдеров без привязки к поставщику. Вы стандартизируете Delta Lake или Apache Iceberg?

6Тридцать команд публикуют 600 таблиц через bronze, silver и gold слои, а потребителям нужен SLO свежести 99,5%. Какие контракты вы зададите между слоями medallion?

8У логистической компании 40 типов событий, опоздание данных до 15 минут, SLA трекинга 5 секунд и всего восемь платформенных инженеров. Вы выберете Lambda или Kappa?

12Spark каждую ночь уплотняет 80 ТБ Iceberg-таблиц, Flink записывает 20 000 обновлений в секунду, а читателям нужны согласованные снимки. Как скоординировать топологию?

15Маркетплейсу нужны чтения профиля быстрее 20 мс, ad hoc анализ 3 ПБ, полнотекстовый поиск по 500 млн объявлений и неизменяемый аудит. Как выбрать технологии хранения?

17Ядро Data Vault содержит 12 лет истории продаж, но 1 200 аналитикам нужны ежедневные запросы выручки быстрее 5 секунд. Как построить размерные витрины без второй истины?

18В компании 18 продуктовых команд в commerce, fulfillment, finance и customer support с общими данными клиентов и заказов. Как провести границы доменов data mesh?

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