В последнее время все чаще звучит вопрос: какую технологию использовать для Data Mesh — Databricks, AWS, Snowflake или Open-Source-решения? Команда VK Cloud перевела статью с подсказками о том, как выбирать подходящие технологии и оценивать их применение в вашем конкретном случае.

Data Mesh — это парадигма, а не архитектура

Разные компании реализуют Data Mesh на основе разной архитектуры, потому что Data Mesh — это не архитектура, а стиль. Можно использовать любые технологии в разных сочетаниях и разными способами — и это все еще будет Data Mesh. Можно сказать, что это «микросервисы для аналитических данных».  

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

Владение доменом 

Для организации принципа Domain Ownership дата-продукты объединяют в группы на основании не технических границ, а принадлежности к потокам создания ценности. При этом важно, чтобы отдельная команда каждого дата-продукта могла отслеживать собственные пайплайны и политики наряду с хранением данных и выходными портами — например, API.

Данные как продукт

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

Self-service-платформы данных

Желательно, чтобы командам не приходилось все время изобретать колесо, когда речь заходит об инфраструктуре. Это трата времени и сил, которая отвлекает от создания классных дата-продуктов. Платформа Self-service расширяет возможности разработчиков, автоматизируя решение задач по предоставлению ресурсов. 

Федеративное управление вычислительными ресурсами 

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

Соответствие принципов функциям и технологиям

Мы изложили основные принципы Data Mesh, теперь можно сопоставить их с функциями. Для простоты я объединю владение доменом и данные как продукт и буду называть их дата-продуктами.

Далее я расскажу о подходящих инструментах: 

Платформа:

1. Предоставление общих функций (API, UI, код коннектора). Инструменты Infrastructure as Code, такие как Terraform, Ansible или CloudFormation и т. п. Типовой API платформы данных. Инструменты непрерывной интеграции, такие как Jenkins.
   
2. Функции потоковой обработки. Инструменты: Kafka, MQ, Flink, Kinesis.
   
3. Портал для разработчиков (полная интеграция). Полностью внутрикорпоративный или созданный с помощью Spotify Backstage или похожего решения.
   

Governance:

1. Каталог: индекс документов и метаданных, программы-обходчики для поиска информации. Инструменты Wiki, например Confluence (для базового каталога). Коммерческие каталоги, такие как Collibra или Open-Source-альтернативы: Amundsen, DataHub.
   
2. Стандарты данных и API. Инструменты Data Governance, Wiki, Swagger, Open Data Protocol.
   
3. Политики доступа. Wiki, метаданные для каталога, реализация отдельной политики, скорее всего в дата-продуктах. OPA или аналог для пользовательских API для HTTP или интегрированные инструменты. Ranger для Hadoop.
   
4. Мониторинг и автоматический комплаенс. Инструменты Data Governance. Инструменты и библиотеки наблюдаемости данных, такие как Great Expectations.io, внутрикорпоративные дашборды.
   
5. Data lineage. Инструменты Data Lineage или инструменты Data Governance с интегрированным lineage. Также они могут быть в ETL (например, Pachyderm) или хранилище (например, в озере данных).
   
6. Интеграция IDM. Пользовательский код или коннекторы в инструментах хранения данных.
   

Данные как продукт:

1. Хранилища данных. Базы: SQL, NoSQL, графовая БД, Search.
   
2. Порты ввода и вывода. Пользовательские API, инструменты ETL, коннекторы. Например, плагины для потокового ввода или для вывода BI или отчетности.
   
3. Интеграция между продуктами. Инструменты визуализации данных, Starburst.io, инструменты облачного провайдера или готовые платформы данных.
   

Подробнее изучить все эти типы инструментов можно в моем обзоре на GitHub.

Кое-что о владении данными

Владение данными не сопоставляется с функциями напрямую — это скорее вопрос организационных практик и процессов. Но это не значит, что в контексте реализации Data Mesh о нем нечего сказать. Здесь будут особенно полезны такие методологии, как Domain-driven design, Event storming, топологии команд, сценарии использования и Discovery workshops.

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

Важно отметить, что вам может понадобиться целый ряд функций. На сложном и «зрелом» конце этого спектра располагается портал ресурсов для разработчиков, где все предоставляется автоматически. Это своего рода мастер настройки для создания новых дата-продуктов. В нем легко выбирать нужные технологии для хранилища данных, портов ввода-вывода, коннекторы и многое другое. В сущности, именно это Жамак Дегани называет Experience plane. Если не знаете, что это, посмотрите вебинар Lessons From the Trenches in Data Mesh.

Трудно построить портал ресурсов для разработчиков, но делать это совсем не обязательно. На облегченном конце спектра лежат просто шаблоны начальной загрузки инфраструктуры для дата-продуктов и Wiki для каталога данных. И они могут оказаться весьма эффективными. На 52-й минуте упомянутого вебинара Жамак Дегани предлагает внедрять API-платформы как можно раньше, даже если изначально они делают не все, что вам бы хотелось. Можно начать с простых вариантов и постепенно добавлять нужные компоненты к платформе по мере необходимости. 

Можно ли использовать готовые решения

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

Если вы присматриваетесь к готовому решению, следует учитывать несколько нюансов: 

1. Готовые платформы данных основываются на сервисах или функциях, а не на дата-продуктах. В них нельзя создать данные как продукт с определенным хранилищем, портами вывода и т. п. Так что настоящую парадигму Data Mesh невозможно реализовать в готовых платформах данных. 
   
2. У готовых платформ нет концепции пользовательских API для данных. Возможно, у них есть универсальные API, но, если разработчику нужно написать код, чтобы выявить пользовательский API для данных или для модели машинного обучения, ему, возможно, придется выйти за пределы платформы. 
   
3. Их ETL-философия не многоязычна: чаще всего они чрезмерно категоричны, а их интеграции ориентированы на исходное хранилище и метаданные платформы. 
   
4. Они предлагают универсальный подход без возможности выбирать нужные разработчикам инструменты. 
   
5. У мультитенантной модели на базе аккаунтов может быть масса ограничений. Если делать множество операций в одном облачном аккаунте, вы, скорее всего, достигнете предела. Эту тему тоже обсуждали на вебинаре Lessons from the trenches in Data Mesh.
   

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

Как выбрать технологию для Data Mesh

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

Использовать ли готовую платформу данных или создавать свою собственную? 

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

Нужен ли UI платформы данных? Или можно обойтись API или даже просто некоторыми руководствами и шаблонами?

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

Нужно ли вам Governance, которое охватывает политики и мониторинг?

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

Самый важный совет — как можно раньше выявить ключевые сценарии использования. Если вы попробуете оценить инструменты, не осознавая сценарии использования, вы не поймете, какую задачу пытаетесь решить. Не углубляйтесь в поиск «самых лучших» инструментов для «идеальной» реализации Data Mesh: это задача, которую в принципе нельзя решить окончательно. Нужно четко представлять, чего вы пытаетесь достичь, и тогда вы сможете найти инструменты, которые оптимально вам подходят.
 

Команда VK Cloud развивает собственные Big Data-решения. Будем признательны, если вы их протестируете и дадите обратную связь. Для тестирования пользователям при регистрации начисляем 3000 бонусных рублей.