Data Mesh: как работать с данными без монолита

Привет, Хабр! Мы в Dodo Pizza Engineering очень любим данные (а кто их сейчас не любит?). Сейчас будет история о том, как накопить все данные мира Dodo Pizza и дать любому сотруднику компании удобный доступ к этому массиву данных. Задача под звёздочкой: сохранить нервы команды Data Engineering.

Как настоящие Плюшкины, мы копим всевозможную инфу о работе наших пиццерий:

• помним все заказы пользователей;
• знаем, сколько времени ушло на изготовление самой первой пиццы в Сыктывкаре;
• видим, сколько времени пицца остывает на тепловой полке в Воронеже прямо сейчас;
• храним данные по списанию продуктов;
• и многое-многое другое.

За работу с данными в Dodo Pizza сейчас отвечает несколько команд, одна из них – команда Data Engineering. Сейчас перед ними (то есть нами) стоит задача: дать любому сотруднику компании удобный доступ к этому массиву данных.

Когда мы стали думать, как это сделать и начали обсуждать задачу, мы нашли очень интересный подход к управлению данными – Data Mesh (по ссылке вы найдёте огромную шикарную статью). Её идеи очень хорошо легли на наше представление о том, как мы хотим построить нашу систему. Дальше в статье будет наше переосмысление подхода и то, как мы видим его внедрение в Dodo Pizza Engineering.

Что мы имеем в виду под «данными»

Для начала давайте определимся с тем, что мы подразумеваем под данными в Dodo Pizza Engineering:

• События, которые шлют сервисы (у нас есть общая шина, построенная с помощью RabbitMQ);
• Записи внутри базы данных (для нас это MySQL и CosmosDB);
• Clickstream с мобильного приложения и сайта.

Чтобы бизнес Dodo Pizza мог использовать эти данные и полагаться на них, важно чтобы выполнялись следующие условия:

• Они должна быть целостными. Мы должны быть уверены, что не изменяем данные в процессе их обработки, хранения и отображения. Если бизнес не сможет доверять нашим данным, то в них не будет никакой пользы.
• Они должны иметь метку времени и не затираться. Это значит, что мы в любой момент времени хотим иметь возможность откатиться назад и посмотреть на данные того отрезка времени. Например, узнать, сколько пицц продали 8 июля 2018 года.
• Они должны быть надёжными. В процессе сбора и хранения данных мы должны не терять не только целостность, но и надежность. Мы не можем терять данные, слайсы времени, потому что вместе с ними мы теряем доверие наших клиентов (как внешних, так и внутренних).
• Они должны быть со стабильной схемой – мы пишем запросы на эти данные. Нам бы очень не хотелось, чтобы с изменением кода приложения, с рефакторингом, они поменялась настолько, что наши запросы перестали работать. Тот, кто пишет запросы никогда не узнает, что вы сделали рефакторинг, пока всё не сломается нафиг. Не хотелось бы узнать об этом от клиентов.

Учитывая все эти требования, мы пришли к выводу, что данные в Dodo – это продукт. Такой же, как публичное API сервиса. Соответственно, владеть данными должна та же команда, которая владеет сервисом. Также изменения схемы данных должны быть всегда обратно-совместимыми.

Традиционный подход – Data Lake

Для решения задач надёжного хранения и обработки больших данных существует традиционный подход, принятый во многих компаниях, которые работают с таким пулом информации – Data Lake. В рамках этого подхода инженеры по работе с данными собирают информацию со всех компонентов системы и складывают их в одно большое хранилище (это может быть, например, Hadoop, Azure Kusto, Apache Cassandra или даже MySQL реплика, если данные в неё влезают).

Дальше эти же самые инженеры пишут запросы к такому хранилищу. Реализация этого подхода в Dodo Pizza Engineering подразумевает, что команда Data Engineering будет владеть схемой данных в аналитическом хранилище.

При этом варианте развития событий, команда становится очень грустными котиками и вот почему:

• Она должна следить за изменениями во ВСЕХ сервисах внутри компании. А их много и изменений очень много (в среднем мы мерджим ~100 pull requests в неделю, при этом многие сервисы не делают pull requests совсем).
• При изменении схемы данных продуктоунер и команда, изменяющая схему данных, должны ждать пока Data Engineering допишет код, необходимый чтобы изменения поддерживались. При этом у нас уже давно фичатимы и ситуация, когда одна команда ждёт другую – очень редкая. И мы не хотим, чтобы это стало «нормальной» частью процесса разработки.
• Она должна быть погружена в ВЕСЬ бизнес компании. Сеть пиццерий выглядит простым бизнесом, но это только кажется. Очень сложно собрать в одной команде достаточно компетенций для построения адекватной модели данных для всей компании.
• Она является единой точкой отказа. Каждый раз, когда надо изменить данные, которые возвращает сервис или написать запрос, – все эти задачи падают к команде Data Engineering. В итоге у команды перегруженный бэклог.

Получается, что команда находится в точке пересечения огромного количества потребностей и вряд ли сможет удовлетворить их. При этом будет находиться в постоянном цейтноте и стрессе. Нам такого очень не хочется. Поэтому приходится думать, как решить эти проблемы и при этом получить возможность анализировать данные.

Перетекая от Data Lake к Data Mesh

К счастью, этот вопрос задавали себе не только мы. На самом деле, подобная проблема уже была решена в индустрии (аллилуйя!). Только в другой области: развертывание приложений. Да, я говорю про DevOps подход, где команда определяет, как нужно разворачивать продукт, который они создают.

Похожий подход к решению проблем Data Lake предложила Zhamak Dehghani, консультант ThoughtWorks. Наблюдая за тем, как подобные задачи решают Netflix и Spotify, она написала потрясающую статью How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh(ссылка на нее была в начале статьи). Основные идеи, которые мы для себя из неё вынесли:

• Поделить большой Data Lake на домены данных, которые очень похожи на domain-driven design домены. Каждый домен – маленький bounded context.
• Feature Team, которые отвечают за DDD домены, отвечают и за соответствующие домены данных. Они хранят схему, вносят в неё изменения, загружают в неё данные. При этом сами всё знают: как изменить загрузку данных и ничего не сломать, когда приложение меняется. Знания никуда не уходят. Чтобы открыть данные, им не надо никуда идти. Сама команда ведёт полный цикл разработки от изменения оперативных данных до предоставления аналитических данных третьим лицам. Одна команда владеет всем связанным с доменом (как бизнес-доменом, так и доменом данных).
• Data Engineer – роль внутри Feature Team. Это не обязательно должен быть отдельный человек, но обязательно, чтобы команда обладала данной компетенцией.

А в это время команда Data Engineering…

Если представить, что всё это реализуется по щелчку пальцев, то останется ответить на два вопроса:

Чем теперь будет заниматься команда Data Engineering? В Dodo Pizza Engineering уже есть команда платформы/SRE. Её задача – дать разработчикам инструменты для простого развертывания сервисов. Команда Data Engineering будет выполнять такую же роль только для данных.

Превращение операционных данных в аналитические – сложный процесс. Сделать аналитические данные доступными для всей компании – ещё сложнее. Именно решением этих проблем и будет заниматься команда Data Engineering.

Мы собираемся предоставить Feature Team удобный набор инструментов и практик, с помощью которых они смогут публиковать данные из своего сервиса для остальной компании. Также мы будем отвечать за общие инфраструктурные части data pipeline (очереди, надежное хранилище, кластера для выполнения преобразований над данными).

Как навыки Data Engineer появятся внутри Feature Team? С Feature Team всё сложнее. Конечно, мы могли бы попробовать нанять по одному Data Engineer в каждую из наших команд. Но это очень сложно. Найти человека с хорошим бэкграундом в обработке данных и убедить его работать внутри продуктовый команды тяжело.

Большим плюсом Dodo является то, что мы любим внутреннее обучение. Так что сейчас наш план такой: команда Data Engineering начинает публиковать данные некоторых сервисов, плачет, колется, но продолжает кушать кактус. Как только мы поймем, что у нас есть готовый процесс для публикации, мы начинаем рассказывать о нём в Feature Team.

У нас есть несколько способов, как это сделать:

1. DevForum, на котором мы расскажем, как выглядит процесс, который мы создали, какие есть инструменты и как их наиболее эффективно использовать.
2. Выступление на DevForum поможет нам собрать обратную связь от продуктовых разработчиков. После этого мы сможем присоединяться к продуктовым командам и помогать им решать задачи с публикацией данных, организовывать тренинги для команд.

Потребление данных

Сейчас я много рассказал о публикации данных. Но есть ещё и потребление. Что по этому вопросу?

У нас есть замечательная команда BI, которая пишет очень сложные отчеты для управляющей компании. Внутри Dodo IS есть много отчетов для наших партнеров, которые помогают им управлять пиццериями. В нашей новой модели мы думаем о них, как о потребителях данных, у которых есть свои домены данных. И именно потребители будут отвечать за свои собственные домены. Иногда домен потребителя может быть описан одним запросом в аналитическое хранилище – и это хорошо. Но мы понимаем, что это не всегда будет работать. Именно поэтому мы хотим, чтобы та платформа, которую мы создадим для продуктовых команд, могла также быть использована и потребителями данных (ведь в случае с отчетами внутри Dodo IS – это будут одни команды).

Вот так мы видим работу с данными в Dodo Pizza Engineering. С удовольствием прочитаем ваши мысли по этому поводу в комментариях.

Источник: habr.com