Вредные советы при построении Аналитики (Data Lake / DWH / BI) – целеполагание и результаты
Всем привет! На связи Артемий Козырь — Analytics Engineer в Wheely.
Продолжаю серию публикаций в формате «вредных советов», целью которых является попытка обратить внимание на (не)лучшие практики и подходы в построении аналитических сервисов с реальными примерами и историями.
В этой публикации Вас ожидает:
Выполнение задач без четкого понимания целей — Question your customer;
Игнорирование оценки ожидаемых характеристик данных — Assess data expectations;
Пренебрежение документацией и пояснениями к коду — Ensure access and transparency.
Выполнять задачи без четкого понимания цели
Самая неблагодарная и неправильная работа. Аналитика — это способ принимать взвешенные и обоснованные решения. Чаще всего задачи ставятся бизнес-пользователями, которые имеют смутное представление о технических аспектах и возможностях систем аналитики — и это нормально.
Игорь, CTO в Wheely, в ответ на просьбу о фиче / доработке / запросе прав доступа всегда задаёт вопрос:
Чего ты хотел бы добиться этими действиями?
Почему это важно?
1. Ясные цели и задачи сокращают издержки.
Понятные требования автоматически фиксируют фокус на релевантных целях и действиях. И наоборот, нечеткие желания приводят к размытым результатам, которые вряд ли смогут кого-то обрадовать.
2. Понимание конечного результата позволит выбрать лучший путь к нему.
А это значит, что вы вправе выбирать пути решения, инструменты, технологии с высоты своего опыта или опыта своей команды. Главное — помочь решить бизнес-пользователю его задачу.
Что может пойти не так?
1. Работа вхолостую, в ошибочном направлении.
Иначе говоря, трата времени впустую. Выполнение деятельности, которая не принесет результата и не будет оценена. Искреннее недоумение у ряда инженеров могут вызывать вопросы типа «А чем же ты занимался?» или «А на что ты потратил эти две недели?».
2. Большое количество доработок, повторных итераций.
Один из самых неприятных моментов — возвращение задачи на доработку с ощущением того, что не был получен требуемый результат. После всех усилий и времени, которые Вы могли потратить на его реализацию.
Одно из следствий — творческое выгорание и потеря мотивации.
3. Микроменеджмент, попытка бизнес-пользователей говорить на техническом языке.
Попытка описать не просто результат, но и набор действий / шагов для его достижения.
Приведу интересную аналогию — высокоуровневый декларативный язык SQL, в котором Вы описываете, что хотите получить в результате выполнения запроса. Но не то, как произвести циклы вычислений, в каком порядке выполнить сканы и джоины таблиц. Все эти детали реализации отдаются на откуп парсеру, движку СУБД. Он знает это лучше.
Дайте каждому заниматься деятельностью в той сфере, в которой он силен.
Что делать?
1. Challenging your counterparty — задавайте вопросы
Например, для каждой задачи в таск-трекере Jira создайте шаблон, который обяжет заказчика четко сформулировать свои требования и ожидания:
Не стесняйтесь дискутировать, предлагать варианты и решения. Возможно, совместно будет найдено лучшее решение.
2. Договоритесь и имейте одинаковые ожидания до старта
Прежде чем делать, продумайте на два-три шага вперед то, что собираетесь делать. Прототипируйте быстро — получайте обратную связь сразу.
А далее делайте качественно и надежно, чтобы не возвращаться к исправлениям.
Я люблю работу и задачи, которые кому-то приносят пользу и помогают, оцениваются по достоинству. Таким образом заряжаюсь и я сам.
Игнорировать оценку ожидаемых характеристик данных
Кому-то привычнее называть это Data Quality, но сегодня я бы использовал термин Data Expectations Assessment — оценка ожидаемых характеристик данных.
Оценка не ограничивается базовыми вещами: not null, uniqueness, reference integrity, accepted values. Она вполне согласуется с тестированием распределения выборок, попадания значений в заданные интервалы, RegExp, результатов агрегатных функций (min, max, count distinct).
Почему это важно?
1. Страховка на случай незапланированных отклонений.
Конечно, страховка не сможет защитить от самого возникновения проблемы.
Но это хорошая попытка вовремя получить уведомления о том, что что-то где-то идёт не так. То есть тогда, когда проблема еще не стала глобальной, не повлияла на чьи-то решения и выводы. Хорошая практика — получать уведомления сразу в Slack или Telegram.
2. Быть в курсе проблемы до того как её обнаружит бизнес-пользователь.
Все допускают ошибки, и часто они происходят под воздействием внешних факторов. Важно показать свою позицию и ownership над этой проблемой. Уведомить участников и пользователей о том, что проблема известна и мы уже работаем над её исправлением, до того как этот вопрос будет задан самими пользователями.
Это не просто тактика реагирования — это показатель зрелости и ответственности команды за свои сервисы. Проактивная позиция — то, что помогает заслужить уважение и доверие пользователей.
Что может пойти не так?
1. Потеря доверия к аналитическим сервисам.
Постоянные проблемы с качеством аналитических сервисов подрывают доверие. Впоследствии даже простые и корректные отчеты могут вызывать вопросы и требовать ручной проверки.
2. Тяжелые последствия даже незначительных отклонений.
Одна дублирующая запись, например, в справочнике водителей, в ходе графа преобразований (DAG) может привести к сотням и тысячам лишних записей. В результате, витрина данных будет показывать недостоверные показатели в части финансовых результатов, что абсолютно недопустимо.
Что делать?
1. Сделайте тестирование ожиданий частью процесса разработки.
Именно так. Наравне с кодом новых интеграций и витрин данных выводите в эксплуатацию регулярное тестирование ожиданий.
Это может быть одним из требований к выводу новой функциональности. Например, посмотрите, как устроен Pull Request Checklist в dbtLabs:
2. Думайте об узких местах и формулируйте ожидания заранее.
Используйте все доступные возможности:
3. Не давайте багам повторяться. Только новые ошибки!
Не страшно, если ошибка всё же была допущена. Сделайте выводы и защитите себя от возникновения ошибок подобного рода в будущем.
Например, обнаружив проблему с пустой таблицей-справочником я добавляю ожидание непустой таблицы в будущем expect_table_row_count_to_be_between для всех таблиц:
- name: dim_cars
description: Wheely partners' cars.
tests:
- dbt_expectations.expect_table_row_count_to_be_between:
min_value: 100
...Оставлять скудные пояснения и документацию к функционалу
Отсутствие документации и комментариев к тому, какие задачи решаются в коде — одна из причин больших потерь в средне- и долгосрочной перспективе. Отсутствие документации на понятном языке = отсутствие прозрачности и полноценной картины сути.
Почему это важно?
1. Чистота, порядок, системность.
В первую очередь это важно для самого автора. С тем прицелом, чтобы вернувшись к коду через неделю-месяц-год сразу получить четкое понимание целей и назначения тех или иных разработок.
Например, таблица с расписанием и назначением dbt Jobs, которая ответит на все вопросы новичков:
Написание документации с современными инструментами может и должно приносить радость. Даже сейчас эту самую статью я пишу в блокноте Sublime с использованием языка разметки Markdown.
2. Низкий порог входа для членов команды.
Аналитические сервисы — это командная работа. Согласитесь, гораздо проще ввести человека в курс дела, показав наглядную диаграмму, список верхнеуровневых шагов, граф зависимостей моделей, описывающих логику преобразований, нежели чем сразу дать изучать сам код (порой весьма сложный и неоднозначный — смотри первую часть публикации).
3. Доступ к документации для бизнес-пользователей.
Каждый бизнес-пользователь вправе самостоятельно задавать вопросы, тестировать гипотезы, однако это представляется возможным только в том случае, если обеспечен простой и понятный доступ к данным, их взаимосвязям и специфике расчетов (Data democratization).
Значительной доли простых рутинных вопросов бизнес-пользователей, например «А как считается это поле?», «Откуда поступает этот атрибут?», будет возможно избежать, тем самым освободив ресурсы для фокуса на более сложные и приоритетные задачи.
Что может пойти не так?
1. Непрозрачность — отсутствие центра компетенций.
Сегодня код без документации — завтра legacy, с которым никто не хочет работать. Наследие, которое рано или поздно придется переписывать заново.
Концентрация знаний о какой-то области в одной голове — это плохо. К тому же, нередки случаи, когда люди оставляют команду.
2. Кратный рост ресурсов, затрачиваемых на поддержку и изменения
Каждое новое обращение к этой части функционала будет подразумевать затраты времени на то, чтобы вспомнить смысл и разобраться в коде. Как следствие, повышенная вероятность допустить новые ошибки и баги.
Что делать?
1. Начинайте разработку с документирования идеи и логики, визуальной схемы
Простое пояснение, суммирующее требования заказчика, формулы расчета показателей, логику трансформации данных. Подойдут в том числе и ссылки на странички в Notion/Confluence, Jira, Slack.
Используйте для этого возможности документации проекта dbt. Это полноценное веб-приложение с поиском и возможностью визуализировать граф зависимостей моделей.
В качестве живого демо рекомендую изучить Gitlab dbt docs — веб-приложение с документацией DWH Gitlab.
2. Актуализируйте документацию после получения ответов на вопросы
Я искал ответ сегодня и нашел его с трудом. Сделаю так, чтобы мой товарищ завтра не потратил своё время на поиск того же ответа — просто занесу его в виде комментария к атрибуту или витрине данных.
Понимание этих практик хотят видеть нанимающие менеджеры
Человек, осознащий ценность этих советов и следующий им — желаем и незаменим в любой команде.
Наступать на грабли полезно, но всё-таки приятнее учиться на чужих ошибках.
На live-сессиях я и мои коллеги делимся выстраданным опытом и практиками. Реальные специалисты отрасли, практические знания, проекты с использованием ресурсов Яндекс.Облака. Если Вам стало интересно, изучите программы и приходите на вебинары:
Также своими наблюдениями, опытом и практиками я делюсь в ТГ-канале Technology Enthusiast.
Если Вам понравился материал, голосуйте За, добавляйте в закладки, комментируйте насчет тем, о которых хотели бы узнать.
Спасибо!
