Каждая компания генерирует, обрабатывает и хранит данные. Маленькие компании пользуются excel-табличками, компании побольше – огромные хранилища данных и команды, которые их обслуживают.
«Данные – это новая нефть.» Клайв Хамби
![](https://habrastorage.org/getpro/habr/upload_files/b00/6ca/ed6/b006caed658d019089fe87b49fb39b09.png)
Меня данные тоже не обошли стороной: я собираю количественную мотивацию по новой задаче, выбираю решение, опираясь на статистику, после релиза проверяю успешность фичи. За 3 года работы в Контуре я написала бессчетное количество SQL-запросов, сделала несколько дашбордов в Redash, описала десятки фронтовых и бэковых метрик в постановках и сломала свой мозг в попытках понять, как добывать данные из Касандры.
Работать с данными – это классно, но если они некачественные, то и результат работы получается такой же. И идти до результата приходится долго. Но оказывается, много проблем можно решить с помощью data governance.
В этой статье я расскажу: что такое data governance, какие проблемы поможет решить data governance и как применить data governance на практике.
Начнем с определения
Data governance (DataGov) – это система по управлению данными, которая обеспечивает высокое качество, доступность, целостность и безопасность данных в организации.
Сразу хочу оговориться, что data governance – это масштабная, всеобъемлющая область, которая позволяет выстроить процессы и подходы работы с данными на разных уровнях. Поэтому я считаю, что каждый аналитик тоже может влиять на data-культуру и использовать подходы DataGov в масштабе своей команды и в разрезе своих задач.
Перед тем как узнать, как применять DataGov, давайте на примерах разберем, что болит у аналитика при работе с данными.
Какие проблемы бывают с данными
![](https://habrastorage.org/getpro/habr/upload_files/0df/21c/f75/0df21cf75861e24eb3d36e6a7bed6982.png)
1. Данных нет или их недостаточно
Раскатали фичу, но логи писать не стали. Как результат – не можем посчитать метрики и ответить на вопрос, взлетела ли фича, сложно проводить раскопки при факапах.
2. Данные есть, но они некачественные
В поляшку таблицы БД договорились писать строку в формате JSON. Волей случая разработчик поставил лишнюю кавычку и теперь в БД стали улетать невалидные JSON’ы. Получается, что данные есть, но распарсить и работать с ними проблематично.
3. Данные есть, они качественные, но их сложно достать
Команда находится в процессе переезда с MS SQL на PostgreSQL. Аналитику (мне) нужно сопоставить данные из разных СУБД. Как это сделать «красиво» – я понятия не имею. Все, что приходит в голову, – положить результаты запросов из разных источников в одну excel-табличку и колдовать. Большие объемы данных так не обработать.
4. Разночтение данных / отсутствие единого подхода
У нас в компании, как и в многих других, нет консенсуса по многим базовым определениям – клиент, лид, баланс и т. д. Это приводит к тому, что в разных отчетах, дашбордах и других артефактах данные могут расходиться, а любой разговор с человеком из другой команды я начинаю с того, что определяю, какой смысл каждый из нас вкладывает в одни и те же слова.
5. Долгий поиск данных
Аналитик может потратить 30-50% рабочего времени на поиск данных. Получается, что высокооплачиваемые специалисты тратят только половину рабочего времени на решение своих прямых задач. Это невыгодно бизнесу.
Да, в хранилище и табличках своего продукта аналитик, скорее всего, разбирается. Но лично у меня в работе всё чаще появляются сквозные интеграционные межпродуктовые задачи. И тут аналитику уже нужно лезть в чужой огород данных. Нет понимания, где их искать, поэтому приходится идти долгим путем: спросить знающего коллегу, написать в мотермост-канал продукта (подробно описать, что вам нужно достать и для каких целей), а потом ждать, пока до вашего вопроса доберется дежурный.
Это не все проблемы, которые несет в себе недостаточный уровень data-культуры. Есть еще утечка данных, нехватка железа и другие.
О data governance
После того, как мы прочувствовали всю боль, которую может причинить работа с данными, хочется дополнить приведенную выше цитату Клава Хамби:
«Данные – это новая нефть. Они могут быть такими же токсичными, если ими не управлять.»
![](https://habrastorage.org/getpro/habr/upload_files/a59/9a0/69e/a599a069edabee90a86498bceb539b7a.png)
Поэтому важно научиться осознанно работать с данными. Эту цель ставили перед собой разные компании. Они пробовали разные подходы. Эволюционным путем индустрия пришла к тому, что сложился единый подход data governance, который агрегирует весь накопленный опыт.
Data governance состоит из 10 выделенных областей, в сторону которых можно развивать компанию/продукт. Все направления важны и нужны, но это не значит, что нужном разом прокачивать все. Эффективнее будет:
Понять, что из себя представляет каждое направление и зачем каждое из них нужно
Оценить, на каком уровне каждое направление сейчас
Приоритизировать направления с точки зрения трудозатрат и профита
Действовать!
![](https://habrastorage.org/getpro/habr/upload_files/95f/b53/84b/95fb5384b8b42d02d35b7cab0f72d987.png)
Конечно, такая работа, даже на уровне команды, – это трудоемкий процесс, требующий компетенции и заинтересованности от всех ее членов.
Хорошая новость в том, что некоторые идеи и подходы DataGov можно начать применять уже сейчас, они помогут снять часть проблем при работе с данными.
Полезные советы
Лучше собирать лишние данные, чем страдать от того, что их не хватает.
Хорошая практика – подумать на этапе аналитики о том, какие данные и для чего хочется собирать в рамках задачи.
Чтобы не забыть подумать, можно зашить блок «Метрики» в шаблон постановки. Именно так сделали мы в моей команде:
![](https://habrastorage.org/getpro/habr/upload_files/d2c/75f/341/d2c75f34121e6009d87c54febc5c07e9.png)
Полезно иметь правила по описанию данных/процессов/метрик. Важно, чтобы они были понятные и лаконичные.
Полезно следовать правилам и описывать данные/процессы/костыли на wiki или в других артефактах, которые создает ваша команда.
Полезно поддерживать единообразие в названиях. Это упрощает поиск. Например, у нас в команде есть статья о том как давать названия метрикам, которая призывает аналитика поумерить свое креативное мышление и диктует требования к названию:
![](https://habrastorage.org/getpro/habr/upload_files/947/537/e2b/947537e2bd57703467b85e8aff716114.png)
Описывать таблички и поляшки в них можно прямо в БД, такая возможность есть во многих СУБД. Это поможет лучше ориентироваться в ваших табличках вам самим, новым членам команды и людям из других команд. Добавить описание к таблице, как правило, можно с помощью SQL-запроса.
Полезно фиксировать, как рассчитывался тот или иной показатель, чтобы другой человек мог это воспроизвести. Да и через какое-то время вам самим это поможет вспомнить, откуда взялись цифры.
Можно создать автоматический справочник, в котором будут лежать все метрики/данные. Это позволит ускорить поиск. Мы в команде реализовали его с помощью дашборда в Redash, в котором выведены все метрики, которые пишем. На дашборде есть возможность поиска по названию, выведена дата первой и последней записи по каждой метрике и есть возможность посмотреть пример записи по любой метрике. Как это выглядит:
![](https://habrastorage.org/getpro/habr/upload_files/de1/f30/a0b/de1f30a0b38f82be2b621a33c147d429.png)
Подведем итоги
Чтобы данные работали на нас, нужно ими управлять. Делать это можно в масштабах целой компании, а можно локально в своей команде и продукте. Системный аналитик трогает данные в своей работе, а значит, может влиять на уровень зрелости data-культуры.
Я приоткрыла дверь в дивный мир с data governance и засунула туда свой любопытный нос. Теперь я по-другому смотрю на процессы, связанные с управлением данными в своей работе, понимаю их важность, осознаю проблемы и знаю, как подобраться к их решению.
А начать можно с маленьких шагов. Следуя незамысловатым советам, мы сделаем свою работу с данными и работу коллег удобнее.
BogdanPetrov
Первый пункт из Полезных советов на мой взгляд спорный. Это две отдельные проблемы, которые не обязательно противопоставлять. А вот второй пункт отлично дополняется цитатой из той же DAMA DMBOK