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]: Остаются ли критические метрики во входных данных неизменными при разных загрузках?

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

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

4️⃣ Определи источник истины (Source of Truth - SOT) и проследи за его использованием

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


⭐️ Определение метрики SOT: Определи метрику на слое витрины данных (управляемой командой обработки данных). Наличие метрик, определённых в одном месте и используемых заинтересованными лицами, гарантирует, что все используют одну и ту же метрику.

⭐️ Данные SOT: Заинтересованные лица должны (в идеале) использовать только данные из слоя витрины данных. Данные SOT гарантируют, что все заинтересованные лица будут видеть согласованные данные. Если они используют данные из какой-либо таблицы фактов и измерений, убедись, что они знают логику объединения и возможные фильтры.

⭐️ Происхождение данных SOT - Data Lineage: Убедись в том, что ты отслеживаешь, какие команды используют данные из слоя витрины данных. Такая прослеживаемость позволит заинтересованным лицам устранить несоответствие между метриками, которое может возникнуть между их информационными панелями. Например, dbt data lineage

5️⃣ Держи заинтересованных в курсе событий для достижения более существенного эффекта


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

Четыре шага, которые позволят тебе максимально увеличить шансы на создание эффективного хранилища данных:

✔️ Потребность или боль: Прежде чем строить/улучшать хранилище, убедись в наличии сильной потребности/боли. Например, данные разбросаны по нескольким базам данных и не могут быть легко проанализированы вместе; аналитические запросы могли бы быть быстрее и повлиять на производительность производства, стратегию данных для компании и т.д. Если потребности в хранилище нет, большинство руководителей будут рассматривать твою работу как источник трат.

✔️ Информированность: Члены команды, не являющиеся специалистами по работе с данными, должны знать, что ты создаёшь и какую проблему решаешь. Обеспечь рассылку электронных писем, демо роликов и т.д., чтобы люди знали о проекте. Если люди спрашивают о дополнительных возможностях/новых наборах данных, это хороший знак, так как он свидетельствует об интересе людей к тому, что ты создаёшь. Ещё один момент, на который следует обратить внимание - согласованность действий команд, особенно команд, работающих над проектом. Убедись, что все необходимые команды (обычно это команды, занимающиеся разработкой и конечными пользователями) согласны с концепцией хранилища.

✔️ Определение ожиданий: Очень важно определить, что и когда ты будешь делать. Тебе будет трудно составить точный график, лучше всего использовать оценки с дополнительным буфером времени в 20-40% (в зависимости от отсутствия ясности). Осуществляй поставки решения итеративно, по бизнес-подразделениям, по наборам фактов/тёмных таблиц и т.д. Не жди, пока не будет готово всё хранилище. Предоставляй периодические обновления и держи заинтересованные стороны в курсе событий с помощью электронной почты, JIRA и т.д.

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

6️⃣ Следи за "красными флагами" на уровне организации 🚩


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

🚩Отсутствие заинтересованности руководства: Если руководство не заботится о данных, ситуация не изменится.

🚩Постоянные реорганизации: Ты будешь перегружен работой, проекты могут быть сокращены, моральный дух будет низким и т.д.

🚩 Отсутствие команды по работе с данными: Если ты являешься первым сотрудником, если ты не нанят для создания команды по работе с данными и знаешь, что руководство высоко ценит данные, не присоединяйся (или не уходи).

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