- PVSM.RU - https://www.pvsm.ru -
Привет! Мы в Dodo Pizza Engineering очень любим данные (а кто их сейчас не любит?). Сейчас будет история о том, как накопить все данные мира Dodo Pizza и дать любому сотруднику компании удобный доступ к этому массиву данных. Задача под звёздочкой: сохранить нервы команды Data Engineering.
Как настоящие Плюшкины, мы копим всевозможную инфу о работе наших пиццерий:
За работу с данными в Dodo Pizza сейчас отвечает несколько команд, одна из них – команда Data Engineering. Сейчас перед ними (то есть нами) стоит задача: дать любому сотруднику компании удобный доступ к этому массиву данных.
Когда мы стали думать, как это сделать и начали обсуждать задачу, мы нашли очень интересный подход к управлению данными – Data Mesh [1] (по ссылке вы найдёте огромную шикарную статью). Её идеи очень хорошо легли на наше представление о том, как мы хотим построить нашу систему. Дальше в статье будет наше переосмысление подхода и то, как мы видим его внедрение в Dodo Pizza Engineering.
Для начала давайте определимся с тем, что мы подразумеваем под данными в Dodo Pizza Engineering:
Чтобы бизнес Dodo Pizza мог использовать эти данные и полагаться на них, важно чтобы выполнялись следующие условия:
Учитывая все эти требования, мы пришли к выводу, что данные в Dodo – это продукт. Такой же, как публичное API сервиса. Соответственно, владеть данными должна та же команда, которая владеет сервисом. Также изменения схемы данных должны быть всегда обратно-совместимыми.
Для решения задач надёжного хранения и обработки больших данных существует традиционный подход, принятый во многих компаниях, которые работают с таким пулом информации – Data Lake. В рамках этого подхода инженеры по работе с данными собирают информацию со всех компонентов системы и складывают их в одно большое хранилище (это может быть, например, Hadoop, Azure Kusto, Apache Cassandra или даже MySQL реплика, если данные в неё влезают).
Дальше эти же самые инженеры пишут запросы к такому хранилищу. Реализация этого подхода в Dodo Pizza Engineering подразумевает, что команда Data Engineering будет владеть схемой данных в аналитическом хранилище.
При этом варианте развития событий, команда становится очень грустными котиками и вот почему:
Получается, что команда находится в точке пересечения огромного количества потребностей и вряд ли сможет удовлетворить их. При этом будет находиться в постоянном цейтноте и стрессе. Нам такого очень не хочется. Поэтому приходится думать, как решить эти проблемы и при этом получить возможность анализировать данные.
К счастью, этот вопрос задавали себе не только мы. На самом деле, подобная проблема уже была решена в индустрии (аллилуйя!). Только в другой области: развертывание приложений. Да, я говорю про DevOps подход, где команда определяет, как нужно разворачивать продукт, который они создают.
Похожий подход к решению проблем Data Lake предложила Zhamak Dehghani, консультант ThoughtWorks. Наблюдая за тем, как подобные задачи решают Netflix и Spotify, она написала потрясающую статью How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh [1](ссылка на нее была в начале статьи). Основные идеи, которые мы для себя из неё вынесли:
Если представить, что всё это реализуется по щелчку пальцев, то останется ответить на два вопроса:
Чем теперь будет заниматься команда 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.
У нас есть несколько способов, как это сделать:
Сейчас я много рассказал о публикации данных. Но есть ещё и потребление. Что по этому вопросу?
У нас есть замечательная команда BI, которая пишет очень сложные отчеты для управляющей компании. Внутри Dodo IS есть много отчетов для наших партнеров, которые помогают им управлять пиццериями. В нашей новой модели мы думаем о них, как о потребителях данных, у которых есть свои домены данных. И именно потребители будут отвечать за свои собственные домены. Иногда домен потребителя может быть описан одним запросом в аналитическое хранилище – и это хорошо. Но мы понимаем, что это не всегда будет работать. Именно поэтому мы хотим, чтобы та платформа, которую мы создадим для продуктовых команд, могла также быть использована и потребителями данных (ведь в случае с отчетами внутри Dodo IS – это будут одни команды).
Вот так мы видим работу с данными в Dodo Pizza Engineering. С удовольствием прочитаем ваши мысли по этому поводу в комментариях.
Автор: onikiychuka
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/big-data/336547
Ссылки в тексте:
[1] Data Mesh: https://martinfowler.com/articles/data-monolith-to-mesh.html
[2] DevForum: https://habr.com/ru/company/dodopizzaio/blog/462033/
[3] Источник: https://habr.com/ru/post/475476/?utm_campaign=475476&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.