Хабр, привет!
Представьте: ваш бизнес растет, а вместе с ним и количество данных. Но вместо ценной аналитики — хаос: отчеты готовятся месяцами, данные разбросаны по 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 — однако мы не просто скопировали этот подход, а адаптировали его. Так, четыре принципа трансформировались в
Данными владеют и управляют доменные команды;
Домены создают дата-продукты (и отвечают за них);
Коммунальная платформа данных (не просто Self Service, но и общие инструменты);
Единые правила в работе с данными.
Чтобы реализовать последние два постулата и стандартизировать работу с данными, мы собрали центральную команду платформы данных — это архитекторы, платформенные инженеры данных и разработчики, которые создавали ее с нуля, искали и тестировали инструменты, а также формулировали правила и регламенты для остальных.
Кроме того, компания начала активно нанимать дата-специалистов в домены — это необходимо, чтобы каждый из доменов действительно мог владеть и управлять данными.
Как только в каждом домене появились специалисты, ответственные за работу с данными, пришлось решить следующую задачу — интегрировать все источники в платформу данных. Причем не просто «попросить» команды об этом, но и задать для них 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.
Трансформации позволяют развиваться быстрее. В том числе тебе как специалисту.
Заложить время на коммуникации и взаимодействие. Децентрализация требует временных затрат.
Активнее развивать Self-Service-инструменты. Автоматизация — это ключ к успеху. Чем больше процессов можно отдать на откуп командам, тем выше будет их вовлеченность.
Регулярно проводить обучения. Люди не сразу понимают, как работать в новом подходе. Нужно активно обучать и поддерживать команды.
Привлекать дата-специалистов из доменов. Это поможет сделать общую платформу более эффективной (а еще специалисты не начнут строить свои «мини-империи» данных в противовес коммунальной платформе данных).
И главный вывод. Data Mesh — не панацея и даже не технология, а взгляд на управление данными. Его внедрение требует организационных, технических и культурных изменений, которые могут занять годы. В быстрорастущих компаниях подход позволяет значительно ускорить обработку данных, повысить их качество и сделать их доступными для бизнеса. Но если компания небольшая, с устойчивой структурой данных, то централизованная команда DWH может быть эффективнее.
