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

Analytics Engineer превращает исходные данные из хранилища в проверенные и документированные модели, которыми можно пользоваться единообразно.

• Дата-инженеры обычно строят загрузку данных и платформенную инфраструктуру, которая доставляет данные в хранилище.
• Аналитики данных обычно интерпретируют подготовленные данные, отвечают на вопросы и создают отчёты.
• Analytics Engineer отвечает за слой моделирования между ними с помощью SQL, dbt, проверок, документации и контроля версий.

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

• Факты представляют события или процессы, например заказы, платежи или просмотры страниц.
• Измерения описывают сущности, например клиентов, товары, каналы и даты.
• Такая структура обеспечивает понятную и единообразную фильтрацию, группировку и агрегацию.

Схема «звезда» размещает таблицу фактов в центре и напрямую соединяет её с таблицами измерений.

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

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

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

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

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

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

• Измерение клиента может включать сегмент, страну, канал привлечения и статус.
• У измерения обычно есть ключ, на который ссылаются одна или несколько таблиц фактов.
• Его атрибуты дают названия, фильтры, группы и иерархии, а не меры событий.

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

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

Мера является числовым свойством факта и считается аддитивной, если её сумма по подходящим измерениям сохраняет смысл.

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

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

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

Согласованное измерение является общим измерением с едиными ключами и определениями для нескольких таблиц фактов или процессов.

• Общее измерение клиента может использоваться для продаж и обращений в поддержку.
• Единые атрибуты обеспечивают одинаковый смысл фильтров и групп в разных отчётах.
• Согласованность позволяет сравнивать данные без повторного определения бизнес-понятий в каждой витрине данных.

Измерение даты задаёт единый календарный словарь для анализа фактов во времени.

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

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

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

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

• Одна строка может представлять дневной остаток по счёту или недельный запас товара.
• Её гранулярность включает наблюдаемую сущность и период снимка.
• Меры снимка часто полуаддитивны, потому что сумма повторяющихся состояний по времени вводит в заблуждение.

Накапливающая таблица фактов-снимков отслеживает один экземпляр процесса через несколько этапов.

• Строка может представлять заказ от создания до оплаты, отправки и доставки.
• Даты этапов и поля статуса обновляются по мере продвижения процесса.
• Её гранулярность составляет одну строку на экземпляр процесса, а не на этап.

Тип 1 перезаписывает изменившийся атрибут, а тип 2 сохраняет историю, создавая новую версию строки.

• Type 1 подходит для исправлений или атрибутов, чьи прошлые значения не важны для анализа.
• Type 2 использует даты действия, признак текущей строки или похожие поля для определения версий.
• Факты могут ссылаться на суррогатный ключ, действовавший в момент события.

Полезный логический порядок выглядит так: FROM и JOIN, WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY и LIMIT.

• FROM и JOIN формируют входные строки до фильтрации на уровне строк.
• GROUP BY создаёт группы, а HAVING фильтрует их до формирования результата.
• Оконные функции вычисляются после группировки и HAVING, но до окончательной сортировки результата.
• Псевдонимы из SELECT могут быть недоступны на более ранних логических этапах.

WHERE фильтрует строки до агрегации, а HAVING фильтрует группы после неё.

• Условие по дате или статусу исходных строк обычно относится к WHERE.
• Условие вроде COUNT(*) больше десяти относится к HAVING.
• Фильтрация через WHERE меняет набор строк, участвующих в каждом агрегате.

Для каждой выходной группы должно существовать одно однозначное значение каждого выбранного выражения без агрегации.

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

Большинство SQL-агрегатов игнорирует NULL, а COUNT(*) считает строки независимо от наличия NULL.

• COUNT(column) считает только строки, где столбец не равен NULL.
• SUM(column) и AVG(column) используют значения без NULL и могут вернуть NULL, если таких значений нет.
• Замена NULL на ноль допустима только тогда, когда ноль имеет корректный бизнес-смысл.

Раздувание строк при JOIN возникает, когда соединение создаёт несколько выходных строк для одной строки на уровне гранулярности меры.

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