Для создания Data Lake нужен итерационный подход – agile и все, что с этим связано. Еще необходимо правильно организовать работу команд, синхронизировать их распределить ответственность между участниками. Тогда получится прямая связь между пользователями и людьми, которые развивают витрины данных или домены. В этой статье поговорим о задачах, архитектуре и проблемах развития Data lake, а также обсудим способы решения возникающих проблем, специфику процессов и перспективы развития.
Откуда берутся данные?
МТС – цифровая экосистема, строящаяся на фундаменте базового телекоммуникационного бизнеса с более чем 80 миллионами абонентов. Мы собираем обезличенные данные о нагрузке на базовые станции, информацию о звонковой и интернет-активности пользователей, цифры из салонов продаж и онлайн-магазинов, аналитику наших сервисов: МТС Банк, Мой МТС, МТС Music, онлайн-кинотеатр KION, МТС Библиотека.
Что такое Data Lake?
Под термином Data Lake обычно понимают массив неструктурированных данных, загруженных из источников «как есть». Мы придерживаемся более строгого определения и считаем, что Data Lake предназначен для интеграции информации из разных каналов, приведения их к одному знаменателю. Этот подход позволяет превратить сырую информацию в метрики, необходимые бизнесу. Другими словами, с нашей точки зрения Data Lake содержит и слои структурированных данных.
Data Lake – это еще и монетизация данных, поэтому тут очень важно получить Business Value. То есть соблюсти баланс между затратами на хранение данных и прибылью, которую эти данные дают. Иначе все это превратится из цифрового океана в информационное болото.
Какие задачи мы решаем?
Наша продуктовая техническая команда занимается интеграцией источников данных и внедрением архитектуры. Интегрировано уже примерно 40 петабайт данных из различных источников, также у нас около 1500 объектов и более 3000 процессов загрузки. Актуальная задача команды – разработка пользовательского профиля с учетом данных из различных источников. Данные, объединенные в клиентской области, позволяют принимать решения о дальнейшем развитии цифровых продуктов.
Еще одна важная задача – внедрение технической поддержки и предоставление SLA. Мало обеспечить доступ к данным, его нужно сделать качественным и предсказуемым. Для этого у нас есть технические и бизнес-проверки качества данных, линии поддержки. Долгосрочные цели – расширить коммунальное использование инфраструктуры Big Data и развитие культуры работы с данными.
Как менялась архитектура?
Пока не появилась Big Data – в ходу были системы управления базами данных (СУБД), в которых агрегировали информацию. Там не хранился исходный материал из источника, система приводилась к реляционному виду. СУБД трудны в расширении и дорогостоящи: нужно тратить значительные средства на команды, которые обслуживают эти системы, на покупку лицензий. Учитывая все увеличивающийся объем данных, многие ведущие компании перешли на Big Data-решения, основанные на Open Source. В том числе, это позволило хранить RAW-данные – «сырую» информацию из источников.
Мы собрали конструктор из Open Source-компонентов на основе стека Hadoop. С точки зрения архитектуры – это экосистема компонентов. Основные его достоинства: возможность хранения сырых данных и возможность параллелизма. Мы можем горизонтально масштабировать Hadoop и, в отличие от СУБД, он способен почти неограниченно расширяться.
Раньше было так – разработчики получали бизнес-требования пользователей, производили анализ данных, источников, прорабатывали архитектуру. Затем – постановка ТЗ и набора требований. Далее – сама разработка и сдача функционала заказчику.
После внедрения методологии разработки agile процесс кардинально изменился. Одно из важных изменений – построение прототипа. Для гибкой итеративной разработки необходимо предоставить доступ к решению, прототипу, MVP. Процесс динамический, поэтому пользователи могут ощутимо менять требования. Если мы не будем к этому адаптироваться – значит, мы не сделаем то, что нужно пользователям. Мы гарантируем качество данных и создаем соответствующие метрики. На нас лежит ответственность не только за готовый функционал, но и за его дальнейшее развитие и поддержку.
Как работают команды?
Есть соблазн сделать так, чтобы над проектом работала только R&D-команда. На ранних этапах развития Big Data так и было, сказывался дефицит специалистов. R&D-команды, которые непосредственно проводили исследования для пользователей, сначала узнавали, что нужно заказчику и формировали требования к функционалу. После того, как R&D-команда разработала прототип, его продуктивизировала другая команда. Здесь мог появиться эффект “испорченного телефона”, так как задача проходила через промежуточное звено. Это приводило к долгим коммуникациям и перерасходу ресурсов команды. Этого можно избежать, если R&D проходит параллельно с продуктивизацией.
Возьмем пример плохого развития событий (на иллюстрации выше он слева). Предположим, что у нас есть команда продуктивизации, которая работает по вотерфоллу. И есть R&D-команда, которая проводит исследования для бизнеса – они смотрят, из каких данных можно извлечь пользу, как их правильно интегрировать. А еще они делают модели данных, которые позволяют принимать решения, приводят к монетизации информации.
Предположим, что они сформировали прототип, который сейчас дает прибыль компании. Прототип – это ТЗ для Prod-команды. Она берет его и продуктивизирует в течение определенного срока. За это время условия могут измениться и тот прототип, который был сначала, денег не приносит. Соответственно, работа Prod-команды оказывается никому не нужной.
Здесь возникает необходимость в agile: когда обе команды итеративно синхронизируют требования с бизнесом и это приводит к созданию актуального для заказчика продукта.
Как выстроить архитектуру?
Изначально в МТС были классические хранилища: SAS и Teradata. Зачастую у данных был сложный цикл – сначала они поступали в SAS, трансформировались там, потом информация отправлялась в Teradata, а конечная витрина проходила через несколько этапов и предоставлялась потребителю в виде BI-отчета или простого отчета.
Когда мы планировали новую архитектуру Big Data, то поняли, что такой подход не слишком продуктивен. Любые технологии имеют свои ограничения. Кроме того, в такой сложной архитектуре точек отказа достаточно много. Так мы перешли к архитектуре с Hadoop, единым набором инструментов для сбора и трансформации данных, формирования витрин. Также в результате MPP-система стала презентационным слоем, никаких трансформаций в ней не производится. Все ETL-процессы проходят в одной системе.
Изначально в data lake значительный объем занимает слой RAW-данных – это зеркало источников. Для большого количества алгоритмов необходимо исследование “сырых” данных, потому что при трансформации и агрегации некоторые закономерности в данных теряются. В этом случае нужно обращаться к RAW-данным. Также этот слой пригодится и если мы сделали какую-то ошибку в витринах и необходимо перезагрузить в них данные.
Далее – слой DDS (detail data storage). Это слой детальный слой данных, в котором они распределены уже по бизнес-сущностям, которые необходимы конечному потребителю. Когда аналитикам нужно обратиться к детальным данным, им удобно пользоваться этим слоем, так как в нем отражена бизнес-модель.
Следующий слой – это коммунальные витрины данных, CDM (common data marts). В этом слое данные уже агрегированы и содержат метрики, которые считаются по определенным алгоритмам. Метрики нужны пользователям, их можно использовать для построения Data Science-моделей, для принятия решений или для BI-систем.
Как распределить ответственность?
Теперь поговорим о том, как положить процессы итеративной разработки на слои данных Data Lake. Это непростая задача, и всегда есть соблазн распределить ответственность по этим слоям. Суть в том, что когда мы разделяем ответственность по слоям, разработчикам удобнее иметь дело с определенным набором инструментов, шаблонов, которые специфичны для определенных слоев данных. Например, люди, которые с RAW, не хотят изучать остальные инструменты.
Поэтому можно выделить отдельные команды, ответственные за свой слой данных. Это удобно, но такое разделение команд приводит к проблемам с коммуникациями. Мы выделяем предметную область, в пределах которой одна команда отвечает за все слои данных. Также команда гарантирует пользователям, что данные будут в нужном для бизнеса виде и требуемого качества. Когда мы применили такой подход – количество инцидентов и коммуникаций уменьшилось. Это позволило развиваться дальше. И пользователи почувствовали изменения, они стали больше доверять данным, которые мы готовим.
В результате мы пришли к такому архитектурному ландшафту данных: у нас есть предметные области, есть продуктовые песочницы, в которых тот или иной продукт может создать свою область данных, трансформировать ее, и сделать что-то на основе наших витрин. Это нужно для процессов исследования данных. И есть еще презентационный слой, который сейчас копируется в Teradata. Это необходимо для распределения нагрузки между системами: одна выделена для процессов загрузки и трансформации данных, а MPP-система (Teradata) – для работы пользователей.
Как проверить работоспособность?
Кроме того что необходимо распределить ответственность по командам, нужно еще сделать общими методологии к работе с данными для того, чтобы система была контролируемой. Мы написали гайд, он называется Definition of Done, для того, чтобы понять, насколько конкретная разработка работоспособна и можно ли доверять определенной витрине. В Data Lake витрина считается законченной, если все пункты гайда выполнены.
Там, как минимум, должны присутствовать архитектура потоков данных и низкоуровневая архитектура – вплоть до IP-адресов. Также необходимо описать архитектуру данных, причем модель должна быть согласована еще и с подразделением Data Governance. Это позволяет прийти к единой и удобной в работе модели данных, которая не противоречит сама себе. Также у нас выстроены процессы Code review, Review-архитектуры. Обязательно наличие метрик Data Quality (качества данных), а все процессы должны оставлять следы в логах для возможности мониторинга и трассировки проблем с данными. Присутствует дашборд в Grafana, с его помощью можно узнать, как сейчас себя чувствует та или иная витрина, стоит ли ей в данный момент доверять или нет. Еще одна полезная вещь – унифицированный каталог, в котором отображены все загрузки, витрины данных, а каждый атрибут расписан.
Каков компонентный состав Data Lake?
Мы применяем Apache AirFlow, Apache Spark, хранятся данные в Hadoop. Система гетерогенная, с MPP. Используем и Alation, это такой каталог данных, который позволяет работать со знаниями о данных. В нем есть интерфейс, где можно напрямую подключиться к источнику или к Data Lake.
Еще мы применяем Apache Atlas – это технология, которая позволяет создать data lineage. Он нужен для того, чтобы при изменении какого-то объекта мы знали, какие еще процессы его используют, и могли управлять разработкой с точки зрения появления проблем в дальнейшем на production. Из DevOps-инструментов у нас развита Openstack-технология, она позволяет создавать тестовые кластеры. Также используем test, dev-контуры, есть Kubernetes, Jenkins, Grafana, Prometheus – это все нужно для процессов CICD и мониторинга.
Что в итоге?
Выводы: для эффективной работы команд, которые разрабатывают Data Lake, необходим не просто agile с итерационной разработкой, но еще и правильно выстроенная структура команд с учетом предметных областей. Необходимы единые подходы к разработке и архитектуре. Фреймворк Data Mesh позволяет улучшать работу команд разработки аналитических хранилищ, нести ответственность за конечный результат и улучшать пользовательский опыт при работе с данными.
Если у вас есть какие-либо замечания, вопросы или же вы хотите поделиться своими наработками в сфере Data Lake – добро пожаловать в комментарии!
Автор: Григорий Коваль
