Не потеряться в данных: оптимизируем аналитику с помощью DataHub
Как не потеряться в данных для аналитики?
Когда количество их источников ограничено, а аналитикой занимается пара человек, в целом всё понятно: обеспечить прозрачность вполне можно на уровне ведения документации (если заниматься этим ответственно).
Но что, если данных в компании много, они отличаются сложной структурой и поступают из разных источников? Едут и из MongoDB, и из PostgresSQL, и из MS SQL; при этом постоянно появляются новые продукты и направления, данных становится ещё больше. Документация по ним устаревает примерно в тот момент, когда заканчиваешь её писать.
Попутно растёт команда аналитиков — новым людям нужно рассказывать, что где лежит, откуда прилетает, какие есть особенности.
Упростить жизнь в такой ситуации призван Data Catalog, и в Сравни мы выбрали популярный вариант — DataHub. Под катом рассказываем, как меняется работа с данными для аналитики, когда в твоей жизни появляется визуализация потоков данных.
Привет, Хабр! Я Павел, Data Architect в Сравни. В начале этого года мы внедрили в компании DataHub — опенсорс-инструмент для визуализации потоков данных, от источников до отчётностей, который активно используется нашими аналитиками и дата-инженерами.
Система помогла нам упростить работу с зависимостями в данных, повысить их безопасность, эффективно вести и поддерживать по ним документацию, ускорить онбординг новых аналитиков в команду.
Ниже расскажу о нашем опыте применения DataHub и ситуациях, в которых инструмент может пригодиться. Надеемся, будет полезно продуктовым и дата-аналитикам; руководителям, нацеленным на выстраивание порядка в процессах и всем, кто интересуется актуальным тулингом для ИТ-команд. Поехали!
Отправная точка: фиксируем основные источники данных
Для начала — немного о специфике наших данных и том, откуда они поступают.
В Сравни мы делаем финансовый маркетплейс: предоставляем сервисы для онлайн-подбора и оформления ОСАГО, кредитов, проверки кредитного рейтинга и многое другое. Продукты отличаются моделью монетизации, пользовательским поведением и логикой данных. В этом смысле мы »20 разных компаний в одной». Соответственно, от каждого продукта собираем свой набор данных.
Есть общий для всех слой внешних данных: веб- и мобильной аналитики, CRM-маркетинга. Часть данных связана с платформенными сервисами, общими для всех продуктов — например, сервисом авторизации и регистрации или SMS-коммуникации.
Есть собственные каналы продаж вроде партнерской программы и агентского кабинета для работы по модели B2B2C (мы обращаемся к агентам, которые находят для нас клиентов). Есть внешние площадки, владельцы сайтов, разные сторы: Google Play, RuStore, сторы вендоров (Samsung, Huawei и так далее).
Все данные мы забираем в DWH, где они делятся на несколько уровней. Сначала идут сырые данные, затем — витрины данных, потом агрегаты. Наконец, эти данные могут использоваться для разных задач: создание отчётности, алерты по бизнесовым метрикам, сбор сегментов для CRM-маркетинга, анализ результатов A/B-тестов.
Возьмем конкретный источник, например, AppsFlyer — систему мобильной аналитики. Сотрудники работают с готовой витриной данных — плоской табличкой, куда они приходят и что-то считают. Но чтобы её собрать, требуется около 20–30 разных таблиц с сырыми данными. Установками по iOS, Android, органическими и не органическими установками, ретаргетингами, событиями и так далее. То есть речь об огромном массиве разнокалиберных данных. Здесь на сцену выходит DataHub.
Зачем нам понадобился DataHub
Почему вообще мы решили внедрять DataHub? Расскажу на примере.
Представьте, выходит на работу новый аналитик, дата-инженер, разработчик. Или кто-то из текущих сотрудников переходит на другой продукт или направление — со спецификой новой деятельности сотрудник пока не знаком.
Раньше приходилось проводить мастер-классы в зуме и рассказывать: «Эта табличка считает так, эти данные идут отсюда». Не самый удобный способ, поэтому в какой-то момент мы начали вести документацию в базе знаний. Со временем изменения вносились все менее регулярно, данные теряли актуальность, и про таблицу в базе знаний мы в итоге благополучно забыли.
С DataHub всё стало куда проще. Чтобы на этапе онбординга сотрудник быстрее освоился, мы предоставляем ему доступ к системе, где он может посмотреть весь путь от источника до Value. И быстро увидеть, с какими данными связан тот или иной отчёт: DataHub автоматически выстраивает его связи.
Здесь же доступны метаданные: где какая таблица находится, сколько в ней строк, когда было последнее обновление; прочитать базовое описание, посмотреть тег предметной области.
DataHub позволяет нам изучать структуру, разворачивать источники данных в слое, смотреть, откуда что забирается. Объяснить же всё это на словах, без объемной документации — непросто. Можно рассказать, где какой отчёт лежит и для чего он нужен, но весь масштаб — количество таблиц и их взаимосвязи — устно передать вряд ли получится. В этом смысле DataHub работает как точка входа в массив данных компании.
DataHub на практике: кейсы
Рассмотрим пример применения DataHub в Сравни: когда мы анализируем данные, начиная путь от конкретной продуктовой витрины.
Например, выбираем витрину Calculation_Osago. Видим, где она находится, название таблиц, количество строк; видим, что автоматически подтягиваются названия полей, тип данных, описание.
Во вкладке «Документация» — полное описание витрины, источники данных, частота обновлений и прочая важная информация. Можно нажать на источники и посмотреть их в репозитории.
Здесь же можно увидеть статистику по каждой таблице, чтобы делать профайлинг данных. По каждому полю приводится минимальное и максимальное среднее значение, медианное значение, количество NULLов, количество и процент уникальных значений. Например, можно проверить, есть ли дублирование строк: для этого нужно убедиться, что показатель Distinct уникального идентификатора (hash ID) равен 100%. Если это не так, значит, где-то есть дубль, и можно посмотреть, в чём проблема.
Далее — lineage, где отображаются все связи конкретной витрины. Если сперва мы проходили от отчётов до источника, то сейчас как бы упираемся в середину пути. Здесь видны все отчёты, связанные с витриной, при этом с ними могут работать разные аналитики. Если вдруг что-то стало неактуальным в бизнес-логике и нам нужно это удалить, можем проверить, кто работает с этими таблицами и не сломают ли наши манипуляции отчёт. И наоборот: видим, что из чего собирается.
Случается что-то с отчётом или с Telegram Bot — неважно, с любым куском аналитики, где нам кажется подозрительной та или иная метрика или значение. Например, локации отвалились или отображаются некорректно. В DataHub мы можем посмотреть, с чем связан отчёт, проследовать по всему пути и проверить, где данные не загрузились.
У DWH-специалистов, как известно, всё происходит по ETL-процессу. Благодаря алертам они вовремя узнают, когда данные должны были доехать, но не доехали, витрина не обновилась, и так далее. И вот мы поняли, что есть проблемы с локациями, выявили их, а теперь смотрим, что могло на это повлиять. Предупредили заказчиков: такие-то отчёты временно недоступны, поправим в такие-то сроки. DWH берут исходники DataHub, разворачивают его и интегрируют со всеми системами, которые используют наши аналитики. Дальше DataHub выстраивает все связи.
Это удобно и с точки зрения обновления. Например, мы удалили отчёт или схлопнули два отчёта в один. Не нужно вручную удалять его в DataHub, система сама проходится по всему пайплайну и ETL и периодически обновляется.
Похожим образом DataHub помогает в разрезе бизнес-аналитики. Расписываем коммуникационные витрины (столбцы, метрика, логика, ссылки на Git), подтягиваем зависимости к отчётам в Apache Superset: удобно и аналитикам, и пользователям отчётов. Если падают конкретные метрики, всегда можно проследить, в каких именно данных искать проблему (например, понимаем, что есть проблема с UTM-разметкой — и смело идем в CRM).
Как не потеряться в данных: волшебная таблетка
Резюмируя возможности инструмента, перечислю сценарии, в которых он оказался нам наиболее полезен.
Онбординг коллег. DataHub помогает быстро освоить контекст и понять, что где находится по части данных, не бегая по DWH и не опрашивая других аналитиков. Позволяет от аналитики углубиться в витрины, провалиться к данным или, наоборот, от данных пойти к аналитике. Помимо прочего, это помогает снизить bus factor — зависимость команд от знаний избранных опытных сотрудников.
Расследования: когда что-то пошло не так. И нам нужно понять, где именно. Для этого проходим в DataHub по всей цепочке.
Просмотр зависимостей. Если мы хотим удалить витрины, отрефакторить, переименовать или удалить поля — и убедиться, что ничего в итоге не сломается, можем заранее всё посмотреть. А также узнать ответственных по тем или иным данным. Один из наших недавних кейсов: перенос витрин данных на Greenplum. DataHub предоставил прозрачную картину того, откуда поступают данные в витрину; дата-инженеры смогли чётко отследить, какие источники данных участвуют в процессе и безболезненно осуществили перенос.
Оптимизация процессов вокруг данных. С помощью DataHub можно, например, обнаружить, что множество отчётов смотрит на второй слой данных, и это работает не оптимально. Значит, для ускорения работы надо сделать для него отдельную витрину.
Поддержка документации. С DataHub можно создать и поддерживать живую документацию по всему процессу работы с данными, включая источники, трансформации, витрины и даже бизнес-логику. В условия большого количества различных данных, вести и актуализировать такую документацию может быть проще и удобнее, чем в том же Confluence.
Повышение безопасности данных. DataHub позволяет быстро выявить и оценить, кто и какие данные использует. Это помогает отслеживать доступ и минимизировать риски утечки или несанкционированного использования данных. В общем каталоге можно настроить разные уровни доступа, права. Например, можно закрыть доступ к персональным данным по требованию ИБ — и аналитики это поле не увидят, потому что оно для них не существенно.
Как понять, нужен ли вам DataHub?
Во-первых, оценить масштаб. Если аналитика в компании не слишком большая (это не столько про количество данных, сколько про структуру, сложность бизнес-логики) , внедрение DataHub может оказаться нецелесообразным. Нужно ведь поднимать целую систему, разбираться, настраивать. А выхлоп при этом может не нести значительной выгоды — «как микроскопом гвозди забивать».
Во-вторых, стоит перепроверить, как у вас в компании обстояли дела с прошлыми заходами на внедрение чего-то нового. DataHub предлагает причастным к работе с данными иначе вести дела —, а значит, потребуется много рассказывать, показывать. Приучать людей к мысли, что за данными нужно ходить на в лички и чатики, а в систему.
Оглянуться на опыт прошлых внутренних внедрений — поможет сформировать адекватные ожидания, в том числе по срокам.
Наконец, посмотреть, как в команде обстоят дела с инженерной культурой. Есть ли запрос на унификацию; насколько высоко ценится существование общей картины происходящего в процессах. Это может стать блокером. Помощь, о которой не просят — насилие.
В конечном итоге DataHub — никакая не волшебная таблетка. Можно и нужно пробовать другие системы; проверять, что лучше сработает для вас.
Главное — искать точки роста для работы с данными и соразмерять усилия и потенциальную выгоду от нововведений. Не бежать вперёд паровоза, но и не держаться за статус-кво, правильно выбирать момент для улучшений. А каким именно инструментом в итоге пользоваться — дело второстепенное.
