Хабр, привет!

Представьте: ваш бизнес растет, а вместе с ним и количество данных. Но вместо ценной аналитики — хаос: отчеты готовятся месяцами, данные разбросаны по Excel-файлам, а команда DWH не успевает закрывать запросы. Знакомо? Мы прошли через это и решили внедрить Data Mesh. Ожидания были амбициозные, но что получилось на самом деле?

Я Петр Гуринов, руководитель практики инженерии данных в Лемана Тех. Работаю в ИТ больше десяти лет, а непосредственно с хранилищами данных — больше пяти лет.

Сегодня я расскажу, как мы адаптировали Data Mesh, что предполагали, с какими трудностями столкнулись и какие уроки вынесли.

Это статья по итогам моего выступления на SmartData, если предпочитаете смотреть, а не читать, вот ссылка на YouTube и ВКонтакте.

Как мы Data Mesh внедрять решили

К 2019 году в компании накопилось множество проблем, связанных с управлением данными. 

Мы работали по классической централизованной модели, где за обработку, интеграцию и подготовку данных отвечала небольшая команда DWH из 8 человек. Этого было явно недостаточно для покрытия всех потребностей бизнеса, особенно с учетом того, что запросы на новые отчеты обрабатывались месяцами.

Технологический стек состоял из MSSQL, SSIS, SSRS, а QlikView использовался не только для визуализации, но и в качестве ETL-инструмента, который работал поверх CSV-выгрузок. Этот подход приводил к техническому хаосу, задержкам в обновлении данных и постоянному росту объема ручных операций. 

Бизнес, в свою очередь, жил в парадигме Excel-driven development — выгруженные вручную данные хранились на компьютерах отдельных сотрудников, что делало аналитику несистемной и трудно воспроизводимой.

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

Так мы пришли к Data Mesh.

Что такое Data Mesh

Data Mesh — это не технология, не конкретный гайдлайн и не готовый рецепт, а скорее подход, который описывает, как можно управлять данными в организации. Первое упоминание о Data Mesh — статья Жамак Дегани 2019 года, там же автор сформулировала ключевые принципы.

• Децентрализованное владение данными — вместо одной команды DWH ответственность за данные передается в продуктовые команды, которые работают в отдельных бизнес-доменах.

• Данные как продукт — информация должна быть документирована, проверяема и доступна внутри компании, у данных должно быть описание и понятные метрики. 

• Self-Service-инфраструктура — платформенные инструменты должны позволять командам самостоятельно интегрировать и обрабатывать данные без постоянного привлечения централизованных специалистов.

• «Федеративное управление» — стандарты работы с данными унифицированы, но управление распределено между различными командами.

Как проходила трансформация

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

Если сфокусироваться на том, что важно в контексте Data Mesh, то раньше у нас было четкое разделение на IT и бизнес. Теперь же в компании появилось около 20 доменов, каждый из которых отвечает не только за бизнес-функции, но и за IT-составляющую — и в том числе данные.

Доменная архитектура отлично соотносится с Data Mesh — однако мы не просто скопировали этот подход, а адаптировали его. Так, четыре принципа трансформировались в

1. Данными владеют и управляют доменные команды;

2. Домены создают дата-продукты (и отвечают за них);

3. Коммунальная платформа данных (не просто Self Service, но и общие инструменты);

4. Единые правила в работе с данными.

Чтобы реализовать последние два постулата и стандартизировать работу с данными, мы собрали центральную команду платформы данных — это архитекторы, платформенные инженеры данных и разработчики, которые создавали ее с нуля, искали и тестировали инструменты, а также формулировали правила и регламенты для остальных.

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

Как только в каждом домене появились специалисты, ответственные за работу с данными, пришлось решить следующую задачу — интегрировать все источники в платформу данных. Причем не просто «попросить» команды об этом, но и задать для них KPI и четкие требования потому что бизнес-приложения должны сделать свои данные доступными в DWH.

Организационная структура

Как я уже упоминал выше, компания поделилась на домены. 

Домен «Клиенты» управляет всеми процессами и информацией о покупателях, программе лояльности. Домен «Платежи» отвечает за транзакции в онлайне и офлайн-магазинах. А домен «Логистика» агрегирует данные о складах, доставке и запасах. И так далее.

Однако для корректной работы в парадигме Data Mesh этого оказалось недостаточно. Поэтому параллельно с функциональными доменами было создано два трансверсальных, или структурно общих: централизованная команда платформы данных, а также команда, которая развивает инфраструктуру и обеспечивает техническую поддержку.

Но и такой подход показался недостаточно полным. В каждом домене появились дата-специалисты, при этом домены существуют независимо друг от друга. Чтобы не допустить «изобретения велосипедов» и следить за актуальностью навыков, а также для обмена знаниями и выработки единых стандартов были организованы сообщества. В них специалисты из разных доменов обсуждают лучшие подходы к работе с данными.

Что в итоге?

Ожидание

Мы полагали, что домены будут ответственны за бизнес-процесс, приложение и дата-продукты. Ожидалось, что так мы получим гибкость, оперативность и осознанное отношение. Ведь если данные принадлежат продуктовой команде, она должна быть заинтересована в их чистоте, актуальности и корректности.

Реальность

Во многом так и случилось. Однако монструозные ERP-системы все равно управляются другими командами, а у некоторых доменов до сих пор нет данных в DWH. Или данные есть, но нет дата-специалистов, которые могли бы с ними работать.

Выводы

• Монолиты — зло. Особенно когда речь про большие старые системы, которые отвечают сразу за большой периметр данных и процессов. Тогда при интеграции с дата-платформой сложно понять, а что именно интегрировать. Чтобы сделать процесс интеграции монолитов более эффективным, лучше разделить его на предметные области и закрепить их за доменами — они лучше знают, какие таблицы на самом деле нужны.

• Нужно обучать не только технологиям, но и другому стилю менеджмента. У многих специалистов есть опыт работы с монолитным ядром и центральной командой DWH — и они привыкли работать по-старому. Без постоянного переобучения сложно избавиться от прежних привычек.

• Enterprise Architect, или архитекторы предприятия, — лучшие друзья для поиска правильного решения. Они помогают найти точки деления по предметным областям.

Принципы ИТ

В рамках компании они едины для всех команд, не только для дата-специалистов.

• Принцип «You Build It, You Run It» — каждая команда сама отвечает за качество и доступность своих данных. Нет никакой централизованной команды поддержки, которая решает любые вопросы.

• Кроссфункциональный состав доменных команд — команды объединили в себе фронтенд- и бэкенд-разработчиков, аналитиков, дата-инженеров, дата-партнеров и т. д.

• Короткие релизные циклы — речь в первую очередь про продуктовый подход, и постоянное отслеживание метрик. Продакты должны четко понимать, куда развивают свой продукт.

• InnerSource — подход, при котором практики Open Source используются внутри корпоративных границ, таким образом код становится доступным для всех сотрудников — поощряется совместная разработка.

Но как дата-специалисты отнеслись к культурным изменениям?

Ожидание

Раз команды кроссфункциональны, домены будут «знать свои данные», а также участвовать в глобальном развитии платформы. 

Реальность

В целом так и получилось. Однако некоторые команды не до конца понимают принцип «данные как продукт» — и считают, что их зона ответственности ограничивается созданием отчетов, а за интеграцию и чистоту данных отвечает кто-то другой. И наоборот, другие команды оказались настолько кроссфункциональны, что стали создавать свои локальные платформы данных.

Выводы

• Необходимо помогать доменам с выявлением потребностей. Кто им нужен, какие роли, в каком количестве? Это должно решаться на уровне сообществ и команды управления данными.

• Важно популяризировать платформу данных. И делать это постоянно: рассказывать про практики, подходы и рекомендации. Мы активно занимались этим в течение пары первых лет, но со временем поверили в Data Mesh настолько, что перестали заниматься обучением. Это была ошибка: в команды постоянно приходят новые люди, и просветительская работа должна вестись перманентно.

• Платформа данных — это продукт. Ее необходимо развивать, следить за метриками, прислушиваться к пользователям и вносить необходимые изменения.

Процессы

С переходом к Data Mesh пришлось пересмотреть подход к организационным процессам.

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

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

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

Та же проблема актуальна и для работы с сообществами. Часть доменов вообще не пересекается друг с другом по рабочим вопросам, многие сотрудники работают удаленно, из разных городов. Получается, члены команд больше не могут собраться вместе и “пойти в бар”, чтобы обсудить наболевшие моменты. Так что нужны новые практики и подходы к взаимодействию в профессиональных сообществах.

Если говорить о разработке, меняется подход к code review. Из-за того, что данные переданы в ведение доменов, необходимо постоянно проверять код и следить за тем, чтобы в нем не нарушались общие правила и стандарты. Частично проблему решает автотестирование, но для сложных задач необходимо привлекать экспертов.

Наконец, растет важность аудита. В противном случае команды рано или поздно начнут «изобретать велосипеды».

Но как компания адаптировалась к изменениям в процессах?

Ожидание

При переходе на Data Mesh появились центры компетенций и позиция «руководитель практики». Именно он и сможет настроить все процессы в одиночку.

Реальность

Процессов слишком много и управлять ими в одиночку невозможно — часть остается без должного внимания.

Выводы

Жамак Дегани не просто так назвала «федеративное управление» одним из ключевых принципов Data Mesh. Чтобы корректно выстроить процессы, необходимо привлекать специалистов из разных доменов — вместе они помогут выстроить все необходимые регламенты.

Технологии

Мы сформулировали, что процессы разработки и платформа в целом должны базироваться на следующих технологических принципах.

• Масштабируемость. Разработчики должны изначально понимать, как масштабировать любое решение — сколько это будет стоить и получится ли сохранить необходимый уровень SLA.

• Эффективность работы с облаками. Все продукты должны запускаться в любом облаке (будь то частное или публичное).

• Только Open Source. Никаких вендорских решений и связанных с ними ограничений.

• Внутренняя разработка сервисов. Собственные продукты и практики, которые позволяют эффективно вписать open-source-решение в общий ландшафт.

В результате платформа данных на первом этапе выглядела вот так. Сейчас архитектура поменялась — мы уже писали об этом подробнее.

Вместе с определением технологических принципов мы поняли, что для корректного перехода на Data Mesh компании необходимы еще и платформенные сервисы, которые позволят сделать продукт удобным для конечных пользователей.

• Описание данных. Нужен дата-каталог, который понятен и доступен всем. И строить платформу данных важно опираясь на дата-каталог как на один из ключевых инструментов. 

• Качество данных. Домены должны регулярно проверять свои источники.

• Аудит доступов. Важно не просто выдавать доступы, но и постоянно следить за тем, у кого они есть.

• Единообразие интеграции данных. Core-команда платформы данных должна следить за тем, чтобы все их источники легко интегрировались с платформой.

• Управление справочниками. Для этого пригодится отдельная система с историчностью строк и валидацией справочников, дабы избежать дублирования.

• «Отстрел» зависших сессий. Например, Greenplum имеет ограничение на число подключений, поэтому важно дать пользователям возможность «обрубать» сессии.

• Создание сэмплов данных для разработки. Из продовых и предпродовых окружений, с учетом требований безопасности.

Как технологии и принципы в итоге сказались на развитии платформы?

Ожидание

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

Реальность

Несмотря на облака, важно постоянно взаимодействовать с локальной инфраструктурой — иначе она станет узким местом и затормозит развитие. Та же проблема с Open Source — он иногда «ломается» (обычно в самый неподходящий момент).

Выводы

• Важно учиться «готовить» Open Source самостоятельно — и иметь экспертизу внутри. Время, когда достаточно было купить коробочное решение и получить миллион сертификатов, прошло. На рынке уже много специалистов с опытом в open-source-продуктах, которые сразу могут влиться в задачи.

• Fullstack-разработчики помогут быстро разрабатывать внутренние сервисы.

Команда платформы данных должна составлять не менее 20% от общего количества дата-специалистов — чтобы все сервисы развивались в соответствии с потребностями пользователей.

Советы себе пять лет назад

Или уроки, которые мы вынесли.

Сейчас мы работаем в подходе Data Mesh. В компании сегодня трудится более сотни специалистов по работе с данными, кроме того, к задачам часто привлекаются аутстафферы. Время интеграции источника в хранилище сократилось с полугода до пары недель. Всего благодаря платформе создано более 1500 отчетов, а число пользователей достигло 12,5 тысячи человек. Но главное — домены научились самостоятельно создавать дата-продукты, а компания перешла к подходу Data Informed.

За это время мне удалось сформулировать пять выводов, которые очень пригодились бы на старте перехода к Data Mesh.

1. Трансформации позволяют развиваться быстрее. В том числе тебе как специалисту.

2. Заложить время на коммуникации и взаимодействие. Децентрализация требует временных затрат.

3. Активнее развивать Self-Service-инструменты. Автоматизация — это ключ к успеху. Чем больше процессов можно отдать на откуп командам, тем выше будет их вовлеченность.

4. Регулярно проводить обучения. Люди не сразу понимают, как работать в новом подходе. Нужно активно обучать и поддерживать команды.

5. Привлекать дата-специалистов из доменов. Это поможет сделать общую платформу более эффективной (а еще специалисты не начнут строить свои «мини-империи» данных в противовес коммунальной платформе данных).

И главный вывод. Data Mesh — не панацея и даже не технология, а взгляд на управление данными. Его внедрение требует организационных, технических и культурных изменений, которые могут занять годы. В быстрорастущих компаниях подход позволяет значительно ускорить обработку данных, повысить их качество и сделать их доступными для бизнеса. Но если компания небольшая, с устойчивой структурой данных, то централизованная команда DWH может быть эффективнее.

Полезные материалы

• How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

• Data Mesh Principles and Logical Architecture

• Data Mesh: Delivering Datа-driven Value At Scale

• Introduction to Data Mesh with Zhamak Dehghani

• Дмитрий Шостко: Как построить Data Mesh в организации

• Как с помощью Data Mesh разломать ваше DWH — Евгений Ермаков, Яндекс GO