Как не ошибиться при создании Data Lake / DWH / BI
Представляем Вашему вниманию статью, главной целью которой является попытка обратить внимание на все тонкости и нюансы построения современных аналитических систем.
В ней мы поговорим о следующем:
- Решение задач без четкого понимания их истинных целей;
- Отсутствие должного внимания по отношению к оценке планируемых характеристик данных;
- Игнорирование важности составления документации и пояснений к коду.
Решение задач без четкого понимания их истинных целей
Не стоит забывать о том, что аналитика данных – это, в первую очередь, способ принимать взвешенные решения. Как правило, аналитические задачи формулируются пользователями, далекими от мира BI- систем, - и это нормльно.
В ответ на поступивший запрос прав доступа не стесняйтесь задавать дополнительные вопросы:
«А для чего он тебе/ Чего ты хочешь добиться?»
Почему это важно?
1. Четко поставленные и правильно сформулированные цели сокращают издержки, фиксируя фокус на том, что действительно важно;
2. Ясное понимание конечного результата помогает выбрать наиболее оптимальный путь к его достижению. Другими словами, Вы имеете полное право выбирать те инструменты и способы решения задач, которые считаете нужными (исходя из Вашего опыта работы/опыта работы коллег или партнеров).
Что может пойти не так?
1. Работа впустую или, другими словами, бессмысленная трата времени. Деятельность, которая не приносит желаемого результата, никому не нужна.
2. Слишком большое количество доработок/ итераций. Частое возвращение задачи на доработку - не самое приятное, что может быть. Особенно, с учетом сил и времени, которое Вы потратили на решение поставленной задачи. Старайтесь учитывать сразу все требования уже на самых ранних этапах работы над поставленной задачей;
3. Микроменеджмент или попытка описать не просто желаемый результат, но и алгоритм его достижения. Пример: высокоуровневый SQL, на котором Вы описываете, чего хотите добиться в результате запроса - но не то, как произвести вычисления или в каком порядке выполнить JOIN нескольких таблиц – это дело движка СУБД. Давайте каждому заниматься тем, в чем он действительно силен.
Что делать?
1. Задавать уточняющие вопросы бизнес-пользователям, обсуждать возможные решения. Пример: для каждой задачи в Jira создайте шаблон, который обяжет Вашего коллегу/руководителя четко сформулировать свои требования по следующим характеристикам: задача/ проблема; цель; ожидаемый результат; комментарии.
2. Договариваться «на берегу». Прежде чем начать делать что-то, продумайте свои последующие действия на 2-3 шага вперед. Как только предпримите какое-то конкретное действие - сразу же запросите обратную связь. А далее делайте упор на качество и надежность – так Вы сможете избежать большого числа исправлений и итераций.
Отсутствие должного внимания по отношению к оценке планируемых характеристик данных
Кто-то называет это Data Quality, кто-то - Data Expectations Assessment, но суть одна, речь идет об оценке ожидаемых характеристик данных, которая не ограничивается такими базовыми понятиями, как not null, uniqueness, reference integrity и т.д. Она отлично согласуется с тестированием распределения выборок, попаданием значений в определенные интервалы или получением результатов агрегатных функций (min, max, count distinct и т.д.)
Почему это важно?
1. Страховка на случай незапланированных отклонений. Безусловно, Data Expectations Assessment не сможет защитить Вас от факта возникновения проблем, но даст возможность вовремя получить уведомления о том, что что-то произошло не так (то есть не тогда, когда проблема уже стала глобальной). Совет: воспользуйтесь Slack или Telegram.
2. Старайтесь узнавать о проблеме до того, как её обнаружит конечный пользователь. Ошибаются все. Но в данном случае речь идет о том, чтобы признать свою ошибку и уведомить о ней своего коллегу/руководителя до того, как он сам об ней узнает. Это не просто тактика реагирования – это показатель Вашей зрелости и способности брать ответственность за свои действия. Проактивная позиция – это именно то, что помогает заслужить уважение и доверие окружающих Вас людей.
Что может пойти не так?
1. Потеря доверия к аналитическим сервисам. Проблемы с качеством результата Вашей работы, которые повторяются из раза в раз, в какой-то момент времени однозначно подорвут доверие к тому, что Вы делаете. Однажды может получиться так, что даже самые простые отчеты могут вызывать дополнительные вопросы и потребуют проверки вручную;
2. Серьезные последствия даже самых незначительных отклонений. Всего лишь одна дублирующая запись в ходе DAG может привести к сотням и даже тысячам лишних записей. В итоге Data Mart будет отражать нерелевантную информацию в части финансовых результатов, что абсолютно недопустимо.
Что делать?
1. Сделайте тестирование ожиданий неотъемлемой частью текущего процесса разработки. Как вариант, это может быть одним из главных требований к выводу новой функции. Пример: посмотрите, как в dbtLabs устроен Pull Request Checklist:
2)Заранее думайте об узких местах и формулируйте свои ожидания. В этом Вам могут помочь следующие инструменты и решения: source freshness (оценка актуальности данных); возможности Generic + Singular tests; тесты из модуля dbt-utils; модуль dbt-expectations (портирование The Great Expectations)
3)Не позволяйте багам повторяться. Повторимся, что ошибиться может каждый. Просто сделайте выводы и постарайтесь в дальнейшем не допускать подобных ошибок:
expect_table_row_count_to_be_between для всех таблиц:
- name: dim_cars
description: partners' cars.
tests:
- dbt_expectations.expect_table_row_count_to_be_between:
min_value: 100
...
Пример: Если Вы вдруг обнаружили проблему с пустой таблицей-справочником, добавьте ожидание непустой таблицы в будущем (expect_table_row_count_to_be_between) для всех таблиц:
- name: dim_cars
description: partners' cars.
tests:
- dbt_expectations.expect_table_row_count_to_be_between:
min_value: 100
...
Игнорирование важности составления документации и пояснений к коду
Полное отсутствие документации и комментариев к тому, какие именно задачи решаются в коде – одна из причин серьезных потерь в средне - и долгосрочной перспективе. Отсутствие документации на языке, понятном всем пользователям – это то же самое, что и отсутствие прозрачности текущих бизнес-процессов и полной картины в целом.
Почему это важно?
1. Чистота/порядок/системность. В первую очередь это нужно самому автору – если Вы захотите вернуться к коду через неделю/месяц/год, Вы сразу же поймете, о чем в Ваших разработках шла речь (на момент их создания). Пример: таблица с расписанием и назначением dbt Jobs, предназначенная для новичков:
2. Низкий порог входа для новых членов команды. Аналитические сервисы – это командная работа; ввести нового человека в курс дела гораздо проще, показав ему наглядную диаграмму/список верхнеуровневых шагов, нежели чем сразу же дать на изучение сам код.
3. Доступ к документации для пользователей. Каждый пользователь вправе самостоятельно задавать интересующие его вопросы, но это реализуемо только в том случае, если к корпоративным данным обеспечен простой и понятный доступ (Data Democratization). Если Вы сделаете это, то сможете избежать многих рутинных вопросов, освободив тем самым свое время для решения более сложных и приоритетных задач.
Что может пойти не так?
1. Отсутствие прозрачности = отсутствие центра компетенций. Помните о том, что концентрация знаний о чем-либо в одной голове – это всегда плохо;
2. Соразмерное увеличение ресурсов, затрачиваемых на поддержку и обновления. Каждое новое обращение к этой части функционала подразумевает временные затраты на то, чтобы вспомнить первоначальный смысл и разобраться в коде (что созвучно с повышенной вероятностью допуска новых ошибок и багов).
Что делать?
1. Начинайте разработку с документирования идеи/логики/визуальной схемы. Речь идет о простом и максимально понятном изложении, объединяющем все требования заказчика, формулы расчета и логику преобразования данных (подойдут ссылки на странички в Notion/Confluence/ Jira/ Slack, возможности документации dbt и т.д.)
Также рекомендуем Вам изучить Gitlab dbt docs (веб-приложение с документацией DWH Gitlab).
2)Обновляйте документацию по мере получения ответов на интересующие Вас вопросы. Если Вы сегодня искали ответ на какой-то вопрос и с трудом нашли его, позаботьтесь о том, чтобы завтра Ваш коллега сделал бы то же самое, только гораздо быстрее и легче – просто занесите его в виде комментария к атрибуту или Data Mart.
Если Вы освоите все эти советы и примените их на практике, Ваше руководство по достоинству оценит проделанную Вами работу!
