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-команды и других команд есть конкурирующие цели, необходимо решить их до начала работы над любой инициативой. Несогласованность целей приведет к проблемам, недоверию и токсичной рабочей обстановке. Если такая ситуация повторяется, возможно, пришло время искать новую работу.

🔥 Вывод


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

Напомню, что рассмотрели:

1. Понять суть бизнеса

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

3. Хорошие входные данные необходимы для хорошего хранилища данных

4. Определить источник истины (SOT) и проследить его использование

5. Держать заинтересованные стороны в курсе событий для достижения большего эффекта

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

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

⏩Как объяснить 5-тилетней девочке работу DDL под капотом:

Представь, что ты построила из лего большую замечательную коробку для хранения своих игрушек. Эта коробка упорядочивает твои игрушки: куклы в одном углу, машинки в другом, кубики в третьем и так далее. В SQL (языке запросов для баз данных) такие "коробочки" называются таблицами.


Теперь, чтобы что-то изменить в конструкции этой коробки, например, добавить еще один отсек или разделитель, тебе нужно использовать специальные блоки и инструменты. В мире баз данных это называется DDL, что означает "язык описания данных".


Давай разберемся, как работает DDL:


1️⃣ Создание новой "коробочки" (таблицы): Это как если бы ты взяла лего и построила совершенно новую коробку для других игрушек. В SQL ты бы написала команду "CREATE TABLE", чтобы создать новую таблицу.

2️⃣ Добавление или удаление отсеков (столбцов) в "коробочке": Если ты захочешь разделить один из углов на меньшие части, чтобы там можно было хранить, скажем, твои мелкие фигурки, это как добавление новых столбцов в таблицу. В SQL ты бы использовала команду "ALTER TABLE ADD COLUMN" или "ALTER TABLE DROP COLUMN" для удаления столбца.

3️⃣ Изменение разделителей (изменение структуры столбцов): Если ты решишь, что отделение для машинок должно быть больше, чтобы поместить еще больше машинок, это как изменение свойств столбца в таблице. В SQL для этого тоже используется команда "ALTER TABLE".

4️⃣ Удаление "коробочки": Если решила, что больше не нужна тебе эта коробка, ты просто разбираешь ее на части и убираешь блоки обратно в коробку с лего. В SQL для удаления таблицы есть команда "DROP TABLE".


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