11 уроков, полученных при управлении командой платформы данных в рамках внедрения data mesh
Введение
Команда специалистов по данным компании BlaBlaCar начала работу над построением Data Mesh в феврале 2022 года. Сейчас над этим процессом трудятся 7 команд:
- 6 многопрофильных команд, каждая из которых несет ответственность за свой бизнес-домен;
- 1 команда платформы данных, состоящая исключительно из дата-инженеров.
Решение о создании команды платформы данных было принято для того, чтобы обеспечить общую инфраструктуру и инструментарий для специалистов по работе с данными во всех подразделениях компании. Практикующие специалисты по данным - это дата-инженеры, инженеры-аналитики, аналитики данных, инженеры ML и ученые по данным. Мы также создали сообщества, в которых собраны сотрудники с одинаковыми техническими знаниями и навыками из разных команд, чтобы обмениваться опытом и совместно руководить рабочим процессом.
В этой статье я хочу поделиться с Вами выводами, которые мы сделали за последние пару лет, внедряя модель data mesh. Основное внимание будет уделено проблемам, с которыми сталкиваются команды, а не управлению в целом.
Дженерики
Работая над каждым конкретным вариантом использования в рамках одной команды, мы всегда помним об универсальности. Другими словами, мы проверяем, можно ли без особых усилий использовать то, что мы создаем, для других вариантов использования и в других командах. Мы думаем о команде платформы как о стартапе внутри компании, предоставляющем общие инструменты для специалистов по работе с данными. Таким образом, команда платформы данных владеет агностическим программным обеспечением, а команды домена активно его используют.
Очевидно, что создание универсального программного обеспечения связано со значительными первоначальными затратами. Например, создать скрипт, который может скопировать любую таблицу и передать ее на склад, гораздо сложнее, чем создать скрипт, который умеет копировать только одну конкретную таблицу. Общая версия должна уметь преобразовывать любой возможный тип поля во входной схеме в выходную схему склада. Если Вы переходите к какой-либо конкретной версии, все становится намного проще: схемы могут быть жестко закодированы для входных и выходных данных. Таким образом, Вам не придется реализовывать сложную логику преобразования схем.
Основываясь на нашем опыте, с уверенностью можем сказать, что универсальность – самая правильная инвестиция для масштабных продуктов, поскольку подобные инструменты можно использовать повторно без особых усилий.
Пример
Перед нами была поставлена задача построить feature-store (хранилище данных для машинного обучения). Оно предоставляет ученым данные для создания обучающих наборов данных, а также обслуживает полученные модели.
Что –то пошло не так
В качестве первой версии мы создали специфический feature-store. Его исходный код знал о моделях данных (таких как предложения вариантов поездок, бронирования и пользователи) и строил разнообразные конвейеры ввода.
Специалисты по обслуживанию feature-store должны были понимать бизнес-логику каждого варианта использования и историю, лежащую в его основе. Добавление новых данных иногда подразумевало адаптацию архитектуры кода всего приложения.
Каждый раз, когда пользователи хотели получить новые данные в feature-store, они создавали для нас тикеты в Jira. И каждый раз нам приходилось вносить серьезные изменении в уже построенную схему.
Сработало на все 100
Благодаря самой первой версии у нас появилась возможность использовать машинное обучение на производстве, но как только она начала пользоваться успехом, ее стало крайне трудно масштабировать ввиду сложности обслуживания.
Поэтому мы решили перейти к схеме, при которой команда платформы данных создает общий feature-store, не имеющий никакого представления о данных. Добавление новых конвейеров данных не требует особых знаний в каждой конкретной области: специалисты предоставляют программное решение, а пользователи используют его самостоятельно. Они добавляют конфигурации и простой код по заранее определенному шаблону и получают возможность реализовать свои программы.
Это обеспечивает пользователям определенную автономию и одновременно снижает потребность специалистов по данным в знании каждого конкретного варианта использования домена.
Взаимодействие с большим количеством заинтересованных сторон
Data-mesh обеспечивает автономность доменно-ориентированных команд. Они практически не связаны друг с другом, каждая из них владеет своим собственным доменом. При этом команда платформы данных связана со всеми командами. Заинтересованные стороны могут быть представлены как узлами data mesh, так и техническими специалистами и дата-инженерами. Последние, очевидно, будут использовать команду платформы данных в качестве шлюза в отдел данных, особенно для решения технических вопросов, таких как безопасность данных соответствие нормативным требованиям. Мы обнаружили, что им гораздо проще обратиться к нам напрямую, чем ко всем узлам данных по очереди:
- Мы можем быстро предоставить им краткий обзор всего стека данных;
- Наше с ними взаимодействие позволяет им лучше сформулировать свои запросы к специалистам по работе с данными: общение между ними может быть затруднено, поскольку они обладают совершенно разными навыками и знаниями и «говорят на разном языке»;
- Мы в состоянии оптимизировать различные рабочие процессы: зачастую платформа данных может построить одно универсальное решение абсолютно для всех, а не для каждой команды по отдельности.
Наличие такого большого количества заинтересованных сторон порождает множество проблем: необходимо собирать различную информацию, находить способы для эффективного воздействия, добиваться принятия решений большим количеством людей и адаптировать коммуникацию в зависимости от аудитории.
Пример
В нашем случае заинтересованными сторонами являются 6 команд по работе с данными, 4 сообщества и 5 команд по обслуживанию инфраструктуры.
Мы прилагаем множество усилий для укрепления связей с каждой из них. Это включает в себя регулярные запросы обратной связи и совместное создание нашей дорожной карты. За это отвечает владелец продукта платформы данных - он собирает запросы и обратную связь, чтобы определить нужные точки воздействия.
Мы также организуем встречи под названием "управление стеком" для обсуждения основных решений стека. Сообщества играют важнейшую роль в принятии решений по проектированию, в некоторых из них есть представители команды платформы данных.
Построение «правильной» команды специалистов
Сфера нашей деятельности довольно обширна: от поддержки проектов в области науки о данных до аналитики и инфраструктуры.
Для того, чтобы иметь возможность эффективно общаться со всеми упомянутыми выше заинтересованными сторонами и выполнять самые разные миссии, нам нужна была команда, обладающая широким спектром знаний.
Все члены нашей команды – дата-инженеры с одинаковыми обязанностями. Тем не менее, каждый из нас обладает уникальным опытом: кто-то ранее работал в качестве ученого по данным, кто-то - аналитиком данных, а кто-то – backend/frontend - разработчиком. Подобная структура позволяет нам охватывать широкий диапазон технических знаний и при необходимости обмениваться опытом.
Пример
Когда команда только начинала свою работу, каждый специалист разбирался только в определенной части стека.
Было сложно что-то исправлять или отвечать на определенные запросы, если по какой-либо причине нужный «эксперт» отсутствовал. Одним из инструментов, который мы в итоге взяли на вооружение, стала матрица навыков. Ее цель заключается в обмене знаниями внутри команды, что позволяет каждому члену команды провести оценку своих знаний и умений. Каждую неделю мы выделяем время, в течение которого «эксперт» помогает нам выполнить общие операции, касающиеся определенных частей стека. «Неэксперты" выполняют задания и задают уточняющие вопросы «эксперту».
Иногда мы специально поручаем определенные задачи тем людям, которые откровенно «плавают» в соответствующих областях. Данный метод мы рассматриваем как долгосрочные инвестиции в создание «правильной» команды. Эксперты будут оказывать этим людям максимальную поддержку и научат их разбираться в сложных темах - постепенно мы обеспечим нужное нам «приращение» опыта внутри команды.
Расстановка приоритетов
Мы оказались в сложнейшей ситуации: слишком много заинтересованных сторон и широкий спектр обязанностей.
Чтобы справиться с огромным количеством поступающих запросов, мы используем два ключевых метода:
- Избирательность при построении дорожной карты: каждый квартал мы выбираем проекты, связанные сразу с несколькими приоритетными частями стека, и отказываемся от остальных;
- Ротация запусков и вызовов: каждую неделю кто-то из команды назначается дежурным в случае поломки части стека и необходимости оказания поддержки пользователям, что обеспечивает непрерывность процесса обслуживания.
Если Вы не выберете приоритетные направления своей деятельности, их будет слишком много, и Вы просто не справитесь со своими задачами - потребность в поддержке всегда велика.
Пример
Команда данных, отвечающая за автобусы, хотела получать данные из API (от внешнего поставщика). Внешнего решения, соответствующего всем нашим потребностям и бюджету, не нашлось, поэтому мы решили создать что-то собственными силами. У нас был выбор:
- С самого начала пойти по пути универсального решения, поручив его создание команде платформы данных, либо
- Поручитькоманде домена разработать решение автономно, без нашего вмешательства.
Мы коллективно решили, что команда домена создаст нужный им продукт самостоятельно и будет поддерживать его локально, поскольку в других командах подобной необходимости не было. Данное решение позволило высвободить драгоценное время команды платформы данных и сосредоточиться на приоритетных темах, актуальных для всех команд.
Согласование действий с ключевыми заинтересованными сторонами
Если посмотреть на эту проблему с другой стороны, то запуск сразу нескольких проектов командой платформы данных создает давление на другие команды. Вместо того, чтобы уделять время своим специфическим задачам, команды тратили слишком много времени на освоение изменений, которые мы привносили в общую инфраструктуру.
Даже с учетом самых благих намерений единовременный запуск слишком большого количества изменений может негативно сказаться на организации в целом. Такое решение может вызвать сильное сопротивление изменениям. Причина проста: люди, на которых Вы хотите повлиять, не понимают, зачем Вы все это делаете, им гораздо легче работать по старинке. Именно поэтому мы совместно заранее планируем наши преобразования, чтобы убедиться, что команды смогут воспринять потенциальные изменения и станут частью общего проекта.
Пример
Что-то пошло не так
Одним из наших первых проектов стала задача по изменению конвейера отслеживания данных, предназначенному для front-end-приложений, потому что он был слишком сложным, и мы не могли поддерживать его должным образом. В новой версии появились новые таблицы, с которыми должны были работать инженеры-аналитики всех доменных подразделений.
У инженеров-аналитиков были другие приоритеты, и они абсолютно не понимали, почему мы вносим изменения.
Ситуация была тяжелой, и нам потребовалось слишком много времени, чтобы завершить данный проект.
Сработало на все 100
Одним из примеров крупных преобразований, которые мы проводим в настоящее время, является переход на dbt. Потребность в этом возникла у инженеров-аналитиков, которым нужно было оптимизировать свою работу - при этом наша команда платформы данных призвана обеспечить инфраструктуру перехода.
В данном случае мы видим совершенно иную динамику развития процесса. Заинтересованные стороны не просто присоединяются к проводимым изменениям, а скорее сами возглавляют их.
Гибкость важнее жестких правил
Благодаря работе команды платформы данных нашей организации не нужно изобретать велосипед, мы предоставляем общие инструменты и шаблоны. Тем не менее, в некоторых случаях подразделениям, ориентированным на конкретные области, приходится действовать быстро и в одиночку, чтобы уложиться в определенный срок или просто поэкспериментировать о. И мы совершенно не против этого.
Платформа данных воспринимается не как команда, которая решает, как все должно быть сделано, а скорее как помощник. Мы стремимся к принятию, а не к навязыванию обязательств.
Data Mesh тяготеет к гибкости. Наличие команды платформы данных не должно менять эту тенденцию, а, скорее, наоборот, усиливать ее. Правила и шаблоны возникают естественным образом благодаря предоставляемому инструментарию. Это особенно актуально для самого первого раза: во многих случаях Вы не хотите сразу переходить на общие правила - Вы ждете появления паттерна, и только затем вкладываете деньги в то, чтобы сделать его универсальным.
Для того, чтобы обеспечить сплоченность в стеке, мы внедрили еще один паттерн: периодически «перемещаем» инженеров между командой платформы и командами доменов. Идея заключается в поощрении внутренней мобильности, которая позволяет гармонизировать рабочую практику. Люди, приходящие в команду платформы, привносят контекст домена; люди, уходящие из нее в команды доменов, становятся «амбассадорами» общей платформы.
Пример
В настоящее время мы занимаемся реорганизацией хранилищ данных. Как команда платформы, мы заняли позицию не «решателей», а именно помощников. Инженеры-аналитики и аналитики данных сами решают, как они хотят организовать свои GCP-проекты, на которых размещены их хранилища.
Команда платформы данных оказывает помощь в создании системы управления правами, соответствующей пожеланиям аналитиков. Мы вмешиваемся только в случаях серьезных трудностей или угрозы безопасности, связанных с выбором того или иного решения. Члены команд доменов должны чувствовать нашу поддержку, необходимую для выполнения своей работы, а не давление от требований, предъявляемых к инфраструктуре, и жестких сроков.
Инновации на основе реальных потребностей, а не тенденций
Мы не внедряем инструменты только потому, что они модные. Мы внедряем только то, что действительно нужно бизнесу.
Для этого мы обычно работаем вместе с командой по работе с данными и создаем определенные решения, которые затем распространяем на другие команды. Мы убедились, что такая схема действительно работает. На конкретных примерах и с помощью измеримых результатов мы можем наглядно показать, ЧТО именно дает новый инструмент или методология. Это значительно облегчает процесс внедрения.
Кроме того, «совместное строительство» создает общие цели и генерирует общий успех, что крайне важно для совместной работы.
Пример
В 4-м квартале 2022 года мы решили оптимизировать подход к машинному обучению, внедрив культуру MLOps. Эти преобразования были бы невозможны, если бы над ними работала только команда платформы данных.
Мы знали, что одно доменное подразделение, отвечающее за выявление мошенничества, работает над оптимизацией жизненного цикла своих моделей машинного обучения, и решили объединить с ними свои усилия.
Так возникла рабочая группа, в которой мы совместно обсуждали организационные изменения и экспериментировали с инструментами и паттернами. Проект привел к значительному улучшению качества машинного обучения в производстве, сокращению времени выхода продукта на рынок и сокращению затрат на внедрение конвейера обучения в 4 раза. Затем мы масштабировали этот паттерн на другие области с остальными командами.
Не взваливайте на себя слишком много обязанностей
В определенный момент мы столкнулись со слишком большим количеством различных запросов. Для многих людей первой мыслью в случае возникновения каких-либо проблем было обращение в команду платформы данных. Безусловно, было очень приятно, что все были уверены в том, что мы можем помочь буквально во всем, но это сильно усложняло нашу работу. Это было особенно заметно в самые первые дни реорганизации data mesh. Специалисты по работе с данными приходили к нам с вопросами, выходящими за рамки нашей компетенции: доступ к инструментам, управляемым ИТ-командой, проблемы с инфраструктурой, принадлежащей SRE, и т. д.
Первым порывом было ответить как можно лучше и подробнее. И чем полезнее мы были, тем больше было запросов вне нашей компетенции. В итоге мы выработали решение перестать брать на себя несвойственные нам роли и перенаправлять определенные запросы «по адресу», в соответствующие команды.
Пример
Чтобы решить проблему множества запросов «не по адресу», мы провели несколько бесед:
- Внутри команды. Это позволило нам выявить проблему, а также принять коллективное решение прекратить брать на себя чужие роли;
- С инженерными менеджерами доменных подразделений, чтобы они ориентировали экспертов по данным задавать тот или иной вопрос сначала в своей собственной междисциплинарной команде, и только потом при необходимости обращаться в команду платформы данных;
- С сообществами, где собираются дата-инженеры, чтобы ознакомить их с выявленной проблемой и убедить их предоставлять «первую помощь» в своих группах (а не бежать сразу к нам за помощью).
В результате количество запросов «не по адресу» резко сократилось, ответственность команды платформы данных приобрела более четкие границы. Тем не менее, этот пункт всегда нужно отслеживать и разъяснять, особенно для новичков.
“Build vs buy"
Как уже говорилось ранее, команда платформы данных создает и поддерживает множество собственных продуктов, что абсолютно не мешает нам использовать решения с открытым исходным кодом или сторонние продукты.
Основное правило гласит, что строить самостоятельно следует только в случае, если:
- Нам это действительно нужно;
- Нет действительно подходящей внешней альтернативы или разрыв в стоимости слишком велик.
Мы всегда стараемся подходить к вопросу build vs. buy взвешенно. Периодически мы пересматриваем принятые решения, чтобы проверить их целесообразность.
Это очень важно для того, чтобы оставить только то, что действительно необходимо поддерживать. В противном случае у платформы данных будет слишком много работы и слишком мало времени, чтобы сосредоточиться на том, что приносит осязаемую пользу.
Пример
В определенный момент нужно было принять решение, стоит ли продолжать разрабатывать собственный конвейер отслеживания фронтенда или лучше обратиться к сторонним организациям. Чтобы выработать единственно верное решение, мы обратились к нескольким внешним поставщикам услуг, а также подключили людей из отдела маркетинга и обсудили возможные варианты в группе. В итоге мы увидели, что конечные пользователи не проявляют особого интереса к функциям, предоставляемым внешними поставщиками, а разница в стоимости сторонних и собственных разработок значительна. Поэтому мы решили сохранить существующую систему, поскольку она полностью соответствовала всем нашим требованиям.
Совершенно по-другому мы поступили в отношении загрузки маркетинговых конвейеров (для получения данных от внешних провайдеров, таких как Google Ads и Facebook Ads). Мы решили продолжить работу с Rivery, поскольку данное решение показалось нам более надежным и экономически эффективным по сравнению с тем, что мы могли бы создать собственными силами.
Периодически мы «бросаем вызов» текущим процессам. Конечно, не всем сразу, но каждые 6 месяцев мы пересматриваем те или иные решения, принятые раньше.
Тренды и тенденции
Мы не зависим от последних трендов и тенденций, но все же следим за тем, что происходит в мире.
Мы всегда открыты к возможным изменениям, даже если речь идет о нашем самом ценном программном обеспечении, созданном собственными силами.
Еще один важный урок, который мы хорошо усвоили, заключается в том, что технические обзоры, которые мы возглавляем, должны включать конечных пользователей, например, ученых по данным или аналитиков.
Пример
Недавно мы решили сравнить нашу систему Airflow (мы используем Composer) с другими решениями, существующими на рынке, или развернуть ее в нашем кластере Kubernetes и поддерживать самостоятельно.
Для этого мы задействовали группу из нескольких человек, обладающих разным опытом использования Airflow.
Поскольку эти специалисты чувствовали себя сопричастными, они с радостью делились своим опытом и содействовали выработке коллективного решения, затрагивающего абсолютно всех в нашей компании.
Обязательно отмечайте успехи
Как и любая инфраструктурная команда, Вы будете получать обратную связь только в том случае, когда что-то пойдет не так. Кто-нибудь из Вас хоть раз отправлял своей инфраструктурной команде что-нибудь подобное: "Привет! Я сел за компьютер, и пока все идет хорошо. Отличная работа, спасибо!"? Инфраструктурные команды - это герои «в тени», и их миссия заключается в том, чтобы надежность воспринималась как нечто само собой разумеющееся.
Если Вы руководите такой командой, Вам очень важно отмечать успехи, связывать их с проектами остальных подразделений и рассказывать о них. Ведь за каждым успешным бизнесом стоит качественная инфраструктура. Это очень важно не только для поддержания морального духа самой команды, но и для демонстрации потенциальным заинтересованным сторонам, где они могут помочь.
Пример
Придумывая названия проектов в нашей дорожной карте, мы обязательно указываем их влияние на бизнес-проекты в целом. Например, "поддержка [некоего подразделения] в создании обратного ETL для расчета вероятности [определенного бизнес-кейса]". Подобное название придает смысл техническому проекту.
Как и в любой команде, общение - это ключ к обмену опытом и празднованию совместных достижений.
Заключение
Два года назад мы внедрили парадигму data mesh в BlaBlaCar. Оглядываясь назад, можно совершенно точно сказать, что наличие команды платформы данных позволило нам реализовать чисто технические проекты, которые без нее были бы невозможны. Это повлияло на продуктивность наших доменных подразделений и, следовательно, на бизнес в целом.
Выделение ресурсов для подобной команды способствует обмену опытом и сотрудничеству внутри компании.
Для поддержания баланса необходимо следить за тем, чтобы на регулярной основе выполнялись следующие условия: стремление к содействию, а не навязыванию своего видения; определение приоритетных направлений деятельности; работа с широким кругом задач и накопление общих знаний и опыта внутри команды платформы данных.
