6 шагов, позволяющих избежать беспорядка данных в хранилище

📎 Введение

В большинстве компаний с данными полный бардак. Команды, отвечающие за работу с данными, сталкиваются с множеством проблем, таких как ручное редактирование таблиц, дублирование определённых метрик, некорректные исходные данные, отсутствие управления данными, отсутствие инфраструктуры и т.д. Если тебе в голову приходят такие мысли как:

Интересно, в каждой ли компании до сих пор царит неразбериха с данными?

Надеюсь найти лучшее место для работы с более совершенными методами обработки данных.

Верю в существование аналитических хранилищ, которые представляют собой сплошной кошмар.

Ищу работу в надежде найти мифическую “зрелую организацию”, где научусь всё делать правильно.

Считаю, что хранилище данных - это повсеместное дерьмо.

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

Рассмотрим шесть важнейших шагов по созданию (и поддержке) хранилища данных, которое предоставляет заинтересованным сторонам всё, что им может понадобиться, и при этом позволяет избежать бардака в данных.

0⃣ Шесть шагов, которые помогут тебе создать отличное хранилище данных. Хотя идеальным вариантом является последовательное выполнение этих шагов, в реальных проектах, возможно, придётся менять их в зависимости от конкретной ситуации или задачи.

Хотя некоторые из приведённых ниже разделов не являются техническими, их выполнение позволит команде разработчиков (например DE) получить больше ресурсов (времени и/или денег), что поможет тебе избежать путей, которые могут приводить к беспорядку в данных.

1️⃣ Понимай бизнес

Прежде чем приступить к проектированию любой системы, необходимо в первую очередь узнать, как твоя компания зарабатывает деньги. Понимание экономических аспектов деятельности компании, таких как её клиенты, партнёры и продаваемые продукты, имеет решающее значение для всего, что ты делаешь как инженер данных (DE).

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

🔘Что это за бизнес, как он зарабатывает деньги, куда тратит деньги?
🔘Что представляют собой субъекты бизнеса (например, продавец, покупатель и т.д.) и как они взаимодействуют друг с другом?
🔘Какие бизнес-процессы происходят (например, клики, оформление заказа, доставка и т.д.)?
🔘Какие данные используются для расчёта итоговых показателей компании? (KPI, метрики и т.д. на уровне компании)
🔘Что является наиболее приоритетным для бизнеса на следующий квартал, следующий год и следующие пять лет?

Хотя приведенные выше вопросы могут показаться простыми, чаще всего для ответа на них требуется несколько встреч (в зависимости от размера компании). Практически всегда отсутствует актуальная документация, и для понимания текущего и будущего планируемого состояния требуется беседа с менеджерами/инженерами по продукту.

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

Результатом этого этапа является создание концептуальной модели данных (CDM), представляющей взаимодействие бизнес-субъектов друг с другом.

Например, рассмотрим этот простой CDM для сайта электронной коммерции.

2️⃣Сделай данные удобными для использования с помощью соответствующей модели данных


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

Плохая модель данных - это боль в использовании и обслуживании, которая приведёт к появлению беспорядочных данных. Хотя существует множество способов моделирования хранилища, рассмотрим популярную модель размерности Кимбалла (Kimball). В современных системах данных существуют три основные концепции:


🟡Таблицы фактов и измерений:

🔘Под измерениями понимается таблица с данными для бизнес-субъекта (например, клиента, продукта, партнера и т.д.). Таблицы измерений обычно имеют имя dim_noun.

🔘Факты относятся к тому, как бизнес-субъекты взаимодействуют друг с другом в реальной жизни (например, клиент - закупки - продукт). Таблицы фактов обычно имеют имя fct_verbs. Основная идея заключается в том, чтобы хранить данные о реальном взаимодействии с минимально возможной степенью детализации - если клиент выкупает пять товаров, мы создаем одну строку для каждого взаимодействия клиента с товаром (это называется зерном таблицы). Наличие данных с минимально возможной зернистостью позволяет нам препарировать данные любым необходимым способом.

🟡Объединения (Joins): Таблицы фактов обычно объединяются с несколькими таблицами измерений. При наличии отношений "многие-ко-многим" между измерениями следует использовать таблицу-мост. Объединения между таблицами фактов являются сложной задачей - будь внимателен к стоимости запроса.

🟡Витрины данных с OBT (One Big Table): Витрины данных (data marts), как правило, представляют собой данные, представленные для конкретной вертикали бизнеса. Витрина данных может иметь одну или несколько OBT, которые формируются путём объединения таблиц фактов и измерений и агрегирования до требуемой степени детализации - при этом также производится расчёт метрик. Хотя заинтересованные стороны могут объединить таблицы фактов и измерений и получить данные, желательно предоставить им единую таблицу со всеми необходимыми колонками. Предоставление единой таблицы гарантирует, что все необходимые расчёты метрик будут находиться в одном месте (а не в огромном количестве BI-инструментов) и будут согласованы между различными группами заинтересованных сторон.

Дополнительным преимуществом хорошего моделирования данных является более простое построение их структуры.

Рассмотрим простую модель хранилища, показанную ниже. В этом потоке мы проверяем данные перед их использованием (и перед тем, как сделать их доступными для потребителей), правильно моделируем данные, имеем источник истинных данных и метрики для последующего использования, а также отслеживаем использование данных. На следующих шагах увидим, почему эти концепции являются критически важными.

В приведённом хранилище используем бронзовые/серебряные/золотые слои для постепенного преобразования данных.

3️⃣Для хорошего хранилища данных необходимы хорошие исходные данные

Какими бы хорошими ни были модель данных и пайплайны, если входные данные неверны, то данные в хранилище будут непригодны для использования (Garbage In, Garbage Out).

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

*️⃣Актуальность (свежесть) данных [Data Freshness]: Являются ли данные такими свежими, как ожидалось?
*️⃣Типы данных [Data Types]: Меняется ли тип входных данных? Были ли добавлены/изменены столбцы без уведомления команды обработки данных?
*️⃣Ограничения данных [Data Constraints]: Соблюдаются ли в исходных данных такие ограничения, как уникальность, отсутствие null-ов, отношения и перечисления?
*️⃣Отклонение размера данных [Data Size Variance]: Остаётся ли размер входных данных неизменным при разных загрузках?
*️⃣Отклонение метрик данных [Data Metric Variance]: Остаются ли критические метрики во входных данных неизменными при разных загрузках?

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

Никогда не используй плохие данные для построения моделей данных, независимо от реакции вышестоящих команд, поскольку ответственность за плохие данные будет лежать на тебе и только на тебе❗️