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

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

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

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

• Например, я начну с продаж в магазинах и связанных данных о клиентах и товарах, а не со всех данных ритейла сразу.
• Я перечислю исходные системы, владельца процесса, ожидаемые результаты и используемые бизнес-термины.
• Пополнение запасов и договоры с поставщиками я явно отмечу как не входящие в первую версию.
• До проектирования сущностей и связей я подтвержу границы на примерах вопросов для отчетности.

Они описывают один домен с возрастающей детализацией реализации.

• Концептуальная модель показывает главные бизнес-понятия, например Клиент, Заказ и Товар.
• Логическая модель добавляет атрибуты, ключи, связи и правила без выбора конкретной базы данных.
• Физическая модель определяет таблицы, типы столбцов, ограничения и индексы для конкретной платформы, например PostgreSQL.

Сущность представляет отдельный бизнес-объект, а атрибут описывает этот объект.

• Клиент и Счет являются сущностями, потому что бизнес отслеживает их независимо.
• customer_email и invoice_date являются атрибутами, потому что описывают сущность.
• Полезно проверить, нужны ли понятию собственная идентичность и связи с другими объектами.

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

• Один клиент может сделать много заказов, поэтому связь Клиент и Заказ имеет тип один-ко-многим.
• Один заказ может содержать много товаров, а один товар входить во много заказов, поэтому это связь многие-ко-многим.
• Обязательность тоже важна: у заказа должен быть клиент, но у клиента может не быть заказов.

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

• customers.customer_id может уникально идентифицировать каждого клиента.
• orders.customer_id может ссылаться на этот ключ, чтобы каждый заказ принадлежал существующему клиенту.
• Ссылочная целостность отклоняет некорректные ссылки и задает поведение при обновлении или удалении родительской строки.

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

• Код страны ISO подходит как естественный ключ, потому что он осмыслен и централизованно контролируется.
• Сгенерированный customer_id изолирует внутренние связи от изменяемого адреса электронной почты.
• Строка order_items может использовать пару order_id и line_number как составной ключ.

Первые три нормальные формы устраняют повторяющиеся значения и зависимости, которые относятся не ко всему ключу.

• Первая нормальная форма требует атомарных значений и отсутствия повторяющихся групп столбцов.
• Вторая нормальная форма устраняет зависимости только от части составного ключа.
• Третья нормальная форма устраняет зависимости между неключевыми атрибутами, например хранение сведений о postal_code в таблице Customer.

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

• Отчетная таблица может хранить customer_region рядом с каждой продажей, чтобы не выполнять повторяющиеся соединения.
• Цена решения состоит в дополнительном хранении и риске рассогласования скопированных значений.
• Я сохраняю нормализованный источник истины и документирую способ обновления денормализованной таблицы.

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

• Сервис заказов выполняет много коротких вставок и обновлений со строгой согласованностью.
• Хранилище сканирует и агрегирует миллионы строк продаж для анализа тенденций и дашбордов.
• Схемы OLTP часто нормализованы, а модели OLAP часто используют факты и измерения для удобного анализа.

Хранилище данных объединяет данные всей организации, а витрина обслуживает более узкую команду или предметную область.

• Хранилище может объединять продажи, финансы, поддержку и продуктовые данные с общими определениями.
• Маркетинговая витрина может предоставлять только модели кампаний, клиентов и конверсий.
• Витрина упрощает работу, но скопированным витринам нужны согласованные определения, иначе метрики начнут расходиться.

Озеро данных недорого хранит разные файлы, а lakehouse добавляет управление как у таблиц и надежную аналитику поверх этих файлов.

• Озеро может хранить сырые CSV, JSON, изображения и Parquet в объектном хранилище.
• Формат lakehouse, например Delta Lake или Apache Iceberg, добавляет схемы, транзакции и метаданные таблиц.
• Благодаря этим механизмам подготовленные данные озера можно надежно использовать в SQL-запросах и BI-инструментах.

ETL преобразует данные до загрузки в целевую систему, а ELT сначала загружает сырые данные и преобразует их внутри целевой платформы.

• ETL может защищать ограниченную целевую систему, отправляя только очищенные и подготовленные данные.
• ELT использует вычислительные ресурсы хранилища, например Snowflake или BigQuery, для преобразований.
• Выбор определяет место выполнения логики, но оба подхода требуют валидации и lineage.

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

• Ночной финансовый отчет может загружать все транзакции за вчера одним пакетом.
• Для выявления мошенничества платежные события могут требоваться за несколько секунд, что говорит в пользу потока.
• Потоковая обработка сложнее в эксплуатации, поэтому я не выберу ее, если бизнесу достаточно часовой или дневной свежести.

Schema-on-write проверяет и формирует данные до сохранения, а schema-on-read применяет структуру во время чтения.

• Таблица хранилища отклоняет строки, которые не соответствуют объявленным столбцам и типам.
• Озеро данных может сохранить сырой JSON и позволить каждому читателю позже выбирать и приводить поля.
• Schema-on-write улучшает согласованность, а schema-on-read сохраняет гибкость, но переносит работу и риски на потребителей.

Эти слои разделяют временную загрузку, историю данных в исходном виде и готовые для бизнеса наборы данных.

• Staging хранит временные файлы или таблицы, пока загрузка проходит проверку.
• Raw сохраняет значения источника с минимальными изменениями для повторной обработки или аудита.
• Curated применяет типы, правила качества, соединения и бизнес-определения для надежного использования.

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

• Факты продаж могут содержать quantity, revenue, date_key, product_key и store_key.
• Измерения Product и Store содержат названия, категории и местоположения для группировки фактов.
• Таблицы фактов обычно большие и узкие, а измерения меньше и содержат описательные поля.

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

• Звезда может хранить категорию и отдел товара в измерении Product ради простых запросов.
• Снежинка может разделить Product, Category и Department, чтобы сократить повторение атрибутов.
• Звезды проще для аналитиков, а снежинки уменьшают дублирование ценой дополнительных соединений.

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

• Одна строка может представлять одну позицию заказа, а не заказ целиком или дневной итог.
• Каждый ключ измерения и показатель должен описывать то же событие позиции заказа.
• Смешение гранулярностей может повторить итог заказа в каждой позиции и завысить сумму.

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

• Примеры включают одну позицию заказа, один платеж или один клик на сайте.
• Строки обычно добавляются по мере событий, а не перезаписываются как текущий снимок.
• Атомарные события затем можно агрегировать по дате, клиенту, товару и другим измерениям.