Объяснение современных архитектур данных
Как профессионал в области данных, я стал свидетелем удивительной эволюции в области использования и обработки данных, произошедшей за последние 15 лет. За это время появилось множество мощных концепций и инновационных архитектур данных, каждая из которых обещала решить растущие сложности современного управления данными. В этой статье мы рассмотрим наиболее заметные тенденции, изучим их сильные и слабые стороны, а также влияние на будущее архитектуры данных.
Введение
Ландшафт данных превратился из нишевой области в центральную опору современной корпоративной деятельности. Давайте сделаем краткий обзор того, как все происходило.
Корпоративные данные: В 2010 году я работал с хранилищем данных объемом 1,5 ПБ - в то время это было что-то нереальное, находящееся за пределами кругов Big Tech. Перейдем к сегодняшнему дню - управление десятками и даже сотнями петабайт данных стало обычным делом для крупных предприятий. Такие компании, как Snowflake и Databricks, регулярно обрабатывают экзабайты данных о клиентах. Мы наблюдаем фундаментальный переход от пакетных процессов к потоковым данным в реальном времени, которые поступают из самых разных источников, таких как устройства IoT и транзакционные системы. Кроме того, возросло разнообразие данных, требующее от нас обработки всего: от структурированных табличных данных до неструктурированных форматов, таких как аудио и видео.
Хранение: В то время системы хранения данных были медленными и непомерно дорогими, часто ограничивались большими серверами баз данных, подключенными по SAN к устройствам обработки данных от таких производителей, как EMC, HP или Fujitsu. Приобретение дополнительной емкости могло занять месяцы. Сегодня твердотельные накопители стали товаром, расширяемое по требованию объектное хранилище доступно практически каждому по меньшей цене.
Сетевое взаимодействие: Сетевые возможности также были ограничены: большинство бэк-офисных сетей работали на 1G Ethernet, а 10G и Infiniband из-за их высокой стоимости предназначались только для высокопроизводительных кластеров. В отличие от этого, в современных облачных инфраструктурах обычно используются сети 40 и 100 Гбит/с, что значительно повышает пропускную способность и задержку передачи данных.
Вычисления: В то время в обработке данных доминировали большие SMP-серверы таких производителей, как SUN, Fujitsu и HP, а кластерные вычисления все еще находились в зачаточном состоянии. Массивные хранилища данных полагались на дорогостоящие MPP-устройства, такие как Netezza, Vertica или Greenplum. Однако это уже не так, поскольку достижения в области распределенных вычислений демократизировали доступ к масштабируемым высокопроизводительным вычислительным ресурсам.
Несмотря на эти серьезные технологические достижения, многие предприятия по-прежнему сталкиваются с проблемами, которые сохраняются уже более десяти лет, только в гораздо больших масштабах:
- Предоставление достоверных данных клиентам наиболее эффективным и надежным способом.
- Интеграция данных из разрозненных источников - и без того сложная задача при работе с внутренними системами - становится еще сложнее, когда в нее включаются системы, приобретенные в результате слияний и поглощений.
- Эффективное управление данными остается труднодостижимой целью, а традиционные модели управления данными часто оказываются непрактичными и во многих случаях становятся узкими местами, а не помощниками.
Архитектура данных это дисциплина, определяющая методы построения сложных систем обработки данных. Когда-то это была относительно простая задача, включающая сочетание инструментов ETL и хранилища данных с выбором между моделями Инмона или Кимбалла, теперь она более сложной и изощренной.
Итак, на какие основы мы можем опираться в сегодняшнем сложном ландшафте? Давайте рассмотрим наиболее популярные парадигмы:
- Data Lake
- Виртуализация данных
- Современное DWH
- Ткань данных
- Платформа данных
- Data Lakehouse
- Data Mesh
Data Lake
Термин «Data Lake» был введен в 2011 году Джеймсом Диксоном, директором по технологиям компании Pentaho. Озеро данных позволяет проводить масштабную аналитику, предоставляя единое хранилище для всех данных из различных источников, которые могут понадобиться любому сотруднику организации для анализа. Его также можно представить как универсальную файловую систему, хотя это скорее паттерн проектирования, чем архитектура данных. Этот паттерн приобрел популярность с появлением доступных и масштабируемых решений для хранения данных, таких как распределенная файловая система Apache Hadoop Distributed File System (HDFS). Сегодня более современные реализации хранят данные в облачных распределенных объектных хранилищах, таких как Amazon S3 или Azure Data Lake Storage (ADLS) Gen 2, которые составляют основу большинства крупномасштабных платформ данных..
Эволюция централизованного хранилища
Хотя централизованное хранение данных не является чем-то новым, ключевым нововведением в «озерах данных» является отделение хранения от вычислений. Исторически сложилось так, что из-за ограниченной емкости традиционных хранилищ данных компании выгружали огромные объемы данных в виде плоских файлов в сетевые хранилища (NAS), такие как EMC Isilon. Однако для анализа этих данных требовалось сначала загрузить их в реляционную базу данных.
В отличие от этого, Hadoop с самого начала был разработан для обработки крупномасштабных данных непосредственно из объектных хранилищ. Изначально для этого использовался фреймворк map-reduce, а позже - более продвинутые инструменты, такие как фреймворк Spark и SQL-движки, например Hive и Presto. Хотя озеро данных рассматривается в первую очередь как решение для хранения данных, всегда подразумевается, что широкий набор инструментов может осуществлять доступ и обработку данных внутри него.
Логическое зонирование в Data Lake
Данные в озере обычно организуются в несколько логических зон или слоев - такой подход в последнее время получил распространение под названием «медальонная» или «многоходовая» архитектура. Каждая зона озера предназначена для группировки данных со схожим жизненным циклом, шаблонами доступа, качеством и требованиями к безопасности. Эти зоны обеспечивают логическую изоляцию, что позволяет разрабатывать, внедрять и расширять их независимо друг от друга. Благодаря установлению четких логических границ зоны способствуют долгосрочному развитию архитектуры данных и остаются независимыми от поставщиков и продуктов. Хотя зоны могут быть адаптированы под конкретные нужды, обычно они организованы таким образом, чтобы постепенно улучшать структуру и качество данных по мере прохождения каждого уровня.
Самые распространенные зоны:
- «Зона посадки» данных: Необязательный посредник между вышестоящими системами и зоной сырых данных. Эта зона помогает вводить данные, сохраняя их целостность и ограничивая доступ и преобразование для бизнес-пользователей.
- Зона сырых данных: Эта зона ориентирована на эффективный ввод данных без преобразования, сохраняя их в родном формате. Она поддерживает несколько версий данных и ограничивает доступ бизнес-пользователей, чтобы предотвратить случайную перезапись.
- Зона подтвержденных (курируемых) данных: В этой зоне сырые данные преобразуются в проверенные наборы данных, часто маскирующие конфиденциальную информацию. Здесь размещаются основополагающие продукты данных, автоматизируются преобразования, данные хранятся близко к источнику, избегаются преобразования, специфичные для бизнеса, и соблюдается строгая политика хранения данных.
- Зона преобразования/обслуживания данны: Эта зона содержит продукты бизнес- и аналитических данных, подвергшиеся трансформации в соответствии с конкретной областью. Данные организованы с использованием бизнес-семантики, хранятся в оптимизированных моделях и разделены в соответствии с различными аналитическими потребностями. Для повышения производительности, контроля доступа и адаптивности зоны продуктов бизнес- и аналитических данных могут быть физически или логически разделены.
Преимуществ Data Lake:
- Экономическая эффективность. Озера данных обеспечивают значительную экономию средств в первую очередь благодаря гибкости и масштабируемости облачных решений по хранению данных.
- Эластичность. Современные облачные платформы обеспечивают практически безграничные возможности хранения данных по требованию, что избавляет от необходимости тщательного планирования и закупки мощностей. Такая эластичность позволяет организациям масштабировать свои операции с данными без особых усилий.
- Гибкость систем. Традиционные хранилища данных часто навязывают единую каноническую схему для всех аналитических нужд, что может быть непрактично для любых, кроме самых маленьких организаций. Озера данных, напротив, позволяют хранить необработанные данные в любой форме, которую предоставляет источник, без каких-либо предположений относительно схемы. Интерпретировать и структурировать данные в соответствии со своими конкретными задачами должны сами потребители данных.
- Управление качеством данных. Обеспечение качества данных в традиционных хранилищах данных требует обширного анализа для создания единого авторитетного источника, что может быть непрактичным и нежелательным. Неизменная природа исходных данных в озере в сочетании с их постоянной доступностью позволяет легко перерабатывать их для исправления ошибок в конвейерах обработки или для поддержки новых, возникающих требований.
Трудности и способы их решения:
- Достоверность данных. Каждый фрагмент данных в озере должен иметь четкое происхождение, включая отслеживание исходной системы и времени создания данных. Это необходимо для поддержания целостности данных и облегчения аудита.
- Выборочный доступ к сырым данным. Необработанные данные очень ценны, поэтому доступ к ним должен быть ограничен. Команды по работе с данными могут создавать карты данных по мере выявления ценных представлений данных, позволяя последующим пользователям рассматривать эти карты как авторитетные источники в конкретных контекстах.
- Ограничения, связанные с гибкостью. Централизованная команда по работе с данными, управляющая монолитным озером данных, может ограничить гибкость организации. Разделение архитектуры данных на отдельные конвейеры - вход, обработка и обслуживание - требует сложной координации для эффективного предоставления новых источников данных или решения новых задач.
- Данные как актив, а не как продукт. Данные в озере часто рассматриваются как актив, а не как продукт, что обычно приводит к отсутствию официальных соглашений об уровне обслуживания (SLA) или целей уровня обслуживания (SLO). Это может привести к проблемам в обеспечении надежности и подотчетности данных.
- Операционные тонкости. Такие межфункциональные возможности, как наблюдаемость трубопроводов, управление событиями и оркестровка заданий, часто не интегрированы в экосистему озера данных в качестве основных компонентов. Использование разрозненных технологий может затруднить создание целостной и надежной в эксплуатации системы озера данных, что приведет к потенциальной нестабильности.
Виртуализация данных/Федерация
Виртуализация данных или федерация формирует логический слой данных, который позволяет приложениям получать данные и манипулировать ими, не требуя детального знания базовых систем. Обычно он реализуется в виде определенного сервера виртуализации. Такой подход обеспечивает доступ к данным в режиме реального времени непосредственно из их источника, устраняя необходимость в перемещении или репликации данных. Это снижает риск ошибок и уменьшает нагрузку на управление неиспользуемыми данными. Важно отметить, что виртуализация данных не навязывает единую модель данных, а управляет унифицированными данными для обеспечения централизованной безопасности и управления.
Возможности виртуализации данных:
- Абстракция: Виртуализация данных абстрагирует уровень сложности, связанный с доступом к данным из различных базовых систем. Это включает в себя абстрагирование таких деталей, как местоположение, структура хранения, API, язык доступа и технология хранения, что упрощает взаимодействие приложений с данными.
- Виртуализированный доступ к данным: Эта возможность позволяет подключаться к различным источникам данных, включая базы данных, хранилища данных, облачные приложения, хранилища больших данных и даже файлы Excel, делая их доступными из единой логической точки доступа.
- Трансформация и Федерация данных: Виртуализация данных позволяет преобразовывать, переформатировать, улучшать качество данных, агрегировать информацию и объединять связанные данные в бизнес-представления, независимо от формата или источника. Эта возможность крайне важна для предоставления пользователям значимых, унифицированных представлений данных.
- Доставка данных в режиме реального времени: Поскольку виртуализация данных подключается к базовым источникам данных в режиме реального времени, она предоставляет актуальную информацию бизнес-пользователям. Такой доступ в режиме реального времени обеспечивается с помощью представлений и служб данных, выполняемых по требованию клиентских приложений или пользователей.
Преимущества виртуализации данных:
- Защита исходных систем. Изолируя критически важные исходные системы от прямого доступа пользователей и приложений, виртуализация данных помогает предотвратить непреднамеренные изменения данных.
- Доступ к данным в режиме реального времени. Виртуализация данных повышает скорость доступа к данным в режиме реального времени без дополнительных инвестиций в хранение, позволяя организациям более эффективно использовать существующую инфраструктуру данных.
- Оптимизированная обработка запросов. Виртуализация данных позволяет перенести обработку запросов на источник данных, а не на средний уровень. Это может привести к более эффективному выполнению запросов и снижению нагрузки на уровень виртуализации.
- Самостоятельный доступ к данным. Многие системы виртуализации данных позволяют конечным пользователям создавать виртуальные базы данных в режиме самообслуживания, обеспечивая прямой доступ к исходным системам без широкого участия ИТ-специалистов.
- Централизованное управление и безопасность. Виртуализация данных позволяет архитекторам применять централизованные политики управления данными и безопасности для всех источников данных, обеспечивая соответствие требованиям и снижая риск утечки данных.
- Эффективность ресурсов разработки. Подход к виртуализации данных на основе представлений упрощает разработку и снижает потребность в ручном кодировании, позволяя разработчикам сосредоточиться на масштабировании и ускорении доставки информации.
Трудности и способы их решения:
- Влияние на операционную систему. Виртуализация данных может негативно повлиять на время отклика операционных систем, особенно если уровень виртуализации недостаточно масштабирован для обработки неожиданных пользовательских запросов.
- Недостаточная степень управления историческими данными. Виртуализация данных не подходит для записи исторических снимков, что ограничивает ее полезность в критически важных сценариях анализа исторических данных.
- Сложность управления изменениями. Все приложения и пользователи, использующие один и тот же сервер виртуализации, должны принимать изменения, внесенные на уровне виртуализации данных, что усложняет управление изменениями.
- Несовместимость со сложными аналитическими запросами. Аналитические приложения часто требуют сложных объединений, сканирования таблиц и перетасовки данных, которые обычно несовместимы с шаблонами доступа, поддерживаемыми виртуализацией данных. В частности, эффективное выполнение межсистемных объединений может быть затруднено. Системе достаточно сложно определить стоимость своих планов выполнения. А сделать так, чтобы уровень федерации запросов точно предсказывал стоимость планов выполнения запросов в различных базовых системах, практически невозможно.
- Борьба за ресурсы. Пользовательские запросы с различными профилями выполнения будут конкурировать за ограниченные ресурсы сервера виртуализации, что может привести к конфликтам и узким местам в производительности.
- Высокий уровень безопасности. Обеспечение высокой степени безопасности для больших объемов бортовых данных может быть ресурсоемким. Во многих случаях зонирование безопасности для сегментации данных является более практичным подходом, поскольку оно сужает потенциальный объем хакерской атаки.
- Стоимость вычисления vs. Стоимость хранения. Хотя хранение данных больше не является существенной проблемой, вычисления по-прежнему требуют ресурсов. Во многих сценариях материализация некоторых преобразований (предварительная обработка и хранение данных) будет менее затратной, чем их выполнение на лету каждый раз.
- Вопросы, связанные с высокой доступностью. С точки зрения высокой доступности виртуализация данных представляет собой единую точку отказа, что может стать серьезным риском для организаций, которые в значительной степени зависят от постоянного доступа к виртуализированным данным.
Современный DWH
Tрадиционные DWH уже несколько десятилетий являются основой бизнес-аналитики, обеспечивая надежное управление структурированными данными. Однако зачастую они сталкиваются с проблемами стоимости, масштабируемости и гибкости. Появление озер данных позволило устранить некоторые из этих ограничений, обеспечив гибкое и масштабируемое решение для хранения данных различных типов. Сочетая ценность для бизнеса и производительность реляционных хранилищ данных с гибкостью озер данных, организации могут использовать сильные стороны обеих технологий в современной архитектуре данных.
Интеграция Data Lake и DWH
В современной архитектуре озеро данных фактически заменяет традиционную область хранения данных, а также классические процессы ETL. Оно служит центральным узлом для ввода данных, обрабатывает масштабные преобразования данных, включая гармонизацию данных и материализацию продуктов данных. Затем бизнес-ориентированные наборы данных публикуются в реляционном хранилище данных, обычно структурированном в размерной модели, для поддержки отчетности и возможностей бизнес-аналитики (BI). Одновременно озеро данных может использоваться для обучения моделей машинного обучения (ML) и поддержки расширенной аналитики.
Хотя любая реляционная база данных может содержать размерные данные (для этих целей часто используется PostgreSQL), современные реляционные решения для хранения данных, такие как Snowflake, Databricks, Azure Synapse Analytics, Google BigQuery и Amazon Redshift, имеют определенные преимущества. Эти платформы отделяют хранение данных от вычислений, обеспечивают эффективную интеграцию с объектными хранилищами и обеспечивают превосходную производительность при работе с большими объемами данных.
Преимущества архитектуры современного DWH:
- Универсальность в работе с данными: Эта архитектура может эффективно управлять различными форматами данных, включая структурированные, неструктурированные и потоковые данные.
- Оптимизированная отчетность и производительность BI: Современное хранилище данных обеспечивает более высокую производительность запросов по сравнению с SQL-движками, обычно используемыми в озерах данных, и обеспечивает лучшую интеграцию со стандартными инструментами отчетности и BI.
- Эластичная масштабируемость: Разделение хранения и вычислений обеспечивает эластичную масштабируемость, позволяя архитектуре легко справляться с растущими объемами данных.
- Аналитика в режиме реального времени: Архитектура поддерживает аналитику данных в реальном времени, позволяя предприятиям принимать своевременные решения на основе самых актуальных данных.
- Улучшенная производительность конвейеров данных: Современные конвейеры данных и облачные ETL-инструменты работают значительно лучше, чем традиционные ETL-процессы.
- Гибкое моделирование данных: Эта архитектура поддерживает гибкое моделирование данных, включая схему при чтении и эволюцию схемы, что позволяет организациям адаптироваться к изменяющимся требованиям к данным.
- Экономическая эффективность: Выполняя преобразования данных в рамках озера данных, организации могут потенциально сократить расходы, связанные с обработкой данных.
- Повышенная безопасность данных: Архитектура позволяет лучше контролировать безопасность данных с помощью стандартных механизмов управления доступом на основе ролей (RBAC).
Потенциальные недостатки современной архитектуры хранилищ данных:
- Повышенный уровень сложности: Гибридный характер этой архитектуры создает дополнительную сложность, требуя оркестровки нескольких технологий. Полная реализация потенциала этой архитектуры требует наличия специализированного и разнообразного набора навыков, что может привести к проблемам с наймом персонала, увеличению потребности в обучении и повышению стоимости обслуживания.
- Дублирование данных и управление ими: Несмотря на относительно низкие затраты на хранение данных, управление данными в озере данных и реляционном хранилище данных может быть сложным. Такая архитектура часто требует определенного уровня дублирования данных, что может усложнить работу по управлению данными и их синхронизации.
- Проблемы с соблюдением нормативных требований: Общая сложность системы может привести к возникновению проблем с соблюдением нормативных требований, особенно в средах, где требуется сертификация по таким стандартам, как PCI DSS или HIPAA. Обеспечить соответствие всех компонентов архитектуры нормативным требованиям может быть непросто.
Ткань данных
Gartner определяет ткань данных как концепцию, которая выступает в качестве интегрированного слоя (или «ткани») данных и взаимосвязанных процессов. Ткань данных использует непрерывную аналитику существующих, обнаруживаемых и предполагаемых активов метаданных для облегчения разработки, развертывания и использования интегрированных и многократно используемых данных в различных средах, включая гибридные и мультиоблачные платформы.
Пять ключевых столпов ткани данных
- Расширенный каталог данных: Система данных должна собирать и анализировать все формы метаданных, используя автоматизацию AI/ML для расширения и поддержания всеобъемлющего каталога данных.
- Граф знаний, обогащенный семантикой: Сеть данных должна создавать и курировать графы знаний, обеспечивая расширенную аналитику связанных метаданных с помощью алгоритмов AI/ML. Эти графы знаний обеспечивают семантическое понимание взаимосвязей данных, повышая полезность и доступность данных.
- Активация метаданных и механизм рекомендаций: Процессы с помощью AI/ML преобразуют пассивные метаданные в активные метаданные. Эти активные метаданные затем используются для рекомендаций, оптимизации использования данных и улучшения процессов принятия решений.
- Подготовка и доставка данных: Надежная основа для интеграции данных с помощью ИИ является важнейшим элементом структуры данных. Она обеспечивает эффективную подготовку, очистку и доставку данных, поддерживая аналитику и операционные приложения в режиме реального времени.
- Оркестровка и DataOps: структура данных должна автоматизировать оркестровку данных с помощью AI/ML, оптимизировать операции с данными (DataOps) и обеспечивать беспрепятственный поток данных между различными платформами и средами.
Ткань данных не зависит от платформы, то есть она может работать с различными платформами развертывания, методами обработки данных, подходами к доставке данных, местоположением и архитектурными стилями. Она абстрагирует сложность управления различными средами данных, облегчая использование данных в качестве стратегического актива. Таким образом, ткань данных обеспечивает эффективное объединение, доступ, совместное использование и управление любыми данными, независимо от их происхождения и платформы..
Преимущества внедрения ткани данных:
- Улучшенная интеграция и подключение данных: Ткань данных интегрирует и соединяет все данные организации, обеспечивая беспрепятственный обмен данными и улучшая бизнес-результаты благодаря более обоснованному принятию решений.
- Ускоренное обнаружение данных в режиме самообслуживания: Благодаря легкому доступу к надежным данным сеть данных ускоряет процесс самостоятельного обнаружения данных и аналитики, позволяя потребителям данных быстрее получать информацию.
- Аналитика в режиме реального времени: Оптимизация жизненного цикла данных с помощью структуры данных позволяет проводить аналитику и аналитические исследования в режиме реального времени, что обеспечивает более оперативную разработку приложений, основанных на данных.
- Сокращение расходов на управление данными: Интеллектуальная автоматизация в рамках структуры данных снижает затраты и усилия, связанные с задачами управления данными, такими как повышение качества данных, их хранение, классификация данных и применение политик.
- Автоматизированная оркестровка и масштабирование: Ткань данных автоматизирует оркестровку рабочих нагрузок, эластичное масштабирование, самонастройку и самовосстановление, обеспечивая готовность заданий к работе в любой среде и с любым объемом данных.
- Обогащенные активы данных: Ткань данных автоматически связывает обнаруженные активы данных и обогащает их знаниями и семантикой, помогая потребителям находить, понимать и использовать данные более эффективно.
Трудности и способы их решения
- Зрелость технологий: Большая часть технологий, необходимых для полной реализации концепции Gartner о сети данных, все еще находится в зачаточном состоянии или еще не разработана, что может ограничить немедленное внедрение комплексного решения сети данных.
- Качество метаданных: Эффективность сети данных в значительной степени зависит от качества собираемых метаданных. Если сбор метаданных в закрытой системе относительно прост, то интеграция метаданных из несовместимых систем разных поставщиков может оказаться весьма сложной задачей.
- Жесткие модели метаданных: В системах, предоставляемых поставщиками, часто используются жесткие модели метаданных, которые могут быть недостаточно гибкими, чтобы удовлетворить все потребности клиентов. Устранение этих ограничений может потребовать дорогостоящей настройки системы или, в некоторых случаях, вообще оказаться невозможным.
- Нормативные ограничения: В высокорегулируемых средах рассуждения на основе ОД могут быть неприемлемы из-за требований к человеческому контролю и надзору. Это может ограничить внедрение компонентов на основе ИИ/МЛ в структуру данных.
- Сложность получения знаний: Создание и поддержка полезного графа знаний по своей сути сложна и обычно требует специальных знаний. Во многих случаях этот процесс не может быть полностью автоматизирован, что требует значительного вмешательства человека и его опыта.
Хаб данных/Платформа данных
Хаб данных или платформа данных нацелены на интеграцию данных и поддержку передовой аналитики в масштабе. Она представляет собой хорошо интегрированный комплекс сервисов, не зависящих от конкретной области, которые обеспечивают поступление, интеграцию, преобразование, управление и доставку данных. Основная цель - дать организациям возможность эффективно проектировать, разрабатывать, внедрять, управлять, публиковать и потреблять продукты данных, которые приносят пользу бизнесу. Платформа отличается модульностью, гибкостью и экономичностью. Однако, учитывая разнообразие типов данных и специфические потребности бизнеса, создание универсальной платформы данных является сложной и дорогостоящей задачей. Вместо этого платформу данных следует рассматривать как концептуальный проект, реализуемый с помощью облачных компонентов или локальных сервисов, в зависимости от требований организации.
Ключевые принципы современной платформы данных:
- Менталитет «Данные как продукт»: Откажитесь от разрозненных систем и монолитных озер данных и относитесь к данным как к продукту. Каждый продукт данных разрабатывается с использованием возможностей платформы данных, не зависящих от домена, соответствует определенной области данных и должен соответствовать принципам FAIR (Findable, Accessible, Interoperable, and Reusable). Эти продукты данных также должны иметь опубликованные SLA/SLO и обязывать к «горизонтальному» сквозному управлению данными.
- Управление данными, ориентированное на домен: Переход от централизованного к федеративному управлению данными, ориентированному на домен. Этот подход использует такие возможности платформы, как наблюдаемость среды, для облегчения взаимодействия между заинтересованными сторонами и обеспечения соответствия методов управления специфическим потребностям каждого домена данных.
- Самообслуживание и общие сервисы: Платформа должна предоставлять возможности самообслуживания и общие сервисы, не зависящие от домена, такие как исследовательская среда, каталоги активов данных, система качества данных, оркестровка процессов, обработка событий, управление онтологиями и общими словарями, аудит и мониторинг, защита данных, общие механизмы обработки данных, а также поддержка операций с данными и разработкой.
- Инкрементная разработка: Создавайте платформу постепенно, постоянно проверяя развивающуюся архитектуру на соответствие стратегическим принципам управления. Такой подход позволяет платформе органично развиваться, обеспечивая при этом соответствие долгосрочным целям.
Ключевые модули платформы данных
Независимо от модели развертывания, каждая платформа данных состоит из пяти ключевых, слабо связанных между собой модулей:
- Хранение: Обеспечивает базовую инфраструктуру для хранения необработанных, обработанных и аналитических данных, поддерживает различные форматы данных и обеспечивает масштабируемость. В типичной реализации в качестве уровня хранения используется озеро данных. Однако, строго говоря, это не является обязательным условием. В качестве хранилища также могут использоваться реляционные или NoSQL-базы данных.
- Загрузка данных: Захват данных из различных источников, обеспечивающий своевременный и надежный сбор данных.
- Трансформация данных: Обеспечивает очистку, обработку и обогащение данных, подготавливая их к использованию аналитическими инструментами и приложениями.
- Обслуживание данных: Обеспечивает эффективное и доступное предоставление обработанных данных пользователям и приложениям, часто через API, информационные панели или другие интерфейсы.
- Общие дополнительные сервисы: Поддерживают общую работу платформы, включая сетевое взаимодействие, вычисления и дополнительные услуги, такие как безопасность, мониторинг и управление.
Основные возможности мультифункциональной платформы данных
- Фреймворки для разработки: Предоставление многократно используемых компонентов, которые абстрагируют общие функциональные возможности и интегрируются с другими сервисами платформы. Эти фреймворки должны включать стандартные шаблоны для конвейеров DevOps, что позволит сократить количество шаблонного кода, упростить процесс адаптации новых членов команды и упростить разработку конвейеров ввода и преобразования данных.
- Каталог данных: Управление техническими и бизнес-ориентированными метаданными, обеспечивающее регистрацию всех артефактов данных (исходных, производных и продуктов данных) в этом каталоге. Каталог должен включать подробное описание форматов данных, схем, происхождения, классификации чувствительности, версионности, SLA/SLOs, атрибутов качества, статистики, таксономии, требований к хранению, архивированию и собственности. Она также должна обеспечивать возможность обнаружения и выборки продуктов данных.
- Подсистема обработки событий и уведомлений: Обеспечивает основу для асинхронной обработки данных, управляемой событиями, позволяя наблюдать за окружающей средой, обрабатывать сложные события, планировать на основе событий и распространять уведомления по всей системе.
- Оркестровка процессов: Поддержка сложного планирования конвейеров, отслеживание зависимостей между заданиями, разработка рабочих процессов, управление отказами и повторными попытками выполнения заданий, что обеспечивает бесперебойное и эффективное выполнение процессов обработки данных.
- Исследовательская среда: Среда самообслуживания для специалистов по исследованию данных, инженеров по обработке данных и команд по работе с данными, поддерживающая поиск, обнаружение, создание прототипов продуктов данных, обучение ML-моделей и их проверку.
- Аудит и мониторинг: Внедрите единую систему мониторинга, обеспечивающую проверку состояния платформы в режиме реального времени, генерацию предупреждений, операционные панели, аудит доступа для обеспечения соответствия нормативным требованиям, анализ журналов после смерти и отслеживание активности.
- Защита данных: Интеграция с системами управления идентификацией и доступом (IAM) для защиты данных от несанкционированного доступа. Это включает в себя управление согласованными политиками безопасности, токенизацию, шифрование и маркировку данных.
- Качество данных и управление: Обеспечьте основу для анализа качества данных, профилирования и сканирования на соответствие политикам. Система должна генерировать предупреждения, связанные с качеством, поддерживать рабочие процессы управления и обеспечивать надежность и достоверность данных.
- Управление справочными данными: Обеспечивает междоменную стандартизацию и гармонизацию данных, управление справочными данными, онтологиями и таксономиями в масштабах всего предприятия. Платформа должна способствовать декларативной проверке атрибутов, сопоставлению контекста и концепций, а также предоставлять механизм вывода и разрешения правил.
Трудности, связанные с созданием мультифункциональной платформы
- Сложность: интеграция и адаптация к тонкостям конкретных бизнес-процессов при управлении множеством сервисов от разных поставщиков может быть очень сложной. Однако для перехода на современную платформу не обязательно начинать с самых передовых инструментов и систем. Принятие стратегии постепенного роста с четкой ориентацией на конечную цель имеет решающее значение для создания надежной и эффективной платформы.
- Стоимость: Создание сложной платформы данных обычно требует значительных инвестиций, зачастую исчисляемых миллионами долларов. Такие первоначальные инвестиции оправданы только в том случае, если платформа необходима для поддержки масштабных операций. Важно определить области с наиболее значительным потенциальным влиянием и постоянно согласовывать решения с соображениями окупаемости инвестиций (ROI). Поскольку цели организации могут меняться со временем, разработка платформы должна основываться на таких фундаментальных принципах, как эволюционная архитектура и разделение задач.
- Управление людьми и изменениями: Переход от традиционных разрозненных ИТ-операций к услугам, не зависящим от домена, и подходу, ориентированному на продукты данных, может оказаться сложной задачей. Продуманная интеграция управления организационными изменениями в траекторию роста платформы просто необходима. Мониторинг внедрения платформы и обеспечение ее эффективного использования в организации также крайне важны. Установление непрерывной обратной связи с пользователями обеспечит развитие платформы в соответствии с их потребностями и ожиданиями. Даже самая совершенная платформа не сможет работать, если ее не будут эффективно использовать. Приоритетное внимание к опыту пользователей и всестороннее обучение являются решающими факторами в преодолении этого разрыва. Кроме того, ландшафт платформ данных быстро развивается, регулярно появляются новые инструменты, фреймворки и лучшие практики. Поддерживать платформу в актуальном состоянии и внедрять инновации, не нарушая существующие операции, очень непросто.
Data Lakehouse
Концепт Data Lakehouse был представлен командой Databricks и популяризирован Биллом Инмоном в его книге «Создание озера данных». Сегодня эта идея широко распространена среди крупнейших игроков в области управления данными, включая Microsoft, Amazon, Dremio, Starburst и других. Архитектура Data Lakehouse сочетает в себе масштабируемость и экономическую эффективность озера данных с аналитической инфраструктурой, традиционно ассоциируемой с хранилищами данных. Такой гибридный подход позволяет более эффективно считывать, обрабатывать и понимать данные, используя при этом недорогие решения для хранения, обычно применяемые в озерах данных.
Основные принципы Data Lakehouse:
- Использование существующей инфраструктуры озера данных: По возможности используйте существующую инфраструктуру озера данных, храня данные в недорогих хранилищах, таких как Amazon S3, Azure Blob Storage или Google Cloud Storage. Для обеспечения совместимости и гибкости данные следует хранить в открытых форматах, таких как CSV, Parquet и ORC.
- Обеспечение согласованности данных с помощью ACID-транзакций: Используйте такие технологии, как Delta Lake или Apache Iceberg, для обеспечения согласованности данных с помощью транзакций ACID (Atomicity, Consistency, Isolation, Durability), часто управляемых с помощью SQL.
- Поддержка внедрения и эволюции схем: Хранилище данных должно поддерживать внедрение и эволюцию схем, позволяя использовать такие архитектуры схем хранилищ данных, как схемы типа «звезда» и «снежинка».
- Реализация механизмов управления и аудита: Добавьте функции управления и аудита, включая тонкий контроль доступа на основе ролей. Обеспечьте возможность манипулирования данными через различные API (Scala, Java, Python, SQL), чтобы соответствовать таким нормативным требованиям, как GDPR и CCPA.
- Разделение хранения и вычислений: Архитектура должна обеспечивать независимое масштабирование ресурсов хранения и вычислительных ресурсов, позволяя одновременно работать с большим количеством пользователей и большими массивами данных без снижения производительности.
- Обеспечение прямого доступа к данным: Обеспечьте прямой доступ к необработанным, обработанным и агрегированным данным для инструментов бизнес-аналитики (BI). Это уменьшает застойность данных, повышает их свежесть, снижает задержки и минимизирует затраты на поддержание отдельных копий данных в озере и хранилище.
- Поддержка API-интерфейсов, отличных от SQL, для обработки данных: Включите эффективные декларативные API, не связанные с языком SQL, например API, подобные DataFrame, чтобы специалисты по исследованию данных могли напрямую обращаться к большим объемам данных и обрабатывать их, особенно в экспериментах по машинному обучению с использованием библиотек R и Python.
- Поддержка открытых форматов данных и API: Поддержка открытых форматов данных и API, обеспечивающих прямой доступ к данным без использования проприетарных движков, что позволяет избежать привязки к поставщикам и обеспечивает долгосрочную гибкость.
- Обеспечение потоковой передачи данных и онлайн-аналитики: Поддержка потоковой передачи данных и онлайн-аналитики, устраняющая необходимость в отдельных системах для работы с данными в режиме реального времени.
Трудности и ограничения Data Lakehouse
Концепция Data Lakehouse больше похожа на прагматичную попытку кодифицировать существующий статус-кво, чем на архитектуру, подкрепленную последовательным анализом проблем. Поскольку эта концепция не является революционной, барьер для ее внедрения невелик, и почти все поставщики утверждают, что реализуют ее. Хотя эта концепция получила значительное распространение, у нее есть определенные ограничения, которые могут помешать ее эффективности:
- Ориентация на технологии: Подход Data Lakehouse в первую очередь фокусируется на технологических решениях, зачастую упуская из виду важность людей и процессов в управлении данными. Эффективные платформы данных требуют целостного подхода, объединяющего технологию с организационной практикой и культурой.
- Ограниченное внимание к силосам данных и согласованию бизнеса: В то время как «Озеро данных» делает акцент на открываемости данных, оно, как правило, игнорирует проблемы, связанные с разрушением изолированности данных и согласованием активов данных с бизнес-целями. Также не уделяется достаточного внимания жизненному циклу данных, соглашениям об уровне обслуживания (SLA) и целям уровня обслуживания (SLO).
- Централизованное управление против гибкости: Централизованное управление и применение схем, присущие Data Lakehouse, могут препятствовать гибкости организации. Быстрая адаптация крайне важна по мере развития бизнеса, а жесткие структуры управления могут стать узким местом.
- Неадекватное решение проблем интеграции данных: Хотя Data Lakehouse предоставляет технические возможности для масштабной трансформации данных, она не в полной мере решает важнейшие задачи интеграции данных, такие как управление сложностью данных, метаданными и правилами контекстного сопоставления. Это важнейшие компоненты для создания действительно интегрированной и пригодной для практического использования платформы данных.
Data Mesh
Data Mesh - это относительно новая концепция управления данными, представленная как социотехнический подход к обмену, доступу и управлению аналитическими данными в сложных, масштабных средах - как внутри организаций, так и между ними. По данным Gartner, в настоящее время Data Mesh находится на пике завышенных ожиданий, что подчеркивает растущий интерес к ней и пристальное внимание к ней. Важно отметить, что Data Mesh - это не архитектура данных в традиционном понимании, а скорее изменение парадигмы подхода организаций к владению, управлению и руководству данными.
Фундаментальные изменения, внедренные Data Mesh
- Организационный сдвиг: Data Mesh выступает за переход от централизованного владения данными, традиционно управляемого специализированными командами, к децентрализованной модели, в которой владение данными и ответственность за них переносятся в бизнес-области, где эти данные возникают или наиболее активно используются.
- Архитектурный сдвиг: Вместо того чтобы полагаться на монолитные хранилища или озера данных, Data Mesh предлагает распределенную систему, в которой данные подключены и доступны через стандартизированные протоколы. Такой подход поддерживает более масштабируемую и гибкую архитектуру данных.
- Технологический сдвиг: В Data Mesh к данным относятся как к гражданину первого класса, а не просто как к побочному продукту выполнения конвейерного кода. Данные и код, который их поддерживает, считаются автономными, живыми единицами, которые могут развиваться независимо друг от друга.
- Операционный сдвиг: Управление данными переходит от централизованной модели «сверху вниз» с существенным вмешательством человека к федеративной модели. В этой модели политики управления вычислительно встраиваются в узлы сетки, что позволяет применять более динамичные и масштабируемые методы управления.
- Сдвиг системы ценностей: Основополагающая точка зрения на данные меняется с отношения к ним как к статичному активу, который нужно собирать, на отношение к ним как к продукту, призванному служить и радовать своих пользователей.
Ключевые принципы Data Mesh
- Децентрализованное владение данными, ориентированное на домены: Право собственности на аналитические данные децентрализовано по бизнес-доменам, что дает возможность тем, кто ближе всего к данным, управлять ими и делиться ими. Этот принцип согласуется с проектированием, ориентированным на домен (DDD), и подчеркивает важность экспертизы домена в управлении данными.
- Данные как продукт: Data Mesh требует, чтобы бизнес-домены относились к своим данным как к продукту, абстрагируясь от базовой сложности и обеспечивая их обнаруживаемость, понятность, адресуемость, надежность, безопасность, совместимость, доступность и ценность.
- Инфраструктура самообслуживания данных: Архитектура способствует развитию инфраструктуры данных с самообслуживанием, которая позволяет ориентированным на домен командам управлять всем жизненным циклом данных, от приобретения до демократизации, не полагаясь в значительной степени на централизованные ИТ-команды.
- Федеративное управление вычислениями: Управление в Data Mesh является федеративным, при этом каждая команда домена данных отвечает за свои локальные продукты данных, придерживаясь при этом общих политик управления. Такой подход обеспечивает доступность, безопасность, доверие и многократное использование данных в организации.
Преимущества Data Mesh:
- Индивидуальные продукты данных: Data Mesh позволяет создавать индивидуальные продукты данных, отвечающие конкретным требованиям бизнеса, связывая стратегические бизнес-цели с динамичной экосистемой продуктов данных.
- Масштабируемость за счет децентрализации: Децентрализация владения и использование опыта в конкретной области позволяют Data Mesh масштабировать предоставление продуктов данных и стимулировать культурный сдвиг в сторону менталитета продуктов данных.
- Повышенная гибкость: Благодаря разрушению монолитных централизованных архитектур и абстрагированию сложности Data Mesh повышает гибкость организации, позволяя быстрее реагировать на потребности бизнеса.
- Гибкая модель управления: Федеративная модель управления позволяет организациям адаптировать методы управления к своим уникальным потребностям, балансируя между локальной автономией и централизованным надзором.
Трудности и способы их решения
Data Mesh привлекла много внимания с момента своего появления в 2019 году. На первый взгляд, сетка данных решает множество существующих проблем и может обеспечить ряд существенных преимуществ. Однако это все еще относительно новая концепция, и ей еще предстоит полностью реализоваться в существующих рыночных предложениях. Пока что ее проникновение на рынок составляет от 5 до 20 %, и, по прогнозам Gartner, она устареет, не достигнув плато продуктивности в рамках Hype Cycle 2023 года. Есть несколько факторов, которые необходимо учитывать перед внедрением сетки данных.
Люди и культурные изменения:
- Повышенная ответственность: Data Mesh возлагает значительные обязанности на доменные команды, требуя от них владения и управления продуктами данных в дополнение к их существующим функциям. Это может стать дополнительным бременем, поэтому создание стимулов и структур поддержки имеет решающее значение для обеспечения успешного внедрения.
- Нехватка навыков: Доменным командам может не хватать опыта для эффективного проектирования и управления продуктами данных. Навыки моделирования данных, управления жизненным циклом, создания API, SLA/SLOs и управления зависимостями очень важны, но их может не хватать. Чтобы восполнить эти пробелы, необходимо провести соответствующее обучение и скорректировать роли.
- Состав команды: Оптимизация состава кросс-функциональных команд, включая специалистов по анализу данных, инженеров и DevOps, может оказаться непростой задачей. Выделение ресурсов доменным командам может оказаться дорогостоящим и неэффективным, особенно для доменов с переменчивым спросом.
- Культурный аспект: Культура организации играет решающую роль в определении успеха децентрализованного принятия решений. Сопротивление изменениям или отсутствие поддержки автономности доменов могут препятствовать внедрению Data Mesh.
Процесс и организационная структура:
- Границы домена и право собственности: Определение соответствующих доменных границ и уровней владения - один из самых сложных аспектов внедрения Data Mesh. Этот процесс часто требует переоценки и возможной реструктуризации организации, чтобы привести операционные и аналитические функции в соответствие с правами собственности на домен.
- Управление и взаимодействие: Все заинтересованные стороны должны четко определить и принять модели управления, рабочие процессы и KPI. Федеративная модель управления является новой для многих организаций и требует переосмысления существующих структур и процессов. Сотрудничество между доменами должно быть улучшено, чтобы обеспечить беспрепятственную интеграцию и применение политик.
- Управление изменениями: Внедрение Data Mesh часто требует значительных организационных изменений. Хорошо отлаженный процесс управления изменениями имеет решающее значение для руководства переходом, снижения сопротивления и обеспечения успеха программы.
Технологии и инфраструктура:
- Инфраструктура самообслуживания: Для создания инфраструктуры самообслуживания данных на уровне домена требуются сложные возможности платформы данных, такие как федеративное управление, анализ данных, совместимость и развертывание на базе облачных вычислений. Эти возможности еще только появляются и могут потребовать сложной пользовательской разработки и высокой операционной зрелости.
- Интеграция унаследованных систем: Интеграция унаследованных операционных систем в систему, ориентированную на домен, может оказаться непростой задачей. Переход часто занимает много времени и требует больших затрат, особенно для организаций со значительными инвестициями в унаследованные системы.
- Реализация вычисляемых политик: Data Mesh опирается на вычисляемые политики для обнаружения и интеграции данных. Однако существующие инструменты не полностью поддерживают эти возможности, и не существует стандартизированного подхода к кодированию метаданных политики и операционной семантики. Разработка сложных онтологических систем для контекстного сопоставления и композиции доменов необходима, но остается областью постоянных исследований.
- Стоимость и сложность: Разработка и поддержка архитектуры Data Mesh может быть дорогостоящей и сложной, особенно в крупных организациях с разнообразными и распределенными потребностями в данных. Организации должны тщательно оценить потенциальные затраты и выгоды, прежде чем вступать на этот путь.
Заключение
В 1970 году Эдгар Ф. Кодд совершил революцию в области управления данными, изобретя реляционную алгебру - концепцию, опирающуюся на прочный теоретический фундамент. Этот прорыв привел к созданию реляционных баз данных и появлению языка SQL, который до сих остается доминирующим языком для обработки данных.
Такие эксперты, как К. Дж. Дейт и Хью Дарвен, в течение многих лет утверждали, что реляционные базы данных теоретически могут обрабатывать широкий спектр данных. Однако существующие реляционные базы данных имели специфические недостатки, которые эффективно устранила методология хранилищ данных. Методология хранилищ данных предлагает практическое решение, которое остается актуальным и сегодня, даже несмотря на отсутствие надежного теоретического обоснования.
В отличие от этого, современные архитектуры данных, такие как «data lake» и «data mesh», зачастую не имеют целостной теоретической базы и не способны эффективно решать некоторые из наиболее сложных современных задач, связанных с данными. Дискуссии о различиях между этими архитектурами могут стать слишком академичными, напоминая средневековые споры об абстрактных понятиях, таких как количество ангелов, которые могут стоять на булавочной головке. Такая ситуация подчеркивает необходимость разработки фундаментальных архитектурных принципов, которые позволят четко отличить одну архитектуру от другой. Несмотря на то что современные архитектуры предлагают ценные инструменты, остается потребность в чем-то более радикальном и основополагающем.
Пока мы ждем следующего значительного прорыва в архитектуре данных, современные специалисты по данным предпочитают работать со следующими парадигмами:
1. Отделение хранения данных от вычислений: В традиционных системах хранение данных тесно связано с вычислительным механизмом для оптимизации производительности. Однако такая модель существенно ограничивает масштабируемость. Отделение хранения от вычислений, как это происходит в архитектурах озер данных, будет и дальше доминировать в аналитической обработке данных. Реляционные системы, такие как Snowflake и AWS Aurora, пошли по пути такого разделения, полагаясь на масштабируемое объектное хранилище для обеспечения гибкости и масштабируемости.
2.Дублирование данных: Исторически сложилось так, что усилия по обработке данных были направлены на оптимизацию компоновки данных и минимизацию их дублирования из-за высокой стоимости хранения. Сегодня хранение данных обходится недорого, что позволяет организациям хранить необработанные данные неограниченное время и обрабатывать их по мере необходимости. Хранение нескольких копий данных, особенно в разных порядках сортировки, может повысить эффективность обработки. Однако, несмотря на снижение стоимости хранения, управление данными остается сложным и дорогостоящим. Необходимо уделять пристальное внимание обслуживанию и синхронизации этих дополнительных копий.
3. Управление вычислительными данными: Практика управления данными, включающая в себя анализ и проверку достоверности данных, качество данных, управление хранением и жизненным циклом данных, а также политики безопасности, должна быть автоматизирована и интегрирована в качестве первоклассных граждан в любую зрелую платформу данных. Традиционно к этим аспектам относились как к второстепенным, что препятствовало гибкости и надежности систем данных. Упор на управление вычислениями необходим для поддержания целостности и надежности современных платформ данных.
4. Данные как продукт: Отношение к данным как к продукту может способствовать демократизации доступа, повышению качества и масштабированию практики управления данными. Такой подход особенно полезен при работе с крупномасштабными данными, хотя он может быть не столь практичным для небольших сред. Тем не менее, принятие подхода к управлению данными как к продукту может значительно улучшить работу с данными и их использование в организации.
5. Перспективы сервисов на основе ИИ: Несмотря на то, что все еще находится на начальном этапе развития, сервисы на основе ИИ обладают огромным потенциалом для упрощения и автоматизации сложных задач, таких как классификация данных, интеграция данных и расширенный анализ данных. Эти сервисы могут сыграть решающую роль в решении некоторых проблем, с которыми сталкиваются современные архитектуры данных, предоставляя новые способы управления и анализа данных в масштабе.
В целом, несмотря на то, что современные архитектуры данных еще не раскрыли весь свой потенциал, описанные выше руководящие принципы закладывают прочный фундамент для создания и управления эффективными системами данных. По мере развития технологий эти принципы помогут организациям ориентироваться в сложностях управления данными и подготовиться к следующей волне инноваций в этой области.
