Глава 2 «Типы архитектур данных»

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

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

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

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

Эта глава предлагает краткий обзор основных типов архитектур, которые будут подробно рассмотрены в книге:

• реляционные хранилища данных (relational data warehouse),
• озёра данных (data lake),
• современные хранилища данных (modern data warehouse),
• фабрика данных (data fabric),
• озеро-хранилище данных или гибридное хранилище данных (data lakehouse),
• и сетка данных (data mesh).

Каждому типу будет посвящена отдельная глава с детальным описанием.

Эволюция архитектур данных

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

Реляционные базы данных предназначены для работы со структурированными данными и предоставляют инструментарий для создания, изменения и запроса данных с использованием стандартизированного языка, известного как SQL (Structured Query Language). Реляционная модель была впервые предложена Эдгаром Ф. Коддом в 1970 году, и с середины 1970-х годов она стала доминирующей моделью для систем управления базами данных. Большинство операционных приложений требуют постоянного хранения данных, и для этого чаще всего используются реляционные базы данных.

В реляционных базах данных, где на первом месте стоят согласованность и целостность данных, используется подход, называемый schema-on-write (схема на запись). Схема — это формальная структура, которая определяет организацию и взаимосвязи между таблицами, полями, типами данных и ограничениями. Она служит чертежом для хранения и управления данными, обеспечивая их согласованность, целостность и эффективную организацию внутри базы данных. Реляционные базы данных (и реляционные хранилища данных) требуют некоторой предварительной работы перед тем, как данные попадут в систему. Сначала необходимо создать базу данных, её таблицы, поля и схему, а затем написать код для передачи данных в базу. При подходе schema-on-write схема данных определяется и применяется на этапе записи или загрузки данных в базу. Данные должны соответствовать заранее определённой схеме, включая типы данных, ограничения и связи, прежде чем они могут быть сохранены.

Для сравнения, при подходе schema-on-read схема применяется на этапе чтения или доступа к данным, а не записи. Данные могут загружаться в систему хранения без строгого соответствия схеме, и структура определяется только при запросе или использовании данных. Этот подход обеспечивает большую гибкость при работе с неструктурированными или полуструктурированными данными и обычно используется в озёрах данных, которые будут рассмотрены позже в этой главе.

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

Это включает:

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

Общие элементы архитектур данных

Хранение данных

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

Обработка данных

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

Доступ к данным

Архитектуры данных должны предоставлять механизмы доступа к данным, включая пользовательские интерфейсы и API, которые позволяют запрашивать и анализировать данные.

Безопасность и конфиденциальность данных

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

Управление данными

Архитектуры данных должны предоставлять рамки для управления данными, включая стандарты качества, отслеживание происхождения данных и политики хранения.

Основная цель архитектуры данных

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

В Таблице 2-1 приведено высокоуровневое сравнение характеристик архитектур данных, описанных в этой книге. Это поможет вам начать определять, какая архитектура может лучше всего подойти для вашего сценария использования.

Таблица 2-1. Сравнение архитектур данных

или переведенная версия таблицы:

Реляционное хранилище данных (Relational Data Warehouse, RDW)

Реляционные базы данных были основным инструментом хранения данных в течение нескольких десятилетий. Первое реляционное хранилище данных, использовавшееся в производстве, было разработано в Стэнфордском университете доктором Джеком Э. Шемером, основателем корпорации Teradata в 1979 году. Первую систему Teradata установил банк Wells Fargo в 1983 году для анализа финансовых данных.

По мере того как организации начали генерировать огромные объёмы данных, становилось всё сложнее обрабатывать и анализировать эти данные без значительных задержек. Ограничения реляционных баз данных привели к созданию реляционных хранилищ данных (RDW), которые стали популярными в конце 1980-х годов, примерно через 15 лет после появления реляционных баз данных.

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

RDW имеет вычислительный механизм (compute engine) и хранилище. Вычислительный механизм предоставляет мощность для выполнения запросов к данным, а хранилище — это реляционное хранилище, организованное в таблицы, строки и столбцы. Мощность RDW может использоваться только для данных, находящихся в его реляционном хранилище — они связаны друг с другом.

Ключевые функции RDW включают:

• Поддержку транзакций (обеспечение надёжной и согласованной обработки данных).
• Журналирование операций (запись всей активности в системе).
• Принудительное соблюдение схемы (гарантия того, что данные организованы и структурированы в соответствии с заданной схемой).

В 1970–1980-х годах реляционные базы данных использовались для операционных приложений, таких как обработка заказов и управление запасами. Эти приложения называются OLTP-системами (Online Transaction Processing). Они позволяют создавать, читать, обновлять и удалять данные в базе — операции, известные как CRUD (Create, Read, Update, Delete).

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

RDW были изобретены, чтобы решить эту проблему. Данные из реляционной базы копируются в хранилище данных, где пользователи могут выполнять запросы и отчёты без нагрузки на операционную систему, как показано на Рисунке 2-1.

Рисунок 2-1. Data warehousing

Озеро данных

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

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

Технология хранения озёр данных началась с HDFS (Hadoop Distributed File System), бесплатной технологии с открытым исходным кодом, популярной в начале 2010-х годов и размещаемой почти исключительно локально. HDFS — это масштабируемая, отказоустойчивая распределённая система хранения, работающая на обычном оборудовании.

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

В отличие от RDW, озёра данных используют подход schema-on-read, что означает отсутствие необходимости заранее готовить данные для загрузки в озеро. Данные сохраняются в исходном (сыром) формате, как они поступают из исходной системы. Например, экспортированные из реляционной базы данные в формате CSV могут быть загружены в озеро данных без изменений. Для загрузки этих данных в RDW их пришлось бы преобразовать в строки и столбцы таблицы.

При загрузке файла данных в озеро его схема может отсутствовать или находиться в отдельном файле. Поэтому схема определяется при чтении, либо создаётся, либо извлекается из файла, как показано на Рисунке 2-2.

Данные из различных источников — операционных баз данных, датчиков, социальных сетей — могут попадать в озеро данных. Эти файлы могут содержать структурированные (например, реляционные базы данных), полуструктурированные (CSV, JSON, XML) и неструктурированные (электронная почта, документы, PDF) данные, а также двоичные данные (изображения, аудио, видео).

Рисунок 2-2. Озеро данных

Озёра данных изначально создавались как решение всех проблем реляционных хранилищ данных, таких как высокая стоимость, ограниченная масштабируемость, низкая производительность, сложность подготовки данных и ограниченная поддержка сложных типов данных. Компании, продававшие Hadoop и озёра данных, такие как Cloudera, Hortonworks и MapR, представляли их как волшебное решение, которое автоматически копирует, очищает и делает данные доступными для конечных пользователей. Они утверждали, что озёра данных могут полностью заменить реляционные хранилища данных, предлагая подход «одна технология для всего». Многие компании решили сэкономить, используя бесплатные инструменты с открытым исходным кодом для всех своих нужд.

Однако на практике запросы к озёрам данных оказались далеко не такими простыми: для работы с ними требовались серьёзные навыки. ИТ-отделы говорили конечным пользователям: «Мы скопировали все данные, которые вам нужны, в озеро данных. Просто откройте Jupyter Notebook, используйте Hive и Python, чтобы создавать отчёты с файлами из этих папок». Такой подход провалился, поскольку у большинства пользователей не было необходимых навыков для выполнения этих задач.

Компании на собственном опыте убедились, что такие сложные и трудные в использовании решения оказывались дороже из-за высоких затрат на оборудование и поддержку, задержек в производстве и снижения производительности. Кроме того, озёра данных не обладали такими функциями, как поддержка транзакций, строгое соблюдение схемы и журналирование операций, которые ценились в хранилищах данных. В результате две из трёх ведущих компаний, продававших озёра данных (Hortonworks и MapR), обанкротились.

Тем не менее озёра данных не исчезли. Их роль трансформировалась: теперь они используются для промежуточного хранения и подготовки данных. Эта тема подробно рассматривается в главе 5.

Modern Data Warehouse (Современное хранилище данных)

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

Озёра данных не смогли заменить реляционные хранилища данных, но остались полезными для промежуточного хранения и подготовки данных. Почему бы не объединить преимущества обоих подходов?

Примерно с 2011 года многие компании начали разрабатывать архитектуры, в которых озёра данных существуют рядом с реляционными хранилищами данных. Такой подход сформировал архитектуру, известную как современное хранилище данных (Modern Data Warehouse, MDW), изображённое на Рисунке 2-3.

Рисунок 2-3. Современное хранилище данных (MDW)

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

Data Fabric (Фабрика данных)

Архитектура Data Fabric начала появляться около 2016 года. Фабрика данных можно рассматривать как эволюцию архитектуры современного хранилища данных, в которую добавлено больше технологий для работы с дополнительными источниками данных, обеспечения безопасности и упрощения доступа к данным. Также были улучшены процессы загрузки, трансформации, выполнения запросов, поиска и доступа к данным, как показано на Рисунке 2-4. С таким количеством дополнений система превращается в «фабрику» — большую инфраструктуру, способную обрабатывать любые виды данных. Более подробно эта тема раскрывается в Главе 11.

Рисунок 2-4. Data fabric

Озеро-хранилище данных (Data Lakehouse)

Термин озеро-хранилище данных представляет собой смесь (портманто) понятий «озеро данных» и «хранилище данных». Такие архитектуры начали набирать популярность около 2020 года, когда компания Databricks впервые ввела этот термин.

Идея гибридного озера-хранилища заключается в том, чтобы отказаться от реляционного хранилища данных и использовать в архитектуре только одно хранилище — озеро данных. Все типы данных — структурированные, полуструктурированные и неструктурированные — загружаются в озеро данных, и все запросы и отчёты выполняются на его основе.

Вы можете подумать: «Постойте. Ведь изначально озёра данных уже использовали этот подход, и он провалился! Что изменилось?» Ответ, как показано на Рисунке 2-5, заключается в добавлении транзакционного уровня хранения поверх существующего озера данных. Этот слой делает озеро данных более похожим на реляционную базу данных. Среди популярных решений с открытым исходным кодом для такого уровня — Delta Lake, Apache Iceberg и Apache Hudi.

Все эти технологии подробно рассматриваются в Главе 12.

Рисунок 2-5. Data LakeHouse

Архитектура «Сетка данных» (Data Mesh)

Термин архитектура «Сетка данных» был впервые представлен в блоге Заамак Дехгани (Zhamak Dehghani), основательницы и генерального директора Nextdata, в мае 2019 года. Позже, в декабре 2020 года, Дехгани уточнила концепцию и выделила четыре основные принципы архитектуры Сетки данных. С тех пор эта тема вызывает огромный интерес, обсуждаясь в блогах, на конференциях и в СМИ. Архитектура даже вошла в цикл Gartner Hype Cycle для управления данными. Несмотря на ажиотаж, подход подходит лишь для ограниченного числа сценариев.

Современное хранилище данных, фабрика данных и озеро-хранилище данных используют централизованный подход, предполагающий копирование операционных данных в центральное хранилище, контролируемое ИТ-отделом.

Однако такая централизация вызывает три основные проблемы:

• Владение данными. Кому принадлежат данные?
• Качество данных. Кто отвечает за их чистоту?
• Масштабируемость. Как масштабировать организацию и технологии?

Цель Data Mesh — решить эти проблемы.

В Data Mesh остаются распределёнными по различным доменам внутри компании, таким как производство, продажи или поставки (правая часть Рисунка 2-6). Каждый домен имеет собственную мини-команду ИТ, которая отвечает за данные: их очистку, создание аналитических данных и обеспечение доступа. У каждого домена есть своя инфраструктура для вычислений и хранения. Это создаёт децентрализованную архитектуру, где данные, люди и инфраструктура масштабируются вместе с ростом числа доменов.

Рисунок 2-6. Data mesh (архитектура «Сетка данных»)

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

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

Все аспекты архитектуры Data Mesh рассматриваются в Главах 13 и 14.

Резюме

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

Сообщение Глава 2 «Типы архитектур данных» появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.