Адам Беллемар, технолог компании Confluent, в прошлом инженер платформы данных в Shopify, Flipp и BlackBerry, рассказывает на портале The New Stack, как сетка данных (Data Mesh) стратегически решает проблемы организации работы с данными.

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

Так называемая демократизация данных в значительной степени не оправдала своих надежд. Доступ к данным все еще затруднен, и зачастую они представляют собой нечто вроде «дотянись и возьми сам». Это ведет к анархии данных.

Именно здесь на помощь приходит сетка данных.

Концепция Data Mesh была разработана более года назад Жамак Дехгани, консультантом по технологиям компании Thoughtworks, чтобы исправить то, что она считает серьезными недостатками в способах получения и потребления данных в современном деловом мире.

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

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

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

Итак... Что это такое?

В настоящее время данные непрерывно генерируются практически в каждой точке организации. Это привело к широкому распространению обработки потока событий (ESP) — практики принятия мер в отношении серии точек данных, которые исходят от системы, никогда не прекращающей генерировать данные. («Событие» относится к каждой точке данных в системе, а «поток» — к непрерывной доставке этих событий.)

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

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

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

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

Типичное хранилище данных имеет множество источников, разбросанных по всей компании, с разным уровнем качества. Существует множество заданий ETL (извлечение, преобразование, загрузка), выполняемых в различных системах и возвращающих наборы данных в центральное хранилище. Команды аналитиков очищают и исправляют бóльшую часть данных, извлечение и загрузка занимают оставшееся время.

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

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

Мы пытались справиться с этим быстро растущим объемом данных с помощью таких решений, как Apache Hadoop. Но те из нас, кто работает с данными, к сожалению, хорошо знакомы с нехваткой последовательных, стабильных и четко определенных данных. Это часто проявляется в виде диспропорций в аналитической отчетности: например, аналитики сообщают, что было проведено 1100 взаимодействий с продуктом, но клиенту был выставлен счет за 1123 взаимодействия. Операционные и аналитические системы не всегда совпадают, и это в значительной степени связано с получением данных из различных источников.

Архитектуре данных часто не хватает строгости, и она развивается ситуативно, без той дисциплины и структуры, каких нам хотелось бы. Пользователи знают, что когда они обращаются к озеру данных, чтобы взять данные для дальнейшей обработки и анализа, получаемая информация может быть «хрупкой». Старое ПО может казаться надежным, но при получении необычных данных или их изменении оно дает сбой. И по мере того, как ПО в конкретном проекте становится все более крупным и расширяет базу пользователей, которые с ним работают, оно становится все менее гибким.

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

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

Нервная система для данных

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

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

Данные больше не рассматриваются как побочный продукт приложений, вместо этого они рассматриваются как четко определенный самостоятельный продукт (data product). Рассматривайте сетку данных как противоположность хранилищу данных. Продукты данных — это источники хорошо сформированных данных, которые распределены по всей компании, и каждый из них рассматривается как первоклассный продукт в своем собственном праве, с выделенным правом собственности, управлением жизненным циклом и соглашениями об уровне обслуживания. Идея заключается в том, чтобы тщательно разработать, курировать и представить их остальной части организации в качестве продуктов для потребления другими командами, обеспечивая надежный и заслуживающий доверия источник для обмена данными в рамках всей организации.

Потоки событий — это оптимальное решение для работы с подавляющим большинством продуктов данных. Они представляют собой масштабируемый, надежный и долговечный способ хранения и передачи важных бизнес-данных и преодоления постоянно увеличивающегося разрыва между аналитической и оперативной обработкой. Они предоставляют потребителю контроль над постоянно обновляемой копией данных, доступной только для чтения, для обработки, перемоделирования, хранения и обновления по своему усмотрению (вспомните микросервисы).

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

Но реализация сетки данных — это еще не все, также важно понимать следующее:

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

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

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