Building Medallion
Architectures
Designing with Delta Lake and Spark

Piethein Strengholt

Архитектура
медальона
Проектирование с помощью Delta Lake и Spark

Питхейн Стренгхольт

2026

ББК 32.973.233-018
УДК004.65
С84

Стренгхольт Питхейн
С84	Архитектура медальона. Проектирование с помощью Delta Lake и Spark. —
Астана: «Спринт Бук», 2026. — 400 с.: ил.
ISBN 978-601-12-8023-5
Объемы данных растут экспоненциально, а опасность оказаться в «болоте данных» (data swamp) подстерегает на каждом шагу? Чтобы получить ценную аналитику, которая обеспечит конкурентное преимущество, можно обратиться к проверенной модели архитектуры медальона. Однако реализовать надежную
архитектуру данных довольно сложно, особенно бронзовый, серебряный и золотой уровни.
Опираясь на свой богатый практический опыт, Питхейн Стренгхольт развеивает распространенные
заблуждения и объясняет сложные проблемы, с которыми вы столкнетесь, начиная работу над новой архитектурой данных. Архитекторы и инженеры любого профиля найдут здесь ответы на свои частые вопросы,
а также юзкейсы реальных компаний с примерами того, что сработало, а что нет и почему.
Вы получаете не очередную «теорию уровней», а полное практическое руководство, позволяющее
разобраться, как правильно проектировать и реализовывать каждый уровень на Microsoft Fabric и Azure
Databricks (с готовыми примерами кода и GitHub-репозиторием); реальные кейсы внедрения в AP Pension,
Amadeus и ZEISS; рекомендации о том, как вписать медальон в data mesh; разбор таких вопросов, как
контракты данных, безопасность и генеративный ИИ (включая RAG и работу с неструктурированными
данными).
Для дата-инженеров, архитекторов данных, глав дата-офисов и всех, кто устал от «еще одного озера,
которое никто не может использовать».

16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)

ББК 32.973.233-018
УДК 004.65

Права на издание получены по соглашению с O’Reilly. Все права защищены. Никакая часть данной книги не
может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских
прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может
гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные
ошибки, связанные с использованием книги. Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете найти в этой книге. На момент подготовки книги к изданию все ссылки на
интернет-ресурсы были действующими. В книге возможны упоминания организаций, деятельность которых запрещена на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др.

ISBN 978-1098178833 англ.

ISBN 978-601-12-8023-5

Authorized Russian translation of the English edition of Building Medallion
Architectures ISBN 9781098178833 © 2025 Piethein Strengholt.
This translation is published and sold by permission of O’Reilly Media, Inc.,
which owns or controls all rights to publish and sell the same.
© Перевод на русский язык ТОО «Спринт Бук», 2026
© Издание на русском языке, оформление ТОО «Спринт Бук», 2026

Краткое содержание

ЧАСТЬ I
ОСНОВНЫЕ ПРИНЦИПЫ АРХИТЕКТУРЫ МЕДАЛЬОНА
Глава 1. Эволюция архитектуры данных.....................................................................................24
Глава 2. Закладка фундамента..........................................................................................................56
Глава 3. Секреты архитектуры медальона..................................................................................73
ЧАСТЬ II
ПОСТРОЕНИЕ УРОВНЕЙ МЕДАЛЬОНА
Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric..... 118
Глава 5. Строим бронзовый уровень......................................................................................... 140
Глава 6. Строим серебряный уровень....................................................................................... 176
Глава 7. Строим золотой уровень................................................................................................ 221
ЧАСТЬ III
РЕАЛЬНЫЕ ПРИМЕРЫ
Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension...................... 270
Глава 9. Пример: Amadeus, технологический лидер туристической отрасли........ 291
Глава 10. Пример: стратегические преобразования данных в ZEISS.......................... 309
ЧАСТЬ IV
МАСШТАБИРОВАНИЕ, УПРАВЛЕНИЕ ДАННЫМИ
И БУДУЩЕЕ АРХИТЕКТУР МЕДАЛЬОНА
Глава 11. Масштабирование архитектур медальона.......................................................... 324
Глава 12. Управление данными и безопасность в архитектуре медальона............ 345
Глава 13. Будущее архитектур медальона с генеративным ИИ..................................... 371

Оглавление

От издательства........................................................................................................................ 13
О научном редакторе русского издания.................................................................................................13
Предисловие............................................................................................................................. 14
Введение.................................................................................................................................... 17
Для кого эта книга..............................................................................................................................................18
Структура книги..................................................................................................................................................19
Условные обозначения....................................................................................................................................20
Использование исходного кода примеров............................................................................................21
Благодарности.....................................................................................................................................................21

ЧАСТЬ I
ОСНОВНЫЕ ПРИНЦИПЫ АРХИТЕКТУРЫ МЕДАЛЬОНА
Глава 1. Эволюция архитектуры данных.............................................................................. 24
Что такое архитектура медальона?............................................................................................................26
Краткая история архитектуры хранилищ данных...............................................................................28
OLTP-системы................................................................................................................................................29
Хранилища данных....................................................................................................................................31
Область промежуточного хранения..................................................................................................32
Методология Инмона................................................................................................................................33
Методология Кимбалла............................................................................................................................35
Традиционные хранилища данных: ключевые выводы............................................................38
Краткая история озер данных......................................................................................................................39
HDFS..................................................................................................................................................................41
MapReduce.....................................................................................................................................................42
Apache Hive....................................................................................................................................................42
Проект Spark..................................................................................................................................................45
Озера данных: ключевые выводы.......................................................................................................46
Краткая история архитектуры озер-хранилищ данных...................................................................47
Основатели Spark........................................................................................................................................47
Появление открытых табличных форматов...................................................................................49

Оглавление  7
Расцвет архитектур озер-хранилищ данных..................................................................................51
Архитектура медальона и сложности ее практической реализации ................................53
Заключение...........................................................................................................................................................54
Глава 2. Закладка фундамента............................................................................................... 56
Фундаментальные предусловия..................................................................................................................57
Дополнительные посадочные зоны..........................................................................................................57
Сырые данные......................................................................................................................................................58
Пакетная обработка..........................................................................................................................................59
Обработка в реальном времени.................................................................................................................61
Spark Structured Streaming......................................................................................................................62
Поставка изменений в данных..............................................................................................................63
Захват изменений в данных...................................................................................................................63
Факторы и учебные ресурсы.................................................................................................................64
ETL и средства оркестрации..........................................................................................................................65
Управление таблицами Delta........................................................................................................................67
Z-упорядочение...........................................................................................................................................67
V-упорядочение...........................................................................................................................................68
Партиционирование таблиц.........................................................................................................................68
Жидкая кластеризация.............................................................................................................................69
Сжатие и оптимизация записи..............................................................................................................69
DeltaLog...........................................................................................................................................................70
Заключение...........................................................................................................................................................71
Глава 3. Секреты архитектуры медальона........................................................................... 73
Трехуровневая структура...............................................................................................................................73
Бронзовый уровень...........................................................................................................................................75
Иерархия обработки.................................................................................................................................75
Обработка полных загрузок данных..................................................................................................77
Обработка инкрементальных загрузок данных...........................................................................77
Историзация данных на бронзовом уровне .................................................................................79
Эволюция и управление схемой..........................................................................................................80
MergeSchema и контроль соблюдения схемы...............................................................................83
Технические проверки ............................................................................................................................85
Использование и управление (governance)...................................................................................87
Бронзовый уровень на практике.........................................................................................................88
Серебряный уровень........................................................................................................................................89
Очистка данных...........................................................................................................................................89

  

8

Оглавление
Проектирование модели данных серебряного уровня............................................................92
Гармонизация с другими источниками.............................................................................................97
3NF и Data Vault............................................................................................................................................97
Операционные запросы и машинное обучение....................................................................... 100
Управление пересекающимися требованиями......................................................................... 101
Задачи автоматизации........................................................................................................................... 101
Серебряный уровень на практике................................................................................................... 103
Золотой уровень.............................................................................................................................................. 105
Схема «звезда».......................................................................................................................................... 105
Особенности проектирования схем «звезда»............................................................................ 108
Метод OBT.................................................................................................................................................... 110
Сервисный уровень................................................................................................................................ 112
Золотой уровень на практике............................................................................................................ 113
Заключение........................................................................................................................................................ 114

ЧАСТЬ II
ПОСТРОЕНИЕ УРОВНЕЙ МЕДАЛЬОНА
Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric.......... 118
Пример: Oceanic Airlines............................................................................................................................... 119
Знакомство с Microsoft Fabric..................................................................................................................... 120
Домены......................................................................................................................................................... 120
Рабочие пространства и емкости..................................................................................................... 121
OneLake......................................................................................................................................................... 123
Инженерия данных с использованием Spark............................................................................. 123
Хранилища данных с T-SQL.................................................................................................................. 126
Другие типы рабочих нагрузок Fabric............................................................................................ 127
Создание основы............................................................................................................................................. 127
Настройка емкостей............................................................................................................................... 128
Настройка доменов................................................................................................................................ 129
Настройка рабочих пространств...................................................................................................... 129
Создание Lakehouse................................................................................................................................ 129
Особенности работы с емкостью..................................................................................................... 132
Особенности работы с доменом...................................................................................................... 132
Особенности рабочих пространств............................................................................................... 133
Особенности работы с сущностями Lakehouse......................................................................... 135
Особенности работы с учетными записями хранения данных.......................................... 137
Заключение........................................................................................................................................................ 139

  

Оглавление

9

Глава 5. Строим бронзовый уровень.................................................................................. 140
Создание пайплайна данных..................................................................................................................... 140
Развертывание базы данных AdventureWorks............................................................................ 141
Настройка подключения к базе данных Azure SQL.................................................................. 142
Создание нового пайплайна данных.............................................................................................. 143
Прочие соображения............................................................................................................................. 149
Реализация таблиц Lakehouse................................................................................................................... 152
Перенос файлов Parquet в управляемые таблицы Delta....................................................... 153
Использование внешних таблиц...................................................................................................... 157
Обновление таблиц операциями MERGE...................................................................................... 158
Spark Structured Streaming................................................................................................................... 160
Использование CDC................................................................................................................................ 162
Методы обработки данных.................................................................................................................. 163
Управление схемой......................................................................................................................................... 163
Создание таблиц без определения схем....................................................................................... 164
Определение схем через DataFrame API....................................................................................... 165
Команды SQL DDL.................................................................................................................................... 166
Конфигурации в YAML или JSON....................................................................................................... 167
Метод, основанный на метаданных................................................................................................. 169
Databricks Auto Loader........................................................................................................................... 170
Сторонние инструменты....................................................................................................................... 172
Эволюция схем.......................................................................................................................................... 172
Заключение........................................................................................................................................................ 174
Глава 6. Строим серебряный уровень................................................................................. 176
Краткий обзор................................................................................................................................................... 177
Реализация метода, основанного на метаданных............................................................................ 178
Реализация хранилища метаданных............................................................................................... 179
Реализация динамической проверки данных............................................................................ 183
Возможности для улучшения............................................................................................................. 186
Очистка данных................................................................................................................................................ 188
Реализация задач очистки данных.................................................................................................. 189
Факторы очистки данных..................................................................................................................... 193
Фреймворки преобразования данных и инструменты качества данных..................... 195
Оптимизация производительности запросов посредством денормализации.................. 198
Простое обогащение данных..................................................................................................................... 199
Историзация данных...................................................................................................................................... 202

  

10

Оглавление

Задания оптимизации................................................................................................................................... 209
Оркестрация с Apache AirFlow.................................................................................................................. 210
Заключительные рекомендации.............................................................................................................. 213
Данные серебряного уровня как продукт........................................................................................... 217
Заключение........................................................................................................................................................ 218
Глава 7. Строим золотой уровень........................................................................................ 221
Проектирование золотого уровня.......................................................................................................... 221
Преобразование данных с использованием схемы «звезда»............................................. 222
Создание семантической модели.................................................................................................... 237
Создание первого отчета Power BI................................................................................................... 241
Создание потоков задач....................................................................................................................... 244
Усовершенствования золотого уровня......................................................................................... 245
Microsoft Fabric на практике................................................................................................................ 249
Продукты данных............................................................................................................................................ 250
Введение в принципы создания продуктов данных............................................................... 252
Разновидности продуктов данных................................................................................................... 252
Моделирование данных....................................................................................................................... 252
Управление данными............................................................................................................................. 253
Управление данными с помощью Microsoft Purview....................................................................... 254
Проектирование с помощью Microsoft Purview........................................................................ 255
Рекомендации для архитектуры медальона............................................................................... 262
Заключение........................................................................................................................................................ 266

ЧАСТЬ III
РЕАЛЬНЫЕ ПРИМЕРЫ
Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension......................... 270
Архитектура медальона............................................................................................................................... 275
Прочие соображения ................................................................................................................................... 287
Заключительные рекомендации.............................................................................................................. 290
Глава 9. Пример: Amadeus, технологический лидер туристической отрасли.............. 291
Архитектура медальона............................................................................................................................... 296
FinOps.................................................................................................................................................................... 302
Модели данных................................................................................................................................................. 303
Контракты данных........................................................................................................................................... 306
Управление данными..................................................................................................................................... 307

  

Оглавление

11

Глава 10. Пример: стратегические преобразования данных в ZEISS............................ 309
Эволюция платформы данных................................................................................................................... 310
Архитектура медальона............................................................................................................................... 314
Продукты данных и обмен данными...................................................................................................... 317
Рекомендации и лучшие практики.......................................................................................................... 319

ЧАСТЬ IV
МАСШТАБИРОВАНИЕ, УПРАВЛЕНИЕ ДАННЫМИ
И БУДУЩЕЕ АРХИТЕКТУР МЕДАЛЬОНА
Глава 11. Масштабирование архитектур медальона....................................................... 324
Децентрализация управления данными.............................................................................................. 324
Гибкость федеративной модели....................................................................................................... 325
Сетка медальона (medallion mesh).................................................................................................. 326
Количество архитектур медальона................................................................................................. 328
Разновидности внутренней архитектуры медальона.................................................................... 331
Отдельные уровни продуктов данных........................................................................................... 331
Адаптированные архитектуры медальона.................................................................................. 333
Адаптируемость бронзового уровня............................................................................................. 336
Вариации на серебряном уровне..................................................................................................... 338
Вариации на золотом уровне............................................................................................................. 338
Корпоративные модели данных ..................................................................................................... 339
Управление мастер-данными............................................................................................................. 341
Управление референсными данными............................................................................................ 343
Заключение........................................................................................................................................................ 344
Глава 12. Управление данными и безопасность в архитектуре медальона................. 345
Управление данными..................................................................................................................................... 345
Управление данными в архитектуре медальона...................................................................... 346
Unity Catalog............................................................................................................................................... 349
Архитектура медальона с Unity Catalog........................................................................................ 351
Контракты данных........................................................................................................................................... 356
Контракты в каталоге............................................................................................................................. 357
Контракты в метахранилище.............................................................................................................. 358
Контракты данных с использованием файлов YAML и GitOps............................................ 359
Другие спецификации контрактов данных.................................................................................. 360
Безопасность данных и управление доступом.................................................................................. 361
Заключение........................................................................................................................................................ 370

  

12

Оглавление

Глава 13. Будущее архитектур медальона с генеративным ИИ...................................... 371
Обработка неструктурированных данных.......................................................................................... 372
RAG.................................................................................................................................................................. 372
Бронзовый уровень................................................................................................................................ 374
Серебряный уровень............................................................................................................................. 376
Золотой уровень...................................................................................................................................... 378
Интеграция LLM и архитектур медальона........................................................................................... 381
Роль агентов....................................................................................................................................................... 384
Обучение и тонкая настройка моделей LLM...................................................................................... 386
Будущее архитектур медальона............................................................................................................... 387
Заключение........................................................................................................................................................ 390
Об авторе................................................................................................................................. 393
Иллюстрация на обложке...................................................................................................... 394

От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@sprintbook.kz
(издательство «SprintBook», компьютерная редакция).
Мы будем рады узнать ваше мнение!

О научном редакторе русского издания
Николай Марков — инженер по построению инфраструктуры с более чем
14-летним опытом разработки и проектирования систем на разных языках
и платформах. Консультирует компании, выступает на конференциях и читает
курсы в университетах в разных странах по вопросам Data Governance и Data
Engineering. Участвовал в проектах в США, Европе и России.

Предисловие
К архитектурам медальона (Medallion architecture) я испытываю смешанные
чувства. Как нечто настолько простое могло породить столько путаницы и споров
в отрасли? Почему все определяют их по-разному? Для чего вообще нужна эта
концепция? И самое важное — почему вас это должно интересовать?
Я почти 10 лет занимался внутренней разработкой средств бизнес-аналитики,
прежде чем стать внешним консультантом, — как раз вовремя, чтобы поймать
первую европейскую волну перехода на Azure для задач аналитики. Моя долгая
борьба с односерверной SQL Server в попытке создания облачно-совместимых
архитектур и понимание того, что она просто не подходит для этой цели, заставили
меня в 2015-м обратиться к стремительно развивающимся тогда технологиям —
озерам данных (data lake) и распределенным вычислениям.
С тех пор моя миссия вполне очевидна: объединять наши подходы, учиться на
примерах из прошлого и развиваться, не цепляясь за устаревшие традиции. Архи­
тектуры медальона — отличный инструмент, чтобы транслировать это видение.
Работая в Advancing Analytics, я помогаю компаниям со всего мира раскрыть
истинный потенциал своих данных — выйти за пределы установки «быстрее
и дешевле», чтобы развивающиеся компании могли работать по-новому с теми
данными, которые у них уже есть. Я консультирую таких отраслевых гигантов,
как Microsoft и Databricks, формируя инструменты и стратегии завтрашнего дня,
и много времени посвящаю выступлениям на тему архитектур данных на международных конференциях, мероприятиях и на моем YouTube-канале Advancing
Analytics (https://youtube.com/c/AdvancingAnalytics).
Я проектировал архитектуры для гигантов мирового ретейла, блестящих цифровых стартапов, монолитных регулируемых финансовых сервисов и тех, кто
находится между ними, и с готовностью заявляю, что все эти варианты дизайна
очень во многом похожи. В конце концов, все они извлекают данные, проводят
их очистку и анализ. Так что если вы переходите от традиционных хранилищ
данных или пытаетесь уйти от хаоса больших данных, не беспокойтесь — путь,
на который вы встаете, пройден многими и понятен, и найдется множество экспертов, готовых вам помочь (включая Питхейна и меня).
Мы бросили все силы, чтобы определить хоть какие-то стандарты озер данных. Архитектуры медальона именно это собой и представляют — стандарт проектирования
платформ с использованием озер данных. Эти развивающиеся концепции могут показаться чем-то мистическим, что лежит в компетенции отдельных узких специалистов.
Но это не так: они уже заняли центральное место в современном подходе к созданию
платформ данных. Даже компания Microsoft, когда-то прочно ассоциировавшаяся
с реляционными базами данных, своей Microsoft Fabric расширила границы видения

  

О научном редакторе русского издания

15

озер-хранилищ данных (lakehouse). Если вы работаете с данными и аналитикой, понимание архитектур медальона для вас не преимущество, а необходимость.
Более того, архитектура медальона — великолепная концепция, которую слишком часто понимают неправильно. Нередко она воспринимается как жесткая
пошаговая процедура, хотя в действительности это гибкий метод, который помогает разобраться в эволюционирующем ландшафте. Это попытка упростить
десятилетие органической эволюции и технологических новшеств в концепциях,
которые можно представить пользователям, не разбирающимся в технической
стороне вопроса. Однако за упрощение приходится платить: оно оставляет много
возможностей для споров, неправильных интерпретаций и недовольства.
Эта книга послужит вам проводником на пути принятия архитектуры медальона.
Она поможет не поддаваться ажиотажу и преувеличениям и объяснит, почему
мы используем те или иные паттерны и как их реализовать. Но откуда берется
путаница и почему нам нужны архитектуры медальона? Чтобы понять это, необходимо обратиться к истории.
Все началось в эпоху больших данных (Big Data) со стремительного роста инноваций в распределенном хранении и вычислениях. На заре формирования
концепции Big Data озера данных адаптировались для аналитики в серьезных
объемах и глубоких инноваций — мы стали выполнять запросы в невообразимом
ранее масштабе и открыли доступ в мир анализа данных. Но инновации не давались даром. Прошло несколько лет, и репутация озер данных упала; в них разочаровались, поняв, что они не способны решить все проблемы в мире. Появился
новый страшный термин — «болото данных» (data swamp).
Тем не менее это было не недостатком самой технологии, а лишь последствиями
раннего принятия и инноваций. Мир Big Data и ранние озера данных фактически
каждый раз изобретались заново — каждый отдельный пайплайн данных мог быть
невероятно мощным, но не существовало никакой общей архитектуры или операционной модели, задающей направление проектирования. При этом реляционные
базы данных процветали, основываясь на дисциплине. Выстраданные в течение
десятилетий архитектурные подходы (такие, как методология Кимбалла) породили предсказуемые, эффективные аналитические системы. Это архитектурное
пространство было очень хорошо изучено — почти до той степени, в какой его
зависимость от традиции стала чрезмерной. По мере становления озер данных
основную сложность стала представлять адаптация жесткости хранилищ данных
к масштабу и гибкости озер без нарушения догматической традиции.
Затем произошел прорыв. Доступные технологии распределенных вычислений
(такие, как Apache Spark), опираясь на новые структуры данных (такие, как Delta
Lake, Iceberg и Hudi), превратили озера данных в управляемые высокопроизводительные платформы. Возникли озера-хранилища (lakehouse) — концепция,
объединяющая лучшие стороны озер и хранилищ. А архитектуры медальона
проложили организациям дорогу к озерам-хранилищам. Вместо того чтобы оставаться уделом нишевых компаний, работающих со специфическими задачами,

  

16

Предисловие

озера данных стали технологией де-факто для платформ данных. Все двери
гостеприимно распахнулись перед ними.
Архитектуры медальона представляют собой простую концепцию уровней
«бронза-серебро-золото» рабочей модели управления озером-хранилищем. Это
попытка создания набора сложных, гибких технических решений, которая не позволит организациям увязнуть в «болотах данных» прошлого. Однако сведение
сложной задачи к простой диаграмме создает свои проблемы — все начинают
додумывать, заполняя пробелы, и находить собственные более глубокие смыслы
и определения. Таково текущее положение дел, и скорее всего, именно в нем находятся читатели, открывшие эту книгу.
Реализация архитектуры медальона не сводится к выполнению списка готовых
инструкций. Это не точный фиксированный процесс, в который вы пытаетесь
встроить уникальные потребности своей организации. Вместо этого следует сосредоточиться на том, чтобы предоставить контекст своим потребителям данных:
организовать данные так, чтобы пользователи понимали, когда они очищены или
готовы для использования. Помогите потребителям как можно проще и быстрее
найти данные, которые сделают их работу более эффективной. Когда вы это сделаете, вы сможете адаптировать процессы к своему дизайну.
И в этом вам поможет книга. Питхейн собрал историю, контекст, процессы и нюансы этих паттернов проектирования и представил самую их суть. Вы начнете
намного лучше понимать, почему мы следуем тем или иным процессам и какую
пользу они принесут, — это поможет приспособить их к неповторимой культуре
вашей организации. Если вы прежде работали с хранилищами данных, многие из
описываемых концепций — адаптированных и настроенных для изменяющегося
технологического стека — будут вам знакомы.
Выше встречается очень важное слово: контекст. Процессы и технические реализации можно легко документировать и публиковать как «правильный» способ решения
поставленной задачи, но такая публикация быстро потеряет ценность, если вы забудете «почему». В этой книге Питхейн даст вам эту важную часть головоломки: он
объяснит не только как реализовать некоторые процессы, но и почему эти процессы
нужны и какие решения принимались при их создании. Вы научитесь самостоятельно решать, какие процессы и методы вам следует принять, а без каких, откровенно
говоря, ваша конкретная реализация сможет прекрасно обойтись.
Эта книга — не просто учебник, а проводник. Во время путешествия с ним вы будете возвращаться к выводам и описаниям методов, изучая главы с реализациями
и оттачивая технику. К концу книги вы не только начнете понимать архитектуры
медальона — вы освоите их.
Итак, приступайте к погружению в мир озер и озер-хранилищ данных!
Саймон Уайтли (Simon Whiteley),
технический директор и основатель Advancing Analytics
(https://advancinganalytics.co.uk)

Введение
В начале 2024 года я проводил свой третий за неделю семинар по проектированию
архитектур. Разговор естественным образом перешел к архитектуре медальона.
Участники забрасывали меня вопросами: какие существуют лучшие практики?
что делают другие компании? подойдет ли эта архитектура для больших организаций, использующих несколько доменов? заменит ли сетка данных архитектуру
озер-хранилищ? как реализовать серебряный уровень на практике?
Каждый раз, когда я обсуждаю концепцию архитектуры медальона, мне кажется,
что я разгадываю сложную головоломку. Несмотря на простой иерархический
подход к решению архитектурных вопросов, постоянное отсутствие четких
определений и руководств с описаниями все время приводит к недопониманию,
недоразумениям и неэффективности в организациях. Это побудило меня принять ответственное решение: написать книгу, которая бы содержала подробное
руководство по архитектуре медальона, с понятными рекомендациями для профессионалов, которые ищут выход из этого сложного лабиринта.
Я занялся серьезным изучением архитектуры медальона (Medallion architecture).
Мои исследования и практический опыт показали, что она сильно пересекается
с такими темами, как хранилища данных (data warehouses), управление данными
(data governance), управление метаданными (metadata management) и моделирование данных (data modeling). Эти элементы не существуют сами по себе; они
связаны и влияют друг на друга на фундаментальном уровне. Понимая текущие
проблемы и осознавая необходимость внести ясность в профессиональное сообщество, я решил создать ресурс, который бы стал источником знания. Я также
узнал, что, как и у многих хороших вещей в жизни, у хороших архитектур есть
свои особенности.
Книга «Архитектура медальона» — моя попытка развеять завесу тайны вокруг
сложной темы. Прежде чем браться за работу, я проводил опросы среди профессионалов, чтобы понять, чего читатели могут ожидать от книги. Многие практики
хотели увидеть прикладное руководство и компетентное изложение таких тем,
как сетки данных (data mesh) и генеративный ИИ, при этом отмечая важность
управления данными и безопасности. Они также выразили сильное желание
учиться на опыте других реальных организаций. Работая над книгой, я учитывал
всю эту обратную связь.
В книге я рассмотрел широкий спектр тем, относящихся к архитектуре медальона. Тем не менее на основании полученной обратной связи мне пришлось отдать
предпочтение некоторым областям перед другими. В результате вы не найдете
в книге глубокого обсуждения непрерывной интеграции и развертывания (CI/

Введение


  

18

CD), DataOps, машинного обучения, происхождения данных (data lineage) или
моделирования бизнес-данных. Эти темы действительно важны, но они требуют
отдельного подробного обсуждения, которое выходит за рамки этой книги. Вместо
этого я решил сосредоточиться на самых актуальных областях, оказывающих
наибольшее влияние на остальные, чтобы информация была практичной и пригодилась в вашей работе.
Я постарался удовлетворить ожидания читателей и предоставить ясные, прямолинейные рекомендации и определения, которые помогут вам эффективно
реализовать архитектуры медальона. И новичку, все еще разбирающемуся
в азах архитектуры озер-хранилищ, и разработчику, который собирается
взяться за свой первый проект, будет полезно, если мы пройдем этот сложный
путь вместе.
Структура книги ориентирована на максимально широкую аудиторию. Каждый
раздел посвящен определенному свойству архитектуры медальона. Книга начинается с изучения эволюции архитектуры данных и разбора ключевых практик
из прошлого и настоящего. Затем четко и непредвзято представляются основные концепции архитектуры медальона. Переходя от теории к практике, книга
предлагает подробные описания, на которых читатель может обучаться. Кроме
того, в ней представлены реальные примеры успешной реализации архитектур
медальона в различных компаниях с описанием лучших практик и типичных
ловушек. Наконец, в книге обсуждаются такие новые тенденции, как сетка данных, управление данными, контракты данных, безопасность и искусственный
интеллект (ИИ); эта информация будет полезной для читателей, желающих
расширять и масштабировать свои архитектуры данных.
Я надеюсь, что книга «Архитектура медальона» станет полезным источником информации для широкого круга читателей, от новичков до опытных профессионалов. Что бы вы ни искали: основательное введение в тему, практические примеры,
описания реальных сценариев применения или более глубокие знания, — в этой
книге вы обязательно найдете для себя что-то полезное.

Для кого эта книга
Если вы выбрали эту книгу, скорее всего, вы уже работаете с данными. Возможно,
вы планируете создать новую платформу данных, ищете возможности для расширения существующей платформы или просто интересуетесь, почему вокруг
столько разговоров об архитектуре медальона. Возможно, вы хотите узнать, как
она работает, как эффективно ее реализовать и можно ли адаптировать ее для
ваших конкретных потребностей.
Вы можете быть членом команды дата-инжиниринга или архитектуры предприятия либо занимать ключевую роль CDO (Chief Data Officer, директор по данным). А может, вы дата-инженер, специалист data science или менеджер данных.
Или даже входите в команду более широкого профиля, связанную с данными.

  

Структура книги

19

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

Структура книги
Книга представляет собой практическое руководство, которое поможет читателю
понять и реализовать одну или несколько архитектур медальона. Она пригодится
и тем, кто уже знаком с концепцией и хочет глубже в ней разобраться. В книге
подробно рассматривается роль технологического стека Azure в реализации
реальной архитектуры медальона. Мы рассмотрим такие сервисы, как Microsoft
Fabric, но не с целью их продвижения или прямого сравнения с другими сервисами. Главное, это углубить ваше понимание архитектуры медальона и объяснить,
как применять ее на практике.
Так как технологии стремительно развиваются, я решил сосредоточиться на зарекомендовавших себя сервисах и функциональности, которые вряд ли заметно
изменятся в ближайшем будущем. Например, такие инструменты, как Apache
Airflow, (Azure) Data Factory, PySpark и методы на основе метаданных (metadatadriven), надежны и хорошо адаптируются к различным условиям. Навыки,
которые вы приобретете при использовании Microsoft Fabric, также позволят
эффективно работать с другими платформами на базе Spark и Delta Lake.
Книга делится на четыре части, следуя от теории к практике.
В части I «Основные принципы архитектуры медальона» мы начнем с крат­
кого знакомства с историей эволюции архитектур данных. Сначала рассмотрим историю темы, а также текущие лучшие практики, чтобы понять,
как развивалась архитектура данных. Чтобы разобраться в сложностях
современных данных, необходимо понимать, какие прежние концепции
остались актуальными и как они трансформировались. Затем мы займемся
изучением тонкостей архитектуры медальона, разбив ее на базовые концепции и этапы реализации.
Часть II «Построение уровней медальона» уже более практическая. В ней мы
рассмотрим весь процесс создания архитектуры медальона на базе Microsoft
Fabric. Для читателей, интересующихся Azure Databricks, добавлена ссылка
на сторонний пост в блоге, содержащий дополнительный контент и предлагающий альтернативный путь обучения. Материал этой части книги очень
разнообразен — от фундаментальных концепций до сложных стратегий,

  

20

Введение

причем без привязки к конкретной технологии. Это гарантирует, что вы
сможете эффективно применять полученную информацию в любых архитектурах озер-хранилищ.
Часть III «Реальные примеры» заполняет пробел между теорией и практикой.
В ней приводятся интервью с профессионалами, которые успешно реализовали
архитектуры медальона в своих организациях. Вы узнаете, как AP Pension,
Amadeus и ZEISS применяли архитектуру медальона для повышения качества
обработки данных и возможностей аналитики.
В завершающей части IV «Масштабирование, управление данными и будущее архитектур медальона» мы обсудим, как масштабировать архитектуры
медальона для крупных сред предприятия. Также затронем такие нетривиальные темы, как сетки данных и контракты данных. Напоследок мы заглянем
в будущее архитектур медальона и изучим применение генеративного искусственного интеллекта.

Условные обозначения
В этой книге используются следующие условные обозначения:
Курсив
Курсивом выделены новые термины или важные понятия.
Моноширинный шрифт

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

Этот рисунок указывает на общее примечание.

Этот рисунок указывает на предупреждение.

  

Благодарности

21

Использование исходного кода примеров
В книге приводятся многочисленные фрагменты кода и параметры конфигурации,
необходимые для понимания концепций и составления исчерпывающих описаний. Вспомогательные материалы (примеры кода, упражнения и т. д.) доступны
для свободной загрузки на моей странице GitHub по адресу: https://github.com/
pietheinstrengholt/building-медальона-architectures-book.
Если у вас возникнут вопросы технического характера, касающиеся использования примеров кода, направляйте их по электронной почте на адрес support@
oreilly.com.
Главная задача этой книги — помочь вам успешно решать свои задачи. В общем
случае все примеры кода из книги вы можете использовать в своих программах
и в документации. Вам не нужно обращаться в издательство за разрешением, если
вы не собираетесь воспроизводить существенные части программного кода. Если
вы разрабатываете программу и используете в ней несколько фрагментов кода
из книги, разрешение издательства O’Reilly не требуется. Но для продажи или
распространения примеров из книги оно обязательно. Вы можете отвечать на
вопросы, цитируя эту книгу или примеры из нее, но на включение существенных
объемов программного кода из книги в документацию вашего продукта потребуется разрешение.
Мы рекомендуем, но не требуем добавлять ссылку на первоисточник при цитировании. Под ссылкой на первоисточник мы подразумеваем указание авторов,
издательства и ISBN.
За разрешением на использование значительных объемов программного кода из
книги обращайтесь по адресу permissions@oreilly.com.

Благодарности
Специалисты-практики в области данных, дата-инженеры и другие эксперты значительно улучшили эту книгу. Я старался написать серьезное, но при этом легко
читаемое руководство. Если у меня это получилось, то во многом это заслуга замечательных интеллектуалов, которые поддерживали меня на этом пути. Спасибо
всем, кто внес свой творческий вклад и помог воплотить этот проект в жизнь.
Особо хочу отметить за бесценную обратную связь и предложения ряд людей.
Это Оле Олсен-Багно (Ole Olesen-Bagneux), Кристофер Мендик (Christopher
Mendyk), Айтор Мургузур (Aitor Murguzur), Джеймс Серра (James Serra), Майянк
Шривастава (Mayank Srivastava), Джейми Сасикумар (Jaimi Sasikumar), Генри
Корнегор (Henri Kornegoor), Франческо Фава (Francesco Fava), Пол Эндрю (Paul
Andrew), Кристоф ван дер Лок (Kristof van de Loock), Джако ван Гелдер (Jaco van
Gelder), Корне Потжетье (Corné Potgieter), Саймон Остер (Simon Oster), Барт
ван дер Хулст (Bart van der Hulst), Даан Хамбл (Daan Humble), Батухан Тьютер

  

22

Введение

(Batuhan Tüter), Праджнан Шарма (Prajnan Sharma), Джонас де Кестер (Jonas de
Keuster), Рене Бремер (René Bremer), Бен Кузи (Ben Kuzey), Реми Урсем (Remy
Ursem), Марк Бенсон (Mark Benson), Санджив Мохан (Sanjeev Mohan) и Сарат
Сасидхаран (Sarath Sasidharan). Ваша аналитика и поддержка действительно
сделали эту книгу такой, какая она есть, и я глубоко благодарен за ваше участие.
Спасибо команде Databricks, включая Айзека Гритца (Isaac Gritz), Майкла Дэвисона (Michael Davison) и Франко Патано (Franco Patano) за полезную аналитическую обратную связь. Я очень благодарен вам за помощь.
Отдельная благодарность Якобу Ренноу Иенсену (Jacob Rønnow Jensen) за
помощь в работе с главой об AP Pension. Открытость нашего общения и ваши
проницательные наблюдения были чрезвычайно важны, и я глубоко ценю ваши
полезные предложения.
Огромное спасибо компании Amadeus, особенно Джоэлу Сингеру (Joel Singer)
и Бертрану Коньяру (Bertrand Cognard). Ваши наблюдения и опыт были бесценными, и я благодарен за вашу поддержку.
Не могу не упомянуть команду Carl Zeiss, включая Маркуса Моргнера (Markus
Morgner), Сашу Сомера (Sascha Saumer) и Герта Кристена (Gert Christen). Спасибо за ваши наблюдения и открытость в общении.
Большое спасибо Скотту Хейнсу (Scott Haines), соавтору книги «Delta Lake:
The Definitive Guide» (O’Reilly), за его наблюдения и обратную связь. Он оказал
огромную помощь, пояснив ряд нюансов в книге.
Хочу поблагодарить Саймона Уайтли (Simon Whiteley) — потрясающий источник
вдохновения и поддержки. На мой взгляд, вы образцовый лидер сообщества.
Также я благодарю команду O’Reilly Media, особенно Мишель Смит (Michelle
Smith), за поддержку, и моих замечательных редакторов Ширу Эванс (Shira
Evans) и Кэтрин Тозер (Katherine Tozer). Ваши советы и поддержка сыграли
решающую роль в создании этой книги, и я благодарен за работу с такой замечательной командой.
Наконец, я глубоко благодарен своей жене Джессике и нашим трем дочерям —
Джулии, Валери и Максим — за их постоянную поддержку и содействие. Ваша
любовь и понимание освещали весь этот долгий путь.

Часть I
Основные принципы
архитектуры медальона

Первая часть этой книги поможет начать освоение сложных архитектур данных.
Она начинается с подробного обзора эволюции архитектур данных, а продолжается углубленным теоретическим анализом архитектуры медальона, закладывая
прочную теоретическую основу для дальнейшего изучения. В ней рассматривается историческое развитие модели медальона и особенности ее конкретных уровней. Это подготовит вас к рассмотрению сценариев практического применения
этой модели, представленным в последующих главах.
В главе 1 начинается знакомство с историей развития архитектур данных. В ней
обсуждается происхождение таких систем, определяющие принципы проектирования, которые продолжают влиять на современные архитектуры, а также
практические уроки, усвоенные за десятилетия управления данными. Эта глава
необходима для всех, кто хочет твердо освоить фундаментальные концепции,
характерные для архитектуры медальона и других систем данных.
В главе 2 будут рассмотрены основные предусловия, на которых строится архитектура медальона. В ней описаны ключевые концепции и паттерны, которые
будут часто встречаться при подробных обсуждениях других глав.
В главе 3 мы перейдем к подробному исследованию самой архитектуры медальона.
Здесь обсуждаются все уровни модели медальона, их функции, взаимодействия,
а также отмечается стратегическая важность каждого компонента. Хотя материал этой главы теоретический, он помогает связать абстрактные концепции с их
практическими следствиями и подготовиться к детальному рассмотрению их
применения на практике в последующих главах.
Все вместе эти главы обеспечивают полноценное введение в темы и концепции,
которые будут развиваться в книге. Изучить их стоит каждому, кто хочет глубже
понять структуру и полезность нетривиальных архитектур данных в современных
средах предприятий.

ГЛАВА 1

Эволюция архитектуры данных
Создание надежной архитектуры данных — одна из самых сложных задач при
работе с данными. Процесс обработки данных — от их сбора до преобразования,
распространения и итогового потребления — сильно зависит от множества разных
факторов: средств управления данными (governance), используемых инструментов, профиля рисков организации, размера, зрелости, требований сценариев
использования и других потребностей, включая производительность, гибкость
и управление затратами.
Несмотря на эти отличия, каждая архитектура данных включает несколько
основных компонентов. Я часто рассматриваю их через призму трехуровневой
архитектуры — концепцию, которую я представил в своей предыдущей книге
«Data Management at Scale»1 (O’Reilly). Этот дизайн стал полезным инструментом
концептуализации и структурирования стратегий управления данными предприятий. Он включает три уровня: на первом размещаются поставщики данных,
второй служит платформой распространения, а третий включает потребителей
данных. Кроме того, всеобъемлющий уровень метаданных и управления необходим для контроля за всей архитектурой данных. Высокоуровневая схема этого
дизайна изображена на рис. 1.1.

Уровень метаданных и управления данными

1. Поставщики
данных

2. Уровень распространения

3. Потребители
данных

Рис. 1.1. Трехуровневая архитектура

1

Стренгхольт П. «Масштабируемые данные. Высоконагруженные архитектуры, Data
Mesh и Data Fabric», 2-е изд.

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

25

Краткое описание каждого уровня (слева направо):
Первый уровень
Уровень включает поставщиков данных, представляющих источники, из
которых извлекаются данные. Извлеченные данные характеризуются разными типами, форматами и местоположениями, распределенными по разным
организациям.
Второй уровень
Этот уровень представляет платформу распространения. Для него характерна
высокая сложность, обусловленная огромным выбором доступных инструментов и технологий. Организации сталкиваются с непростой задачей выбора из
сотен (если не тысяч) продуктов и решений с открытым кодом для проведения
интеграции.
Третий уровень
Этот уровень включает потребителей данных, а точнее, сервисы-потребители
данных. Сервисы данных используют бизнес-аналитику, машинное обучение
и искусственный интеллект (ИИ) для построения прогнозов, автоматизации
и выявления закономерностей в реальном времени. Другие сервисы обеспечивают основные функции хранения и обработки данных. Этот уровень включает
разнообразные технологии и типы приложений, так как каждая бизнес-задача
требует специализированного решения; как следствие, оба типа сервисов
играют важную роль в современных архитектурах данных.
Чтобы завершить высокоуровневое описание архитектуры, я обычно рисую охватывающий уровень, который называется уровнем метаданных и управления
данными. Этот уровень очень важен для общего контроля и управления всей
архитектурой данных.
Трехуровневая диаграмма (в которой особенно важное место занимает внутренняя архитектура среднего уровня) отражает эволюцию управления платформой
данных в организациях. Она демонстрирует значительный сдвиг от традиционных
проприетарных систем хранилищ данных (data warehouses) к более гибким распределенным архитектурам данных с открытым исходным кодом. Этот переход
обусловлен появлением фреймворков и инструментов с открытым кодом, объединяемых общим термином «современный стек данных».
Проблема в том, что современный стек данных сам по себе не представляет завершенной платформы данных. Он требует интеграции многих независимых
сервисов и инструментов, каждый из которых проектировался под конкретные
элементы обработки и управления данными. Каждый сервис или инструмент приносит свой набор стандартов обмена данными, протоколов безопасности и средств
управления метаданными. Более того, пересекающиеся функциональности многих сервисов усложняют развертывание и использование. Таким образом, чтобы

  

26

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

эффективно использовать современный стек данных, необходимо тщательно
выбрать наиболее подходящие сервисы, а затем тщательно провести интеграцию
каждого компонента. Процесс интеграции существенно затрудняет начало работы.
«Это упущение не какого-то отдельного поставщика; это упущение рынка
в целом»1.
Бенн Стэнсил
Поставщики технологий тоже видят эту проблему. Они признают сложность
интеграции и управления инфраструктурой, хранения данных и вычислений.
В области разработки и стандартизации был достигнут значительный прогресс,
особенно в Apache Spark (https://spark.apache.org) и форматах таблиц с открытым
исходным кодом, таких как Delta Lake (https://docs.delta.io/latest/index.html). Это
привело к созданию полнофункциональных программных платформ, упрощающих обработку данных. Многие инженеры данных предпочитают эти платформы
за их инновационные возможности. Вдобавок организации, пользующиеся Spark
и Delta Lake, обнаружили, что архитектура медальона (определение которой
приводится в следующем разделе) особенно удобна, так как она использует
все сильные стороны мощной, масштабируемой и эффективной структуры для
сквозного управления данными и аналитики.

Что такое архитектура медальона?
Архитектура медальона — это паттерн проектирования данных, предназначенный для их логической организации (чаще всего в озерах-хранилищах). В нем
используются три уровня платформы данных, на каждом из которых происходит
пошаговое и последовательное улучшение структуры и качества данных (бронзовый ⇒ серебряный ⇒ золотой уровни). В главе 3 каждый из уровней будет
рассмотрен более подробно, а пока я ограничусь их кратким описанием:
Бронзовый уровень (Bronze)
На бронзовом уровне хранятся сырые данные из разных источников в их исходной структуре. Уровень служит точкой отсчета изменений и надежным
исходным хранилищем.
Серебряный уровень (Silver)
На серебряном уровне данные очищаются и стандартизируются для комплексной аналитики посредством проверки качества, стандартизации, удаления
дубликатов и других преобразований. Это переходный этап, на котором получают обработанные детализированные согласованные данные лучшего качества.
1

Цитата из статьи Бенна Стэнсила (Benn Stancil) Microsoft Builds the Bomb (https://oreil.
ly/FMlrI), в которой рассматриваются проблемы решений платформ данных на уровне
рынка.

  

Что такое архитектура медальона?

27

Золотой уровень (Gold)
На золотом уровне очищенные данные оптимизируются для конкретных
бизнес-идей и решений. На нем происходит агрегирование, обобщение и обогащение данных для получения высокоуровневых отчетов и аналитики, при
этом на первый план выходят производительность и масштабируемость, обес­
печивающие быстрый доступ к ключевым метрикам и аналитике.
Такая структура, изображенная на рис. 1.2, отлично подходит для практической
реализации или сценариев использования, способствующих развитию бизнеса.

Уровень метаданных и управления

Архитектура медальона
Источники
данных

Бронзовый

Серебряный

Золотой

Сервисы
интеллектуальной обработки
и потребления
данных

Рис. 1.2. В архитектуре медальона данные упорядочиваются по трем уровням, на каждом из которых
структура и качество данных постепенно улучшаются
Архитектура медальона предоставляет обозначения разных уровней, удобные
для стороны бизнеса. Тем не менее многие организации не могут понять, как
организовать эффективное распределение по уровням и моделирование своих
данных, и тратят бесчисленные часы на обсуждение таких вопросов, как выбор,
интеграция, пересечение функциональности и т. д. У них возникают трудности
с распределением целей по разным зонам или пониманием смысла уровней
Bronze, Silver и Gold. Также возникают вопросы относительно управления данными и стратегий масштабирования. Например, какие части архитектуры могут
управляться метаданными с гибкой настройкой конфигурации и автоматизацией?
Выбор полнофункциональной платформы не даст готовых ответов на вопросы
и не решит этих проблем.
Прежде чем погружаться в конкретику ответов на эти вопросы и проектирование
архитектуры медальона, необходимо понять ход эволюции архитектур данных.
Где появились эти платформы? Какие принципы проектирования остаются актуальными и должны применяться и в наши дни? Понимание истории и фундаментальных принципов архитектур данных поможет эффективно использовать эти
сквозные платформы. Эта глава как раз и содержит такую вводную информацию.
В ней исследуются прошлые достижения, наблюдения, паттерны, лучшие практики и принципы. Вооружившись необходимой информацией, обоснованиями
и выводами, вы будете готовы к части II, в которой научитесь проектировать
и реализовывать собственные архитектуры данных.

  

28

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

Если вы чувствуете, что уже достаточно хорошо разбираетесь в основах архитектуры данных, можете перейти к главе 3, в которой дается подробное описание архитектуры медальона и ее уровней. Если нет — начинайте вместе с нами
знакомиться с традиционными хранилищами данных. Затем мы перейдем к исследованию паттернов, появившихся с озерами данных (data lakes), включая
Hadoop. Мы обсудим достоинства, недостатки и выводы, которые были сделаны
из каждой архитектуры, а также связь этих разработок с современными лучшими
практиками. Наконец, мы подробно рассмотрим озера-хранилища и архитектуры
медальона, между которыми существует тесная связь. В этом разделе мы также
обсудим разных поставщиков технологий.

Краткая история архитектуры хранилищ данных
Мысленно вернемся в 1990-е годы. Тогда для сбора и интеграции данных
в однородные коллекции стали использоваться хранилища данных (data
warehouse). Они позволяли создать единую версию истинных данных, служащую ключевым источником информации для принятия бизнес-решений
в компании.
Процесс получения аналитики на основе данных состоит из нескольких этапов,
включая сбор данных из разных источников, приведение их к единому формату
и загрузку в центральный репозиторий. Этот процесс более подробно рассматривается в главе 3. А пока сосредоточимся на архитектуре хранилища данных
(рис. 1.3), которая также включает сервисы-источники и сервисы-потребители
(например, средства составления отчетов).

Источники
OLTPсистемы
OLTPсистемы
OLTPсистемы

Операционный
репозиторий
данных

Область
промежуточного
хранения
Файловый
репозиторий

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

Витрина
данных
Витрина
данных

Метаданные
Рис. 1.3. Типичная архитектура хранилища данных

Средства
составления
отчетов

  

Краткая история архитектуры хранилищ данных

29

Начнем с рассмотрения уровней от OLTP-систем (слева) до хранилищ данных
в середине. Витрины данных (data marts) в правой части рассматриваются в разделе «Методология Инмона», с. 33.

OLTP-системы
Большая часть систем-источников проектировалась для транзакционных или
эксплуатационных целей, что отражало потребности в управлении транзакциями
и хранении записей в эпоху ранних вычислительных технологий. Такие источники, показанные на рис. 1.3 слева, часто назывались системами онлайн-обработки
транзакций, или OLTP-системами (OnLine Transaction Processing), что описывало
их основное назначение.
Внимательнее присмотревшись к OLTP-системе, можно заметить, что рабочие нагрузки в ней обычно весьма предсказуемы. Вы должны понимать, как используются
OLTP-системы и какие типичные нагрузки можно ожидать. Запросы относительно
просты, а объем полученных данных невелик: прочесть запись, обновить, удалить
и т. д. Нижележащая физическая модель данных проектируется (оптимизируется)
для таких предсказуемых запросов. В результате OLTP-системы обычно нормализуются так, чтобы каждый атрибут хранился только в одном экземпляре.

Нормализованные и денормализованные базы данных
В контексте реляционных баз данных нормализацией называется процесс
изменения структуры данных для удаления избыточности и улучшения
целостности данных. Обычно нормализация представляет собой приведение данных к одной из нормальных форм, каждая из которых устраняет
конкретные аномалии или избыточность. На практике чаще всего применяется третья нормальная форма (3NF). Нормализация позволяет хранить
данные более эффективно и последовательно, упрощая обслуживание
и выборку данных. Таким образом, говоря о нормализованных данных,
мы имеем в виду данные, организованные с расчетом на эффективность
хранения и целостность.
Денормализацией называется процесс отмены эффекта нормализации
с намеренным введением в базу данных избыточности с целью ускорения обработки запросов и получения данных. Денормализация часто
используется в хранилищах данных и аналитике для оптимизации выборки и обработки данных. Выполняя денормализацию данных, можно
сократить количество соединений, необходимых для загрузки данных,
что может значительно улучшить производительность запросов. С другой
стороны, денормализация также может создавать проблемы целостности
данных, так как неправильное управление может привести к несоответствиям в избыточных данных.

  

30

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

Многие OLTP-системы нацелены на обеспечение в первую очередь целостности
и стабильности. Для этого они используют системы управления базами данных,
поддерживающие свойства ACID: атомарность (Atomicity), согласованность
(Consistency), изоляцию (Isolation) и устойчивость (Durability)1. Эти свойства
важны для эффективного проведения бизнес-транзакций, так как они помогают
управлять данными и защищать их в процессе работы. Однако дизайн OLTP
влечет за собой ряд последствий, которые необходимо понимать, особенно при
обсуждении в организации.
Во-первых, операционные системы не предназначены для того, чтобы предоставлять полный и консолидированный аналитический обзор всего, что происходит
в бизнесе или конкретных предметных областях. Дело в том, что извлечение
данных из моделей с высокой степенью нормализации для сложных запросов
часто затруднительно из-за высокой нагрузки на OLTP-системы. Чтобы получить нужную информацию, требуются сложные запросы. Такие запросы требуют
больших объемов данных и их комбинаций, а это означает, что многие таблицы
придется соединять или группировать.
Кроме того, запросы такого типа обычно интенсивно расходуют ресурсы, и при
слишком частом их выполнении производительность может быть ограниченна,
особенно при работе с большими датасетами2. Если такие проблемы приводят
к аномальному поведению операционной системы, это может отрицательно
сказаться на бизнесе. Следовательно, очень важно тщательно продумать потенциальные последствия нормализованной структуры. Хотя нормализация может
эффективно работать для некоторых целей, она не всегда подходит для получения
больших аналитических представлений данных.
Во-вторых, из-за жестких требований к высокой целостности, производительности и доступности OLTP-системы часто обходятся дорого. Типичная стратегия
оптимизации таких систем включает перемещение неиспользуемых данных и/или
проектирование систем для работы только с самыми новыми данными. Такой подход означает, что обновление данных будут происходить моментально без сохранения старых версий записей. В контексте виртуализации данных3 инженеры иногда
считают, что все исторические данные должны храниться в OLTP-системах, а не
в хранилище, озере данных или озере-хранилище. Но из-за особенностей дизай1

2

3

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

  

Краткая история архитектуры хранилищ данных

31

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

Хранилища данных
Хранилище данных (data warehouse) служит центральным хабом. Оно используется для сбора и структурирования данных из разных систем-источников, их
преобразования к последовательному формату для аналитической обработки
в реальном времени, или OLAP (OnLine Analytical Processing), включающей
сложные специфические вычисления. Анализ в автономном режиме обычно
менее критичен для бизнеса, и требования к целостности и доступности таких
систем могут быть менее жесткими. Хотя данные в OLTP-системах хранятся
и оптимизируются в плане целостности и избыточности, в OLAP оптимизируется аналитическая производительность. Поэтому OLAP, где в основном выполняются повторяющиеся операции чтения при редких операциях записи, обычно
оптимизируется для интенсивного чтения данных. Например, данные могут
дублироваться для паттернов чтения в различных аналитических сценариях.
Таблицы в базах данных OLAP обычно не подвергаются жесткой нормализации,
но в ходе предварительной обработки преобразуются в денормализованные
структуры: как правило, в большие деструктурированные разреженные копии
данных.
В книге «Deciphering Data Architectures» Джеймса Серра (James Serra) (издательство O’Reilly)1 приводится подробный обзор архитектур данных, включая хранилища, озера и озера-хранилища данных. Это ценный источник
информации об эволюции архитектур данных и принципов, лежащих в их
основе.
1

Серра Дж. «Архитектуры данных: современные решения для любых задач».

  

32

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

Чтобы загрузить данные в хранилище данных, необходимо первым делом
извлечь их из разных систем-источников. Для этого необходимо понимать
исходные данные, а также прочитать и скопировать необходимые данные в область, часто называемую областью промежуточного хранения (staging area), для
последующей обработки. Область промежуточного хранения, как показано на
рис. 1.3, располагается между операционными системами-источниками и областью интеграции данных и представления. Она часто представляет собой
как область хранения, так и совокупность процессов, объединяемых общим
термином ETL (Extract, Transform, Load — извлечение, преобразование и загрузка).

Область промежуточного хранения
Область, или уровень, промежуточного хранения может быть реализована разными способами, которые не ограничиваются реляционными базами данных
и файловыми репозиториями. Реляционные базы данных гибкие, но дорогие.
Файловые репозитории дешевы, но ограничены по функциональности. Области промежуточного хранения также обычно используются для хранения
исторических копий. Это полезно для повторного воспроизведения сценариев,
когда поврежденное хранилище данных необходимо восстановить. Количество
старых поставок данных (исторических копий) в разных областях промежуточного хранения разных организаций может различаться. Мне знакомы сценарии,
когда все поставки данных, включая исправления, должны были храниться для
целей аудита в течение нескольких лет. И наоборот, я видел, как область промежуточного хранения очищалась после успешной обработки или по истечении
фиксированного периода времени. В этом контексте очистка производится
для снижения затрат на хранение или может быть обусловлена требованиями
к управлению данными.
Сложности с извлечением и промежуточным хранением связаны с тем, что
разные системы-источники могут использовать разные типы формата данных.
Следовательно, реальный процесс загрузки данных будет значительно изменяться
в зависимости от типа источника данных. Некоторые системы допускают прямые
обращения к базе данных, другие требуют, чтобы загрузка, или прием (ingestion),
данных производилась через API. Несмотря на технологические достижения,
многие процессы сбора данных продолжают зависеть от извлечения файлов, поскольку этот способ оказался более экономичным и простым в реализации для
больших объемов данных.
После извлечения данных в область промежуточного хранения к ним применяются
различные преобразования: очистка, обогащение, управление мастер-данными
и назначение ключей хранилища. Все эти преобразования представляют собой
предварительные шаги, в ходе которых данные из разных источников соединяются,
преобразуются и загружаются в области интеграции и представления в хранилище
данных. В большинстве случаев требуется переработать сильно нормализованные

  

Краткая история архитектуры хранилищ данных

33

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

Итак, остается вопрос: как моделировать данные в областях интеграции и представления? Рассмотрим две основные методологии: Инмона и Кимбалла.

Методология Инмона
К сожалению, в среде дата-инженеров сохраняется недопонимание относительно
того, должны ли данные после извлечения и преобразования и перед загрузкой
в область представления для генерирования запросов и отчетов моделироваться
в физические нормализованные структуры. Это недопонимание обусловлено
различием подходов к обработке данных.
Традиционно хранилища данных стоили дорого. Методология Инмона, появив­
шаяся в начале 1990-х и получившая название по фамилии своего создателя Билла
Инмона (Bill Inmon), показана на рис. 1.4. Это был популярный метод, основанный на нормализованной модели данных, обычно в третьей нормальной форме.
Модель 3NF структурирует данные в таблицы с минимальной избыточностью; она
гарантирует, что каждый блок данных хранится только в одном экземпляре, а дуб­
ликаты данных исключены. Она также обеспечивает целостность ссылок, так как
каждый непервичный атрибут таблицы зависит только от первичного ключа. Этот
метод значительно снижает требования к необходимому пространству хранения.
Кроме того, он подразумевает создание централизованного высокоструктурированного хранилища данных, называемого корпоративным хранилищем данных (EDW,
Enterprise Data Warehouse), которое обслуживает всю организацию.
Для запросов и улучшения производительности методология Инмона также
включает уровень представления: витрины данных (data marts). Они создаются
после надежного сохранения данных на уровне интеграции. Обычно витрины
данных содержат лишь небольшое подмножество данных уровня интеграции
и проектируются для конкретного сценария использования, группы или круга
пользователей. Данные в таких витринах обычно организуются по схеме «звезда»,
так как они оптимизированы для быстрого чтения. Простота и денормализация
структур данных в схемах «звезда» — основные причины того, почему эти схемы хорошо подходят для операций с интенсивным чтением. Соответственно,
можно заметить, что данные в витринах данных хранятся менее эффективно по
сравнению с уровнем интеграции. Кроме того, преобразование данных из 3NF на
уровне интеграции в денормализованную модель в витринах данных потребует
значительных усилий. Этот процесс часто включает сложные соединения (joins)

  

34

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

для пересборки данных и полного восстановления их значений для более эффективного анализа и запросов информации1.

Область
промежуточного
хранения
Файловый
репозиторий

Обычно реализуется в той же базе данных
(РСУБД)
Витрина данных

Хранилище данных
Уровень интеграции

Витрина данных

Средства
составления
отчетов

Витрина данных

Рис. 1.4. Методология Инмона — нисходящий дизайн, в котором сначала строится централизованное
хранилище данных, а затем на его основе создаются витрины данных
Многие практикующие специалисты с осторожностью относятся к использованию
нормализованных структур на уровне интеграции и пространственных структур для
целей представления. Это связано с тем, что данные извлекаются, преобразуются
и загружаются дважды. Сначала данные извлекаются, преобразуются и загружаются на нормализованном уровне интеграции. Затем все это делается заново для
итоговой загрузки данных в многомерную модель. Разумеется, этот двушаговый
процесс требует больше времени и ресурсов для разработки, больше времени для
периодической загрузки или обновления данных и больше пространства для хранения копий данных. Другой недостаток заключается в том, что при добавлении
новых данных в витрину их придется сначала добавить на уровень интеграции. Так
как разработка требует времени, а изменения на уровне интеграции — крайней осторожности, пользователям, запрашивающим новые данные, придется дольше ждать.
Более того, избыточность — дублирование данных, без которого можно обойтись, — часто преподносится как проблема на уровне интеграции Инмона. Тем не
менее в эпоху облачных вычислений этот аргумент уже не столь актуален. Облачные хранилища стали довольно дешевы, тогда как вычисления могут оставаться
затратными. Из-за этих высоких затрат многие эксперты сейчас предпочитают
метод моделирования данных Кимбалла.
1

Здесь речь идет о «сборке обратно» бизнес-объектов согласно бизнес-доменам для того,
чтобы на них потом удобнее было смотреть аналитикам. — Примеч. науч. ред.

  

Краткая история архитектуры хранилищ данных

35

Методология Кимбалла
Методология Кимбалла, названная по имени ее создателя Ральфа Кимбалла
(Ralph Kimball), была представлена в 1996 году как метод моделирования данных
и часто используется при организации хранилищ данных1. Она ориентируется
на создание таблиц измерений для эффективной аналитической обработки. При
таком подходе сначала создаются размерные витрины данных для реакции на потребности бизнеса. Для этого Кимбалл рекомендует применять метод размерного
моделирования с использованием схемы «звезда».
Абстрактное представление методологии Кимбалла изображено на рис. 1.5.

Область
промежуточного
хранения
Файловый
репозиторий

Обычно реализуется в той же базе данных (РСУБД)
Хранилище данных
Представления

Витрина данных

Средства
составления
отчетов

Рис. 1.5. Методология Кимбалла — восходящий метод построения хранилищ данных
В этом подходе к моделированию данных уровень интеграции хранилища данных
рассматривается как конгломерат или набор таблиц измерений (dimension tables),
которые являются производными копиями транзакционных данных из системисточников. Переданные на уровень интеграции данные уже оптимизированы для
быстрого чтения. Эти данные, более плоские и разреженные, сильно напоминают
структуры витрин данных в методологии Инмона. Однако в отличие от модели
Инмона уровень интеграции у Кимбалла включает таблицы измерений, образующие основу для витрин данных. Таким образом, модель Кимбалла не только
признает существование витрин данных, но и рассматривает их как необходимые
для повышения производительности и создания подвыборок. Витрины данных
допускают агрегирование или изменение хранимых копий данных на основании
требований групп пользователей. Интересно, что витрины данных также могут
1

Ральф Кимбалл представил концепцию размерного моделирования для отрасли хранилищ данных / бизнес-аналитики в 1996 году в своей авторитетной книге The Data
Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses (John
Wiley & Sons).

  

36

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

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

Путаница с функциями уровней хранилищ данных
Важно пояснить, что с функциями уровней хранилищ данных иногда
возникает путаница, такая же, как та, что может возникнуть при формировании уровней архитектуры медальона. Эти разные уровни, образующие среднюю часть общей большой архитектуры, проектируются для
закрепления заметно различающихся обязанностей за разными этапами,
соответствующими распространенным практикам в архитектуре ПО. Как
правило, присутствует уровень промежуточного хранения (staging) или
загрузки (ingestion), на котором хранятся сырые данные; этот уровень
фактически отделяет системы-источники от хранилища данных. За ним
следует уровень интеграции или трансформации, на котором данные
интегрируются после выполнения всех приемочных критериев области
промежуточного хранения. Здесь очищенные, исправленные, обогащенные и преобразованные данные хранятся в унифицированной модели.
Эта модель гармонизирована, что означает, что форматы, типы, имена,
структуры и отношения в ней стандартизированы. Уровень также содержит исторические данные, обрабатываемые для получения информации
об изменениях во времени. Наконец, присутствует уровень представления (или презентационный уровень), на котором выбираются данные,
актуальные для конкретных сценариев использования. Модель данных
подстраивается под специфические требования сценариев использования.
Однако важно отметить возможные веские причины отхода от этой
традиционной трехуровневой архитектуры хранилища данных. Ради
гибкости или возможности аудита некоторые организации реализуют
дополнительные уровни. Например, можно добавить дополнительный
уровень для аудируемости, где источники сначала связываются с целевой моделью перед слиянием с другими источниками. Также область
промежуточного хранения может быть разбита на дешевый файловый
репозиторий со всеми поставленными данными и реляционную базу
данных, содержащую только самые последние проверенные данные. Ключевой вывод: количество уровней или зон зависит от ваших требований.
Единственно правильного ответа не существует. Все сводится к выбору
подходящих для ваших целей компромиссов.
Чтобы облегчить размерное моделирование таким образом, Кимбалл ввел концепцию согласованных измерений (conformed dimensions). Это ключевые измерения,

  

Краткая история архитектуры хранилищ данных

37

которые становятся общими и используются разными группами пользователей.
Кроме того, Кимбалл вводит метод историзации данных с использованием SCD
(Slowly Changing Dimensions, медленно меняющиеся измерения).
SCD представляют собой таблицы, в которых медленно и планомерно сохраняются все исторические изменения. Другими словами, SCD — разновидность
измерения с атрибутами, отражающими изменение во времени. SCD1, SCD2
и SCD3 — самые распространенные методы для работы с такими изменениями:
SCD1 (https://oreil.ly/yjJ8c)
В этой разновидности, также называемой перезаписью (overwrite), существующие записи в хранилище данных просто обновляются свежей информацией.
Этот метод хорошо подходит для сценариев, когда исторические данные не
важны и значение имеют только самые актуальные данные. При этом SCD
типа 1 не позволяет отслеживать исторические изменения, так как старые
данные перезаписываются новыми.
SCD2 (https://oreil.ly/XfL43)
В этой разновидности, также называемой «добавлением новой строки», в хранилище данных создается новая запись для каждого происходящего изменения с сохранением исходной записи. Этот метод полезен, если исторические
данные важны и их необходимо хранить. Для отслеживания изменений со
временем в SCD2 создается новая запись с новым значением первичного
ключа, но исходная запись при этом сохраняется с отдельным значением первичного ключа. Так хранилище данных может поддерживать полную историю
изменений во времени.
SCD3 (https://oreil.ly/3IFm9)
В этой разновидности, также называемой добавлением нового атрибута, в существующую запись в хранилище данных добавляется новый атрибут для
отслеживания изменений. Этот метод хорошо подходит, если требуется отслеживать изменение во времени только для небольшого количества атрибутов.
Однако у SCD3 есть ограничения — прежде всего то, что этот метод позволяет
отслеживать лишь ограниченный объем исторических данных (обычно только
одно предыдущее состояние).
В эпоху современных архитектур данных моделирование данных (включая методологии Инмона и Кимбалла) продолжает играть важнейшую роль в управлении
данными и эффективном использовании их потенциала. Оно помогает понять
и грамотно применять сложные данные за счет разделения обязанностей загрузки,
интеграции/гармонизации и потребления. Создание надежных представлений
данных и их взаимоотношений упрощает использование данных техническими
и нетехническими стейкхолдерами. Кроме того, моделирование данных способствует повышению производительности и оптимизации запросов. С хорошо
структурированной моделью проще найти и получить конкретные данные, а это

  

38

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

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

Традиционные хранилища данных: ключевые выводы
На этом наше обсуждение традиционных хранилищ данных подходит к концу.
Мы рассмотрели методологии Инмона и Кимбалла, которые остаются актуальными до сих пор. Ниже приведены основные выводы касательно традиционных
хранилищ данных.
Во-первых, концепция разделения данных на уровни не нова. Она доказала свою
эффективность как стратегию разделения обязанностей, способствующую более
эффективной организации данных и управлению ими.
Во-вторых, моделирование данных чрезвычайно важно. Оно играет значительную
роль в обеспечении гибкости, сокращении избыточности данных и повышении
производительности, а также служит интерфейсом для бизнеса. Правильная организация моделирования данных — важнейшая составляющая эффективности
любой системы управления данными.
Наконец, традиционные хранилища данных обеспечивают тесную интеграцию
между программной и аппаратной частями. В таких системах, обычно размещаемых локально, вычислительные ресурсы интегрируются с пространством
хранения, в результате чего работа с данными проходит быстро и эффективно.
В эти системы входят сложные программы, повышающие до максимума производительность оборудования, на котором они выполняются. Эти системы могут
вертикально масштабироваться за счет дополнительной физической инфраструктуры. Несмотря на потенциальную дороговизну и ограничения, они когда-то были
предпочтительным вариантом для многих организаций и продолжают приносить
пользу в специализированных сценариях.
Хранилища данных обладают огромной ценностью для бизнеса, поскольку
предоставляют качественные стандартизированные данные, необходимые для
принятия обоснованных решений. Залогом их эффективности становится экспертное моделирование данных и тесная интеграция оборудования и хранилища, обеспечивающая быструю выборку данных. Все это делает их важнейшим
инструментом бизнес-операций.
Тем не менее традиционные архитектуры хранилищ данных, использующие реляционные системы управления БД (РСУБД), сталкиваются с затруднениями при
обработке быстро растущих объемов данных. У них появляются проблемы с объемом хранилища и масштабируемостью, которые могут приводить к значительным
затратам. Главная проблема заключается в том, что вертикальное масштабирование (наращивание мощности отдельной машины) имеет свои пределы и может

  

Краткая история озер данных

39

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

Краткая история озер данных
Концепция озер данных (data lakes) появилась как решение, исправляющее
недостатки традиционных хранилищ данных. Озера данных стали набирать популярность в середине 2000-х, одновременно с расцветом программных проектов
с открытым исходным кодом. В отличие от своих предшественников, озера данных
ввели новую распределенную архитектуру, способную управлять огромными
объемами данных в разных состояниях: неструктурированном, полуструктурированном и структурированном. Такая гибкость расширила возможности практического использования данных.
Озера данных используют ПО с открытым исходным кодом и, как следствие,
могут работать на любом стандартном или бюджетном оборудовании потребительского класса. Этот отход от проприетарных РСУБД ознаменовал
значительные изменения в отношении построения решений Big Data и отказ
от дорогостоящих аппаратных кластеров. Кроме того, интеграция технологий
машинного обучения в озера данных наделяет их возможностями, выходящими
за рамки традиционного составления отчетов в хранилищах данных. Чтобы
получить наглядное представление о структуре озер данных, взгляните на диаграмму на рис. 1.6.
Первое поколение озер данных в основном строилось на базе Hadoop — известного фреймворка с открытым исходным кодом, включающего различные инструменты и сервисы. В основе Hadoop лежит программный фреймворк MapReduce
и файловая система HDFS (Hadoop Distributed File System)1, предоставляющая
возможность обработки больших датасетов с использованием распределенных
алгоритмов в кластере. Кроме того, Hadoop включает ряд других средств, расширяющих его возможности хранения, обработки и анализа огромных объемов
данных.

1

Первоисточником Hadoop стала статья Санджая Гемавата (Sanjay Ghemawat), Говарда
Гобьофа (Howard Gobioff) и Шун-Так Люна (Shun-Tak Leung) The Google File System
(https://oreil.ly/rLCCa), опубликованная в 2003 году. За ней последовала вторая влиятельная статья MapReduce: Simplified Data Processing on Large Clusters (https://oreil.ly/lqVkL)
Джеффри Дина (Jeffrey Dean) и Санджая Гемавата.

  

40

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

Кластер Hadoop
Таблицы HDFS/HIVE
MapReduce/Spark

Источники
OLTPсистемы
OLTPсистемы
OLTPсистемы

Операционный
репозиторий
данных

Рабочие нагрузки
аналитики данных
Хранилище
данных

Рис. 1.6. Типичная архитектура озер данных с сырыми копиями данных
К их числу принадлежит ключевой компонент, заслуживающий особого упоминания, — Apache Hive1. Эта технология хранилища данных, разработанная на базе
Hadoop, предоставляет SQL-подобный интерфейс для обращения с запросами
и анализа больших датасетов, хранящихся в HDFS. Одна из сильных сторон
Hadoop в контексте озер данных — гибкость в отношении форматов данных.
В отличие от традиционных баз данных, требующих заранее определенной схемы,
Hadoop с Hive поддерживает метод определения схемы при чтении (schema-onread). Этот метод позволяет принимать и хранить данные без фиксированной
структуры и определять схему только при чтении данных. Такая гибкость чрезвычайно полезна для обработки разных типов данных. Hive более подробно рассматривается в разделе «Apache Hive», с. 42.
Понимание Hadoop абсолютно необходимо для работы с современными архитектурами данных, поскольку многие компоненты Hadoop (или, по крайней
мере концепции) продолжают существовать и в наши дни. В следующих разделах будут рассмотрены самые актуальные из этих компонентов. Мы начнем
с HDFS, перейдем к MapReduce, а затем к Hive. Также мы обсудим ограничения
использования HDFS и MapReduce. В завершение поговорим о технологии
Apache Spark, которая является краеугольным камнем многих современных
архитектур озер-хранилищ.

1

Проект Apache Hive был разработан в Facebook на основании идей, представленных
в исследовании Ашиша Тусу (Ashish Thusoo) и др. Hive: A Warehousing Solution Over a
MapReduce Framework (https://oreil.ly/VUqMc).

  

Краткая история озер данных

41

HDFS
Распределенная файловая система Hadoop (HDFS) известна своей отказоустойчивостью и способностью к хранению больших датасетов. Важно заметить, что
HDFS масштабируется горизонтально1 (в отличие от вертикального масштабирования, необходимого для РСУБД); таким образом решаются проблемы нагрузки
и отделения вычислений от хранения.
HDFS работает иначе, чем управление данными РСУБД в хранилищах данных.
HDFS делит данные на большие части (блоки), которые затем распределяются
и реплицируются по узлам в компьютерной сети. Размер каждого блока обычно
составляет 128 или 256 Мбайт, а коэффициент репликации по умолчанию равен 3.
Соответственно, чтение и запись данных (операции ввода/вывода, I/O) в HDFS
могут занимать относительно много времени, особенно если данные не были правильно соотнесены и распределены по узлам. Обработка данных в этих файлах
тоже может создавать проблемы; большое количество маленьких файлов может
привести к появлению множества задач обработки, создающих значительные
накладные расходы. Так как технология Hadoop оптимизирована для больших
файлов, логическая группировка данных повышает эффективность хранения
и обработки. Стало быть, да, с Hadoop рекомендуется использовать (денормализованные) модели данных. Процесс распределения данных в Hadoop невероятно
мощный, но без должного управления он может стать крайне неэффективным.
В HDFS блоки неизменяемы; это означает, что записи можно только вставлять
и присоединять, но не обновлять данные напрямую. Это отличается от обработки
отдельных изменений в системах хранилищ данных. Системы Hadoop сохраняют
все изменения данных в неизменяемом журнале с упреждающей записью (WAL),
прежде чем асинхронный процесс обновит данные в файлах. Как это повлияет на
исторические данные в наших моделях данных? Вспомните концепцию SCD (медленно меняющихся измерений) из методологии Кимбалла. SCD могут сохранять
историю изменений в атрибутах, позволяя запрашивать данные в конкретный
момент времени. Если вам захочется добиться этого в Hadoop, придется разработать обходное решение, которое физически (вос-)создает новую версию таблицы
измерений вместе со всеми историческими изменениями. Для этого можно загрузить все данные и создать новую таблицу с обновленными данными. Такой
процесс требует больших затрат ресурсов и может быть сложным в управлении.
Следовательно, при использовании Hadoop для рабочих нагрузок традиционных
хранилищ данных необходимо учитывать возможные последствия.

1

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

  

42

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

Теерь перейдем от управления данными в HDFS к их обработке. Пришло время
поговорить о MapReduce.

MapReduce
MapReduce — модель программирования, которая была разработана для параллельной обработки данных в распределенном компьютерном кластере. В течение
многих лет она служила основным механизмом обработки больших данных
в Hadoop. При обработке заданий MapReduce использует три фазы — отображение, перестановку и свертку.
Фаза отображения (Map)
В фазе отображения входные данные делятся на меньшие блоки, которые затем
обрабатываются параллельно на узлах кластера. Однако если данные неравномерно распределены между узлами, некоторые узлы могут завершить свою
задачу быстрее других, что приведет к снижению общей производительности.
Фаза перестановки (Shuffle)
В фазе перестановки выполняется сортировка и партиционирование выходных
данных из фазы отображения, прежде чем они будут переданы на свертку. Если
выходные данные имеют большой объем и должны передаваться по сети, эта
фаза может занимать много времени.
Фаза свертки (Reduce)
В фазе свертки данные, прошедшие перестановку, агрегируются и проходят
дальнейшую параллельную обработку в узлах кластера. По аналогии с фазой
отображения, если задачи свертки неравномерно распределены между узлами,
некоторые узлы могут завершить обработку быстрее других, что приведет
к снижению общей производительности.
В процессе отображения, перестановки и свертки могут возникнуть проблемы
с производительностью в Hadoop, если данные неравномерно распределены
между узлами. Так как данные должны передаваться по сети, очень важно, чтобы задачи выполнялись эффективно. Хотя методология MapReduce не всегда
используется напрямую на современных платформах, ее концепции и подход
к обработке Big Data составляют основу многих современных архитектур данных.
Теперь рассмотрим технологию Apache Hive, которая изначально основывалась
на MapReduce.

Apache Hive
Проект Apache Hive (https://hive.apache.org) был разработан в Facebook. Он обес­
печивает прослойку SQL над Hadoop, которая предоставляет пользователям возможность отправки запросов и анализа больших датасетов, хранящихся в Hadoop,
на SQL-подобном языке, известном как HiveQL. Hive использует MapReduce как

  

Краткая история озер данных

43

нижележащее исполнительное ядро для обработки запросов и анализа данных1.
Свои данные Hive хранит в HDFS. Для запросов данных Hive преобразует запросы HiveQL в задания MapReduce, которые затем выполняются в кластере
Hadoop. Эти задания читают данные из HDFS, обрабатывают их и записывают
вывод обратно в HDFS; этот процесс требует большого количества операций
дискового ввода/вывода и передачи данных по сети.
Порядок хранения данных и запросов в Hive значительно отличается от такового
в традиционных хранилищах данных. В последних данные хранятся в проприетарном формате, а запросы выполняются непосредственно с данными. Hive же
хранит данные в HDFS и выполняет запросы в виде заданий MapReduce. Кроме
того, файлы в Hive используют открытые форматы, доступные по лицензии
с открытым исходным кодом. Чтобы лучше понять, как в Hive организовано
хранение и управление данными, рассмотрим принцип внешних и внутренних
таблиц, а затем Hive Metastore.

Внешние и внутренние таблицы
В Apache Hive существует ключевое различие между внешними и внутренними
таблицами. Внешние таблицы связываются с данными, хранящимися за пределами Hive (обычно в файлах CSV или Parquet в HDFS). Hive не контролирует
эти данные, а только предоставляет прямой доступ на уровне файлов, позволяя
анализировать эти файлы. Например, CSV-файл (со значениями, разделенными
запятыми) можно смонтировать как внешнюю таблицу и обращаться к ней с запросами напрямую.
Когда вы удаляете в Hive внешнюю таблицу, то удаляются только метаданные,
а сами данные остаются. Однако удаление внутренней таблицы приводит
к удалению как метаданных, так и содержащихся в ней данных.

А внутренние таблицы (также называемые управляемыми таблицами) находятся
под полным контролем Hive. Эти таблицы часто используют колоночные форматы хранения, такие как ORC (Optimized Row Columnar) и Parquet, доминирующие
во многих современных архитектурах медальона. Эти форматы особенно полезны
для аналитических запросов, включающих агрегирование, фильтрацию и сортировку больших датасетов. Они улучшают производительность и эффективность
за счет радикального сокращения операций ввода/вывода и объема данных,
загружаемых в память. Кроме того, колоночные форматы обеспечивают более
эффективное сжатие данных, что экономит пространство хранилища и сокращает
затраты на управление большими объемами данных.

1

Современный Hive обычно использует Apache Tez как основной движок, а в некоторых
случаях его запускают поверх Apache Spark. Подход с MapReduce устарел. — Примеч.
науч. ред.

  

44

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

Hive Metastore
Ключевым компонентом Hive является Hive Metastore — централизованный
репозиторий, в котором хранятся метаданные о таблицах, столбцах и разделах
в кластере HDFS. Эти метаданные включают схему данных, местонахождение
данных в HDFS и другую информацию, необходимую для запросов и обработки
данных. Этот компонент до сих пор присутствует во многих архитектурах ме­
дальона.
Hive при помощи своего репозитория метаданных позволяет принимать данные
без жесткого требования о предварительном определении схемы. Схема применяется динамически при обращении к данным для чтения. Этот метод также
известен как схема при чтении (schema-on-read). Такая гибкость разительно
контрастирует с методологией схемы при записи (schema-on-write), доминирующей в традиционных базах данных, когда в момент записи данные должны
соответствовать заранее определенной схеме.
Подход schema-on-read, до сих пор встречающийся в современных архитектурах данных, часто приводит к недоразумениям. Некоторые инженеры ошибочно полагают, что схема при чтении отменяет необходимость в моделировании данных. Это совсем не так! Без соответствующего моделирования
данные будут неполными или некачественными, и интегрировать данные из
нескольких источников будет сложнее. Плохое моделирование данных также
может сказаться на производительности. Хотя подход schema-on-read полезен
для быстрого сохранения и выявления сырых данных, вам все равно придется позаботиться о качестве данных, их интеграции, а также о производительности.

Технология Hive со своими метаданными, HDFS и MapReduce, изначально
столкнулась с проблемами. Первая из этих проблем связана с неэффективной
обработкой множества мелких файлов. В HDFS данные распределяются по
нескольким машинам и реплицируются для повышения эффективности параллельной обработки. Каждый файл независимо от размера по умолчанию занимает
в памяти минимальный блок, поскольку данные и метаданные хранятся отдельно. Мелкие файлы, размер которых не превышает размер одного блока HDFS
(обычно 127 Мбайт), могут создать избыточную нагрузку на узел NameNode1.
Например, если вы работаете с блоками по 128 Мбайт, то для 8000 файлов потребуется 1 Тбайт данных и еще 1,6 Мбайт для метаданных. Но если бы этот
1 Тбайт хранился в файлах размером 1 Кбайт, для метаданных потребовалось бы
200 Гбайт, то есть нагрузка на систему возросла бы в 1280 раз. Если эту проблему
не решить, скорость чтения во всем озере данных катастрофически снизится.

1

NameNode в Hadoop отвечает за управление пространством имен файловой системы,
хранение метаданных всех файлов и каталогов, а также регулировку доступа к файлам
со стороны клиентов. Он также управляет отображением файловых блоков на узлы
DataNode, обеспечивая надежность и доступность данных.

  

Краткая история озер данных

45

Во-вторых, первая версия Hive не поддерживала транзакции ACID и полнотаб­
личные обновления, а это создавало риск того, что база данных окажется в рассогласованном состоянии. К счастью, проблема была решена в более поздних
версиях. В разделе «Появление открытых табличных форматов» на с. 49 мы
вернемся к этому факту при рассмотрении формата Delta.
В-третьих, MapReduce может работать достаточно медленно. На каждом этапе
обработки данные читаются и записываются обратно на диск. Процесс поиска по
диску занимает много времени и значительно замедляет операцию в целом. Так
мы приходим к технологии Apache Spark1, которая пытается решить указанную
проблему с производительностью.

Проект Spark
Несмотря на все преимущества, методология MapReduce не всегда работает
эффективно, особенно в крупномасштабных приложениях. Например, типичный алгоритм машинного обучения может потребовать нескольких проходов
по одному датасету, и каждый проход должен быть записан в виде уникального
задания MapReduce. Эти задания должны запускаться в кластере по отдельности,
и данные каждый раз будут загружаться заново.
Для решения этих проблем исследователи из Калифорнийского университета
Беркли, в основном из лаборатории AMPLab (https://amplab.cs.berkeley.edu),
в 2009 году запустили исследовательский проект для изучения способов ускорения обработки заданий в системах на базе Hadoop. Они разработали фреймворк
вычислений в памяти, который получил название Spark. Этот фреймворк был
спроектирован для повышения эффективности крупномасштабной обработки данных за счет хранения данных в памяти (вместо чтения их с диска для
каждой операции). Команда также разработала Shark2 — расширение Spark,
предназначенное для обработки запросов SQL и открывшее дополнительные
возможности для интерактивного использования специалистами по data science
и аналитиками. Архитектура Shark базировалась на Hive. Система преобразовывала физический план, сгенерированный Hive, в программу, выполняемую
в памяти; это позволяло выполнять запросы SQL намного быстрее (до 100 раз),
чем в Hive с MapReduce.
По мере развития Spark стало очевидно, что включение новых библиотек может
значительно расширить возможности фреймворка. Так в проект стал внедряться

1

2

Современные исполнительные среды Spark обладают функциональностью, способной
решить проблему малых файлов. Майлз Коул (Miles Cole) опубликовал руководство
по оптимизации для Microsoft Fabric (https://oreil.ly/AmdYE), в котором содержится
информация по этой теме.
См. исследование AMPLab из Калифорнийского университета Беркли, посвященное
Apache Shark (https://oreil.ly/JUlEw).

  

46

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

механизм «стандартных библиотек»1. В это время команда начала постепенно отказываться от Shark в пользу Spark SQL — нового компонента, обеспечивавшего
совместимость с Hive за счет использования Hive Metastore.
Однако выигрыш по скорости при использовании Spark достигался только при
соблюдении определенных предварительных условий. Например, Spark читает
данные с диска, чтобы загрузить их в память, а это происходит не мгновенно.
Таким образом, после записи данных в HDFS требуется дополнительный процесс загрузки для чтения данных с диска и их перемещения в память Spark. Этот
принцип соблюдается и сейчас. Например, при перезапуске кластера Spark все
данные в памяти теряются и их приходится загружать заново для восстановления
выигрыша по скорости. Для построения современных архитектур это означает,
что ресурсы становятся доступными лишь по истечении некоторого времени запуска2, и в этот период данных еще нет в Spark. Они становятся доступными для
быстрого использования только после запуска процессов выполнения запросов
и/или кэширования.
Сделаем небольшую паузу в обсуждении Spark и перейдем к выводам, которые
следуют из истории озер данных и их эволюции. Мы еще вернемся к Spark, когда
будем говорить об архитектуре озер-хранилищ данных в следующем разделе.

Озера данных: ключевые выводы
Итак, что же мы узнали из описания озер данных и их эволюции?
Озера данных, работающие на базе Hadoop, — надежные решения для хранения
огромных объемов сырых данных в разных форматах, как структурированных,
так и неструктурированных. Эти данные готовы для обработки в приложениях
анализа данных и машинного обучения, и они поддерживают форматы, с которыми не справятся традиционные хранилища данных. В отличие от последних,
озера данных не ограничиваются конкретными форматами. Они ориентируются
на форматы с открытым исходным кодом, например Parquet, поддерживаемый
многими инструментами, драйверами и библиотеками, что обеспечивает бесшовную совместимость. Более того, многие базовые концепции (например, внешние
и управляемые таблицы) продолжают существовать в современных архитектурах
данных.
Тем не менее с ростом популярности и расширением сфер применения озер данных организации начали сталкиваться с проблемами. Хотя загрузка сырых данных
1

2

См. пост Рейнольда Шина (Reynold Xin) за 2014 год Shark, Spark SQL, Hive on Spark,
and the Future of SQL on Apache Spark (https://oreil.ly/13nUf).
В современных архитектурах озер-хранилищ данных время холодного запуска для запросов или обработки данных может быть значительно сокращено за счет использования
вспомогательных файлов (https://oreil.ly/4mYIQ). Такие файлы содержат метаданные
(информацию, схемы, статистику, данные индексирования и т. д.), что повышает эффективность управления данными и выполнения запросов.

  

Краткая история архитектуры озер-хранилищ данных

47

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

Краткая история архитектуры озер-хранилищ данных
После знакомства с историей хранилищ данных и озер данных мы приходим
к последней части обсуждения эволюции архитектур данных. Начнем с современных архитектур, использующих озера-хранилища (lakehouse) как основу для
форматов таблиц данных с открытым исходным кодом, таких как Delta Lake. Для
этого рассмотрим эволюцию Spark, а затем обсудим происхождение технологии
Databricks, ее роли в пространстве данных и отношения с другими поставщиками
технологий. В завершение поговорим об архитектуре медальона.

Основатели Spark
К 2013 году проект Spark, в котором участвовали более 100 специалистов из
30 организаций, набрал значительную популярность. Чтобы обеспечить его
долгосрочную жизнеспособность и независимость от разработчиков технологий, команда решила передать Spark как проект с открытым исходным кодом
в фонд Apache Software Foundation (https://apache.org). Соответственно, проект
Spark был переименован в Apache Spark и вошел в число проектов верхнего
уровня Apache.
В 2013 году создатели Spark основали компанию Databricks (https://databricks.com)
для поддержки и монетизации стремительного роста Spark. Компания Databricks
занимается упрощением обработки больших данных, чтобы они были более доступными для дата-инженеров, теоретиков data science и бизнес-аналитиков.

  

48

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

После этого сообщество Apache Spark (https://spark.apache.org) выпустило несколько версий: Spark 1.0 в 2014 году, Spark 2.0 в 2016, Spark 3.0 в 2020 и Spark 4.0
в 2025. Работа над совершенствованием Spark продолжается, и в фреймворк
регулярно добавляются новые возможности.
Интересно, что компания Databricks избрала маркетинговую стратегию, отличную
от стратегии ее конкурентов из Hadoop. Вместо того чтобы сосредоточиться на
локальном развертывании (как Cloudera и Hortonworks), в Databricks выбрали
исключительно облачное распространение Databricks Cloud. В то время даже
существовала бесплатная версия Community Edition. Компания Databricks начала
с Amazon Web Services, самого популярного облачного сервиса на тот момент,
а позднее добавила поддержку Microsoft Azure и Google Cloud Platform. В ноябре
2017 года Databricks стал полноценным сервисом на платформе Microsoft Azure
путем интеграции Azure Databricks. Темпы перехода на облачные технологии повышались, и решения на облачной основе с разделением хранения и вычислений
приобрели популярность, а традиционные локальные развертывания Hadoop
стали уходить в прошлое. Сегодня можно уверенно сказать, что в Databricks
сделали умный стратегический ход.
Что это означает для Hadoop? Устарела ли эта технология? Нет, она все еще
живет в облачной экосистеме, хотя и претерпела значительные изменения. Разработчики заменили HDFS облачными сервисами объектных хранилищ. В объектном хранилище блоки данных файла хранятся совместно как объект вместе
с необходимыми метаданными и уникальным идентификатором. В этом отношении оно отличается от HDFS, где данные хранятся в блоках на разных узлах,
а местонахождение этих блоков отслеживается отдельным сервисом метаданных
(таким, как NameNode в HDFS).
Переход на облачное объектное хранилище предоставляет ряд преимуществ.
Он не только в общем случае требует меньших затрат для хранения больших
объемов данных, но и более эффективно масштабируется даже до петабайт. Все
основные облачные провайдеры предоставляют такие сервисы, дополненные
надежными соглашениями об уровне обслуживания (Service-Level Agreement,
SLA) и вариантами географической репликации. Например, компания Microsoft
представила Azure Data Lake Storage (https://oreil.ly/uZmTa) — объектное хранилище, обеспечивающее совместимость с интерфейсом HDFS при модернизации
нижележащей архитектуры хранилища. В итоге интерфейс HDFS остается, а нижележащая архитектура хранилища капитально перерабатывается.
Точно так же эволюционировала и технология Spark. Она получила значительные вложения, прежде всего от Databricks, и сейчас может работать независимо в кластере виртуальных машин или внутри контейнеров под управлением Kubernetes. Такая гибкость означает отсутствие привязки к одному
большому кластеру Hadoop. Вместо этого можно создать несколько кластеров
Spark, каждый из которых имеет свою конфигурацию и размер. В зависимости
от конкретных потребностей эти кластеры могут взаимодействовать с одним

  

Краткая история архитектуры озер-хранилищ данных

49

уровнем объектного хранилища, что обеспечивает эластичность и динамичность Spark.
Технология Databricks является движущей силой планирования и развития
Apache Spark. Она предоставляет управляемую платформу, на которой пользователям доступны все преимущества Spark без необходимости изучать сложные
концепции управления кластерами или решать бесконечные инженерные задачи. Вместо этого пользователи работают с удобным интерфейсом. Крроме того,
компаниям, работающим с Databricks, раньше всех становятся доступны все
нововведения Spark.
А теперь немного изменим направление и обратим внимание на современные
архитектуры, которые претерпели значительные изменения благодаря разработке
стандартных табличных форматов с открытым исходным кодом, таких как Hudi,
Iceberg и Delta Lake.

Появление открытых табличных форматов
Исследователи сознавали критическую необходимость улучшенных гарантий
транзакций, расширенной обработки метаданных и усиленной целостности
данных в колоночных форматах хранения. В разработку были запущены проекты, которые позднее перешли на модель с открытым исходным кодом. Проект
Apache Hudi (https://hudi.apache.org) компании Uber появился одним из первых
в 2017 году. Он создавался для упрощения управления большими датасетами
в Hadoop-совместимых файловых системах, с основным вниманием к эффективности обновления/вставки, удаления и поэтапной обработки. Этот проект
запустил инновации в обработке больших данных. Кроме того, Hudi предлагает
бесшовную интеграцию с существующими решениями хранения данных и поддерживает такие популярные колоночные форматы, как Parquet и ORC.
Вскоре после того Netflix запустила проект Apache Iceberg (https://iceberg.apache.
org) для решения проблем с производительностью и сложностью в крупномасштабных аналитических системах данных. В Iceberg появился табличный формат,
который повышал скорость медленных операций и надежность процессов, расширяя возможности обработки данных. Проект обрел популярность благодаря
широкому набору возможностей и поддержке файловых форматов Parquet, ORC
и Avro.
В 2019 году компания Databricks запустила проект Delta Lake (https://oreil.ly/
Vg07Q), продолжающий устранять недостатки традиционных озер данных, таких
как отсутствие транзакционных гарантий и проблемы с целостностью данных.
В Delta Lake появились ACID-транзакции, масштабируемая обработка метаданных и унифицированная обработка потоковых и пакетных данных наряду
с обеспечением целостности данных за счет проверки соответствия и эволюции
схем. Для хранения данных Delta Lake использует исключительно формат файлов Parquet, а для сжатия данных по умолчанию используется алгоритм Snappy.

  

50

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

Apache Hudi, Apache Iceberg и Delta Lake
В 2024 году компания Databricks приняла стратегическое решение о приобретении Tabular — компании, поддерживающей инициативу Apache
Iceberg, одного из ведущих табличных форматов озер-хранилищ с открытым кодом. Основной целью этого приобретения было обеспечить
совместимость между разными платформами озер-хранилищ. Чтобы
сделать это быстро, в Delta Lake была добавлена технология UniForm
(https://oreil.ly/0dvyM), позволяющая записывать данные в Delta Lake,
а затем асинхронно генерировать метаданные для Apache Iceberg или
Hudi. В долгосрочной перспективе Databricks направляет усилия на
разработку единого открытого общепринятого стандарта совместимости
между платформами, обещающего более связный и эффективный подход
к управлению данными. Помимо этой разработки существует и другая
инициатива — Apache XTable. Ее создателями были основатели Apache
Hudi. Apache XTable обеспечивает полноценное однонаправленное преобразование между тремя форматами (Delta, Hudi и Iceberg).
Delta Lake предоставляет поддержку ACID-транзакций через журнал транзакций
(также называемый DeltaLog). Каждый раз, когда пользователь выполняет операцию для изменения таблицы (например, вставку, обновление или удаление), Delta
Lake разбивает эту операцию на серию дискретных шагов, состоящих из одного
или нескольких из перечисленных ниже действий. Эти действия записываются
в журнал транзакций в виде упорядоченных атомарных единиц, называемых
коммитами (commits). Журнал транзакций автоматически сохраняется в подкаталоге _delta_log/ среди файлов Parquet конкретной таблицы. На рис. 1.7 приведен
пример содержимого DeltaLog.
В Delta Lake каждый коммит записывается в файл в формате JSON, начиная
с 000000.json и с последовательным увеличением номеров. При обновлении таб­лиц
Delta Lake сохраняет все предыдущие версии1. Эта функция, называемая перемещением во времени (time travel), позволяет просмотреть состояние таблицы
на любой конкретный момент времени. Например, можно легко проверить, как
выглядела таблица до обновления, или просмотреть ее состояние в интересующий
момент. Если вы хотите узнать больше, рекомендую статью Diving Into Delta Lake:
Unpacking the Transaction Log (https://oreil.ly/aDOQt).
1

Каждая предыдущая версия сохраняется в Delta Lake. Тем не менее при выполнении
обновлений/вставок или удалений более старые версии остаются до тех пор, пока не
активируется процесс очистки (vacuum process). Однако на самом деле Delta Lake не
удаляет никакие данные сразу; удаляются только данные, ссылки на которые отсутствуют в текущем снапшоте таблицы. Интервалы очистки и удаления могут настраиваться.
Подробнее см. в главе 5 книги «Delta Lake: The Definitive Guide» (https://oreil.ly/TV-07)
(O’Reilly).

  

Краткая история архитектуры озер-хранилищ данных

51

my_table/

Журнал транзакций
Отдельные коммиты

_delta_log/
000000.json
000001.json
000002.json
0000010.json

Файлы контрольных точек
(Необязательные) каталоги разделов
Файлы данных

0000010.checkpoint.parquet
data=2019-01-01/
file-1.parquet
data=2019-01-02/
file-2.parquet

Рис. 1.7. Пример структурирования данных и журнала транзакций в Delta Lake

Расцвет архитектур озер-хранилищ данных
С дебютом Delta Lake архитектура озер-хранилищ данных начала обретать популярность. Эта инновационная модель объединяет преимущества озер данных
и хранилищ данных. Она позволяет организациям работать на унифицированной
платформе данных, основу которой составляют программные продукты с открытым исходным кодом. Хотя концепция озера-хранилища данных изначально не
связана ни с какой конкретной технологией, самые популярные реализации этой
архитектуры строятся на базе Apache Spark и Delta Lake. Таким образом, Spark
обеспечивает вычисления при обработке Big Data, а Delta Lake предоставляет
уровень хранения данных с открытым исходным кодом. На рис. 1.8 представлен
обзор структуры озера-хранилища данных.
Архитектура озер-хранилищ отличается от предыдущих архитектур поддержкой
низкозатратного облачного объектного хранилища при одновременном предоставлении ACID-транзакций. Более того, она значительно повышает производительность
по сравнению с традиционными озерами данных, прежде всего благодаря инновациям, реализованным в Apache Spark. Компания Databricks первой предложила
термин «озеро-хранилище» (lakehouse) и позиционировала себя в этом пространстве
продуктов. В дальнейшем ее примеру последовали другие крупные игроки. Ниже
приведен краткий обзор этого сегмента отрасли по состоянию на 2025 год.
Databricks
Компания Databricks, являясь приверженцем архитектуры озер-хранилищ,
интегрирует технологию Delta Lake, которая поддерживает ACID-транзакции

  

52

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

и масштабируемое управление метаданными. Этот формат таблиц идеально
сочетается с Apache Spark, расширяя возможности обработки больших данных
и аналитики за счет повышения производительности и надежности.
Azure HDInsight
Облачный сервис Microsoft — Azure HDInsight — предлагает управляемые
сервисы Apache Hadoop и Apache Spark, предоставляющие масштабируемую
и эффективную среду для обработки больших данных. Он поддерживает
разные табличные форматы и интегрируется с другими сервисами Azure для
расширенной аналитики данных.
Azure Synapse Analytics
Сервис Microsoft Azure Synapse Analytics объединяет решения больших
данных с хранилищами данных в унифицированный аналитический сервис.
Он предлагает гибкие возможности отправки запросов через бессерверные,
выделяемые по требованию или выделенные ресурсы SQL, оптимизируя
управление и анализ обширных датасетов.
Microsoft Fabric
Эта платформа аналитики и данных предоставляется по модели SaaS (Software
as a Service). Microsoft Fabric использует Apache Spark и Delta Lake наряду
с семейством других сервисов для упрощения широкого спектра операций
с данными и аналитики.

Архитектура озера-хранилища
Вычисления
Spark

Облачное объектное хранилище
Источники
OLTPсистемы
OLTPсистемы
OLTPсистемы

Операционный
репозиторий
данных

Бронзовый

Серебряный

Золотой

Рабочая
нагрузка
аналитики
данных
Рабочая
нагрузка
создания
отчетов
Совместное
использование

Рис. 1.8. Типичная архитектура озера-хранилища данных с представлением бронзового,
серебряного и золотого уровней

  

Краткая история архитектуры озер-хранилищ данных

53

Cloudera
Cloudera предоставляет надежную платформу с поддержкой разных табличных
форматов и фреймворков обработки данных. Благодаря широким возможностям интеграции для Apache Hadoop и Apache Spark Cloudera предлагает
гибкую среду, подходящую для создания разнообразных архитектур озерхранилищ данных.
Dremio
Используя Apache Arrow (https://arrow.apache.org), Dremio расширяет возможности операций с данными в памяти на разных языках. Эта платформа отлично
проявляет себя в эффективной выборке и обработке данных, вследствие чего
она идеально подходит для прямых исследований и анализа озер данных.
Starburst
Starburst специализируется на Trino (https://trino.io), движке распределенных
запросов SQL с открытым исходным кодом, предоставляет быструю и масштабируемую аналитику данных из различных источников. Технология поддерживает
широкий спектр табличных форматов и бесшовно интегрируется с другими
технологиями озер-хранилищ данных, повышая производительность запросов.
Кроме уже упомянутых разработчиков, другие крупные игроки (такие, как
Amazon Web Services, Google Cloud Platform и Snowflake) также начали встраивать
термин «озеро-хранилище» в свои предложения. Эта тенденция подчеркивает
растущее признание и принятие архитектуры озер-хранилищ в отрасли управления данными. Техногиганты признают ценность объединения лучших качеств
озер данных и хранилищ данных для создания комплексных и эффективных
решений в области данных. По мере того как все больше организаций стремится
оптимизировать обработку данных и аналитику, модель озер-хранилищ данных
продолжает набирать обороты как наиболее предпочтительная архитектура,
формируя будущее управления данными.
Наконец, Databricks и Microsoft провозгласили архитектуру медальона лучшей
практикой иерархического размещения данных в архитектурах на базе Spark
и Delta Lake. Эта архитектура также станет центральной темой нашей книги.
Этот паттерн организует данные в озере-хранилище по уровням — от бронзового
к серебряному и золотому, переходя по которым структура и качество данных последовательно улучшаются. В следующем разделе будут подробнее рассмотрены
некоторые сложности практической реализации архитектуры медальона. Эта
тема завершит главу, и мы перейдем к описанию основ архитектуры медальона
в главе 2 и паттернам проектирования в главе 3.

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

  

54

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

данных, предлагающий логичный и структурированный подход к организации
данных в озере-хранилище. Название «медальон» обусловлено наличием трех уровней: бронзового (Bronze), серебряного (Silver) и золотого (Gold), которые служат
удобными для пользователя обозначениями для управления данными по аналогии
с уровнями данных в хранилищах или озерах данных. Переход от Bronze к Gold
означает улучшение не только качества данных, но и их структуры и проверки.
Несмотря на интуитивно понятный смысл названий уровней в архитектуре медальона: бронзовый для сырых, серебряный для очищенных и золотой для данных,
готовых к потреблению, — эти названия не содержат в себе никаких практических
рекомендаций. И отсюда следует более общая проблема: не существует единого
мнения относительно конкретных ролей каждого уровня, а в самих терминах
отсутствует описательная точность. Так как мы сделали вывод о важности моделирования данных, вполне очевидно, что хотя именование представляет собой
отправную точку, истинные сложности кроются в практическом применении этой
архитектуры и различиях между теоретическими рекомендациями и фактической
реализацией. Это и есть основная тема книги.
В главе 2 мы рассмотрим некоторые фундаментальные концепции, которые помогут вам ориентироваться в архитектуре медальона, включая посадочные зоны,
сырые данные, пакетную обработку, ETL и средства оркестрации. Затем в главе 3
мы глубже погрузимся в архитектуру медальона и обсудим каждый уровень более
подробно. Это поможет лучше понять, как данные проходят через уровни и что необходимо учитывать, чтобы эффективно применять эту архитектуру на практике.

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

  

Заключение

55

Другое важное направление развития — скорость поставки новых проектов и аналитики, ожидаемая бизнес-пользователями. Этот фактор затрудняет поставку
современных архитектур данных, так как команды разработки находятся под
постоянным давлением: от них требуют быстрого формирования бизнес-рекомендаций. Многие организации не осознают незаменимости моделирования данных.
Архитектуры сетки данных (data mesh) часто упускают из виду эту необходимость1, что приводит к повторяющейся проблеме: распределенные команды раз
за разом создают слегка различающиеся несовместимые модели. Эти вариации
уходят корнями к аналитическим моделям, пайплайнам ETL, продуктам данных
и кодам приложений; в результате то, что некогда было понятным и ясно выраженным дизайном, превращается в нечто туманное и недоступное непосвященным.
Архитектура медальона распознает такие проблемы, но не может предложить
однозначное решение. Практическое применение этого паттерна проектирования
выявляет разрыв между теоретическими моделями и их реализациями и реальными примерами. Такое расхождение подчеркивает постоянную необходимость
точного моделирования данных и стратегий управления данными, адаптированных под конкретные потребности организаций.
Крайне важно, чтобы инженеры и архитекторы данных продолжали исследовать
эти модели, понимая их тонкости, и осмысленно применяли их для удовлетворения растущих потребностей сред больших данных. В главе 2 приводится подробный обзор фундаментальных предварительных условий, необходимых для
построения современных архитектур данных. Закладывая надежный фундамент,
мы готовимся к более сложному материалу главы 3; в ней архитектура медальона
рассматривается более глубоко, с более подробными описаниями всех уровней.

1

Сетка данных (https://oreil.ly/ZVipF) — децентрализованный подход к архитектуре данных и организационному проектированию. В его рамках данные рассматриваются как
продукт, при этом на первый план выходят такие концепции, как владение данными,
основанное на предметной области, самообслуживаемая инфраструктура данных и вычислительное управление.

ГЛАВА 2

Закладка фундамента
Прежде чем строить дом, необходимо заложить надежный фундамент. Это же
правило справедливо для архитектуры медальона. В этой главе будут представлены ключевые компоненты и паттерны, часто используемые при обсуждении
архитектур медальона. Она также подготовит читателя к главе 3, в которой будет
подробно рассматриваться архитектура медальона и ее уровни.
Мы раскроем следующие основные темы:
Дополнительные посадочные зоны
Предварительные области, в которые производится загрузка сырых данных
перед их поступлением в архитектуру медальона.
Сырые данные
Сырые данные, собранные из различных источников и используемые для
дальнейших преобразований и анализа.
Пакетная обработка
Метод обработки данных, при котором данные собираются, обрабатываются,
а затем выдаются пакетами через заранее запланированные интервалы.
Обработка данных в реальном времени
В отличие от пакетной обработки, в этом режиме1 данные обрабатываются
сразу же после того, как они становятся доступными, что делает возможным
немедленный анализ и принятие решений
ETL и средства оркестрации
Неотъемлемые компоненты извлечения, преобразования и загрузки данных,
играющие важную роль в оркестрации и автоматизации рабочих потоков
в экосистеме данных.
1

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

  

Дополнительные посадочные зоны

57

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

Фундаментальные предусловия
Для проектирования и реализации любой архитектуры требуются данные. Следовательно, начинать необходимо с определения целевых систем-источников
и лучшего способа получения из них данных. В этом контексте основные вопросы связаны с тем, нужно ли использовать промежуточные посадочные зоны для
загрузки данных (это может упростить организацию и преобразование данных
перед их интеграцией в архитектуру медальона). Затем необходимо определиться
с методами загрузки — следует ли применить пакетную обработку или обработку
в реальном времени? Это решение повлияет на выбор инструментов и методов
для интеграции данных, оркестрации и управления таблицами.
В следующих разделах мы рассмотрим эти решения в указанном выше порядке,
чтобы лучше понимать бронзовый, серебряный и золотой уровни, о которых
речь пойдет в главе 3. Начнем с потенциальной необходимости дополнительных
посадочных зон.

Дополнительные посадочные зоны
«Посадочная зона» (landing zone) часто используется как предварительная
область, в которую сырые данные извлекаются перед тем, как поступить в архитектуру медальона. На этот выбор влияют различные факторы, в том числе
характеристики источника данных.
Например, при работе с внешними сервисами или провайдерами SaaS может понадобиться безопасная посадочная зона для исходного хранения данных перед
их попаданием на бронзовый уровень. Точно так же некоторые команды приложений с жесткими требованиями к загрузке данных могут требовать выделения
собственных посадочных зон. Такие команды управляют процессом извлечения
данных, гарантируя, что в нем не будет непредвиденных ошибок или несогласованных данных. Для этого им также могут требоваться конкретные инструменты
ETL или развертывание интеграционных сред (https://oreil.ly/QIHbo). В таких
случаях между источниками и архитектурой озера-хранилища часто создается
несколько посадочных зон.

  

58

Глава 2. Закладка фундамента

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

Главное о посадочных зонах
Хотя бронзовый уровень в основном служит областью сбора данных,
в больших или особенно сложных средах вам может понадобиться дополнительная посадочная зона. Называть ли этот уровень бронзовым —
решайте сами. В некоторых организациях он может называться «предбронзовым», «областью промежуточного хранения», «посадочной зоной» и т. д.
и размещаться за пределами типичной архитектуры медальона. Другие
могут включать его в структуру бронзового уровня. Важно загружать
и хранить данные способом, который соответствует функциональным
и нефункциональным требованиям вашей организации.
Рассмотрим другие важные вопросы. Начнем с операций над сырыми данными,
а потом перейдем к методам загрузки.

Сырые данные
Когда речь заходит о сборе данных для перемещения на бронзовый уровень, использовать такие термины, как «сырые» или «в исходном виде», нужно с осторожностью. Возьмем, скажем, сложные транзакционные системы, в которых существуют пакеты с тысячами таблиц. Для работы с ними инженеру стоит сделать
шаг назад и хорошенько обдумать процесс извлечения данных.
Приведу пример из собственного опыта. Мне довелось заниматься извлечением
данных из Temenos T24 — ядра банковской системы. Эта система хранит все свои
данные в формате XML, при этом каждая таблица состоит всего из двух столбцов:
RECID для первичного ключа и XMLRECORD для данных. Прямое извлечение
этих данных привело бы к образованию очень сложного и неуправляемого датасета. Для решения проблемы мы использовали T24 Data Extractor. Эта программа извлекает данные из базы данных T24 и сохраняет их в более управляемой
структуре. На более поздней стадии мы переключились на использование Apache
Flink (https://flink.apache.org) для декодирования и обработки данных в процессе
перемещения, что позволило преобразовывать и обогащать записи XML при их
потоковой передаче из T24 в другие среды.

  

Пакетная обработка

59

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

Главное о сырых данных
Предварительная обработка сложных данных или применение посредника происходит до того, как данные поступят на первый уровень. Это
не считается преобразованием в архитектуре медальона. Следовательно,
данные на первом уровне обычно считаются «сырыми», и в сложных
системах может понадобиться их предварительная обработка, чтобы
сделать их более управляемыми и понятными.
От рассмотрения основных принципов перейдем к другому важному вопросу
управления данными — выбору между пакетной загрузкой и загрузкой в реальном
времени. Понимание различий между этими двумя режимами поможет эффективнее обрабатывать данные. Начнем с пакетной обработки, а затем перейдем
к обсуждению данных реального времени и потоковой загрузки — оно получится
более долгим, поскольку тема довольно сложная.

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

  

60

Глава 2. Закладка фундамента

Очень важно поддерживать целостность данных. Используйте такие методы
проверки, как подсчет строк, контрольные суммы или хеш-суммы для конт­
роля точности и полноты данных при передаче. Кроме того, для организации
мониторинга и диагностики отслеживайте показатели аудита, например
количество файлов, объем данных, продолжительность копирования, идентификаторы операций и результаты.
В отличие от непрерывной обработки, пакетная происходит с заданными
интервалами. Тщательно выбирайте эти интервалы с учетом доступности источников данных, последовательности обработки и срочности анализа данных.
Несмотря на все усилия, при пакетных процессах возможны сбои. Следовательно, для обеспечения гибкости бронзового уровня очень важны надежные механизмы обработки ошибок. Рассмотрите возможность создания
«уровня ошибок» или «приюта данных» (data orphanage), предназначенного
специально для мониторинга и решения таких проблем. Этот уровень станет
своего рода страхующим, перехватывающим любые проблемы, возникающие
в процессе пакетной обработки, и обеспечит гладкое и надежное управление
данными.
Для эффективного управления данными очень важно выбрать правильные
инструменты извлечения и загрузки данных. Изучите инструменты и методы, обеспечивающие бесшовную интеграцию данных и обработку. Например,
Azure Data Factory (https://oreil.ly/GBGoh) широко применяется для извлечения
данных, оркестрации рабочего процесса и управления пайплайном, предоставляя более 200 точек подключения. Оценка и выбор подходящего инструмента
может значительно повысить эффективность и надежность процессов сбора
данных. Мы вернемся к инструментам и факторам, которые необходимо учитывать, в разделе «ETL и средства оркестрации», с. 65.

Главное о пакетной обработке
Сложности при сборе данных отнюдь не новы; организации давно занимаются сбором данных для хранилищ. Соответственно, многие организации часто повторно используют существующие интерфейсы (например,
специальные скрипты извлечения данных или традиционные пакетные
поставки) для импортирования данных в озера-хранилища. И хотя пакетная обработка может показаться простой, зачастую в корпоративных
средах она довольно сложна, поскольку каждый источник имеет свои
особенности, которые приходится учитывать.
Прежде чем исследовать современные методы загрузки данных, важно признать, что сбор данных до сих пор представляет большую сложность для многих
организаций. Это объясняется спецификой систем-источников, разнообразием

  

Обработка в реальном времени

61

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

Обработка в реальном времени
Как отмечалось в главе 1, современные архитектуры озер-хранилищ эффективно
справляются с потоковыми данными или данными реального времени. Обработка
данных в момент, когда они были сгенерированы, делает возможным моментальное получение информации и своевременные действия, критически важные для
приложений, например обнаружение попыток мошенничества, персонализированные взаимодействия с клиентом и динамическую регулировку системы. Это
значительно повышает отзывчивость и эффективность приложений, делая их
мощным бизнес-инструментом в современных динамичных средах.
Для настройки загрузки данных в реальном времени обычно приходится добавлять дополнительные компоненты или корректировать существующую
конфигурацию. Дело в том, что многие приложения не генерируют события автоматически. Возможно, вам как разработчику или инженеру придется изменить
архитектуру приложения для обработки дистрибуции событий. Например, если
вы работаете в приложении Node.js (https://nodejs.org) с использованием Express
(https://expressjs.com), возможно, вам придется установить библиотеку и написать
код для отправки событий такому сервису, как Azure Event Hubs (https://oreil.ly/
F07DH).
Иногда также приходится добавлять ПО или компоненты для чтения журналов
транзакционной базы данных или совершения вызовов API. После создания стабильного потока событий платформа данных начнет сохранять и обрабатывать
эти данные с использованием таких сервисов и фреймворков, как Spark.
При перемещении данных важно отличать события, передающие состояние,
от простых уведомлений. События, передающие состояние, предоставляют
«мгновенный снимок» (снапшот) состояния приложения на конкретный
момент времени; он может использоваться для обработки, анализа или инициирования дальнейших событий. В архитектурах данных они играют важнейшую роль для мониторинга изменений данных или обновлений. С другой
стороны, уведомления представляют собой базовые сигналы, которые сообщают системам или пользователям о произошедших событиях и предлагают
немедленно выполнить какие-то действия: сообщить пользователю о поступ­
лении нового электронного письма, оповестить системного администратора
о потенциальной проблеме и т. д. Обычно они не включают подробную информацию состояния.

  

62

Глава 2. Закладка фундамента

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

Spark Structured Streaming
Надежная поддержка Structured Streaming (https://oreil.ly/PKzWU) в механизме
Apache Spark значительно улучшает обработку данных в реальном времени.
Являясь неотъемлемой частью Spark, Structured Streaming упрощает непрерывную обработку потоков данных и позволяет загружать данные из разнообразных
источников: файлов журналов событий, IoT-устройств и таких систем обмена
сообщениями, как Apache Kafka. Spark Structured Streaming также превосходно
показывает себя в обработке данных в сырой, неструктурированной форме, типичной для многих сценариев данных реального времени.
На этой стадии преобразования приобретают особую важность, так как они переводят сырые данные в более удобный формат. Для неструктурированных данных
фазы преобразования могут включать распаковку (уплощение) вложенного JSON,
извлечение полей из XML или применение сложных функций для создания новых столбцов. Эти операции играют важную роль в очистке и подготовке данных
для последующей аналитики и хранения, гарантируя возможность эффективной
обработки и анализа данных.
После преобразования данных Structured Streaming позволяет выполнять различные операции вывода. К их числу относится запись обработанных данных
в системы долгосрочного хранения для дальнейшего анализа или будущего использования. Поддерживаемые приемники зависят от требований приложения;
это могут быть Delta Lake для ACID-совместимого хранения и версионирования,
традиционные базы данных для реляционного хранения, базы данных NoSQL
для вариантов бессхемного хранения; возможен даже прямой возврат в шины
сообщений реального времени или очереди событий для дальнейшей обработки
или анализа в реальном времени.
Загрузка данных в реальном времени средствами Spark требует постоянной
активности вычислительного кластера, что может привести к высоким затратам. Если задержка не важна, рассмотрите возможность запуска по расписанию (например, каждые пять минут) и обработке накопившихся за это
время данных для снижения затрат.

Кроме того, интеграция Structured Streaming с другими компонентами экосистемы
Spark, такими как MLlib (https://spark.apache.org/mllib) для машинного обучения,

  

Обработка в реальном времени

63

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

Поставка изменений в данных
Другой паттерн, который стоит обсудить в контексте потоковой обработки
данных, — поставка изменений в данных (https://oreil.ly/TzJWZ). Этот механизм
позволяет сохранять изменения в таблицах Delta при их возникновении, чтобы
обрабатывать эти изменения (почти) в реальном времени.
Для поставки изменений в данных необходимо задать свойству d e l t a .
enableChangeDataFeed таблицы Delta значение true. Пример:
ALTER TABLE myDeltaTable
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)

Поставка изменений в данных может служить источником входных данных для
Spark Structured Streaming. Комбинация этих двух инструментов представляет
эффективный механизм обработки данных в реальном времени. Например, она
позволяет обрабатывать только изменения после исходного сравнения MERGE,
ускоряя и упрощая операции ETL/ELT. По той же схеме можно организовать
потоковую передачу изменений нижестоящим системам (например, Kafka или
РСУБД), которые затем могут использовать эти инкрементальные данные для
обработки на более поздних стадиях пайплайнов данных.
За практическим руководством по интеграции Delta Lake со Spark Structured
Streaming обращайтесь к документации Delta Lake «Table Streaming Reads and
Writes» (https://oreil.ly/H9-aT). Этот ресурс содержит подробную информацию
и примеры, которые помогут эффективно реализовать загрузку потоковых
данных.

Захват изменений в данных
Захват изменений в данных (CDC, Change Data Capture) — метод, используемый для идентификации и сохранения изменений, вносимых в данные,
в реальном времени. Средства CDC активно отслеживают изменения в базе
данных и регистрируют их при обнаружении, что делает возможным репликацию данных в другие системы. Этот метод особенно эффективен для сохранения данных систем-источников в реальном времени, упрощая бесшовную
интеграцию этих изменений в платформах данных. CDC более подробно рассматривается в главе 5. В завершение раздела, посвященного обработке данных
в реальном времени, перечислим факторы, которые необходимо учитывать,
и учебные ресурсы.

  

64

Глава 2. Закладка фундамента

Факторы и учебные ресурсы
Spark Structured Streaming, поставка изменений в данных и CDC — неотъемлемые
компоненты мощных пайплайнов интеграции и аналитики данных в реальном
времени. Подробное описание вклада каждого компонента в эти процессы приведено в табл. 2.1.

Таблица 2.1. Обзор методов обработки данных в реальном времени
Метод

Описание

Spark Structured Streaming

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

Поставка изменений
в данных

Сохраняет изменения в таблицах Delta в реальном времени; для повышения эффективности обработки данных передаются только приращения и различия между состояниями («дельты»)

CDC

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

При рассмотрении репликации данных в реальном времени, потоковой обработки и проектирования бронзового уровня приходится учитывать ряд
особенностей. Например, можно рассмотреть возможность использования
функциональности зеркалирования Microsoft Fabric (https://oreil.ly/IXZ-U) для
репликации данных почти в реальном времени из облачного нативного приложения Azure SQL в озеро-хранилище. Этот метод репликации использует
технологию CDC базы данных, преобразует информацию в соответствующие
таблицы Delta и помещает ее в архитектуру озера-хранилища (OneLake). Вопрос о том, будут ли эти данные принадлежать бронзовому уровню, зависит от
конкретных потребностей.
Если ваша главная цель — накопление полных выборок данных, то данные,
реплицируемые в реальном времени, лучше классифицировать как часть промежуточной (посадочной) области. Такая конфигурация позволяет обращаться
с запросами к данным напрямую, как если бы они были частью источника, без
последствий для приложения-источника. Однако она не помогает эффективно
накапливать копии сырых данных для исторического анализа. В таком сценарии
исходный уровень работает как уровень репликации или уровень, предшествующий бронзовому.
С другой стороны, если ваша цель — создание бронзового уровня с возможностью
запросов, который воспроизводит данные источника «как есть», то реплицированные данные в реальном времени могут считаться частью бронзового уровня.
В итоге классификация зависит от конкретных потребностей и ваших планов
по использованию реплицированных данных в архитектуре озера-хранилища.

  

ETL и средства оркестрации

65

Главное о загрузке данных в реальном времени
и потоковых данных
Ключевой вывод заключается в том, что решение о реализации загрузки
или репликации данных в реальном времени, а также классификации
этих данных на бронзовом уровне или в промежуточной области определяется прежде всего специфическими требованиями к использованию
и стратегическими целями бизнеса.
Также важно понимать, что при загрузке данных в реальном времени обновления
часто происходят на нескольких уровнях одновременно. Например, можно воспользоваться механизмом Spark Structured Streaming для обработки потоковых
данных из Azure Event Hubs (https://oreil.ly/F_35_) напрямую. Тогда во время обработки можно сразу же выполнить такие преобразования, как удаление лишних
столбцов, агрегирование данных и даже добавление предварительных оценок
тональности. Можно хранить сырые данные на бронзовом уровне и одновременно
отправить преобразованные, очищенные данные сразу на серебряный или даже
на золотой. В таких сценариях бронзовый уровень выступает скорее как архив,
а не как уровень, с которого читаются данные. Такой способ параллельной обработки особенно подходит для аналитики в реальном времени, позволяя быстро
обращаться к входным данным и анализировать их.
Потоковая передача данных — сложная тема, подробно рассматриваемая в руководстве Delta Lake: The Deinitive Guide. Если вам захочется глубже изучить эту
тему, я также рекомендую ознакомиться с изданием «Structured Spark Streaming
with Delta Lake: A Comprehensive Guide» (https://oreil.ly/wJ_SY). Эти ресурсы содержат выводы и рекомендации по реализации потоковой передачи с фреймворком
Delta Lake, что расширит ваше понимание темы и научит эффективно управлять
данными в реальном времени.
Управление загрузкой (как потоковых, так и пакетных) данных — сложная тема,
и чтобы хорошо разобраться в ней, необходимы четкие рекомендации. Для эффективной обработки данных очень важно подобрать подходящий метод. А для
успешной реализации выбранного метода необходимо определить правильные
инструменты, так как они напрямую влияют на эффективность и действенность
процессов загрузки данных.

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

  

66

Глава 2. Закладка фундамента

Apache Airlow
Платформа с открытым исходным кодом, позволяющая на программном уровне создавать, планировать и отслеживать рабочие потоки. Особенно полезна
для оркестрации сложных пайплайнов данных и управления зависимостями
между задачами. Apache Airflow рассматривается в главе 6.
Azure Data Factory
Технология широко применяется в организациях, использующих Synapse
Analytics, Azure Databricks и Microsoft Fabric. Эффективно работает для
создания, планирования и оркестрации рабочих потоков данных. В Microsoft
Fabric сервис Azure Data Factory (ADF) называется просто Data Factory, но
его функциональность в основном остается той же. Другая важная особенность ADF — поддержка множественных точек подключения, позволяющих
извлекать данные из широкого спектра источников.
Databricks Auto Loader
Продукт спроектирован специально для экосистемы Databricks. К его сильным
сторонам относится инкрементальная обработка новых файлов при их поступ­
лении в облачное объектное хранилище. Одна из стандартных функций — поддержка эволюции схем. Auto Loader рассматривается в главе 5.
Databricks LakeFlow Connect
Другой сервис, специфический для Databricks. Предоставляет встроенные
точки подключения для разных источников, включая Salesforce и SQL Server,
что упрощает загрузку данных.
Databricks Worklows
Управляемый сервис оркестрации, входящий в Databricks. Позволяет определять, управлять и отслеживать многозадачные рабочие для ETL, аналитики
и пайплайнов машинного обучения.
Если вам потребуется более широкая совместимость и набор функций, обратите
внимание на такие сторонние инструменты, как Fivetran (https://fivetran.com),
Qlik (https://qlik.com), StreamSets (https://docs.streamsets.com), Syncsort (https://
precisely.com/product/precisely-syncsort/syncsort-mfx), Informatica (https://informatica.
com) и Stitch (https://stitchdata.com). Они предлагают обширные наборы точек
подключения и средств оркестрации и часто используются в сочетании с другими
инструментами для расширения функциональности.
При проектировании архитектуры медальона необходимо учитывать специфические возможности и ограничения выбранных инструментов ETL. Сложность
шагов загрузки данных, которые возможны при использовании этих инструментов, может потребовать добавления в архитектуру шагов предварительной
обработки. Таким образом, выбор инструментов ETL может не только определять
дизайн первых уровней, но и влиять на архитектуру в целом. Поэтому необходимо

  

Управление таблицами Delta

67

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

Управление таблицами Delta
Задача управления таблицами с учетом ее влияния на производительность,
удобство использования и затраты актуальна для всех уровней. Для улучшения
механизма управления данными рекомендуется использовать такие методы, как
Z-упорядочение и жидкая кластеризация, повышающие эффективность процессов
получения данных. В следующих разделах эти методы будут рассмотрены более
подробно. Мы начнем с Z-упорядочения и V-упорядочения, а затем перейдем
к партиционированию. В завершение рассмотрим методы жидкой кластеризации
(liquid clustering), сжатия таблиц и оптимизации записи, а также DeltaLog.

Z-упорядочение
Z-упорядочение (https://oreil.ly/nPgbD) — это метод, повышающий эффективность
извлечения данных за счет группировки взаимосвязанной информации в одном
файле(-ах). Он улучшает локальность, сокращает количество операций ввода/
вывода и поддерживает многомерное управление данными. Это делает его в два—
четыре раза эффективнее обычного извлечения данных. Рост производительности
Z-упорядочения особенно заметен в сценариях, требующих эффективной фильт­
рации и соединений. Хотя жидкая кластеризация, объединяющая преимущества
Z-упорядочивания и партиционирования таблиц, в некоторых случаях стала
заменять этот метод, Z-упорядочивание может оставаться актуальным в зависимости от вашей архитектуры и требований.
На практике Delta Lake автоматически использует этот метод в своих алгоритмах
пропуска данных. Чтобы реализовать Z-упорядочение, просто укажите столбцы,
которые должны быть в него включены, при помощи условия ZORDER BY. Этот
метод гарантирует оптимальное размещение данных для быстрого доступа и обработки.
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

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

  

68

Глава 2. Закладка фундамента

V-упорядочение
V-упорядочение — еще один прием, используемый для того, чтобы оптимизировать
извлечение данных. В отличие от Z-упорядочения, V-упорядочение представляет
собой способ оптимизации при записи для файлового формата Parquet. По сути, это
оптимизация, которая логически организует данные на основании алгоритма хранения, используемого в ядре Power BI VertiPaq. Она делает возможным быстрое чтение
в вычислительных движках Microsoft Fabric, таких как Power BI или Warehouse.
Обратите внимание: V-упорядочение на 100 % совмес­тимо с открытым форматом
Parquet, поэтому все ядра Spark могут читать его как обычные файлы Parquet.
Согласно документации Microsoft по оптимизации таблиц Delta Lake и V-упоря­
дочению (https://oreil.ly/WzkA2), производительность, достигнутая с использованием V-упорядочения, зависит от ядра и сценария. Если вкратце, производительность при работе с V-упорядоченными файлами может обеспечить ускорение
записи в среднем на 10 %, а в некоторых сценариях выигрыш может достигать
50 %. V-упорядочение настраивается на уровне свойств таблиц Delta. Пример:
CREATE TABLE person (id INT, name STRING, age INT)
USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

Важно понимать, что оптимизация производительности V-упорядочением не
дается даром. Сортировка может увеличить среднее время записи в худшем случае на 15 %1. Но при необходимости эту функцию можно отключить. Негативное
влияние на время записи обусловлено дополнительным этапом сортировки
в процессе записи. Это может создать проблемы при больших объемах записи
и ограниченном объеме чтения.
Для оптимальной производительности лучше всего совместить V-упорядочение
с уровнями архитектуры или конкретного сценария использования, например
в сценарии с интенсивным использованием эндпоинтов SQL. Такое совмещение
поможет определить, компенсирует ли выигрыш от использования сортировки
при V-упорядочении потенциальные потери от производительности.
Разобравшись с упорядочением, перейдем к партиционированию данных — еще
одному паттерну, который может повысить производительность.

Партиционирование таблиц
Партиционирование таблиц (table partitioning) — эффективная стратегия управления большими датасетами размером от нескольких сотен гигабайт до многих
терабайтов. Большая таблица делится на меньшие, более управляемые сегменты,
или партиции, что значительно повышает производительность запросов за счет
1

Майлз Коул (Miles Cole) приводит конкретные цифры повышения производительности для разных рабочих нагрузок в своем блоге To V-Order or Not: Making the Case for
Selective Use of V-Order in Fabric Spark (https://oreil.ly/3iOeE).

  

Партиционирование таблиц

69

сокращения объема данных, которые должны читаться при каждом запросе.
С Delta Lake таблицы можно партиционировать по конкретному столбцу. Для
этого часто используется столбец даты, но вы можете выбрать любой, часто используемый в запросах. Например, если вы часто загружаете данные для некоторой страны, целесообразно провести партиционирование по столбцу страны.
Чтобы реализовать партиционирование, укажите нужный столбец в условии
PARTITIONED BY. Этот способ ускоряет доступ к актуальным данным и оптимизирует обработку запросов. Пример:
CREATE TABLE events
USING DELTA
PARTITIONED BY (date)

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

Жидкая кластеризация
Оптимальная реализация Z-упорядочения и партиционирования сопряжена
с определенными проблемами и компромиссами. Эти способы оптимизации
требуют фиксированной структуры данных и тщательного предварительного
планирования. Для решения этих проблем в середине 2024 года в проекте Delta
Lake появилась новая функция, называемая жидкой кластеризацией (liquid
clustering). Предполагается, что она заменит традиционное Z-упорядочение и партиционирование. Жидкая кластеризация упрощает процесс принятия решений
для организации данных и значительно повышает производительность запросов
за счет автоматической оптимизации структуры данных. Это означает, что вам не
придется вручную настраивать структуру для оптимальной производительности.
Жидкая кластеризация динамически адаптирует структуру данных на основе
ключей кластеризации. В отличие от статической организации данных, характерной для партиционировании в стиле Hive, эта гибкая («жидкая») структура
изменяется в ответ на меняющиеся шаблоны запросов. Динамическая подстройка решает такие проблемы, как неоптимальное партиционирование и высокая
кардинальность столбцов. Кроме того, вы можете применять инкрементальные
оптимизации и перекластеризовывать столбцы без необходимости перезаписывать данные. За более подробной информацией обращайтесь к официальной
документации Delta Lake по жидкой кластеризации (https://oreil.ly/b5COK).

Сжатие и оптимизация записи
Delta Lake предоставляет операцию OPTIMIZE, спроектированную специально для
решения проблемы малых файлов — стандартной проблемы, упоминавшейся в разделе «HDFS» главы 1, с. 41. При обновлении, удалении или добавлении новых
данных Delta Lake сохраняет эти изменения в небольших файлах. Со временем эти

  

70

Глава 2. Закладка фундамента

небольшие файлы накапливаются и могут замедлять процессы извлечения данных.
Для решения этой проблемы можно запустить процесс оптимизации, который
компонует маленькие файлы в большие, более удобные, повышая производительность запросов. Задание на оптимизацию можно за­пустить командой OPTIMIZE:
OPTIMIZE delta_table_name;

Другой способ повышения производительности основан на оптимизации записи. По умолчанию эта функция отключена, но ее можно активизировать в Delta
Lake версии 3.1 и выше — просто задайте свойству таблицы delta.autoOptimize.
optimizeWrite значение true. При включении этого свойства1 Delta Lake автоматически оптимизирует структуру файла данных во время записи, что приводит
к повышению производительности запросов. Дополнительную информацию об
этих возможностях можно найти в документации Delta Lake (https://oreil.ly/eo8ac).
После знакомства с методами оптимизации таблиц перейдем к журналу транзакций, который важен для защиты целостности данных и восстановления данных.

DeltaLog
Журнал транзакций Delta, также называемый DeltaLog, — ключевой инструмент
Delta Lake, часто используемый на всех уровнях архитектуры медальона. Как
отмечалось в главе 1, DeltaLog — журнал транзакций, в котором регистрируются
все изменения, вносимые в данные в таблицах Delta. К их числу относятся добавления, команды изменения структуры, задания оптимизации, модификации
и удаления данных. Журнал ведет подробную историю таблиц и хранит ее в виде
серии файлов JSON в каталоге _delta_log, находящемся в каталоге таблиц Delta.
Каждая транзакция генерирует новый файл журнала с подробной информацией
о выполненных действиях, добавленных и удаленных файлах и других важных
подробностях транзакций. По умолчанию для этих файлов время хранения составляет 7 дней. Но эту настройку можно изменить командой ALTER TABLE SET
TBLPROPERTIES , что повышает гибкость выбора срока хранения журнала. Эта
функция повышает надежность управления данными, а также расширяет возможности аудита и отката изменений в случае необходимости.
Команда VACUUM очищает каталог таблицы, удаляя из него любые файлы,
не находящиеся под управлением Delta, а также файлы данных, не являю­
щиеся частью последнего состояния журнала транзакций таблицы, возраст
которых превышает заданный порог удержания. Очистка помогает поддерживать эффективную, оптимизированную среду хранения данных, одновременно обеспечивая экономию и соответствие требованиям.
1

Как и в случае с V-упорядочением, использование свойства delta.autoOptimize.
optimizeWrite увеличивает накладные расходы. Для заданий умеренного размера, обрабатывающих от 2 до 5 миллионов записей, дополнительная задержка составит в целом
от 5 до 10 секунд.

  

Заключение

71

Для архитектуры медальона журнал DeltaLog предоставляет мощные средства
безопасности. Если произойдет ошибка или целостность данных окажется под
угрозой, особенно на уровнях Silver или Gold, вы сможете быстро вернуться
к предыдущей версии таблицы Delta благодаря команде RESTORE, которая предоставляет доступ к более ранним версиям таблицы по времени или номеру версии.
Эта возможность лежит в основе таких критически важных функций, как аудит
данных, отмена транзакций и репликация экспериментов или отчетов.
Тем не менее следует заметить, что журнал DeltaLog — это прежде всего средство
восстановления данных и аудита, а не традиционная база данных с исторической
информацией. Например, чтобы получить через журнал транзакций записи, изменившиеся за последний месяц, потребуется много операций обработки данных,
так как придется прочитать все файлы и сравнить их на наличие изменений.
Более эффективный способ отслеживания исторических изменений основан на
прямом управлении ими в таблице с использованием таких методов, как SCD
(медленно изменяющиеся измерения). Такой подход не только оптимизирует
производительность, но и помогает поддерживать целостность данных во времени. Мы вернемся к этой теме в подразделе SCD раздела «Серебряный уровень»
главы 3, с. 89.

Главное об управлении таблицами
Для достижения оптимальной производительности управления данными
совместите методы упорядочения (такие, как V-упорядочение и жидкая кластеризация) с уровнями архитектуры, уделяя первоочередное
внимание запросам и схемам доступа на каждом уровне. Это обеспечит
эффективную обработку запросов и извлечение данных. Также важно
установить адекватные пороги удержания для таблиц Delta. Выберите
пороги, подходящие для ваших потребностей эксплуатации и сценариев
восстановления данных и сохраняющие баланс между свежестью данных
и затратами на хранение.
Получив полное представление о ролях и факторах, которые необходимо учитывать при реализации схем загрузки и управления таблицами, вы готовы к принятию обоснованных решений о структуре и методологиях архитектуры медальона.
Давайте перечислим ключевые выводы и разберемся, что полезного можно из них
извлечь и что пригодится в дальнейшем на нашем пути.

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

  

72

Глава 2. Закладка фундамента

потребовать особого подхода к эффективному управлению операциями извлечения и загрузки данных, поэтому важность этого фундаментального этапа нельзя
недооценивать. Очень важно участвовать в подробном планировании и сотрудничать с владельцами систем-источников. Это поможет принять обоснованные
решения о том, стоит ли добавлять посредника, дополнительные посадочные
зоны и использовать интеграционные компоненты времени выполнения, а также
о выборе между пакетной обработкой и обработкой в реальном времени. Для всех
этих решений существуют свои условия, и они могут значительно повлиять на
объем работы, необходимый для сбора данных.
Более того, от выбора ETL и средств оркестрации может зависеть дизайн начальных уровней и архитектуры в целом. Чтобы эти инструменты не только
отвечали текущим целям, но и сочетались с общими требованиями организации,
от архитектора потребуется тщательное их обдумывание и стандартизация.
В контексте инструментов и сервисов стандартизация играет ключевую роль
для эффективности управления данными и метаданными, сбора происхождения
данных (data lineage), последовательного составления отчетов о качестве данных
и других подобных задач. Это решение повлияет на гибкость и масштабируемость
архитектуры медальона.
Кроме того, управление таблицами и подход к моделированию данных тесно
связаны и исключительно важны для оптимизации производительности. Стратегии управления таблицами должны определяться в самом начале процесса
проектирования, чтобы архитектура могла эффективно справляться с предполагаемыми нагрузками.
После рассмотрения этих фундаментальных вопросов все готово к построению
архитектуры медальона. В главе 3 глубже изучается специфика каждого уровня — его подробная структура, факторы, которые необходимо учитывать, и выработанные лучшие практики.

ГЛАВА 3

Секреты архитектуры медальона
В главе 1 мы поговорили об эволюции Spark и Delta Lake, а также представили
архитектуру медальона. Этот паттерн проектирования помогает организовать
данные логически в современных архитектурах озер-хранилищ. Он использует
три уровня (бронзовый, серебряный и золотой) для последовательной очистки
датасетов на протяжении всего жизненного цикла: приема данных, их преобразования и загрузки в различные целевые системы.
Попытка объяснить принципы архитектуры медальона часто напоминает открытие ящика Пандоры, поскольку всем уровням, предназначенным для разных
задач, недостает четких определений и содержательных рекомендаций. Такая неоднозначность часто рождает больше вопросов, чем ответов, создавая порочный
круг недопонимания и неэффективности.
Несмотря на популярность этой трехуровневой архитектуры, касательно каждого
уровня ведутся серьезные споры по поводу его области действия, назначения
и лучших практик. Более того, между теорией и практическим применением существует значительный разрыв. В этой главе я поделюсь наблюдениями из моего
опыта проектирования каждого уровня архитектуры медальона с теоретической
точки зрения. В части II мы перейдем от теории к практике. Выводы этой главы
пригодятся вам при выполнении упражнения, когда вы будете учиться строить
архитектуру реального решения.

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

  

74

Глава 3. Секреты архитектуры медальона

Бронзовый
уровень
(сырые копии)

Источники
OLTPсистемы
OLTPсистемы
OLTPсистемы

Посадочная
зона
Репозиторий
больших
двоичных
файлов
Kafka

Исходная
посадочная
зона для сырых
данных,
собранных
из разных
источников

Серебряный
Золотой уровень
уровень
(данные, смоде(отфильтрованлированные
ные, чистые, для потребления)
дополненные
данные)
Переходная
стадия, на которой структура
и гранулярность
данных все еще
соответствуют
источникам,
но данные прошли обработку,
обеспечивающую
их качество
и целостность

Основное
внимание
уделяется
производительности и масштабируемости
данных,
позволяющим
быстро получать
бизнес-аналитику

Рис. 3.1. Архитектура медальона и ее три уровня
Бронзовый уровень
Это область для размещения сырых данных, собранных из различных источников. Данные на бронзовом уровне хранятся в своей исходной структуре, без
преобразований, становясь историческим эталоном и единым источником истины. Уровень обеспечивает надежное хранение данных, делая их доступными
для дальнейшей обработки.
Ключевые характеристики этого уровня — большой объем, разнообразие и достоверность. Данные хранятся в неизменяемом виде для сохранения целостности исходного состояния.
Серебряный уровень
На нем выполняется очистка и стандартизация сырых данных, подготовка их
к более сложным задачам эксплуатации и аналитики. На этом уровне данные
проходят проверку качества, стандартизацию, удаление дубликатов и другие
операции, повышающие их надежность и удобство использования. Серебряный уровень — это переходная стадия, на которой данные все еще гранулярны,
но прошли обработку для обеспечения качества и согласованности.
Ключевые характеристики этого уровня — улучшение структуры и удобства
обработки запросов, благодаря чему с данными удобнее работать аналитикам
и специалистам data science.
Золотой уровень
Поставляет очищенные данные, оптимизированные для конкретной биз­нес-­
аналитики и принятия решений. На золотом уровне проводится агрегирование,

  

Бронзовый уровень

75

обобщение и обогащение данных для поддержки высокоуровневых отчетов
и аналитики. На этом уровне основное внимание уделяется производительности, удобству использования и масштабируемости, обеспечивающим быстрый
доступ к ключевым метрикам и аналитическим выводам.
Ключевые характеристики этого уровня — высокая степень организации
и оптимизации для потребления, чтобы данные могли поддерживать стратегические бизнес-операции и решения.
Хотя переход от локальных РСУБД на распределенные архитектуры со слабой связанностью изменили положение дел в технологиях, фундаментальные
методологии хранилищ и моделирования данных остаются актуальными.
Если вы успели подзабыть эти навыки, я рекомендую повторить основы.
В числе хороших источников информации можно выделить книги Kimball
Group (https://oreil.ly/ehuVU) о хранилищах данных и размерном моделировании, а также книгу о схемах звезды «Star Schema: The Complete Reference»
Кристофера Адамсона (Christopher Adamson) (McGraw Hill Osborne Media)
(https://oreil.ly/VZT3Q). Это замечательные ресурсы для понимания принципов
моделирования данных.

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

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

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

  

76

Глава 3. Секреты архитектуры медальона

данных и потребностей организации. В главе 2 мы обсуждали возможность включения дополнительных посадочных зон и принадлежности таких зон к бронзовому уровню. Вернемся к этой теме с примерным сценарием и сделаем несколько
выводов.
Традиционные системы-источники часто диктуют формат, в котором должны
экспортироваться данные, обычно CSV или JSON. Рассмотрим унаследованное
приложение, которое экспортирует данные только в локальную файловую сис­
тему. В этом сценарии данные интегрируются в архитектуру медальона через
пакетную обработку.
Вот типичная структура процесса. Все начинается с временным размещением
данных в посадочной зоне, где выполняются минимальные задачи обработки,
такие как распаковка сжатых файлов, сравнение контрольных сумм и генерация
метаданных. Затем данные копируются на бронзовый уровень и преобразуются
в формат типа Delta Lake для повышения производительности. На этом этапе
также выполняются базовые проверки, обеспечивающие целостность данных.
Дополнительно данные могут классифицироваться или шифроваться для защиты конфиденциальной информации. Наконец, данные сравниваются и интег­
рируются с существующими наборами «бронзовых» данных для поддержания
согласованности и полноты. Мы вернемся к этим подробностям в главе 5, когда
займемся реализацией бронзового уровня с использованием внешних таблиц
или копий Delta.
Шифрование сырых данных исключительно важно для защиты персональной
информации (PII, Personally Identifiable Information) от несанкционированного доступа. Соответственно, перед размещением на бронзовом уровне данные довольно часто подвергаются шифрованию. Для шифрования можно
воспользоваться фреймворками с открытым исходным кодом, такими как
Fernet (https://oreil.ly/e5C_d), или другими средствами шифрования.

В иерархии обработки данных бронзовый уровень часто включает несколько
подуровней: внутреннюю область промежуточного хранения, область обработки
и очистки и в итоге репозиторий в формате Delta. Таким образом, состоит ли
бронзовый уровень из одного физического уровня или из нескольких подуровней,
зависит от сложности источника данных, организационных требований и решения
о том, включать ли посадочную зону как часть бронзового уровня.
После формирования иерархии обработки необходимо сосредоточиться на обработке и управлении данными во времени, потому что каждый источник уникален, а механизм поставки данных зависит от системы-источника. Одни системы
предоставляют полные выборки, другие поставляют инкременты («дельты»),
третьи передают данные непрерывно в потоковом режиме. Следовательно, при
разработке архитектуры необходимо выбрать подходящий паттерн обработки.
Рассмотрим эти стратегии более подробно. Начнем с обработки полных загрузок
данных, а затем перейдем к обработке инкрементальных.

  

Бронзовый уровень

77

Обработка полных загрузок данных
Полные загрузки подразумевают не изменение, а передачу всего датасета от системы-источника, гарантируя, что все данные будут доступны для последующей
обработки. При этом большие пакеты данных обычно обрабатываются с фиксированными интервалами, часто с использованием посадочных зон (которое не
является обязательным). После проверки данные сохраняются в сырой форме и накапливаются в папках вместе со всеми предыдущими поставками данных. На этом
этапе обычно выполняются минимальные преобразования: фильтрация, удаление
конфиденциальных столбцов и т. д. После накопления данных самая последняя
поставка обычно преобразуется в формат Delta Lake или предоставляется в форме
внешних таблиц для обработки на следующем уровне. Мы вернемся к этим паттернам в главе 5, когда будем более подробно рассматривать полные загрузки данных
с конкретными примерами.

Обработка инкрементальных загрузок данных
Паттерн загрузки инкрементов (приращений), или дельта-загрузок1, часто применяется в сценариях, требующих обработки только изменений или обновлений
данных. Это делает возможной более эффективную обработку данных и снижает
время обработки по сравнению с полной загрузкой. При таком подходе вы обычно
получаете только изменившиеся данные, например, в форме событий. Эти данные
размещаются на предварительном уровне, где применяются некоторые несложные
преобразования: изменение формата файлов (например, из JSON в Parquet), преобразование данных в формат Delta Lake или простые исправления типа данных.
Затем можно воспользоваться режимом добавления (append mode) (https://oreil.
ly/Kihgv) или операциями слияния (merge) (https://oreil.ly/VPIQE) для интеграции
входных новых данных с существующими данными, уже присутствующими на
бронзовом уровне. Рассмотрим эти методы более подробно.
Режим добавления
В контексте Delta Lake «режим добавления» (append) означает, что новые
данные добавляются в существующую таблицу Delta без модификации или
удаления существующих данных. Это может быть полезно в сценариях, когда
в датасет непрерывно добавляются новые записи (например, при ведении журнала или потоковой передаче данных), не затрагивая существующие данные.
В следующем примере df представляет DataFrame — структурированную
коллекцию данных с именованными столбцами. При помощи Spark можно
прочитать данные в DataFrame, а затем добавить их к таблице Delta:
df = spark.read.json(f"{filePath}/events/*.json")
df.write.format("delta").mode("append").saveAsTable("events")
1

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

  

78

Глава 3. Секреты архитектуры медальона

Режим append не выполняет обновления или удаления — он просто добавляет
новые данные в конец датасета.
Операции слияния сложнее, потому что они позволяют как вставлять новые
записи, так и обновлять существующие записи по некоторому ключу.
Режим слияния
В Delta Lake «режим слияния» (merge) предоставляет возможность одновременного выполнения вставки и обновления в таблицах Delta. Это особенно
полезно при необходимости обновления существующих записей и новых
вставок в одной операции на основании заданного условия.
Допустим, вы управляете таблицей с информацией о клиенте, включая флаг
статуса is_current для клиентов, присутствующих в системе-источнике в течение последних 180 дней. Можно воспользоваться операцией MERGE с таблицей Delta, которая фактически позволяет выполнить несколько изменений
одновременно:
• вставка новых клиентов;
• обновление статуса недавно вернувшихся клиентов;
• изменение статуса существующих клиентов в таблице Delta, неактивных
в настоящее время.
Delta Lake эффективно выполняет эти операции за кулисами, обеспечивая целостность данных и оптимизированную обработку. Мы вернемся к этому способу
слияния в главе 5.
Обработка инкрементальных загрузок — эффективный способ управления
большими датасетами за счет обработки только изменений с момента последней
поставки вместо повторной обработки всех датасетов. Такой подход особенно
удобен в сценариях с большими таблицами систем-источников (например, содержащими миллионы строк). Более того, инкрементальная загрузка играет важную
роль в эффективном обновлении данных на любых уровнях (в том числе сереб­
ряном и золотом) без повторной обработки всего датасета. Один из факторов,
которые необходимо учитывать при инкрементальной загрузке, — возможность
ее объединения с поставкой изменений в данных для передачи инкрементальных
изменений на следующие уровни.
Реализуя инкрементальную обработку с Delta Lake и Spark, а также применяя
такие конфигурации, как trigger(Available Now=True), организации могут
управлять своими данными более эффективно и экономично.

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

  

Бронзовый уровень

79

записи с момента последней загрузки. Также важно позаботиться о том, чтобы система-источник не обновляла записи старше последнего загруженного инкремента.
Если обновления более старых записей возможны, стандартная инкрементальная
загрузка может упустить эти изменения. В таких случаях может потребоваться CDC
или другие аналогичные инструменты. Такие инструменты спроектированы для отслеживания всех изменений данных (вставок, обновлений, удалений) из журналов
транзакций и могут более надежно обеспечивать полную синхронизацию данных.
Для потоковой передачи обычно задается значение startingVersion исходной
позиции (https://oreil.ly/mdyg9) с использованием журнала транзакций Delta (или
Iceberg). Это позволяет возобновить передачу данных точно с места разрыва, без
необходимости выполнения дополнительных команд.
Чтобы определить последнюю обработанную запись, можно также воспользоваться функцией max (https://oreil.ly/CBhY8) для идентификатора или столбца
updated_at бронзового уровня. Имея наибольшее значение (max(updated_at))
бронзового уровня, можно запросить из данных источника записи с идентификаторами или метками времени, превышающими это значение. Это гарантирует,
что обрабатываться будут только новые записи или записи, обновленные после
последней загрузки.
Еще одна рекомендация — ведение таблицы метаданных, в которой отслеживаются обработанные записи. Такое решение помогает управлять потоками данных
и обеспечивать согласованность, особенно в сложных системах.
Если вам захочется подробнее разобраться в инкрементальных дельта-загрузках
и их применении на практике, посмотрите ролик Incremental Refresh with Your
Warehouse Without a Date in Microsoft Fabric (https://oreil.ly/cNE8z). Это видео,
посвященное инкрементальным дельта-загрузкам, содержит подробную информацию и примеры, которые помогут эффективно реализовать этот метод.
Полученные входные данные в инкрементальной форме можно интегрировать
с полным историческим датасетом. Процесс историзации важен не только для
создания полного архива, но и для обеспечения доступности текущих данных
с целью дальнейшей обработки в нижележащих системах. Этой теме посвящен
следующий раздел.

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

  

80

Глава 3. Секреты архитектуры медальона

В архитектуре медальона архивация данных выполняется достаточно тривиально
при использовании эффективного формата хранения данных (такого, как Parquet
или Delta) и распределении данных по папкам1. Структурирование данных по
таблицам с интервальным партиционированием и их сортировка по папкам
с именами в формате ГГГГ/ММ/ДД или даты/времени обеспечат хорошую
организацию и управляемость данных. Такая систематическая орга­низация не
только поддерживает четкую и ясную структуру, но и упрощает доступ и аудит.
Если вам когда-нибудь придется вернуться к данным за конкретный день, вы
сможете легко воссоздать их состояние, а это гарантирует, что вы сможете загрузить исторические данные в любой момент, когда потребуется.
Тем не менее важно заметить, что бронзовый уровень не предназначен для историзации данных в смысле представления полностью обработанной таблицы SCD2.
Данные на бронзовом уровне часто считаются неизменяемыми, то есть доступны
только для чтения. Хотя данные можно присоединять или добавлять слиянием
и датасет будет инкрементально расти во времени, обновления или обработка
данных нетипичны для этого этапа.
Вы можете применять версионирование данных, используя функцию time
travel в Delta Lake. Она предназначена в основном для восстановления данных, аудита и воспроизведения экспериментов или отчетов, а не для полной
долгосрочной архивации данных.

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

Эволюция и управление схемой
Бронзовый уровень решает важнейшую задачу управления крайне разнообразными и постоянно изменяющимися схемами данных при поступлении данных
в систему. Эффективная обработка эволюции схем на этой стадии лежит в основе
1

В зависимости от алгоритма сжатия можно ожидать уменьшения размера данных в файлах Parquet до 75 % по сравнению с другими форматами (например, CSV).

  

Бронзовый уровень

81

всей последующей обработки данных и аналитики. Можно обрабатывать изменения входных схем на бронзовом уровне или подождать, пока данные переместятся
на серебряный. Время решения этих проблем сильно зависит от специфических
потребностей приложения и характеристик данных.
При управлении схемами организации должны выбрать одно из существующих
проектировочных решений, каждое из которых предлагает свой подход к эволюции схем.
Определение схемы при чтении (schema-on-read)
При таком подходе схема применяется динамически при чтении данных.
Данные сохраняются без жесткой схемы. Она вычисляется или применяется
только при обращении к данным в ходе обработки (при чтении). Этот гибкий
подход требует, чтобы система распознавала различные схемы данных и могла
адаптироваться к ним прямо в момент загрузки. Он особенно полезен при
работе с полуструктурированными или неструктурированными данными
или структурированными данными без жестко зашитой схемы (например,
файлами CSV или Parquet).
Определение схемы при записи (schema-on-write)
Этот подход подразумевает определение схемы — имен таблиц и столбцов,
типов данных, первичных ключей — при записи данных в хранилище. Необходимо заранее определить схему, убедившись, что данные соответствуют ей
с самого начала, до записи. Этот подход более жесткий по сравнению с определением схемы при чтении, так как он обеспечивает согласованность схемы
с самого начала. На практике он обычно применяется со структурированными
данными.
Если при использовании Delta Lake нет заранее определенной схемы, система
устанавливает исходную схему, используя StructType из DataFrame, преобразуемого в формат Delta. В Apache Spark StructType обозначает контейнер, определяющий структуру и типы столбцов DataFrame.
На бронзовом уровне метод определения схемы при чтении обычно применяется
в случае сохранения данных в исходном формате без проверки соответствия схеме
во время загрузки. Этот метод обеспечивает гибкость, так как он не требует предварительного определения схемы и может корректно обрабатывать изменения
в структуре данных. Представьте, что вы каждый день партиционируете данные
на основе дат в формате ГГГГ/ММ/ДД с сохранением их в файлах Parquet в соответствующих папках, помеченных датой. С определением схемы при чтении
вы можете немедленно обращаться к этим данным и читать их (за разные дни)
без необходимости заранее определять, как должна выглядеть структура данных.
Такой подход позволяет легко интегрировать и анализировать данные, собранные
с течением времени. Тем не менее при этом необходимо учитывать ряд важных
факторов.

  

82

Глава 3. Секреты архитектуры медальона

Во-первых, если вы будете полагаться только на определение схемы при чтении,
это не позволит обрабатывать данные вслепую. Возможно, все равно придется
выявлять и регистрировать изменения схемы, обрабатывать сбои, восстанавливать данные при помощи функциональности time travel Delta Lake и добавлять
метаданные, относящиеся к схеме, для более сложной обработки на более поздних этапах. Мы глубже изучим эти темы и такие инструменты, как Auto Loader,
в разделе «Databricks Auto Loader» в главе 5, с. 170.
Во-вторых, важно определить метод обновления данных, особенно для историзации и интеграции данных. Некоторые возможные варианты — непрерывное добавление (append) или слияние (merge) с существующими датасетами, их полная
перезапись (overwrite) и применение партиционирования на основе времени.
Выбор зависит в основном от природы данных, их использования, конкретных
системных требований и факторов производительности. Например, добавление
обычно выполняется с транзакционными данными, потому что данные этого
типа увеличиваются постепенно с каждой новой транзакцией. Перезапись, как
правило, применяется для датасетов с регулярно изменяющимся источником или
в тех случаях, когда важен самый свежий снапшот. При этом можно реализовать
партиционирование на основе времени для повышения производительности
запросов и эффективного управления большими датасетами, особенно когда обращение к данным чувствительно по времени1.
Таким образом, бронзовый уровень часто объединяет методы определения схемы
при чтении и при записи. Изначально определение схемы при чтении применяется
в посадочной зоне или на уровне, предшествующем бронзовому. Сначала данные
читаются без явного объявления схемы данных. Затем при перемещении на уровень, где они становятся доступными для запросов, происходит переключение
на определение схемы при записи. На этом критически важном уровне разумно
выбрать формат хранения с поддержкой схем, например Delta Lake. Delta Lake
позволяет схеме данных адаптироваться по мере эволюции, что избавляет от необходимости перезагружать весь датасет. Благодаря этой возможности данные
остаются актуальными и полезными, даже если в них произойдут изменения.
Вскоре мы вернемся к этой функции.
Тем не менее следует помнить, что поддержание актуальности схем может создать
проблемы, особенно если системы-источники часто изменяются. Обеспечение
целостности данных и надежности систем в таких случаях требует бдительности и,
возможно, нестандартных стратегий управления схемами. По этой причине важно
поддерживать схему, которая последовательно соответствует системе-источнику
при поступлении данных на уровень, доступный для запросов. Обычно схема настраивается во время процесса загрузки данных для соответствия стандартам —
либо на языках определения данных (DDL, Data Definition Language), либо на

1

Дополнительную информацию о партиционировании см. в разделе «Партиционирование таблиц» главы 2, с. 68.

  

Бронзовый уровень

83

программном уровне с использованием таких инструментов, как Spark SQL или
Databricks Auto Loader. Эта тема более подробно рассматривается в части II.

MergeSchema и контроль соблюдения схемы
Delta Lake предлагает набор функций для управления схемами данных, таких
как обработка эволюции схем (schema evolution) и контроль соблюдения схемы
(schema enforcement). Применяемые функции зависят от специфических потребностей и дизайна схемы и могут встречаться на всех уровнях архитектуры
медальона.
Например, по мере эволюции данных может возникнуть необходимость в изменении схемы таблицы для новых типов данных (например, добавления новых
столбцов). Здесь поможет функция mergeSchema. Она была разработана для упрощения управления и эволюции во времени схем таблиц Delta Lake. Включите
в операцию записи в Apache Spark настройку.option("mergeSchema", "true").
После этого Delta Lake скорректирует схему таблицы следующим образом:
Если столбец существует в источнике DataFrame, но не в таблице Delta, Delta
добавляет новый столбец. У всех существующих строк новый столбец содержит значение null.
Если столбец существует в таблице Delta, но не в источнике DataFrame, он
остается неизменным. У новых записей такие отсутствующие столбцы содержат null.
При добавлении столбца NullType во всех существующих строках для этого
столбца устанавливается значение null.
Если существует столбец с тем же именем, но другим типом данных, Delta
Lake попытается преобразовать данные к новому типу1. Если преобразование
завершится неудачей, Delta Lake выдаст ошибку.
В случае ошибок или сбоев можно откатить таблицу к предыдущей версии при
помощи истории таблиц. Эта функция отмены позволяет устранить проблемы,
связанные с эволюцией схемы. После отката можно заново обработать исправленные данные по корректной схеме. Узнать больше о поддержке эволюции схем
в Delta Lake можно в блогах Delta Lake Schema Enforcement (https://oreil.ly/8PtcS)
и Delta Lake Schema Evolution (https://oreil.ly/lZLnp).
Для более жестких ограничений можно воспользоваться возможностью задания
ограничений (https://oreil.ly/vFv6M), тесно связанной с методом определения схемы
1

Механизм TypeWidening (https://oreil.ly/bqCmp) разрешает изменения в пределах одной категории типов. При этом переходы между категориями типов, например преобразование
строки в логическое значение, недопустимы. Чтобы осуществить такое изменение, необходимо выполнить перезапись в масштабе таблицы и включить режим overwriteSchema:
true.

  

84

Глава 3. Секреты архитектуры медальона

при записи. Подобный подход позволяет следить за тем, чтобы данные, записываемые в таблицу Delta, четко соответствовали схеме таблицы, и отклонять любые
попытки записи, которые ей не соответствуют. При загрузке данных в систему
Delta Lake проверяет их на соответствие заранее определенной схеме. Любые
отклонения вызывают ошибку; так обеспечивается целостность и согласованность данных. Однако это усложняет обработку долгосрочных и деструктивных
изменений в схеме системы-источника.
Если вы сталкиваетесь с изменениями, влияющими на совместимость (например,
с изменениями, которые не могут быть обработаны в режиме mergeSchema), схемы
необходимо согласовать. При корректировке схемы таблицы Delta доступны
следующие варианты:
Использование команд SQL ALTER COLUMN
Обновление схем командами SQL ALTER COLUMN подразумевает внесение прямых изменений, требующих тщательной координации между владельцами
систем-источников и управляющими платформами данных. Эффективный
способ управления этими изменениями основан на занесении операций
или скриптов в репозиторий. Этот метод очень точен, но может оказаться
трудоемким и подверженным ошибкам из-за необходимости тщательной
координации.
Автоматизированная эволюция схемы
Можно реализовать автоматизированные инструменты или скрипты, которые
обнаруживают изменения схемы в системе-источнике и автоматически генерируют и применяют необходимые команды ALTER для приемной системы.
Этот подход более подробно рассматривается в разделе «Эволюция схем»
главы 5, с. 172.
Использование фреймворка, управляемого метаданными
Этот рекомендуемый метод не только помогает в сопровождении исходной
и новой приемной схемы, но и предоставляет надежный механизм систематического управления изменениями. Поддержка отображений между схемами
обеспечивает масштабируемость метода, способного обрабатывать сложные
преобразования и эволюции схем почти без ручного вмешательства. Метод
гарантирует, что репозиторий метаданных остается всегда актуален и точно
отражает используемые схемы. Иногда он интегрируется с пайплайном непрерывной интеграции и развертывания (CI/CD) для автоматизации обновлений
и развертываний. Мы вернемся к этому методу в главе 5.
Ограничение деструктивных изменений
Иногда можно пообщаться с командами систем-источников и предложить
им избегать деструктивных изменений. Таким образом, разрешаются только изменения, обладающие обратной совместимостью. Хотя такой подход

  

Бронзовый уровень

85

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

Технические проверки
Технические проверки играют очень важную роль, так как проблемы с целостностью данных, точностью, полнотой и согласованностью могут иметь значительные
эксплуатационные и стратегические последствия для любой организации. В архитектуре озер-хранилищ бронзовый уровень служит начальным репозиторием
для сырых, обычно неструктурированных данных. Здесь они хранятся в «родном»
формате и могут содержать расхождения или ошибки.
Проверки (например, формата, схемы и полноты) на этом этапе нужны по
нескольким причинам. Прежде всего, они гарантируют соответствие данных
стандартам, что помогает поддерживать согласованность в датасете. Это особенно важно, так как данные из разных источников не всегда соответствуют
стабильной структуре. Более того, ранние проверки помогают выявлять
и решать проблемы с целостностью данных. В частности, они полезны при
использовании метода определения схемы при записи. Раннее обнаружение
ошибок не позволит ошибкам перейти на последующие уровни (серебряный
и золотой), где данные проходят дополнительную обработку и очистку для
целей аналитики.
В дизайне бронзового уровня эффективные средства проверки данных занимают
центральное место. Можно либо выполнить эти проверки за один раз, либо разбить их на сегменты, либо интегрировать при передаче данных на серебряный
уровень. Для эффективной валидации данных многие компании используют
скрипты и поддерживают репозиторий метаданных. В репозитории хранятся
технические подробности схем от систем-источников, что позволяет организовать автоматический контроль соблюдения правил допустимости данных — как
декларативно, так и динамически.

  

86

Глава 3. Секреты архитектуры медальона

Дизайн бронзового уровня также зависит от того, насколько допустимы недостатки целостности данных. Если вы считаете, что они могут вызвать сбой в последующих процессах или потребители данных не смогут с ними разобраться,
пайплайн следует остановить. Такой подход, известный как агрессивный контроль
целостности данных, подразумевает раздельное хранение проверенных и некорректных данных в разных папках или таблицах. Это позволяет легко идентифицировать и исправлять проблемы и гарантирует, что некорректные датасеты не
поступят на реальный бронзовый уровень.
И наоборот, если какие-то проблемы с целостностью или полнотой данных допустимы, вы можете продолжить обработку данных — этот подход называется
неагрессивным контролем целостности. В этом сценарии как проверенные, так
и некорректные данные хранятся непосредственно в приемной папке или таблице
бронзового уровня. В такой ситуации обработку данных можно продолжить, но
следует помнить, что, возможно, проблемы придется решать позднее на другом
уровне (обычно серебряном).
Как правило, проверки предназначены для валидации технических аспектов
источника данных и предотвращают переход данных в следующую зону, если
они не соответствуют набору заранее определенных стандартов. Если данные
не удовлетворяют стандартам следующей зоны, владельцы данных обязаны
исправить проблему в тесном взаимодействии с командами приложений и датаинженерами. Участники этих команд, занимающиеся управлением и поставкой
данных, должны убедиться, что данные соответствуют требованиям к целостности, сформулированным потребителями или пользователями озер-хранилищ.
В этом случае бронзовый уровень служит не только репозиторием для сырых
данных, но и критической контрольной точкой для точности и целостности данных, гарантируя, что в архитектуру озера-хранилища поступают только данные,
удовлетворяющие заранее определенным стандартам качества. Такой активный
подход к управлению данными помогает защитить целостность и удобство использования данных на протяжении их жизненного цикла в озере-хранилище.
Существуют различные инструменты для управления загрузкой данных, их проверкой и оркестрацией, а также проверкой целостности данных.
Для решения проблем с совместимостью и согласованностью данных можно
воспользоваться средствами проверки схем Delta Lake. Например, контроль
соблюдения схемы проверяет, что разработчики придерживаются заранее
определенных стандартов, сохраняя чистоту своих таблиц. Когда данные записываются в таблицу, Delta Lake выполняет проверку схемы, чтобы убедиться,
что схема данных соответствует схеме таблицы. Если схемы совместимы, то
проверка проходит и запись осуществляется успешно, если нет — Delta Lake
отменяет транзакцию, предотвращая запись всех данных.
Вы можете применять фреймворки или средства контроля качества данных:
Delta Live Tables, Great Expectations, dbt (data build tool), Ataccama, Monte

  

Бронзовый уровень

87

Carlo Data и т. д. Мы вернемся к различиям между этими инструментами
в главе 6.
Для проверки целостности данных можно использовать кастомные решения со
скриптами, кодом и метаданными схем. Этот подход часто применяют, когда
у организаций имеются специфические требования, которые не покрываются
существующими инструментами или фреймворками. Кастомные решения
можно настроить для уникальных потребностей организации, чтобы повысить
гибкость и добавить больше возможностей.
Azure Data Factory поддерживает функцию обнаружения дрейфа схем (https://
oreil.ly/yOaM2), что снижает риск ошибок из-за нежелательных изменений в источниках данных выше по потоку.
Итак, мы рассмотрели условия, которые необходимо учитывать при проектировании. Теперь посмотрим, как используется бронзовый уровень и какую роль он
играет в более широком контексте использования данных. Это поможет лучше
понять его важность и интеграцию с более масштабной системой управления
данными.

Использование и управление (governance)
Существует мнение, что запросы к данным или ситуативный анализ данных
на бронзовом уровне могут представлять ценность для бизнес-пользователей. Но сырые данные создают много проблем, поскольку для работы с ними
требуется хорошо понимать структуру системы-источника и встроенную
в нее сложную бизнес-логику. А множество мелких таблиц еще усложняет
дело. Сильная связь с исходной системой-источником создает серьезные затруднения, особенно когда в системе-источнике происходят изменения. Эти
сложности часто мешают напрямую использовать данные бронзового уровня
для бизнес-аналитики.
Чтобы обеспечить необходимый уровень управления данными, реализуйте
жесткий контроль доступа для предотвращения несанкционированных обращений к данным, манипуляций с ними или их удаления. Данные на бронзовом
уровне неизменяемы (то есть остаются в исходном состоянии), хотя при обработке сугубо технических данных возможны исключения. Неизменяемость
требует ведения подробных журналов, в которых для обеспечения точности
отслеживания регистрируется время загрузки, источники и любые взаимодействия с системами.
Критически важно настроить оповещения для отслеживания любых аномалий
в размере данных, формате или времени поступления, чтобы поддерживать
целостность пайплайнов данных. Также очень важно разработать и регулярно
обновлять план реагирования для решения проблем, связанных с неправильной
поставкой данных. Рекомендуется внедрять лучшие практики (например, тщательное документирование изменений и ведение каталога ссылок).

  

88

Глава 3. Секреты архитектуры медальона

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

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

Бронзовый уровень
(сырые копии)

Источники
OLTPсистемы
OLTPсистемы
OLTPсистемы

Посадочная
зона
Репозиторий
больших
двоичных
файлов

Kafka

Сырые экспортирован- Проверенные
таблицы
ные данные
Delta
(CSV)
Сырые экспортированные данные
(Parquet)

Проверенные
таблицы
Delta

Сырые экспортирован- Проверенные
таблицы
ные данные
Delta
(JSON)

Серебряный
уровень
(отфильтрованные, чистые,
дополненные
данные)
Переходная
стадия, на которой структура
и гранулярность
данных соответствуют
источникам, но
данные прошли
обработку,
обеспечивающую
их качество
и целостность

Рис. 3.2. Структура бронзового уровня на практике

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

  

Серебряный уровень

89

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

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

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

  

90

Глава 3. Секреты архитектуры медальона

Приведем примеры операций очистки данных.
Снижение шума и удаление недостоверных данных
Удаление нерелевантных данных (например, ненужных столбцов или строк)
для повышения качества данных и снижения требований к хранению. На этом
шаге также удаляются недостоверные данные, которые неточно отражают
истинный источник.
Обработка отсутствующих значений
Принятие решения о том, что делать с отсутствующими значениями в датасете:
удалять, заменять значением по умолчанию, применять методы подстановки
для оценки отсутствующих значений на основе близлежащих данных.
Удаление дубликатов
Проверка того, что датасет не содержит одинаковых записей, если только это
не обусловлено специальными требованиями (например, удержание данных
в целях комплаенса). Дубликаты могут искажать результаты анализа и приводить к неточности в моделях.
Отсечение пробелов
Удаление ненужных пробелов в записях данных, особенно в строковых типах
данных, где начальные и конечные пробелы могут влиять на сортировку, поиск
и другие задачи обработки строк.
Исправление ошибок
Выявление и исправление ошибок ввода данных: опечаток, неправильного
регистра символов, ошибочных единиц измерения и т. д. К этой категории
также относится выявление и исправление выбросов (outliers) — точек данных,
явно отличающихся от нормы.
Проверки согласованности
Проверка согласованности данных в наборе данных. К этой категории относится стандартизация сокращений, терминологии и единиц измерения
(например, использование только сокращения NL вместо NETHERLANDS).
Стандартизация форматов
Проверка согласованности форматов данных (например, использование
[ГГГГ]-[ММ]-[ДД]) с пониманием того, что в локальных контекстах могут
быть предпочтительны альтернативные форматы (например, [ДД]-[ММ][ГГГГ]).
Исправление типов
Проверка того, что за столбцами закреплены правильные типы данных (числовые, вещественные, даты и т. д.).

  

Серебряный уровень

91

Исправление диапазонов
Проверка того, что данные в каждом столбце входят в заданные диапазоны
значений.
Исправление неуникальности
Проверка того, что данные в каждом столбце сохраняют уникальность (там,
где это необходимо).
Исправление нарушений целостности
Проверка отсутствия «бесхозных» столбцов; каждая дочерняя запись должна соответствовать существующей родительской записи в родительской
таблице.
Маскировка чувствительных данных
Сокрытие любой персональной информации, записанной обычным текстом,
до момента использования данных. Это делается для защиты конфиденциальности и соблюдения нормативных требований.
Выявление аномалий
Обнаружение и исправление аномалий, которые могут указывать на проблемы
с качеством данных. Например, внезапный пик в данных продаж может быть
признаком проблем с качеством данных.
Управление мастер-данными
Обработка данных для обеспечения точности, единообразия и согласованности
общих критически важных данных организации.
Стандартизация данных
Обработка таких данных, как адреса, телефонные номера, местоположения
и справочные коды, для обеспечения их точности и согласованности между
системами.
Согласование данных
Согласование данных с использованием общей модели данных для стандартизации и гармонизации информации между разными системами.
Список не исчерпывающий. Написание правил очистки — сложная задача,
требующая глубокого понимания данных и бизнес-процессов, сгенерировавших данные. Помните, что после очистки структуры таблиц в целом не
отличаются от структур бронзового уровня. Заметим, что неправильные или
отклоненные данные обычно не удаляются. Вместо этого они помечаются
или отфильтровываются, а затем сохраняются в карантинной таблице на
серебряном уровне. Мы подробно рассмотрим эту тему с фрагментами кода
и примерами в главе 6.

  

92

Глава 3. Секреты архитектуры медальона

Итак, данные прошли очистку; что дальше? Сохранить данные в исходной
структуре или перемоделировать их? Рассмотрим эти вопросы в следующих
разделах.

Проектирование модели данных серебряного уровня
Структура модели данных серебряного уровня относится к числу важнейших
параметров архитектуры медальона. Часто эта тема вызывает особое внимание
из-за обилия вариантов. На выбор реализации значительно влияет количество
источников, из которых собираются данные, степень совместного использования
этими источниками одних и тех же ключевых элементов или объектов, которые
могут сравниваться, сопоставляться и комбинироваться между ­разными системами-источниками, и необходимость гармонизировать эти перекрывающиеся
ключевые элементы для получения целостной картины.
Начнем с согласования и переименования столбцов, а затем перейдем к денормализации. После этого рассмотрим темы SCD, использование суррогатных ключей
и гармонизацию с другими источниками. Наконец, обсудим 3NF и методы моделирования Data Vault, а завершим обсуждение методами использования данных
и управления ими на серебряном уровне.

Согласование и переименование столбцов
В архитектуре медальона вполне типично совмещение серебряного и бронзового уровней (прямое, один к одному) по таблицам, хотя способы представления
данных на этих уровнях могут несколько отличаться.
Такой подход не применяется повсеместно, но многие организации, в которых
я работал, рассматривали переименование столбцов как лучшую практику для
применения согласованных схем именования на серебряном уровне, и я согласен
с таким подходом. Выполняя переименование и закрепление комментариев за
столбцами, команды данных гарантируют, что эти имена будут содержательными и в полной мере будут отражать представляемые ими данные. Таким образом
упрощается навигация по датасетам и манипуляции с ними. Также при этом
улучшается взаимодействие между участниками команд, зависящими от одних
и тех же данных; тем самым устраняется путаница и сокращается количество
ошибок в процессе обработки данных. Пример использования SQL для создания
таблицы и переименования столбцов с техническими именами на более удобные
для пользователя:
/** Создание таблицы с комментариями для пользователя **/
CREATE TABLE silver.customer (
CustomerID BIGINT COMMENT 'Customer Identifier',
FullName STRING COMMENT 'Customer Full Name',
Region STRING COMMENT 'Region Code',
SignupDate DATE COMMENT 'First Sign Up Date',

  

Серебряный уровень

);

LastLogin DATE

93

COMMENT 'Last Login Date'

/** Удобочитаемые имена таблиц и полей **/
INSERT INTO silver.customer
(CustomerID, FullName, Region, SignupDate, LastLogin)
SELECT
custID AS CustomerID,
CONCAT(f_name, ' ', l_name) AS FullName,
rgcd AS Region,
sigdt AS SignupDate,
lldt AS LastLogin
FROM
bronze.cust_data;

Переименование столбцов часто включает стандартизацию и согласование
данных в таблицах для обеспечения согласованности и надежности. Например,
данные можно скорректировать, чтобы они укладывались в нужный диапазон,
или стандартизировать категорийные данные при помощи согласованных кодов
или меток. Стандартизация такого рода на серебряном уровне способствует бесшовным преобразованиям и интеграции данных для золотого уровня, где данные
очищаются для конкретных задач бизнес-аналитики.
Использование подходящих типов данных позволяет избежать неявных преобразований типов, замедляющих запросы из-за потребления дополнительных
вычислительных ресурсов. Выбирая наиболее компактный из подходящих типов
данных, вы также сможете добиться выигрыша за счет эффективности хранения
данных.
Применение конкретных диапазонов или стандартизация категорийных
данных в таблицах серебряного уровня могут относиться к управлению
мастер-данными (Master Data Management, MDM). Операции MDM направлены на обеспечение согласованности и точности общих данных организации, часто называемых мастер-данными (master data). Стандартизация
данных в таблицах серебряного уровня соотносится с этими целями, поскольку обеспечивает однородность и надежность данных в рамках организации. Мы вернемся к MDM в разделе «Управление мастер-данными»
главы 11, с. 341.

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

  

94

Глава 3. Секреты архитектуры медальона

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

Денормализация
Чтобы оптимизировать производительность запросов в моделировании данных,
можно консолидировать данные в меньшее количество таблиц; сокращение необходимости в сложных соединениях увеличивает скорость выполнения запросов. Этот процесс часто называется денормализацией. Иногда он проводится на
серебряном уровне, еще чаще встречается на золотом. Если вы ожидаете более
частой перезагрузки и интенсивного чтения данных на серебряном уровне, лучше
использовать более денормализованную модель данных, поскольку обычно она
обеспечивает более высокую производительность.
В денормализованной модели данные организуются вокруг предметных облас­
тей, к которым часто обращаются с запросами. Это устраняет необходимость
в множественных соединениях и хорошо сочетается с распределенными и колоночными архитектурами хранения. Такой подход упрощает структуру данных,
что делает возможным быстрый доступ к необходимой информации и повышает
эффективность запросов. Вот пример денормализации данных с использованием
команды SQL:
INSERT INTO silver.customer_return
SELECT
cus.CustomerID,
cus.FullName,
c.Region,
c.SignupDate,
c.LastLogin,
st.OrderID,
st.OrderDate,
st.OrderAmount
FROM
silver.customers cus
INNER JOIN
silver.orders st
ON cus.OrderID = st.OrderID
INNER JOIN
silver.customer_details c
ON cus.CustomerID = c.CustomerID

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

  

Серебряный уровень

95

организации используют задания обслуживания и оптимизации для управления
таблицами.

SCD
Чтобы построить полный исторический протокол всех изменений со временем,
необходимо заново привести данные в форму, известную как SCD2 (Slowly
Changing Dimensions type 2). В таблицы добавляются дополнительные столбцы
(start_date, end_date, is_current и т. д.) для более эффективного отслеживания
изменений. Это сложный и нетривиальный процесс, так как само определение «изменения» сильно зависит от таблиц источника и приемника. Процесс
включает создание бизнес-ключей или генерирование хешей, поскольку они
помогают выполнять сравнения, определяющие, как обрабатывать данные
источника.
Бизнес-ключ
В моделировании данных и проектировании баз данных термином «бизнесключ» обозначается свойство или набор свойств, которые могут использоваться для однозначной идентификации бизнес-концепции или сущности.
Бизнес-ключи также часто называются натуральными ключами. Примеры
бизнес-ключей — добавление поля CustomerID или номера социального страхования в качестве первичного ключа в CRM-системах.
Хеш
В обработке данных хешем называется результат фиксированного размера,
генерируемый из входных данных произвольного размера с использованием
алгоритма хеширования. Этот уникальный результат служит цифровым «отпечатком пальца» для исходных данных.
Помните, что структура целевых таблиц влияет на этот процесс; столбцы, не
включенные в целевую таблицу, не должны входить в сравнение.
В сообществе дата-инженеров нет единого мнения относительно того, создавать
SCD на серебряном уровне или его следует зарезервировать для золотого. Большинство инженеров считают, что золотой уровень больше подходит для SCD21,
так как создание и хранение этих таблиц требует значительных затрат, а используются они обычно весьма ограниченно. Таким образом, в таблицах серебряного
уровня должны храниться в основном текущие записи.
Однако у такой точки зрения есть свои недостатки. Если на золотом уровне происходит консолидация и слияние различных источников данных, создание исторической перспективы на серебряном уровне оказывается полезным, особенно

1

Различия между SCD1, SCD2 и SCD3 обсуждаются в разделе «Методология Кимбалла»
главы 1, с. 35.

  

96

Глава 3. Секреты архитектуры медальона

если достоверный контекст источника важен. Часто так происходит при создании
моделей машинного обучения, зависящих от исторических данных в их исходном
контексте. Кроме того, для операционных отчетов поддержание исторических
данных в их исходной форме избавит от необходимости хранения рабочих данных
вблизи от источника. Это становится особенно актуальным в ситуациях, когда
организации обладают ограниченным доступом к достоверным данным в операционных системах, таких как SaaS, сервисы сторонних организаций, решения
NoSQL и т. д. В итоге решение о том, стоит ли реализовать SCD на серебряном
уровне, требует рассмотрения множества факторов и зависит от специфических
требований проекта.

Суррогатные ключи
Спор относительно SCD имеет отношение к другой дискуссии — о том, стоит
ли создавать суррогатные ключи на серебряном уровне. Суррогатный ключ
представляет собой уникальный идентификатор, назначаемый записям; он не
имеет внутреннего смысла для бизнеса, но служит для однозначной идентификации записей внутри таблицы. Суррогатные ключи обычно генерируются
либо с использованием функции автоматической нумерации, либо посредством
хеширования, либо созданием уникального идентификатора через конкатенацию
нескольких столбцов. Их главными преимуществами являются стабильность
и долговечность — они никогда не изменяются. Суррогатный ключ полезен для
отслеживания изменений в размерных атрибутах со временем, потому что его
значение не меняется даже при изменении бизнес-ключа.
Я считаю, что суррогатные ключи в норме не должны принадлежать серебряному
уровню. Они должны создаваться на последующем этапе, где данные из разных
источников объединяются для построения таблиц измерений и фактов. На этой
стадии таблицы соединяются с помощью натуральных/бизнес-ключей для поиска
и добавления суррогатных ключей. Таким образом, серебряный уровень должен
быть предназначен для очистки и улучшения представления датасета, а не для
создания суррогатных ключей.
Тем не менее если на использование суррогатных ключей во всех SCD имеются
веские причины, они могут быть реализованы как на серебряном уровне, так и на
золотом. В этом сценарии суррогатный ключ, сгенерированный на серебряном
уровне, может использоваться в качестве ключа поиска соответствующего суррогатного ключа на золотом уровне. Такой подход может быть полезен, но требует
аккуратной реализации для обеспечения согласованности и целостности данных
между уровнями.
На этом обсуждение архитектуры построения серебряного уровня подходит
к концу. Как вы узнали, в архитектуре медальона бронзовый и серебряный уровни
достаточно хорошо согласуются. Тем не менее между представлением данных
на этих уровнях существуют отличия. Например, столбцы могут быть переименованы, а данные могут пройти стандартизацию. Кроме того, используемое

  

Серебряный уровень

97

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

Гармонизация с другими источниками
Мне часто приходится отвечать на вопрос, нужна ли предварительная интеграция
источников на серебряном уровне для создания интегрированного или корпоративного представления. Решение зависит от ряда факторов.
В общем случае я рекомендую сохранять разделение для простоты управления и более четкой изоляции обязанностей. В этом случае преждевременное
слияние и интеграция данных из разных систем-источников нежелательны,
так как это может создать лишнюю связанность между приложениями. Например, пользователь, желающий получить данные из одного источника, может
оказаться непреднамеренно связан с другими системами, если данные объединяются непосредственно после загрузки на бронзовый уровень. В результате
пользователь может столкнуться с непредвиденными последствиями от работы
других систем.
Таким образом, если вы стремитесь поддерживать изолированный дизайн, интеграцию или объединение данных из разных источников лучше переместить
на золотой уровень. Такая стратегия сочетается с поддержанием четких границ
и минимизацией зависимостей между разными системами. Эта философия также
применима к сопоставлению озер-хранилищ данных с системами-источниками.
Таким образом, если вы создаете продукты данных (соотнесенные с системамиисточниками) и при этом вам важно сохранить принадлежность данных, я не рекомендую использовать раннее перекрестное соединение данных в приложениях
из различных предметных областей.
Тем не менее я также видел организации, которые предпочитают интегрировать
данные из разных источников на серебряном уровне. В этом сценарии серебряный уровень действует скорее как традиционный уровень интеграции данных,
позволяющий комбинировать и гармонизировать данные между сущностями
перед их перемещением на золотой уровень для итогового потребления. При
таком подходе обычно применяют более традиционные методы моделирования данных (такие, как 3NF или Data Vault). Рассмотрим эти модели более
подробно.

3NF и Data Vault
Концепция третьей нормальной формы (3NF), как упоминалось в разделе «Методология Инмона» главы 1, с. 33, представляет собой метод моделирования
данных, часто используемый в рабочей или транзакционной нормализации базы
данных для сокращения избыточности и зависимостей. Некоторые специалисты

  

98

Глава 3. Секреты архитектуры медальона

отдают предпочтение 3NF и другим нормализованным формам для озер-хранилищ данных за сокращение избыточности данных, лучшую адаптируемость
и согласованность данных, которые они обеспечивают.
Расширяя принципы 3NF, Data Vault представляет другой нормализованный метод моделирования данных. Он дополняет концепции 3NF такими уникальными
функциями, как концентраторы (или хабы — уникальные бизнес-ключи), ссылки
(связи данных) и сопроводительные таблицы (с подробным описанием данных).
Концепции моделирования Data Vault обычно реализуются на серебряном
уровне архитектуры медальона. На нем размещается как набор необработанных
данных (сырой Data Vault), так и уже обработанные бизнес-данные (бизнесData Vault). Сырой Data Vault содержит структурированные нормализованные
представления сырых данных, отображенные на концептуальную бизнес-модель. Он интегрирует различные источники с использованием бизнес-ключей,
обеспечивая защиту от дрейфа схем и отслеживание исторических изменений.
Серебряный уровень также включает такие элементы бизнес-Data Vault, как
гармонизация и промежуточные преобразования, которые обогащают данные
и приводят их в соответствие с определениями масштаба предприятия. PIT
(Point-in-time) и Bridge-таблицы дополнительно повышают производительность и запросы, подготавливая данные для использования на золотом уровне.
Роли бронзового и золотого уровней в такой конфигурации остаются в основном неизменными: бронзовый уровень служит областью промежуточного
хранения сырых данных, а золотой преобразует данные для бизнес-экспертизы
и аналитики.
Структура Data Vault известна своей адаптируемостью. Она отлично показывает себя в средах с частыми изменениями структур данных и бизнес-правил,
благодаря чему особенно полезна для организаций со сложными требованиями
к данным. Есть несколько причин, по которым корпорации могут выбрать 3NF
либо структуру Data Vault в своей архитектуре медальона.
Высокие требования к интеграции
Предприятия с несколькими разрозненными системами-источниками пользуются возможностью создавать унифицированные, интегрированные и согласованные модели данных с помощью модели Data Vault.
Сложные среды уровня предприятия
Организациям, работающим в нескольких предметных областях или использующим распределенные команды, необходима гибкость и модульность,
предлагаемые 3NF и Data Vault.
Быстро изменяющиеся требования и дрейф схем
Вследствие устойчивости моделей Data Vault к изменениям и их способности
адаптироваться к эволюции схем они идеально подходят для динамических

  

Серебряный уровень

99

сред, когда потребности бизнеса и технические потребности часто эволюционируют. Решая эти проблемы, Data Vault обеспечивает фреймворк для
управления и поставки качественных данных, застрахованный от проблем
с будущими изменениями.
Эффективное управление сложными временными измерениями
Модель Data Vault может эффективно управлять несколькими активными
временными линиями в одной записи (временем создания, функциональной
обработки и загрузки). Это расширяет возможности для отслеживания и понимания эволюции данных, что необходимо для аудита, комплаенса и подробного исторического анализа.
Несмотря на эти преимущества, использование 3NF или Data Vault на серебряном
уровне имеет свои недостатки. Хотя эти методы моделирования обеспечивают
улучшенную гибкость и сокращают затраты на хранение, обычно они плохо подходят для облачных архитектур данных из-за проблем с масштабируемостью.
Многие предпочитают широкие вложенные денормализованные таблицы, потому что такая конфигурация максимизирует эффективность облачной инфраструктуры. Денормализованные таблицы не требуют вычислительно затратных
соединений и перемещений данных между вычислительными узлами Spark, что
может значительно снизить производительность запросов.
Создание 3NF или Data Vault также может быть сложным процессом, отнимающим больше времени и ресурсов. Обе модели требуют глубокого понимания
отношений и зависимостей в данных, что делает необходимым тщательное
планирование и анализ. Они также должны придерживаться жестких правил
и структур для поддержания своей целостности и эффективности. Для решения
этих проблем можно рассмотреть возможность частых проверок и реализации
таких фреймворков автоматизации, как VaultSpeed (https://vaultspeed.com).
Кроме того, гибкость архитектур озер-хранилищ данных заставляет сомневаться в необходимости сильно нормализованной модели (такой, как Data Vault),
особенно если значительных изменений схемы не предполагается. Архитектура
медальона упрощает перезагрузку данных с бронзового уровня через сырые исходные таблицы, допускающие запросы, а Delta поддерживает функцию перемещения во времени, делая возможными быстрые откаты данных серебряного
уровня к предыдущим версиям данных.
Если вы хотите подробнее разобраться в этой теме, я рекомендую видео Саймона Уайтли (Simon Whiteley) о возможностях сводов данных (https://oreil.ly/
Pgtc1).

Из-за сложностей и требований таких моделей, как 3NF и Data Vault, организации часто выбирают большие денормализованные таблицы по практическим

  

100

Глава 3. Секреты архитектуры медальона

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

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

  

Серебряный уровень

101

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

Управление пересекающимися требованиями
Продолжим тему обогащения данных. Между дата-инженерами не утихают споры
о том, где применять бизнес-правила — на серебряном или на золотом уровне.
Обсуждения строятся вокруг повторного использования и стандартизации.
В общем случае я рекомендую свести к минимуму преобразования на серебряном уровне. Место бизнес-правил — на золотом уровне, предназначенном для
конечного пользователя. Это позволит выполнить настройки, соответствующие
специфическим потребностям сценария использования, и упростит управление
обновлениями и обслуживание.
Однако при таком подходе могут возникнуть затруднения, когда одна и та же
интеграция часто повторно используется разными командами. Если данные на
золотом уровне привязаны к одному исходному бизнес-подразделению, то другой
команде, которой понадобятся те же данные, возможно, придется реконструировать логику. Данное обстоятельство лишний раз подчеркивает необходимость
тщательного планирования структуры серебряного и золотого уровней и выбора
места для обогащения и преобразования данных. Мы вернемся к теме структуры
при обсуждении курируемых и семантических уровней на золотом уровне.

Задачи автоматизации
Ключ к масштабированию лежит в автоматизации большинства задач. Тем не
менее важно понимать, что не все действия по обработке на разных уровнях архитектуры медальона легко стандартизировать или автоматизировать.
Когда речь заходит об автоматизации, при использовании разных инструментов и фреймворков приходится учитывать разные факторы. Как показано на
рис. 3.3, переход данных из источника на бронзовый уровень создает особенно
много проблем. Сложности возникают из-за различий в технологиях и сторонних решениях на стороне системы-источника. Некоторые компании — производители ПО могут использовать для извлечения данных уникальные API
или проприетарные сервисы, что может привести к различиям в форматах
данных. Например, если производитель поддерживает только экспортирование
в формате CSV, то адаптация процессов для поддержки этого формата просто
необходима.

  

102

Глава 3. Секреты архитектуры медальона

Трудно автоматизируемые Легко автоматизируемые

Трудно параметризуемые

Pull

Системыисточники

Push

Бронзовый

Серебряный

Золотой

Сценарии
использования

Рис. 3.3. Сравнение легко автоматизируемых стадий с этапами сложной обработки
в архитектуре медальона
После того как вы проведете первые преобразования и данные будут доступны
в стандартизированном (Delta Lake) формате на бронзовом и серебряном уровнях, можно переходить к дальнейшей стандартизации и автоматизации. На этом
этапе начинают играть важную роль инструменты и фреймворки, управляемые
метаданными, которые делают обработку более оптимизированной и автоматизированной. Это помогает обеспечить максимальную масштабируемость и эффективность в архитектуре обработки данных.
Вернемся к рис. 3.3. Переход от бронзового уровня к серебряному обычно более простой по сравнению с переходом от системы-источника к бронзовому.
На этой стадии преобразования обычно прогнозируемы и относительно просты; они включают такие задачи, как переименование столбцов, применение
фильтров, исправление проблем с качеством данных, использование таблиц
поиска и присваивание значений по умолчанию. Благодаря прогнозируемой
природе этот этап инженерии данных проще параметризуется, что повышает
эффективность и управляемость1. Соответственно, многие организации используют фреймворки, управляемые метаданными, с общими скриптами и/или
блокнотами.
Эти фреймворки позволяют определять задачи инженерии данных на декларативном уровне. Важнейшие элементы: информация схемы, правила качества
данных, натуральные и бизнес-ключи, правила отображения — хранятся в репозитории метаданных. Затем этот репозиторий используется для автоматического генерирования кода преобразования. Простое обновление метаданных
способствует преобразованиям, которые значительно автоматизируют процесс
инженерии данных.
Среди фреймворков, заслуживающих внимания, стоит выделить dbt — упоминавшийся ранее инструмент командной строки с открытым исходным кодом.
Его сильной стороной являются преобразования, определяемые по шаблонам,
1

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

  

Серебряный уровень

103

с синтаксисом, сходным с командами SELECT в SQL. Другой декларативный
фреймворк инженерии данных, на который стоит обратить внимание (особенно
при работе в среде Databricks), — Delta Live Tables (DLT). Он не только упрощает
преобразования, но и управляет оркестрацией задач, кластерами, мониторингом,
качеством данных и обработкой ошибок.
На рис. 3.3 завершающий этап включает поставку очищенных данных потребителям на основании их специфических требований. Этот этап трудно параметризовать, прежде всего из-за сложной бизнес-логики, которая часто необходима
для интеграции и которую бывает трудно выразить одними метаданными. Тем
не менее применение шаблонов и сервисов позволяет частично стандартизировать рабочие процессы. Это упрощает процесс, повышая его эффективность
и управляемость.
Для создания масштабируемого фреймворка очень важно понимание и управление вариациями на разных этапах инженерии данных. Эффективно применяя
средства автоматизации и фреймворки, организации могут оптимизировать
свои пайплайны обработки данных, обеспечивая их надежность и адаптируемость.

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

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

  

104

Глава 3. Секреты архитектуры медальона

Если вы хотите и определиться с принадлежностью данных и наладить интеграцию, рассмотрите возможность создания отдельных уровней: один для очищенных
данных, ориентированных на систему-источник, и другой для гармонизированных. Какой бы подход вы ни выбрали, важно поддерживать каждый уровень в чистом и согласованном состоянии. На рис. 3.4 показано, как серебряный уровень
может выглядеть на практике.
Бронзовый уровень
(сырые копии)

Источники

OLTPсистемы
ERPсистема

Посадочная
зона
Репозиторий
больших
двоичных
файлов

Сырые экспор- Проверенные
таблицы
тированные
Delta
данные (CSV)

Очищенные
и согласованные
таблицы

Историзированные
таблицы

Сырые экспор- Проверенные
тированные
таблицы
данные
Delta
(Parquet)

Очищенные
и согласованные
таблицы

Историзированные
таблицы

Сырые экспор- Проверенные
таблицы
тированные
Delta
данные (JSON)

Очищенные
и согласованные
таблицы

Историзированные
таблицы

Граница области управления

CRMсистема

Kafka

Серебряный уровень
(отфильтрованные,
чистые, дополненные данные)

Золотой
уровень
(данные,
смоделированные для
потребления)
Основное
внимание
к производительности
и масштабируемости данных,
позволяющим
быстро получать выводы
бизнесаналитики

Рис. 3.4. Возможная структура серебряного уровня на практике
Серебряный уровень обычно воспроизводит бронзовый и содержит точное представление данных, но с некоторыми важными улучшениями: таблицы очищены,
а данные стандартизированы. Эта простая конфигурация обычно удовлетворяет
большинство потребностей организаций, обеспечивая согласованность и удобство
использования данных. Тем не менее архитектуру серебряного уровня можно
настраивать в зависимости от сложности данных, количества задействованных
источников и специфических требований организации к производительности
и гибкости. Такая адаптируемость позволяет серебряному уровню не только
удовлетворять текущие потребности в обработке данных, но и масштабироваться
и эволюционировать для будущих потребностей.
На следующем уровне — золотом — очищенные и организованные данные приводятся к форме, наиболее ценной для бизнеса. Здесь данные преобразуются в аналитику, которая становится основанием для действий и напрямую поддерживает
процессы принятия решений. Операции на золотом уровне сложны, поскольку
включают нетривиальные методы моделирования и агрегирования данных, а также применение бизнес-логики, соответствующей стратегическим целям.

  

Золотой уровень

105

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

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

  

106

Глава 3. Секреты архитектуры медальона

Ясность и релевантность для бизнес-пользователей имеют решающее значение.
Даже если модель данных обладает выдающейся производительностью, она вряд
ли будет успешной, если не соответствует тому, как пользователи концептуализируют свою предметную область и ориентируются в ней. Если бизнес-пользователи
считают модель неподходящей для препарирования и анализа данных в соответствии с их повседневными бизнес-процедурами, она не будет эффективной.
При проектировании модели данных на первый план выходит структура, отражающая интуитивную ментальную модель конечного пользователя: схема «звезда».
Она получила свое название по форме — в центре таблица фактов, с которой
соединяются таблицы измерений. Это гарантирует, что модель данных будет не
только эффективна, но и доступна и что она обладает ценностью для тех, кто использует ее с целью принятия обоснованных бизнес-решений.
Чтобы разработать схему «звезда», необходимо сначала понять бизнес-требования, а для этого придется пообщаться с ключевыми стейкхолдерами, чтобы
узнать их потребности и ожидания. Затем объявляется гранулярность схемы,
которая определяет уровень подробностей в таблицах фактов и таблицах измерений и обес­печивает возможность их соединения. Уровень гранулярности также
определяет, какие операции агрегирования необходимы.

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

  

Золотой уровень

107

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

Загрузка таблиц измерений
Загрузка таблиц измерений в схеме «звезда» усложняется необходимостью обрабатывать SCD — это пошаговый процесс, включающий сравнение входных
данных с существующими данными в таблице измерений. Это сравнение помогает выявлять новые или измененные данные, управлять суррогатными ключами
и выполнять вставку или обновление размерных записей.
На этом шаге обработки SCD процесс ETL сканирует существующую таблицу
измерений в поисках соответствующего бизнес-ключа. Если совпадение найдено,
процесс обновляет существующую запись и вставляет новую запись с обновленной информацией. Если совпадение не найдено, процесс вставляет новую
запись и назначает новый суррогатный ключ. Если бизнес-ключи из разных
источников пересекаются, необходимо сделать корректировки. Использование
идентификаторов системы-источника — эффективный способ управления такими
пересечениями.
Важно гармонизировать данные перед вставкой записей в таблицы измерений.
Процесс включает преобразование данных к общему формату. Каждая системаисточник анализируется для выявления общих атрибутов и значений — задача,
часто требующая значительных бизнес-знаний. В процессе гармонизации может
потребоваться реорганизация, очистка и исправление: расшифровка кодов, разбиение атрибутов, состоящих из нескольких частей, замена null-полей обязательными значениями и т. д.
После гармонизации записи готовы к вставке в таблицу измерений. Процесс может состоять из нескольких переходов или этапов. Как правило, данные сначала
загружаются во временную таблицу, а затем переносятся в таблицу измерений.
Этот многоэтапный подход помогает обеспечить целостность и согласованность
данных в таблице измерений схемы «звезда».

Загрузка таблиц фактов
Загрузка таблиц фактов в схеме «звезда», хотя на первый взгляд и проще загрузки таблиц измерений, все еще сопряжена с определенными трудностями.
1

Мы вернемся к этой теме в части III с более конкретными примерами.

  

108

Глава 3. Секреты архитектуры медальона

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

В процессе загрузки могут возникнуть ситуации, когда некоторые отношения
между измерениями и фактами в таблице невозможно установить. Это называют преждевременным фактом (early arriving fact). В таких случаях приходится
создавать записи-заполнители. Они встают на место отсутствующих записей
и помогают поддерживать целостность отношений между таблицами измерений
и таблицами фактов, обеспечивая правильное функционирование схемы «звезда».

Оптимизация загрузок
При загрузке схемы «звезда» возможно появление узких мест, например, слишком большое время поиска, из-за которого пользователям приходится подолгу
ожидать. Для решения этих проблем можно оптимизировать обработку данных,
встраивая в таблицы административные столбцы. Например, добавление столбцов
вида type1_hash и type2_hash может оптимизировать обнаружение изменений
типа 1 и 2 в процессе ETL.
В модели SCD1 старое значение перезаписывается новым, а история не ведется. Модель SCD2 сохраняет как текущие, так и исторические записи
в одном файле или таблице.

Кроме того, включение таких столбцов, как creation_date (дата создания) или
update_date (дата изменения), упрощает выявление новых данных и изменение

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

Особенности проектирования схем «звезда»
Управление процессом ETL и создание схемы «звезда» — сложный процесс,
полный нюансов; в предыдущих разделах были представлены лишь некоторые его базовые концепции. При построении собственной схемы «звезда» вы

  

Золотой уровень

109

столк­нетесь с некоторыми особенностями проектирования, свойственными
этому подходу. Вероятно, вы обнаружите, что процесс необходимо разделить
на несколько подэтапов, и то, что изначально выглядит как единый золотой
уровень, будет эволюционировать и становиться все более сложным с течением
времени.
Метод разработки схем «звезда» от Кимбалла, по сути, является набором принципов проектирования. Он предоставляет рекомендации и общие правила, которые вы или ваши разработчики должны соблюдать. Тем не менее различные
организации управляют своими моделями совершенно по-разному. Рассмотрим
некоторые альтернативные подходы, чтобы дать вам более полное представление
о возможных вариантах.

Курируемые, семантические и платиновые уровни
Хотя реализация схемы «звезда» с фактами и измерениями является популярной стратегией для золотых уровней, такие схемы могут усложняться с расширением размерных моделей и подключением новых источников данных.
Этот рост часто приводит к пересечению требований — сходных, но достаточно
отличающихся для того, чтобы для них требовались разные методы проектирования, которые теоретически могут изменить дизайн золотого, а иногда даже
серебряного уровня.
Например, некоторые организации могут добавлять дополнительные согласованные или курируемые (curated) уровни с отдельными (семантическими)
уровнями для витрин данных, использующих схемы «звезда». Иногда эти дополнительные уровни называются платиновыми, что подчеркивает их специа­
лизированную природу и высокую степень чистоты. В таких конфигурациях
часто применяется определенная модель данных организации, например создание стандартных классификационных таблиц и согласованных измерений,
которые затем могут использоваться разными витринами данных в более
крупной архитектуре озера-хранилища. Хотя такой подход считается сложным
и затратным по времени, он остается популярным, поскольку гарантирует возможность повторного использования данных и стандартизацию между разными
подразделениями организации.
У решений с изменением дизайна золотого уровня имеются свои особенности, на
которые влияют такие факторы, как размер организации, количество систем-источников, предназначенных для интеграции, требования к семантическим моделям и специфические требования потребителей. Каждый из этих факторов может
значительно изменить реализацию стратегии моделирования данных и способ ее
существования, из-за чего этот подход необходимо адаптировать к специфическим требованиям и возможностям организации. А теперь рассмотрим другой
метод проектирования, упрощающий модель данных.

  

110

Глава 3. Секреты архитектуры медальона

Метод OBT
Хотя схемы «звезда» могут быть очень полезными, их проектирование требует
больших усилий. По этой причине некоторые предпочитают реализовывать метод
«одной большой таблицы» (OBT, one big table) за его простоту и скорость, которые
могут перевесить соображения гибкости и расширяемости.
В рамках OBT все данные, актуальные для анализа или текущих операций,
хранятся в одной большой таблице. Этот метод не предполагает распределения
данных по нескольким таблицам или их организации в более сложные схемы, например «звезда» или «снежинка». Такой подход может быть предпочтительным
по нескольким причинам.
Простота управления
Решения OBT просты в управлении и легки для понимания, особенно для
тех, кто не является специалистом в хранилищах данных. Такая простота
может оказаться преимуществом для небольших команд или проектов, когда
сложность может создавать значительные затраты времени и усилий. Некоторые специалисты отмечают, что поддержка одной большой таблицы может
сократить затраты, связанные с управлением несколькими таблицами и отношениями в схеме «звезда». Это упрощает управление данными и снижает
затраты как времени, так и ресурсов.
Повышение производительности
Для некоторых типов запросов, особенно не требующих агрегирования больших объемов данных из разных измерений, одна большая таблица способна
обеспечить более высокую производительность. Устранение соединений,
необходимых в схеме «звезда», значительно ускоряет выполнение запросов.
Гибкость схемы
Метод OBT предоставляет гибкую схему, которую проще изменить и расширить по сравнению с более жесткой схемой «звезда». Это может быть ­особенно
полезно в динамичных средах с быстро изменяющимися бизнес-требованиями,
когда необходимы оперативные изменения в модели данных.
Популярность у специалистов
Дизайны с одной большой таблицей также могут быть предпочтительными
для специалистов data science, работающих с инструментами, которые требуют данных в одном неструктурированном формате. Кроме того, дизайн OBT
удобен для преобразования данных в датасеты на основе векторов или графов
для моделирования.
Удобство для долгосрочного анализа
Для датасетов, по своей природе требующих отслеживания изменений во
времени (например, данных продаж или пользовательской активности), одна

  

Золотой уровень

111

большая таблица может упростить анализ временных рядов. Аналитики могут
наблюдать исторические тенденции и делать прогнозы на будущее на основании непрерывного потока данных.
Казалось бы, хранение всех данных в одной таблице упрощает ее структуру, но
оно также может усложнить создание запросов для получения осмысленных выводов. Рассмотрим конкретный пример.
Возьмем таблицу заказов Orders. Вместо распределения данных по нескольким
реляционным таблицам все данные хранятся в одной таблице с несколькими
столбцами: OrderID, OrderDate, CustomerID и Products. В этой таблице столбец
Products содержит вложенный массив данных, хранящий один или несколько
товаров, связанных с каждым заказом. Пример:
OrderID: 5687
OrderDate: 2024-11-15
CustomerID: 112233
Products: [
{
"ProductID": 101,
"ProductName": "Apple iPhone 15 Pro",
"Quantity": 2,
"Price": 1299.99
},
{
"ProductID": 205,
"ProductName": "Dell XPS 15",
"Quantity": 1,
"Price": 1899.99
}
]

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

  

112

Глава 3. Секреты архитектуры медальона

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

Сервисный уровень
До сих пор мы обсуждали дизайн и моделирование данных для озера-хранилища, включая различные уровни. Реализуя архитектуры, особенно работая
с золотым уровнем, возможно, вы сочтете необходимым реплицировать данные
между другими типами баз данных, помимо озер-хранилищ, с использованием
таблиц Delta. В этом сценарии данные передаются с курируемого или презентационного уровня из озера-хранилища другим сервисам, таким как Azure
Data Explorer (https://oreil.ly/8fqSY), Azure SQL (https://oreil.ly/VqC6d), сервисам
графовых баз данных и т. д. Такое перемещение упрощает доступ к данным для
конечных пользователей и обслуживает разнообразные потребности бизнеснаправлений.
Для примера возьмем подразделение организации, хорошо освоившее Azure SQL.
Его сотрудники разработали приложения и используют средства создания отчетов, зависящие от данных, хранящихся в базах данных Azure SQL. Вместо того
чтобы поручить центральной команде управлять данными в озере-хранилище, это
подразделение управляет данными в собственной среде. Оно переносит данные
из озера-хранилища в базу данных Azure SQL, фактически создавая «витрину
данных». Это экономит время подготовки данных для подразделения, позволяя
сосредоточиться на извлечении более глубоких выводов непосредственно из
данных. Более подробную информацию см. в блоге Джеймса Серра (James Serra)
Serving Layers with a Data Lake (https://oreil.ly/66tgp).
Нечто похожее часто можно наблюдать с инструментами создания отчетов. Например, Power BI, широко используемый инструмент создания отчетов, может
напрямую подключаться к таблицам Delta в озерах-хранилищах. При этом многие
организации выбирают режим Import в Power BI для обеспечения последовательной производительности и детализированных средств настройки безопасности.
В режиме Import Power BI реплицирует данные из озера-хранилища в свое ядро
в памяти, называемое VertiPaq1. Это повышает производительность запросов и эффективность извлечения данных, что особенно полезно при работе с большими
датасетами в модели создания отчетов.
В архитектурах озера-хранилища данных часто используются разнородные
технологические сервисы для эффективного удовлетворения различных
1

VertiPaq — ядро столбцового хранения данных в памяти, используемое Microsoft Power
BI, а также рядом других продуктов Microsoft, включая Analysis Services и Excel Power
Pivot.

  

Золотой уровень

113

потребностей. Типичная архитектура озера-хранилища включает бессерверные
вычисления для ситуативных запросов, Spark для обработки больших данных
и таблицы Delta, в которых хранится основной объем данных. Кроме того, могут
применяться реляционные базы данных для выполнения сложных запросов;
базы данных временных рядов для работы с IoT (интернетом вещей) и потоковым анализом; средства создания отчетов, такие как Power BI, для упрощения
аналитики и визуализации. Решение о дополнении золотого уровня уровнем,
использующим другие технологии баз данных, часто принимается с учетом
удобства использования, совместимости с другими сервисами, гибкости, производительности и затрат.
Такая конфигурация дополнительных баз данных встречается во многих организациях. Она демонстрирует, что архитектура озер-хранилищ данных достаточно
универсальна и может адаптироваться под специфические потребности. Важно
понимать, что архитектура озер-хранилищ предоставляет не «решения на все
случаи жизни», а скорее гибкую основу, способную учитывать разнообразные
потребности различных организаций.

Золотой уровень на практике
Золотой уровень архитектуры медальона играет важнейшую роль в оптимизации
данных для принятия решений и высокопроизводительной аналитики. Здесь
важно обеспечить тесное совмещение с управлением данными (data governance)
для обеспечения комплаенса, целостности и безопасности. Все датасеты следует
документировать и каталогизировать, сохраняя прозрачность относительно
использования и сегментации данных под конкретные сценарии. Четкое определение ролей и обязанностей в этой модели также способствует подотчетности
и соблюдению лучших практик. Мы вернемся к некоторым из этих концепций
в главе 11.
Структура данных, хранящихся на золотом уровне, должна быть простой, очевидной и оптимизированной для чтения (см. раздел «Управление таблицами
Delta» в главе 2, с. 67). Их конфигурация должна подходить для разных сценариев использования. Чтобы спроектировать эффективную модель на этом
уровне, необходимо совмещать технические стратегии с потребностями бизнеса.
В итоге это приведет к появлению дополнительных физических (под-)уровней,
изображенных на рис. 3.5.
Организации, стремящиеся достичь конкурентного преимущества в сфере,
управляемой данными, получают его благодаря гибкости, предоставляемой
разными методами моделирования. Хотя освоить множество разных форматов — задача не из простых, ваши потребители выиграют от возможности
полностью использовать свои информационные ресурсы, применяя наиболее
подходящую модель.

  

114

Глава 3. Секреты архитектуры медальона

Источники

OLTPсистемы
ERPсистема

Бронзовый уровень
(сырые копии)

Серебряный уровень
(отфильтрованные,
чистые, дополненные
данные)

Сырые экс- Проверенпортированные данные ные таблицы Delta
(CSV)

Очищенные Историзии согласован- рованные
ные таблицы таблицы

Сырые экс- Проверенпортированные данные ные таблицы Delta
(Parquet)

Очищенные Историзии согласован- рованные
ные таблицы таблицы

Сырые экс- Проверенпортированные данные ные таблицы Delta
(JSON)

Очищенные Историзии согласован- рованные
ные таблицы таблицы

Посадочная
зона
Репозиторий
больших
двоичных
файлов

Золотой уровень
(данные, смоделированные для
потребления)
OBT

Курируемые
данные

Витрины

Граница области управления

CRMсистема

Kafka

OBT

Курируемые
данные

Витрины
Витрины

Облачный
Секциониру- Очищенные Не обязательно: Соединяемые
Данные
репозиторий
ется
и согласованSCD2,
между
относятся
для больших и сохраняется ные со стан- конструирова- источниками: к приложедвоичных
в нативном
дартами
ние признаков гармонизиро- ниям, то есть
объектов,
формате
предметной
и т. д.
ванные
семантиченапример
озера-храниобласти
и денормали- ским уровням
ADLS
лища
зованные

Рис. 3.5. Возможная структура золотого уровня на практике

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

Таблица 3.1. Обзор уровней архитектуры медальона
Уровень

Назначение

Модель
данных

Применяемые
преобразования

Формат файлов
и таблиц

Технология ETL

Посадочная
зона

Посадочная
зона для
сырых данных
из системисточников

Сырые данные,
как в источнике

Отсутствуют

Форматы
файлов для
передачи: CSV,
Parquet, JSON
и т. д.

Azure Data
Factory, Kafka,
Auto Loader,
Azure Event
Hubs, Databricks
LakeFlow
Connect

  

Заключение

115

Уровень

Назначение

Модель
данных

Применяемые
преобразования

Формат файлов
и таблиц

Технология ETL

Бронзовый

Представление
проверенных
сырых данных
с использованием стандартизированных
табличных
форматов

Схема
системыисточника

Минимум (например, применение фильтров
и добавление
метаданных)

Платформенный формат
озера-хранилища (например,
Delta Lake или
Iceberg)

SQL, Python
c фреймворками (такими,
как DLT)

Серебряный

Чистая, историзированная
и оптимизированная для
чтения версия
(хотя все еще
ориентированная на
источник)

Разные:
повторение
бронзового
уровня, предметно-ориентированная,
3NF или Data
Vault

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

Платформенный формат
озера-хранилища (например,
Delta Lake или
Iceberg)

SQL, Python
c фреймворками (такими, как
dbt или Great
Expectations)

Золотой

Оптимизация
для создания
ценности

Моделирование данных по
Кимбаллу или
OBT

Гармонизированные,
агрегированные
и с применением
сложной бизнеслогики

Платформенный формат
озера-хранилища (например,
Delta Lake или
Iceberg)

SQL, Python
c фреймворками (такими,
как dbt),
семантические
модели

Но почему архитектура медальона так важна для стратегии данных организации?
И какие убедительные выводы можно сделать из этого путешествия? Ответ кроется в ее гибком модульном подходе, который позволяет организациям приспособить свои процессы, связанные с данными, к конкретным потребностям. Хотя
концепция трех отдельных уровней предлагает структурированное решение, она
не универсальна. Важно понимать возможности и ограничения каждого уровня,
которые можно адаптировать, чтобы они лучше соответствовали условиям эксплуатации и стратегическим целям.
Чтобы воспользоваться этой гибкой иерархией, необходимо осознать важность
определения стандартов в масштабе организации. Гибкость необходима, но
четкие стандарты должны служить инженерам руководством для обеспечения
согласованности и эффективности. С учетом неоднозначности в ролях уровней
и отсутствия четких отраслевых определений очень важно понимать возможности
каждого уровня, то, как выполняется проверка данных на каждой стадии, а также точные роли и обязанности в архитектуре, чтобы поддерживать надежность
стратегии данных. Мы вернемся к этим темам в части IV.

  

116

Глава 3. Секреты архитектуры медальона

Организации, изначально принявшие такие нестандартные модели, как Data
Vault, иногда испытывают проблемы производительности, тогда как организации,
поставившие на первое место производительность и применяющие более простые
модели (такие, как OBT), часто сталкиваются с негибкостью. Эти примеры показывают, что эффективная архитектура данных требует динамичного подхода,
сочетающего производительность с гибкостью. Дело даже не в выборе модели,
а в том, чтобы обеспечить итеративные уточнения и корректировки для удовле­
творения как текущих, так и будущих потребностей. Чтобы достичь такого баланса, организации должны стараться определить четкие стандарты моделирования
данных в отношении того, чего ожидать от каждого уровня. Так они могут быть
уверенными, что их данные обрабатываются эффективно и могут адаптироваться
и использоваться в соответствии с эволюционирующими бизнес-ожиданиями.
Продолжим исследование архитектуры медальона на практическом примере
с учетом всех рассмотренных лучших практик и факторов. Этот опыт поможет
глубже понять, как бронзовый, серебряный и золотой уровни применяются в реальных условиях, и даст ценную информацию о моделировании данных и сложностях архитектуры. В следующей главе мы начнем с создания необходимой
инфраструктуры для реализации архитектуры медальона с использованием таких
сервисов, как Microsoft Fabric.

ЧАСТЬ II

Построение
уровней медальона
Во второй части книги мы переключимся с теоретических основ на практическое
применение. Эта часть посвящена тому, чтобы сделать теорию действенной. Она
представляет собой комплексное практическое руководство, которое шаг за шагом
проведет вас через сквозной процесс построения архитектуры медальона.
Работая с примерами и фрагментами кода, вы примените полученные знания
в реальном контексте. Это поможет наглядно представить рассмотренные ранее концепции и углубить понимание каждого уровня архитектуры. Применяя
инструменты и методы, вы получите ценное представление о практических проблемах и пользе от реализации надежной структуры данных.
В главе 4 мы настроим необходимую инфраструктуру для реализации архитектуры медальона. Вы узнаете, как определить конфигурацию Microsoft Fabric
для поддержки архитектуры. На информации из этой главы строится материал
последующих глав.
В главе 5 мы начнем практическое изучение архитектуры медальона и реализуем
бронзовый уровень с применением Microsoft Fabric. Этот фундаментальный уровень очень важен; он включает настройку загрузки исходных данных и предварительных стадий обработки. Мы рассмотрим лучшие практики и ключевые условия
эффективного построения бронзового уровня, который является фундаментом
для более структурированных серебряного и золотого уровней.
В главе 6 мы сосредоточимся на создании серебряного уровня. Мы продолжим
использовать Microsoft Fabric для преобразования данных с бронзового уровня
в более структурированный формат, оптимизированный для запросов и анализа.
В этой главе рассматриваются такие критически важные процессы, как проверка
и очистка данных для улучшения их качества и надежности, чтобы подготовить
их для сложных задач аналитики. Кроме того, в ней обсуждается использование
Apache Airflow для оркестрации пайплайнов данных.
Наконец, глава 7 описывает переход к золотому уровню. Мы исследуем продвинутые методы агрегирования данных и создания отчетов, позволяющие получать качественные аналитические выводы, на основе которых принимаются бизнес-решения.

ГЛАВА 4

Строим основу архитектуры медальона
с посмощью Microsoft Fabric

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

Почему мы будем в основном использовать решения, портируемые и не привязанные к конкретному разработчику технологий? В настоящее время не хватает
практичных общедоступных примеров реализации сквозных архитектур медальона. Многие материалы либо чересчур теоретичны и обобщенны, либо уделяют
внимание какой-то одной стороне, что усложняет применение этих концепций
в реальных сквозных сценариях. Я намерен заполнить этот разрыв между теорией
и практикой в подробном пошаговом описании реализации.
В нашем упражнении будет в основном использоваться Microsoft Fabric. Хотя
существуют и другие сервисы, с Microsoft Fabric вы получите навыки и фундаментальное понимание, которое легко перенести на другие платформы.
Инновации рождаются очень быстро, а сервисы и функции постоянно изменяются. Поэтому я буду ориентироваться на сервисы, проверенные временем,

  

Пример: Oceanic Airlines

119

и портируемую функциональность, которая вряд ли изменятся в будущем. К примеру, возьмем Apache Airflow, (Azure) Data Factory, Spark, PySpark и методы,
управляемые метаданными. Эти инструменты универсальны и могут применяться
в разных конфигурациях. Таким образом, навыки, полученные благодаря прочтению книги, можно применить и с другими провайдерами решений. Собственно,
я протестировал все фрагменты кода в книге с другими сервисами на базе Spark
и Delta Lake, и они отлично работали.
Весь путь обучения также можно пройти с Azure Databricks. Подробные
инструкции по настройке, включая информацию об использовании Unity
Catalog, доступны в моем блоге (https://oreil.ly/Z7JS7), а при желании вы можете перейти сразу к главе 5.

Какой бы путь вы ни выбрали, наш подход к изложению в основном нейтрален
по отношению к поставщику. Таким образом, принципы, лучшие практики
и фрагменты кода, которые будут рассматриваться, будут применимы к другим
продуктам, использующим технологии Spark и Delta Lake. Связующей нитью
для них служит архитектура медальона.
Работа над примером в этой главе начнется с создания фундаментальной инфраструктуры, а затем мы последовательно построим каждый уровень в главах 5, 6 и 7, начав с бронзового, перейдя на серебряный и завершив золотым
уровнем.
Тем не менее это руководство не ограничивается простыми инструкциями; после
каждой серии шагов мы будем делать небольшую паузу для размышлений. В этих
паузах мы обсудим различные вопросы, включая место архитектуры медальона
в более широком контексте, альтернативные решения и многое другое, что расширит ваши знания.

Пример: Oceanic Airlines
В этом обсуждении архитектур медальона будет использоваться пример с вымышленной компанией Oceanic Airlines. Компания, известная обширной полетной сетью, взялась за переработку своей системы управления данными и строит
современную архитектуру на базе озер-хранилищ данных.
Инициатива началась с серии бизнес-семинаров с участием стейкхолдеров
из разных подразделений, включая IT, службу эксплуатации, отдел по работе
с клиентами и финансовый отдел. Эти семинары помогли выявить конкретные
потребности и ожидания, относящиеся к данным новой архитектуры. После тщательной оценки разных вариантов компания Oceanic Airlines решила реализовать
Microsoft Fabric в дизайне, показанном на рис. 4.1.
Мы рассмотрим развертывание и настройку Microsoft Fabric, особенности дизайна
и лучшие практики эффективной загрузки данных на бронзовом уровне. Этот

  

120

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

пошаговый метод позволит создать надежный фундамент вашей архитектуры
данных.

Управление данными с помощью Microsoft Purview
SQL

Метахранилище

Обработка
Инженерия данных Synapse (Spark)
Операционные
системы
Посадочная
зона для
Blobобъектов

Загрузка
данных
средствами
Data Factory

Bronze
(Lakehouse)

Silver
(Lakehouse)

Gold
(Lakehouse)

Предоставление
услуг

Отчеты
Data
science

Оркестрация с использованием Airflow
Рис. 4.1. Высокоуровневая схема с предложенной архитектурой

Знакомство с Microsoft Fabric
Microsoft Fabric — платформа данных и аналитики на базе модели SaaS. Она
предоставляет среду совместной работы для инженеров, специалистов data
science и бизнес-аналитиков. Она поддерживает такие популярные технологии,
как Apache Spark и Delta Lake.
Как и многие другие сервисы данных, платформа включает управляемый вебинтерфейс и интегрируется с некоторыми другими сервисами, такими как
Microsoft Entra ID (https://oreil.ly/lZpx-). Например, интеграция с Microsoft Entra ID
позволяет пользователям входить в Microsoft Fabric через персональную учетную
запись. Эту функцию можно настроить, чтобы она требовала многофакторной
аутентификации и других мер безопасности.
На рис. 4.2 изображен начальный экран Microsoft Fabric, открывающий доступ ко
всей функциональности платформы. Рассмотрим основные компоненты Microsoft
Fabric, начиная с доменов, рабочих пространств и емкостей.

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

  

Знакомство с Microsoft Fabric

121

Microsoft Fabric использует домены (https://oreil.ly/8hiYk) для упрощения перехода
от централизованного управления данными к децентрализованному.

Рис. 4.2. Возможности Microsoft Fabric по преобразованию данных, анализу и генерированию аналитики,
а также визуализации и отчетов
В Microsoft Fabric можно сгруппировать все актуальные артефакты и данные в домене, который обычно соответствует конкретному бизнес-юниту организации —
отделу, бизнес-проекту и т. д. Например, отдельные домены могут существовать
для продаж, финансов и маркетинга, и каждый поддерживает изоляцию для
обеспечения целостности и безопасности данных.
Важно знать, что домены служат наивысшим уровнем абстракции в Microsoft
Fabric, работая в модели делегирования. Эта модель позволяет каждому бизнесюниту установить собственные правила и ограничения, адаптированные для его
потребностей. Группировка данных по доменам подразумевает их связывание
с рабочим пространством (Workspace) и емкостью, или вычислительной мощностью (capacity)1.

Рабочие пространства и емкости
Рабочие пространства (Workspaces) (https://oreil.ly/lKfxc) в Microsoft Fabric представляют собой среды совместной работы для специалистов, взаимодействующих
1

В русскоязычной литературе и документации Microsoft Fabric термин capacity переводят
как емкость, пул ресурсов, вычислительная мощность и т. д. В официальной документации Microsoft Learn используется перевод «емкость». — Примеч. пер.

  

122

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

с данными. Они предназначены для создания и совместного использования различных объектов, включая озера-хранилища, хранилища данных, блокноты и отчеты. Каждое рабочее пространство соединяется с одним доменом, предоставляя
общую область для доступа к артефактам конечным пользователям. Пользователи
взаимодействуют с ними при помощи сервисов наподобие Power BI, где можно
создавать дашборды и отчеты и работать с этими дашбордами. Способ сотрудничества и обмена данными, ориентированный на рабочее пространство, аналогичен
подходу, используемому в других сервисах, таких как Azure Databricks и Synapse
Analytics.
На стороне инфраструктуры каждое рабочее пространство связывается с емкостью (capacity) (https://oreil.ly/SCi_h) — универсальным пулом (бакетом) вычислений. В Microsoft Fabric емкости также выполняют роль лицензий, которые
распределяют эти пулы ресурсов для поддержки вычислительных потребностей
различных операций. Иначе говоря, вы приобретаете определенный объем вычислительных мощностей, измеряемый в единицах емкости (capacity units, CU).
Емкости могут иметь разные размеры и конфигурации (Fabric SKU, Stock
Keeping Units): F2, F16, F64 и т. д. — и следуют разным моделям подписки, например, собственно подписки или оплаты по мере использования (pay-as-you-go)
(вы создаете емкость, запускаете рабочую нагрузку, а затем приостанавливаете
емкость). Эти емкости, размещенные в вашем арендаторе Azure, находятся под
полным управлением Microsoft; это означает, что нижележащие виртуальные
машины невидимы для пользователей. Емкости могут назначаться одному или
нескольким рабочим пространствам, как показано на рис. 4.3.

Арендатор
Azure

Емкость
Fabric

Рабочее
пространство
Fabric

Емкость
Fabric

Рабочее
пространство
Fabric

Рабочее
пространство
Fabric

Домен Fabric
Рис. 4.3. Отношения между арендатором Azure, емкостями Fabric и рабочими пространствами Fabric
В следующем разделе рассматривается OneLake — концепция общего хранения,
появившаяся в Microsoft Fabric.

  

Знакомство с Microsoft Fabric

123

OneLake
OneLake — основной уровень хранения в Microsoft Fabric. Для хранения данных
этот уровень использует Azure Data Lake Storage (ADLS) Gen2, при этом по
умолчанию используется формат таблиц Delta.
При включении Fabric на уровне арендатора OneLake автоматически становится
доступным для всех рабочих пространств, позволяя разным рабочим нагрузкам
легко обращаться к одним и тем же данным. Это особенно удобно для вычислительных ядер Lakehouse и Warehouse, использующих для хранения данных
формат Delta. Уровень хранения также интегрируется с Power BI для анализа
больших датасетов, гарантируя, что все инструменты — от Apache Spark до Power
BI — смогут взаимодействовать без необходимости дублирования данных. Это
означает, что когда дата-инженер создает таблицу Delta в Lakehouse, разработчик
Power BI может тут же обратиться к ней для получения отчета.
OneLake также представляет упрощенный уровень виртуализации данных, позволяющий создавать ярлыки, или ссылки (shortcuts) (https://oreil.ly/fmE52), на
другие места хранения. Эти места могут находиться внутри OneLake или быть
внешними, как Azure или Amazon Web Services.
Помимо ссылок, Microsoft Fabric имеет функцию зеркалирования, которая
реплицирует снапшоты баз данных в реальном времени. Например, на рис. 4.4
зеркалирование применяется к таким базам данных, как Cosmos DB и Azure
SQL Database. Зеркалирование гарантирует, что реплики синхронизируются
практически мгновенно и будут сохраняться в OneLake в формате Delta готовыми к немедленному использованию. Это напоминает технологию сохранения
изменений в данных.
Ссылки упрощают подключения к данным в таких форматах, как Delta Lake
и Iceberg, тогда как зеркалирование оптимально для проприетарных форматов
(например, Azure SQL) (см. рис. 4.4, на котором показаны подключения Microsoft
Fabric OneLake к разным источникам).
OneLake служит унифицированным уровнем хранения в экосистеме Microsoft
Fabric. Этот уровень интегрируется в Workspaces, предоставляя пользователям
доступ и операции с данными в разных типах рабочих нагрузок. Эти типы рабочих
нагрузок будут подробнее рассмотрены в следующих разделах.

Инженерия данных с использованием Spark
Data Engineering (инженерия данных) — один из основных типов рабочих нагрузок Microsoft Fabric. Пользователи получают возможность использовать Apache
Spark для обработки данных в своих аналитических проектах, от интеграции
данных до хранилищ данных, задач data science и бизнес-аналитики. Мы будем
использовать этот тип рабочей нагрузки для построения архитектуры медальона,
так как Spark является популярным вариантом обработки данных и аналитики.

  

124

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

Зеркало

ADLS Gen2
Future (on-prem S3):
Cloudflare, Qumulo,
MinIO, Dell ECS

Ссылка

Microsoft
Fabric

Ссылка

Ссылка
Dataverse

Локальный
экземпляр OneLake
(таблицы, файлы)

Ссылка

Cosmos DB, Azure SQL DB,
Fabric SQL DB,
SQL MI, Snowflake,
Databricks Unity Catalog,
Open mirroring (Striim,
MongoDB, Oracle
GoldenGate, DataStax),
SQL Server, PostgreSQL,
MySQL, Teradata,
BigQuery, Redshift
Amazon AWS S3/
Amazon S3 compatible
(preview)/Google Cloud
(preview)
Fabric OneLake (таблицы,
хранилище,
озеро-хранилище,
KQL DB, зеркала)

Рис. 4.4. Справочная диаграмма Джеймса Серра, демонстрирующая подключение Microsoft Fabric OneLake
к разным источникам
В области Data Engineering, изображенной на рис. 4.5, присутствует элемент
(тип сущности) Lakehouse, в котором пользователи могут хранить свои данные
и управлять ими.
Для сущностей Lakehouse компания Microsoft исключила настройку учетных
записей хранения, контейнеров и структур папок. Чтобы запустить процесс инженерии данных, вы создаете сущность Lakehouse (или Warehouse) и начинаете
работать с данными. Платформа незаметно предоставляет необходимые ресурсы
и конечные точки SQL, а также управляет инфраструктурой за вас.
В Microsoft Fabric сущность Lakehouse служит общей средой для разных типов
данных, как структурированных, так и неструктурированных. Она поддерживает хранение и управление различными форматами, включая CSV, XML, JSON
и Parquet. Тем не менее при создании таблиц с применением платформы по
умолчанию используется формат Delta Lake. Но что самое важное, все хранимые
данные в Lakehouse находятся в OneLake, так что они потенциально также доступны для других рабочих нагрузок и пользователей.
Вы можете обращаться к сущностям Lakehouse и взаимодействовать с ними через
область Data Engineering, которая предоставляет пользовательский интерфейс,
сходный с другими сервисами на базе Spark. Здесь можно писать блокноты, создавать таблицы и выполнять код Python. Этот процесс интегрируется с управляемой

  

Знакомство с Microsoft Fabric

125

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

Рис. 4.5. Рабочая нагрузка Data Engineering открывает прямой доступ к различным элементам:
озерам-хранилищам, блокнотам, средам и т. д.
Сущности Microsoft Fabric Lakehouse используются для построения архитектуры озер-хранилищ, но не путайте эти понятия! Озеро-хранилище — современная архитектура данных, сочетающая элементы озер данных и хранилищ данных, о которых говорилось в главе 1. В Microsoft Fabric сущность
Lakehouse относится к конкретной реализации в экосистеме Microsoft, включая пространство хранения, конечные точки SQL и другие элементы конфигурации. Таким образом, сущности Lakehouse используются для построения
архитектуры озер-хранилищ в Microsoft Fabric.

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

  

126

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

контроль доступа. Кроме того, схемы делают возможной сегрегацию источников
данных, изоляцию конкретных операций и внедрение подуровней в сущность
Lakehouse. Например, вы можете создать схему oceanic и переместить в нее все
необходимые таблицы. Такая конфигурация упрощает обращение ко всем таблицам. Пример создания таблицы в схема в Lakehouse на Python:
df.write.mode("Overwrite").saveAsTable("oceanic.sales")

Безопасность на уровне Lakehouse также присутствует. Вы можете предоставлять
доступ другим пользователям или группам к конкретным сущностям Lakehouse
или объектам Lakehouse без открытия доступа ко всей сущности Workspace и ее
компонентам.
Сущности Lakehouse также интегрируются с управлением жизненным циклом
в Microsoft Fabric. Они хранят как метаданные, так и данные, на которые могут
ссылаться другие объекты в Workspace. Например, сущность Lakehouse можно
сохранить в репозитории кода — Azure DevOps, GitHub и т. д. Как правило, в Git
отслеживаются только метаданные, а не сами данные.
В Lakehouse в единое целое упаковывается Spark, эндпоинты SQL, репозитории
файлов и схемы, использующие таблицы Delta. Перейдем к другому типу рабочей
нагрузки Microsoft Fabric — хранилищам данных (Warehouse).

Хранилища данных с T-SQL
Сущности Warehouse немного похожи на Lakehouse, но предлагают иной тип
рабочей нагрузки, где можно разрабатывать и выполнять сценарии SQL. Сущности Warehouse, как и Lakehouse, хранят свои данные в OneLake и используют
тот же формат Delta.
Главное отличие между сущностями Lakehouse и Warehouse — ядра обработки,
которые они используют1. Warehouse работает с распределенным ядром, поддерживающим многотабличные транзакции (https://oreil.ly/FIj4g) через T-SQL
(https://oreil.ly/VcBmN) — проприетарное расширение языка SQL. T-SQL недоступен в Apache Spark, в отличие от Spark SQL (https://spark.apache.org/sql) — модуля
Spark для структурированной обработки данных с использованием интерактивных запросов SQL.
Переходить со Spark на T-SQL целесообразно, если ваша обработка данных требует нетривиальных транзакций или ваши инженеры хорошо владеют T-SQL.
В таких случаях сущность Warehouse может быть лучшим вариантом. Тем не
менее если ваша команда более уверенно работает со Spark или если вам важнее
всего эксплуатационная совместимость и открытые стандарты, лучше остановиться на Lakehouse.
1

Компания Microsoft опубликовала руководство по выбору между Warehouse и Lakehouse
(https://oreil.ly/W34yL).

  

Создание основы

127

Сущности Warehouse в Microsoft Fabric проектируются для управления сложными транзакциями между разными таблицами, хотя они используют иные языки
и ядра обработки, чем озера-хранилища Spark. Кроме того, ядро обработки хранилища данных улучшает производительность за счет использования таблиц,
оптимизированных для V-упорядочения. Очень важно понимать эти отличия,
чтобы выбрать наиболее подходящий инструмент для своих потребностей. А сейчас рассмотрим другие возможности Microsoft Fabric.

Другие типы рабочих нагрузок Fabric
Lakehouse и Warehouse интегрируются с другими типами рабочих нагрузок
в Microsoft Fabric. Например, тип рабочей нагрузки Data Factory позволяет оркестрировать и автоматизировать движения и преобразования данных. Кроме
того, существует тип рабочей нагрузки Real-Time Intelligence, который позволяет
получать данные в реальном времени от Azure Event Hubs или Azure IoT Hub.
Затем эти данные обрабатываются и загружаются в Lakehouse, Warehouse или
базы данных Kusto Query Language (KQL) (https://oreil.ly/PL2Yh), которые больше
подходят для обработки данных реального времени или временных рядов. Интеграция типов рабочих нагрузок также распространяется на такие инструменты,
как Power BI или Fabric Data Science. Например, область Notebook включает Data
Wrangler — инструмент, который готовит данные и генерирует код Python. Этот
код может использоваться с целью дальнейшей обработки данных для Lakehouse
или Warehouse.
Каждый тип рабочей нагрузки предназначен для конкретных потребностей. Все
они наделены разными возможностями, однако все ядра обработки интегрируются с архитектурой хранения OneLake, по умолчанию использующей формат
таблиц Delta. Эта интеграция позволяет использовать данные между разными
типами рабочих нагрузок без дублирования — иногда этот метод называется
нулевым ETL.
Немного сменим тему и перейдем к практической настройке платформы. Для
этого потребуется начать с создания основы.

Создание основы
Вернемся к примеру с системой для Oceanic Airlines. Первым шагом станет использование Microsoft Fabric для ее развертывания, что потребует подписки Azure
(https://azure.microsoft.com):
1. Войдите в свою учетную запись Power BI по адресу https://app.powerbi.com.
2. Щелкните кнопку Settings (Настройки) в правом верхнем углу.
3. Выберите вариант Admin portal (Панель администратора) из раздела Governance
and insights (Управление и инсайты).

  

128

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

4. Перейдите в раздел Tenant settings (Настройки арендатора) и найдите Microsoft
Fabric в начале области настроек.
5. Разверните вариант Microsoft Fabric и включите его.
После включения можно решить, хотите ли вы предоставить доступ к Microsoft
Fabric всем участникам вашего арендатора или ограниченной безопасной
группе. Подробности см. в документации Microsoft (https://oreil.ly/uAMpW) и на
рис. 4.6.
После включения Microsoft Fabric вы сможете обратиться к системе по адресу
https://app.fabric.microsoft.com. На экране появится заставка Microsoft Fabric.

Рис. 4.6. Окно администрирования, в котором организации, использующие Power BI,
могут включить Microsoft Fabric
Чтобы полностью использовать все возможности Fabric, потребуются достаточные емкости по ресурсам.

Настройка емкостей
Чтобы исследовать возможности Microsoft Fabric, можно начать с пробного периода. Выберите настройки Help and support (Помощь) и посмотрите, доступен
ли вариант Users can try Microsoft Fabric paid features (Пользователи могут получить
пробный доступ к платной функциональности). Пробный период может отлично
подойти для того, чтобы протестировать возможности программного продукта
без начальных затрат.
Чтобы приобрести подписку, войдите на портал Azure (https://portal.azure.com)
и создайте новую группу ресурсов (https://oreil.ly/iFxZV). Перейдите в маркетплейс Azure и найдите Microsoft Fabric. Выберите вариант Fabric, который

  

Создание основы

129

лучше подходит для ваших потребностей (для нашего примера выберите
бюджетный вариант F4), и разверните его в только что созданной группе ресурсов. Это позволит полностью и без проблем интегрировать Microsoft Fabric
в рабочий поток.

Настройка доменов
Перейдите на портал администрирования и щелкните вкладку Domains (Домены).
Нажмите кнопку Create new domain (Создать новый домен). Откроется диалоговое
окно для ввода имени нового домена (например, Sales); назначьте администраторов домена, а затем щелкните кнопку Create.
После установления домена найдите значок Microsoft Fabric в левом нижнем
углу. Щелкнув его, вы сможете выбрать один из адаптированных процессов,
подходящих для разных рабочих нагрузок. Для целей нашего примера выберите
Data Engineering (Инженерия данных).

Настройка рабочих пространств
После выбора Data Engineering страница обновится и в левой части появится новый
вариант Workspaces. Создайте три новых рабочих пространства: для разработки,
для тестирования и для эксплуатации. Обязательно выберите для каждой сущности Workspace режим лицензирования, включающий емкость Fabric (например,
Trial (Пробный) или Premium (Премиум)). Не забудьте связать все новые рабочие
пространства с доменом Sales.
Чтобы расширить обмен артефактами между средами и реализовать процесс
CI/CD, см. документацию Microsoft Fabric по управлению развертываниями
(https://oreil.ly/GEcJh).

Выберите только что созданное рабочее пространство разработки. Когда пространство откроется, оно будет пустым и готовым к запуску нового проекта.
Теперь перейдите в настройки Workspace и включите режим Users can edit data
models (Пользователи могут редактировать модели данных) (https://oreil.ly/PlcqM),
как показано на рис. 4.7. Повторите этот процесс для двух других рабочих пространств.
Включение этой функции позволит создавать отношения между таблицами
в Lakehouse с использованием семантической модели Power BI. Мы воспользуемся этим в главе 7 при построении семантической модели.

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

  

130

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

Рис. 4.7. Функция редактирования модели данных (флажок внизу экрана) позволяет создавать отношения
между таблицами в Lakehouse с использованием семантической модели Power BI
Сначала перейдите на домашнюю страницу Data Engineering и создайте новую
сущность Lakehouse с именем Bronze . Не забудьте при создании установить
флажок рядом с Lakehouse schemas. Примерно через 20 секунд новая сущность
Lakehouse будет готова; изначально она практически пуста. В ней вы найдете
схему по умолчанию dbo в разделе Tables (Таблицы). Эта схема относится к постоянным компонентам, ее нельзя ни изменить, ни удалить.
Повторите последний шаг, создав еще две сущности Lakehouse: Silver и Gold.
Каждая сущность Lakehouse служит уровнем хранения для соответствующего
уровня архитектуры медальона. Когда все будет сделано, экран должен выглядеть
примерно так, как показано на рис. 4.8.
Создание множественных схем (https://oreil.ly/ZKL-8) или логические группировки таблиц в одной сущности Lakehouse1 считаются лучшей практикой, прежде
всего оптимизирующей организацию и повышающей уровень безопасности.
Создавая множественные схемы, вы фактически разбиваете данные на категории и управляете ими. Более того, этот подход предотвращает конфликты
имен, потому что одно имя таблицы из источников может использоваться на
разных уровнях.
1

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

  

Создание основы

131

Рис. 4.8. Страница рабочих пространств с тремя уровнями Lakehouse
Итак, вы успешно настроили основные сервисы для Oceanic Airlines. Мы определили важнейшие конфигурации для емкостей, доменов, сущностей Workspace
и Lakehouse. Давайте ненадолго остановимся и обдумаем выполненные действия
и процесс настройки.
1. Емкости
Мы начали с создания емкости для запуска рабочих нагрузок. Емкости необходимы для получения вычислительных ресурсов, требуемых для заданий
обработки данных.
2. Домены
Далее мы создали новый домен Sales для Oceanic Airlines. Этот домен служит
основной административной границей и обеспечивает управление всеми проектами, относящимися к данным, для конкретного бизнес-сегмента.
3. Рабочие пространства
Мы создали в Microsoft Fabric три сущности Workspace для заданий обработки данных. Они предназначены для разработки, тестирования и экс-

  

132

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

плуатации. Связывая каждое рабочее пространство с доменом Sales, мы
гарантируем, что все данные и артефакты будут оставаться в одном бизнесподразделении.
4. Ресурсы Lakehouse
Мы развернули три элемента Lakehouse — Bronze, Silver и Gold. Эти уровни
представляют разные стадии обработки и уточнения данных, которые образуют основу архитектуры данных.
В следующих разделах мы поговорим о том, что необходимо учитывать при работе
с емкостью, доменами и рабочими пространствами, а затем обсудим сущности
Lakehouse и Warehouse. Также уделим внимание учетным записям хранения
данных, так как другие платформы на базе Spark все еще зависят от них при
хранении данных. Разобравшись с этими элементами, мы перейдем к первому
источнику данных. Заметим, что другие сервисы, такие как Azure Databricks
и Synapse Analytics, используют аналогичные концепции, поэтому знания,
которые вы получите, вы сможете применить к другим сервисам, связанным
с платформами данных.

Особенности работы с емкостью
При настройке Microsoft Fabric исключительно важно выбрать правильные вычислительные ресурсы для выполнения заданий обработки данных. В нашем примере выбирается вариант F4 SKU, идеально подходящий для простых пакетных
заданий ETL, которые не требуют обширных преобразований и ориентированы
на небольшую группу пользователей.
Однако с расширением требований стоит подумать о развертывании разных емкостей для более эффективного обслуживания разных типов рабочих нагрузок.
Можно создать стандартную зарезервированную емкость для повседневных задач
и меньшую, более эффективную по затратам емкость с оплатой по фактическому
потреблению («по требованию») для ситуативных или более простых заданий.
Такая стратегия распределения рабочих нагрузок между разными кластерами
помогает оптимизировать затраты и производительность. Она также упрощает
адаптацию архитектуры к эволюционирующим требованиям, поддерживая беспрепятственную и эффективную работу систем.

Особенности работы с доменом
Первый домен был создан при настройке Microsoft Fabric. Домен служит
логическим контейнером для всех актуальных данных и артефактов (таких,
как блокноты) в определенной области или подразделении организации. Эта
возможность особенно полезна в больших компаниях, так как позволяет группировать данные по бизнес-функциональности, функциональным областям
или отделам. Такая организация помогает пользователям управлять своими

  

Создание основы

133

данными в соответствии с конкретными нормативами, ограничениями и потребностями.
Возьмем пример с авиакомпанией Oceanic Airlines. Вероятно, в ней работает
множество разных команд в разных бизнес-юнитах: менеджмент в аэропортах,
перевозки багажа, продажи, финансы, маркетинг, эксплуатация и т. д. В таком
сценарии домен может представлять отдел компании, например отдел продаж.
Ответственность за управление пользователями и рабочими пространствами
и соответствующие полномочия могут быть делегированы назначенным администраторам доменов или ответственным участникам. Кроме того, домены
могут делиться на поддомены. Например, домен Sales (продажи) может иметь
поддомены Sales Consumers (продажи для физических лиц) и Sales Businesses
(продажи для предприятий).
Количество доменов, необходимых компании, зависит от многих факторов. Одни
компании используют разнообразные домены на основе специализаций бизнеса,
другие могут быть не столь масштабными или не применять столь проработанные
методы управления большими данными. Мелкие компании могут ограничиться
меньшим количеством доменов, но увеличить численность команд, обрабатывающих более крупные датасеты. Мы подробно рассмотрим эту тему в главе 11 при
обсуждении масштабирования архитектур.
Домены предназначены в первую очередь для разделения задач управления
и администрирования. Они не определяют, кому разрешен доступ к данным или
другим артефактам. Задачи безопасности и управления доступом решаются на
других уровнях, которые рассматриваются ниже.

Особенности рабочих пространств
Рабочие пространства играют важнейшую роль в Microsoft Fabric. Они выступают центрами совместной работы, в которых пользователи выполняют различные
задачи, в том числе задачи загрузки данных, машинного обучения, обнаружения
данных и составления отчетов. Управление артефактами в рабочих пространствах — не уникальная функция Microsoft Fabric. Другие сервисы (такие, как
Synapse Analytics и Azure Databricks) также используют рабочие пространства
для оптимизации своих операций и повышения производительности.
Рабочие пространства соединяют пользователей с конкретными регионами, емкостями и системами контроля версий, необходимыми для управления кодом и артефактами. Соединение сущности Workspace с конкретным регионом помогает
управлять всеми хранимыми данными в пределах этого региона. Можно связать
Workspace с конкретной емкостью для определенного региона, чтобы все данные
и артефакты хранились в его пределах. Это особенно удобно для глобальных компаний, которые должны подчиняться жестким законам о разделении хранимых
данных по географическому признаку. Например, если бизнес-подразделение
должно разделять данные между Европой и США, использование нескольких

  

134

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

сущностей Workspace может обеспечить выполнение этих требований. В результате одна бизнес-область с несколькими лока­лизованными экземплярами
платформ может управлять несколькими Workspace1.
Как вы уже узнали, сущности Workspace связываются с емкостями. Правильное
соответствие емкостей и рабочих пространств может повышать эффективность.
Например, один блок емкости (CU) может обслуживать все рабочие пространства
разработки разных команд или же продакшен-среда с повышенной нагрузкой
может иметь собственную, специально выделенную емкость. Использование дополнительных сущностей Workspace может быть эффективно для оптимизации
и сегрегации рабочих нагрузок с интенсивными вычислениями внутри домена.
Рабочие пространства также интегрируются с системой контроля версий для
управления процессами развертывания и разделения обязанностей между стадиями разработки, тестирования и продакшена. Каждой стадии рекомендуется выделить собственную сущность Workspace, это важно для управления процессами
CI/CD. Для архитектуры медальона рекомендуется хранить весь код и артефакты
(такие, как Lakehouse) в пределах одной сущности Workspace. От этого можно отказаться и создавать отдельные сущности Workspace для разных уровней. Однако
это может усложнить процесс CI/CD, поскольку придется управлять разными
сущностями Workspace и связанными с ними артефактами.
По аналогии с другими сервисами на базе Spark сущности Workspace служат
границами безопасности для управления разрешениями. Они включают разные
роли (администратор, участник, наблюдатель и т. д.) со специальными правами
и ограничениями. Более того, сущности Workspace могут обеспечивать сегрегацию
операций или распределение данных. Например, чтобы предоставить некоторым
пользователям ограниченный доступ для исследовательских целей в продакшенсреде, можно создать новую сущность Workspace со ссылками только для чтения
на другие сущности Workspace. Этот метод сегрегации может упростить обмен
данными между командами.
Кроме того, сущности Workspace включают управляемую сущность для безо­
пасных обращений к другим сервисам. Например, недавно созданная сущность
Workspace может ограничивать некоторые архитектурные компоненты, чтобы они
могли подключаться только к конкретным частям, — что-то вроде виртуальной
сети, подключенной к локальному источнику данных. Эта функция особенно
полезна для организаций, требующих строгой изоляции данных или имеющих
специфические требования к управлению данными.
1

В данном контексте под «экземпляром платформы» понимается конкретная конфигурация таких платформ, как Synapse Analytics и Azure Databricks в пределах региона,
допускающая локализованные конфигурации. В Microsoft Fabric все иначе; система
работает как унифицированная платформа SaaS, которая позволяет пользователям
управлять операциями при помощи наборов Workspace в одной архитектуре платформы
без четко определенных и изолированных экземпляров.

  

Создание основы

135

У подхода с использованием нескольких сущностей Workspace есть и другие
преимущества. Например, настройка отдельных рабочих пространств для разных
команд может сфокусировать усилия и повысить безопасность за счет предоставления изолированных сред для каждой команды, чтобы они могли работать над
своими проектами. В сценариях, с которыми я сталкиваюсь достаточно часто, одна
команда управляет всем вводом и загрузкой данных из-за сложностей, присущих
этим процессам. После загрузки, очистки и организации данные становятся доступными для других команд. Как правило, эти команды не выходят за пределы
собственных рабочих пространств, сосредоточиваясь на конкретных проектах.
Такая схема организации работы наглядно изображена на рис. 4.9.

Золотой
Рабочее пространство
Системыисточники

Бронзовый

Серебряный

Центральная команда

Золотой

Золотой
Золотой

Золотой

Рис. 4.9. Все задачи получения и загрузки данных обслуживаются одной командой
(часто встречается в небольших организациях)
В нашем примере Oceanic Airlines изначально управляет всеми заданиями обработки данных в одном рабочем пространстве, доступном инженерам для разработки и совместной работы. С ростом организации и увеличением количества
проектов может быть полезно создание нескольких рабочих пространств, например, для поддержки тестирования и эксплуатации. Эта стратегия позволяет
более эффективно управлять разными проектами и командами, адаптируясь
к росту и эволюционирующим потребностям. Мы вернемся к этой теме в разделе
«Количество архитектур медальона» главы 11, с. 328.

Особенности работы с сущностями Lakehouse
В начале этой главы были кратко описаны сущности Lakehouse и Warehouse,
играющие важную роль в хранении структурированных данных в Microsoft Fabric.
Эти сущности являются ключевыми компонентами архитектур медальона. Как
правило, архитектура медальона разбивается на три уровня, каждый из которых
представляет отдельную степень качества данных — чем выше уровень, тем выше
качество данных.
При работе в Microsoft Fabric рекомендуется закрепить за каждым уровнем
отдельную сущность Lakehouse. Это лучше, чем использовать одну сущность
Lakehouse или Warehouse с несколькими схемами для всех уровней. Когда вы

  

136

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

используете несколько различных сущностей Lakehouse или Warehouse, они
включают встроенные эндпоинты SQL, что позволяет более точно управлять
тем, кому разрешен доступ к тому или иному эндпоинту. Таким образом, чтобы
построить стандартную архитектуру медальона в Microsoft Fabric, следует создать
минимум три сущности: Lakehouse для бронзового, Lakehouse для серебряного,
и Lakehouse или Warehouse для золотого уровня.
Рабочий поток развертывания между фазами разработки, тестирования и эксплуатации (DTP, Deployment/Testing/Production) часто подразумевает клонирование
сущностей Workspace. Каждая среда обычно содержит как минимум три сущности
Lakehouse или Warehouse. Для DTP это означает, что в итоге у вас появляются
девять сущностей Lakehouse в трех Workspace. На первый взгляд много, но такая
конфигурация вполне управляема, так как можно закреплять разные емкости за
каждым уровнем в сущности Lakehouse каждой среды.
Права доступа настраиваются для каждой сущности. Например, вы можете разрешить дополнительным пользователям доступ к уровню только для чтения через
эндпоинт SQL. Такая конфигурация особенно полезна, если вы хотите предоставить доступ только к качественным данным на золотом уровне или доступ
разработчикам, которые должны заняться диагностикой проблем в бронзовой
продакшен-среде, но доступ к другим уровням данных им не нужен.
Сущность Lakehouse также предоставляет дополнительный уровень разделения
для защиты. Представьте, что команда большого домена управляет несколькими приложениями, но не все участники команды должны иметь доступ ко всем
сырым данным. Или, возможно, несколько меньших команд загружают данные,
и вы хотите запретить им запись в один и тот же приемник. В таком случае настройка дополнительных сущностей Lakehouse или Warehouse позволяет каждой
команде управлять своими данными независимо от других.
Для успешной архитектуры медальона крайне важно соответствие стандартам, так
как это позволяет новым командам быстро и эффективно подключаться к работе.
Например, каждая сущность Workspace должна придерживаться конкретной
структуры своих сущностей Lakehouse. Примите правила назначения описательных имен, отражающих связанную с ними сущность Workspace или проект.
Другая полезная стратегия — написание скриптов для процесса развертывания
таким образом, чтобы все важные элементы (такие, как сущности Workspace
и Lakehouse) были упакованы вместе.
В зависимости от специфических требований сущность Workspace может содержать
более трех типичных сущностей Lakehouses для бронзового, серебряного и золотого
уровней. Собственно, любой из этих уровней может включать несколько сущностей
Lakehouse для лучшей организации и управления данными. Например, бронзовый
или золотой может иметь несколько сущностей Lakehouse, каждая из которых помечается специальным префиксом или идентификатором, четко описывающим
их назначение и содержимое. Это обеспечивает большую гибкость и контроль за
управлением и обращением к данным в пределах каждого уровня.

  

Создание основы

137

Чтобы лучше понять тему управления данными, изучите, как жизненный цикл
данных организован в других сервисах на базе Spark и Delta Lake, особенно использующих Azure Data Lake Storage. Так вы узнаете, как эффективно интегрировать эти сервисы и сформировать надежную и эффективную экосистему данных.

Особенности работы с учетными записями хранения данных
При настройке сервисов на базе Spark (таких, как Azure Databricks, Synapse
Analytics или Azure HDInsight) крайне важно выбрать правильную стратегию для
управления учетными записями хранения данных. Например, если вы решаете
использовать Azure Databricks, возможно, вы выберете одну учетную запись Azure
Data Lake Storage, разделенную на три контейнера: Bronze, Silver и Gold. Такая
конфигурация гарантирует, что все ваши данные будут находиться в одном месте
и будут распределены по разным контейнерам.
The Hitchhiker’s Guide to the Data Lake (https://oreil.ly/sGrAu) — подробное
руководство с описанием основных моментов, которые необходимо учитывать
при построении собственных озер данных, включая ADLS и конфигурации
учетных записей хранения данных.

Можно ли отклоняться от этой конфигурации? Безусловно. Для небольших
проектов с простым управлением данными часто хватает одной учетной записи
хранения, потому что ею легко управлять и обращаться к данным. Но в больших
проектах вам может понадобиться несколько учетных записей хранения, чтобы
данные разделялись для целей упорядочения или безопасности. Тогда каждой
команде дата-инженеров выделяется собственная учетная запись с несколькими
контейнерами для разных уровней. Такой подход помогает более эффективно
организовать доступ и управление данными.
Другое возможное решение — использование гибридной модели, которая выдерживает баланс между данными с локальным и централизованным размещением.
Этого можно добиться, реализуя учетные записи как для локального, так и для
централизованного хранения. Каждый домен может использовать внутреннюю
выделенную учетную запись для обработки на основе домена, которая может
включать операции на бронзовом, серебряном или золотом уровне. Эта учетная
запись предназначена исключительно для внутреннего использования, и доступ
к ней из других доменов не предоставляется. Кроме учетных записей локального
хранения создается централизованная общая учетная запись. Она используется
для распространения итоговых версий продуктов данных, которые обычно хранятся либо на серебряном уровне (продукты данных, ориентированные на источник), либо на золотом (агрегированные или ориентированные на потребителя
продукты данных) в других доменах. Общая учетная запись хранения данных
часто находится под управлением центрального отдела. Такая структура обеспечивает гибкость доменов с сохранением контроля за всеми операциями обмена
данных. Практический пример этого дизайна приведен в главе 11.

  

138

Глава 4. Строим основу архитектуры медальона с посмощью Microsoft Fabric

Существует много других причин для отклонения от конфигурации озер данных
по умолчанию. Среди них можно выделить следующие:
Организационная структура
Разные отделы управляют принадлежностью своих данных.
Мультирегиональные развертывания
Соблюдение требований о региональном хранении данных.
Обход лимитов Azure
Обход ограничений подписки или уровня обслуживания.
Реализация других политик Azure
Адаптация политик для каждого озера данных.
Отслеживание затрат
Упрощение выставления счетов за счет отдельных подписок Azure для каждого озера.
Отделение конфиденциальных данных
Изоляция и применение более жестких мер контроля за конфиденциальными
данными.
Сегрегация среды
Использование разных озер для разработки, тестирования и эксплуатации.
Уменьшение задержки
Размещение озер данных ближе к конечным пользователям или приложениям.
Ограничение привилегий
Ограничение повышенных привилегий к необходимым ресурсам данных.
Управление данными и комплаенс
Соблюдение различных нормативных требований и стандартов.
Особые потребности отделов
Некоторым командам необходимы выделенные озера данных.
Возможность аварийного восстановления
Распределение озер данных между регионами для обеспечения доступности
данных.
Разные уровни обслуживания
Использование отдельных озер для оптимизации затрат и производительности для разных типов данных.

  

Заключение

139

Чтобы больше узнать о причинах для реализации дополнительных озер данных,
обращайтесь к статье When to Have Multiple Data Lakes (https://oreil.ly/epq6Z)
Джеймса Серра (James Serra).
Создав основу и обсудив ключевые факторы проектирования, подведем краткий
итог основных этапов развертывания и того, что вы узнали о Microsoft Fabric,
прежде чем переходить к построению бронзового уровня в главе 5.

Заключение
В этой главе мы узнали, как настроить Microsoft Fabric — платформу, предоставляющую обширные возможности пользовательской настройки для разных
потребностей организаций. Были затронуты темы доменов, а также сущностей
Workspace и Lakehouse.
Ключевые стратегии создания основы для архитектуры медальона:
Организуйте сущности Lakehouse в рабочих пространствах Workspace, а затем в доменах.
Оцените эластичность рабочих нагрузок, чтобы повысить экономическую
эффективность архитектуры. Проанализируйте возможность резервирования
и стратегического совмещения рабочих пространств с разными типами блоков
емкости (CU).
Предоставьте командам рекомендации относительно оптимального количества
сущностей Workspace и Lakehouse. Примите стандартные правила именования
в организации.
Управление платформой аналитики данных (такой, как Microsoft Fabric) включает в себя разные параметры конфигурации и условия, что может усложнить
управление рабочими нагрузками в организациях. Таким образом, для эффективного управления и обслуживания потребуется опытная команда дата-инженеров. Она должна действовать направленно, начиная с малого и постепенно
наращивая усилия. Регулярные взаимодействия с другими командами, включающие использование демоверсий, еженедельные общие ланчи и ежемесячные
социальные активности помогают наладить совместную работу и внедрять
инновации. Это способствует формированию сильной культуры организации
и обеспечивает соответствие платформы более широким целям бизнеса. В главе 5, продолжающей тему использования Microsoft Fabric, мы сфокусируемся
на бронзовом уровне.

ГЛАВА 5

Строим бронзовый уровень
После создания основы платформы данных, будь то Microsoft Fabric или Azure
Databricks, пришло время перейти к бронзовому уровню. Это уровень, куда впервые поступают все сырые данные, и здесь они поддерживаются в своей исходной
форме. Он служит историческим архивом и надежным единым источником
данных.
В процессе создания первого уровня мы будем заниматься такими задачами, как
настройка подключений, построение первого пайплайна данных, загрузка данных и управление схемой. При этом мы будем рассматривать разные фрагменты
кода. Они приводятся для пояснения — часть только в учебных целях, а часть
вы сможете использовать в своих программах. Однако помните, что примеры
упрощены для наглядности, и, возможно, вам придется слегка изменить их при
использовании в реальных сценариях.
К концу главы вы будете хорошо понимать, как построить и реализовать бронзовый уровень архитектуры медальона, включая тонкости, связанные с загрузкой
и управлением данными. Это подготовит вас к работе с серебряным и золотым
уровнями. Начнем с пайплайна данных.

Создание пайплайна данных
В этом разделе мы построим пайплайн данных1 при помощи Data Factory, с интеграцией Spark и Delta Lake в процесс. Этот практический пример поможет
вам понять, как указанные инструменты взаимодействуют в реальных условиях.
При использовании Azure Data Factory вы заметите небольшие отличия в некоторых диалоговых окнах конфигурации по сравнению с Data Factory
в Microsoft Fabric. Если при использовании Azure Databricks вы столкнулись
с трудностями, обратитесь к описанию начальных шагов настройки (https://
oreil.ly/MjoEK).

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

Пайплайн (pipeline) представляет собой логическую группировку операций по выполнению некоторой задачи.

  

Создание пайплайна данных

141

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

Рис. 5.1. Общий вид пайплайна в Data Factory
К концу раздела вы получите полезную информацию и рекомендации, которые
подготовят вас к реализации таблиц Lakehouse. После этого мы займемся управлением схемами.

Развертывание базы данных AdventureWorks
В этом упражнении база данных AdventureWorks будет использоваться для демонстрации того, как ввести реальный источник данных в созданную нами новую
среду. База данных AdventureWorks часто используется для демонстрационных
целей и обучения; она отлично подходит для изучения загрузки данных, повышения качества данных и операций по их интеграции.
База данных AdventureWorks входит в Azure SQL (https://oreil.ly/OxKE3) — облачный сервис реляционных баз данных, предоставляемый Microsoft Azure.
Технология Azure SQL популярна среди организаций, занимающихся созданием
новых облачных нативных приложений. Она спроектирована для управления
и хранения структурированных данных, обеспечивая высокую безопасность,
масштабируемость и доступность.

  

142

Глава 5. Строим бронзовый уровень

Чтобы развернуть пример AdventureWorks в Azure SQL, выполните инструкции из документов Quickstart: Create a Single Database (https://oreil.ly/M_UeH)
и AdventureWorks Sample Database (https://oreil.ly/qQjjm).
После выполнения описанных действий и завершения развертывания можно переходить к построению своего первого пайплайна с использованием Data Factory.
В следующих разделах мы займемся настройкой подключения. После этого при
помощи Data Factory загрузим данные на бронзовый уровень и партиционируем
их по дате загрузки. После этого запустим задание Spark для создания таблиц
бронзового уровня с использованием того же пайплайна.

Настройка подключения к базе данных Azure SQL
Чтобы прочитать данные из базы данных AdventureWorks и записать их на
бронзовый уровень, нужно задать детали подключения в Data Factory. Они содержат свойства подключения и учетные данные, необходимые для подключения
к приемникам.
Чтобы настроить подключение к базе данных, нажмите на значок шестеренки
Settings в верхней части экрана и выберите вариант Manage Connections and Gateways (Управление подключениями и шлюзами). Затем выберите New (Новый)

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

Нам нужно создать подключение с помощью SQL Server для использования базы
данных AdventureWorks. Подробности см. в руководстве Set up Your Azure SQL
Database Connection (https://oreil.ly/gxLb7). Кроме того, я рекомендую использовать
для аутентификации учетную запись распорядителя сервиса (service principal)
(https://oreil.ly/84R73), так как она предоставляет наиболее безопасный и масштабируемый способ аутентификации учетной записи Data Factory с сервисами Azure.
На рис. 5.2 изображен общий экран настройки.
У каждого источника данных свои уникальные особенности. Возможно,
вместо конфигураций и действий, описанных в этом разделе, вам придется
использовать совершенно другие. Эта тема рассматривается далее в подразделе «Настройка действия CopyTable», с. 146. Схема именования в этом
примере следует схеме базы данных AdventureWorks. Ничто не мешает
изменить ее, чтобы она лучше соответствовала вашему конкретному источнику данных.

После настройки всех деталей подключения можно запустить проект, создав
­н овый пайплайн в Data Factory (https://oreil.ly/4-ZF- ). Этот пайплайн данных ­станет основой для будущих шагов, включая создание действий Lookup

  

Создание пайплайна данных

143

(Поиск), ForEach (цикл for each), Copy Tables (Копировать таблицы) и Notebook
(Блокнот).

Рис. 5.2. Настройка подключения в Data Factory

Создание нового пайплайна данных
Чтобы создать новый пайплайн, вернитесь к Workspace при помощи навигационной панели в левой части экрана и откройте вариант Workspace для разработки.
Щелкните кнопку New Item и выберите пайплайн данных (Data pipeline). Затем
введите имя вновь созданного пайплайна, например AdventureWorks. Страница
обновится и покажет пустой холст, на котором будет строиться пайплайн. На
холсте в пайплайн будут добавляться такие действия, как Lookup, ForEach, CopyTable
и Notebook (вы найдете их на панели Activities в верхней части экрана).

  

144

Глава 5. Строим бронзовый уровень

Начните с добавления действия Lookup — перетащите его на пайплайн. Действие Lookup будет использоваться для получения информации схемы из
базы данных AdventureWorks. Информация будет использоваться в процессе
перебора списка таблиц баз данных для выполнения операции копирования.
Таким образом, каждая таблица будет динамически скопирована в Lakehouse
бронзового уровня.
Затем щелкните на действии, чтобы настроить его. В настройках выберите
недавно созданное подключение AdventureWorks Connection для чтения
информации из базы данных. Затем перейдите в раздел деталей; установите
в строке Use query (Использовать запрос) переключатель Query, чтобы загрузить
все имена таблиц. Убедитесь, что флажок First row only (Только первая строка)
не установлен, чтобы разрешить чтение всех строк из таблицы. Подробнее см.
на рис. 5.3.

Рис. 5.3. Запрос, используемый для загрузки только актуальной информации схемы

  

Создание пайплайна данных

145

Приведенная ниже команда SQL читает из представления INFORMATION_SCHEMA
только функциональные имена таблиц. Это представление предоставляет внутренний, не зависящий от системных таблиц доступ к метаданным базы данных.
Оно обеспечивает более стандартизированный метод получения информации об
объектах базы данных: таблицах, столбцах, доменах, ограничениях, привилегиях
и т. д. Поскольку большинство современных баз данных поддерживает системные
таблицы, запрос метаданных часто выглядит так:
SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_SCHEMA = 'SalesLT'

Чтобы убедиться, что все работает правильно, щелкните кнопку Preview data
(Предпросмотр данных). Если данные отображаются как ожидалось и на экране
появляется общее представление с таблицами, можно переходить к добавлению
действия ForEach.

Построение цикла ForEach
ForEach относится к категории действий управления последовательностью выполнения; оно перебирает содержимое коллекции элементов и выполняет операцию с каждым элементом коллекции в определенном порядке. ForEach часто
используется в проектах инженерии данных для выполнения набора (повторяющихся) операций с группой файлов или таблиц. В нашем случае ForEach будет
использоваться для перебора информации системного объекта, полученного от
базы данных AdventureWorks. Эта информация будет использоваться для копирования таблиц в Lakehouse бронзового уровня.

Чтобы перебрать информацию системного объекта, полученного от базы данных
AdventureWorks, добавьте следующие данные в поле Items действия ForEach1:
@activity('LookupTables').output.value

Эта конфигурация позволяет ForEach извлечь схему и имена таблиц из результатов запроса (из действия Lookup). Затем ForEach использует вывод как аргументы
в цикле. При настройке ForEach проследите, чтобы входное имя точно совпадало
с именем из предыдущего действия. Например, в примере на рис. 5.4 ввод должен
быть напрямую связан с заданием LookupTables.
После настройки действия ForEach интегрируем действие CopyTable.

1

Для выполнения циклического перебора также можно запустить блокнот Spark из другого блокнота. Этот вариант может быть эффективнее и проще в обслуживании. Узнать
о нем больше можно в статье High Concurrency Mode in Apache Spark for Fabric (https://
oreil.ly/uCRIv).

  

146

Глава 5. Строим бронзовый уровень

Рис. 5.4. Перебор всех таблиц с использованием действия ForEach

Настройка действия CopyTable
Откройте цикл ForEach и перетащите в него действие CopyTable. Оно обеспечивает
копирование данных из источника в приемник. В данном случае оно будет копировать таблицы из базы данных AdventureWorks в сущность Lakehouse бронзового
уровня. Чтобы настроить действие CopyTable, необходимо задать свойства Source
(Источник) и Destination (Приемник) (рис. 5.5).
Для свойства Source необходимо выбрать AdventureWorks Connection вместе с соответствующей базой данных. Убедитесь, что TableName и SchemaName заданы как
входные параметры. Эти значения соединяются с метаданными, которые были
извлечены действием Lookup.
@item().table_name
@item().table_schema

  

Создание пайплайна данных

147

Рис. 5.5. Параметры свойства Source действия CopyTable
Затем перейдите к свойству Destination. Для параметра Connection (Подключение)
выберите сущность Lakehouse Bronze. В диалоговом окне File path (Путь к файлу)
добавьте следующие два свойства:
@concat('adventureworks/', formatDateTime(utcnow(), 'yyyyMMdd'))
@concat(item().table_name,'.parquet')

На рис. 5.6 показана страница настройки Destination.

  

148

Глава 5. Строим бронзовый уровень

Рис. 5.6. Свойство Destination действия CopyTable
Если все настроено правильно, вы найдете на панели инструментов кнопку Run
(https://oreil.ly/SYMjT) для запуска пайплайна и отслеживания процесса. Когда все
заработает, как ожидалось, в контейнере Bronze должна появиться папка с именем,
соответствующим сегодняшней дате (рис. 5.7).
Благодаря этой конфигурации данные AdventureWorks будут сохранены и партиционированы в Lakehouse бронзового уровня, следуя вот такому формату: Files/
adventureworks/ГГГГММДД/TableName.parquet. К преимуществам этого метода можно отнести архивацию всех данных в дневном временном окне, обеспечивающую
структурированное хранение данных на основе времени. При систематической
историзации данных для заданий обработки Spark создается хорошо подготовленный ввод. Такой подход также поддерживает требования к аудиту и предоставляет
историческую информацию для восстановления данных в случае ошибок.

  

Создание пайплайна данных

149

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

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

  

150

Глава 5. Строим бронзовый уровень

могут понадобиться такие специализированные инструменты, как Azure Functions
(https://oreil.ly/wGFO2).
Главный вывод заключается в том, что специфика процесса загрузки данных
сильно зависит от характеристик системы-источника и природы обрабатываемых данных. Понимание этих факторов очень важно для проектирования
эффективной стратегии загрузки данных. Решения «на все случаи жизни» не
существует; каждый сценарий требует адаптированного под ситуацию уникального подхода.
Реализация и управление бронзовым уровнем сильно отличаются в разных организациях. Изменчивость зависит от требуемой гибкости, природы источников
данных и конкретных организационных требований. Эти факторы приводят к различиям в подходах к реализации таблиц и управлению схемой. При разработке
следует принимать во внимание следующие особенности:
Структура партиционирования данных
Переключение с плоской схемы партиционирования ГГГГММДД на иерархическую схему ГГГГ/ММ/ДД улучшает управляемость данных и производительность запросов. Оно делает возможным точное отсечение по дате, снижает
потери от хранения большого количества файлов в одном каталоге и упрощает
такие операции, как удаление и архивация данных, за счет организации данных
в более удобные блоки.
Логирование и метрики
При загрузке данных очень важно отслеживать ход процесса для целей аудита и диагностики. На практике эта задача решается сохранением в журнале
метрик каждого датасета, обрабатываемого на бронзовом уровне. Например,
с Data Factory можно обращаться к метрикам из свойства .output.runStatus.
metrics, регистрируя такие подробности, как количество прочитанных и записанных строк данных, а также время обработки до приемника.
Также при работе с потоковыми данными или данными реального времени
метрики QueryProgress из Apache Spark Structured Streaming предоставляют разностороннюю информацию о выполнении потоковых запросов. Эти
метрики включают такую важную информацию, как количество входных
и обработанных строк за секунду, продолжительность обработки пакета и задержка сохранения в приемнике. Понимание этих метрик поможет понять
и оптимизировать производительность потокового пайплайна.
Кроме того, будет полезно реализовать задания постобработки, которые
сравнивают количество строк и суммы в исходных данных по всем уровням
архитектуры медальона. Такие проверки помогают выявить все несогласованности и ошибки в данных. Желательно выполнять эти задания проверки после
каждого инкрементального обновления для обеспечения целостности данных.

  

Создание пайплайна данных

151

Реализация логирования
В текущей конфигурации не хватает средств ведения журнала, которые связаны с механизмами мониторинга, обсуждавшимися в предыдущем пункте.
Чтобы масштабировать и повышать надежность обработки данных, я рекомендую реализовать механизм ведения журнала с целью сохранения основной
информации для мониторинга и диагностики. Для его разработки можно
воспользоваться такими сервисами, как Azure Monitor (https://oreil.ly/ndUub)
или Azure Log Analytics (https://oreil.ly/CH-c3), или же разработать кастомное
решение, например с использованием Azure SQL.
Настройка автоматических триггеров
Оркестрацию пайплайнов данных можно улучшить некоторыми функциями,
например, автоматически запускающими пайплайны загрузки данных при
появлении новых данных. За практическим примером обращайтесь к статье
Create a Trigger that Runs a Pipeline in Response to a Storage Event (https://oreil.
ly/ZV-SZ).
Создание совместно используемых библиотек
Общие библиотеки с хорошей документацией и тестами могут заметно повысить эффективность команд данных, работающих в рамках организации.
Для улучшения масштабируемости я рекомендую разработать скрипты для
преобразований технических форматов файлов, деструктуризации сложных
структур и операций добавления (append). Такие скрипты можно повторно
использовать между пайплайнами, экономя время и усилия. Храните их
в общем репозитории кода.
Создание универсальных пайплайнов, получающих информацию из метаданных
Вместо создания отдельного пайплайна для каждого типа данных можно использовать механизм, основанный на метаданных, и настроить универсальные пайплайны, автоматически регулируемые на основе предоставленных
метаданных. Такое решение значительно снижает необходимость в написании
и обслуживании большого объема кода. Конкретный пример такого рода приведен в главе 6.
Параметризация сервиса для получения динамических значений во время
выполнении
Сервис можно параметризовать, чтобы он получал динамические значения
во время выполнения. Например, для подключения к разным базам данных
на одном логическом сервере SQL можно параметризовать имя базы данных
в определении связанного сервиса. Подробнее об этом см. в разделе «Метод,
основанный на метаданных», с. 169 и в статье Parameterize Linked Services in
Azure Data Factory and Azure Synapse Analytics (https://oreil.ly/osBjY).

  

152

Глава 5. Строим бронзовый уровень

Использование шаблонов Data Factory
Шаблоны, поставляемые с Data Factory, предоставляют готовые пайплайны,
которые помогут быстро начать работу с Data Factory. Более полная информация доступна на GitHub (https://oreil.ly/vJjTP).
Развертывание интеграционных модулей для конкретных сетевых требований
Сетевые требования могут усложнить конфигурацию системы. Например,
если вам нужно обратиться к локальным источникам данных или сервисам из
других виртуальных сетей, возможно, вам придется развернуть интеграционный модуль в виртуальной сети. Узнать больше можно в статье Data Factory
Integration Runtime (https://oreil.ly/9nYs1).
Решение проблем безопасности данных
Соображения безопасности данных, особенно при работе с персональной
информацией или другими конфиденциальными данными, могут усложнить
процесс загрузки данных. Возможно, вам придется фильтровать конфиденциальные данные, применять шифрование или динамическую маскировку
данных. За дополнительной информацией обращайтесь к статье PII Detection
and Masking (https://oreil.ly/eUIjh).
Перепроектирование для решения проблем производительности
Проблемы с производительностью могут потребовать перепроектирования
стратегий загрузки данных. Рассмотрите такие варианты, как режим Parallel
Copy действия CopyActivity в Data Factory, для повышения пропускной
способности или переход на инкрементальную загрузку и обработку дельтаприращений вместо полного извлечения данных.
Мы успешно настроили необходимые конфигурации в пайплайне данных и импортировали сырые файлы Parquet в сущность Lakehouse бронзового уровня.
Но работа еще не закончена. Следующий важный шаг — сделать данные более
доступными и готовыми для более глубокой обработки. Далее в этой главе мы
настроим реальные таблицы Lakehouse, а потом займемся управлением схемой.

Реализация таблиц Lakehouse
До сих пор мы сохраняли данные в файлах Parquet. Однако бронзовый уровень —
это не только хранилище для файлов; он играет важнейшую роль в обеспечении
однородности и доступности данных. Далее мы проведем дополнительную обработку данных, чтобы к ним можно было обращаться с запросами и они были
доступны для дальнейшего использования.
В следующих разделах рассмотрим различные паттерны загрузки данных, их
преобразования и создания таблиц. Более полное понимание этих паттернов
поможет вам спроектировать стратегию загрузки данных, адаптированную для

  

Реализация таблиц Lakehouse

153

своих спе­ци­фических потребностей и целей. Помните, что главной функцией
бронзового уровня является загрузка данных в их сыром, непреобразованном
состоянии; это делает возможной отправку к ним запросов в целях исследований
и ситуативного анализа, а также обеспечивает основу для дальнейшей обработки
данных.
Для начала разберемся, как читать данные и напрямую выводить их в таблицы
Delta. Затем рассмотрим использование внешних таблиц для других сервисов на
базе Spark. После этого исследуем методы загрузки данных реального времени
(например, Spark Structured Streaming и CDC), что ускоряет обновления на
бронзовом уровне. К концу этого раздела вы начнете лучше понимать паттерны,
которые делают данные пригодными для запросов, а также последствия выбора
каждого варианта.

Перенос файлов Parquet в управляемые таблицы Delta
До сих пор мы рассматривали пакетный процесс, который включает обработку
больших объемов данных за один раз — в отличие от обработки записей данных
по одной или непрерывно. Мы использовали Data Factory для переноса таблиц
из базы данных AdventureWorks и сохранения их в формате Parquet. Этот шаг
сам по себе еще не делает данные готовыми для запросов и анализа. Чтобы к ним
можно было обращаться напрямую в новой среде, мы создадим таблицы Delta.
Создание таблиц Delta обеспечивает соответствие принципам ACID, что гарантирует целостность данных и надежность при параллельных операциях чтения
и записи. Таблицы Delta также поддерживают такие расширенные возможности,
как перемещение во времени и эффективные обновления/вставки и удаления,
повышающие надежность и гибкость данных.
Чтобы создать таблицы Delta в Microsoft Fabric (и, возможно, в Azure Databricks),
необходим скрипт, который может вызываться из пайплайна данных. Перейдите
к сущности Workspace из навигационной панели в левой части экрана и вернитесь к пайплайну данных, созданному в последней части рассматриваемого нами
примера. Затем откройте действие ForEach и интегрируйте новое действие Notebook, перетащив его в рабочий поток. После этого обновите настройки Notebook,
задав следующие параметры конфигурации в разделе Base parameters (Основные
параметры):
schemaName

Задайте значение adventureworks.
tableName

Задайте значение @item().table_name, чтобы имя таблицы передавалось динамически.
filePath

  

154

Глава 5. Строим бронзовый уровень

Используйте значение @formatDateTime(utcnow(), 'yyyyMMdd') для генерирования пути, включающего текущую дату. Это поможет организовать или партиционировать данные по дате.
Подробная настройка действия Notebook показана на рис. 5.8.

Рис. 5.8. Подробности конфигурации действия Notebook
Затем перейдите к Workspace и создайте новый блокнот, в котором будет размещаться скрипт для создания таблиц Delta. Этот скрипт будет выполнять следующие задачи в указанном порядке:
1. Получение параметров (schemaName, tableName и filePath) из параметров Data
Factory.
2. Создание схемы Lakehouse, если она еще не существует, с использованием
заданного имени schemaName.

  

Реализация таблиц Lakehouse

155

3. Удаление существующей таблицы.
4. Чтение данных из файла Parquet и их загрузка в DataFrame.
5. Добавление столбца loading_date в каждый датасет на бронзовом уровне
для регистрации текущей даты и времени загрузки данных. Метка времени
упрощает отслеживание изменений и аудит; она необходима для реализации таких функций, как SCD2, которым точный хронометраж изменений
или добавлений записей необходим для поддержания корректных версий.
В этом примере будет добавлен только один столбец. В реальной ситуации мы бы включили еще столбцы метаданных: source_system, lineage_id
и т. д.
6. Наконец, скрипт записывает содержимое DataFrame в таблицу Delta с использованием параметров, переданных Data Factory. Опция mode("overwrite")
гарантирует, что если таблица уже существует, она будет перезаписана новыми
данными.
В этом разделе будет рассмотрен метод удаления таблиц и перезаписи их
новыми данными — он особенно хорошо подходит для обработки поставок
данных целиком. В этом случае все начнется «с чистого листа» из-за удаления
устаревшей информации, и данный метод не подойдет для дельта-поставок,
включающих только инкрементальные обновления. В разделе «Создание
таблиц без определения схем» на с. 164 описан альтернативный метод, адаптированный для дельта-поставок или накопления данных.

Новый блокнот откроется через несколько секунд после создания и будет содержать единственную ячейку. Блокноты состоят из одной или нескольких ячеек
с кодом или разметкой Markdown (отформатированным текстом). Когда блокнот
откроется, переименуйте его и присвойте ему имя load_bronze (https://oreil.ly/CXdAB) — выберите текст Notebook в левой верхней части блокнота и введите новое
имя. Не забудьте выбрать в меню слева сущность Lakehouse бронзового уровня,
чтобы убедиться в том, что вы находитесь в правильной среде.
Весь код и скрипты доступны на GitHub (https://github.com/pietheinstrengholt/

building-медальона-architectures-book).

Теперь вставьте в ячейку следующий код:
# Вывод базовых параметров по контексту пайплайна
schemaName = ""
tableName = ""
filePath = ""

После вставки кода переключите режим Toggle parameter cell (Переключить параметры ячейки) при помощи многоточия в правом верхнем углу ячейки. Этот шаг
обязателен, он позволяет задать параметры (https://oreil.ly/PZ-BQ) в ячейке. После

  

156

Глава 5. Строим бронзовый уровень

этого создайте новый блок кода, щелкнув « +» в нижней части ячейки. Вставьте
в новый блок следующий код1:
# Импорт функций
from pyspark.sql.functions import current_date
# Создание схемы
spark.sql(f'CREATE SCHEMA IF NOT EXISTS {schemaName}')
# Удаление таблицы
spark.sql(f'DROP TABLE IF EXISTS {schemaName}.{tableName}')
# Чтение данных
df = spark.read.parquet(f"Files/{schemaName}/{filePath}/{tableName}.parquet")
# Добавление столбца метаданных loading_date с текущей датой
df = df.withColumn("loading_date", current_date().cast("string"))
# Перезапись таблицы
df.write.mode("Overwrite").saveAsTable(f"{schemaName}.{tableName}")

После подготовки блокнота вернитесь к пайплайну Data Factory и снова запустите его. Если вся конфигурация задана верно, новые имена таблиц должны появиться в базе данных adventureworks в сущности Lakehouse бронзового уровня.
Пример показан на рис. 5.9.
Создавая таблицы Delta на бронзовом уровне, вы совершаете большой шаг
к тому, чтобы сделать данные пригодными для запросов и готовыми к анализу.
Например, теперь можно легко отправлять запросы к данным с использованием
команд SQL или наглядно представить данные при помощи таких сервисов, как
Power BI. Кроме того, таблицы Delta обеспечивают целостность данных и делают
возможными такие расширенные функции, как перемещение во времени (time
travel) и эффективные обновления/вставки и удаления. Данные, которые теперь
хранятся в формате таблицы Delta, позволяют эффективно решать последующие
задачи проектирования серебряного уровня.
Создание таблиц Delta завершает учебный пример построения бронзового уровня. Тем не менее стоит упомянуть и о других подходах. Например, существуют
сценарии, требующие работы с внешними таблицами, особенно с большими датасетами, к которым нужно обращаться с запросами без загрузки в управляемую
среду. Эти методы будут рассмотрены в следующих разделах.

1

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

  

Реализация таблиц Lakehouse

157

Рис. 5.9. Обзор таблиц Delta бронзового уровня

Использование внешних таблиц
Внешние таблицы уже упоминались в главе 1. Эти таблицы позволяют запрашивать данные, хранящиеся за пределами управляемой среды, например данные из
таких систем внешнего хранения, как HDFS или ADLS.
Хотя на момент написания книги Microsoft Fabric не поддерживает создание
внешних таблиц для сущностей Lakehouse с включенной схемой1, это можно делать во многих других платформах на базе Spark. Например, в Azure Databricks
для создания внешней таблицы можно воспользоваться командой CREATE TABLE
с условием LOCATION. Просто укажите местоположение таблицы в качестве пути
к файлам Parquet в ADLS. Скрипт начинается с получения параметров, переданных из Azure Data Factory, при помощи действия Databricks Notebook (https://
oreil.ly/iA6s6). Затем он переходит к созданию новой схемы, гарантируя, что любые
ранее существующие таблицы с тем же именем будут удалены.
1

Если вы настраиваете внешние таблицы в сущностях Lakehouse без включенной схемы,
ознакомьтесь с познавательным блогом Айтора Мургузура (Aitor Murguzur) (https://oreil.
ly/CVteO).

  

158

Глава 5. Строим бронзовый уровень

А вот как создать внешние таблицы с использованием скрипта Python script
(https://oreil.ly/AZLJ6):
# Получение параметров от Data Factory
schemaName=dbutils.widgets.get("schemaName")
tableName=dbutils.widgets.get("tableName")
filePath=dbutils.widgets.get("filePath")
# Создание базы данных
spark.sql(f'CREATE SCHEMA IF NOT EXISTS bronze_{schemaName}')
# Удаление таблицы
spark.sql(f'DROP TABLE IF EXISTS bronze_{schemaName}.{tableName}')
# Создание новой внешней таблицы с использованием каталога для текущей даты/
времени
ddl_query = f"""
CREATE TABLE bronze_{schemaName}.{tableName}
USING PARQUET
LOCATION '/mnt/bronze/
{schemaName}/{filePath}/{tableName}.parquet'
"""
# выполнение запроса
spark.sql(ddl_query)

Использование внешних таблиц просто и прямолинейно; они не требуют дублирования данных. Тем не менее при этом необходимо учитывать ряд особенностей:
Чтение из внешних таблиц Parquet обычно выполняется медленнее чтения
из таблиц Delta. Такое снижение производительности возникает, например,
из-за субоптимального партиционирования, которое влияет на обращения
и обработку данных.
В отличие от управляемых таблиц Delta у внешних таблиц Parquet отсутствует
поддержка таких продвинутых функций, как контроль за соблюдением схемы
и time travel, для более совершенного управления данными и аналитики.
Использование внешних таблиц — простой и понятный способ настройки пайп­
лайна данных. Он не является чем-то неправильным и может хорошо подойти для
ваших конкретных требований. Тем не менее это не самый оптимизированный
метод. В следующем разделе вы узнаете, как организовать более эффективное
чтение и вывод данных.

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

  

Реализация таблиц Lakehouse

159

(обновления и новые записи) при помощи сложных фильтров. В таких случаях
как раз и пригодятся операции слияния.
Delta Lake поддерживает операции MERGE, которые выполняют слияние новых
данных с существующими таблицами. Эта возможность особенно полезна для
обновления или вставки данных в таблицах. Пример скрипта с использованием
MERGE в SQL (https://oreil.ly/mBlLe):
MERGE INTO Bronze_Customer AS t
USING Landing_Customer AS s
ON t.CustomerID = s.CustomerID
WHEN MATCHED THEN
UPDATE SET
t.Name = s.Name,
t.ContactDetails = s.ContactDetails,
t.PurchaseHistory = s.PurchaseHistory
WHEN NOT MATCHED THEN
INSERT (CustomerID, Name, ContactDetails, PurchaseHistory)
VALUES (s.CustomerID, s.Name, s.ContactDetails, s.PurchaseHistory);

Операция слияния чрезвычайно гибка; она поддерживает множество различных
условий: WHEN MATCHED, WHEN NOT MATCHED, WHEN MATCHED AND, WHEN NOT MATCHED BY
TARGET, WHEN NOT MATCHED BY SOURCE и т. д. Эти условия позволяют определять различные действия на основании критериев совпадения и предоставляют мощный
инструмент для управления инкрементальными загрузками данных.
Тот же код можно выполнить в скрипте Python через DeltaTable API (https://oreil.
ly/kpqCv), используя возможности параметризации кода аргументами.
from delta.tables import *
dTable = DeltaTable.forPath(spark, \
f"abfss://{workspaceId}@onelake.dfs.fabric.microsoft.com/ \
{lakehouseId}/Tables/{schemaName}/{tableName}")
(dTable.alias("original")
.merge(df.alias("updates"), f"original.{primaryKey} = updates.{primaryKey}")
.whenMatchedUpdateAll()
.whenNotMatchedInsertAll()
.execute()
)

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

  

160

Глава 5. Строим бронзовый уровень

После исследования различных пакетно-ориентированных методов обработки
данных перейдем к Spark Structured Streaming — универсальному решению загрузки потоковых данных.

Spark Structured Streaming
Потоковая обработка — метод, основанный на загрузке сообщений из очередей
или файлов, выполнении некоторой обработки (запросы, фильтры, агрегирование) и последующей отправке результатов в приемник с минимальной задержкой.
Потоковая обработка отличается от пакетной или микропакетной обработки1,
которая обычно выполняется на периодической основе.
Технология Spark Structured Streaming — отличное решение для потоковой
обработки в реальном времени благодаря своей универсальности и бесшовной
интеграции с любой платформой на базе Spark. Как обсуждалось в главе 3, Spark
Structured Streaming особенно хорошо работает в сценариях, требующих низкой
задержки ответа, так как позволяет обрабатывать данные в реальном времени.
Например, Spark Structured Streaming может использоваться для обработки
данных от IoT-устройств, периферийных устройств или других источников данных реального времени, таких как финансовые транзакции или журналы работы
оборудования.
Рассмотрим практический пример создания системы мониторинга воздушных
судов в реальном времени. В таком сценарии Azure Event Hubs может использоваться для загрузки данных от датчиков и устройств на каждом самолете
и последующей обработки этих данных в реальном времени с использованием
Spark Structured Streaming. Задача может решаться на таких языках программирования, как C#, Java, Python или Node.js. Пример этой архитектуры показан
на рис. 5.10.
Загрузка
в реальном
времени
Системы
реального
времени

Azure
Event
Hubs

Microsoft Fabric
Обработка
Коннектор

Spark Structured Streaming

Bronze
(Lakehouse)

DirectQuery
Отчеты

Рис. 5.10. Архитектура с загрузкой данных в Event Hubs с использованием Spark Structured Streaming

1

Операция foreachBatch (https://oreil.ly/ttjm3) в Apache Spark используется в основном со
Structured Streaming для применения логики обработки к каждому микропакету потока.

  

Реализация таблиц Lakehouse

161

Одним из преимуществ Spark Structured Streaming является поддержка сложной обработки событий, позволяющая обрабатывать нетривиальные запросы
и объединение потоков со статическими данными или другими потоками. Эта
особенность важна для приложений, требующих расширенной аналитики, например рекомендательных систем или систем отслеживания активности пользователей. Например, в соответствии с приведенной выше диаграммой, Oceanic
Airlines может воспользоваться Spark Structured Streaming для мониторинга
своего авиа­парка в реальном времени. При возникновении нештатной ситуации
(скажем, плохих погодных условий) поток событий может мгновенно уведомить
заинтересованные стороны. Это позволяет быстро принимать решения о перенаправлении самолетов или реализовать необходимые меры для обеспечения
безопасности. Spark Structured Streaming можно расширить интеграцией с Azure
Event Hubs, как обсуждается в следующем разделе.

Пример использования Azure Event Hubs
Чтобы настроить Spark Structured Streaming в Spark в сочетании с Azure Event
Hubs (https://oreil.ly/WUo2f), используйте следующий фрагмент кода (https://oreil.
ly/eUWVD):
# Библиотека, позволяющая выполнять потоковую передачу из Azure Event Hubs
%pip install azure-eventhub
ehConf = {}
# Конфигурация подключения к Azure Event Hubs
connectionString = "Endpoint=sb://{NAMESPACE}.servicebus.windows.net/ \
{EVENT_HUB_NAME};EntityPath={EVENT_HUB_NAME}; \
SharedAccessKeyName={ACCESS_KEY_NAME}; \
SharedAccessKey={ACCESS_KEY}"
# Для версий 2.3.15 и выше словарь конфигурации требует,
# чтобы строка подключения была зашифрована
ehConf['eventhubs.connectionString'] = sc._jvm.org.apache.spark.eventhubs \
.EventHubsUtils.encrypt(connectionString)
# Потоковая передача данных из Azure Event Hubs
df = spark \
.readStream \
.format("eventhubs") \
.options(**ehConf) \
.load()
# Запись потока: сохранение потоковых данных в таблице Delta
df.writeStream \
.option("checkpointLocation","abfss://<abfss_location>") \
.outputMode("append") \
.format("delta") \
.toTable("bronze.weather")

  

162

Глава 5. Строим бронзовый уровень

Процесс начинается с установки необходимой библиотеки для потоковой передачи контента из Azure Event Hubs. Затем настраивается конфигурация подключения, включая строку подключения, которая шифруется для целей безопасности.
Затем данные передаются из Event Hubs в структуру DataFrame, которая затем
может быть записана в таблицу Delta на бронзовом уровне. Задается местоположение контрольной точки для хранения метаданных потокового запроса; они обес­
печивают отказоустойчивость и позволяют перезапустить запрос в случае сбоя.
Кроме записи потоковых данных на бронзовый уровень можно продолжить
обработку DataFrame с использованием Spark Structured Streaming. Эта технология позволяет выполнить фильтрацию, очистку и преобразование данных.
Очищенный вывод также можно сохранить прямо на серебряном уровне, где он
становится доступным для более сложного анализа и создания отчетов. Этот
шаг значительно повышает качество и доступность данных для последующих
процессов. Мы вернемся к этой теме в главе 6.
Хотя в этом разделе наше внимание сосредоточено на обработке и преобразовании
данных с использованием Spark Structured Streaming, важно учитывать, каким
образом данные изначально попадают в систему. Так мы подходим к концепции
CDC, которая играет важнейшую роль в сохранении изменений из различных
источников данных перед их обработкой. Хотя оба метода улучшают обработку
данных, CDC концентрируется на исходном сохранении изменений в данных,
подготавливая их к последующей обработке и анализу.

Использование CDC
Механизм CDC (change data capture) используется для отслеживания изменений
в базе данных. Он захватывает изменения, вносимые в данные: вставки, обновления, удаления и т. д. — и сохраняет их в отдельной таблице. CDC особенно
полезен для репликации данных в реальном времени. Отслеживание изменений
позволяет поддерживать точное и актуальное представление данных.
Например, Microsoft Fabric поддерживает CDC посредством зеркалирования.
С этой функцией базы данных (как в нашем примере AdventureWorks) могут
напрямую реплицироваться в OneLake из Fabric (см. Tutorial: Configure Microsoft
Fabric Mirrored Databases from Azure SQL Database (https://oreil.ly/XIxBI)).
Кроме уже рассмотренных механизмов CDC, подключение поставки изменений в данных, особенно в архитектурах озер-хранилищ с использованием
Delta Lake и Spark, может значительно повысить эффективность репликации
данных. Этот метод открывает возможность более детализированного отслеживания изменений в данных, включая вставки, обновления и удаления,
за счет предоставления оптимизированного и масштабируемого доступа
к записям изменений.

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

  

Управление схемой

163

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

Методы обработки данных
Мы исследовали различные методы обработки данных, значительно расширяющие возможности управления информацией и ее обработки. Мы начали с перехода от файлов Parquet к управляемым таблицам Delta, которые обеспечивают
повышенную производительность и возможность перехода во времени между
версиями данных. Далее рассмотрели применение внешних таблиц для непосредственного доступа к данным. Отметили эффективность обновления таблиц
операциями MERGE, полезными в сценариях, когда нужно обработать только необходимые изменения (например, обновления и новые записи). Также обсудили
применение Spark Structured Streaming для выполнения преобразований данных
в реальном времени и механизм CDC, который воплощает паттерн «нулевого
ETL» посредством зеркалирования или сохранения изменений в базах данных
в реальном времени.
Каждый из этих паттернов играет ключевую роль в современных архитектурах
данных. При этом важно оценивать их с учетом конкретного сценария и сложностей, связанных с получением данных. Часто в системе используется комбинация нескольких методов, приспособленных под специфические потребности
архитектуры.
После исследования методов обработки данных и факторов, которые следует
учитывать при их использовании, необходимо рассмотреть другую основополагающую область: управление схемой. Понимание и изучение стратегий управления
схемой очень важно, так как эти стратегии образуют основу практических примеров, к которым мы обратимся в главе 6.

Управление схемой
Как подчеркивалось в разделе «Эволюция и управление схемой» главы 3 с. 80,
управление схемой и ее эволюцией чрезвычайно важно, особенно на бронзовом
уровне, который служит первичным репозиторием для сырых данных, хранящихся в исходной форме. Схему можно представить как план, описывающий
структуру данных с определениями типов данных и отношений между разными
элементами данных.
Существует несколько вариантов управления схемами, каждый из которых
имеет свои достоинства и недостатки. Начнем с изучения самого простого

  

164

Глава 5. Строим бронзовый уровень

и самого гибкого метода, а затем перейдем к более структурным и формальным
вариантам.

Создание таблиц без определения схем
Один из простейших методов генерирования таблиц в озере-хранилище заключается в том, чтобы не определять никакие схемы, поручая управление
эволюцией схем Delta Lake. Например, представьте сценарий, когда вы хотите
избежать воссоздания таблиц при каждом запуске пайплайна по аналогии
с предыдущим примером и вместо этого присоединять и накапливать данные,
доверяя функциональности эволюции схем Delta Lake обрабатывать структуры данных, загружаемых со временем. Кроме того, для повышения производительности можно провести партиционирование данных по дате загрузки.
В таком случае можно использовать следующий фрагмент кода (https://oreil.
ly/RAgf):
from delta.tables import *
from pyspark.sql.functions import current_date
# Удаление любых существующих данных
if (DeltaTable.isDeltaTable(spark, f"{schemaName}.{tableName}")):
spark.sql(f"DELETE FROM {schemaName}.{tableName} \
WHERE loading_date = current_date()")
# Чтение данных
df = spark.read.parquet(f"Files/{schemaName}/{filePath}/{tableName}.parquet")
# Добавление столбца с датой загрузки в DataFrame
df = df.withColumn("loading_date", current_date())
# Запись данных в таблицу Delta со слиянием схем
df.write.format("delta") \
.mode("append") \
.partitionBy("loading_date") \
.option("mergeSchema", "true") \
.saveAsTable(f"{schemaName}.{tableName}")

В этом примере Delta Lake объединяет схему новых данных с существующей
схемой таблицы Delta. Включая параметр mergeSchema в эту операцию, Delta Lake
управляет эволюцией схемы. Это означает, что любые столбцы, присутствующие
в DataFrame, но не в целевой таблице, автоматически добавляются в конец схемы
как часть транзакции записи. Обратите внимание: в этом примере мы повторно
используем такие имена переменных, как schemaName, tableName и filePath,
для представления имени схемы, имени таблицы и пути соответственно. Для
Microsoft Fabric, а также Azure Databricks вы можете заменить их собственными
значениями.
Такой метод накопления данных прост и гибок. Он позволяет присоединять новые
данные к существующим таблицам без определения схем. Эта гибкость особенно

  

Управление схемой

165

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

Определение схем через DataFrame API
Определение схем через DataFrame API (https://oreil.ly/S7Y-0) — еще один способ
определения схем в озерах-хранилищах. Следующий пример кода (https://oreil.
ly/jy-vn) показывает, как он работает:
from pyspark.sql.types import *
# Определение схемы
schema = StructType([
StructField("CustomerID", IntegerType(), True),
StructField("NameStyle", BooleanType(), True),
StructField("Title", StringType(), True),
StructField("FirstName", StringType(), True)
])
# Чтение сырых данных JSON и применение схемы
df = spark.read.schema(schema).json("/path/to/raw/data")
# Запись DataFrame в таблицу Delta
df.write.format("delta").saveAsTable("adventureworks.customer")

DataFrame API отлично подходит для управления сложными и вложенными
структурами данных в Spark, особенно с неструктурированными данными. Он
может использоваться с методом определения схемы при чтении, при котором
необходимая схема (скажем, имена столбцов и типы данных) задается в запросе к сырым данным при загрузке в Spark (с использованием DataFrame). Если
успешно применить схему не удается, проблему можно решить реализацией
логики обработки ошибок в коде.
Перейдем к другому методу: использованию команд языка определения данных
SQL, который может упростить процесс создания таблиц непосредственно из
блокнотов. Этот подход определения схемы при записи дополняет стратегию
определения схемы при чтении, так как он позволяет определять и обеспечивать
принудительное соблюдение структур данных в точке записи данных.

  

166

Глава 5. Строим бронзовый уровень

Команды SQL DDL
Следующий вариант — написание команд языка определения данных (DDL, Data
Definition Language) прямо в блокнотах Spark. Этот способ особенно полезен там,
где важны согласованность и целостность данных.
Следующая команда SQL DDL создает схему с именем adventureworks1:
CREATE SCHEMA adventureworks

Добавьте следующую команду SQL DDL (https://oreil.ly/ijBDm), которая создает
таблицу с именем customer в схеме adventureworks:
CREATE TABLE customer (
CustomerID INT COMMENT 'Идентификатор клиента',
NameStyle BOOLEAN COMMENT 'Стиль именования',
Title STRING COMMENT 'Название клиента',
FirstName STRING COMMENT 'Имя клиента'
)
USING delta

Включение команд DDL в блокноты Spark, как показано выше, позволяет эффективно создавать таблицы с возможностью быстрой настройки и управления
структурой базой данных прямо в среде блокнота. Кроме того, так как многие
другие (реляционные) базы данных используют команды SQL DDL, этот способ
идеально подходит для сценариев с миграцией или репликацией схемы или повторного использования существующего кода DDL, обеспечивая совместимость
и простоту интеграции между разными платформами.
В других средах на базе Spark определение местоположения в команде
CREATE TABLE назначает таблицу как внешнюю.

DataFrame API и команды SQL DDL — мощные инструменты настройки схем, но
их сложность может затруднить управление нетривиальными структурами данных. Проблему можно решить, позволив приложению экспортировать DDL как
часть процесса сборки либо использовать метод определения схемы при записи
в сочетании с параметром mergeSchema. Последний метод обеспечивает строгую
согласованность данных наряду с гибкостью при изменении требований к данным.
Еще один вариант — управление схемами с использованием отдельных файлов
конфигурации. В следующем разделе вы узнаете, как это работает.
1

Команда %%sql в средах на базе Spark — «волшебная» команда (https://oreil.ly/O8nKy),
которая позволяет пользователям выполнять запросы Spark SQL к данным, хранящимся
в разных источниках — таблицах, представлениях, внешних базах данных и т. д. При
выполнении команды %%sql пользователи могут напрямую записывать код Spark SQL
в блокнот и запрашивать данные без необходимости создания DataFrame или регистрации временной таблицы.

  

Управление схемой

167

Конфигурации в YAML или JSON
Использование конфигурации в формате YAML или JSON — еще один эффективный метод определения схем. Этот способ хорошо работает, когда возникает
необходимость хранения определений схемы в отдельном файле, который затем
может многократно использоваться в различных блокнотах или проектах. Язык
YAML особенно удобен благодаря своему формату, понятному для человека.
Простота и ясность делают его идеальным для файлов конфигурации и обмена
данными, где особенно важна читабельность.
Кроме того, YAML весьма гибок. Он позволяет легко добавлять дополнительные
метаданные или комментарии. Например, для каждого столбца можно включить
флаг персональной информации, который сообщает, содержит ли этот столбец
чувствительные данные. Другое важное преимущество YAML или JSON заключается в том, что контроль версий этих файлов может осуществляться отдельно
от основного кода. Это отличие позволяет командам эффективно отслеживать
изменения схемы базы данных со временем и управлять ими.
Вот как может выглядеть определение схемы в формате YAML в файле schema.
yaml:
columns:
- name: CustomerID
type: integer
- name: NameStyle
type: boolean
- name: Title
type: string
- name: FirstName
type: string
PII: true

Для интеграции YAML в блокнот можно воспользоваться пакетом PyYAML.
В следующем примере загружается файл YAML, который используется для
генерирования схемы PySpark из содержащихся данных. Этот фрагмент кода
(https://oreil.ly/cLx7O) содержит две функции Python, которые созданы специально для использования PySpark и YAML с целью обработки схемы, описанной
в файле YAML.
Чтобы воспроизвести этот пример, установите пакет PyYAML командой pip

install PyYAML.

Функция load_yaml_file получает на входе путь и читает файл YAML. Она
использует yaml.safe_load() для безопасного парсинга контента YAML в каталог Python. Затем функция generate_schema_from_yaml на входе получает
эти данные YAML. Сначала она извлекает из данных список столбцов, а затем

  

168

Глава 5. Строим бронзовый уровень

перебирает все столбцы, проверяет тип данных и добавляет соответствующее
поле StructField в объект StructType на основании типа столбца (integer, string,
boolean, datetime). Эти функции выглядят так:
import yaml
from pyspark.sql.types import *
# Функция для загрузки файла YAML
def load_yaml_file(yaml_file_path):
with open(yaml_file_path, 'r') as file:
schema_yaml = yaml.safe_load(file)
return schema_yaml
# Функция для генерирования схемы PySpark по данным YAML
def generate_schema_from_yaml(yaml_data):
columns = yaml_data['columns']
schema = StructType()
for column in columns:
if column['type'] == 'integer':
schema.add(StructField(column['name'],
elif column['type'] == 'string':
schema.add(StructField(column['name'],
elif column['type'] == 'boolean':
schema.add(StructField(column['name'],
elif column['type'] == 'datetime':
schema.add(StructField(column['name'],

IntegerType(), True))
StringType(), True))
BooleanType(), True))
Datetime(), True))

return schema

Схема, сгенерированная по файлу YAML, может использоваться для определения
схемы DataFrame. Пример использования функций для загрузки файла YAML
и генерирования схемы PySpark:
# Загрузка файла YAML
schema_yaml = load_yaml_file('/path/to/schema/schema.yaml')
yaml_data = load_yaml_file(schema_yaml)
schema = generate_schema_from_yaml(yaml_data)
# Определение DataFrame со схемой
df = spark.createDataFrame(data, schema=schema)

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

  

Управление схемой

169

В примере выше используется простая схема с несколькими столбцами, но он
легко расширяется на более сложные схемы с вложенными структурами и дополнительными данными. Также его можно расширить для генерирования команд
SQL DDL по данным YAML перед созданием таблицы в озере-хранилище. Это
может быть полезно при включении более сложных типов данных или ограничений в определение схемы1.
У такого подхода всего один недостаток: разметка JSON или YAML может стать
большой и громоздкой для сложных схем. Например, если ваша схема содержит сотни столбцов или сложных вложенных структур, файл JSON или YAML
окажется сложен для управления. В таких случаях может быть эффективнее
использовать метод, основанный на метаданных (metadata-driven).

Метод, основанный на метаданных
Метод на основе метаданных — более продвинутый механизм определения схем.
Он основан на хранении определений схем в централизованном репозитории
метаданных (например, базе данных или каталоге данных). Репозиторий метаданных содержит информацию о структуре данных, включая имена столбцов,
типы данных, ограничения и отношения между разными элементами данных.
Эти метаданные могут использоваться для динамического генерирования определений схем во время выполнения, что позволяет адаптировать схему к разным
источникам и приемникам данных. В главе 6 вы увидите, как реализовать метод
на основе метаданных с базой данных Azure SQL.
Жако ван Гелдер (Jaco van Gelder) опубликовал функцию, которая мастерски
управляет добавлением новых столбцов в схему базы данных, предотвращая
дублирование или нарушение существующей последовательности столбцов.
С функцией можно ознакомиться на странице GitHub: Jaco’s Schema Evolution
Function (https://oreil.ly/SoWlA).

Реализация решения, управляемого метаданными, может быть сложным и долгим
делом. В качестве альтернативы рассмотрим еще один мощный инструмент —
Databricks Auto Loader. Эта технология использует Structured Streaming во
внутренней реализации и предоставляет возможности, которые расширяют обработку и интеграцию данных как в пакетном режиме, так и в реальном времени.
Хотя эта возможность поддерживается только в Databricks, она может заметно
упростить управление эволюцией схемы.
1

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

  

170

Глава 5. Строим бронзовый уровень

Databricks Auto Loader
Auto Loader (https://oreil.ly/BLcPC) — специфическая функция Databricks, упрощающая процесс загрузки данных в существующие таблицы1. Фактически она
работает как механизм потоковой передачи Spark с добавленной функциональностью пакетной загрузки. При обнаружении файлов Auto Loader сохраняет их
метаданные в хранилище «ключ — значение» (RocksDB), находящемся в области
контрольной точки пайплайна. Этот метод хранения гарантирует, что каждый
блок данных будет обработан ровно один раз. Если произойдет сбой, Auto Loader
продолжит обработку, используя информацию, хранящуюся в контрольной точке.
Эта возможность позволяет поддерживать семантику exactly once («ровно один
раз») при записи данных в Delta Lake, не требуя от вас управления или поддержания какого-либо состояния для отказоустойчивости или точности.
Преимущества Auto Loader особенно ярко проявляются в обработке эволюции
схем. Когда Auto Loader обрабатывает новые файлы, он автоматически вычисляет
схему по этим файлам. По мере эволюции входных данных Auto Loader автоматически интегрирует новые атрибуты схемы, найденные во входных файлах,
с существующей схемой. Это автоматическое слияние означает, что вам не придется беспокоиться о несоответствиях в старых и новых форматах данных. Auto
Loader поддерживает все схемы согласованными и актуальными, обеспечивая
надежное представление данных.
Если вам не требуется автоматическая эволюция схем, можно скорректировать
настройки. Например, если присвоить cloudFiles.schemaEvolutionMode значение
rescue, Auto Loader не будет автоматически обновлять схему. Вместо этого в схему
будет добавлен столбец _rescued_data. Главное преимущество столбца _rescue —
обеспечение гибкой и надежной стратегии управления данными. Сохранение
непредвиденных данных позволяет инженерам и аналитикам проанализировать
изменения структуры данных в удобное время. Если будет решено, что новые
элементы данных должны остаться, содержимое столбца _rescue может быть
обработано ретроспективно. Это гарантирует, что ценные данные не будут потеряны и могут быть интегрированы в основной датасет, обогащая информационные ресурсы организации. Кроме того, это сводит к минимуму необходимость
в немедленных изменениях пайплайнов загрузки данных, а эти изменения могут
быть как деструктивными, так и ресурсоемкими.
Auto Loader также поддерживает различные форматы данных, включая JSON,
CSV, Parquet, Avro, ORC, TEXT и двоичный формат. Auto Loader спроектирован
для инкрементальной загрузки данных из облачного объектного хранилища, но
его можно использовать и для инкрементального копирования всех данных из
заданного каталога в таблицу-приемник.

1

Функция Auto Loader спроектирована специально для работы со средой Databricks и не
работает на других платформах.

  

Управление схемой

171

Следующий фрагмент кода (https://oreil.ly/WTqLI) выполняет полную загрузку
данных как часть проекта Oceanic Airlines. Если вы планируете использовать
Azure Databricks, используйте этот код в исходном виде или измените под конкретные потребности.
# Получение параметров от Azure Data Factory
catalogName="prod_sales"
schemaName=dbutils.widgets.get("schemaName")
tableName=dbutils.widgets.get("tableName")
filePath=dbutils.widgets.get("filePath")
# Получение данных схемы из посадочной зоны
jsonSchema = spark.read.parquet(f"/Volumes/{catalogName}/sources/landing/\
{schemaName}/{filePath}/{tableName}.parquet").schema.json()
ddl = spark.sparkContext._jvm.org.apache.spark.sql.types.DataType \
.fromJson(jsonSchema).toDDL()
# Миграция данных parquet в дельта-файлы
(spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "parquet")
.option("cloudFiles.includeExistingFiles", "true")
.option("cloudFiles.backfillInterval", "1 day")
.option("cloudFiles.schemaLocation", f"/Volumes/{catalogName}/sources/\
landing/{schemaName}/_checkpoint/{tableName}_autoload/")
.schema(ddl)
.load(f"/Volumes/{catalogName}/sources/landing/\
{schemaName}/{filePath}/{tableName}.parquet")
.writeStream
.format("delta")
.option("checkpointLocation", f"/Volumes/{catalogName}/sources/landing/\
{schemaName}/_checkpoint/{tableName}_autoload/")
.trigger(availableNow=True) # Start immediately
.toTable(f"bronze_{schemaName}.{tableName}")
)

Процесс начинается с получения схемы файла Parquet из посадочной зоны. Полученная схема преобразуется в формат DDL, который используется для создания
таблицы в целевой базе данных. При помощи Auto Loader данные Parquet переносятся в созданную таблицу. Параметру backfillInterval задается значение
1 day, чтобы Auto Loader заполнял данные за предыдущий день.
В этом фрагменте кода .schema и .option("cloudFiles.schemaLocation") используются вместе. Это может быть полезно в сценариях, когда требуется обес­
печить и соответствие конкретной схеме, и при этом эволюцию схемы. Вот как
они работают вместе:
Контроль соблюдения схемы
Задавая настройку .schema, вы требуете, чтобы данные соответствовали заданной схеме. Это может предотвратить ошибки при загрузке, если входные

  

172

Глава 5. Строим бронзовый уровень

данные содержат непредвиденные столбцы или типы, которые не соответствуют определенной схеме.
Эволюция схемы
Эта настройка задает место, где хранится и поддерживается схема читаемых
файлов. Задавая .schema значение .option("cloudFiles.schemaLocation"),
вы разрешаете Azure Databricks обрабатывать изменения в схеме со временем. Например, если во входных данных добавляются новые столбцы, Azure
Databricks может обновить схему, хранящуюся в заданном месте, и последующие операции чтения могут распознать эти новые столбцы. Более того,
вы можете задать в настройке cloudFiles.schemaEvolutionMode нужный тип
поведения, например add NewColumns, merge или failOnNewColumns.
После знакомства с возможностями Databricks Auto Loader мы кратко обсудим
некоторые сторонние инструменты, которые могут упростить и ускорить процесс
определения схем, а затем перейдем к последнему вопросу управления схемой:
лучшим практикам эволюции схем.

Сторонние инструменты
Другой возможный вариант определения схем — использование сторонних
инструментов, предоставляющих графический интерфейс для проектирования
и управления схемами. Эти инструменты позволяют визуально конструировать
и изменять определения схем, упрощая работу со сложными структурами данных.
Некоторые популярные инструменты этой категории — SQLAlchemy (https://
sqlalchemy.org), SqlDBM (https://sqldbm.com), erwin Data Modeler (https://erwin.com)
и Hackolade (https://hackolade.com).
Сторонние решения предоставляют средства проектирования схем, интеграции
данных и управления качеством данных, вследствие чего они идеально подходят
для организаций со сложными требованиями к данным. Однако при их использовании важно учитывать и потенциальные недостатки, такие как дополнительные
затраты, усилия по интеграции и возможность привязки к технологии конкретного производителя, что в будущем может ограничить гибкость. Все эти факторы
следует тщательно проанализировать, чтобы быть уверенным, что выбранное
решение соответствует потребностям организации и долгосрочной стратегии.
Перейдем к последней части управления схемой: лучшим практикам.

Эволюция схем
Предварительное определение таблиц имеет ряд преимуществ перед созданием таблиц «на лету» при записи данных в Delta Lake. Оно позволяет лучше контролировать схему таблицы и типы столбцов, что повышает качество данных и сокращает
количество ошибок. Кроме того, предварительное определение таблиц повышает
производительность запросов, обеспечивая эффективное партиционирование.

  

Управление схемой

173

Например, партиционирование данных по столбцу Region позволяет ускорить
запросы к большим датасетам и специфичным названиям компаний.
При управлении эволюцией схемы и создании адаптивной архитектуры следует
учитывать следующие лучшие практики.
Тщательное планирование
Прежде чем вносить в схему изменения, проведите тщательное планирование
и подробно регистрируйте версии схем. Это помогает отслеживать и понимать
эволюцию схемы данных со временем.
Тестирование в безопасной среде
Протестируйте изменение схемы в среде разработки или тестирования, прежде чем запускать его на продакшен. Этот шаг поможет выявить и устранить
потенциальные проблемы без вреда для живых данных.
Поддержание обратной совместимости
Убедитесь, что изменения схемы обладают обратной совместимостью для
сохранения целостности данных. Это позволит избежать нарушения работоспособности существующих запросов и приложений, зависящих от текущей
схемы.
Наличие стратегии отмены
Разработайте стратегию отмены для возврата к предыдущей схеме, если
в процессе миграции что-то пойдет не так. Это минимизирует нарушения
и способствует целостности данных.
Использование инструментов миграции схем
Рассмотрите возможность использования инструментов миграции схем данных, таких как Atlas (https://github.com/ariga/atlas) и Liquibase (https://liquibase.
com), для автоматизации и эффективного управления изменениями схем. Эти
инструменты помогают организовать контроль версий схемы базы данных,
применять инкрементальные изменения и отслеживать изменения схемы со
временем. Также можно извлечь текущие команды DDL из среды разработки
и сохранить их в репозитории кода. Для всех критически важных изменений
напишите процедуру миграции. Например, можно запустить действие GitHub
по пул-реквесту из ветви разработки, автоматически сгенерировать скрипты
миграции, а затем передать эти изменения на продакшен.
Использование методов на основе метаданных или конфигураций YAML
Применение методов на основе метаданных и/или конфигураций YAML позволяет автоматизировать изменения схемы и обеспечить согласованность
между средами. Такой подход упрощает управление схемой и снижает риск
ошибок со стороны человека.

  

174

Глава 5. Строим бронзовый уровень

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

Заключение
Как вы увидели, создание бронзового уровня с возможностью обработки запросов
в архитектуре медальона — задача весьма многогранная. Она требует интеграции
многочисленных компонентов и сервисов, у каждого из которых свои уникальные
проблемы и требования. В этой главе мы успешно интегрировали свой первый источник данных на бронзовый уровень. Мы разработали пайплайн, который перемещает таблицы из базы данных примера на бронзовый уровень, создали блокнот
и загрузили файлы Parquet в виде таблиц Delta в сущности Lakehouse. Также мы
изучили разные подходы к реализации таблиц озер-хранилищ и к управлению
схемой.
Несмотря на прямолинейную природу процесса, методы сбора данных сильно
зависят от сценариев. Сбор данных остается фундаментальной проблемой в инженерии данных из-за своей сложности, а также необходимости в стабильности
и надежности. Как следствие, многие организации разрабатывают множественные пайплайны для управления разнообразными источниками данных, каждый
из которых требует особого подхода, так как решений «на все случаи жизни» не
существует. Выбор правильного паттерна зависит от ряда факторов, включая
типы источников данных, объем данных, флюктуации схем систем-источников
и потребности в обработке. Кроме того, необходимо учитывать конкретные
требования к проектам, такие как обработка в реальном времени или пакетные
задания, а также паттерны поставки данных (например, дельта-поставки или
полные поставки).
Чтобы получить успешный результат и добиться согласованности, очень важно
понимать каждый паттерн в деталях и уметь применять их в разных сценариях.
Я также рекомендую предоставлять подробные руководства и проводить обучение, особенно когда несколько команд инженеров занимаются разными экземплярами платформ в пределах одной организации. Это гарантирует, что все команды
будут действовать согласованно и следовать одним и тем же общим практикам.
Например, если вы имеете дело с периодической пакетной обработкой больших
объемов данных, порекомендуйте командам использовать Data Factory для оркестрации и таблицы Delta для хранения и обработки данных. Для потоковой передачи данных в реальном времени можно рассмотреть Spark Structured Streaming.
А для сценариев, требующих сочетания пакетной обработки с обработкой в реальном времени или прямого доступа к данным, лучшим решением может стать
объединение внешних таблиц для прямых запросов со Structured Streaming для
загрузки и обработки данных. Таким образом, главное — разобраться в особенностях, тщательно проанализировать компромиссы и применять выбранные

  

Заключение

175

методы последовательно. Вот некоторые ключевые выводы, которые помогут
создать надежный бронзовый уровень:
Учтите, что каждый источник данных при интеграции может создавать специ­
фические проблемы, например структурные или сетевые ограничения. Поддерживайте гибкость своих стратегий поступления данных.
Спроектируйте специализированный пайплайн для каждого источника данных и используйте шаблоны для общих фаз обработки с целью поддержания
согласованности и повторного использования.
Разработайте стратегию управления эволюцией схемы и организуйте техническую проверку. В этом может помочь реализация метахранилища.
Организуйте данные по разным схемам или отдельным сущностям Lakehouse
для разных источников, сохраняя соответствие с пайплайнами данных.
Задайте правила о том, будут ли доступны данные бронзового уровня для
конечных пользователей.
В следующей главе мы перейдем к созданию серебряного уровня. Мы продолжим
использовать Microsoft Fabric и обсудим преобразование данных с бронзового
уровня в структурированный формат, оптимизированный для запросов и анализа.
В нем будут задействованы такие операции, как очистка данных, для обеспечения
их качества и надежности. Мы реализуем технические проверки, которые станут
шлюзом между бронзовым и серебряным уровнями и будут встроены в общую
архитектуру в главе 6.

ГЛАВА 6

Строим серебряный уровень
В главе 5 рассматривался фундаментальный дизайн и настройка бронзового
уровня в архитектуре медальона на примере компании Oceanic Airlines. Мы изу­
чили операции развертывания и настройки конфигурации и разобрали многочисленные фрагменты кода и примеров. Вы узнали, что создание бронзового
уровня с возможностью запросов представляет значительную сложность из-за
постоянно развивающейся и сложной природы систем-источников.
На этой основе строится материал главы 6, в которой мы перейдем к серебряному уровню — следующему уровню архитектуры медальона, где осуществляется
очистка, уточнение и стандартизация данных. Мы рассмотрим несколько важнейших тем:
Обеспечение целостности данных через метод на основе метаданных.
Очистка данных для улучшения их качества.
Преобразование данных в денормализованную модель для простоты доступа.
Обогащение данных, в частности, с помощью мастер-данных.
Историзация данных для отслеживания изменений со временем.
Задания оптимизации.
Оркестрация пайплайнов данных при помощи Airflow для автоматизации
сквозной обработки.
Как и глава 5, эта глава содержит описание важнейших этапов конфигурации
и практик написания кода. В ней будут рассмотрены практические действия,
включая проверку на основе метаданных, очистку данных и задачи историзации,
которые можно реализовать непосредственно в проекте.
В этой главе мы также рассмотрим некоторые преобразования данных и инструменты для контроля качества данных: dbt, DLT, Great Expectations и др. Кроме
того, мы познакомимся с концепцией продуктов данных и обсудим обоснованность их использования на серебряном уровне для конкретных организаций.
К концу главы вы будете хорошо понимать многие особенности проектирования
серебряного уровня и узнаете, как их правильно реализовать.
Стоит заметить, что хотя пример с Oceanic Airlines ориентирован на пакетноориентированную обработку, соображения относительно его дизайна и лучшие

  

Краткий обзор

177

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

Краткий обзор
В главах 4 и 5 была заложена основа архитектуры медальона. Среда настроена,
база данных AdventureWorks с использованием Azure SQL развернута, а пайп­
лайн данных построен на базе Data Factory для загрузки данных и сохранения
данных в таблицах Delta. Мы подчеркнули важность управления схемой, к чему
вернемся в дальнейшем.
Пришло время двигаться дальше и на этой основе создать серебряный уровень.
Мы начнем упражнение с реализации метода на основе метаданных, как показано
в верхней части рис. 6.1. Хранилище метаданных играет ключевую роль в определении технических проверок на серебряном уровне, автоматизируя процессы
и делая их более эффективными. Затем перейдем к операциям, связанным с преобразованиями данных, которые необходимы для построения серебряного уровня.

SQL

Метахранилище
Обработка
Инженерия данных Synapse (Spark)

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

Загрузка
данных
средствами
Data Factory

Bronze
(Lakehouse)

Silver
(Lakehouse)

Оркестрация с использованием Airflow

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

  

178

Глава 6. Строим серебряный уровень

Реализация метода, основанного на метаданных
Созданная нами архитектура вошла в динамическую фазу. В фазе загрузки вы
узнали, что системам-источникам часто требуется специальный пайплайн со
специализированными скриптами для преобразования форматов данных. В некоторых случаях также могут понадобиться дополнительные сервисы интеграции
или посадочные зоны. Сложность бронзового уровня может привести к недостаточной стандартизации, что затруднит обслуживание и масштабирование
пайплайна обработки данных.
Однако серебряный уровень более предсказуем, потому что данные на бронзовом уровне хранились в стандартизированном табличном формате Delta. Такая
стандартизация позволяет автоматизировать большую часть действий серебряного уровня. Здесь метод, основанный на метаданных, становится чрезвычайно
ценным.
Этот метод использует метаданные (информацию о данных) для автоматизации
управления данными и инженерных процессов. Это такие задачи, как, например,
интеграция данных и проверки их качества. Используя метаданные, организации могут повысить эффективность и точность своих действий по управлению
данными. По сути, этот метод сокращает необходимость в специализированных
скриптах и сводит к минимуму повторение одних и тех же действий в разных
частях проекта.
В работе метода, основанного на метаданных, крайне важную роль играет мета­
хранилище (metastore) — централизованный репозиторий, в котором хранятся
метаданные: структуры схем, местоположение источников и приемников, информация о владельцах данных и детали использования. Метахранилище также
помогает контролировать соблюдение политик и правил касательно данных,
так как метаданные могут использоваться для определения этих политик и их
применения в рамках всего проекта. Кроме того, метахранилище облегчает совместное использование метаданных различными инструментами и системами
управления. С помощью метаданных можно выполнять идентичные преобразования в различных сервисах, таких как Microsoft Fabric, и других средах на базе
Spark, например Azure Databricks.
В этом примере проверки данных выполняют функции привратников, пропускающих с бронзового уровня на серебряный только данные, прошедшие
техническую проверку. Тем не менее если самое важное — обеспечить целостность бронзового уровня, может быть целесообразно переместить эти технические проверки на один уровень вверх.

В следующих разделах мы вместе реализуем метод, основанный на метаданных. Мы начнем с создания новой базы данных для хранения метаданных. Затем соберем метаданные схемы из базы AdventureWorks, которая затем будет
использована для установления правил проверки данных. Сформулировав

  

Реализация метода, основанного на метаданных

179

некоторые первичные выводы, мы перейдем к следующим задачам. Часть из них
вы ­выполните самостоятельно; часть приводится только в учебных целях. К числу
задач относится очистка данных, операции денормализации, некоторые простые
улучшения, историзация, управление и оптимизация таблиц.

Реализация хранилища метаданных
Создадим хранилище метаданных, развернув еще одну базу данных Azure SQL1.
Вернитесь к порталу Azure и создайте новую базу данных с выбранным вами
именем. В нашем примере она называется metadatastore. После развертывания
базы откройте редактор запросов. Создайте таблицу, которой мы присвоим имя
SchemaMetadata. В этой таблице будут храниться все необходимые метаданные.
Скопируйте и вставьте следующий скрипт SQL (https://oreil.ly/FKysm) для создания таблицы:
CREATE TABLE SchemaMetadata
(
Id INT IDENTITY(1,1) PRIMARY KEY,
SchemaName NVARCHAR(128),
TableName NVARCHAR(128),
ColumnName NVARCHAR(128),
DataType NVARCHAR(128),
CharacterMaximumLength INT,
NumericPrecision INT,
NumericScale INT,
IsNullable NVARCHAR(3),
DateTimePrecision INT,
IsPrimaryKey BIT DEFAULT 0
)
GO

Скрипт, который вы только что выполнили, создает новую таблицу SchemaMetadata.
Она предназначена для хранения подробностей схемы базы данных. Приведенный
пример демонстрирует общие концепции, а не описывает решение во всех деталях.
В реальных сценариях вам, скорее всего, придется расширить его другими сторонними решениями или скриптами, чтобы включить дополнительные метаданные,
например метаданные приемной схемы, метки безопасности, информацию для
фильтрации строк и отображения столбцов.
После запуска скрипта и создания таблицы необходимо получить метаданные
схемы из базы AdventureWorks. Для этого я написал простой скрипт, читающий
все необходимые метаданные из системных таблиц AdventureWorks. Этот скрипт
миграции (https://oreil.ly/HPw66) генерирует команды INSERT для хранилища
метаданных, созданного при помощи предыдущего скрипта. В этом примере
1

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

  

180

Глава 6. Строим серебряный уровень

я демонстрирую использование всего одной таблицы Address. В реальных сценариях вам придется перебрать все необходимые таблицы в базе данных:
SELECT
'AdventureWorks' as 'SchemaName',
TABLE_NAME as 'TableName',
COLUMN_NAME as 'ColumnName',
DATA_TYPE as 'DataType',
CHARACTER_MAXIMUM_LENGTH as 'CharacterMaximumLength',
NUMERIC_PRECISION as 'NumericPrecision',
NUMERIC_SCALE as 'NumericScale',
IS_NULLABLE as 'IsNullable',
DATETIME_PRECISION as 'DateTimePrecision',
COLUMNPROPERTY(OBJECT_ID(TABLE_NAME), COLUMN_NAME, 'IsIdentity')
as 'IsPrimaryKey'
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
TABLE_NAME = 'Address'

После сбора метаданных схемы из базы AdventureWorks вернемся к базе данных
Azure SQL хранилища метаданных для вставки всех записей. Ниже приведен
пример (https://oreil.ly/nYKF7). Вернитесь к хранилищу метаданных и выполните
следующий скрипт:
INSERT INTO SchemaMetadata
(SchemaName, TableName, ColumnName, DataType, CharacterMaximumLength,
NumericPrecision, NumericScale, IsNullable, DateTimePrecision, IsPrimaryKey)
VALUES
('AdventureWorks', 'Address', 'AddressID', 'int',
NULL, 10, 0, 'NO', NULL, 1),
('AdventureWorks', 'Address', 'AddressLine1', 'nvarchar',
60, NULL, NULL, 'NO', NULL, 0),
('AdventureWorks', 'Address', 'AddressLine2', 'nvarchar',
60, NULL, NULL, 'YES', NULL, 0),
('AdventureWorks', 'Address', 'City', 'nvarchar',
30, NULL, NULL, 'NO', NULL, 0),
('AdventureWorks', 'Address', 'StateProvince', 'int',
NULL, 10, 0, 'NO', NULL, 0),
('AdventureWorks', 'Address', 'PostalCode', 'nvarchar',
15, NULL, NULL, 'NO', NULL, 0),
('AdventureWorks', 'Address', 'CountryRegion', 'geography',
NULL, NULL, NULL, 'YES', NULL, 0),
('AdventureWorks', 'Address', 'rowguid', 'uniqueidentifier',
NULL, NULL, NULL, 'NO', NULL, 0),
('AdventureWorks', 'Address', 'ModifiedDate', 'datetime',
NULL, NULL, NULL, 'NO', 3, 0);
GO

На рис. 6.2 представлены результаты сбора метаданных. Созданное метахранилище позволит выполнить правила проверки данных с применением средств
автоматизации.

  

Реализация метода, основанного на метаданных

181

Рис. 6.2. Хранилище метаданных будет использоваться для управления проверкой данных
на серебряном уровне
Пока что мы собрали только самые основные метаданные. Они включают информацию схемы для одной базы данных: имена таблиц и столбцов, типы данных,
атрибуты, допускающие null, и первичные ключи. Они также ограничиваются
одной таблицей Address.
Далее рассмотрите возможность расширения метаданных и добавления информации, относящейся к домену, метаданных для разных источников и метаданных
безопасности, например меток безопасности или фильтрации строк. Возможно,
также стоит внедрить метаданные для более сложной логики обработки: переименования столбцов источника в соответствии с приемником, выполнения простых соединений (joins) или объединений (unions) и отфильтровки неактуальных
данных. Кроме того, для оптимизации процесса CI/CD можно добавить метаданные, относящиеся к специфике среды, детали развертывания и информацию
по версионированию. В итоге объем фреймворка метаданных будет зависеть от
конкретных требований.
Затем интегрируйте метахранилище в пайплайн данных с помощью метода,
основанного на метаданных. Для этого потребуется сделать несколько шагов.
На рис. 6.3 показано, как выглядит полностью настроенная конфигурация.
Когда все будет готово, вернитесь в среду Microsoft Fabric. В разделе Settings
зарегистрируйте новую базу данных Azure SQL как новое подключение. Это делается так же, как при создании базы данных AdventureWorks. Затем перейдите

  

182

Глава 6. Строим серебряный уровень

к пайплайну данных и откройте существующее действие ForEach. Добавьте новое
действие Lookup, перетащив его в рабочий поток. Подключите его к шагу блокнота, отвечающему за создание таблиц Delta. Выберите действие Lookup, перейдите
в раздел Settings и настройте подключение Connection для использования нового
хранилища метаданных. Для запроса мы будем использовать имя таблицы как
входные данные для вызовов. Обновите поле Query следующим кодом (https://
oreil.ly/UavpD):
@concat('SELECT * FROM [dbo].[SchemaMetadata]
WHERE SchemaName=''AdventureWorks''
AND TableName=''',item().table_name,'''')

Подробные настройки действия Lookup см. на рис. 6.3.

Рис. 6.3. Подробности конфигурации действия Lookup для загрузки метаданных

  

Реализация метода, основанного на метаданных

183

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

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

При работе с метаданными в действии ForEach следует рассмотреть два варианта.
Можно выбрать строгий подход, при котором системе для работы пайплайна
метаданные из базы данных необходимы — без них он работать не будет. Это
более ограничивающий вариант. С другой стороны, иногда предпочтителен
более гибкий подход, который позволяет пайплайну продолжать работать даже
при недоступности данных. В нашем примере будем считать, что метаданные не
всегда могут быть под рукой.
Чтобы реализовать гибкий подход, перетащите новое действие If Condition
в ForEach. Новое действие можно настроить для проверки условий в зависимости
от того, будет результат истинным или ложным. В нашем случае выражение настраивается подсчетом входных данных, полученных действием LookupMetadata.
Если счетчик больше нуля, метаданные доступны для обработки. Для реализации этого условия обновите IfCondition следующим выражением:
@greater(activity('LookupMetadata').output.count, 0)

После настройки IfCondition откройте условие True. Здесь следует добавить новое
действие Notebook. Оно будет отвечать за выполнение технических проверок на
основании метаданных, полученных из LookupMetadata.
Подробные настройки конфигурации действия IfCondition см. на рис. 6.4.

  

184

Глава 6. Строим серебряный уровень

Рис. 6.4. Подробности конфигурации действия IfCondition для запуска технической проверки данных
Теперь перейдите в раздел Settings and parameters недавно созданного действия Notebook. Добавьте три новых параметра с именами schemaName, tableName и metadata.
Используйте для каждого параметра соответствующее выражение:
Для schemaName: adventureworks.
Для tableName: @item().table_name.
Для metadata: @string(activity('LookupMetadata').output.value).
За подробными настройками конфигурации действия Notebook обращайтесь
к рис. 6.5.
Перейдите в среду Workspace и откройте недавно созданный блокнот. Нам
нужно, чтобы он проверял схему на основании метаданных, загруженных
из базы данных. Сначала скрипт технической проверки (https://oreil.ly/bih7f)
проверяет наличие параметра metadata. После этого выходные метаданные
проверяются и загружаются в формате JSON. Впоследствии скрипт перебирает метаданные для динамического построения правил проверки данных.
Если какие-либо данные окажутся недействительными, выполнение тут же
останавливается.

  

Реализация метода, основанного на метаданных

185

Рис. 6.5. Подробности конфигурации действия Notebook для выполнения технических проверок
Скопируйте и вставьте следующий код в созданный блокнот:
# Вычисление базовых параметров по контексту пайплайна
schemaName = ""
tableName = ""
metadata = ""

После вставки кода переключите режим Toggle parameter cell при помощи многоточия в правом верхнем углу ячейки. Затем создайте новый блок кода, щелкнув
значок + в нижней части ячейки. Вставьте в новый блок следующий код:
# Импортирование необходимых библиотек
import json
# Проверка наличия параметра metadata
try:
json.loads(metadata)

  

186

Глава 6. Строим серебряный уровень

except ValueError as e:
mssparkutils.notebook.exit("Metadata is not a valid JSON object.")
json_metadata = json.loads(metadata)
# Загрузка данных и преобразование DataFrame
df = spark.read.table(f'bronze.{schemaName}.{tableName}')
# Проверка существования столбцов в метаданных из DataFrame
missing_columns = [item["ColumnName"] for item in json_metadata \
if item["ColumnName"] not in df.columns]
# Если столбцы отсутствуют, процесс останавливается
if missing_columns:
mssparkutils.notebook.exit(f"Technical validations have failed: " \
+ join(missing_columns))

Когда все будет готово, запустите пайплайн данных. Если все работает как положено, действие ForEach переберет все таблицы и прочитает соответствующие
метаданные. Затем IfCondition используется для проверки доступности метаданных. Если метаданные доступны, пайплайн запускает действие Notebook для выполнения необходимых технических проверок.
Сейчас выполняются самые простейшие проверки — проверяются только имена
столбцов. Но скрипт можно легко расширить и добавить в него правила для
первичных ключей, допустимости null, уникальности, длины полей и многого
другого. Если какая-либо таблица не соответствует необходимым стандартам,
пайплайн останавливается. Такое решение обеспечивает надежную защиту данных, поступающих на серебряный уровень.
На этом практическая часть раздела завершена. В следующем разделе резюмируем, что мы узнали о подходе, основанном на метаданных, и обсудим, как его
можно улучшить, а затем вернемся к практическим примерам.

Возможности для улучшения
Метод, основанный на метаданных, строится на простой, но эффективной концепции: использовании метаданных (данных о данных) для управления процессами
проверки, преобразования и загрузки. Этот метод требует создания репозитория
метаданных, в котором они хранятся. Ему также необходим оркестратор, который
читает метаданные и динамически генерирует задания, проверки и преобразования. Это можно организовать через пайплайн, инициирующий выполнение
блокнота. Кроме того, рекомендуется проводить мониторинг и отслеживание
статуса заданий для контроля за тем, что все работает правильно.
Для дальнейшего масштабирования я советую рассмотреть следующие усовершенствования:
Внешнее размещение метахранилища с доступом через API для модели управления метаданными с самообслуживанием.

  

Реализация метода, основанного на метаданных

187

Расширение метода, основанного на метаданных, для поддержки технических
форматов файлов. Например, условие ForEach может использоваться для
преобразования Parquet в Delta или CSV в Delta либо для парсинга сложных
вложенных структур XML.
Расширение возможностей обработки такими операциями, как присоединение, слияние и полная перезапись. Подумайте о внедрении сложных преобразований данных, таких как шаблоны SQL или функций, определяемые
пользователем. Некоторые компании используют файлы JSON, описывающие
все шаги преобразования, другие выбирают шаблоны SQL.
Реализация получения схемы на серебряном уровне, связанная со стратегиями управления схемой, рассмотренными в разделе «Управление схемой»
в главе 5, с. 163.
Повышение безопасности данных за счет создания безопасных представлений, использующих методы управления политиками (например, маскировку
на уровне строк или столбцов), и реализация управления группами пользователей через RBAC (Role-Based Access Control) или ABAC (AttributeBased Access Control). Это особенно полезно при работе с чувствительными
данными.
Выполнение блокнотов в других блокнотах за счет использования метаданных.
Такой подход помогает организовать динамическое управление выполнением
задач и зависимостей. Он упрощает передачу параметров между блокнотами
и корректирует обработку данных на основе метаданных, что также может
быть полезно для одновременного выполнения нескольких блокнотов.
Добавление средств аудита и ведения журнала для тщательного мониторинга
загружаемых записей. Это поможет обнаруживать любые проблемы в процессе и отслеживать метрики производительности для выявления областей,
нуждающихся в улучшении.
Реализация системы уведомлений для быстрого оповещения команды эксплуатации об успешных результатах и о сбоях, например с использованием
Slack (https://slack.com) или Microsoft Teams.
Разработка системы создания отчетов или компонента наблюдаемости на
стадии выполнения, предоставляющего подробную информацию о сбоях,
количестве обработанных записей, времени обработки, количестве записей
в источнике и т. д. Это необходимо для распространения важной информации
и аналитики производительности.
В том, что касается управления пайплайнами данных, метод на основе метаданных
обладает рядом преимуществ перед традиционными стратегиями на основе кода.
Рассмотрим некоторые из этих преимуществ.
Прежде всего метод, основанный на метаданных, может улучшить гибкость
и адаптируемость пайплайнов. Это означает возможность поддержки разных

  

188

Глава 6. Строим серебряный уровень

источников и приемников данных с разными форматами, схемами и частотами. Кроме того, обработку можно скорректировать для поддержки различных
паттернов загрузки: полной загрузки, инкрементальной загрузки и полной
перезаписи.
Другое преимущество заключается в том, что метод, основанный на метаданных,
значительно сокращает объем кода, который потребуется писать и обслуживать.
Вместо того чтобы создавать несколько блокнотов, можно поддерживать набор универсальных пайплайнов, способных работать с разными источниками
и приемниками данных на основе метаданных. Это значительно сократит время
и усилия, необходимые для обслуживания кода.
Более того, метод, основанный на метаданных, упрощает и стандартизирует
процессы разработки и развертывания. Вы сможете легко добавить проверки
и изменения с использованием метаданных без изменения кода или повторного
развертывания пайплайнов. Это значительно повысит эффективность процессов
разработки и развертывания.
Наконец, в зависимости от дизайна пайплайна можно добиться параллелизма и конкурентности за счет одновременного выполнения нескольких копий
действия Notebook. Таким образом можно оптимизировать производительность
и эффективность пайплайна, ускорить его и сделать более эффективным.
После создания основы процесса, управляемого метаданными, и технической
проверки данных перейдем к их очистке. Этот этап менее предсказуем и часто
требует индивидуальных настроек. После рассмотрения процесса очистки мы
обсудим возможность его автоматизации с использованием метаданных.

Очистка данных
Очисткой данных называется процесс выявления ошибок, несоответствий и неточностей в данных и их исправления или удаления. Она необходима, поскольку
данные часто содержат ошибки и расхождения, включая человеческие ошибки,
системные ошибки и ошибки ввода данных. Они могут иметь серьезные последствия для качества и точности данных: привести к ложным выводам, ошибочным
решениям и плохим бизнес-результатам.
Очистка данных отличается от проверки целостности данных — она подразумевает анализ и исправление неточностей и ошибок в датасете для повышения его
качества. Как правило, сначала необходимо выполнить запросы к данным и провести профилирование, чтобы лучше понять, какие данные находятся в тех или
иных таблицах. В ходе этого процесса могут обнаружиться ошибки, аномалии
и несогласованности. Затем данные необходимо исправить. При этом их можно
преобразовать в согласованный формат, например, чтобы использовать единый
формат даты. Также можно добавить отсутствующую информацию — скажем,
геолокацию клиентов. Кроме исправления аномалий очистка включает важный

  

Очистка данных

189

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

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

Реализация задач очистки данных
Познакомимся поближе со сложностью очистки данных. Вернитесь к Workspace
и создайте новый блокнот Notebook. Он будет предназначен для очистки данных
базы AdventureWorks. Мы интегрируем его в пайплайн данных так, чтобы он
следовал за действием ForEach.
Присвойте блокноту имя clean_data. Убедитесь, что в меню слева выбран вариант
Silver Lakehouse, чтобы вы работали в правильной среде. Для этой демонстрации
данные будут загружаться из базы данных AdventureWorks бронзового уровня.
Откройте блокнот и начните загрузку данных из таблицы customer бронзового
уровня. Для этого необходимо выполнить следующий код:
customers = spark.read.table("bronze.adventureworks.customer")
display(customers)

Выполнив этот запрос, вы увидите, что данные не очищены (рис. 6.6).
Например, столбец Title включает различные обращения: Mr., Ms., Mrs., Dr..
Вместо того чтобы работать с ними, будет эффективнее определить пол каждого
клиента. Кроме того, из столбца SalesPerson следует удалить префикс adventureworks. Столбец ModifiedDate необходимо стандартизировать единым форматом
даты, а столбец PasswordHash убрать. Кроме того, все телефонные номера должны
быть отформатированы в едином стиле, потому что некоторые содержат префикс 1 (XX)1.

1

Строка 501 на рис. 6.6.

  

190

Глава 6. Строим серебряный уровень

Рис. 6.6. Таблица customer1
Перечисленные улучшения в таблице customer представляют основополагающие
действия по очистке данных. Важно понимать, что очистка зависит от датасета,
часто бывает сложной и для нее необходимо глубокое понимание как данных, так
и бизнес-процессов, которые их генерируют.
Приведенный далее скрипт очистки (https://oreil.ly/-VDuD) показывает, как выполнять эти операции в PySpark. Функция regexp_replace удаляет префикс
adventure-works из столбца SalesPerson. Функция date_format стандартизирует столбец ModifiedDate единым форматом даты. Функция udf применяется
для определения пола каждого клиента. Попробуйте выполнить следующий
скрипт:
# Импортирование необходимых библиотек
from pyspark.sql.functions import *
from pyspark.sql.types import StringType
# Загрузка данных
customers = spark.read.table("bronze.adventureworks.customer")

1

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

  

Очистка данных

191

# Удаление лишних столбцов
customers = customers.drop("PasswordHash", "PasswordSalt", "rowguid")
# Функция для определения пола
def determine_gender(title):
if title == 'Mr.':
return 'Male'
elif title in ('Ms.', 'Mrs.', 'Miss'):
return 'Female'
else:
return 'Unknown' # Значение по умолчанию для других случаев
determine_gender_udf = udf(determine_gender, StringType())
# Добавление пола в каждый словарь в списке
customers = customers.withColumn("Gender", \
determine_gender_udf(trim(customers["Title"])))
# Определение функции strip_prefix
def strip_prefix(value):
return value.strip("adventure-works\\")
# Определение функции strip_prefix_udf
strip_prefix_udf = udf(strip_prefix, StringType())
# Обновление SalesPerson в каждом словаре в списке
customers = customers.withColumn("SalesPerson", \
strip_prefix_udf(customers["SalesPerson"]))
# Замена типа ModifiedDate на ГГГГ-ММ-ДД
customers = customers.withColumn("ModifiedDate", \
date_format(customers["ModifiedDate"], "yyyy-MM-dd"))
# Приведение всех телефонных номеров к единому формату
customers = customers.withColumn("Phone", \
regexp_replace(customers["Phone"], r"1 \(\d{2}\) ", ""))
# Запись данных customers в clean_ table
customers.write.mode("Overwrite") \
.saveAsTable("adventureworks.clean_customer")

После запуска скрипта и проверки вновь созданной чистой таблицы вы увидите
результаты, показанные на рис. 6.7. Данные клиентов стали чистыми и согласованными. Также приводятся некоторые статистические показатели данных. Эта
информация поможет лучше понять данные и выявить любые потенциальные
проблемы.
Очистка данных в PySpark иногда может быть очень сложной, поскольку она
требует больше кода. Другой способ очистки основан на использовании библио­
тек, таких как pandas. Библиотека pandas популярна и широко применяется
в data science и проектах машинного обучения для конструирования признаков,
предварительной обработки данных, очистки и преобразования. Следующий

  

192

Глава 6. Строим серебряный уровень

Рис. 6.7. Результаты после очистки таблицы
скрипт (https://oreil.ly/3xss6) демонстрирует, как выполнить те же операции преобразования с использованием pandas:
# Тот же код, что в предыдущем примере, но с использованием pandas
import pandas as pd
customers = spark.read.table("bronze.adventureworks.customer")
customers = customers.toPandas().drop(columns=["PasswordHash", \
"PasswordSalt", "rowguid"])
customers['ModifiedDate'] = pd. \
to_datetime(customers['ModifiedDate']).dt.strftime('%Y-%m-%d')
customers['Gender'] = customers['Title'].apply \
(lambda x: "Male" if x == "Mr." else "Female" \
if x in ('Ms.', 'Mrs.', 'Miss') else "Unknown")
customers['SalesPerson'] = customers['SalesPerson']. \
str.replace('adventure-works\\', '', regex=False)
customers['Phone'] = customers['Phone']. \
str.replace(r'.*?(\d{3} \d{3}-\d{4})', r'\1', regex=True)
# Проверка общих телефонных номеров
customers['SharedPhone'] = customers.duplicated(subset=['Phone'])
# Вывод результатов
display(customers)

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

  

Очистка данных

193

Тем не менее при работе с большими датасетами pandas изначально не распределяет свои операции по всем узлам Spark. В Spark операции, выполняемые
с помощью pandas, обычно запускаются на ведущем узле без использования
функциональности распределенной обработки Spark. Это приводит к снижению
эффективности обработки, так как рабочие узлы остаются недозагруженными.
Для преодоления этого ограничения Spark предоставляет реализацию pandas API
для Spark (https://oreil.ly/L52Vh), спроектированную, чтобы ликвидировать разрыв
между простотой pandas и масштабируемостью Apache Spark.
На серебряном уровне обычно выполняется переименование и переформатирование для соответствия стандартам домена или организации. Например,
поле "cust_id" может быть переименовано в "customer_id" для соответствия
правилам именования, принятым в организации.

Теперь, когда вы знаете, как очистить данные в таблице customers, я рекомендую
очистить остальные таблицы в базе данных AdventureWorks. Попробуйте использовать тот же блокнот. Создайте новый блок кода для каждой таблицы. Не
забудьте сохранить эти таблицы с префиксом _clean, чтобы упростить их идентификацию. Когда код будет готов, интегрируйте блокнот в пайплайн данных
для автоматизации процесса очистки. Разместите интеграцию после действия
ForEach, отвечающего за техническую проверку всех данных.
Как и при хранении промежуточных очищенных датасетов, в итоге все зависит
от потребностей организации. Некоторые организации хранят датасеты в виде
таблиц для аудита и отладки, что может привести к необходимости проектирования дополнительного подуровня таблиц на серебряном уровне. Именно это
происходит в нашем примере: очищенные данные сохраняются с префиксом
_clean. Также можно использовать другую схему или сущность Lakehouse. Другие предпочитают обрабатывать все структуры DataFrame за один раз без записи
промежуточных результатов в таблицы Delta. Выберите тот вариант, который
лучше подходит для целей вашей организации.
Не забывая об этих практических примерах, ненадолго остановимся. В следующих разделах мы рассмотрим темы, призванные углубить ваше понимание
материала, при этом мы сосредоточимся на теоретических вопросах качества
данных, а не на практике. Затем рассмотрим вопросы нормализации данных,
их обогащения и MDM. Мы вернемся к практической части после описания
историзации данных.

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

  

194

Глава 6. Строим серебряный уровень

в системах-источниках. Например, можно сохранить ошибочные записи (скажем,
клиентов с возрастом более 150 лет) в карантинной таблице, как показано в следующем скрипте (https://oreil.ly/8gQU1):
customers.filter(age > 150).write.format("delta") \
.mode("append").saveAsTable("adventureworks.customer_quarantine")

Подумайте, должна ли при этом прерываться обработка. В главе 3 обсуждалась
агрессивная проверка качества данных. Если предполагается, что последующие
процессы могут завершиться со сбоем или потребители данных не справятся
с этими проблемами, пайплайн следует остановить. Для этого можно воспользоваться подсчетом ошибок и использованием функции mssparkutils.notebook.
exit из Fabric Spark1.
Пример возможной реализации:
customers = spark.read.table("adventureworks.customer")
duplicateIds = customers.toPandas().duplicated(subset=['CustomerID'])
title_not_null = customers.toPandas()['Title'].isnull()
if duplicateIds > 0 or title_not_null > 0:
mssparkutils.notebook.exit(f"DQ duplicateIds error: \
{duplicateIds}, DQ title_not_null error: {title_not_null}")

Эти примеры очистки данных представлены для пакетного режима, но, с небольшими исправлениями, очистка данных также может осуществляться для
обработки в реальном времени. Вот наглядный пример (https://oreil.ly/9yb2e) того,
как может выполняться очистка данных в реальном времени с использованием
Azure Event Hubs со Spark Structured Streaming2:
# Потоковая передача данных из Azure Event Hubs
df = spark \
.readStream \
.format("eventhubs") \
.options(**ehConf) \
.load()
# Удаление строк, содержащих null или NaN
output = df.na.drop()
# Запись очищенных данных в таблицу Delta
output.writeStream \
.format("delta") \
.outputMode("append") \
.toTable("adventureworks.events")
1

2

Microsoft Spark Utilities, или MSSparkUtils, — встроенный пакет, разработанный для
упрощения стандартных операций. В Databricks существует похожий полезный инструмент dbutils.
См. описание конфигурации в разделе «Пример использования Azure Event Hubs»
в главе 5, с. 161.

  

Очистка данных

195

Этот скрипт извлекает данные из Azure Event Hubs, удаляет строки со значениями null или NaN (Not a Number) и немедленно записывает очищенные данные
в таблицу Delta, которая может находиться на серебряном уровне. Такой подход
позволяет очищать данные в реальном времени при их поступлении в потоковом
режиме.
От обсуждения операций очистки данных перейдем к возможной организации
очистки данных и связи этих наблюдений с предшествующим обсуждением.
При использовании скриптов (например, Jupyter Notebooks) существует несколько вариантов организации задач по очистке данных. Некоторые инженеры
предпочитают выделить отдельный блокнот для каждого источника данных. Этот
способ упрощает мониторинг изменений и обновлений, так как вся информация
хранится централизованно. Другие предпочитают разбивать свои действия по
очистке данных между блокнотами, организованными по действиям. Такой подход помогает поддерживать рабочий поток в порядке, особенно при обработке
сложных датасетов или множественных стадий очистки. Он также позволяет
разным участникам команды сосредоточиться на конкретных областях, не мешая
работе друг друга.
Добиться полной стандартизации при очистке данных сложно из-за разнообразной и сложной природы данных. Можно ли упростить процесс, переводя процессы
очистки данных на управление метаданными? И да и нет. Если в вашем случае
очистка данных состоит из стандартных проверок качества и этапов (таких, как
перекрестная проверка датасетов с централизованным управлением по референсным данным), возможно, стоит воспользоваться обобщенными блокнотами,
управляемыми метаданными, с передачей аргументов. Но каждый датасет в целом
обычно требует отдельного подхода, адаптированного к его конкретной структуре
и потребностям в очистке.
Эта особенность часто заставляет разработчиков хранить правила качества
данных в отдельных блокнотах или сценариях либо в метаданных в таблицах
Delta, давая возможность применять более специализированные и эффективные
стратегии очистки данных. Следовательно, также важно четко направлять усилия
инженерных команд. Поощряйте применение лучших практик форматирования
и удобочитаемости кода, таких как добавление осмысленных комментариев,
использование единой схемы расстановки отступов и модуляризация. Также
важно установить стандарт относительно предпочтительных фреймворков или
инструментов.
Следующий раздел посвящен выбору правильных инструментов и фреймворков.

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

  

196

Глава 6. Строим серебряный уровень

зависит от специфических требований организации. Ниже перечислены некоторые популярные инструменты и фреймворки преобразования данных, качества
и очистки данных.
dbt (Data Build Tool)
Один из самых популярных ETL-инструментов — dbt (https://getdbt.com). Он
позволяет аналитикам данных и инженерам преобразовывать данные для разных решений по шаблонам SQL. Благодаря универсальному способу запи­си
таких шаблонов dbt дает возможность протестировать преобразования данных
и убедиться, что они работают так, как ожидалось.
Среди преимуществ можно выделить то, что dbt как продукт нейтрален по
отношению к способу преобразования данных в хранилище или озеро-хранилище. Dbt транспилирует код SQL в целевой диалект SQL. Это означает,
что вы можете написать свои преобразования на каком-то одном диалекте
SQL и выполнить их с любой SQL-базой, например Fabric Spark (https://oreil.
ly/wPmSC), Fabric Warehouse (https://oreil.ly/bhzI-) или Databricks Spark (https://
oreil.ly/i_pYO). С другой стороны, по мере более глубокого изучения dbt вы
можете обнаружить, что простых конфигураций SQL просто недостаточно.
В таком случае шаблоны Jinja и модели Python помогут динамически настроить генерацию запросов SQL и управлять ею. Такой подход безусловно
эффективен, но сложен в изучении и может отклоняться от принятого в dbt
подхода нейтральности к базам данных.
Более того, dbt предлагает интегрированную документацию и тестовый
фреймворк, который проверяет, что преобразования работают так, как ожидалось. Продукт распространяется как в версии с открытым исходным кодом,
так и в виде версии с SaaS-размещением с моделью оплаты по количеству
пользователей.
Delta Live Tables
Delta Live Tables (DLT) (https://oreil.ly/QlZ7k) — декларативный ETL-фреймворк
для платформы Databricks Data Intelligence Platform, упрощающий потоковые
и пакетные процессы ETL. Он интегрируется с другими сервисами Databricks
(такими, как MLflow и Unity Catalog) и улучшает отслеживание происхождения данных. DLT также предоставляет методы задания и оценки стандартов
качества данных, упрощающие разработку пайплайнов обработки данных.
DLT особенно хорошо подходит для управления CDC благодаря правильному
решению таких проблем, как нарушение порядка событий, которые может
быть сложно воспроизвести вручную.
В модели оплаты DLT не предусмотрен бесплатный тариф (https://oreil.ly/
gwk5C), и DLT повышает зависимость от Databricks. Так как DLT требует

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

  

Очистка данных

197

Great Expectations
Great Expectations (https://greatexpectations.io) — еще один инструмент, ориентированный на качество данных. Это библиотека Python с открытым исходным
кодом, которая упрощает тестирование, документирование и профилирование
данных. С помощью Great Expectations можно определить ожидания по качеству данных и проверить данные на соответствие этим ожиданиям. Инструмент генерирует отчеты, которые предоставляют подробную информацию
относительно точности и надежности данных.
Ключевое отличие от других инструментов состоит в том, что Great Expectations
уделяет первоочередное внимание проверке и документированию качества
данных, а не их преобразованию. Такой подход означает, что интеграция Great
Expectations в существующие пайплайны данных может требовать более существенной настройки и конфигурации. А вот dbt и DLT строились с расчетом
на бесшовную интеграцию с широким набором инструментов экосистемы
данных. Это потенциально упрощает их реализацию.
Кроме того, сторонние инструменты качества данных и наблюдаемости, такие
как Ataccama (https://oreil.ly/fdfQl) и Monte Carlo (https://montecarlodata.com), предлагают интеллектуальное профилирование данных с применением ИИ-сервисов,
функции исправления источника и последующего управления, а также генерирования отчетов для углубленного анализа качества данных.
При выборе инструментов для преобразования данных, качества и очистки
важно сравнить эти варианты с базовым PySpark (включая библиотеки, такие
как pandas и Polars (https://pola.rs)). Базовый PySpark предлагает максимальную
гибкость и избегает привязки к конкретной технологии, что может быть значительным преимуществом. Однако в нем сложнее реализовать такие функции,
как отслеживание происхождения данных, автоматизированное тестирование,
управление зависимостями и поддержка потоковой передачи. Для них, скорее
всего, придется создать специальные библиотеки, что увеличит первоначальный
объем работы.
Некоторые разработчики предпочитают использовать для преобразований
данных базовые команды SQL, отдавая должное их простоте и портируемости
по разным системам баз данных. Хранение этих SQL-команд в блокнотах или
в представлениях баз данных упрощает доступ к данным и управление ими. Этот
метод базируется на понятном всем языке, что позволяет избежать сложности
специализированных инструментов и напрямую взаимодействовать с базами
данных для точного контроля над операциями с данными. С другой стороны,
SQL уступает Python по гибкости, что ограничивает сложность доступных
операций.
Если подытожить, выбор подходящего фреймворка или инструмента для преобразования данных, качества и очистки определяется конкретными потребностями. Важно оценить разные инструменты и фреймворки, чтобы определить

  

198

Глава 6. Строим серебряный уровень

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

Оптимизация производительности запросов
посредством денормализации
В главе 3 обсуждается важность стабильной производительности запросов.
Одна из стратегий повышения производительности использует денормализацию,
упрощающую получение данных за счет сокращения количества необходимых
соединений, требующих интенсивных вычислений. В чем важность этого подхода
для серебряного уровня?
Денормализацию рекомендуется применять при работе с очень сложными
сырыми данными, например сценариями, где задействованы сотни мелких
системных таблиц, что замедляет эффективные обращения к данным. Использование денормализованного формата хорошо работает для колоночных
файловых форматов (таких, как Parquet) при условии, что данные правильно
партиционированы (что предотвращает их смещение, то есть неравномерное
распределение по узлам распределенной системы). Такой подход также эффективен, когда аналитикам и дата-инженерам требуется быстрый доступ к данным
серебряного слоя для машинного обучения и получения текущих отчетов. За
дополнительной информацией по теме обращайтесь к разделам главы 3 «Денормализация», с. 94, и «Метод OBT», с. 110.
Apache Spark 2.3 и более поздние версии позволяют соединить два потоковых
объекта DataFrame в реальном времени. Эта возможность полезна для объединения данных из нескольких потоков и может использоваться для денормализации в реальном времени. См. документацию Apache Spark по операциям соединения (https://oreil.ly/XParg).

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

  

Простое обогащение данных

199

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

Простое обогащение данных
Под обогащением (enriching) понимается добавление в существующие данные
дополнительных деталей, что делает датасеты более полезными и насыщает их
контекстом. На серебряном уровне обычно выполняются простые улучшения,
которые повышают практическую ценность данных, не требуя сложных процессов. Например, это может быть присоединение новых атрибутов, геокодирование, добавление меток времени, преобразование имперских единиц измерения
в метрические, агрегирование данных или внедрение референсных данных. Такое
обогащение гарантирует, что данные будут не только чистыми, но и улучшенными
по тем параметрам, которые используются для более глубокого анализа.
Обогащение данных может затрагивать и более сложные измерения в зависимости от контекста. Например, большие языковые модели (LLM) открывают
новые возможности для обогащения данных контекстными выводами или для
генерации синтетических признаков. При генерации признаков следует тщательно проектировать процесс обогащения, чтобы преобразовывать сырые данные
в осмысленный ввод для моделей машинного обучения. В MDM (управлении
мастер-данными) обогащение играет ключевую роль для обеспечения согласованности, точности и надежности датасетов.
В архитектуре медальона сложные бизнес-правила обычно принадлежат
золотому уровню. Он предназначен для сложной логики и нетривиальных
вычислений. Эти процессы преобразуют чистые данные в ценную аналитическую информацию, адаптированную для конкретных бизнес-потребностей.

Обогащение также может быть непростым, требующим нетривиальной логики
обработки и использования LLM. Например, внедрение таких ИИ-сервисов, как
Azure OpenAI (https://oreil.ly/vSiXx), Fabric AI Services (https://oreil.ly/EBJA-) или
Databricks AI functions (https://oreil.ly/uahpt), позволит улучшать данные разными
хитроумными способами. Как правило, такие улучшения требуют более мощных
методов обработки.
В следующем учебном фрагменте кода приводится пример (https://oreil.ly/_fT3P)
обогащения с использованием сервиса Azure OpenAI1. Этот сервис позволяет генерировать текстовые ответы на промпты. В примере ниже сервис Azure OpenAI

1

Пример взят из библиотеки OpenAI Python API (https://oreil.ly/QZiC6).

  

200

Глава 6. Строим серебряный уровень

может использоваться для классификации компаний по названиям. В качестве
промптов можно использовать имена компаний из столбца CompanyName таблицы
customer. Далее мы генерируем ответ с использованием Azure OpenAI и выводим
ответ на каждый промпт:
# Настройка конфигурации Azure OpenAI
AZURE_OPENAI_API_KEY="<your API Key>"
AZURE_OPENAI_ENDPOINT="<your_OpenAI_Endpoint>"
# Загрузка библиотеки openai
from openai import AzureOpenAI
# Инициализация клиента Azure OpenAI
client = AzureOpenAI(
api_key = AZURE_OPENAI_API_KEY,
api_version = "2024-10-01",
azure_endpoint = AZURE_OPENAI_ENDPOINT
)
# Загрузка данных
df = spark.read.table("adventureworks.customer")
# Извлечение CompanyName из DataFrame
prompts = df.select('CompanyName').map(f=>f.getString(0)) \
.collect.toList.distinct
# Перебор промптов
for prompt in prompts:
response = client.chat.completions.create(
model="<your_model_name>",
messages=[
{"role": "user", "content": \
"Classify this company by returning the NAICS: " \
+ prompt}
],
max_tokens=100
)
# Вывод ответа на каждый промпт
print(f"Prompt: {prompt}")
print("Response:", response.choices[0].message.content)
print()

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

  

Простое обогащение данных

201

LLM не детерминированы по своей природе; это означает, что их ответы
могут изменяться даже при использовании тщательно продуманных промптов.
Например, при использовании LLM для получения кодов NAICS (https://
census.gov/naics) очень важно проводить проверки согласованности. Это помогает убедиться в правильности формата и точности ответов. Для поддержания целостности и согласованности данных я рекомендую реализовать
лучшие практики очистки данных после использования каждой функции на
базе ИИ. Такой подход гарантирует, что данные, с которыми вы работаете,
останутся надежными и точными. Мы вернемся к этой теме в главе 13.

Обогащение данных тесно связано с генерацией признаков в data science. Генерация признаков (feature engineering) подразумевает создание и выбор релевантных переменных из сырых данных для повышения производительности модели
машинного обучения. Кроме того, обогащение данных помогает проверять или
уточнять эти признаки. Например, в датасете с информацией о клиентах (дата
рождения, пол и т. д.) данные можно обогатить вычислением и добавлением
нового атрибута возраста. Затем этот атрибут может использоваться моделью
машинного обучения для прогнозирования оттока клиентов — возможно, с группировкой клиентов по разным возрастным диапазонам.
MDM — еще один ключевой метод улучшения данных. MDM развивает принципы обогащения данных созданием унифицированного источника истины для
всех критических бизнес-данных. На серебряном уровне интеграция процессов
MDM значительно улучшает данные. Здесь MDM играет важнейшую роль для
повышения согласованности данных, точности и практической ценности. Возьмем
пример AdventureWorks: MDM может стандартизировать референсные данные
в столбцах CountryRegion и StateProvince способом, обеспечивающим согласованность данных из разных систем-источников. Установка референсного значения по
умолчанию для CurrencyCode поможет избежать путаницы для тех, кто не знаком
с данными. Более того, консолидация данных клиентов из разных источников
и добавление идентификатора MasterCustomer устанавливает надежный единый
источник истины для информации клиентов в рамках организации.
В MDM часто используются сложные процессы, требующие управления
огромными объемами данных между разными системами. Такие решения, как
Profisee (https://profisee.com) и CluedIn (https://cluedin.com), чрезвычайно важны, так как они упрощают эти процессы.

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

  

202

Глава 6. Строим серебряный уровень

Выйдем за пределы теории и займемся концепцией историзации данных, для ее
изучения добавим новый блокнот в пайплайн данных. Этот процесс получает на
входе очищенные данные, которые мы создали ранее, и улучшает их, добавляя
временное измерение для отслеживания и отображения изменений в таблице
с течением времени.

Историзация данных
Историзация данных подразумевает отслеживание изменений во времени, что
необходимо для регистрации изменений в данных, мониторинга их жизненного
цикла и поддержки анализа. Этот процесс помогает выявлять тенденции, закономерности и аномалии, способствуя принятию обоснованных решений, помогая в прогнозировании и построении прогностических моделей. Историзация
выполняется разными способами на разных уровнях, и каждый из этих способов
отличается своими преимуществами. Рассмотрим эти методы.
Партиционирование бронзового уровня
Историзация на бронзовом уровне использует партиционирование данных
для организации и хранения исторических данных, чтобы они были доступны
в нужный момент. Этот метод структурирует исторические данные в точке доставки (это упрощает доступ), но может привести к появлению изолированных
датасетов (что затрудняет интеграцию).
Перемещение во времени (time travel) в Delta
Функция Delta Lake сохраняет снапшоты данных в разные моменты времени.
Тем самым пользователи получают возможность восстанавливать и запрашивать предыдущие версии данных. Пользователи могут обращаться к таблице
в том состоянии, в каком она существовала на определенный момент времени; для этого используются метаданные, сохраняющие все версии данных.
Хотя период удержания (время хранения) по умолчанию составляет 7 дней,
его можно неограниченно увеличивать. Однако функция перемещения во
времени в Delta требует дополнительного ручного сравнения изменений
между двумя версиями, так как она не формирует список этих изменений
автоматически.
Медленно изменяющиеся измерения (SCD2)
В отличие от изолированной историзации в датасетах и ручной работы, требуемой для перемещения во времени, реализация SCD2 предоставляет более
простой способ отслеживания и получения информации об изменениях. Этот
способ автоматически отслеживает изменения исторических данных, и с ним
вам будет проще увидеть, как данные эволюционируют.
У каждого варианта есть свои преимущества, и в зависимости от специфических требований проекта, чтобы обеспечить наиболее разносторонний подход

  

Историзация данных

203

к управлению историческими данными, может оказаться полезной комбинация
этих методов историзации.
При переходе на серебряный уровень метод SCD2 считается лучшей практикой.
Он консолидирует все данные в одну централизованную таблицу. Это упрощает
доступ к данным и анализ. Процесс консолидации включает присоединение
столбцов для сохранения даты загрузки данных в таблицу. Эти столбцы упрощают
фильтрацию и выборку исторических данных по конкретным датам, что облегчает управление историческими записями. На рис. 6.8 показано, как выглядит
результат обработки SCD в Spark.
Обратите внимание: CustomerID 1 — первый столбец на рис. 6.8 — был обновлен
22 января 2025 г., после закрытия предыдущей записи 21 января 2025 г. Кроме
того, поле current было обновлено значением false для предыдущей записи.
Текущие значения представляются значением 1, тогда как значение 0 представляет исторические данные. В сообществе инженеров нет единого мнения
относительно того, следует ли реализовать SCD на серебряном уровне или же
отложить реализацию до золотого. Решение зависит от конкретных потребностей организации.

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

  

204

Глава 6. Строим серебряный уровень

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

Векторы удаления Delta Lake
Векторы удаления (deletion vectors) Delta Lake предназначены для эффективного управления и отслеживания удалений в таблицах Delta. Данная
функция особенно полезна в средах с частыми операциями удаления.
Например, в сценариях с высокой текучестью данных или регулярными
обновлениями и удалениями (скажем, при управлении SCD) векторы
удаления повышают эффективность этих операций.
Чтобы активировать векторы удаления, необходимо изменить свойства
таблицы Delta Lake. Начните с выполнения следующей команды:
ALTER TABLE tblName SET TBLPROPERTIES ('delta.enableDeletionVectors' =
true);

После включения этой настройки Delta Lake хранит позиции удаленных
строк отдельно от настоящих файлов данных — этот метод называется
«мягким удалением». Он не изменяет существующие файлы данных при
удалении. Вместо этого слияние изменений выполняется только при
чтении данных («слияние при чтении») без ущерба для целостности
и производительности операций с данными.
Реализуем SCD2 с использованием скрипта. Работа начинается с выбора очищенной таблицы серебряного уровня. Затем данные сравниваются для выявления изменений. После этого на серебряном уровне создается новая таблица для
отслеживания этих изменений во времени; она дает полноценное представление
об эволюции данных.
Чтобы реализовать этот паттерн, перейдите в рабочее пространство (Workspace)
разработки при помощи навигационной панели в левой части экрана. Затем создайте новый блокнот. Интегрируйте его в пайплайн данных после этапов проверки

  

Историзация данных

205

качества данных. Этому блокноту можно присвоить имя historize_data_scd2.
Убедитесь, что в меню слева выбрана сущность Lakehouse серебряного уровня,
чтобы выполнение происходило в правильной среде.
При моделировании SCD могут использоваться разные таймлайны. Если
система-источник включает собственный функциональный таймлайн (например, действующих дат), его можно использовать для понимания изменений в данных на основании функционального таймлайна независимо от порядка их поступления. Если функциональный таймлайн недоступен,
придется положиться на технический. Он использует дату загрузки или
метку времени, которую предоставляет бронзовый уровень.

Не спешите копировать код — сначала я приведу общий обзор скрипта SCD2
(https://oreil.ly/YcLFU). Он делится на три части:
1. Первая часть действия Notebook загружает необходимые функции.
2. Вторая часть содержит функцию, которая начинается с чтения таблиц с префиксом clean_. Затем она переходит к назначению меток времени, проверяет присутствие первичного ключа и объединяет данные, вызывая другую
функцию. Затем предыдущий датасет сравнивается с новым. Для сравнения
данных используется бизнес-ключ1, изначально присвоенный в системе-источнике; он очень важен, так как однозначно идентифицирует каждую запись.
При отсутствии первичного ключа скрипт генерирует хешированный ключ,
который гарантирует, что каждая запись имеет уникальный идентификатор.
Сравнивая эти ключи, скрипт определяет, является запись новой, измененной
или должна быть удалена.
3. В третьей и последней части функция вызывается для каждой таблицы. При
этом используются такие аргументы, как имя схемы, имя таблицы и первичный ключ.
Продолжим работу над примером. Вставьте следующий код в нужную ячейку.
Первая часть скрипта импортирует функции и библиотеки, необходимые для
выполнения процесса историзации:
# Импорт функций
from pyspark import *
from pyspark.sql import functions as F
from pyspark.sql.functions import *

Щелкните значок +, чтобы добавить новую ячейку с кодом, и вставьте код, приведенный ниже. Следующая часть скрипта содержит основную функцию, которая
1

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

  

206

Глава 6. Строим серебряный уровень

читает данные из очищенной таблицы, генерирует хеш-ключ при отсутствии
первичного ключа и задает текущую дату1.
Функция также содержит логику слияния исходных и новых данных, создания
динамических столбцов и генерации целевых выборок на основании кодов
действий. Затем она отделяет записи, которые не требуют действий, от записей,
которые должны быть вставлены, удалены или обновлены. Наконец, функция
перезаписывает существующую таблицу с использованием данных из последней
структуры DataFrame2.
# Функция SCD2
def fn_SCD2(schemaName, tableName, primaryKey):
# Выборка данных с бронзового уровня или промежуточного серебряного уровня
dataChanged = spark.read.table(f"{schemaName}.clean_{tableName}")
# Удаление столбца loading_date из датасета
dataChanged = dataChanged.drop('loading_date')
# Генерирование хеш-ключа при отсутствии первичного ключа
if not primaryKey or primaryKey == "":
dataChanged = dataChanged.withColumn("hash", \
sha2(concat_ws("||", *dataChanged.columns), 256))
primaryKey = 'hash'
# Создание списка всех столбцов
columnNames = dataChanged.schema.names
# Назначение текущей даты
current_date = datetime.date.today()
# Попытка чтения существующего датасета
try:
# Чтение исходных данных – таблицы SCD2 со всеми данными
dataOriginal = spark.read.table(f"{schemaName}.hist_{tableName}")
except:
# При первой загрузке данные еще не существуют
newOriginalData = dataChanged.withColumn('current', lit(True)) \
.withColumn('effectiveDate', lit(current_date)) \
.withColumn('endDate', lit(datetime.date(9999, 12, 31)))
newOriginalData.write.format("delta").mode("overwrite") \
.saveAsTable(f"{schemaName}.hist_{tableName}")
# Чтение исходных данных – таблицы SCD2 со всеми данными
dataOriginal = spark.read.table(f"{schemaName}.hist_{tableName}")

1

2

Приведенный скрипт настроен для обработки данных, организованных по схеме
ГГГГММДД. Если вы работаете с другой системой секционирования или планируете
читать данные с промежуточного уровня с использованием даты снапшота, скрипт придется доработать, чтобы он соответствовал этим требованиям.
Функция перемещения во времени в Delta Lake остается полностью рабочей даже в том
случае, если данные были перезаписаны.

  

Историзация данных

# Переименование всех столбцов в dataChanged с добавлением префикса src_
df_new = dataChanged.select([F.col(c).alias("src_"+c) \
for c in dataChanged.columns])
src_columnNames = df_new.schema.names
df_new2 = df_new.withColumn('src_current', lit(True)) \
.withColumn('src_effectiveDate', lit(current_date)) \
.withColumn('src_endDate', lit(datetime.date(9999, 12, 31)))
# Создание динамических столбцов
src_primaryKey = 'src_' + primaryKey
# Полное слияние, соединение по ключевому столбцу и столбцу даты,
# чтобы в соединении использовались только новейшие записи
df_merge = dataOriginal.join(df_new2, (df_new2[src_primaryKey] \
== dataOriginal[primaryKey]), how='fullouter')
# Вычисление нового столбца для обозначения действия
df_merge = df_merge.withColumn('action',
when(concat_ws('+', *columnNames) == \
concat_ws('+', *src_columnNames), 'NOACTION')
.when(df_merge.current == False, 'NOACTION')
.when(df_merge[src_primaryKey].isNull() & df_merge.current, 'DELETE')
.when(df_merge[src_primaryKey].isNull(), 'INSERT')
.otherwise('UPDATE')
)
# Генерирование целевых выборок по кодам действий
column_names = columnNames + ['current', 'effectiveDate', 'endDate']
src_column_names = src_columnNames + ['src_current', \
'src_effectiveDate', 'src_endDate']
# Для записей, не требующих действий
df_merge_p1 = df_merge.filter(df_merge.action == \
'NOACTION').select(column_names)
# Для записей, требующих только вставки
df_merge_p2 = df_merge.filter(df_merge.action == \
'INSERT').select(src_column_names)
df_merge_p2_1 = df_merge_p2.select([F.col(c) \
.alias(c.replace(c[0:4], "")) for c in df_merge_p2.columns])
# Для записей, требующих удаления
df_merge_p3 = df_merge.filter(df_merge.action == \
'DELETE').select(column_names).withColumn('current', lit(False)) \
.withColumn('endDate', lit(current_date))
# Для записей, требующих истечения срока действия и вставки
df_merge_p4_1 = df_merge.filter(df_merge.action == \
'UPDATE').select(src_column_names)
df_merge_p4_2 = df_merge_p4_1.select([F.col(c) \
.alias(c.replace(c[0:4], "")) for c in df_merge_p2.columns])
# Замена src_ alias во всех столбцах

207

  

208

Глава 6. Строим серебряный уровень

df_merge_p4_3 = df_merge.filter(df_merge.action == \
'UPDATE').withColumn('endDate', date_sub(df_merge.src_effectiveDate, 1)) \
.withColumn('current', lit(False)).select(column_names)
# Объединение всех записей
df_merge_final = df_merge_p1.unionAll(df_merge_p2) \
.unionAll(df_merge_p3).unionAll(df_merge_p4_2).unionAll(df_merge_p4_3)
# Существующие записи перезаписываются новой структурой DataFrame
df_merge_final.write.format("delta").mode("overwrite") \
.saveAsTable(schemaName + ".hist_" + tableName)

Наконец, создайте еще одну ячейку кода и вставьте в нее следующий фрагмент.
Эта часть скрипта вызывает функцию SCD2 для каждой таблицы в датасете
AdventureWorks. При вызове указывается имя схемы, имя таблицы и первичный
ключ для каждой таблицы (там, где он есть):
fn_SCD2("adventureworks","address","AddressID")
fn_SCD2("adventureworks","customer","CustomerID")
fn_SCD2("adventureworks","customeraddress","")
fn_SCD2("adventureworks","product","ProductID")
fn_SCD2("adventureworks","productcategory","ProductCategoryID")
fn_SCD2("adventureworks","productdescription","ProductDescriptionID")
fn_SCD2("adventureworks","productmodel","ProductModelID")
fn_SCD2("adventureworks","productmodelproductdescription","")
fn_SCD2("adventureworks","salesorderdetail","")
fn_SCD2("adventureworks","salesorderheader","SalesOrderID")

После вставки кода щелкните кнопку Run, чтобы выполнить скрипт. Если все
сделано правильно, исторические данные должны появиться в таблице с префиксом hist_t на серебряном уровне. На этом практическое упражнение на
серебряном уровне завершается. Мы успешно историзировали данные, что дает
возможность отслеживать изменения во времени и получать более глубокую
аналитику. В последней части этого раздела вы узнаете больше об обработке
исторических данных.
В методе на основе метаданных, который мы обсуждали в этой главе, поле
идентифицируется как первичный ключ пометкой IsPrimaryKey в метаданных. Этот атрибут может использоваться для автоматизации процесса историзации данных.

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

  

Задания оптимизации

209

с Delta Lake на Iceberg сводится к простому изменению в коде: замене write.
format("delta") на write.format("iceberg"). Но как вы видели, реализация этого
процесса в PySpark требует большого объема кода.
Также возможен другой вариант: использование SQL или нативной функции
merge из Delta Lake для достижения похожих результатов за одну операцию. Но он
подходит только для таблиц Delta. Функция merge особенно полезна для обновлений/вставок. Она позволяет эффективно вставлять новые записи, обновлять
существующие и удалять устаревшие записи, управляя историческими данными
и обеспечивая целостность данных. В главе 7 продемонстрировано практическое
применение функции merge в Delta Lake.
Подведем итог. Вы узнали, что создание пайплайна данных для серебряного
уровня обычно включает серию последовательных действий. Начать следует
с технической проверки данных и их очистки. Затем можно провести (необязательное) объединение и обогащение данных. Историзация завершает этот пайплайн. Чтобы он работал эффективно, очень важно поддерживать указанный
порядок действий. В некоторых сценариях удобно разбить пайплайн на сегменты
например, отдельный сегмент для очистки и другой для обогащения данных.
Такая стратегия упрощает обслуживание и управление и позволяет выполнять
параллельную обработку без наложения действий. Однако важно координировать
эти пайплайны, чтобы быть уверенным, что данные обрабатываются в правильной
последовательности.
Перейдем к обсуждению оптимизации и оркестрации. Следующие разделы не
входят в пример Oceanic Airlines и предназначены исключительно для целей
обучения.

Задания оптимизации
С расширением объема хранимых данных эффективное обслуживание таблиц
выходит на первый план в управлении таблицами Delta Lake. В этом процессе
важнейшую роль играет команда OPTIMIZE.
Команда OPTIMIZE (https://oreil.ly/s2f_I) объединяет мелкие файлы в более крупные
и организует данные для повышения производительности запросов. Регулярное
использование этой команды не только увеличивает скорость обработки запросов, но и снижает затраты на них. Для оптимального результата запланируйте ее
ежедневное или еженедельное выполнение в зависимости от ваших потребностей
в обработке данных. Также можно автоматизировать эту команду как часть пайп­
лайна данных. Например, в конце пайплайна данных можно добавить блокнот,
выполняющий команду OPTIMIZE для поддержания и оптимизации таблиц Delta
Lake.
Посмотрим, как связать воедино разные задачи в одном пайплайне данных с использованием Apache Airflow.

  

210

Глава 6. Строим серебряный уровень

Оркестрация с Apache AirFlow
В нашем упражнении мы исследовали многие этапы обработки данных и отметили важность их правильного упорядочения. (Azure) Data Factory с ее широкими
возможностями оркестрации иногда становится визуально перегруженной изза сложного интерфейса с прямоугольниками и стрелками. Поэтому возникает
желание упростить управление рабочими потоками.
Apache Airflow (https://airlow.apache.org) — продукт с открытым исходным кодом,
упрощающий управление рабочими потоками в инженерии данных. Он широко
применяется на практике благодаря своей гибкости и совместимости с разными
движками обработки данных, такими как Microsoft Fabric, Azure Databricks,
Synapse Analytics и многими другими.
Apache Airflow позволяет дата-инженерам создавать рабочие потоки в виде направленных ациклических графов (DAG, Directed Acyclic Graph). DAG представляют собой наборы задач, организованные в соответствии с их взаимосвязями
и зависимостями. Это обеспечивает четкую структуру для выполнения задач
и условий. Создание DAG в Airflow требует написания Python-скрипта. Этот
скрипт, описывающий конфигурацию рабочего процесса, определяет задачи
(tasks) и их зависимости. Каждая задача обычно представлена оператором Airflow,
а зависимости задают порядок выполнения. Основное преимущество этого метода — возможность фиксировать DAG в системах контроля версий, таких как
Git. Использование Python также означает, что сложную логику и управляющие
структуры можно встраивать в рабочие потоки.
Оставшаяся часть раздела представляет практическую демонстрацию работы
с Airflow. Подготовить Airflow к использованию можно двумя способами:
Ручная установка с локальной интеграцией в среды на базе Spark
Этот вариант обеспечивает более высокую степень контроля и не зависит от
других сервисов. Инструкцию по установке можно найти в документации
Installation of Airflow (https://oreil.ly/H2cj_). Для подключения к Microsoft Fabric
не забудьте добавить пакет apache-airflow-microsoft-fabric-plugin (https://
oreil.ly/DF9ht) в среду Airflow.
Управляемый сервис Airlow
Также можно выбрать управляемый сервис Airflow, например, через Data
Workflows в Data Factory. Этот вариант требует меньших текущих затрат
и автоматически интегрируется с другими сервисами Azure. Подробнее см.
в документации Tutorial: Run a Microsoft Fabric Item Job in Apache Airflow
DAGs (https://oreil.ly/TiVIs).
После выбора одного из двух вариантов и входа в веб-интерфейс Airflow можно
приступать к построению DAG. Для Microsoft Fabric я рекомендую использовать управляемый сервис, потому что это проще и не требует лишних действий.

  

Оркестрация с Apache AirFlow

211

Просто убедитесь, что вы выполнили предварительные условия (https://oreil.
ly/7-YEJ) и включили режим Users can create and use Apache Airflow jobs в настройках Microsoft Fabric. После этого можно будет выбрать вариант Apache Airflow
job при создании новой сущности в Workspace. Присвойте ей подходящее имя,
щелкните Create — и все. Страница автоматически перенаправит вас в вебинтерфейс Apache Airflow.
Чтобы создать новый DAG, щелкните вариант New DAG file. Введите имя файла
(например, Adventureworks), а затем щелкните Create. Пример создания DAG
в Apache Airflow:
from airflow import DAG
from apache_airflow_microsoft_fabric_plugin.operators.fabric \
import FabricRunItemOperator
from airflow.utils.dates import days_ago
from airflow.operators.python import PythonOperator
# Определение аргументов по умолчанию
default_args = {
'owner': 'airflow',
'depends_on_past': False,
'email_on_failure': False
}
def my_python_callable():
pass
with DAG('fabric_dag',
description="Рабочий поток ELT в архитектуре медальона",
start_date = days_ago(2),
schedule_interval = None,
default_args = default_args
) as dag:
clean_data = FabricRunItemOperator(
task_id="clean_data",
workspace_id="92187CE0-B7EB-4FDF-80CE-EFF76639EED8",
item_id="27DE4FE9-666D-40BB-8C71-CFF017976D7",
fabric_conn_id="fabric_conn_id",
job_type="RunNotebook",
wait_for_termination=True,
deferrable=True,
)
clean_data_failure = PythonOperator(
task_id="clean_data_failure",
python_callable=my_python_callable,
trigger_rule="all_failed",
)
# Назначение зависимостей задач
clean_data >> clean_data_failure

  

212

Глава 6. Строим серебряный уровень

Этот фрагмент кода (https://oreil.ly/YsVjd) показывает, как выполняется оркестрация задач для очистки и соединения данных для примера DAG из Microsoft Fabric
с именем fabric_dag. Вы можете включить в DAG любое количество задач, каждая
из которых представляет конкретный шаг обработки данных. DAG из примера
использует следующий метод запуска задач:
FabricRunItemOperator

Этот оператор предназначен для активации существующих элементов в Microsoft
Fabric. Вы должны предоставить значение item_id для выполняемого элемента.
Метод позволяет выполнять любые артефакты: блокноты, пайплайны данных
и т. д. Этот оператор может быть более гибким и простым в обслуживании, если
заменить жестко закодированные значения workspace_id и item_id динамическими идентификаторами при помощи пакета sempy (https://oreil.ly/6hpFA).
После сохранения DAG вы сможете просмотреть граф и управлять им через
веб-интерфейс Apache Airflow. Скриншоты на рис. 6.9 и 6.10 показывают, как выглядят DAG в Airflow1. На рис. 6.9 представлен порядок задач и их зависимости
в созданном DAG.

Рис. 6.9. Представление DAG с именем fabric_dag в пользовательском интерфейсе Apache Airflow
1

На момент подготовки русского издания книги вышла версия Airflow 3.x, в которой
почти полностью переработали интерфейс, так что у читателей он может выглядеть
иначе. Но суть от этого не меняется, структура DAG’ов и возможности по управлению
ими там такие же. — Примеч. науч. ред.

  

Заключительные рекомендации

213

Рис. 6.10. Гистограмма и сетка времени DAG в Airflow
На рис. 6.10 изображено представление мониторинга в веб-интерфейсе Apache
Airflow. Здесь вы видите все выполняемые задачи и их текущие статусы. Эта
возможность весьма полезна для отслеживания прогресса и производительности
DAG, позволяя быстро выявлять и решать любые проблемы, возникающие при
выполнении. В верхней части выводится диаграмма выполнения DAG по продолжительности, а внизу представлены экземпляры задач.
Таким образом, Apache Airflow — это чрезвычайно эффективная платформа для
оркестрации сложных рабочих потоков данных. Apache Airflow обладает широкими
возможностями интеграции с Microsoft Fabric, а также с другими сервисами, например Azure Databricks. Кроме того, специфический для Airflow метод определения
оркестрации в коде обеспечивает повышенную гибкость и точность при управлении
задачами данных. Многие дата-инженеры отдают предпочтение Airflow благодаря
эффективной автоматизации и упрощение рабочих потоков.
В конце обсуждения практических особенностей серебряного уровня дадим
несколько рекомендаций, после чего перейдем к изучению продуктов данных.

Заключительные рекомендации
Представьте, что вы — инженер в Oceanic Airlines, которому поручили разработать
надежный пайплайн данных.

  

214

Глава 6. Строим серебряный уровень

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

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

  

Заключительные рекомендации

215

Рост сложности также влияет на другие действия: обогащение данных, денормализацию и историзацию. Различным пользователям могут потребоваться разные срезы
данных, у них могут быть специфические потребности в отношении производительности, что приводит к разным стратегиям и, как следствие, к появлению разных
блокнотов. Историзация также добавляет сложности, так как, возможно, придется
управлять разными версиями данных, обеспечивать эффективную архивацию или
предоставлять простой доступ к историческим данным. Это часто требует применения разнообразных методов, каждый из которых использует свой набор блокнотов.
На практике часто оказывается, что реалистичный пайплайн данных должен быть
более динамичным и адаптируемым, чем могут обеспечить несколько статических блокнотов. Таким образом, когда речь заходит об оптимизации разработки
для инженеров Oceanic Airlines, следует обратить внимание на практические
рекомендации, обеспечивающие хорошее структурирование и удобство обслуживания проекта.
Развивайте культуру инженерии данных
Примите менталитет DevOps, реализуйте пайплайны CI/CD и сформируйте
культуру совместной работы и обмена знаниями. Внедрение этих практик
повышает качество, надежность и эффективность проектов данных.
Используйте Azure Data Factory для перемещения данных и Airflow
для оркестрации
Начните с применения ADF для извлечения и исходного перемещения данных. ADF отлично подходит для таких задач, позволяя выполнять бесшовную
оркестрацию потока данных из разных источников. В свою очередь, Apache
Airflow идеально подходит для оркестрации сложных рабочих потоков, управления зависимостями и планирования задач. Объединив эти два инструмента,
можно создать мощный пайплайн данных, который эффективно перемещает
и обрабатывает данные.
Используйте метаданные
После получения данных извлеките необходимые метаданные. Метаданные
могут передавать информацию о том, как данные обрабатываются на следующих этапах пайплайна.
Повышайте скорость выполнения запросов с высокой конкурентностью
Рассмотрите возможность применения высокой конкурентности или режимов
совместных сеансов. Это позволяет организовать совместное использование
вычислительных ресурсов Spark между несколькими блокнотами, значительно ускоряя выполнение запросов при параллельном выполнении заданий.
Не путайте режим высокой конкурентности Fabric, способствующий этой
эффективности, с кластерным режимом высокой конкурентности (High
Concurrency) Databricks.

  

216

Глава 6. Строим серебряный уровень

Переключитесь с команд вывода на логирование
Вместо того чтобы использовать для отладки команды вывода, реализуйте
модуль ведения журнала. Так вы сможете сохранить вывод чистым и профессиональным, а журнал поможет с выявлением ошибок в эксплуатации.
Кроме того, рекомендуется реализовать единую методологию логирования
в ADF и блокнотах. Это упростит мониторинг, отладку и анализ сквозного
поведения системы.
Защищайте чувствительную информацию
Никогда не храните пароли или учетные данные в файлах Python или блокнотах. Используйте для хранения конфиденциальной информации безопасное
хранилище типа Azure Key Vault (https://oreil.ly/wz6Rn).
Следите за логической организацией кода
Группируйте взаимосвязанные строки кода. Это улучшает удобочитаемость
и контекст, а также облегчает обслуживание кода. Кроме того, используйте
логическую организацию блокнотов. Сгруппируйте их по назначению: очистка
данных, преобразование, обогащение и т. д. Это упрощает управление рабочим
процессом и его понимание. Для каждого блокнота используйте понятное содержательное имя, описывающее его функцию.
Контролируйте версии с помощью Git
Храните артефакты каждой команды (например, блокноты) в репозитории
Git. Эта практика помогает отслеживать изменения, сотрудничать с другими
и вести исторические записи вашей работы. Организуйте репозиторий с папками вида notebooks/, src/ и tests/.
Замените жестко закодированные значения аргументами функций
Чтобы расширить возможность многократного использования и повысить
удобство обслуживания кода, преобразуйте все жестко закодированные данные
из блокнотов в аргументы функций.
Стремитесь к компактности кода
Старайтесь, чтобы размер блокнотов не превышал 300 строк, а функции
ограничивались 100 строками. Если функция становится слишком большой, по возможности разбейте ее на несколько меньших, более компактных
блоков.
Следите за стилем оформления кода
Чтобы убедиться, что ваш код соответствует отраслевым стандартам, подключите Pylint (https://pylint.org). Этот инструмент выполняет статический анализ
кода для обнаружения ошибок и поддержания единого стиля оформления
кода. Рассмотрите возможность принятия стилевого руководства, например
PEP8, для более последовательного оформления кода Python.

  

Данные серебряного уровня как продукт

217

Оптимизируйте хранения с использованием представлений
Если вы создаете промежуточные таблицы, используйте представления вместо
физических таблиц, чтобы свести к минимуму затраты хранилища и ресурсов.
Очищайте память после выполнения
Всегда стирайте временные таблицы и вычислительные ресурсы Spark после
выполнения блокнота, чтобы избежать лишних затрат.
Тестируйте код
Используйте фреймворки тестирования, такие как pytest (https://docs.pytest.
org), чтобы убедиться, что код работает так, как предполагалось, и предотвращать ошибки в будущем.
Используйте IDE для написания рабочего кода
Для более высокой эффективности на продакшен желательно перейти
с Jupyter Notebooks (.ipynb) на скрипты Python (файлы .py). Это улучшит
управление кодом в таких системах контроля версий, как Git, и ускорит
выполнение. Переход на локальную интегрированную среду разработки
(IDE), например Visual Studio Code дополнительно оптимизирует процесс.
Такие IDE предоставляют расширенные средства редактирования и прямой
интеграции с Git, которые упрощают управление кодом и расширяют возможности совместной работы.
Реализовав эти рекомендации, инженеры из Oceanic Airlines смогут улучшить
структуру, эффективность и безопасность своих программных проектов и получить более надежные и удобные для использования результаты. После введения
этих практик данные с бронзового уровня будут достоверными и пригодными для
различных целей. Данные серебряного уровня идеально подходят для операционных отчетов, так как контекст исходной системы часто остается неизменным,
несмотря на внесенные улучшения. Эти данные также хорошо использовать при
тренировке моделей машинного обучения, особенно когда есть возможность
организовать цикл обратной связи о качестве полученных моделей. Кроме указанных применений данные серебряного уровня иногда могут прямо выступать
как продукт данных.

Данные серебряного уровня как продукт
Концепция данных как продукта заметно набрала обороты в последние годы.
Впервые она была описана Жамак Дехгани (Zhamak Dehghani) в статье How
to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (https://oreil.
ly/23m-B). Подход «данные как продукт» ориентирован на то, чтобы пользователи
осуществляли управление данными так же, как управление реальными продуктами. Это подразумевает отношение к данным как к ценному активу, требующему

  

218

Глава 6. Строим серебряный уровень

особого внимания к владению, управлению, обслуживанию и оптимизации
данных.
В контексте архитектур медальона продукты данных эволюционировали в логические представления в каталоге данных, состоящем из различных ресурсов данных: таблиц, файлов, отчетов и т. д. Эти продукты данных, по сути, упаковывают
данные для создания бизнес-ценности вместе с необходимыми метаданными для
описания их структуры, происхождения и отношений к физическим данным.
Продукты данных можно классифицировать по категориям, например, операционные и аналитические. Операционные продукты данных обычно хранятся
и используются на серебряном уровне. Как правило, они соответствуют системамисточникам и поэтому отлично подходят для составления эксплуатационных отчетов и машинного обучения. Со своей стороны, аналитические продукты данных
обычно берутся с золотого уровня и используются для более широкого анализа
данных и составления отчетов.
При проектировании и использовании продуктов данных приходится учитывать
ряд особенностей. Во-первых, продукты данных должны быть ориентированы на
потребителя, иначе говоря, должны быть доступными, понятными и удобными.
Эта ориентация на потребителя и возможность многократного использования
накладывает на дизайн ограничения, обеспечивающие стабильность и обратную
совместимость. Это может ограничить гибкость частого изменения структуры серебряного уровня. Если вы напрямую предоставляете продукты данных с серебряного
уровня, обдумайте и учтите последствия от изменений схемы для этих датасетов.
Другим возможным решением может быть создание (виртуального) подуровня, на
котором размещаются стабильные копии данных специально для этих продуктов.
Во-вторых, данные на серебряном уровне часто группируются по системе-источнику, вследствие чего они хуже подходят для кросс-функционального анализа
с другими источниками данных. В таких ситуациях следует установить принципы,
утверждающие, что операционные продукты данных или данные с серебряного
уровня должны использоваться только в пределах своего конкретного домена.
Такая стратегия гарантирует правильность применения продуктов данных и поддерживает качество данных. Мы еще вернемся к этой теме в главе 7.

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

  

Заключение

219

Однако все этапы обработки на серебряном уровне необходимо проходить в правильной последовательности!
Один из ключевых вопросов — способ организации фаз обработки. Например,
можно ли сохранить все в одной сущности Lakehouse, используя префиксы имен
таблиц вида clean_, quarantine_ или hist_, или же необходимо создать отдельную сущность Lakehouse для каждого шага обработки? Ответ на этот вопрос
зависит от сложности обработки данных и разделения обязанностей. Принимая
решение, необходимо проанализировать компромиссы между управляемостью
и безопасностью.
Как мы уже знаем, у метода, основанного на метаданных, есть очевидные преимущества. Он не только упрощает процессы, но и существенно снижает необходимость в ручном написании скриптов, а также риск ошибок. Такой подход
гарантирует, что при перемещении данных по пайплайну — от проверки целостности до обогащения и историзации — будет поддерживаться высокий стандарт
качества и надежности данных.
Представление о данных как о продукте открывает немало интересных возможностей. Когда вы рассматриваете данные так же, как материальный продукт,
вы следите за их эффективным управлением, обслуживанием и оптимизацией.
Такой подход не только улучшает операционную эффективность, но и расширяет
возможности организации по анализу информации и принятию быстрых обосно­
ванных решений.
Некоторые ключевые выводы из материала этой главы:
Сосредоточьтесь на выполнении необходимых преобразований для уточнения сырых данных, полученных на бронзовом уровне. К их числу относится
решение проблемы отсутствующих значений, исправление ошибок и стандартизация форматов, гарантирующие качество и единообразие данных.
Предоставьте рекомендации по эффективному моделированию данных для
поддержки их четкой структуры и анализа.
Решите, стоит ли интегрировать данные из разных источников для формирования консолидированного представления. Если интеграция в настоящее
время неприемлема, установите рекомендации для поддержания соответствия
между данными и их исходными системами-источниками.
Внедрите стратегию для управления референсными данными, чтобы обеспечить согласованность референсных значений между разными источниками.
Это подразумевает определение централизованного механизма управления
референсными данными для поддержания точности и целостности при сравнении данных и аналитике.
Реализуйте идемпотентность в своем дизайне. Убедитесь, что каждая операция в пайплайне данных (например, merge или append overwrite) может быть
повторена без изменения результата по сравнению с исходным применением.

  

220

Глава 6. Строим серебряный уровень

Избегайте использования append без предшествующего усечения (truncate),
чтобы предотвратить появление дубликатов и обеспечить согласованность.
Расширьте функциональность хранения и обработки данных для эффективного управления их возросшими объемами. Включите задачи оптимизации
и учета в конец пайплайна данных, чтобы обеспечить оптимальную производительность.
Установите процедуры для управления инкрементальными обновлениями,
чтобы поддерживать актуальность серебряного уровня без необходимости
заново обрабатывать весь датасет.
Создайте стандартные функции для автоматизированных задач обработки
данных, включая рутинные проверки и операции сопровождения.
Сформулируйте рекомендации относительно того, должны ли данные сереб­
ряного уровня быть доступными для конечных пользователей и других доменов. Если нет, рассмотрите возможность создания подуровней в серебряном
уровне для создания стабильных копий данных, к которым будут обращаться
пользователи.
Проанализируйте возможность использования фреймворков преобразования
данных (таких, как dbt) для упрощения сложных задач обработки данных,
которые традиционно решаются в блокнотах. Кроме того, подумайте об использовании Airflow для оркестрации этих задач.
В главе 7 мы разберемся в том, что же означает построение золотого уровня. Мы
изучим, как оптимизировать данные для аналитики, создать унифицированное
представление данных и спроектировать уровень, поддерживающий принятие
бизнес-решений. Кроме того, мы обсудим, как настроить каталог для надежного
управления данными и их контроля. Это будет завершающий этап на пути со­
здания сквозной архитектуры медальона.

ГЛАВА 7

Строим золотой уровень
В главе 5 мы построили бронзовый уровень, уделяя основное внимание созданию
структуры с возможностью запросов, несмотря на разнообразие и сложность систем-источников. Я подчеркивал важность стабильности и надежности на этом
фундаментальном уровне. В главе 6 мы переключили внимание на серебряный
уровень, который служит для повышения качества данных и формирования
надежного механизма их обработки. Вы узнали, как адаптировать дизайн сереб­
ряного уровня для удовлетворения специфических потребностей организации.
В заключение мы рассмотрели датасеты, которые проходят тщательное уточнение
и проверку, закладывая основу для следующих стадий.
В этой главе мы продолжим работу с практическим примером, глубже изучая
специфику проектирования золотого уровня — последнюю и самую детализированную стадию архитектуры медальона. Этот уровень играет ключевую роль
в принятии решений и генерации отчетов. Он является вершиной процесса
очистки данных, где они оптимизируются для выполнения высокопроизводительных запросов и аналитики. Этот уровень играет решающую роль в поддержке
критически важных бизнес-функций.
Мы будем действовать по той же схеме, что использовалась на предыдущих
уровнях. Вы увидите, как приобретенные навыки преобразуются в контекст
золотого уровня. Это позволит вам применить все результаты в других средах
на базе Delta Lake и Spark. Часть описания также включает построение семантического уровня — еще одного уровня уточнения или абстракции, дающего более
бизнес-ориентированное представление данных. После того как вы завершите
упражнения и изучите многочисленные примеры, мы обсудим использование
данных и возможности создания продуктов данных на золотом уровне. А в конце
главы подробно поговорим об управлении данными и Microsoft Purview.

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

  

222

Глава 7. Строим золотой уровень

Преобразование данных с использованием схемы «звезда»
Золотой уровень лучше всего организовать по схеме «звезда». Эта разновидность
модели данных особенно эффективна для хранения данных и задач бизнес-аналитики. Как было показано в разделе «Схема “звезда”» главы 3, с. 105, в этой схеме
данные структурируются вокруг центральной таблицы фактов, от которой, словно
лучи звезды, отходят таблицы измерений. Такая структура упрощает сложные
взаимосвязи в данных, облегчая бизнес-пользователям получение информации
для отчетов и анализа. Кроме того, схема «звезда» оптимизирует производительность запросов, вследствие чего она идеально подходит для сред анализа данных
и составления отчетов.
Чтобы начать построение схемы «звезда», необходимо определить требуемые
бизнес-сущности и бизнес-события, так как они будут представлять измерения
и факты в модели схемы. Это обычно делается в тесном сотрудничестве с бизнес-пользователями, так как им известен контекст бизнес-целей и процессов.
Во время общения также необходимо обсудить гранулярность данных, то есть
уровень их детализации. Например, в отчетах для бизнеса могут содержаться
данные об отдельных продуктах и заказах, но не низкоуровневые транзакции,
образующие каждый заказ.
В нашем примере и в базе данных AdventureWorks актуальная информация может
включать продукты, категории продуктов, клиентов, адреса и даты. После определения предметной области, на которой вы сосредоточитесь, определите центральную
таблицу (или таблицы) фактов. Эта таблица содержит ключевые метрики для
анализа (продажи, доходы, количество клиентов). Затем следует спроектировать
таблицы измерений, предоставляющие контекст для фактов, с такими атрибутами,
как время, география, продукт или клиент. Наконец, установите отношения между
таблицами фактов и измерений, используя внешние ключи для завершения схемы.
Важно учитывать, что при загрузке данных в схеме «звезда» всегда следует начинать
с таблиц измерений, а потом переходить к таблицам фактов. Эта последовательность очень важна для поддержания целостности ключевых отношений.
В примере AdventureWorks схема «звезда» включает следующие таблицы:
Измерение адреса
Содержит подробную информацию о каждом адресе (строка адреса 1, город,
штат, страна и т. д.) для классификации и однозначной идентификации адресов.
Измерение клиента
Включает информацию о клиентах (имя клиента, название компании, продавец и т. д.) для классификации и анализа клиентской демографии и поведения.
Измерение даты
Предоставляет временное измерение (дата, день, месяц, год и т. д.) для временного анализа и отчетов.

  

Проектирование золотого уровня

223

Измерение продукта
Содержит подробную информацию о каждом продукте (название продукта,
категория, название модели) для классификации и однозначной идентификации продуктов.
Факты продаж
Центральное место в этой схеме занимает таблица с транзакционными данными (ключ продукта, ключ клиента, сумма продажи и т. д.), необходимыми
для отслеживания и анализа эффективности продаж.
В контексте золотого уровня в архитектуре медальона, где критично принятие
решений и историческая точность, регулярно используются SCD (особенно
тип 2)1, гарантирующие точность представления текущего и исторического
состояния данных. Такой подход предоставляет глубокие аналитические возможности и дает возможность формировать стратегические выводы. В учебном
примере мы продолжим использовать этот метод, хотя и серебряный уровень уже
содержит историзированные данные. В основном это делается в учебных целях
и для понимания процесса.
Применение SCD2 на серебряном уровне чрезвычайно полезно, так как оно
подразумевает хранение всех исторических изменений в данных с использованием достоверного контекста. Применимость SCD2 на золотом уровне
должна определяться конкретными бизнес-требованиями. Если конечные
пользователи должны напрямую обращаться к историческим состояниям
данных для получения информации и анализа, реализация SCD2 может быть
чрезвычайно ценной. Для демонстрации мы будем использовать SCD2 на
золотом уровне, хотя на самом деле это зависит от конкретных обстоятельств.

В следующих разделах вы узнаете, как построить золотой уровень, проектируя
таблицы по схеме «звезда» и загружая данные в виде таблиц Delta. Как показано
на рис. 7.1, конструирование золотого уровня включает три основных этапа: 1) создание таблиц, 2) обработку таблиц измерений и 3) обработку таблицы фактов.
Бронзовый уровень
1. Создание таблиц поиска
2. Копирование файлов
3. Создание таблиц Delta

Серебряный уровень
1. Создание таблиц поиска
2. Проверка таблиц
3. Очистка данных
4. Историзация данных

Золотой уровень
1. Создание таблиц
2. Обработка таблиц измерений
3. Обработка таблицы фактов

Рис. 7.1. Основные цели учебного примера

1

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

  

224

Глава 7. Строим золотой уровень

После создания структуры схемы «звезда» мы также сделаем некоторые промежуточные выводы, прежде чем переходить к семантической модели для установления
отношений между таблицами. Наконец, вы узнаете, как создать отчет Power BI и документировать весь дизайн проекта от начала до конца при помощи потоков задач.

Создание таблиц на золотом уровне
Вернитесь к Microsoft Fabric и откройте рабочее пространство (Workspace) разработки. Выберите в меню Open notebook вариант New notebook. Через несколько
секунд появляется новый блокнот с одной ячейкой. Когда блокнот откроется,
присвойте ему имя create_gold_tables. Процесс переименования аналогичен тем,
которые использовались в главах 5 и 6. Выберите сущность Lakehouse золотого
уровня в левой части экрана, чтобы выполнение происходило в правильной среде.
Переходим к кодингу. Вставьте приведенный ниже код в ячейку блокнота. Скрипт
начинается с создания таблиц измерений для адреса, клиента, даты и продукта,
а также таблицы фактов для продаж на золотом уровне сущности Lakehouse.
Фрагмент кода (https://oreil.ly/SkPU5) следует лучшим практикам, описанным
в разделе «Эволюция и управление схемой» главы 3, с. 80. Он включает необходимые действия для определения схем и сохранения таблиц в таблицах Delta.
Для улучшения управляемости рассмотрите возможность разбиения кода по
отдельным ячейкам для каждой таблицы.
from pyspark.sql.types import *
# Создание схемы
spark.sql(f'CREATE SCHEMA IF NOT EXISTS adventureworks')
# Определение схемы для адреса
schemaAddress = StructType([
StructField("ID", StringType()),
StructField("AddressID", IntegerType()),
StructField("AddressLine1", StringType()),
StructField("AddressLine2", StringType()),
StructField("City", StringType()),
StructField("StateProvince", StringType()),
StructField("CountryRegion", StringType()),
StructField("current_flag", BooleanType()),
StructField("current_date", DateType()),
StructField("end_date", DateType())
])
# Создание DataFrame
dfAddress = spark.createDataFrame([], schemaAddress)
# Создание таблицы
dfAddress.write.mode("append").saveAsTable("adventureworks.dimension_address")
# Определение схемы для клиента
schemaCustomer = StructType([
StructField("ID", StringType()),
StructField("CustomerID", IntegerType()),
StructField("Title", StringType()),

])

  

Проектирование золотого уровня

225

StructField("FirstName", StringType()),
StructField("MiddleName", StringType()),
StructField("LastName", StringType()),
StructField("CompanyName", StringType()),
StructField("EmailAddress", StringType()),
StructField("Phone", StringType()),
StructField("current_flag", BooleanType()),
StructField("current_date", DateType()),
StructField("end_date", DateType())

# Создание DataFrame
dfCustomer = spark.createDataFrame([], schemaCustomer)
# Создание таблицы
dfCustomer.write.mode("append").saveAsTable("adventureworks.dimension_customer")
# Определение схемы для даты
schemaDate = StructType([
StructField("ID", StringType()),
StructField("OrderDate", DateType()),
StructField("Day", IntegerType()),
StructField("Month", IntegerType()),
StructField("Year", IntegerType())
])
# Создание DataFrame
dfDate = spark.createDataFrame([], schemaDate)
# Создание таблицы
dfDate.write.mode("append").saveAsTable("adventureworks.dimension_date")
# Определение схемы для продукта
schemaProduct = StructType([
StructField("ID", StringType()),
StructField("ProductID", IntegerType()),
StructField("ProductNumber", StringType()),
StructField("Color", StringType()),
StructField("Size", StringType()),
StructField("Weight", StringType()),
StructField("CategoryName", StringType()),
StructField("ProductModelName", StringType()),
StructField("current_flag", BooleanType()),
StructField("current_date", DateType()),
StructField("end_date", DateType())
])
# Создание DataFrame
dfProduct = spark.createDataFrame([], schemaProduct)
# Создание таблицы
dfProduct.write.mode("append").saveAsTable("adventureworks.dimension_product")
# Определение схемы для продаж
schemaSales = StructType([
StructField("SalesKey", StringType()),

  

226

])

Глава 7. Строим золотой уровень

StructField("AddressKey", StringType()),
StructField("CustomerKey", StringType()),
StructField("ProductKey", StringType()),
StructField("DateKey", StringType()),
StructField("Revenue", DoubleType()),
StructField("OrderQty", IntegerType()),
StructField("UnitPrice", DoubleType()),
StructField("current_flag", BooleanType()),
StructField("current_date", DateType()),
StructField("end_date", DateType())

# Создание DataFrame
dfSales = spark.createDataFrame([], schemaSales)
# Создание таблицы
dfSales.write.mode("append").saveAsTable("adventureworks.fact_sales")

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

Создание таблицы измерений для адреса
На следующем этапе мы займемся построением таблиц измерений. Начнем
с измерения адреса. Для этого шага создайте еще один блокнот и присвойте ему
имя dimension_address (https://oreil.ly/4yRg8). Для записи на золотой уровень
рекомендуется использовать запись, оптимизированную для V-упорядочения.
Следовательно, в начало блокнота для таблиц золотого уровня следует добавить
следующие настройки конфигурации:
# Создание сеанса для записи в V-порядке
"spark.sql.parquet.vorder.enabled", "true"
"spark.microsoft.delta.optimizeWrite.enabled", "true"
"spark.microsoft.delta.optimizeWrite.binSize", "1073741824"

Эти настройки создают сеанс для записи с включением V-упорядочения. Опция
optimizeWrite сокращает количество созданных файлов и служит для увеличения размера каждого отдельного файла. Для optimizeWrite выбрано значение по

умолчанию 1 Гбайт1, или 1 073 741 824 байта.
1

На основании информации, собранной за несколько лет, Delta Lake рекомендует использовать размер файла по умолчанию равным 1 Гбайт, так как этот размер эффективно
работает на типичных вычислительных экземплярах. Дополнительную информацию см.
в статье: «Delta Lake Small File Compaction with OPTIMIZE» (https://oreil.ly/IVggo).

  

Проектирование золотого уровня

227

После настройки конфигурации добавьте в блокнот новый блок кода и вставьте
в него следующий фрагмент:
from pyspark.sql.functions import *
# Загрузка данных в DataFrame
address = spark.read.table("silver.adventureworks.hist_address") \
.where(col("current") == True)
address = address.dropDuplicates(["AddressID"])
address = address[["AddressID", "AddressLine1", "AddressLine2", \
"City", "StateProvince", "CountryRegion"]]
# Добавление хеш-кода с использованием всех выбранных столбцов
dimension_address = address.withColumn("ID", \
sha2(concat_ws("||", *address.columns), 256))

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

Идентификационные столбцы
На момент написания книги сущность Lakehouse в Fabric не поддерживает
идентификационные столбцы (https://oreil.ly/P0w9x), которые обычно используются в базах данных для автоматического генерирования уникального идентификатора для каждой новой строки данных, упрощая вставку
новых данных и обеспечивая генерирование уникальных идентификаторов
без пересечений. Возможно, ситуация изменится с поддержкой Delta
Lake 3.3.0 (https://oreil.ly/gsXg_) в Microsoft Fabric.
Вместо идентификационного столбца я решил использовать функцию
SHA-2 в скриптах. Эта функция заменяет механизм автоинкремента2,
обеспечивая уникальность записей.

1
2

В таких измерениях суррогатные ключи служат первичными ключами.
Альтернативой для SHA-2 могла бы стать функция monotonically_increasing_id. Подробнее об этом см. в статье «How to Overcome the Identity Column Limitation in Microsoft
Fabric» (https://oreil.ly/EF-xW).

  

228

Глава 7. Строим золотой уровень

После ввода кода в блокнот выполните ячейки. Ход работы можно в любой момент
проверить командой display(df). В данном случае для просмотра содержимого
DataFrame можно выполнить команду display(dimension_address).
Затем добавим следующий блок кода. Эта часть скрипта управляет обновлениями
таблицы dimension_address с использованием операции merge из Delta Lake. Это
позволяет обновлять, вставлять и удалять данные в таблице Delta за одну операцию. Приведенный ниже фрагмент кода достигает этой цели, объединяя ранее
созданную структуру DataFrame с целевой таблицей Delta на золотом уровне.
Фрагмент спроектирован для SCD2.
Краткое описание его работы:
Если запись в DataFrame совпадает с существующей записью в таблице Delta
(на основании суррогатного идентификатора), код обновляет существующую
запись текущей датой.
Если запись не найдена, в таблицу Delta вставляется новая запись.
Если запись в таблице Delta не имеет соответствующей записи в DataFrame,
код обновляет старую запись в таблице Delta; это указывает, что она более не
актуальна.
Скопируйте следующий фрагмент в блокнот для реализации указанных операций
обновления и вставки:
from delta.tables import *
deltaTable = DeltaTable.forPath(spark, \
'Tables/adventureworks/dimension_address')
deltaTable.alias('gold') \
.merge(
dimension_address.alias('updates'),
'gold.ID = updates.ID'
).whenMatchedUpdate(set =
{
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedInsert(values =
{
"ID": "updates.ID",
"AddressID": "updates.AddressID",
"AddressLine1": "updates.AddressLine1",
"AddressLine2": "updates.AddressLine2",
"City": "updates.City",
"StateProvince": "updates.StateProvince",
"CountryRegion": "updates.CountryRegion",
"current_flag": lit("1"),
"current_date": current_date(),

  

Проектирование золотого уровня

229

"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedBySourceUpdate(set =
{
"current_flag": lit("0"),
"end_date": current_date()
}
).execute()

После добавления в блокнот всего необходимого кода запустите выполнение
ячеек. Это действие заполнит таблицу измерений для продуктов на золотом
уровне сущности Lakehouse. После выполнения ячеек не пожалейте времени
и проведите дополнительные проверки согласованности, чтобы убедиться, что
все настроено правильно.
На момент написания книги схемы Lakehouse (https://oreil.ly/jZvpI) находятся
на предварительной стадии разработки, а метод DeltaTable.forName еще не
поддерживается. Это означает, что для обращения к таблицам Delta придется использовать метод DeltaTable.forPath. Ожидается, что в будущем ситуация изменится.

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

Создание таблицы измерений для клиентов
Создайте новый блокнот и присвойте ему имя dimension_customer (https://oreil.
ly/NvgeJ). Просто повторите действия, описанные выше для таблицы измерений
address, но на этот раз примените их к данным клиентов. Используйте следующие
фрагменты кода:
from pyspark.sql.functions import *
# Загрузка данных в DataFrame как отправная точка для создания золотого уровня
customer = spark.read.table("silver.adventureworks.hist_customer") \
.where(col("current") == True)
customer = customer.dropDuplicates(["CustomerID"])
dimension_customer = customer[["CustomerID", "Title", "FirstName", \
"MiddleName", "LastName", "CompanyName", "EmailAddress", "Phone"]]
# Добавление хеш-кода с использованием всех выбранных столбцов
dimension_customer = dimension_customer.withColumn("ID", \
sha2(concat_ws("||", *dimension_customer.columns), 256))

Наконец, скопируйте в новую ячейку следующий фрагмент кода для обновления
таблицы dimension_customer:
from delta.tables import *
deltaTable = DeltaTable.forPath(spark, \
'Tables/adventureworks/dimension_customer')

  

230

Глава 7. Строим золотой уровень

deltaTable.alias('gold') \
.merge(
dimension_customer.alias('updates'),
'gold.ID = updates.ID'
).whenMatchedUpdate(set =
{
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedInsert(values =
{
"ID": "updates.ID",
"CustomerID": "updates.CustomerID",
"Title": "updates.Title",
"FirstName": "updates.FirstName",
"MiddleName": "updates.MiddleName",
"LastName": "updates.LastName",
"CompanyName": "updates.CompanyName",
"EmailAddress": "updates.EmailAddress",
"Phone": "updates.Phone",
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedBySourceUpdate(set =
{
"current_flag": lit("0"),
"end_date": current_date()
}
).execute()

Снова выполните ячейки блокнота, чтобы проверить результаты.

Создание таблицы измерений для даты
Создадим таблицу измерений для дат. Таблица будет использоваться для формирования контекста данных продаж из таблицы фактов. В ней хранятся поля для
даты, месяца, года и т. д. Обратите внимание: для этой таблицы данные не историзируются, потому что атрибуты дат фиксированны и не изменяются со временем.
Создайте новый блокнот и присвойте ему имя dimension_date (https://oreil.ly/
OuN18). Скопируйте следующий код в ячейку блокнота, чтобы создать таблицу
измерений для дат:

from pyspark.sql.functions import *
# Загрузка данных в DataFrame
dim_date = spark.read.table("silver.adventureworks.hist_salesorderheader") \
.where(col("current") == True)
dim_date = dim_date.dropDuplicates(["OrderDate"]).select(col("OrderDate"), \
dayofmonth("OrderDate").alias("Day"), \

  

Проектирование золотого уровня

231

month("OrderDate").alias("Month"), \
year("OrderDate").alias("Year")
).orderBy("OrderDate")
# Добавление хеш-кода с использованием всех выбранных столбцов
dim_date = dim_date.withColumn("ID", \
sha2(concat_ws("||", *dim_date.columns), 256))

Этот фрагмент кода извлекает день, месяц и год из столбца OrderDate и сортирует
DataFrame по OrderDate. Для обеспечения согласованности с другими таблицами
он в итоге генерирует уникальный хеш-код для каждой строки в таблице измерений. Хеш-код действует как суррогатный ключ для таблицы измерений даты.
Следующий шаг — слияние DataFrame с целевой таблицей Delta на золотом уровне. Используйте приведенный ниже фрагмент кода для обработки обновлений
в таблице dimension_date:
from delta.tables import *
deltaTable = DeltaTable.forPath(spark, \
'Tables/adventureworks/dimension_date')
deltaTable.alias('gold') \
.merge(
dim_date.alias('updates'),
'gold.ID = updates.ID'
).whenNotMatchedInsert(values =
{
"ID": "updates.ID",
"OrderDate": "updates.OrderDate",
"Day": "updates.Day",
"Month": "updates.Month",
"Year": "updates.Year",
}
).execute()

Снова выполните ячейки блокнота, чтобы проверить результаты.

Создание таблицы измерений для продукта
Создайте новый блокнот с именем dimension_product (https://oreil.ly/MkzXF). Этот
блокнот сначала загружает и фильтрует данные из таблиц продуктов, категорий
продуктов и моделей продуктов, проверяя, что остаются только самые новые
и уникальные записи, основанные на конкретных идентификаторах. Затем таблицы усекаются до самых необходимых столбцов, и между ними выполняются
соединения. Просто повторите ранее выполненные действия, используя следующий фрагмент кода:
from pyspark.sql.functions import *
# Загрузка данных в DataFrame

  

232

Глава 7. Строим золотой уровень

product = spark.read.table("silver.adventureworks.hist_product") \
.where(col("current") == True)
product = product.dropDuplicates(["ProductID"])
product = product[["ProductID", "Name", "ProductNumber", \
"Color", "Size", "Weight", "ProductCategoryID", "ProductModelID"]]
category = spark.read.table("silver.adventureworks.hist_productcategory") \
.where(col("current") == True)
category = category.dropDuplicates(["ProductCategoryID"])
category = category[["ProductCategoryID", "Name"]]
category = category.withColumnRenamed("Name", "CategoryName")
model = spark.read.table("silver.adventureworks.hist_productmodel") \
.where(col("current") == True)
model = model.dropDuplicates(["ProductModelID"])
model = model[["ProductModelID", "Name", "CatalogDescription"]]
model = model.withColumnRenamed("Name", "ProductModelName")
# Выполнение соединений
dimension_product = product.join(category, on="ProductCategoryID", how="left")
dimension_product = dimension_product.join(model, \
on="ProductModelID", how="left")
# Выбор только актуальных столбцов
dimension_product = dimension_product[["ProductID", "Name", "ProductNumber", \
"Color", "Size", "Weight" , "CategoryName" , "ProductModelName"]]
# Добавление хеш-кода с использованием всех выбранных столбцов
dimension_product = dimension_product.withColumn("ID", \
sha2(concat_ws("||", *dimension_product.columns), 256))

Скопируйте фрагмент кода, выполняющий обновления таблицы dimension_

product, в новую ячейку:

from delta.tables import *
deltaTable = DeltaTable.forPath(spark, \
'Tables/adventureworks/dimension_product')
deltaTable.alias('gold') \
.merge(
dimension_product.alias('updates'),
'gold.ID = updates.ID'
).whenMatchedUpdate(set =
{
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedInsert(values =
{
"ID": "updates.ID",
"ProductID": "updates.ProductID",
"ProductNumber": "updates.ProductNumber",
"Color": "updates.Color",
"Size": "updates.Size",

  

Проектирование золотого уровня

233

"Weight": "updates.Weight",
"CategoryName": "updates.CategoryName",
"ProductModelName": "updates.ProductModelName",
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""

}
).whenNotMatchedBySourceUpdate(set =
{
"current_flag": lit("0"),
"end_date": current_date()
}
).execute()

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

Создание таблицы фактов по продажам
Напишем скрипты для заполнения таблицы фактов, центра схемы «звезда».
В таблице фактов хранятся количественные данные для анализа, а вокруг нее
располагаются таблицы измерений с описательными атрибутами, относящимися к фактам. В нашем учебном примере таблица фактов включает данные,
относящие­ся к продажам, и ключи для связи с таблицами измерений. Эти ключи
позволяют соединить таблицу фактов с таблицами измерений, упрощая многомерный анализ.
В среде Lakehouse создайте новый блокнот с именем fact_sales (https://oreil.ly/
YKmYC). Проделайте то же, что для продуктов и клиентов, то есть скопируйте
в ячейку код для выбора, соединения и фильтрации данных. Для учебных целей
этот шаг включает небольшой объем бизнес-логики, так как пример требует расчета выручки от каждой позиции в заказе (order detail).
Когда все будет готово, используйте приведенные фрагменты кода для создания
и заполнения структуры DataFrame sales:
from pyspark.sql.functions import *
# Загрузка данных в DataFrame
orderdetail = spark.read.table("silver.adventureworks.hist_salesorderdetail") \
.where(col("current") == True)
orderdetail = orderdetail.dropDuplicates(["SalesOrderID"])
orderdetail = orderdetail[["SalesOrderID", "SalesOrderDetailID", \
"ProductID", "OrderQty", "UnitPrice"]]
orderdetail = orderdetail \
.withColumn("Revenue",orderdetail["OrderQty"] \
* orderdetail["UnitPrice"] )
orderheader = spark.read.table("silver.adventureworks.hist_salesorderheader") \

  

234

Глава 7. Строим золотой уровень

.where(col("current") == True)
orderheader = orderheader.dropDuplicates(["SalesOrderID"])
orderheader = orderheader[["SalesOrderID", "CustomerID", \
"BillToAddressID", "OrderDate"]]
orderheader = orderheader \
.withColumnRenamed("SalesOrderID", "SalesOrderID2")
# Выполнение соединений
sales = orderdetail.join(orderheader, \
orderdetail['SalesOrderID'] == orderheader['SalesOrderID2'], "left")
sales = sales.withColumn('SalesKey', concat(sales['SalesOrderID'], \
sales['SalesOrderDetailID']))
# Выбор только подходящих столбцов
sales = sales[["SalesKey", "ProductID", "CustomerID", \
"BillToAddressID", "Revenue", "OrderDate", "OrderQty", "UnitPrice"]]

А теперь подготовим DataFrame для таблицы фактов, внедряя суррогатные
ключи из таблиц измерений. Для ускорения этого процесса таблица фактов
будет соединена с таблицами измерений при помощи бизнес-ключей и только
текущих данных. В качестве бизнес-ключей используются исходные ключи из
систем-источников, такие как CustomerID, ProductID и OrderDate. Скрипт выбирает
суррогатные ключи из таблиц измерений и переименовывает их для совмещения
со схемой таблицы фактов.
Использование суррогатных ключей необходимо для поддержания целостности
и согласованности данных. Они служат уникальными, назначаемыми базой данных идентификаторами, сокращающими зависимость от бизнес-ключей, которые
могут изменяться со временем из-за разных факторов бизнеса или текущей эксплуатации. Даже при изменении атрибутов бизнес-ключей суррогатные ключи
остаются неизменными, сохраняя согласованность исторических данных. Кроме
того, суррогатные ключи эффективно справляются с разными версиями данных,
гарантируя, что таблицы фактов будут точно соединены с правильной версией
записей измерений.
Скопируйте следующий фрагмент в ячейку блокнота:
# Загрузка текущих данных из таблиц измерений
dimension_address = spark.read.table("adventureworks.dimension_address") \
.where(col("current_flag") == True)
dimension_customer = spark.read.table("adventureworks.dimension_customer") \
.where(col("current_flag") == True)
dimension_product = spark.read.table("adventureworks.dimension_product") \
.where(col("current_flag") == True)
dimension_date = spark.read.table("adventureworks.dimension_date")
# Соединение таблицы фактов с таблицами измерений по бизнес-ключам
fact_sales = sales.join(dimension_address,(sales.BillToAddressID \
== dimension_address.AddressID), "left") \
.join(dimension_customer,(sales.CustomerID \

  

Проектирование золотого уровня

235

== dimension_customer.CustomerID), "left") \
.join(dimension_product,(sales.ProductID \
== dimension_product.ProductID), "left") \
.join(dimension_date,(sales.OrderDate \
== dimension_date.OrderDate), "left") \
.select(col("dimension_address.ID").alias("AddressKey"), \
col("dimension_customer.ID").alias("CustomerKey"), \
col("dimension_product.ID").alias("ProductKey"), \
col("dimension_date.ID").alias("DateKey"), \
col("SalesKey"), col("Revenue"), col("OrderQty"), col("UnitPrice"))

Наконец, последний фрагмент кода обрабатывает обновления таблицы fact_
sales. Скопируйте следующий код в ячейку:
from delta.tables import *
deltaTable = DeltaTable.forPath(spark, \
'Tables/adventureworks/fact_sales')
deltaTable.alias('gold') \
.merge(
fact_sales.alias('updates'),
'gold.SalesKey = updates.SalesKey \
AND gold.AddressKey = updates.AddressKey \
AND gold.CustomerKey = updates.CustomerKey \
AND gold.ProductKey = updates.ProductKey \
AND gold.DateKey = updates.DateKey' \
).whenMatchedUpdate(set =
{
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedInsert(values =
{
"SalesKey": "updates.SalesKey",
"AddressKey": "updates.AddressKey",
"CustomerKey": "updates.CustomerKey",
"ProductKey": "updates.ProductKey",
"DateKey": "updates.DateKey",
"Revenue": "updates.Revenue",
"OrderQty": "updates.OrderQty",
"UnitPrice": "updates.UnitPrice",
"current_flag": lit("1"),
"current_date": current_date(),
"end_date": """to_date('9999-12-31', 'yyyy-MM-dd')"""
}
).whenNotMatchedBySourceUpdate(set =
{
"current_flag": lit("0"),
"end_date": current_date()
}
).execute()

  

236

Глава 7. Строим золотой уровень

После вставки кода еще раз выполните ячейки в блокноте. На этот раз таблица
фактов будет создана на золотом уровне сущности Lakehouse. Выделите немного времени на проверку результатов. Они должны соответствовать данным на
рис. 7.2.
С созданием таблицы фактов вы успешно завершили настройку золотого уровня
для Oceanic Airlines. Теперь уровень готов к поддержке высокопроизводительных запросов и аналитики, позволяя извлекать ценную информацию из данных.
Остается еще один шаг: включение блокнотов в пайплайн данных. Я рекомендую
связать этап создания таблиц золотого уровня с шагом историзации данных — последним действием серебряного уровня. После этого следует добавить блокноты
измерений; можно организовать их параллельное выполнение, так как между ними
нет зависимостей. Наконец, внедрите блокнот фактов, ответственный за обработку
таблицы фактов. Последние стадии пайплайна данных представлены на рис. 7.3.
После изменения пайплайна данных золотой уровень готов к поддержке высокопроизводительных запросов и аналитики, позволяющих формировать ценные
аналитические выводы из данных.

Рис. 7.2. Использование эндпоинта SQL для вывода итогового результата: данных, прошедших
преобразование и оптимизированных для аналитики

  

Проектирование золотого уровня

237

Рис. 7.3. Завершающие стадии пайплайна данных с историзацией, параллельной обработкой измерений
и формированием таблицы фактов

Идемпотентность как ключевой принцип дизайна
В этом упражнении мы сосредоточились на создании идемпотентного
пайплайна данных. Этот термин означает, что пайплайн может выполняться многократно без каких-либо проблем и всегда будет выдавать
один и тот же результат. Например, при отсутствии изменений в данных
системы-источника повторное выполнение пайплайна не приведет ни
к каким изменениям: на бронзовом уровне будут загружаться те же файлы
Parquet, будут построены те же таблицы Delta и на серебряном уровне не
появятся новые записи. Это объясняется тем, что тип 2 — единственный
метод SCD, обеспечивающий реальную идемпотентность. Идемпотентный дизайн критичен для поддержания целостности и согласованности
данных в пайплайне.
Перейдем к созданию семантической модели и отношений между таблицами. Этот
шаг играет ключевую роль для обеспечения надлежащей структурированности
модели данных и эффективного взаимодействия таблиц. Он укрепляет целостность данных и делает их более удобными для использования, а анализ — более
содержательным и надежным. Остается разобраться с завершающим этапом.

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

  

238

Глава 7. Строим золотой уровень

модель — это способ представления и организации данных, упрощающий их
понимание и анализ. Можно рассматривать ее как преобразование сложной модели данных с техническими именами столбцов в структуру, более удобную для
пользователя. Это мощный механизм, значительно расширяющий возможности
самообслуживания для бизнес-пользователей, так как они получают возможность взаимодействовать с данными без глубоких технических знаний в области
обработки данных или языков запросов. Более того, семантические модели могут
использоваться в сочетании с другими инструментами, такими как Power BI,
Excel, мобильные приложения и компоненты Microsoft Power Platform.
Будьте внимательны при конструировании семантических моделей, поскольку это может значительно повлиять на общий дизайн и функциональность
золотого уровня. Неправильная модель может привести к неэффективности,
росту затрат и потенциальным ошибкам в обработке данных и получении
информации.

На золотом уровне таблицы создавались с использованием SCD2. Следовательно,
у вас имеется полная история изменений данных. В структуре таблиц присутствуют столбцы current_flag, current_date и end_date, чтобы вы могли обращаться
как к текущим, так и к прошлым версиям данных.
Однако здесь возникает дилемма. У Direct Lake (https://oreil.ly/EVRga)1, режима
прямых запросов к таблицам Delta, существует ограничение: он запрашивает
данные в существующем виде и не поддерживает использование конструкций
SELECT или WHERE в запросах. Это ограничение заставляет искать альтернативные
решения. У каждого из них есть достоинства и недостатки.
Первый возможный вариант — создание на золотом уровне представлений, которые затем могут интегрироваться в семантическую модель. Это представление
может использоваться для фильтрации исторических данных и включения только
актуальных данных. Вот пример (https://oreil.ly/4le1q) создания такого представления командой SQL:
IF OBJECT_ID('adventureworks.v_dimension_customer', 'V') IS NOT NULL
DROP VIEW adventureworks.v_dimension_customer
GO
CREATE VIEW adventureworks.v_dimension_customer
AS SELECT * FROM adventureworks.dimension_customer WHERE current_flag = 1;

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

Режим Direct Lake позволяет Power BI подключаться напрямую к таблицам Delta и отправлять запросы к ним в реальном времени, исключая необходимость в импортировании данных в Power BI с запланированными обновлениями. Также доступен режим
Import, в котором данные импортируются в Power BI.

  

Проектирование золотого уровня

239

к представлению Lakehouse режим Direct Lake по умолчанию переключается в режим DirectQuery (https://oreil.ly/NgKTq), что может ухудшить производительность.
Второй вариант — использование режима Import (https://oreil.ly/tzFy8) в Power
BI, что позволяет выполнить выборку, фильтрацию или другие манипуляции
с данными перед их импортированием в модель. Хотя этот метод подразумевает
дублирование данных и требует их начальной загрузки, что мешает обращению
к данным в реальном времени и потенциально увеличивает сложность и затраты,
он делает возможной настройку и быстрый доступ к данным. Кроме того, он может
обслуживать многих пользователей одновременно без необходимости повторного
получения данных из источника.
В третьем варианте фильтры применяются напрямую к отчетам после загрузки
всех данных из таблиц Delta. Такой подход менее эффективен, так как он требует
дополнительной обработки в Power BI для отсеивания исторических данных. Это
может привести к снижению производительности. Более того, этот подход поднимает вопросы о готовности золотого уровня к потреблению (раз необходима
дополнительная фильтрация в отчетах).
Четвертый вариант требует изменения золотого уровня для повышения эффективности потребления данных. Задача может решаться разными способами.
В нашем примере можно утверждать, что историзированные данные уже присутствуют на серебряном уровне. Можно хранить на золотом уровне только актуальные данные, перезаписывая логику преобразования. Такое изменение сократит
сложность модели данных и улучшит производительность. В то же время это
может ограничить будущие сценарии использования, требующие исторических
данных. Другой метод основан на поддержании существующей модели данных
с добавлением таблиц, оптимизированных для конкретных сценариев использования. В этом случае поддерживается курируемый уровень для обобщенного
использования и семантические уровни для конкретных сценариев. Последняя
стратегия требует написания дополнительного кода для управления данными,
что теоретически может повысить сложность пайплайна. С другой стороны, она
также может повысить эффективность многократного использования данных
и позволяет применять более адаптированные модели данных для разных сценариев использования. Помните об этом, оценивая этот вариант.
Понимание особенностей и применимости каждого варианта необходимо для
принятия обоснованных решений. В корпоративных средах лучшие практики
направлены на поиск компромиссов между режимом Import и оптимизацией
дизайна золотого уровня для улучшения потребления данных в режиме Direct
Lake. Объединение стратегий, таких как использование представлений и дублирование данных на золотом уровне, может создать более гибкую и эффективную модель данных, которая повышает производительность и упрощает
доступ к данным.
Учитывая эти компромиссы и лучшие практики, создадим семантическую модель,
которая внедряет таблицы золотого уровня, разработанные в учебном примере.

  

240

Глава 7. Строим золотой уровень

Такая модель потребует, чтобы пользователи напрямую применяли фильтры
в своих отчетах, делая возможными анализ и исследование динамических данных.
Вот последовательность действий:
1. Перейдите в сущность Lakehouse золотого уровня в рабочем пространстве.
2. Щелкните кнопку New semantic model на ленте в верхней части представления
Lakehouse.
3. Введите имя семантической модели, например Sales.
4. Выберите преобразованные таблицы Gold, которые должны быть включены
в семантическую модель: dimension_address, dimension_customer, dimension_
date , dimension_product и fact_sales . Выбор таблиц для семантической
модели показан на рис. 7.4.

Рис. 7.4. Создание новой семантической модели для таблиц измерений и таблицы фактов

  

Проектирование золотого уровня

241

5. Свяжите таблицы, создавая отношения между ними. Например, можно создать
отношения между полем CustomerKey таблицы fact_sales и полем ID таблицы
dimension_customer. Повторите этот процесс для всех таблиц, чтобы установить необходимые связи.
6. После этого определите кардинальность связей. Например, отношения между
идентификаторами измерений и ключами факторов являются отношениями
типа «один ко многим».
7. Переименуйте таблицы и скройте все лишние столбцы, чтобы модель была
более удобной для пользователя. Например, можно переименовать таблицу
dimension_customer в customer и скрыть столбцы ID и CustomerID.
8. Создайте метрики для таблицы sales. Например, можно создать метрику для
Revenue, чтобы вычислить общий доход от продаж. Для этого можно щелкнуть
правой кнопкой мыши столбец TotalRevenue и выбрать New measure. В верхней
части экрана метрика может определяться на языке DAX:
TotalRevenue = SUM(sales[Revenue])

9. Щелкните Confirm, чтобы завершить работу.
После создания семантической модели экран должен выглядеть, как показано
на рис. 7.5.
Power BI DAX (сокращение от Data Analysis Expressions) — язык формул, используемый в Power BI для выполнения вычислений и генерирования новой
информации по существующим данным в модели. Однако он также может потребовать интенсивных вычислений. Поэтому рекомендуется провести как можно
больше вычислений заранее, в источнике данных, прежде чем импортировать их
в Power BI. Кроме того, оптимизация формул DAX за счет минимизации контекстных переходов и использования эффективных функций значительно повышает производительность. Грамотное проектирование модели данных, особенно
с использованием схемы «звезда», и управление отношениями с правильной
кардинальностью приведут к тому, что отчеты Power BI и другие приложенияпотребители будут быстрыми и масштабируемыми.
После установления отношений и метрик в семантической модели все готово
для создания отчетов и дашбордов в Power BI. Это завершающий шаг разработки
в нашем примере.

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

  

242

Глава 7. Строим золотой уровень

Рис. 7.5. Обзор семантической модели для адреса, клиента, даты, продукта и продаж
В этом упражнении мы будем использовать семантическую модель в качестве
источника данных. Чтобы приступить к созданию отчета в Power BI, щелкните
кнопку New Report и подождите загрузки. Когда холст отчета откроется, перетащите поля из таблиц на холст. Например, поле TotalRevenue (Общая выручка)
из таблицы sales и поле StateProvince (Штат/Провинция) из таблицы customer.
Затем создайте свои визуализации. Для этого выберите группированную столбчатую диаграмму (clustered column chart) из вариантов визуализации и перетащите
ее на отчет. Разместите и отформатируйте визуализации, чтобы данные были
понятными и выглядели привлекательно.

  

Проектирование золотого уровня

243

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

Рис. 7.6. Отчет в Power BI показывает объем выручки по штатам/провинциям
Когда макет и содержимое отчета будут готовы, сохраните отчет под именем, например, RevenuePerState (Выручка по штатам) и опубликуйте в своем рабочем
пространстве. Отчет будет соединен с золотым уровнем сущности Lakehouse, что
гарантирует, что он всегда будет отражать самые актуальные данные.
Теперь вы можете поделиться отчетом с членами вашей организации или встроить
его в презентацию PowerPoint. К преимуществам такого подхода можно отнести
то, что информация остается связанной с золотым уровнем в Lakehouse. Эта
связь гарантирует, что данные презентации будут оставаться актуальными без
каких-либо усилий с вашей стороны и при этом будут соблюдаться политики
и практики безопасности, определенные в Lakehouse.
Прежде чем завершать обсуждение и переходить к следующим шагам, документируем процесс при помощи потоков задач, чтобы обеспечить ясность и простоту
воспроизведения в будущих проектах.

  

244

Глава 7. Строим золотой уровень

Создание потоков задач
В Microsoft Fabric поддерживаются потоки задач (task flows) (https://oreil.ly/
U3Xo5), помогающие наглядно представить их в рабочем пространстве. Этот

инструмент помогает понять, как разные элементы сочетаются друг с другом
и работают совместно, упрощая навигацию по постепенно усложняющемуся
рабочему пространству.
Чтобы создать поток задач, перетащите ползунок в среднюю позицию, как на
рис. 7.7. После этого начните перетаскивать задачи в поток. Каждая добавляемая
задача может представлять разный вид работы: обработку, хранение или визуализацию данных. Этот наглядный механизм используется для документирования
действий, выполняемых в примере.
После завершения поток задач автоматически появится в Workspace. На рис. 7.7
представлен пример документирования всего рабочего потока.

Рис. 7.7. Представление разных действий Workspace на холсте
Итак, упражнение завершено, все практические действия проделаны — пришло
время обдумать пройденные шаги и рассмотреть дизайн в целом. Это поможет
понять, что было сделано, и запланировать будущие улучшения.

  

Проектирование золотого уровня

245

Усовершенствования золотого уровня
Мы добрались до конца учебного примера. Вы увидели, что дизайн схемы «звезда»
одновременно прост и эффективен. Он содержит понятное и компактное представление данных, которое ускоряет анализ и принятие решений. Изначально
данные находились в сложной структуре 3NF из базы данных AdventureWorks,
из-за чего с ними было трудно работать неразработчикам. Приведя их к более
удобной для пользователя структуре, мы повысили их удобочитаемость и эффективность. Разбиение на четко определенные сущности помогает пользователям
понять данные, их предполагаемое использование и возможности их обогащения
дополнительными деталями. Размерное моделирование в этом упражнении
также помогает создавать уровни моделей, предназначенные для использования
инструментами бизнес-аналитики.
Однако этот дизайн можно улучшить. Вот несколько способов:
Упрощайте для пользователей, не владеющих SQL
Конечному пользователю или даже специалисту data science, недостаточно
хорошо знающему SQL, понять одну большую таблицу будет проще, чем
схему «звезда», несмотря на то что большая таблица не столь эффективна
при выполнении запросов и обслуживании. Создание семантической модели
с таблицами и столбцами, которым присвоены понятные и осмысленные имена,
также упростит работу пользователя, плохо владеющего SQL. Таким образом,
золотой уровень может включать дополнительные подуровни, спроектированные для большей доступности и удобства.
Повышайте качество данных
Настоятельно рекомендуется добавить на золотой уровень дополнительный
шаг контроля качества данных, непосредственно за очисткой и соединением
данных на серебряном уровне, чтобы обеспечить успешное конструирование
интегрированного датасета.
Кроме того, для точного соединения записей можно включить в каждое измерение серебряного уровня запись-заполнитель. У этой записи все столбцы
содержат 0, что упростит выявление и решение проблем с любыми пропущенными данными на золотом уровне. В случаях, если в таблице фактов отсутствует размерная запись для ID, запись-заполнитель помогает распознать
отсутствующие данные и обеспечить успешное соединение.
Повышайте производительность
Добавление партиционирования в схему может улучшить производительность запросов за счет сокращения объема данных, сканируемых в процессе
запроса. Другое потенциальное улучшение производительности реализуется
за счет использования меньших таблиц поиска для получения хешей таблиц
измерений. Такое решение сокращает объем данных, сканируемых в процессе
соединений.

  

246

Глава 7. Строим золотой уровень

Включайте столбцы аудита и обработки
Включение таких столбцов, как created_at (создано тогда-то), updated_at
(обновлено тогда-то) и source_system (система-источник), как в таблицы измерений, так и в таблицу фактов помогает отслеживать происхождение данных
(data lineage) и упрощает диагностику.
Реализуйте меры безопасности данных
Вы можете добавить столбцы для реализации безопасности уровня строк
с ограничением доступа к данным на основании пользовательских ролей или
разрешений. Например, для базы данных AdventureWorks можно добавить
дополнительную таблицу HumanResources.Employee (сотрудники) для ограничения доступа к данным в зависимости от отдела, к которому относится
каждый работник. После этого можно воспользоваться системной функцией
USER_NAME() для сопоставления со значением LoginID из таблицы Employee,
определяющим, к каким данным может обращаться пользователь. Подробнее
о безопасности уровня строк данных см. в документации Microsoft Fabric
(https://oreil.ly/kk_MQ) и Power BI (https://oreil.ly/F7fJN).
Добавьте по необходимости дополнительные уровни
В зависимости от сложности данных и потребностей пользователей, возможно, понадобится добавить на золотой уровень дополнительные уровни (со
специализированными таблицами). Такие уровни могут предназначаться для
различных сценариев использования или бизнес-подразделений; различные
приложения могут иметь разные требования в отношении структуры данных,
гранулярности или уровней агрегирования. Эти подуровни могут оптимизироваться по отдельности, например, партиционированием в зависимости
от характеристик использования. Примерно так же можно поступить при
пересечении требований. Вы создаете общий уровень интеграции с согласованными измерениями и данными, которые часто используются на входе
разных сценариев. Затем добавляются подуровни для конкретных сценариев
использования, требующих дополнительных данных или разных операций
агрегирования.
Добавьте по необходимости уровень физических сервисов
В зависимости от сложности данных и потребностей пользователей может
возникнуть необходимость в уровне физических сервисов. Здесь данные копируются с золотого уровня в один или несколько сервисов, чтобы упростить
конечным пользователям обращение к ним. Речь идет о таких продуктах, как
Azure Cosmos DB, Azure SQL Database или база данных для аналитики в реальном времени (https://oreil.ly/YqaJi).
Что касается технологической архитектуры (особенно для сервисного уровня), очень важно понимать, что выбор базы данных или сервиса — достаточно
сложная процедура. Для этого необходимо проанализировать различные
факторы и пойти на некоторые компромиссы. Кроме структуры данных надо

  

Проектирование золотого уровня

247

оценить требования в отношении согласованности, доступности, кэширования,
своевременности и индексирования для повышения производительности.
Существуют разные методы хранения и чтения данных: с использованием
меньших или больших блоков, отсортированных фрагментов и т. д. Что бы ни
утверждали некоторые энтузиасты, ни один способ не сможет идеально подойти для всех свойств одновременно. Таким образом, типичная архитектура
озер-хранилищ обычно состоит из набора разнообразных технологических
сервисов, таких как бессерверный сервис SQL для ситуативных запросов,
колоночное хранилище для быстрых отчетов, реляционная база данных для
более сложных запросов, хранилище временных рядов для IoT и потокового
анализа и т. д.
Инструменты no-code или low-code
В зависимости от пользовательской базы может быть полезно включить
инструменты, не требующие написания кода (no-code) или требующие минимального кодинга (low-code) на золотом уровне. Это позволит пользователям
(самостоятельно) преобразовать данные без необходимости писать блокноты
или запросы SQL.
Например, в Microsoft Fabric для этого можно воспользоваться Dataflow Gen2
(https://oreil.ly/qp-7B)1. На рис. 7.8 представлено возможное преобразование
золотого уровня c помощью визуальных средств и инструментов с минимумом кода.
Также Microsoft Fabric предлагает инструмент Data Wrangler (https://oreil.ly/
RyAk8) для ускорения исследования и подготовки данных. Этот инструмент

интегрируется с библиотекой pandas и включает встроенные визуализации для
упрощения процесса. На рис. 7.9 показано, как он подготовил золотой уровень.
Добавьте Apache Airlow для оркестрации
В зависимости от требований организации стоит рассмотреть добавление
Apache Airflow для оркестрации пайплайнов данных. Мы уже рассматривали
возможности этого инструмента в разделе «Оркестрация с Apache AirFlow»
главы 6, с. 210. Этот сервис поможет автоматизировать пайплайн данных,
планировать задания и наблюдать за обработкой данных.
Генерирация признаков и машинное обучение
Спроектируйте уровни Silver и Gold с расчетом на дальнейшую генерацию
признаков и эксперименты с машинным обучением. Возможно, для этого потребуется адаптировать дизайн и добавить среды Lakehouse и Spark.

1

Отображение Data Flow на Microsoft Fabric (https://oreil.ly/x2uE3) — конвертор для Azure
Data Factory, преобразующий потоки данных ADF в код Spark.

  

248

Глава 7. Строим золотой уровень

Рис. 7.8. Dataflow Gen2 — сервис самообслуживания, позволяющий преобразовывать данные
с минимальным объемом кода

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

  

Проектирование золотого уровня

249

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

Microsoft Fabric на практике
Мы завершаем работу с учебным примером Oceanic Airlines, где использовали
Microsoft Fabric для разработки уровней медальона. Мы обсудили возможности
этой технологии для управления крупномасштабными операциями с данными.
Стоит заметить, что Microsoft Fabric не ограничивается простой поддержкой
доменов, рабочих пространств и озер-хранилищ. Технология включает Copilot,
инструменты ИИ, базы данных временных рядов KQL (https://oreil.ly/qXzEs), базы
данных SQL (https://oreil.ly/z1tFd), аналитику в реальном времени, потоки событий, машинное обучение и интеграцию с Microsoft Purview, и все это в одной
модели SaaS.
Этот интегрированный подход с простым рабочим процессом снижает барьер
входа для новичков. Однако и возможности настройки у него ограниченны.
Организациям с очень специфическими требованиями или требующим более
высокой детализации контроля над операциями с данными может показаться,
что принятая в Microsoft Fabric модель «все в одном» сильно ограничивает их
свободу действий. Кроме того, Microsoft Fabric — платформа относительно
новая, и в ней не хватает некоторых возможностей. Вы должны учитывать отличия между платформами, чтобы понять, как они поддерживают различные
сценарии и почему на рынке находится место как для индивидуальных, так
и для гибридных решений.
От функциональности Microsoft Fabric по созданию архитектур данных логично
перейти к концепции продуктов данных, которые могут использоваться с этими
архитектурами. Продукты данных, по сути, представляют собой «строительные
блоки», пригодные для многократного использования; они проектируются как
масштабируемые, простые в использовании и полезные в разных контекстах
в пределах организации. Они играют ключевую роль для получения информации,
направляющей бизнес-решения и бизнес-операции.
В архитектурах медальона продукты данных — это базовый компонент. Они
часто размещаются на золотом уровне, где уточняются и оптимизируются для
потребления конечными пользователями или последующими приложениями.
Погрузимся немного глубже в концепцию продуктов данных и исследуем лучшие
практики проектирования и управлении ими на золотом уровне.

  

250

Глава 7. Строим золотой уровень

Продукты данных
В разделе «Данные серебряного уровня как продукт» главы 6, с. 217, была представлена концепция продуктов данных (data products). В нем подчеркивалась их
важность как ценных активов, требующих тщательного управления и внимания.
В архитектуре медальона золотой уровень играет особую роль в определении
и создании продуктов данных. На этом уровне появляются данные, предназначенные для прямого потребления конечными пользователями и приложениями,
то есть готовые для бизнеса.
В отрасли не существует единого стандарта продуктов данных на все случаи
жизни, поэтому также не существует универсальной таксономии, стандарта
метаданных или стандарта совместимости. Путаница усугубляется тем, что
многие точки зрения оказываются слишком концептуальными и теоретическими. Например, ведутся непрекращающиеся споры относительно того,
должны ли продукты данных включать метаданные, код обработки и поддерживающую инфраструктуру.
Мой совет: разработайте собственные стандарты с рекомендациями. Не ждите
других; возьмите инициативу в свои руки и создайте стандарт, подходящий
для вашей организации. Это гарантирует однозначность и последовательность
в работе ваших команд.

Организации по-разному подходят к оценке и проектированию продуктов данных
на золотом уровне. Малые организации обычно концентрируются на получении
аналитической информации о доступных для потребления данных. Эти данные
часто интегрируются в более широкую архитектуру озер-хранилищ без четкого
отделения данных, специфических для сценариев использования, от собственно
продуктов данных. Затем в каталоге данных просто перечисляются все доступные
данные, помеченные как готовые для потребления.
Более крупные организации обычно принимают другую стратегию. Они устанавливают стандарты для отделения данных, специфичных для конкретных сценариев использования, от данных, предназначенных для более широкого потребления.
Они могут создавать специальные дополнительные уровни на золотом уровне,
четко помечать продукты данных в каталоге или сохранять их в отдельном озерехранилище. Другая тактика — виртуализация данных, позволяющая создавать
виртуальные уровни с использованием представлений или ссылок (shortcuts)
без физического копирования. Эти практики будут рассматриваться в главе 11,
в разделе «Отдельные уровни продуктов данных», с. 331.
Какой бы подход вы ни выбрали, наличие внятных рекомендаций исключительно
важно для эффективной разработки и управления продуктами данных. Когда
команды данных работают независимо и без общего руководства, они часто
создают данные с несколько различающимися и несовместимыми моделями.
Иногда они производят данные, слишком заточенные на конкретные сценарии
использования. Это усложняет использование данных, особенно многократное,

  

Продукты данных

251

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

Таблица 7.1. Примеры представлений продуктов данных
Сценарий

Пригодность

Лучшая практика или факторы проектирования

Сырые системные данные
на бронзовом уровне

Не подходит

Создает жесткую связанность; обработайте данные на
серебряном уровне для сокращения зависимостей

Таблица Delta на золотом
уровне

Оптимально

Проектируется как датасет, пригодный для многократного использования (например, «одна большая таблица»)
для эффективного и гибкого доступа к данным

Несколько таблиц Delta
в размерной модели на
золотом уровне

Идеально

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

Отчет

На пределе

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

ИИ-модель

На пределе

Модели плохо обобщаются. Вместо них следует передавать данные, на основе которых они строились

Семантическая модель

Оптимально

Разрабатывается для широкого применения и многократного использования

Топик Kafka или Event Hub

Подходит

Используйте события, передающие состояние. Проследите за возможностью многократного использования
и совместимостью

Папка с PDF-файлами

Не подходит

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

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

  

252

Глава 7. Строим золотой уровень

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

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

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

Моделирование данных
Для обеспечения согласованности, надежности и удобства использования данных в пределах организации важно установить четкие стандарты моделирования
данных. Подумайте о принятии следующих мер:
Руководствуйтесь лучшими практиками в отношении гранулярности, референсных данных, типов данных, подробностей схемы, ключей и классификации.
Требуйте использования атомарных данных, которые позволяют правильно
связывать элементы данных с бизнес-понятиями в каталоге.
Эффективно выполняйте объединение данных. Так, код SKU в полях системы
продаж можно сформировать из полей системы складского учета конкатенацией Category_Code (например, ELC для электроники) и Product_ID (например,
00123); будет получен SKU вида ELC-00123.
Дайте рекомендации по управлению ключами внутри и между системами,
чтобы упростить интеграцию между доменами.

  

Продукты данных

253

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

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

  

254

Глава 7. Строим золотой уровень

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

Управление данными с помощью Microsoft Purview
Microsoft Purview (https://oreil.ly/jMSvv) предоставляет различные функции для
эффективного управления и мониторинга данных, а также улучшает видимость
и расширяет контроль по всему жизненному циклу данных. Для управления данными платформа предоставляет Microsoft Purview Unified Catalog (https://oreil.
ly/WMBZ_) с такими возможностями, как отслеживание происхождения данных,
продукты данных, критические элементы данных, цели и ключевые результаты
(OKR) и метрики качества данных. Все это помогает организациям контролировать свои данные с различных точек зрения.

Неоднозначное понятие «домен»
Концепция доменов, или предметных областей, стала популярной благодаря предметно-ориентированному проектированию, или DDD (DomainDriven Design), — методологии, предназначенной для сложных систем
в крупных организациях. Этот подход значительно повлиял на современные стратегии разработки программных продуктов, включая микросервисы и сетки данных.
В области DDD домены (предметные области) определяются как конкретные пространства задач, решением которых намерена заняться организация. Домены включают знания, поведение, законы и действия
и характеризуются семантической связанностью, включая организационные или поведенческие зависимости между командами, системами или
сервисами. Для упрощения управления и улучшения ясности домены
часто сегментируются на субдомены, соответствующие разным организационным аспектам.
Использование термина «домен», однако, может привести к неоднозначности из-за различий в интерпретациях. Например, «бизнес-домен»
может относиться к основной деятельности компании, ее приоритетам,

  

Управление данными с помощью Microsoft Purview

255

приложениям и данным. С другой стороны, «домен управления данными» может включать такие аспекты, как управление данными, владение
данными, а также каталогизация продуктов данных и важнейших бизнес-концепций (например, глоссарий). Точно так же «домен данных»
может быть ориентирован на границы, в которых те или иные данные
собираются, обрабатываются, гармонизируются и распределяются, тогда
как «технический домен» или «прикладной домен» может быть сосредоточен на технологии и приложениях, поддерживающих конкретные
бизнес-функции.
Несмотря на популярность DDD, я сдержанно отношусь к его применению в средах сеток данных (data mesh), прежде всего из-за его сильной
зависимости от методологий, завязанных на программные решения.
Вместо этого я предлагаю определять границы на основании бизнес-возможностей, что обеспечивает более практичную и эффективную схему
разделения обязанностей и ролей внутри организации. Альтернативный
подход — применение принципов Международного общества по организации знаний (International Society for Knowledge Organization) (https://
oreil.ly/THcAp), предлагающего другой надежный метод четкого определения этих областей.
Важно учитывать, что домены могут пересекаться или сливаться, что
добавляет уровни сложности в управление ими. Например, один бизнесдомен может зависеть от нескольких доменов данных, которые, в свою
очередь, могут зависеть от разных технических доменов. И наоборот, несколько бизнес-доменов могут быть сгруппированы в более крупный домен управления данными. А следовательно, очень важно точно определить
границы каждого домена, чтобы избежать пересечения и предотвратить
непреднамеренные слияния. Такая ясность необходима для поддержания
организационной эффективности и связности.
В Microsoft Purview термин «домен» относится к организации управления данными как на технологическом, так и на бизнес-уровне. Он используется в разных
условиях как граница для группировки метаданных и упрощения задач управления данными, таких как владение данными и их обнаружение. В следующих разделах мы исследуем связь доменов с архитектурой медальона, сосредоточившись
на концепции доменов в Microsoft Purview.

Проектирование с помощью Microsoft Purview
Попробуем поработать с Microsoft Purview. Прежде всего создайте учетную запись
Microsoft Purview1. Затем настройте домены управления (governance domains)
и коллекции (collections). Это начальные шаги для работы с Microsoft Purview,
1

Указания см. в документации (https://oreil.ly/V5RT6).

  

256

Глава 7. Строим золотой уровень

и они важны для эффективного управления продуктами данных и бизнес-концепциями.
Существуют отличные информационные ресурсы, которые помогут вам на
началь­ных этапах. Я рекомендую статьи Get Started with the New Data Governance
Experience in Microsoft Purview (https://oreil.ly/i_kLY) и Set Up Your Governance
Domains (https://oreil.ly/nH-jU) для знакомства с основами организации и управления данными.
Мы с Саратом Сасидхараном (Sarath Sasidharan) ведем на YouTube канал Data
Pancakes (https://oreil.ly/JM2Hf), на котором обсуждаем темы, относящиеся
к данным, в том числе управление данными с помощью Microsoft Purview.

Для Microsoft Purview важны два типа доменов: домены управления и коллекции.
Первые направлены на управление продуктами данных и бизнес-концепциями,
а вторые используются для группировки метаданных при техническом сканировании. В следующих разделах они будут рассмотрены более подробно.

Домены управления
В неструктурированном каталоге данных каждый актив данных отображается
как отдельный блок информации, что усложняет эффективное управление такими ресурсами для владельцев и кураторов данных (data stewards). Поскольку
данные динамичны и растут вместе с организацией, таким кураторам требуются
масштабируемые инструменты для управления растущим количеством активов
данных.
На помощь приходят домены управления. По сути, домен выступает в роли
границы, упрощающей единообразное управление данными в пределах организации. Эти домены проектируются гибкими, позволяя организации устанавливать
границы, которые наилучшим образом соответствуют ее потребностям в данных.
Например, можно создать домен управления специально для бизнес-юнита (например, финансов) или сосредоточиться на конкретной предметной области,
например «данные о клиентах» или «информация о продуктах».
Чтобы увидеть более четкую картину, взгляните на пример доменов управления
(Governance domains) в Microsoft Purview на рис. 7.10. На скриншоте показана информация о владении данными (Owner), продуктах данных (Data products) и таких
бизнес-концепциях, как термины глоссария (Glossary terms), OKRs и критические
элементы данных (Critical data elements).
Домены управления устанавливают четкие границы и дают широкое представление о контекстной информации и технических ресурсах данных. Эти домены
связаны с продуктами данных, и через них — с активами данных, которые упорядочиваются в коллекции.

  

Управление данными с помощью Microsoft Purview

257

Рис. 7.10. Сводная страница Governance Domain в Microsoft Purview

Коллекции
Коллекции управляют информацией (метаданными) о технических доменах
и организуют ее. Здесь также можно назначить конкретные роли, включая администраторов источников данных (data source administrators) и администраторов
коллекций (collection administrators), для наблюдения за управлением этими
активами данных. Эта конфигурация жизненно важна для сканирования и управления метаданными о системах-источниках и приложениях.
На рис. 7.11 вы видите, как структура коллекции организована в Microsoft Purview.
В сводном представлении коллекции можно регистрировать источники данных,
сканы и ресурсы и управлять ими.
На рис. 7.11 в качестве примера представлен проект Oceanic Airlines. Он содержит корневую коллекцию с именем Oceanic Airlines, которая включает общие
сервисы, такие как Microsoft Fabric и Azure Databricks. Размещение этих общих
сервисов на высших уровнях иерархии важно по двум причинам. Во-первых,
несколько регистраций источников данных в одной учетной записи Microsoft
Purview не допускается. Таким образом, каждый уникальный сервис может быть
зарегистрирован в коллекции только один раз. Во-вторых, Microsoft Purview
позволяет распространять метаданные только среди своих дочерних коллекций,
но не одноуровневых. Таким образом, размещение общего сервиса (такого, как
Microsoft Fabric) на верхних уровнях иерархии обеспечивает эффективное распределение метаданных в каталоге.

  

258

Глава 7. Строим золотой уровень

Рис. 7.11. Страница Data Sources (источники данных) в Microsoft Purview
На рисунке вы видите также коллекцию с именем Operational systems. В ней
группируются метаданные из рабочих (операционных) систем, например базы
данных Azure SQL от AdventureWorks. Такое размещение помогает хранить все
взаимосвязанные сервисы вместе. В большой организации могут использоваться
сразу несколько рабочих систем, и для каждой существует своя коллекция.
Наконец, в коллекции Lines of Business группируются метаданные из разных направлений бизнеса в организации, например, бизнес-домен Sales. На скриншоте
она пуста, но это временный заполнитель для совмещения с метаданными, которые будут сканироваться при получении метаданных от платформы (такой, как
Microsoft Fabric).
Что касается сканирования Microsoft Fabric как технического источника метаданных, для нее можно воспользоваться функцией ограниченного сканирования
(scoped scanning). Эта функция позволяет не только выбрать конкретные сущности Workspace для сканирования метаданных, но и решить, в какую коллекцию должны попасть метаданные. Например, метаданные из Fabric Workspaces,

  

Управление данными с помощью Microsoft Purview

259

относящиеся к домену Sales, будут добавлены в коллекцию Sales. На рис. 7.12
показан пример ограниченного сканирования в Microsoft Purview.
После сканирования рабочего пространства метаданные становятся доступными
для пользователей каталога. Эти метаданные содержат технические подробности
о ресурсах данных: пайплайнах, озерах-хранилищах, таблицах, столбцах и т. д. Метаданные могут использоваться для эффективного описания продуктов данных.
Рассмотрим подробнее концепцию продуктов данных и исследуем их отношения
с активами данных в Microsoft Fabric.

Рис. 7.12. Функция ограниченного сканирования Microsoft Purview в действии

  

260

Глава 7. Строим золотой уровень

Интеграция Unity Catalog в Microsoft Purview
Unity Catalog (https://oreil.ly/lkixC) — инструмент управления данными,
предназначенный для управления и обеспечения безопасности данных
в Azure Databricks. Он подробно описан в главе 12. Он работает главным образом с операционными аспектами управления данными в Azure
Databricks, тогда как Microsoft Purview предоставляет более широкую
стратегическую точку зрения на управление данными по всему ландшафту
данных. Если ваша практика управления данными должна охватывать
разные технологии и платформы, Microsoft Purview может быть более
подходящим вариантом.
Однако вы можете интегрировать два каталога, чтобы расширить свои
возможности управления данными. Эта интеграция позволяет обнаруживать данные, получать наглядное представление происхождения
данных из рабочих пространств Azure Databricks и организовывать их
в коллекции в Microsoft Purview. Процесс сканирования весьма прост
и похож на сканирование Microsoft Fabric. Сначала вы регистрируете
Unity Catalog, затем выбираете рабочее пространство (Workspace) Azure
Databricks, которое должно быть сканировано, и наконец, направляете
данные в конкретную коллекцию. Дополнительную информацию о подключении и сканировании см. в документации (https://oreil.ly/s2htd).

Продукты данных Microsoft Purview
После создания структуры коллекций и сканирования метаданных о технических
доменах можно переходить к созданию продуктов данных (https://oreil.ly/bSlpm).
Фактически это означает связывание технических метаданных (структуры коллекции) с бизнес-концепциями (доменами управления). Здесь в игру вступают
продукты данных.
В Microsoft Purview продукты данных представляют собой логические сущности,
которые группируют один или несколько ресурсов данных для конкретной бизнес-цели. Они становятся соединительным звеном между доменами управления
и коллекциями. Они помогают организовать эффективное управление данными
и их распространение, обеспечивая контроль за происхождением данных, качество данных и комплаенс. Представление продукта данных в Microsoft Purview
показано на рис. 7.13.
На рис. 7.13 показан пример продукта данных, принадлежащего конкретному домену, владельцем которого является сотрудник организации. Также на странице
выводятся показатели работоспособности (Health actions), частота обновления (Update frequency) и активы данных (data assets), используемые для продукта данных.
Кроме того, в зависимости от прав доступа может присутствовать кнопка Request
access, которая позволяет пользователям запросить доступ к продукту данных. Эта

  

Управление данными с помощью Microsoft Purview

261

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

Рис. 7.13. Продукт данных в Microsoft Purview
При проектировании продуктов данных Microsoft Purview на первый план выходит гибкость. В них могут храниться разнообразные элементы, включая таблицы,
файлы, отчеты Power BI и модели машинного обучения. Это означает, что они не
ограничиваются таблицами Delta из озера-хранилища. Продукты данных также
могут классифицироваться по типам: датасеты, операционные продукты, бизнес
системы/приложения и т. д. Кроме того, активы данных могут совместно использоваться разными продуктами данных, что повышает гибкость управления ими.
Хотя эта гибкость полезна, не менее важно установить четкие стандарты для
определения продуктов данных. Как уже говорилось, необходимо определить рекомендации по тому, что понимается под продуктами данных, по их связи с другими

  

262

Глава 7. Строим золотой уровень

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

Рекомендации для архитектуры медальона
Разберемся, как Microsoft Fabric и Microsoft Purview связаны с архитектурой
медальона в отношении управления данными. Начнем с Microsoft Fabric.
Как было показано в главе 5, домен представляет собой способ логической группировки всех данных в организации, относящихся к определенной области. Чтобы
группировать данные в домены, рабочие пространства связываются с доменами.
В этой конфигурации домены делятся на технические и домены данных. При
использовании таких сервисов, как Microsoft Fabric и Microsoft Purview, очень
важно оперировать согласованными определениями доменов, так как их смысл
может изменяться.
В контексте Microsoft Purview понятие «домены управления» (governance domains)
используются для определения границ, инкапсулирующих конкретные бизнесконцепции и активы данных в унифицированной структуре принадлежности.
В Microsoft Purview также вводится концепция коллекций.
Термин «домен» также встречается в интерфейсе коллекций, но в этом контексте
он несет иной смысл. Здесь доменом называется метод организации технических
метаданных при сканировании систем-источников и приложений. Это значение
четко согласуется с концепцией доменов в Microsoft Fabric, но не стоит путать
его с определением домена управления.
Ключевой вопрос: как разные типы доменов в Microsoft Purview и Microsoft Fabric
взаимодействуют с бизнес-доменами в общей архитектуре?
На рис. 7.14 показаны взаимодействия между разными типами бизнес-доменов. Допустим, у вас имеется бизнес-домен Sales (он был частью практического
упражнения). Также существует другой бизнес-домен с именем Airflight Operations
Management (Управление полетами). Этот бизнес-домен обрабатывает свои системы-источники с использованием архитектуры медальона. Наконец, существует
бизнес-домен Consumer Services (Служба поддержки клиентов). В отличие от

  

Управление данными с помощью Microsoft Purview

263

других, он не имеет собственных систем-источников, а использует данные из
доменов Sales и Airflight Operations, интегрируя эти данные в собственную архитектуру медальона. Таким образом, в итоге существуют три архитектуры медальона.

Microsoft Purview
Домены
управления
Коллекции

Airflight Operations
Management

Sales

Прикладной
домен

Домен
данных

Прикладной
домен

Домен
данных

Consumer Services

Домен
данных

Workspace
Compute
SQL
Lakehouse

Lakehouse

Lakehouse

Бизнес-домен Sales

Lakehouse

Workspace

Workspace

Вычисления

Вычисления

Lakehouse

Бизнес-домен Airflight
Operations Management

Lakehouse

Lakehouse

Lakehouse

Lakehouse

Бизнес-домен
Consumer services

Рис. 7.14. Связи между бизнес-доменами, доменами управления и коллекциями в Microsoft Purview,
а также доменами данных и рабочими пространствами Microsoft Fabric (на диаграмме выделен бизнесдомен Sales, управляющий прикладным доменом и доменом данных)
Чтобы обеспечить эффективное управление данными, каждый бизнес-домен будет
приведен в соответствие с собственным доменом управления в Microsoft Purview.
Эти домены показаны в верхней части рис. 7.14. Каждый домен управления курирует управление продуктами данных и бизнес-концепциями. Домен контролирует
данные на протяжении всего жизненного цикла, от операционных систем до продуктов данных.
Уровнем ниже находятся коллекции, которые упорядочивают метаданные об
активах данных. Необходимо поддерживать четкие отношения между коллекциями и доменами управления, чтобы предотвратить возможные пересечения или

  

264

Глава 7. Строим золотой уровень

слияния. В этом дизайне существует разделение между опрационными системами
и аналитическими сервисами. Такое разделение гарантирует, что метаданные об
операционных системах хранятся отдельно от метаданных, описывающих продукты данных, упрощая эффективное управление данными.
Двигаясь ближе к середине и вниз, можно заметить, как коллекции соединены
с системами-источниками и рабочими пространствами Microsoft Fabric. Эта
конфигурация обеспечивает точное связывание метаданных с данными из конкретных частей архитектуры. Эти системы-источники и сущности Workspace
совместно формируют то, что часто называется бизнес-доменом. В таком домене
(например, Sales) данные активно используются и управляются бизнесом.
Однако бизнес-домен Consumer Services — это исключение. В отличие от других,
он не собирает данные от своих систем-источников. Вместо этого он полагается
на данные от бизнес-доменов Airflight Operations Management. Как следствие, он
содержит только домен данных без прикладного домена.
Главный вывод из этой структуры заключается в том, что в нашем примере домены управления осуществляют контроль за всем жизненным циклом данных.
Они управляют как данными в операционных системах, которые называются
прикладными доменами, так и данными, используемыми в аналитике, известными
как домены данных. В работе с ними задействованы горизонтальные команды,
которые занимаются всем — от операционных систем до продуктов данных.
Единственным исключением является домен Consumer Services, не имеющий
собственных систем-источников, но использующий данные из других доменов.
Можно ли подойти к этой архитектуре иначе? Безусловно. Например, можно со­
здать отдельные домены управления для операционных систем и аналитических
сервисов. Такая стратегия позволяет независимо управлять данными от операционных систем и продуктов данных. Такая конфигурация особенно полезна в организациях, где системами-источниками и продуктами данных занимаются разные
команды. Представьте сценарий, когда прикладная команда занимается системамиисточниками, а другая команда инженерии данных — продуктами данных.
Также можно сгруппировать все коллекции, относящиеся к прикладным доменам,
и соединить их с одним или несколькими доменами управления. Такая схема
хорошо сработает, если централизованная IT-группа или более крупная команда
контролирует все системы-источники приложения.
Как это все отражается на архитектуре медальона? Чтобы обеспечить эффективное управление данными, разные уровни архитектуры должны соответствовать
ролям и обязанностям команд или участников команд.
Начните с определения целей для каталога и с разработки подробного плана реализации структуры данных. Этот шаг поможет эффективно организовать домены
и управлять ими одновременно с определением четких критериев гранулярности,
позволяющих избежать путаницы и пересечений. Затем оцените структуру рабочих
пространств, уровней и продуктов данных в архитектуре медальона. Рассмотрите

  

Управление данными с помощью Microsoft Purview

265

важнейшие вопросы, включая следующие: должны ли бронзовый, серебряный
и золотой уровни всегда управляться в одном рабочем пространстве? сочетаются
ли эти рабочие пространства с конкретными коллекциями и доменами управления?
существует ли необходимость в дополнительных уровнях или отдельных рабочих
пространствах, адаптированных для конкретных сценариев использования или бизнес-юнитов? Также проанализируйте, не потребуют ли эти корректировки новых
доменов управления. Подобные размышления помогут сформировать надежную
основу для управления данными. Рассмотрите следующие сценарии:
Децентрализованное управление
Каждый бизнес-домен управляет собственной системой-источником и поддерживает отдельную архитектуру медальона, которая включает несколько
рабочих пространств для разработки, тестирования и эксплуатации. Возможно,
стоит определить отдельные домены управления для каждого бизнес-подразделения или отдела, чтобы обеспечить необходимые соответствия.
Централизованное проектирование с распределенным использованием
Одна архитектура медальона состоит из нескольких рабочих пространств,
в которых размещаются несколько сущностей озер-хранилищ. Например,
всеми задачами загрузки и очистки занимается одна инженерная команда,
тогда как дополнительные рабочие пространства распределяются между
различными командами, выполняющими гармонизацию данных для разных
бизнес-сценариев. В таком сценарии несколько доменов управления могут
быть связаны с одной структурой коллекции(-й).
Централизованное управление
Централизованная IT-команда управляет всеми системами-источниками,
приложениями и интеграцией данных. Здесь можно организовать все коллекции, связанные с прикладными доменами, и связать их с разными доменами
управления.
Гибридный подход
Сценарий объединяет элементы децентрализованного и централизованного
управления. Например, некоторые критически важные домены данных могут управляться централизованно для сохранения контроля над ключевыми
активами данных и комплаенса, тогда как другие, менее важные домены
данных управляются отдельными бизнес-юнитами для повышения гибкости
и отзывчивости.
После рассмотрения этих сценариев можно выбрать структуру, которая лучше
всего соответствует потребностям и рабочим процессам организации, обеспечивая бесшовную и эффективную реализацию архитектуры. Во всех случаях важно
иметь четкие рекомендации для обеспечения согласованности и предотвращения
недоразумений.

  

266

Глава 7. Строим золотой уровень

Важно разработать понятный фреймворк управления данными, соответствующий стратегии данных организации. Для начала определите, кто является
владельцем данных. При этом важно понимать внутренние роли, задействованные в управлении данными. Подумайте, требуется ли вам децентрализованное
управление данными или же наблюдение за критически важными данными
могут осуществлять централизованные команды. Ответы на эти вопросы помогут вам определить фреймворк управления данными и новые требования
для своей архитектуры.
Если вы хотите жестко определить отношения между продуктами данных
и конкретными активами данных в Microsoft Fabric, используйте приложение
Purview-Bulk-Collection-Mover (https://oreil.ly/lZArX). Это маленькое вебприложение позволяет перемещать большие объемы метаданных между коллекциями; это гарантирует, что метаданные в коллекциях будут относиться
к данным одного конкретного уровня архитектуры медальона.

Наконец, продумайте процессы и политики управления доступом, которые необходимо определить, чтобы к данным могли обращаться только авторизованные
пользователи. Например, можно предоставить пустые рабочие пространства со
ссылками на данные, чтобы пользователи могли обращаться к данным через
интерфейсы только для чтения (read-only). Это гарантирует, что пользователи
не смогут обращаться к данным напрямую, а только через ссылки, управляемые
политиками контроля доступа. Подробнее о стратегиях эффективного управления и масштабирования см. в главе 11. Эта глава поможет вам принимать
обоснованные решения, которые улучшают функциональность, эффективность
и безопасность архитектуры.

Заключение
Наше путешествие по архитектуре медальона началось с загрузки данных на
бронзовом уровне, продолжилось на более тщательно очищенном серебряном
уровне и достигло сложного золотого уровня. Главными нашими задачами было
повышение качества данных и производительности и обеспечение соответствия
архитектуры данных бизнес-целям организации.
Золотой уровень играет ключевую роль в эффективном принятии решений
и создании информативных отчетов. Разрабатывая этот уровень, мы стремились,
чтобы данные были точными, легкодоступными и оптимизированными для
высокопроизводительных запросов и аналитики. Также мы освоили создание
отчетов с помощью Power BI и рассмотрели использование Microsoft Purview
для управления данными. Некоторые ключевые выводы этой главы:
Золотой уровень требует реализации сложной бизнес-логики для точного отражения потребностей бизнеса. Он должен обеспечить как значимость, так и доступность моделей данных. В этом контексте расставляйте приоритеты сценариям использования, основываясь на их важности для бизнеса, осущест­вимости

  

Заключение

267

и доступности ресурсов, а также проводите регулярные исследования для
выявления дублирующейся бизнес-логики и централизованного управления.
Во время конструирования отчетов и семантических моделей очень важно
выдержать баланс при извлечении данных из озер-хранилищ. Используйте
режим Import для оптимальной производительности и проведения сложных
вычислений с применением DirectLake или DirectQuery, когда обращаетесь
к данным реального времени. Для прямых запросов используйте заранее определенные представления или применяйте фильтры непосредственно к самим
отчетам. Как вы узнали, у каждого режима есть свои достоинства и недостатки,
так что выбирайте с умом.
Для управления данными тщательно оцените желаемое количество доменов
управления, коллекций и их уровни детализации. Для этого понадобится
фреймворк управления данными, который соответствует дата-стратегии
организации. В нем должны быть описаны роли, процессы поступления и потребления данных, а также ответственность за управление продуктами данных
и бизнес-концепциями.
Разработайте собственный набор стандартов для продуктов данных, так как
в отрасли не существует единых правил. Начните с установления четких
рекомендаций для проектирования продуктов данных. Это поможет поддерживать согласованность и ясность в пределах компании. В частности, ваши
рекомендации должны описывать структурирование данных и обеспечивать
доступность продуктов данных для бизнес-пользователей. Также можно добавить конкретные инструкции, например, optimizeWrite, для включения
V-упорядочения при создании таблиц Delta.
Подумайте о введении разделения между данными для конкретных сценариев
и дата-продуктами путем использования разных рабочих пространств и сущностей озера-хранилища. Как альтернативу для удобного отделения одного от
другого можно использовать каталог данных.
Обозначьте четкие политики контроля доступа, чтобы убедиться, что к чувствительным данным могут получить доступ только авторизованные пользователи. Например, заполняйте пустые рабочие пространства ссылками на
данные. Мы еще раз обратимся к этим темам в четвертой части книги.
Построение золотого уровня — не просто техническая задача; в большей степени это обеспечение стратегического соответствия технологии бизнес-видению
и дата-стратегии.
На этом завершается вторая часть книги, а на золотом уровне завершается со­
здание архитектуры медальона. Мы прошли долгий путь! Начали его с изучения
бронзового уровня и исследования процедур загрузки и подготовки данных
с использованием Data Factory. Затем перешли на серебряный уровень, очищая
данные и управляя процессами в Airflow, одновременно расширяя знания SQL
и PySpark. И наконец, получили навыки работы с золотым уровнем, построив
размерную модель и добавив создание отчетов в Power BI.

  

268

Глава 7. Строим золотой уровень

Мы описали всего один возможный способ проектирования архитектуры медальона. Их может быть множество, в зависимости от конкретных требований
и свойств, которые вы хотите внедрить в архитектуру; эта тема рассматривается
в главе 11.
Напоследок заметим, что в этом упражнении мы создали базовую архитектуру
озер-хранилищ с нуля в упрощенном варианте. Это решение нельзя назвать
готовым к эксплуатации, но оно послужит неплохой отправной точкой. Будем
надеяться, что оно поможет вам лучше понять основные действия, которые необходимо выполнять, и их взаимосвязи. Если вы будете знать, каким рекомендациям следовать, то будете лучше понимать и эффективнее реализовывать эту
архитектуру.
Для этого проекта я выбрал Microsoft Fabric, при этом уделив внимание паттернам
и технологиям, которые могут применяться очень широко. Например, Spark, Delta
Lake и Airflow достаточно гибки и могут интегрироваться с разными средами.
Data Factory и Power BI хорошо известны своей надежностью и обширными возможностями интеграции с другими платформами. Поэтому стратегии и лучшие
практики, которые мы приняли, можно применять на других платформах, например Azure Databricks. По сути, на основе рекомендаций из этой книги архитектуру
медальона можно построить на любой платформе, поддерживающей Spark и Delta.
Интересно, что, прежде чем завершить книгу, мне пришлось пересмотреть примеры бронзового и серебряного уровней. Поскольку я больше не мог пользоваться
некоторыми сервисами, я быстро сменил направление и заменил инструкции
всего за несколько дней. Это подтверждает, насколько важно обеспечить адаптируемость, портируемость и возможность использования открытой архитектуры
в мире стремительно изменяющихся технологий.
Пришло время перенести теорию, изученную в этой части, на практику. В третьей
части книги мы рассмотрим некоторые корпоративные решения и увидим, как
в них реализуется архитектура медальона. Благодаря этому вы сможете применить полученные знания в собственных проектах.

Часть III
Реальные примеры

В этой части мы займемся изучением реальных применений архитектуры медальона на подробных примерах из практики ведущих компаний. Эта часть не
только демонстрирует адаптируемость и эффективность модели медальона в различных отраслях, но и содержит практические наблюдения о масштабировании
этих архитектур. Изучая примеры, вы начнете лучше понимать, как приспособить
архитектуру медальона к своим специфическим бизнес-целям и потребностям.
В последней главе мы сосредоточимся на стратегиях управления и масштабирования нескольких архитектур медальона в пределах одной организации, а также
познакомимся с перспективами развития этой области.
В главе 8 вы увидите, как известный пенсионный фонд AP Pension реализовал
архитектуру медальона для расширения возможностей обработки данных и аналитики. В примере описаны проблемы, с которыми столкнулись проектировщики
из AP Pension, и способы их преодоления путем применения многоуровневой
структуры.
В главе 9 мы обратимся к примеру Amadeus — лидера в области технологических
решений для туристической отрасли. Этот пример показывает, как компания адаптировала архитектуру медальона для огромных объемов данных и оптимизации
своих операций. Мы сосредоточимся на стратегиях интеграции разрозненных
источников данных и обработке данных в реальном времени для оптимизации
пользовательских взаимодействий и операционной эффективности.
В главе 10 вы узнаете, как ZEISS, глобальный лидер в отрасли оптики, использовал архитектуру медальона, чтобы усовершенствовать управление данными
и процессы аналитики. Пример не только раскрывает технические особенности
управления крупномасштабными системами данных, но и позволяет поразмыслить над широким применением интеграции, управления и обмена данными
в глобальных операциях.

ГЛАВА 8

Пример: данные, аналитика
и бизнес-стратегия в AP Pension
В этой главе мы изучим дизайн медальона, используемый в AP Pension (https://appension.dk/en) — известном датском пенсионном фонде. Руководитель платформы

данных Якоб Ренноу Иенсен (Jacob Rønnow Jensen) поделится своим видением
интеграции бизнеса и стратегии данных AP Pension. Он опишет путь компании
к адаптации современной платформы данных на базе Microsoft Fabric. Вы узнаете,
как в AP Pension решались технические проблемы, как защита данных совмещалась с принципами демократизации данных и как оптимизировались текущие
операции и общая эффективность платформы аналитики.
Якоб доступно опишет эволюцию платформ данных, роль озер-хранилищ и управление сложным ландшафтом данных в AP Pension для сохранения конкурентных
преимуществ в финансовом секторе. Начнем со знакомства с компанией и ее
стратегией данных, а затем подробно изучим бронзовый, серебряный и золотой
уровни ее архитектуры медальона.
В ходе этого исследования вы узнаете, как в AP Pension организовано управление
загрузкой данных, метаданными и данными реального времени, а также какой
существует подход к десериализации JSON и обработке чувствительной персональной информации. Якоб поделится своими выводами о процессах CI/CD,
дизайне рабочего пространства и интеграции с Microsoft Purview.
В завершение главы Якоб озвучит рекомендации и наблюдения по поводу изоляции рабочих нагрузок, безопасности и логической изоляции данных, а также
по управлению рабочим пространством и емкостью. Эта глава даст всестороннее
представление о том, как работа с данными в AP Pension позволяет этой компании добиваться коммерческого успеха с Microsoft Fabric в эпоху данных и искусственного интеллекта.
Питхейн Стренгхольт: Якоб, спасибо, что присоединились ко мне. Для начала
давайте познакомимся. Можете рассказать немного о себе, вашей роли и компании, на которую вы работаете?
Якоб Ренноу Иенсен: Спасибо за приглашение, Питхейн. Меня зовут Якоб Ренноу
Иенсен, и я возглавляю команду платформы данных в AP Pension. Наша компания — датский частный пенсионный фонд, история которого насчитывает 105 лет.
Фонд был совместно основан несколькими крупнейшими кооперативами Дании.

Пример: данные, аналитика и бизнес-стратегия в AP Pension  

271

Сегодня мы обслуживаем примерно 400 000 клиентов из многих отраслей, и у
нас работают более 700 человек. Мы остаемся независимыми и придерживаемся
демократических принципов, заложенных при основании. Наша стратегия, ориентированная на клиента, стремится обеспечить высокую прибыль при поддержании
низких затрат, распределении прибылей и долгосрочном инвестировании.
Питхейн Стренгхольт: Вы кратко описали свою бизнес-стратегию. Можете объяснить, как она связана с вашей стратегией данных?
Якоб Ренноу Иенсен: В 2023 году фонд AP Pension запустил новую бизнесстратегию, включавшую разносторонние цифровые подходы, планируемые
к внедрению до 2029 года. Начальный этап, охватывавший 2023 и 2024 годы,
был посвящен сокращению технического долга и созданию основ для будущих
действий. Ключевые инициативы включали новую облачную административную
платформу для обработки данных клиентов и политик, а также современную
платформу аналитики — разработка последней была поручена моей команде.
На «этапе ускорения», запланированном с 2025 по 2027 год, мы начали развертывать новый фундамент и функциональность для пользователей и клиентов.
В контексте этой цифровой стратегии мы сформулировали ряд руководящих
принципов, направленных на клиентоцентричность, автоматизацию, модульность,
переход на облачные технологии, цифровую ответственность, документирование
и расширение совместной работы.
В дополнение к цифровой стратегии у нас существует отдельная стратегия данных. Она описывает концепцию продуктов данных и наше видение качества данных и управления данными в ситуации, когда существует жесткое разграничение
между операционными и аналитическими данными, так как они служат разным
целям, адаптированным для поддержки наших общих целей. Чтобы эффективно
интегрировать эту относительно полную и обширную стратегию данных в наши
повседневные процессы принятия решений в команде платформы данных, мы
сформулировали суть стратегии для аналитических данных в четырех ключевых
утверждениях: первое имеет стратегическую природу, а три других скорее относятся к операционной сфере:
1. Данные должны быть хорошо защищенными, документированными, удобными
для пользователя и соответствовать информационной модели AP Pension.
2. Данные должны перемещаться настолько редко, насколько это возможно, —
но не реже.
3. Следует применять как можно меньше технологий — но не меньше, чем нужно.
4. Общие затраты на владение данными должны быть настолько низкими, насколько это возможно, — но не ниже этого уровня.
Все эти четыре принципа касаются оптимизации операций аналитической платформы данных и расширения предоставляемых сервисов, а также сочетания
с долгосрочными коммерческими и цифровыми целями AP Pension.

  

272

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Питхейн Стренгхольт: Можете ли вы рассказать о том, как эволюционировали
платформы данных AP Pension с учетом долгой истории фонда?
Якоб Ренноу Иенсен: AP Pension, как и многие компании в финансовом секторе, имеет долгую историю управления данными и их анализа. Со временем
требования к данным увеличивались, и мы прошли через несколько слияний
и поглощений; наши данные и IT-ландшафт стали достаточно сложными. Наши
аналитические данные охватывали широкий спектр от клиентских транзакций
и информации политик до инвестиционных, экологических, социальных и распорядительных (ESG) данных и разнообразных эксплуатационных и рыночных
данных. Эти данные обеспечивают поддержку внутреннего анализа, а также составления внутренних и внешних отчетов.
Когда я пришел в компанию в 2023 году, мне досталась целеустремленная и квалифицированная команда, а также фрагментированный ландшафт данных, который
включал как локальные хранилища данных, так и Azure VM, а кроме того, модель
хранилищ данных в специализированных пулах Synapse в Azure. К сожалению,
старые конфигурации плохо совмещались с цифровой стратегией, а более поздние
не обеспечивали необходимой ценности для аналитических команд AP Pension.
К счастью, были запущены инициативы для переработки базовых процессов,
таких как анонимизация и архивирование данных с использованием Databricks.
С 2022 года я участвовал в закрытом тестировании Microsoft Fabric, и мне было
нетрудно показать руководству AP Pension, что функциональность Fabric и планы
разработки Microsoft хорошо сочетаются с нашей цифровой стратегией, существующими инициативами и целью упрощения как архитектуры, так и эксплуатации.
Это сочетание также обещало более эффективную поддержку аналитических
команд AP Pension за счет более своевременных и актуальных данных.
Более того, фонд AP Pension уже начал использовать Power BI, и общая для
Fabric и Power BI модель модель управления ресурсами делает их совместное
использование неплохой инвестицией. С учетом размера компании, объема обрабатываемых данных и высокого уровня регулируемости сектора, в котором
работает фонд, AP Pension требовалась корпоративная платформа данных, способная справиться с автоматизированным и централизованным управлением
данными, безопасностью и курированием данных. С другой стороны, компания
не столь велика и имеет возможность принимать динамичные решения на уровне
предприятия, так как мы работаем только в одном регионе и поддерживаем тесные
связи с нашими пользователями, руководителями, принимающими решения,
и владельцами систем. Таким образом, можно сказать, что мы оказались в оптимальной точке для раннего перехода на Fabric.
Мы перенесли многие из наших облачных рабочих нагрузок на эту современную
платформу, завершение миграции данных запланировано на 2025 год. Мы реализовали фреймворк, основанный на метаданных, централизованное управление
данными, оптимизированную загрузку данных и платформу для непрерывной
разработки. Даже на этой относительно ранней стадии использования Fabric

Пример: данные, аналитика и бизнес-стратегия в AP Pension  

273

мы уже видим серьезные преимущества от перехода на полностью управляемую
платформу данных SaaS и ее интеграции с нашей новой облачной политикой
и системой администрирования.
Питхейн Стренгхольт: Большое спасибо за рассказ! Опишите, пожалуйста, в общих чертах дизайн вашей платформы.
Якоб Ренноу Иенсен: Разумеется. Наша платформа данных, которую я буду
называть «AP Data», построена на архитектуре медальона. Подробная схема
представлена на рис. 8.1.

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

Посадочная
зона
Временное
хранилище

Метаданные

Управление данными на базе Microsoft Purview
Обработка
Загрузка
потоковых
данных с
использованием зеркалирования
Загрузка
копированных данных
с использованием
Data Factory

Инженерия данных
Synapse (Spark)

Обработка

Tables

Tables

Lakehouse
Bronze

Lakehouse
Silver

Сырые
данные
и другие
форматы данных (зашифрованные)

Microsoft Fabric (Workspace)

Инженерия данных
Synapse (Spark)

Очищенные
и стандартизированные форматы файлов

Хранилища
данных
Synapse

Tables

Lakehouse
Gold

Распределение
по другим
доменам

Выделение
Предоставление
ссылок
на другие
домены

OneLake

Оркестрация и наблюдение с использованием Data Factory и аналитики в реальном времени

Отчеты

Data
science

Автоматизация с использованием REST API
Контроль исходного кода и CI/CD с использованием Azure DevOps

Рис. 8.1. Высокоуровневое представление платформы данных AP Platform на базе Microsoft Fabric

  

274

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

В центре дизайна лежит модель Lakehouse. Мы используем REST API, предоставленные Microsoft Fabric для автоматизации наших процессов на основании
надежного уровня метаданных, бесшовно интегрируемого с Microsoft Purview
для управления данными. Для загрузки данных используется зеркалирование
и функциональность Data Factory в Fabric. Data Factory также обеспечивает оркестрацию процессов на платформе данных, но на будущее мы также планируем
реализовать оркестрацию на базе событий с потоками событий и/или Microsoft
Fabric Activator (https://oreil.ly/dn8rI). Этот полнофункциональный дизайн поддерживает нашу цель по оптимизации операций и повышению эффективности
управления данными.
Питхейн Стренгхольт: Почему в своей архитектуре вы в основном концентрируетесь на проектировании сущностей Lakehouse, а не рассматриваете, например,
Warehouse?
Якоб Ренноу Иенсен: Так как Microsoft Fabric предлагает эндпоинты SQL для
доступа ко всем данным в OneLake, на наш выбор озер-хранилищ на базе Spark
вместо хранилищ данных на базе SQL на уровнях архитектуры медальона AP
Data влияет ряд ключевых факторов.
Во-первых, наши данные включают несколько форматов файлов и частые операции со строками данных на уровнях Bronze и Silver. Модель Lakehouse в сочетании
с возможностями распределенных вычислений в Spark идеально подходит для
решения подобных проблем. На это дополнительно влияет появление в Fabric
нового ядра Spark, Microsoft предлагает его без дополнительных затрат; оно повышает производительность для некоторых типов рабочих нагрузок.
Во-вторых, при разработке фреймворков Python и Spark обеспечивают большую
гибкость, чем SQL. Задачи, которые обычно требуют динамического SQL в хранимых процедурах, могут развертываться с использованием функций и классов
и быстро объединяться в пакеты. Более того, мы можем использовать волшебную
команду %%sql в PySpark, чтобы писать код SQL прямо в блокнотах, что позволяет
нам записывать преобразования на SQL и объединять их с традиционным кодом
Python по мере необходимости.
В-третьих, принятие подхода на базе Spark для загрузки и курирования данных
позволило нам запускать процессы параллельно в Databricks и Fabric во время
предварительного периода и на ранних общедоступных этапах Fabric. Это было
чрезвычайно полезно для целей бенчмаркинга и в качестве запасного варианта.
Наконец, данные могут поставляться из Lakehouse непосредственно пользователям через ссылки в сущностях Warehouse в своих рабочих пространствах, снимая
необходимость в физическом перемещении данных.
Благодаря этим преимуществам модель Lakehouse стала центральным компонентом нашей стратегии данных, расширяющим возможности обработки и распределения данных, а также гибкость эксплуатации.

  

Архитектура медальона

275

Питхейн Стренгхольт: Существуют ли условия, в которых вы бы рассмотрели
возможность включения Warehouse в свою архитектуру медальона?
Якоб Ренноу Иенсен: Эти артефакты — как Warehouse, так и Lakehouse — записывают данные в OneLake, а поскольку эндпоинты SQL в Lakehouse в SQL
Warehouse работают на одном ядре, между ними (теоретически) не должно быть
особых различий с точки зрения последующего потребления. Однако Warehouse
в Fabric в настоящее время поддерживает запросы SQL без учета регистра символов, а также мультитабличные транзакции, которые не поддерживаются в Spark.
В сценариях, когда критически важны именно эти функции, я бы рассмотрел
добавление артефакта Warehouse на уровень медальона. Но как видно из высокоуровневой схемы, сегодня сущности Warehouse рассматриваются как более
актуальные для сервисного уровня, на котором многие из наших сценариев использования подразумевают возможность соединения данных и создания новых
таблиц средствами T-SQL.

Архитектура медальона
Питхейн Стренгхольт: Перейдем к конкретным уровням архитектуры медальона
и начнем с бронзового. Как вы управляете данными и как вы опишете компоненты
своей архитектуры?
Якоб Ренноу Иенсен: Конечно, пора поговорить об уровнях архитектуры медальона. Хотя традиционный вариант медальона обычно включает три уровня,
мы дополнительно разделили их на несколько физических уровней, чтобы обес­
печить физическое и логическое разделение задач и конфигурации в AP Data.
Мы назвали подуровни Bronze Landing, PreArchive и Archive.
Основная цель нашего бронзового уровня — отделение данных от систем-источников и управление персональной информацией (PII). Данные сохраняются при
получении их от систем-источников. Управление PII играет исключительно важную роль на этой ранней стадии загрузки. Изначально персональная информация
может присутствовать на уровне Landing, поэтому мы полностью изолировали
его от остальных данных AP Data и провели усечение таблиц при перемещении
данных на уровень PreArchive, в основном предназначенный для вспомогательных
операций. На уровне Archive все данные с персональной информацией шифруются с индивидуальными (но симметричными) ключами для каждого клиента,
делая возможным процесс дешифрования данных там, где для этого существует
веская бизнес-причина. Ключи шифрования размещаются в хранилище ключей
за пределами Fabric и имеют собственные процессы управления данными и жизненного цикла, как показано на рис. 8.2.
Этот тщательно проработанный процесс промежуточного хранения и шифрования гарантирует, что мы будем ответственно обрабатывать PII, при этом сохраняя
исторические данные и критически важную информацию, необходимые нашей
компании для генерирования отчетов и аналитики. Заметим, что если связь между

  

276

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

клиентом и ключом шифрования удаляется из хранилища ключей, это не повлияет на сами аналитические данные. Мы все еще знаем, что клиент существует
в исторических данных, но способность дешифрования PII удаляется; тем самым
мы обеспечиваем анонимность данных и соблюдаем право клиента на забвение1.
Что касается форматов данных, на уровне Landing мы собираем данные из баз данных в форматах CSV, JSON, Parquet, Delta и XML. Затем эти данные перемещаются
на уровень PreArchive и преобразуются в Delta. Уровень Archive служит стабильной
базой, из которой данные могут заново загружаться на предыдущие уровни AP
Data независимо от систем-источников. Такая структура не только защищает чуствительную информацию, но и поддерживает целостность и доступность данных.
Файл,
Файл,
зашифрованный зашифрованный
мастер-ключом мастер-ключом
AP
AP

Системаисточник

Получение мастер-ключа
шифрования базы данных

Проверка доступа RBAC

PII column
encryption

Посадочная
зона

SQL
Шифрование
Получение
каждого столбца или вставка Хранилище
с персональной
ключей SQL
ключа
информацией CPR-шифрования
ключом,
принадлежащим
номеру CPR

OneLake

ID

SSN (PII)

EncryptKey

1

110478-2356

A%&/DSGBVAV

2

230896-1145

UIDFSAJHK%&

3

Archive

ID

SSN (PII)

Address

Diagnosis (PII)

Value

1

%&SAGBHJDA

SAGBHIDA &%

MS

10

2

=(/DASHB)K

?)(/DASHB

CFR

145

3

A345678300HA

%%457683 OOHA

PIR

453678

Landing
SSN (PII)

Address

Diagnosis (PII)

Value

110478-2356

Andevej 1

MS

10

230896-1145

Lysvej 56

CFR

145

020756-7748

Givevej 17

PIR

453678

Рис. 8.2. Высокоуровневое представление процесса шифрования AP Pension на бронзовом уровне

1

Хотя процессы, описываемые AP Pension, предназначены для ответственной обработки
персональной информации в соответствии с внутренними стандартами защиты данных,
соблюдение требований законодательства остается прямой обязанностью сотрудника,
ответственного за обеспечение нормативно-правового соответствия, или юридического
отдела организации.

  

Архитектура медальона

277

Питхейн Стренгхольт: Используете ли вы партиционирование данных или таб­
лицы Delta с контролем версий для функции перемещения во времени?
Якоб Ренноу Иенсен: Изначально мы рассматривали возможность использования неограниченных перемещений во времени с таблицами Delta на уровне
Archive. Однако наши тесты показали, что это требует слишком большого
объема хранилища и отрицательно влияет на производительность запросов.
Поэтому мы решили хранить исторические данные с помощью физического
партиционирования таблиц в Archive. Такая стратегия позволяет эффективно
хранить данные с полной историей без риска превышения затрат и снижения
производительности.
Питхейн Стренгхольт: Не напоминает ли такой подход SCD?
Якоб Ренноу Иенсен: Он напоминает SCD в некоторых из наших паттернов
загрузки. Тем не менее наш основной способ обработки обновлений и изменений основан на операциях UPSERT с таблицами Delta. Он гарантирует ведение
полной исторической записи, что позволяет эффективно отследить любой
фрагмент данных до его точки происхождения. Этот метод сочетает эффективность с возможностью сохранения и обращения к историческим данным по
мере необходимости.
Питхейн Стренгхольт: Как вы управляете загрузкой данных из разных источников? У вас есть единый стандартный метод или вы используете индивидуальные
процессы для каждого источника?
Якоб Ренноу Иенсен: Мы разработали гибкий процесс загрузки для разных
типов данных, с которыми мы работаем, например для API, баз данных, неструктурированных файлов, таблиц Delta и полуструктурированных файлов. Процесс
видоизменяется в зависимости от типа источника. Например, базы данных SQL
обычно поддерживают более простые и автоматизированные способы регистрации и загрузки метаданных. С другой стороны, неструктурированные файлы
часто требуют ручного вмешательства, особенно для правильной пометки персональной информации. Независимо от источника все данные сначала попадают
в посадочную зону, а затем безопасно обрабатываются и передаются на уровень
Archive. И хотя это может показаться избыточным перемещением, это гарантирует
согласованность обработки данных и безопасное отделение платформы аналитики от рабочих систем, и все это адаптируется к конкретным характеристикам
разных форматов данных.
Питхейн Стренгхольт: Можете рассказать, как вы работаете с метаданными? Вы
используете для этой цели каталог?
Якоб Ренноу Иенсен: Метаданные исключительно важны для наших операций.
Мы используем метахранилище для управления ими, идентифицируя форматы
и столбцы источников, содержащие конфиденциальную информацию. Эти метаданные жизненно важны для разных процессов, включая деперсонализацию
данных, проверку схем и управление вводом, не укладывающимся в OneLake.

  

278

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Питхейн Стренгхольт: Таким образом, если столбец будет помечен как конфиденциальный или несовместимый, ваша система сможет автоматически определить,
как обработать его в последующих процессах?
Якоб Ренноу Иенсен: Именно. Мы автоматизировали этот процесс и также
реализовали то, что мы называем «жесткими правилами» для управления конкретными именами таблиц или форматов из систем-источников, которые не могут
храниться в Delta. Эти правила встраиваются в метаданные, делая возможным
автоматическое управление на последующих этапах. Такая автоматизация оптимизирует наши процессы обработки данных и обеспечивает согласованность
и проверку соответствия стандартам в этих процессах.
Питхейн Стренгхольт: Проводите ли вы техническую проверку данных на любой
из этих стадий? Если проводите, как вы справляетесь с деструктивными изменениями схем?
Якоб Ренноу Иенсен: Да, мы проводим проверку данных. Но мы допускаем дрейф
схемы на уровне Archive для некоторых типов загрузок. Поддержка дрейфа схемы в OneLake позволяет нам адаптироваться к эволюционирующим структурам
данных без нарушения существующих процессов.
Питхейн Стренгхольт: Генерируются ли при изменениях в схемах уведомления
для ваших команд?
Якоб Ренноу Иенсен: Изменения в схемах генерируют сигналы, предлагающие
нам проверить и подтвердить изменения. Хотя формат Delta в OneLake способен
справляться с добавлениями новых столбцов, необходимо следить за тем, чтобы
они правильно обрабатывались на последующих уровнях. Активная система уведомлений помогает поддерживать контроль и обеспечивать целостность данных.
Питхейн Стренгхольт: Вы также обрабатываете на бронзовом уровне загрузку
данных в реальном времени?
Якоб Ренноу Иенсен: Сейчас наш основной метод загрузки данных (почти)
в реальном времени базируется на механизме зеркалирования Microsoft Fabric,
который я буду в дальнейшем называть просто зеркалированием. Для Azure SQL
эта функциональность отражает изменения в журналах транзакций системы-источника по аналогии с традиционным CDC для баз данных SQL. Однако в отличие от механизма CDC, который записывает в таблицы базы данных-источника,
зеркалирование ведет запись напрямую в OneLake. Так мы берем лучшее от обеих
технологий при минимизации влияния на исходную базу данных и требований
к обслуживанию приемника. Все это также относится к зеркалированию баз
данных CosmosDB и Snowflake.
Кроме того, зеркалированные данные могут служить новым непосредственным
источником, особенно полезным в тестовых сценариях, а также для наших команд
ИИ и машинного обучения. Пользователи могут обращаться к данным зеркал почти в реальном времени, чтобы имитировать взаимодействия с продакшен-средой.

  

Архитектура медальона

279

Питхейн Стренгхольт: Вы планируете реализовать операционные отчеты для
зеркалированных данных?
Якоб Ренноу Иенсен: Мы поставляем данные из тестовых сред таким образом,
но еще не создали прямые ссылки для зеркалированных данных на серебряном
и золотом уровне нашей рабочей платформы данных. Здесь зеркалированные
данные остаются на бронзовом уровне и рассматриваются как любой другой источник. Мы рассматриваем возможность добавления бизнес-сценария для отчетов
и аналитики почти в реальном времени в не столь отдаленном будущем, но так
как зеркалирование — относительно новая возможность в нашей корпоративной
фабрике данных, мы в первую очередь исследуем его возможности в связи с нашей новой административной платформой, которой они соответствуют почти
идеально. Однако мы также поняли, что в сценариях, когда прямые обращения
к базе данных невозможны, зеркалирование может стать отличной альтернативой. Оно позволит пользователям обращаться с запросами и отслеживать данные
в реальном времени без риска снижения производительности систем-источников.
Питхейн Стренгхольт: Можете ли вы подробнее рассказать о том, как организовано структурирование и управление данными на серебряном уровне?
Якоб Ренноу Иенсен: Серебряный уровень делится на два подуровня: Base
и Enriched. Base является первой точкой AP Data, к которой разрешается доступ пользователям. Заполнение этого подуровня включает такие процессы, как
удаление дубликатов, переименование и десериализация JSON.
Питхейн Стренгхольт: Значит, структура на серебряном уровне близко соответствует исходным системам-источникам, несмотря на отдельные различия?
Якоб Ренноу Иенсен: Да. Иногда приходится корректировать технические имена
из системы-источника, чтобы с ними было удобнее работать, но мы поддерживаем
базовую структуру в синхронизации с источником, чтобы представление данных
оставалось интуитивно понятным для тех, кто знаком с системами-источниками.
Одним из важных исключений является обработка неструктурированных данных,
таких как JSON. Вместо того чтобы хранить отдельные документы, мы храним
JSON в виде строк данных в таблицах Delta на бронзовом уровне. Эндпоинт SQL
в Fabric уже десериализовал корневые элементы JSON в колоночные данные, но
вложенные массивы в JSON так и остаются в формате JSON. Чтобы решить эту
проблему, мы разработали фреймворк автоматической десериализации «остатков
JSON» из вложенных массивов. На рис. 8.3 показано, как этот процесс может
интегрироваться в зеркало Cosmos DB.
Этот процесс, управляемый данными, включает идентификацию вложенных массивов в столбцах JSON таблиц Delta и создание для каждого уровня вложенности
новых таблиц и столбцов, связываемых с ключами на основании порядковой
позиции в исходном документе JSON. Такая итеративная десериализация преобразует все данные в структурированный колоночный формат, более доступный,
удобочитаемый и поддерживающий запросы с точки зрения SQL.

  

280

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Bronze

Silver

Остаточные
данные JSON
Данные из массивов,
хранящихся в JSON

Прямые
ссылки

Cosmos DB

Зеркало
Azure
Cosmos DB

Lakehouse

Рис. 8.3. Высокоуровневое представление процесса десериализации из зеркала Cosmos DB в Fabric
Питхейн Стренгхольт: Судя по описанию, решение получается всеобъемлющим?
Якоб Ренноу Иенсен: Да, но оно добавляет значительную ценность для наших
бизнес-пользователей, а обработка небольшого количества строк данных на
момент загрузки в Spark кажется наиболее эффективной с точек зрения удобства использования, производительности и емкости. Этот механизм позволяет
поддерживать гибкую, но надежную структуру данных для широкого спектра
аналитических и эксплуатационных потребностей. Автоматизируя процессы
десериализации и структурирования, мы обеспечиваем надежность данных и их
согласованность между различными системами и сценариями использования,
что чрезвычайно важно в нашей динамической среде.
Питхейн Стренгхольт: Вы также используете подуровень Base для сохранения
исторических данных из старых унаследованных систем?
Якоб Ренноу Иенсен: Разумеется. Мы храним исторические данные и обеспечиваем соблюдение стандартов GDPR (General Data Protection Regulation) за
счет реализации таких политик, как право на забвение, гарантируя, что сможем
воссоздать старые отчеты и поддерживать исторические серии, важные для предсказаний и анализа (например, исследования долгосрочности).
Питхейн Стренгхольт: Как вы управляете историей данных на серебряном уровне? Например, строите ли вы SCD?
Якоб Ренноу Иенсен: На подуровне Base, где данные все еще организуются в соответствии с системой-источником, мы берем за основу историю на бронзовом

  

Архитектура медальона

281

уровне. Однако на подуровне Enriched серебряного уровня мы начинаем реализацию SCD.
Питхейн Стренгхольт: Обсудим подуровень Enriched. Для чего он нужен?
Якоб Ренноу Иенсен: На подуровне Enriched начинается упрощенное размерное моделирование. Для золотого уровня используются заранее построенные
загрузчики измерений и фактов, требующие данных в конкретном формате. На
подуровне Enriched мы осуществляем подготовку данных для нашего фреймворка
и промежуточное сохранение данных, которые будут использоваться для разных
целей в последующих процессах, снова стараясь минимизировать необходимость
в избыточных вычислениях и управлении данными.
Питхейн Стренгхольт: Можете объяснить, как работают функции-загрузчики?
Якоб Ренноу Иенсен: Конечно. Сначала загрузчики выполняют важнейшие
вспомогательные задачи, например вычисление хеш-ключей для выявления
изменений в исходных данных. Так как мы не можем напрямую хранить первичные ключи в данных Delta, такие загрузчики также обеспечивают целостность данных за счет проверки дубликатов. Суррогатные ключи вычисляются
хешированием соответствующих бизнес-ключей — это позволяет эффективно
и одновременно загружать данные для фактов и измерений. Этот подход также
упрощает обработку мастер-данных, поступающих позднее, и гарантирует,
что данные будут быстро доступны и согласованы со всеми частями модели
данных.
Питхейн Стренгхольт: На стадии Enriched данные все еще ориентированы на
источник?
Якоб Ренноу Иенсен: На уровне Enriched происходит слияние данных от разных
систем-источников. В частности, при этом решаются такие задачи, как выравнивание несовпадающих таймлайнов от разных источников, часто приводящих
к проблемам вроде «островных разрывов», когда приходится находить и исправлять пропуски в последовательностях (разрывы) или находить и сворачивать
диапазоны последовательных идентичных значений (острова).
Питхейн Стренгхольт: Звучит разумно. Поговорим о золотом уровне. Чем он
отличается от предыдущих?
Якоб Ренноу Иенсен: Золотой уровень делится на три подуровня: Curated,
Modeled и Modeled PII. На уровне Curated реализуется общая размерная модель
организации. Это основная стадия обработки, где происходит создание суррогатных ключей, о которых шла речь ранее, и обеспечивается полная интеграция
между разными элементами размерной модели. Этот механизм в значительной
мере управляется метаданными и концентрируется на преобразовании системноориентированных данных с серебряного уровня в единую версию истины.
Питхейн Стренгхольт: Означает ли это, что вы несете ответственность за информационную модель и MDM?

  

282

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Якоб Ренноу Иенсен: Моя команда не отвечает напрямую за информационную
модель или MDM. Тем не менее мы участвуем в совместных обсуждениях задач
в этой области, чтобы синхронизировать рабочие процессы. В этих обсуждениях,
направленных на то, чтобы наши реализации эффективно удовлетворяли потребности организации, ведущую роль играют команды бизнес-аналитики и архитектуры AP Pension. Как часть нашей стратегии данных мы выбрали мастер-систему
для каждого домена данных, которая будет отвечать за мастер-данные. Но поскольку мы только приступаем к реализации второго этапа стратегии, начиная
закладывать новый фундамент, и у нас все еще остается много унаследованных
систем и данных, необходима некоторая форма MDM на платформе аналитики,
чтобы обеспечить общее понимание и надежный фундамент для аналитики и отчетов.
Питхейн Стренгхольт: Фактически вы говорите о согласованных измерениях;
таким образом, могу ли я сделать вывод, что уровень Curated главным образом
использует схему «звезда»?
Якоб Ренноу Иенсен: Да, уровень Curated использует исключительно схему
«звезда», встраивая измерения в SCD. До перехода на Fabric мы использовали модель Data Vault с PIT-таблицами для управления множественными таймлайнами,
что особенно полезно для данных о пенсиях. Например, выплаты, относящиеся
к прошедшей дате, могут повлиять на исторический статус клиента. Поэтому
более опытные пользователи должны уметь создавать отчеты по нескольким
таймлайнам: дате создания, дате регистрации значения или дате принятия транз­
акции. PIT-таблицы были реализованы для управления этими таймлайнами, но
модель Data Vault сама по себе была слишком сложной для большинства бизнеспользователей.
В нашей новой схеме в дизайн внедрена концепция PIT-таблиц для управления несколькими измерениями SCD2 на уровне Curated. Кто-то возразит, что
наш метод является гибридным SCD типа 7, где мы сохраняем ключи типа 1
для факта и допускаем множественные ключи типа 2 в PIT-таблицах. Это
позволяет раздельно отслеживать несколько таймлайнов на уровне Modeled,
благодаря чему обработка данных остается управляемой, интуитивно понятной
и эффективной. На рис. 8.4 и 8.5 представлены примеры обработки данных на
уровне Curated.
Питхейн Стренгхольт: А что происходит на уровне Modeled, следующим за
Curated?
Якоб Ренноу Иенсен: На уровне Modeled мы готовим данные непосредственно
для потребителей данных. Здесь устанавливаются одиночные размерные отношения между фактами и измерениями с использованием соответствующих
ключей истории из таблиц PIT. Такой подход помогает создавать понятные пути
соединений и упрощает модель данных для пользователей. Мы также готовим
данные для семантических моделей и для потребления приложениями, которые,
как и Power BI, требуют одного ключа для соединения таблиц.

  

Архитектура медальона

283

Рис. 8.4. Обработка таблиц измерений на уровне Curated

Рис. 8.5. Обработка таблицы фактов на уровне Curated
Кроме того, данные распределяются по денормализованным таблицам тогда,
когда это лучше соответствует потребностям пользователя. Часто такие заранее
соединенные таблицы удобнее для дополнительной обработки данных и экспериментов аналитиков, у которых инструменты обычно оптимизируются для
такого типа ввода. Такой формат также может реализоваться с использованием
представлений или семантических моделей, поэтому мы формируем оценку для
каждого конкретного случая, руководствуясь производительностью и практичностью при выборе наилучшего варианта.
Питхейн Стренгхольт: Выходит, на уровне Modeled используются разные таблицы
для разных сценариев использования и таймлайнов в зависимости от конкретных
потребностей?
Якоб Ренноу Иенсен: Именно. Мы скорее позволяем пользователям работать
с данными с уровня Modeled, чем с уровня Curated, потому что Modeled представляет «единую версию истины» с точки зрения пользователя и для целей запросов.
Питхейн Стренгхольт: Получается, у вас есть несколько версий истины для
разных запросов?

  

284

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Якоб Ренноу Иенсен: Я бы сказал, что скорее один и тот же вопрос всегда должен
приводить к одному и тому же ответу. Однако разные сценарии использования
и вопросы могут требовать рассмотрения данных с разных точек зрения. Эти
разные перспективы встраиваются в уровень Modeled.
Питхейн Стренгхольт: По сути, это представления или семантические модели,
построенные поверх данных?
Якоб Ренноу Иенсен: Да, уровень Modeled может включать как физические, так
и семантические модели или может быть объединенным представлением, которое
сочетает прямые ссылки с хранимыми данными. Желательно строить их поверх
размерной модели на уровне Curated. Однако для очень простых, автономных
сценариев использования это может быть представление, основанное на ссылках,
ведущих к данным на уровне Base. Такой подход может использоваться в сценариях зеркалирования наподобие тех, которые были описаны выше, где требуются
данные почти в реальном времени.
Питхейн Стренгхольт: Итак, можно ли заключить, что уровень Modeled использует схему «звезда», если только не существует специального запроса на одну
большую таблицу?
Якоб Ренноу Иенсен: Да. Схема «звезда» — наша стандартная структура, потому
что она эффективно поддерживает широкий диапазон аналитических потребностей. Тем не менее для конкретных сценариев (data science, быстрая доставка
или уникальные данные, которые не используются в других местах) мы можем
выбрать более простое, возможно временное, решение, как, например, денормализованные таблицы.
Питхейн Стренгхольт: И наконец, могли бы вы пояснить назначение уровня
Modeled PII?
Якоб Ренноу Иенсен: Уровень Modeled PII служит для ответственной обработки чувствительной персональной информации. Как я уже говорил, все данные
в AP Data анонимизируются или снабжаются псевдонимами, и каждому клиенту
назначаются уникальные ключи интеграции. Это гарантирует, что в AP Data не
будет храниться персональная информация. Такая конфигурация не только защищает данные, но и обеспечивает соблюдение стандартов GDPR. Тем не менее
могут существовать обоснованные бизнес-потребности, требующие доступа
к персональной информации, и на этот случай у нас имеются жесткие процессы
для безопасного дешифрования данных и предоставления доступа к ним в управляемой среде. Таким образом гарантируется минимальное раскрытие информации
и максимальная безопасность.
В AP Pension мы помечаем эти данные в Microsoft Purview, так что защита от потери
данных может обеспечиваться политиками данных и возможностью регистрации
и оповещений об обращениях к дешифрованным данным. По сути, метод основан
на принципе минимизации данных, и это решение гораздо лучше предоставления
бизнес-пользователям доступа ко всем дешифрованным данным перед выбором.

  

Архитектура медальона

285

Мы как компания сначала проверяем, какие отдельные пользователи данных или
группы имеют обоснованные причины для дешифрования, и только после этого
продолжаем процесс. Контроль и документация играют в нем ключевую роль.
Питхейн Стренгхольт: Мой коллега Джеймс Серра часто упоминает уровень
Serving (сервисный) — физический уровень, использующий технологии, отличные от типичных озер-хранилищ или хранилищ данных. Есть ли нечто подобное
в AP Pension?
Якоб Ренноу Иенсен: Определенно. В AP Pension наш уровень Serving состоит
из индивидуальных рабочих пространств каждой логической группы клиентов.
На рис. 8.6 представлена концептуальная схема поставки нашим внутренним
клиентам данных для потребления с уровней Base и Curated/Modeled.
Рабочее пространство APData Function всегда включает как минимум одну сущность Fabric Lakehouse и одну сущность Fabric Warehouse. В такой конфигурации
пользователи являются зрителями для Workspace и владельцами Warehouse.
Ссылки на данные уровней медальона размещаются в Lakehouse. Хранилище
Warehouse изначально пусто, но из него пользователи могут бесшовно запрашивать данные, доступные по ссылкам в Lakehouse в том же рабочем пространстве,
и сохранять данные в Warehouse. Такая конфигурация дает команде платформы
данных полный контроль за распределением данных, одновременно разрешая
пользователям Workspace читать и записывать таблицы в OneLake средствами
SQL — либо в графическом интерфейсе Fabric, либо в таких инструментах, как
SQL Server Management Studio.
Питхейн Стренгхольт: Говоря о дизайне рабочих пространств, как вы принимаете
решение о том, когда создавать новые элементы Workspace?
Якоб Ренноу Иенсен: Мы основываем решение о создании новых отдельных
Workspace на нескольких ключевых факторах: функциональных ролях, безо­
пасности, логической группировке данных и изоляции рабочих нагрузок. Для
поддержки сущностей Workspace, артефактов и ссылок используется автоматизированный и хорошо документированный процесс. Так как данные физически не
перемещаются на сервисный уровень, мы достигаем низкой задержки и быстрого
выхода на рынок, распространяя существующие продукты данных без лишних
затрат на хранение. Такой подход обеспечивает высокую целостность данных,
безопасность и максимальную гибкость для пользователя.
Питхейн Стренгхольт: Можете подробнее рассказать о необходимости изоляции
рабочих нагрузок?
Якоб Ренноу Иенсен: Разумеется. В Fabric ресурсы совместно используются
разными типами вычислений в емкости. Емкости назначаются на уровне рабочих пространств, а значит, потребуется всеобъемлющая стратегия рабочих
пространств, которая обеспечит каждому процессу и каждому пользователю доступ к необходимым вычислительным ресурсам без риска блокирования других
пользователей той же емкости.

  

286

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

Workspace:
Безопасность:
• уровень Workspace

APData [function]

Безопасность:
• эндпоинт SQL
• семантическая модель

Workspace:

Workspace:

Workspace:

Workspace:

Workspace:

Landing

Archive

Base

Enriched

Curated/
modeled

Назначение:

Назначение:

Назначение:

Назначение:

APData

APData

Назначение:

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

данные систем,
отделенные
от источников

Доступ:

дата-нженеры

дата-нженеры

Содержит:

данные от
систем-источников,
усеченные после
загрузки в архив

Доступ:

Содержит:

анонимизированные
данные в том виде,
в каком они были
получены от
систем-источников

APData

очищенные
данные систем

Доступ:

дата-нженеры
и пользователи SQL
со знанием системисточников (через
ссылки)

Содержит:

анонимизированные
и очищенные
данные в том виде,
в каком они были
получены от
систем-источников

APData

APData

консолидация
единая версия истины
данных от нескольких
Доступ:
систем-иcточников
для использования
дата-инженеры
на уровнях Curated
и пользователи
и Modeled
с соответствующими
бизнес-потребностями
Доступ:
(через ссылки)
дата-нженеры

Содержит:

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

Содержит:

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

Рис. 8.6. AP Pension создает рабочие пространства для конкретных доменов
Например, какие-то рабочие пространства могут быть спроектированы для интенсивных нагрузок, которые возникают ежемесячно и, следовательно, требуют
управления емкостями, отличного от того, что практикуется ежедневно для ad hoc
запросов. Для первых параметр времени может быть более критичным, чем для
вторых, и по этой причине мы управляем емкостями по-разному. Чтобы управление было эффективным, мы выбрали описанную модель, решили тщательно
отслеживать использование емкостей, реализовать защиту от выбросов и создавать сущности Workspace на основании метаданных и шаблонов, что помогает
поддерживать порядок и эффективность.

  

Прочие соображения

287

Питхейн Стренгхольт: Итак, домен AP Data осуществляет полное управление
до уровней Curated и Modeled с дополнительными граничными рабочими пространствами для специфических бизнес-ориентированных рабочих нагрузок
и пользователей?
Якоб Ренноу Иенсен: Все верно.

Прочие соображения
Питхейн Стренгхольт: Некоторые крупные клиенты рассматривают возможность
смещения загрузки и других операций управления данными к другим доменам
как часть подхода «сетка данных» (data mesh). Вы тоже рассматривали такую
возможность?
Якоб Ренноу Иенсен: Определенно. Но в то же время я рад, что компания
Microsoft назвала свой продукт «Fabric» (ткань) а не «Mesh» (сетка), хотя такой
вариант тоже рассматривался. «Ткань» ориентирована на автоматизацию процессов, тогда как сетка данных часто подразумевает более децентрализованный
подход, при котором ответственность за управление данными и комплаенс смещаются на периферию.
Мы делим пользователей на созидателей (cocreators), опытных пользователей
и пользователей отчетов, при этом каждая категория имеет свои потребности
в отношении взаимодействия данных. Созидатели — эксперты предметной области, которые могут разрабатывать продукты данных как рабочие прототипы.
В этом отношении Microsoft Fabric предлагает более широкий диапазон вариантов
разработки, от блокнотов Spark и написания кода SQL, о чем мы уже говорили,
до вариантов low-code или no-code как Data Wrangler, Data Factory и Dataflow.
Доступные инструменты low-code и no-code в Fabric могут быть очень полезными
для разработчиков и помочь таким организациям, как AP Pension, в децентрализованном создании новых продуктов данных. Однако с точки зрения производительности и емкости они часто создают лишние затраты по сравнению с настроенными
решениями Spark, работающими в кластере с подходящим масштабом.
Так как емкости используются совместно, вполне логично, что эти прототипы
в дальнейшем уточняются и интегрируются инженерами в платформу данных.
Это помогает выдержать баланс между автономией и контролем, обеспечивая
целостность данных, производительность и безопасность в пределах платформы.
Питхейн Стренгхольт: Похоже, рабочие прототипы продуктов данных являются
ключевой целью вашей конфигурации. По сути, это ваша разновидность сетки
данных?
Якоб Ренноу Иенсен: Можно рассматривать наш метод как сетку данных, но он
не настолько жесткий. Мы сосредоточились на создании рабочих прототипов,
которые могут эволюционировать в проработанные продукты данных. Такой

  

288

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

подход помогает одновременно использовать уникальный опыт экспертов предметной области, команды платформ данных и созидателей.
Питхейн Стренгхольт: С учетом высокой регулируемости финансового сектора
важно поддерживать определенный уровень зрелости и соблюдать стандарты
и лучшие практики, не так ли?
Якоб Ренноу Иенсен: Безусловно, и именно поэтому мы реализовали конфиденциальность на уровне дизайна и обеспечили централизованное создание наших
центральных продуктов данных и управление ими. Мы хотим освободить пользователей от забот о соблюдении GDPR, размерного моделирования, CI/CD, стандартных соглашений об именовании или стандартах оформления кода. Устраняя
эти сложности, мы сокращаем риск и позволяем пользователям сосредоточиться
на том, в чем они сильны: извлечении бизнес-ценности с использованием данных.
Питхейн Стренгхольт: Я рад, что вы упомянули о CI/CD. В Microsoft Fabric
существуют разные способы. Применяются либо пайплайны развертывания
для продвижения артефактов по рабочим пространствам, либо самостоятельные
реализации CI/CD с использованием Git или Fabric REST API. Какой вариант
используете вы?
Якоб Ренноу Иенсен: Для управления данными в AP Data, а также артефактами
и ссылками мы приняли метод, основанный на метаданных. Он включает пайп­
лайн, генерирующий скрипт на основании зарегистрированных метаданных
для каждой среды, который затем вызывает административные Fabric API. Для
создания таких пайплайнов мы используем Azure DevOps. На текущей стадии
Azure DevOps является более зрелым продуктом, чем пайплайны в Fabric, и это
позволяет нам управлять как элементами Fabric, так и элементами, к Fabric не
принадлежащими. Реализованный метод предоставляет необходимую степень
контроля и эффективно заполняет пробел между традиционными решениями
«инфраструктура как код» и новыми, более гибкими SaaS-решениями наподобие
Microsoft Fabric.
Питхейн Стренгхольт: Звучит почти как «конфигурация как код»!
Якоб Ренноу Иенсен: Да, и полный контроль над процессом развертывания
очень важен. Наша текущая конфигурация служит минимально жизнеспособным
продуктом (MVP) для чувствительного процесса развертывания. Она включает
контроль источников и автоматизированное перемещение между средами. Хотя
на данный момент она еще не является полностью непрерывной, она допускает
столько развертываний, сколько потребуется. Так как сейчас у Microsoft появился
Terraform Provider для Microsoft Fabric (https://oreil.ly/OGtxB), мы надеемся использовать эту функциональность для дальнейшей профессионализации и автоматизации нашего процесса.
Питхейн Стренгхольт: У вас есть что-то вроде контрактов данных, раз вы используете автоматическое развертывание рабочих пространств на базе метаданных
или шаблона?

  

Прочие соображения

289

Якоб Ренноу Иенсен: У нас есть внутренние стандарты относительно того,
когда одобряется качество данных, но не фактические контракты данных. Одна
из главных причин для существования единой платформы данных — управление данными и процессами в одном инструменте, в нашем случае это Microsoft
Purview (рис. 8.1). В соответствии с этими стремлениями метрики качества данных должны храниться в Purview вместе с каталогом данных. Похоже, контракты данных находятся где-то в серой зоне между каталогом данных и качеством
данных. Мы хотим, чтобы пользователь знал, являются ли данные, к которым он
обращается, актуальными и действительными, однако определение этих правил
зависит от каждого объекта данных. Это то, над чем мы работаем в Purview, начиная с центральных и критически важных продуктов данных.
Питхейн Стренгхольт: Можете ли вы больше рассказать о том, как вы используете
Microsoft Purview?
Якоб Ренноу Иенсен: В AP Pension мы используем Microsoft Purview для управления и поддержания классификаций данных как для структурированных, так
и для неструктурированных данных, и здесь нам сильно помогает автоматическая
интеграция между Microsoft Fabric и Microsoft Purview.
Изначально мы работали над каталогом данных, который бы позволял пользователям видеть описания доступных данных и их происхождение без прямой помощи
от команды инженеров или обращения к данным/коду. Затем мы сосредоточились
на классификации данных, в первую очередь PII, и настройке защиты от потери
данных — с помощью политик данных и разрешений уровня Entra ID. Эти политики и разрешения гарантируют, что только авторизованные пользователи
смогут обращаться к чувствительным данным на уровне Modeled PII.
Наша цель — также документирование и повышение качества данных за пределами базовых метрик, с которыми мы работаем сегодня. Если вы хотите сделать
качество данных актуальным для бизнес-пользователей, традиционных метрик
(таких, как диапазоны и количество null) недостаточно. Нас также интересовали
значительные изменения или аномалии в паттернах данных. Мы начали с подхода, основанного на правилах, и рассматривали возможность встраивания ИИ
для обнаружения аномалий или рисков во время того, как Purview сканирует
наши данные. Такой проактивный подход к выявлению потенциальных проблем
я считаю значительным достижением в ходе эволюции Purview и Fabric.
Питхейн Стренгхольт: Приняли ли вы концепцию продуктов данных и как вы
решаете, с каким уровнем архитектуры медальона должны связываться эти продукты данных?
Якоб Ренноу Иенсен: Да, мы интегрируем концепцию продуктов данных непосредственно в управление метаданными, уделяя ей внимание на ранней стадии
процесса (вместо того, чтобы потом встраивать в готовую систему). Такой подход
сочетается с концепцией продуктов данных, предлагаемой Purview. Нам показалось избыточным управлять этой информацией как в метаданных, так и в Purview;

  

290

Глава 8. Пример: данные, аналитика и бизнес-стратегия в AP Pension

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

Заключительные рекомендации
Питхейн Стренгхольт: Можете ли вы что-то порекомендовать читателям этой
книги?
Якоб Ренноу Иенсен: Безусловно. Мои главные рекомендации для любого
нового проекта платформы данных: определить стратегию данных, которая сочетается с бизнес-стратегией, и заручиться поддержкой со стороны руководства,
IT и пользователей на самой ранней стадии процесса.
Питхейн Стренгхольт: Исходя из того что вы сказали в этом интервью, абсолютно
логично сосредоточиться на этом.
Якоб Ренноу Иенсен: Да. Если вы помните, я обобщил нашу стратегию данных
в четырех принципах, и тогда она могла показаться тривиальной. Тем не менее
вы видите, что многие из описанных мной тем и решений отсылают к этим принципам. Собственно, я даже рискну утверждать, что выбор Fabric в AP Pension
уходит корнями глубоко к этим принципам и нашей бизнес-стратегии, а также
к принципам и таймлайнам цифровой стратегии.
Питхейн Стренгхольт: Значит, другие могут обойтись и без Fabric?
Якоб Ренноу Иенсен: Я полагаю, что реализация SaaS и разделение вычислений
и хранения в Fabric наряду с такими возможностями, как ссылки, Direct Lake и автоматические эндпоинты SQL в OneLake, действительно важны и определенно
заслуживают того, чтобы изучить их.
Я также полагаю, что важно понимать различия в моделях сервисов SaaS и PaaS
и уметь выбрать тот вариант, который лучше подходит для ваших потребностей
в областях контроля, бизнеса и эксплуатации.
Также учитывайте перспективные планы Microsoft и планы выпуска Fabric.
В этом обсуждении мы даже не затронули Copilot и ИИ-функциональность стека
Microsoft Analytical. Ситуация развивается быстро, и если вы будете держать руку
на пульсе, это поможет управлять ожиданиями и планами на будущее. Возможности безграничны, однако для того, чтобы действительно стать ориентированной
на данные организацией и получить все преимущества генеративного ИИ и облачных вычислений важно учитывать порядок и структуру реализации и использования этих технологий. Не стоит и говорить, что для меня все начинается
с качества данных, управления данными и безопасности.
Питхейн Стренгхольт: Спасибо, что поделились своими наблюдениями. Обсуждение было невероятно содержательным. Уверен, что наши читатели оценят ваши
подробные объяснения и рекомендации.

ГЛАВА 9

Пример: Amadeus, технологический
лидер туристической отрасли
В этой объемной главе мы исследуем нетривиальную архитектуру данных Ama­
deus (https://amadeus.com), глобального технологического лидера в туристической
отрасли. Своими наблюдениями с нами поделится Джоэл Сингер (Joel Singer) —
глава команды инженерии данных в Amadeus, который руководит инициативами
в области данных компании на основании своего почти 20-летнего практического
опыта.
Джоэл выделяет три столпа стратегии данных Amadeus: сетка данных, открытые
данные и Data 360. Их совокупное применение направлено на формирование
базы знаний и непрерывное улучшение продуктов. Мы исследуем неочевидную реализацию концепции сетки данных в Amadeus, который охватывает как
операционные, так и аналитические данные, чтобы эффективно удовлетворять
разнообразные потребности пользователей.
В ходе интервью Джоэл подробно описывает сложный дизайн медальона архитектуры данных Amadeus на каждом уровне, от загрузки данных до предоставления к ним доступа. Он рассматривает проблемы и решения, встречающиеся при
управлении бронзовым, серебряным и золотым уровнями, подчеркивая важность
качества данных, безопасности и доступности.
В этой главе также затрагиваются более широкие аспекты управления данными
в Amadeus, включая инновационный подход к интеграции данных и совместному
использованию между разными доменами внутри компании.
Питхейн Стренгхольт: Не могли бы вы представиться и рассказать нам о своей
роли и компании, где вы работаете?
Джоэл Сингер: Конечно! Меня зовут Джоэл Сингер, и я возглавляю отдел
инженерии данных в Amadeus — ведущем разработчике технологий в отрасли
международного туризма и путешествий. Мы работаем более чем в 190 странах
и предлагаем современные технологические решения для разных секторов отрасли, включая авиаперелеты, турагентства и гостиницы. Наш штат насчитывает
19 000 сотрудников по всему миру, из них 10 000 занимаются исследованиями
и разработкой. Размер команды говорит о нашей сильной приверженности технологическим инновациям.

  

292

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

Я работаю в Amadeus 23 года и руководил разными инженерными группами.
Мой опыт включает управление разработкой продуктов, интенсивно использующих данные, такие как системы управления доходами авиалиний и программами
лояльности. Эти системы требуют анализа огромных объемов исторических
данных для прогнозирования спроса на авиарейсы и понимания поведения
пассажиров. Качество и доступность этих данных критически важны для поставки самых современных продуктов нашим клиентам. В последние 5 лет
я перешел на более кросс-функциональные роли, занимаясь проектированием
и поставкой платформ данных, используемых всеми командами Amadeus для
разработки наших решений.
Питхейн Стренгхольт: Можете ли вы описать эволюцию своей архитектуры
данных?
Джоэл Сингер: Изначально наша архитектура данных была довольно фрагментированной. У нас было несколько платформ данных, использующих разные
технологии, например разные дистрибутивы Hadoop и решения хостинга. Некоторые приложения размещались локально в нашем дата-центре в Германии,
другие были облачными. Такая разнородность была обусловлена главным образом прошедшими приобретениями, когда новые компании приносили с собой
собственные стеки данных.
В результате сформировался технологический ландшафт разнородных платформ
данных с ограниченными возможностями обмена данными. Многие общие данные
оставались сырыми, что приводило к неоднократному копированию и разным
интерпретациям обработки, а как следствие — к повышению затрат и расхождениям в понимании данных.
Значительный сдвиг произошел в результате нашего стратегического партнерства с Microsoft, о котором было объявлено в феврале 2021 года. Партнерство
включало план миграции локальных дата-центров на облачную платформу. Мы
рассматривали этот процесс не только как миграцию, но и как возможность переработки всей архитектуры данных. Мы решили интегрировать Azure Databricks
и другие облачные технологии, перемещая локальные платформы данных в облако, что представляло около двух третей всех наших платформ данных, — этот
процесс проходил неплохо.
Интересно, что для оставшейся трети платформ, изначально не включенных
в проект облачной миграции, специалисты также увидели потенциальные преимущества и независимо приняли решение о миграции. Они выдвинули свои
доводы и со временем переместили свои платформы в облако, сделав их частью
сетки данных Amadeus.
Этот ход создал своего рода гравитацию данных, так как приложения за пределами исходного проекта также получили преимущества от нахождения в облаке, например улучшенные возможности обмена данными и обращения к ним.
В итоге это привело к централизованному управлению всей архитектуры данных

Пример: Amadeus, технологический лидер туристической отрасли  

293

в облаке, за что отвечала моя группа. Эта эволюция свидетельствовала о богатых
возможностях стратегических партнерств и преимуществах унифицированного
облачного подхода.
Питхейн Стренгхольт: Принята ли в Amadeus стратегия данных? Можете ли
рассказать о ней подробнее?
Джоэл Сингер: Да, в Amadeus существует четко определенная стратегия данных,
одобренная на самом высоком уровне компании. Наша стратегия строится на
трех основных принципах:
Сетка данных
Мы стремимся создать сетку данных (data mesh) на уровне компании. Поскольку Amadeus обслуживает всю экосистему туризма, каждый сектор (авиарейсы, аэропорты, турагентства и гостиницы) имеет собственные уникальные
требования и опыт. Архитектура сетки данных позволяет каждому домену
управлять своими данными, используя конкретные знания и навыки.
Открытые данные
Мы стремимся сделать данные открытыми и доступными. Чтобы обеспечить
практическую ценность данных, мы отслеживаем их качество и происхождение. Мы поддерживаем их обнаруживаемость при помощи каталогов данных,
а доступность — при помощи инструментов, дающих возможность пользователям интегрировать эти данные в свои продукты. Безопасность данных
обеспечивается процессом одобрения, а аудиторские следы используются для
мониторинга обращений к данным и их использования. Наши данные также
защищены от потерь и спроектированы как совместимые для более широких
возможностей многократного использования, в этом помогает аналитика, API
и другие методы.
Data 360
Этот принцип подразумевает использование данных для расширения базы
знаний, что, в свою очередь, помогает улучшить наши продукты. Например, при управлении доходами понимание потребностей клиента помогает
нам уточнить предложения. Эти улучшенные продукты генерируют больше
данных, создавая непрерывный цикл анализа и усовершенствования. Одно
из практических применений при покупках — поиск подходящих рейсов на
сайте турагентства. Мы обрабатываем миллиарды таких транзакций ежедневно, используя данные и машинное обучение для оптимизации процесса
и эффективного нахождения самых экономичных вариантов.
Эти принципы поддерживают нашу цель использования данных для улучшения
наших сервисов и предложений в туристической отрасли.
Питхейн Стренгхольт: Вы расширили концепцию сетки данных в Amadeus, чтобы
она включала как операционные, так и аналитические данные?

  

294

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

Джоэл Сингер: Безусловно, наша реализация концепции сетки данных в Amadeus
многогранна и охватывает все типы использования данных. Хотя изначально
сетку данных связывают прежде всего с аналитикой, наше видение этим не ограничивается. Мы признаем растущую потребность наших клиентов в событийноориентированных подходах и в способности реагировать на события в реальном
времени. Таким образом, наша архитектура сетки данных также поддерживает
потребности операционных данных. Она упрощает доступ к данным через различные интерфейсы, включая API и события; таким образом гарантируется, что
все формы данных будут доступными для наших клиентов. Этот целостный подход позволяет нам более эффективно удовлетворять разнообразные требования
клиентов.
Питхейн Стренгхольт: Существуют ли у вас установленные стандарты для разных
типов совместимости в архитектуре?
Джоэл Сингер: Да, мы отдаем предпочтение использованию существующих
стандартов вместо создания проприетарных решений. Например, для событий
мы используем AsyncAPI (https://asyncapi.com), для APIs — OpenAPI (https://
swagger.io/speciication ), а для аналитики и больших данных — соглашение
о совместном использовании. Существуют отраслевые стандарты, которые
гарантируют, что спецификации будут четкими и понятными для всех. Хотя
нам хотелось бы большего соответствия этим стандартам, их принятие помогает поддерживать ясность и согласованность при обработке данных в наших
системах.
Питхейн Стренгхольт: Вы упоминали, что в своей архитектуре сетки данных
вы применяете машинное обучение для получения аналитических выводов
и оптимизации вариантов путешествий. Предназначена ли эта деятельность для
агрегированных или предварительно интегрированных данных? И сочетается
ли она с MDM?
Джоэл Сингер: Наш подход склоняется скорее к агрегированию данных для
извлечения практической ценности, нежели к традиционному MDM. Мы концентрируемся на использовании функциональности данных для расширения
возможностей наших продуктов. По сути, мы заменяем старые эвристики более
сложными алгоритмами машинного обучения. Такие алгоритмы могут выявлять
закономерности в данных и выводы, которые не могут легко распознаваться
людьми; они используют исторические данные для повышения точности и эффективности. Такой подход позволяет нам непрерывно уточнять наши процессы
и предлагать более совершенные решения.
Питхейн Стренгхольт: Можете ли вы описать высокоуровневую архитектуру
своей платформы данных в Amadeus?
Джоэл Сингер: Конечно! С высокоуровневой точки зрения наша архитектура
платформы данных представляет смесь инструментов с открытым исходным
кодом и технологий Microsoft.

Пример: Amadeus, технологический лидер туристической отрасли  

295

Питхейн Стренгхольт: Сколько доменов и рабочих пространств у вас в управлении и следуют ли они одному архитектурному шаблону?
Джоэл Сингер: В настоящее время мы в Amadeus управляем десятью доменами
данных, каждый из которых соответствует конкретным предметным областям.
Этим доменам ставятся в соответствие посадочные зоны1, не привязанные к организационным структурам, потому что мы предвидим, что потребности организации могут изменяться со временем.
В этих десяти доменах мы создали в сумме 130 рабочих пространств для нашей
текущей среды. Каждое рабочее пространство спроектировано для поддержки
конкретных типов рабочих нагрузок и не связывается напрямую ни с какой конкретной командой для адаптации к изменениям в командах. На рис. 9.1 показан
высокоуровневый обзор нашей архитектуры платформы данных.
Workspace
Avro,
JSON

Real-time

Системыисточники

Azure Data
Factory

Azure Databricks

Бронзовый
уровень
(ADLS gen2)

JSON2Star

Серебряный
уровень
(ADLS gen2)

Золотой
уровень
(ADLS gen2)

Потребители
данных

• Смешанные форматы • Курируемые данные • Схемы «звезда»
• Сырые данные
• Вложенные форматы • Витрины данных
• Неизменяемые
• Внешние данные

Рис. 9.1. Высокоуровневая архитектура элементов, которые могут развертываться командами
в выделенных им средах
Шаблон каждого рабочего пространства зависит от потребностей продукта,
в котором оно используется. Например, у продукта, требующего расширенных
возможностей ИИ, в выделенном рабочем пространстве будут развернуты
ИИ-сервисы Azure. Этот адаптированный подход позволяет нам эффективно
удовлетворять разнообразные и развивающиеся потребности разных продуктов.
Питхейн Стренгхольт: Вы настраиваете сервисы на основании конкретных потребностей каждого домена?
Джоэл Сингер: Именно. Мы ведем каталог всех одобренных и безопасных сервисов, которые являются частью нашего шаблона платформы данных. Это позволяет командам выбирать из каталога сервисы, удовлетворяющие их конкретные
1

Посадочная зона Azure (https://oreil.ly/IaBVH) является фундаментальным элементом
Cloud Adoption Framework в Microsoft Azure, адаптированным для оптимизации процесса
построения безопасной, масштабируемой и эффективной среды для работы с данными
и аналитическими рабочими нагрузками, а также для управления этой средой.

  

296

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

потребности. Они могут создать рабочее пространство и развернуть в нем выбранные сервисы, чтобы адаптировать платформу данных для своих уникальных
требований, обеспечивая безопасность и комплаенс наших общих архитектурных
стандартов.
Питхейн Стренгхольт: Вы говорите о каталоге, который работает как портал
самообслуживания для установления инфраструктуры?
Джоэл Сингер: Да, мы движемся в этом направлении. Система еще не полностью
автоматизирована, но мы работаем над этим. Мы хотим иметь исчерпывающий
каталог всех доступных сервисов, чтобы добиться полной автоматизации развертываний. Это позволит командам обращаться к этим сервисам и пользоваться
ими в режиме самообслуживания. Автоматизация этих процессов очень важна для
нас, особенно с учетом размера организации, так как она поможет центральным
командам работать более эффективно и в масштабе.
Питхейн Стренгхольт: Применяете ли вы при настройке этих рабочих пространств единый инфраструктурный шаблон для всех доменов или существуют
возможности настройки?
Джоэл Сингер: Мы предоставляем два варианта для адаптации к потребностям
доменов. Существуют стандартные шаблоны, которые могут многократно использоваться в разных доменах, если они строятся по сходным паттернам. Дополнительно обеспечивается гибкость выбора конкретных сервисов, адаптированных
к специфическим требованиям команд. Этот двойственный подход поддерживает
как эффективность, так и настройку, позволяя командам либо быстро выполнить
развертывание на базе существующих шаблонов, либо адаптировать их конфигурацию выбором конкретных сервисов.
Питхейн Стренгхольт: Можете ли вы пояснить, как рабочие пространства структурируются в посадочной зоне конкретного домена?
Джоэл Сингер: Да, в каждой посадочной зоне, спроектированной для конкретного
домена, могут размещаться несколько рабочих пространств. Эти пространства
настроены для поддержки полного цикла работы с данными. Он включает исходную загрузку данных, за которой следует основная обработка данных, затем
их преобразования и, наконец, предоставление доступа к данным для бизнесиспользования. Каждое рабочее пространство структурировано таким образом,
чтобы любой из этих этапов проходил максимально эффективно, гарантируя
плавность потока и управления данными на протяжении всего процесса.

Архитектура медальона
Питхейн Стренгхольт: Используют ли все команды одну и ту же конфигурацию
в отношении иерархии архитектуры медальона и сколько в ней уровней?
Джоэл Сингер: Да, все команды придерживаются согласованной конфигурации,
основанной на архитектуре медальона; архитектура состоит из трех главных

  

Архитектура медальона

297

уровней. Эти уровни соответствуют стадиям жизненного цикла данных: их загрузке, обработке и предоставлению к ним доступа. Этот унифицированный подход
гарантирует, что независимо от команды метод управления данными остается
единым в рамках организации.
Питхейн Стренгхольт: Как в Amadeus реализован бронзовый уровень архитектуры медальона (загрузка данных), особенно с учетом разнообразия приложений
и форматов данных, с которыми вы работаете?
Джоэл Сингер: В Amadeus бронзовый уровень рассматривается в основном как
архив. Мы используем данные в исходной форме, будь то EDIFACT (https://oreil.
ly/FNpfv), XML, JSON или другие форматы, типичные для туристической отрасли.
Мы архивируем данные точно в том виде, в каком они были получены, чтобы избежать их повреждения и сделать их неизменяемыми, что помогает защититься
от потери данных. На этой стадии скрывается часть чувствительной информации,
например данные кредитных карт.
Бронзовый уровень служит двум основным целям. Во-первых, он работает как
архив для соответствия нормативам, которые могут требовать хранения данных
по юридическим причинам. Во-вторых, он полезен для специалистов data science,
которые могут извлечь полезную аналитику из сырых зашумленных данных.
Таким образом, хотя первоочередной целью является ведение надежного архива
и единого источника достоверной информации для входных данных, этот уровень
также поддерживает более глубокое исследование данных и анализ в случае необходимости.
Питхейн Стренгхольт: Проектировался ли бронзовый уровень в архитектуре как
уровень, допускающий запросы в формате Delta, как это делается в некоторых
организациях?
Джоэл Сингер: Нет, мы отказались от этого. Главные пользователи нашего бронзового уровня предпочитают работать с сырыми данными, используя собственные
инструменты, а не требуют, чтобы данные прошли обработку для запросов. Мы
стараемся по возможности упростить их работу и сохраняем данные в том формате, в каком они поступают.
Питхейн Стренгхольт: Как вы делаете данные бронзового уровня доступными
для этих целей?
Джоэл Сингер: Мы используем внешние таблицы в Azure Databricks, чтобы
данные были доступны с платформы.
Питхейн Стренгхольт: Какие преобразования происходят при перемещении
данных на серебряный уровень?
Джоэл Сингер: На серебряном уровне происходят значительные преобразования
данных. Основная задача — это нормализация данных в последовательный формат,
обычно с использованием JSON. Мы очищаем и обогащаем данные, обеспечивая
стандартизацию некоторых элементов (например, дат) в датасетах, чтобы упростить

  

298

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

их последующее использование. Целью серебряного уровня является подготовка
данных в унифицированном формате, готовом для бизнес-применения. На этом
уровне мы отходим от использования хранилища сырых данных, потому что оно
оказывается слишком затратным и отражается на производительности. Вместо
этого мы приняли программный подход к преобразованию нормализованной разметки JSON серебряного уровня в схему «звезда» на золотом уровне.
Питхейн Стренгхольт: Значит, на серебряном уровне моделирование данных
стремится сделать данные более денормализованными?
Джоэл Сингер: Да, верно. Один из ключевых процессов на серебряном уровне
включает денормализацию данных. Некоторые записи данных очень неструктурированны, имеют сложную иерархию и могут содержать до 2000 элементов данных.
На серебряном уровне эти данные денормализуются, что упрощает их структуру
для удобства последующего использования. Этот шаг очень важен для подготовки
данных к более эффективному анализу и обработке на следующих стадиях.
Питхейн Стренгхольт: Вы поддерживаете согласование с системами-источниками
в данных или интегрируете данные между разными системами?
Джоэл Сингер: Обычно мы стараемся сохранить согласованность данных с системами-источниками. Впрочем, есть и исключения, особенно в случае референсных
данных, для которых прямая интеграция на серебряный уровень может упростить
запросы к ним в будущем. Главной целью становится сохранение происхождения
данных, способствующее четкому разделению. Если при таком подходе возникнет
необходимость в дополнительных агрегациях или преобразованиях, исходный
источник данных останется доступным, а изменения в нем будут сведены к минимуму. Интеграция на этой стадии ограничивается прежде всего референсными
данными по практическим причинам.
Питхейн Стренгхольт: Что касается референсных данных, есть ли у вас корпоративная модель, которая описывает, какие референсные данные критически
важны для вашей работы?
Джоэл Сингер: Да, у нас имеется система управления мастер-данными, в которой
референсные данные сохраняются в соответствии с четкой моделью данных. Эта
модель совместно используется всеми командами, что особенно важно в туристической отрасли. Например, такие данные, как сопоставления между аэропортами и городами, часто и широко используются в компании. Это гарантирует
согласованность и точность обработки данных между разными применениями
и процессами.
Питхейн Стренгхольт: Можете ли вы подтвердить, что на серебряном уровне
используется формат данных Delta?
Джоэл Сингер: Да. В настоящее время на серебряном уровне используется формат Delta, для чего мы применяем Azure Databricks. При этом мы также следим
за новыми разработками в отрасли, например форматом Iceberg. Интересно

  

Архитектура медальона

299

заметить, что в версии Delta Lake 3.0 появилась поддержка формата Iceberg1.
Мы рады видеть такую конвергенцию, так как она позволяет нам не отставать от
новейших технологий и, возможно, интегрировать их в наши системы.
Питхейн Стренгхольт: Можете ли вы пояснить, как в вашей архитектуре организован золотой уровень?
Джоэл Сингер: Мы разработали собственную библиотеку JSON2Star, которая
упрощает преобразование с серебряного уровня на золотой. Эта библиотека
обрабатывает датасеты JSON с серебряного уровня и с помощью файла конфигурации, определяющего нужную итоговую модель данных или схему «звезда»,
генерирует все необходимые скрипты. Эти скрипты используются для создания
таблиц и включают команды Databricks, необходимые для построения итоговых
схем «звезда». Общая схема процесса изображена на рис. 9.2.

{HOCON}

Конфигурация
модели

{SQL}

Скрипты БД

JSON2Star
Основные
дополнения
Отображение
{JSON}

Стек
дополнений
Преобразование
денежных
единиц

{YAML}

GenAI
ETL

Преобразования
весов

Сырые
PIT-логика

Схема «звезда»

Пропорциональное
распределение

{Plant
UML}

Диаграмма БД
{md/
json}

Словарь

Рис. 9.2. Высокоуровневая архитектура JSON2Star, упрощающая преобразование
с серебряного уровня на золотой уровень
1

В 2024 году компания Databricks приняла стратегическое решение о приобретении
Tabular — компании, которая поддерживает инициативу Apache Iceberg, одного из ведущих табличных форматов озер-хранилищ с открытым исходным кодом. Подробнее
о разных табличных форматах см. во врезке «Apache Hudi, Apache Iceberg и Delta Lake»
главы 1, с. 50.

  

300

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

Этот процесс автоматизирован и выполняется каждый час, получая данные с серебряного уровня для создания схем «звезда». Такая автоматизация не только
повышает нашу эффективность, но и интегрирует подход CI/CD в наш пайплайн
данных. Она полагается на один источник истины, которым является файл конфигурации, определенный в открытом формате. Такое решение значительно упрощает
структурирование документации и скриптов, относящихся к схемам «звезда».
Питхейн Стренгхольт: Существуют ли на золотом уровне структуры, основанные на размерном моделировании, такие как схема «звезда» с таблицей фактов
и окружающими ее таблицами измерений?
Джоэл Сингер: Да, существуют. Наш золотой уровень состоит из таблиц фактов
и таблиц измерений. Тем не менее структура сложнее традиционных схем «звезда», потому что у нас множество таблиц фактов и множество взаимосвязанных
измерений. Из-за этой сложности мы рассматриваем эту структуру не просто
как схему «звезда», а как скопление схем «звезда», которое мы называем схемой
«галактика». Эта сложная конфигурация с широким набором измерений и фактов,
связанных воедино, которые создают значительную ценность для наших клиентов.
Питхейн Стренгхольт: Как организована интеграция данных в домене и как она
совместно используется между доменами?
Джоэл Сингер: Процесс начинается с рабочего потока, где команда, которой потребовались данные из другого потока, должна запросить доступ.
После того как команда запросит доступ к датасету, мы обращаемся к владельцу
данных и юридическим отделам, чтобы убедиться, что доступ к этим данным разрешен. После одобрения этими командами мы получаем доступ через Microsoft
Entra ID к контейнеру данных, в котором хранятся данные.
Кроме того, поскольку некоторые из наших данных сложны, мы используем Unity
Catalog для более точного управления доступом. Например, некоторые записи
могут включать информацию нескольких сущностей (скажем, туристических
агентств и авиарейсов), и каждая из них требует особого представления данных.
Unity Catalog помогает нам управлять этими нетривиальными потребностями
в доступе к данным на основании конкретных сценариев использования или
идентификаторов пользователей.
Все запросы на доступ к данным тщательно отслеживаются. Мы поддерживаем
аудиторский след для отслеживания того, кто выдает запрос и обращается к каждому датасету, проверяя, что использование данных осуществляется прозрачно
и безопасно. Этот структурированный подход позволяет нам управлять совместным доступом к данным между разными доменами при сохранении жесткого
соблюдения стандартов и норм безопасности.
Питхейн Стренгхольт: Может ли система доступа к данным также использоваться для продакшен-сценариев, где данные запрашиваются не только отдельными
пользователями, но и сервисными аккаунтами?

  

Архитектура медальона

301

Джоэл Сингер: Безусловно. В нашей системе поддерживаются как отдельные
пользователи с индивидуальными учетными записями, так и сервисные аккаунты, их можно рассматривать как пользователей-ботов, представляющих
продукты. Например, один из наших продуктов, Amadeus Dynamic Pricing, использует данные из нескольких источников. Он использует данные из системы
бронирования, чтобы понять текущие запросы на покупку, внедряет сторонние
данные и использует референсные данные. Интегрируя все эти источники данных, механизм динамического ценообразования может корректировать цены
на основании рыночных условий. Это показывает, как наша система доступа
к данным поддерживает сложные сценарии эксплуатации, облегчая интеграцию
разнородных источников данных.
Питхейн Стренгхольт: Как ваша корпоративная команда сохраняет контроль за
разнообразными поставками данных и производимыми датасетами?
Джоэл Сингер: Чтобы управлять разнообразными поставками и датасетами
и контролировать их, мы используем каталог данных. Этот инструмент не только
помогает запросить доступ к данным, но и отслеживает запросы на получение
доступа. Кроме того, мы реализовали панель управления, которая дает сводное
представление о том, кто обращается к тем или иным типам данных.
В нашей сетке данных имеется выделенный узел, который ведет мониторинг процессов обмена данными, как бы они ни происходили — через большие данные, API
или события. Это позволяет нам поддерживать аудиторский след всех операций
обмена, обеспечивать прозрачность и подотчетность в обращениях к данным и их
использовании в среде предприятия.
Питхейн Стренгхольт: Таким образом, из каталога данных вы можете отслеживать
все перемещения данных?
Джоэл Сингер: Да, вся информация тщательно фиксируется в каталоге данных.
Из этого каталога можно отслеживать все запросы, доступные эндпоинты API,
продукты данных, перемещения данных и т. д. Мы проверяем, как фактическое
использование данных соответствует заявленному. Это означает, что мы не
только отслеживаем объявленное использование данных, но и следим, чтобы
текущие операции совпадали с этими объявлениями. Система помогает поддерживать целостность данных и соблюдение стандартов во всех операциях
с данными.
Питхейн Стренгхольт: Какое определение продукта данных используется
в Amadeus?
Джоэл Сингер: Продукт данных занимает центральное место в стратегии Amadeus
по трансформации в компанию, управляемую на основе данных. Продукт данных должен обладать рядом ключевых признаков: практической ценностью,
обнаруживаемостью, доступностью, безопасностью, достоверностью, интероперабельностью — и соответствовать стандартам открытых данных. Мы стремимся

  

302

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

к тому, чтобы данные были доступны в разных формах для целей аналитики,
через API или события. Продуктом данных владеет домен, ответственный за их
производство, поскольку он имеет опыт работы с этими конкретными данными.
Этот комплексный подход гарантирует, что наши продукты данных остаются эффективными и удовлетворяют нашим высоким стандартам операций с данными.
Питхейн Стренгхольт: Существуют ли конкретные принципы относительно того,
какие уровни данных могут использоваться на входе продуктов данных, особенно
для предоставления данных другим? Например, разрешается ли для этой цели
использовать бронзовый уровень?
Джоэл Сингер: Мы разрешаем использование любого уровня. Однако применение
бронзового уровня для предоставления данных в общем случае нежелательно,
как я уже говорил. Как правило, для этого чаще используется золотой уровень.
На нем содержатся уточненные данные, и он имеет зависимости, поэтому подходит для широкого распространения и применения данных между разными
сервисами и платформами.
Питхейн Стренгхольт: Таким образом, при всей гибкости использования любого
уровня данных, использование продуктов данных зависит от специфических
условий?
Джоэл Сингер: Точно. Хотя мы предоставляем гибкие возможности использования любого уровня, каждый продукт данных имеет собственный набор условий
для обеспечения целостности и надежности данных. Это помогает поддерживать
стандарты между всеми уровнями и сценариями применения.

FinOps
Питхейн Стренгхольт: Можете ли вы рассказать, как вы относитесь к практике
FinOps и о ее связи с сеткой данных в Amadeus?
Джоэл Сингер: В Amadeus мы уделяем большое внимание концепции FinOps,
особенно в том, что касается оптимизации сетки данных. Изначально базовая
реализация сетки данных создавала значительное финансовое бремя, включавшее затраты на хранение и обработку, прежде всего для производителей данных.
Однако такая схема не стимулирует производителей к обмену или улучшению
удобства использования данных.
FinOps (сокращение от Financial Operations) — бизнес-практика, направленная на максимизацию финансовой ценности затрат на облако. Она объединяет профессионалов из области технологии, бизнеса и финансов с целью
повышения эффективности совместного управления облачными затратами
и вложениями. С ростом миграции на облачные технологии организации
признали необходимость контроля и оптимизации своих затрат на облако,
и в качестве стратегического подхода для достижения этой цели появилась
концепция FinOps.

  

Модели данных

303

Для решения этой проблемы мы стали в большей степени ориентироваться на потребителя. При таком подходе затраты распределяются на конечные продукты, использовавшие данные. Звучит просто, но на практике все усложняется. Например,
если данные о покупках используются двадцатью разными продуктами, затраты
необходимо прежде всего разнести между этими продуктами с использованием
специального ключа. Это более справедливо, и это позволит сосредоточиться
в первую очередь на потребителях, а не на производителях.
Мы продолжаем исследовать инновации, которые помогут стимулировать производителей данных на создание виртуальной модели прибылей и убытков (P&L).
Эта модель не только покрывает затраты, но и генерирует виртуальный доход для
производителей, поощряя их к созданию большего объема качественных данных.
Это требует реализации дополнительных функций, включая сопоставление данных от производителей с итоговыми продуктами, в которых они потребляются.
Такая эволюция нашей стратегии FinOps интересна, потому что она поощряет
стремление к совместному использованию данных между доменами данных.
В итоге с ростом совместного использования данных растет и вовлеченность
клиентов, инновационность продуктов и общий успех нашей сетки данных.
Питхейн Стренгхольт: Потребовала ли реализация виртуального P&L изменений
в финансовых процессах в IT, особенно с учетом того что IT обычно рассматривается как центр затрат?
Джоэл Сингер: Да. Мы называем P&L «виртуальным», поскольку он представляет собой сдвиг в восприятии финансовой ответственности — от рассмотрения
IT-отдела только как центра затрат к потенциальному признанию его как центра
прибылей. Это изменение стало значительным шагом вперед, и хотя пока мы еще
не реализовали полноценную модель виртуального P&L, эта концепция помогает
нам переосмыслить и согласовать финансовые процессы для более качественной
поддержки инициатив, управляемых данными.
Питхейн Стренгхольт: Станет ли переход на более эффективную P&L модель
следующим шагом ваших финансовых процессов в IT?
Джоэл Сингер: Да, мы движемся в этом направлении. В настоящее время модель
виртуальных P&L позволяет производителям данных видеть, какие продукты
потребляют их данные и как затраты распределяются между потребителями. Она
также дает возможность производителям понимать прибыль, генерируемую по
их данным (по крайней мере, виртуально). Это мотивирует их на расширение
объема поставляемых данных. Они видят, какова востребованность этих данных
и как они успешно используются разными командами для создания продуктов.

Модели данных
Питхейн Стренгхольт: Можете ли вы подробнее рассказать о нижележащей
модели данных, которую вы используете для API, событий и продуктов данных?

  

304

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

Джоэл Сингер: Конечно. Подход Amadeus включает в себя внедрение общей модели данных, которую мы называем логической моделью. Она проектировалась
как многоязычная, то есть не привязанная ни к какой конкретной реализации.
На этой логической основе мы создаем более специализированные физические
модели, адаптированные для типа используемого интерфейса, будь то модель для
событий, использующая спецификации AsyncAPI, модель API, использующая
открытые спецификации API, или контракты Big Data. Схематическое представление этого процесса изображено на рис. 9.3.
Концептуальная модель
Многоязычная логическая модель
Физическая модель:

AsyncAPI

Для потребителей
Документация

OpenAPI

DataContract

Для разработчиков
Шаблоны кода/SDK

Рис. 9.3. Управление данными реализуется как код посредством автоматизации создания
всех новых интерфейсов
После создания таких физических моделей мы генерируем связанные с ними
ресурсы, такие как потребительская документация и шаблоны кода или SDK
(Software Development Kit) для разработчиков. При этом наша цель — поддержка одной логической модели между разными реализациями и управление всеми
процессами через пайплайн CI/CD. Это позволяет обеспечить наличие единого
источника истины, эффективную доставку и согласованную документацию независимо от интерфейса, с которым работают клиенты.
Это весьма амбициозное видение, и мы пока не нашли на рынке инструментов,
которые бы в полной мере удовлетворяли наши потребности. Чтобы решить эту
проблему, мы используем различные инструменты, включая проекты с открытым
исходным кодом (например, OpenAPI Generator), для реализации физических
моделей и генерирования необходимой документации. Тем не менее для полной
реализации нашего видения необходимо проделать значительную работу, особенно в отношении доступности необходимых инструментов.
Питхейн Стренгхольт: Можете подробнее рассказать о том, как организовано
хранение этих логических моделей данных?
Джоэл Сингер: Да, мы организовали репозиторий кода, отражающий нашу
иерархию доменов данных. Мы используем комбинацию пайплайнов CI/CD

  

Модели данных

305

и различных инструментов для генерации физических моделей, документации
и SDK. Такая конфигурация соответствует нашему видению программного подхода к моделированию данных.
В основном мы применяем средства визуализации для просмотра моделей на каждой стадии, но не для редактирования, так как эти инструменты не предназначены
для изменений. Программный подход позволяет более эффективно управлять
изменениями и предоставляет ряд преимуществ, таких как возможность проверки валидности моделей, соответствия нашим рекомендациям и стандартам
данных. Такая система помогает поддерживать согласованность и точность между
моделями данных.
Питхейн Стренгхольт: У каждой команды свой репозиторий, и также существует
центральный репозиторий для общих моделей?
Джоэл Сингер: Да, в глобальном репозитории компании мы упорядочиваем
разные домены данных из сетки данных, включая субдомены. Каждая команда
отвечает за свой конкретный субдомен. Хотя ответственность смещается на
уровень команд, общая иерархия управляется централизованно для обеспечения
жизнеспособности и совмещения с нашим более широким видением данных. Централизованное управление очень важно, потому что оно помогает обеспечивать
согласованность даже при изменении организационных структур со временем.
Мы стремимся к тому, чтобы наши практики управления данными были адаптируемыми, но при этом последовательно сочетались с долгосрочными целями.
Питхейн Стренгхольт: Есть ли у команд возможность видеть результаты друг
друга, чтобы по возможности повторно использовать логику или ресурсы?
Джоэл Сингер: В самом деле, мы активно поощряем такого рода сотрудничество
в наших практиках управления данными. В туристической отрасли, где многие
элементы данных (авиарейсы, туристы, цены) являются общими для разных
сервисов (авиалиний, гостиниц), важно иметь стандартизированные общие модели данных. Для этого мы централизованно управляем тем, что мы называем
семействами данных, — моделями данных, общими для большинства областей
компании. Таким образом, наши системы являются не только стандартизированными, но и более простыми в использовании для клиентов. Это повышает
эффективность и согласованность между разными командами и проектами.
Питхейн Стренгхольт: Ваш подход предполагает гибридную модель, в которой
централизованное управление критическими моделями данных объединяется
с локальными расширениями и настройками?
Джоэл Сингер: Именно, это часть нашей стратегии. Мы понимаем, что у каждого направления бизнеса свои уникальные требования. Для решения этой проблемы мы централизованно предоставляем стандартные семейства данных (или
общие модели данных). Затем каждый домен может адаптировать эти модели,
удаляя лишние элементы или добавляя конкретные возможности, актуальные
для его области. Этот метод гарантирует наличие общего фундамента, но при

  

306

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

этом он достаточно гибок для обслуживания специфических потребностей. Мы
также регулярно обсуждаем, как уточнить эти общие модели данных, чтобы
они поддерживали новые тренды и чтобы каждой команде не приходилось
настраивать их по отдельности. Для этого мы стремимся по возможности выделить общие параметры в пределах компании, при этом допуская необходимую
вариативность.
Питхейн Стренгхольт: Такой подход требует высокого уровня стандартизации
в предоставлении ресурсов, CI/CD и процессах оркестрации, верно? Расскажете
об этом подробнее?
Джоэл Сингер: Да, стандартизация для нас очень важна. Мы стремимся применять единый инструментарий для всех процессов CI/CD. Такое решение стало
стандартом, который мы стараемся поддерживать во всех рабочих потоках, автоматизируемых с использованием общих инструментов. Наша цель — установить
единый источник истины, чтобы избежать дублирования и необходимости управления данными в нескольких местах, что мы считаем непрактичным.
Начиная с этого единого источника, мы используем свой инструментарий для
генерации всех остальных необходимых моделей, включая документацию, шаблоны кода, SDK и схемы. Этот метод помогает оптимизировать наши операции
и обеспечить согласованность между практиками управления данными.

Контракты данных
Питхейн Стренгхольт: Вы упомянули о контрактах данных. Можете рассказать
об этой концепции более подробно?
Джоэл Сингер: Конечно. В контексте API существует хорошо известный
стандарт, называемый Open API, который описывает, как должен происходить
информационный обмен или коммуникации между API с двух сторон. Для
событий набирает популярность стандарт AsyncAPI, который упрощает обмен
событиями между двумя сторонами. Однако мы заметили в этой области пробел
для Big Data, приведший к разработке нового стандарта, который называется
контрактом данных.
Мы внимательно отслеживаем и начинаем реализовывать этот зарождающийся
стандарт, потому что видим необходимость в структурированном механизме обмена большими данными по аналогии с тем, как мы управляем API и событиями.
Похоже, такой стандарт хорошо сочетается с существующими протоколами для
API и событий. Можно предполагать, что эти стандарты сблизятся в будущем.
Мы с оптимизмом смотрим на его разработку и интеграцию в наши системы, так
как он представляет значительный шаг по направлению к стандартизации обмена
большими данными.
Питхейн Стренгхольт: Что касается стандартизации контрактов данных, вы приняли существующий стандарт или разработали собственный?

  

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

307

Джоэл Сингер: Мы решили принять существующие стандарты, а не создавать
собственный. Пока мы оцениваем эти стандарты, чтобы убедиться, что они соответствуют нашим потребностям. И мы вполне удовлетворены результатами.
Надеемся, что эти стандарты будут приняты многими командами и компаниями и в перспективе станут такими же популярными и распространенными, как
Open API. Такое широкое распространение способствовало бы согласованности
и эффективности обмена данными между разными платформами и отраслями.

Управление данными
Питхейн Стренгхольт: Контракты данных тесно связаны с управлением данными
(data governance). Как эволюция вашей архитектуры данных упрощает обмен,
стандартизацию и управление данными?
Джоэл Сингер: Трансформация нашей архитектуры не только упрощает обмен
данными, но и улучшает их стандартизацию и управление данными. Изначально
наш подход к управлению данными был в основном централизованным — я буду
называть его Governance 1.0. Около 15 лет назад в компании существовала только
одна исследовательская группа, и стандарты принимались относительно просто,
потому что подчинение строилось по одной линии.
С расширением компании наша структура превратилась в то, что я буду называть
Governance 2.0. Наши группы инженеров были разделены по линиям бизнеса,
и единого руководителя инженерной службы, ответственного в рамках всей
компании, просто не было. Такое изменение усложнило контроль соблюдения
нисходящих стандартов и решений. Как следствие, мы перешли на модель управления данными, основанную на сообществе. В этой конфигурации у нас оставался центральный орган, выдающий рекомендации, но реализацией изменений
управляли участники сообщества, входившие в эту схему управления данными.
С учетом нашего недавнего перехода на облако и текущих усилий по сближению
разных бизнес-вертикалей мы увидели потребность в новой модели управления
данными — Governance 3.0. Эта модель представляет собой федеративный подход
к управлению данными. Мы создали централизованный орган. Он назначает глобальные политики, процессы и правила, предоставляет используемые семейства
данных и управляет каталогом данных, которые могут потребляться внутренними
пользователями и передаваться клиентам. В каждом домене в нашей компании
существует свой локальный орган управления данными, отвечающий за реализацию этих правил и управление повседневными изменениями в их API и других
функциях, относящихся к данным. Эти органы, отдельные для каждого домена,
наделены полномочиями для внешней публикации своих данных в соответствии
с правилами, которые устанавливаются централизованным федеративным органом управления.
Мы полагаем, что эта федеративная структура управления данными — самый эффективный способ организации работы такой компании, как Amadeus,

  

308

Глава 9. Пример: Amadeus, технологический лидер туристической отрасли

в современных условиях. Она сочетает централизованный надзор с локальными
полномочиями, упрощая контроль соблюдения требований и быструю реакцию
на изменения требований. Такая структура облегчает совместное использование
данных, стандартизацию и надежное управление данными в пределах компании.
Питхейн Стренгхольт: Наше интервью подходит к концу. Можете ли вы дать
какие-нибудь рекомендации для читателей книги?
Джоэл Сингер: Мой первый совет — понять, что платформы данных «на все
случаи жизни» не существует; каждая компания уникальна. Сначала оцените,
насколько данные важны для вашей компании, оцените, какова ситуация с ними
сейчас, и определите, чего вы хотите добиться. Очень важно разработать стратегию данных в масштабах организации, которая сочетается с планами компании,
и позаботиться о поддержке на высших уровнях.
Что касается реализации, я прочно верю в важность централизованного органа
как для управления данными, так и для архитектуры. Он помогает обеспечивать
согласованность применения стратегии в компании. Кроме того, по возможности
наделите отдельные домены данных полномочиями для реализации этой стратегии и сделайте их данные доступными для пользователей в удобном формате.
Иначе говоря, чтобы добиться наилучших результатов, управляйте централизованно, но предоставляйте полномочия локально.
Питхейн Стренгхольт: Подпишусь под каждым словом! Спасибо за открытость,
это очень полезная информация. Наши читатели наверняка захотят узнать
больше!

ГЛАВА 10

Пример: стратегические
преобразования данных в ZEISS
В этой главе мы исследуем стратегии данных и инфраструктуру ZEISS (https://
zeiss.com), лидера в отрасли оптики. Наши собеседники в этой главе — Маркус
Моргнер (Markus Morgner), глава Фонда данных предприятия; Саша Сомер
(Sascha Saumer), сеньор дата-инженер; Герт Кристен (Gert Christen), менеджер платформы Microsoft BI. Участники команды данных ZEISS расскажут об
эволюции своих систем данных, стратегических преобразованиях и внедрении
инновационных технологий.
Обсуждение начинается с важного сдвига к централизованной стратегии данных,
стартовавшего в 2021 году. Смена стратегии, направленная на консолидацию разрозненных практик данных в целостную модель, повышает эффективность разных
сегментов компании. Маркус Моргнер подробно описывает переход от децентрализованной конфигурации к федеративной модели, которая не только укрепляет
общий контроль, но и наделяет отдельные сегменты большей автономностью.
Затем Саша Сомер и Герт Кристен подробно опишут технические особенности
платформ данных ZEISS, уделяя особое внимание переходу на облачные технологии и принятие концепции сетки данных. Они объяснят, как компания адаптирует
свои процессы обработки данных для удовлетворения разнообразных бизнес-потребностей через сочетание централизованных и децентрализованных подходов.
Эта глава не только раскроет технические вопросы управления крупномасштабными системами данных, но и даст представление о более широком значении для
управления данными, интеграции и совместном участии в глобальных операциях
ZEISS. Информация, которой поделится команда ZEISS, подчеркнет сложность
сферы управления данными и станет полезным источником аналитики для будущей корпоративной стратегии данных.
Питхейн Стренгхольт: Спасибо, что приняли приглашение. Прежде чем мы начнем, представьтесь, пожалуйста, и опишите свою роль и обязанности в ZEISS.
Маркус Моргнер: Конечно. Давайте я начну. Меня зовут Маркус Моргнер.
Я возглавляю Фонд данных предприятия (Enterprise Data Foundation) в ZEISS.
Наш отдел осуществляет контроль над основными платформами данных уровня
предприятия, который включает управление данными.

  

310

Глава 10. Пример: стратегические преобразования данных в ZEISS

Саша Сомер: Теперь представлюсь я — Саша Сомер, сеньор, дата-инженер в отделе Маркуса. Я занимаюсь в том числе внедрением новых сценариев использования на нашу платформу и работаю над тем, чтобы они успешно выполнялись.
Герт Кристен: И я, Герт Кристен. Я управляю платформой Microsoft BI в команде
Фонда данных, что включает в себя масштабное развертывание сервисов Power
BI. Я также участвую в предстоящей реализации Fabric Data Platform в нашей
компании. Вместе с Сашей мы работаем над созданием единой платформы,
которая предоставляет оптимальные решения на основании разных сценариев
использования.
Питхейн Стренгхольт: Спасибо, а теперь перейдем к первому вопросу. Пожалуйста, расскажите подробнее о ZEISS, в какой отрасли вы работаете, какую
стратегию данных используете, как она поддерживает организацию?
Маркус Моргнер: Конечно. ZEISS — ведущая компания в области оптики, основанная в 1846 году, так что нас можно считать компанией с богатым наследием.
Наш штат насчитывает около 45 000 сотрудников, а выручка за последний финансовый год достигла 10 миллиардов евро. Наша стратегия данных была принята
в 2021 году. До ее появления наши инициативы в области данных и команды были
децентрализованы и работали в изолированных подразделениях организации.
Первым шагом этой стратегии была гармонизация этих разнообразных компетенций и возможностей и объединение их в одной команде — команде данных
и аналитики, также сформированной в 2021 году. Эта команда включает различные роли: управление мастер-данными, бизнес-аналитику, создание отчетов. Мы
также добавили новые роли, такие как специалисты data science, дата-инженеры
и архитекторы. Кроме того, добавили функциональность управления данными,
сосредоточившись на каталогах данных, политиках и соблюдении стандартов.
Мы прошли более половины пути реализации этой стратегии. У нас имеется
центральная организация, но многие вопросы выносятся в наши бизнес-сегменты.
Эти бизнес-сегменты теперь используют наши платформы и придерживаются
наших процессов управления данными. Мы активно обмениваемся знаниями
и ресурсами с такими сегментами, чтобы способствовать их росту. Наша модель
становится полностью федеративной с сильным ядром, которое поддерживает
централизованный контроль над важнейшими функциями одновременно с наделением бизнес-сегментов широкими полномочиями.

Эволюция платформы данных
Питхейн Стренгхольт: Спасибо за подробное объяснение. Расскажите об эволюции вашей платформы данных. С чего вы начали, в каком направлении двигаетесь
сейчас?
Маркус Моргнер: Эволюция нашей платформы данных началась около 2017–
2018 года, когда мы начали изучать возможности Azure. Изначально платформа

  

Эволюция платформы данных

311

работала в режиме песочницы — места для экспериментов без конкретных сценариев использования. В 2018–2019 году мы начали интегрировать реальные
сценарии и значительно расширили свою пользовательскую базу, что продолжалось до 2022 года. Однако архитектура была спроектирована неоптимально — она
разрасталась органически вместе со сценариями использования, и, как следствие,
возникали проблемы с воспроизводимостью и повторным использованием. У нас
был один аналитический стек, работавший на базе озера-хранилища, что приводило к проблемам совместного доступа к ресурсам.
Поняв это, в 2022 году мы сделали шаг назад, проконсультировались с Microsoft
и решили использовать в своей работе Cloud Adoption Framework (https://oreil.
ly/N7eya ). Это помогло нам установить новую платформу, интегрирующую
лучшие практики с самого начала, включая встроенные стандарты управления
данными и высокой безопасности. Платформа eVA базируется на Cloud Adoption
Framework. Она использует посадочные зоны данных (DLZ, data landing zone) для
доменов, которые состоят из одной или нескольких подписок Azure. Платформа
включает центральный хаб для управления данными, безопасности, мониторинга
и извлечения метаданных для каталога. На рис. 10.1 представлен общий обзор
нашей платформы данных.
Мы также начали реализовывать идеи, сходные с концепцией сетки данных, хотя
изначально этот термин формально не использовался. Платформа была разбита
на домены или области, которые, как мы позже поняли, близко соответствовали
описанию Жамак Дехгани (Zhamak Dehghani) из ее книги «Data Mesh: Delivering
Data-Driven Value at Scale» (O’Reilly).
В третьей итерации мы запустили eVA Enterprise Big Data Analytics Platform
3.0. В реализации использовались 30 экземпляров, каждый из которых включал
от трех до четырех подписок, они строились на одних и тех же стеках модулей
Terraform и инфраструктуре. Мы включили области для управления данными,
безопасности, мониторинга и извлечения метаданных для нашего каталога данных. В процессе масштабирования платформы мы разработали разные паттерны
для обработки данных.
Централизованные экземпляры
Предоставляют продукты данных, используемые в пределах компании (например, финансовую информацию), чтобы не приходилось постоянно «изобретать велосипед».
Децентрализованные посадочные зоны данных
Уникальны для конкретных бизнес-доменов или процессов, где данные должны храниться отдельно при минимальном взаимодействии с другими зонами.
Гибридные экземпляры
Пространства для сотрудничества с бизнес-юнитами, в которых предоставляется как минимум инфраструктура и мониторинг безопасности. Дополнительная

312

  

Глава 10. Пример: стратегические преобразования данных в ZEISS

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

DP
DP

Synapse

DP
DP
DP
eVA 3.0

eVA 3.0

Домен №...

Домен №1

DP
DP
DP

Synapse

DP

Центральный
хаб

DP
DP

eVA 3.0

eVA 3.0

Домен №5

Домен №2

DP
DP

DP
Azure ML

DP

DP

Cosmos DB

eVA 3.0

Домен №4
Домены данных
DP Продукт данных

eVA 3.0

Домен №3
Использование данных между доменами

Источники данных

Интеграция платформы

Команды данных

Рис. 10.1. Общий обзор платформы eVA
Питхейн Стренгхольт: Хочу уточнить: говоря о «посадочной зоне», вы используете этот термин в том контексте, в каком он описан в Cloud Adoption

  

Эволюция платформы данных

313

framework? Иначе говоря, речь идет о подписке с набором ресурсов, и их может
быть много?
Маркус Моргнер: Да, верно. Впрочем, сейчас термин «посадочная зона», возможно, уже не очень хорошо подходит для описания. Я предпочитаю называть их «экземплярами» нашей платформы, потому что они охватывают всю конфигурацию.
Каждый экземпляр представляет собой автономную платформу, включающую все
возможности, необходимые для создания сквозных продуктов данных.
Питхейн Стренгхольт: Учитывая разнообразие сервисов, которые вы используете
(Azure Synapse Analytics, Azure Databricks, Microsoft Fabric), определяете ли вы,
какие домены использовать? Имеется ли у вас стратегия будущего состояния?
Есть ли долгосрочный план или необходимость рационализации таких сервисов?
Саша Сомер: Начну с первого вопроса: заранее предписанной стратегии для
выбора технологической платформы, которую должны использовать команды
доменов, не существует. Команды должны сами выбрать то, что лучше подходит
для их потребностей. Мы обеспечиваем общее руководство и поддержку, но окончательный выбор остается за командами. Никого не заставляют использовать
конкретный технологический стек.
Что касается вашего второго вопроса, у нас имеется стратегия миграции, которая в основном сосредоточена на переносе проектов с более старых платформ
(таких, как eVA 2.0) в более новую среду eVA 3.0, а не на конкретные технологии.
Стратегия направлена на стандартизацию рабочих потоков, а ее цель — принять
меры к тому, чтобы все следовали одним и тем же стандартам. Таким образом, мы
продолжаем поддерживать использование Synapse, Databricks и Fabric по мере
необходимости. В настоящее время мы не планируем отказываться от каких-либо
из перечисленных технологий. Миграция происходит органически, на нее влияет
увеличение объема использования сервисов в компании и поддержка сообщества,
что способствует естественному переходу на эти платформы большого количества
пользователей. Мы не вынуждаем отказываться от используемых технологий.
На будущее мы разработали высокоуровневую стратегию для интеграции eVA 3.0
и Fabric на нашу новую платформу данных eVA 4.0. В этой интеграции Fabric будет
применяться на уровне, ориентированном на потребителя, для использования
продуктов данных, создаваемых в сетке данных eVA 3.0.
Герт Кристен: Добавлю, что наш подход — не столько намеренная стратегия,
сколько естественная эволюция. Изначально в своих озерах-хранилищах мы в основном применяли Synapse, но заметили сдвиг в направлении Azure Databricks,
особенно для более сложных сценариев, требующих дополнительной гибкости
и расширенной функциональности. При этом мы продолжаем использовать бессерверные пулы SQL из Synapse за их простоту.
Эта миграция в направлении Azure Databricks для более требовательных рабочих
нагрузок произошла органически, а не в результате применения запланированной
стратегии. Введение сервиса Unity Catalog также упростило этот переход.

  

314

Глава 10. Пример: стратегические преобразования данных в ZEISS

Одной из заметных проблем стали затраты на инфраструктуру. Кроме того, многие
пользователи, особенно в доменах, ориентированных на потребителя, стремятся
к полноценному самообслуживанию. Они предпочитают управлять своими операциями независимо, сводя к минимуму координацию с другими командами при
развертывании новых ресурсов или представлений. Также наблюдается растущий
интерес к использованию Fabric, так как это обеспечивает большую независимость
при управлении проектами. Для доменов, ориентированных на потребителя,
Fabric становится рекомендуемым решением. Однако для агрегатных доменов
и доменов, соответствующих источникам, мы пока планируем продолжать использовать проверенные посадочные зоны данных eVA3.0.

Архитектура медальона
Питхейн Стренгхольт: Перейдем к теме архитектуры медальона. Считается ли
она лучшей практикой для этих экземпляров платформ?
Саша Сомер: Да, определенно. В каждом экземпляре платформы наш подход
базируется на конкретных потребностях бизнеса. Обычно мы рекомендуем
реализовывать архитектуру медальона. Это может привести к созданию разных
учетных записей хранилищ и уровней кода внутри экземпляра. Точная техническая структура может изменяться в зависимости от используемых сервисов,
но мы обычно рекомендуем использовать эту архитектуру, и она применяется
в большинстве случаев.
Питхейн Стренгхольт: Уточню на всякий случай: когда вы создаете экземпляр
платформы или того, что вы ранее называли посадочной зоной, вы адаптируете
его под конкретные потребности. Итак, даже при том что шаблон инфраструктуры
может оставаться неизменным, вы настраиваете компоненты под конкретную
ситуацию, верно?
Саша Сомер: Точно. Хотя некоторые компоненты стандартны (такие, как сырые
данные и расширенная учетная запись хранения), конкретное их предоставление
адаптируется под потребности каждого экземпляра. Если вам нужна, например,
база данных NoSQL, можно предоставить Mongo DB или другой подходящий
вариант. Если необходимо решение на базе SQL Server — мы также адаптируем
его под конкретные нужды.
Питхейн Стренгхольт: В каждом ли экземпляре присутствуют такие фундаментальные сервисы данных, как Azure Synapse Analytics или Azure Databricks?
Саша Сомер: Нет, мы в первую очередь различаем сценарии пакетной обработки
и обработки в реальном времени. Каждый сценарий предусматривает стандартный набор ресурсов, при этом достаточно гибкий, зависящий от потребностей
организации. Например, бизнес-юнит может работать с Azure Databricks, и мы
даем рекомендации о том, какой сервис лучше подойдет для их требований. Такое
же разнообразие характерно для обработки в реальном времени; клиенты могут

  

Архитектура медальона

315

использовать Synapse, Databricks и даже Azure Functions. Хотя некоторые ресурсы
стандартны (например, две учетные записи хранения и сетевые компоненты),
конкретные сервисы данных не фиксированы и могут изменяться для каждого
конкретного экземпляра.
Питхейн Стренгхольт: Зависит ли иерархия архитектуры данных от конкретного
сценария или ситуации? Может ли в нем быть меньше или больше уровней?
Саша Сомер: Да, структура уровней зависит от ситуации. Как говорил Маркус,
в компании у нас около 30 таких экземпляров платформ. Они гармонизированы,
но не идентичны из-за разнообразия сценариев использования. Как правило, это
архитектуры с тремя уровнями (бронзовый, серебряный и золотой), которые могут быть разделены на разные схемы или процессы в учетных записях хранения1.
Некоторые экземпляры могут работать всего с одним или двумя уровнями, они
часто называются уровнем промежуточного хранения и презентационным уровнем. Таким образом, в действительности все зависит от конкретных потребностей
и конфигурации каждого экземпляра.
Питхейн Стренгхольт: Расскажите подробнее об этих экземплярах платформ.
Начнем с первого уровня — как работает загрузка данных?
Саша Сомер: Данные загружаются непосредственно в сервисы, например учетные записи хранения, разными средствами. Один из примеров — Azure API
Management. Обычно данные производятся на стадии событий или в сценариях
реального времени, другими методами. Кроме того, имеется классический пакетный подход, при котором задание, выполняемое каждую ночь, подключается
к системам-источникам для загрузки данных. Таким образом, для загрузки данных, по сути, используются как push-, так и pull-методы.
Маркус Моргнер: Добавлю, что здесь есть возможности для улучшения. В частности, у нас всегда возникали проблемы с обработкой загрузки данных SAP. Мы
рассматриваем возможность добавления уровня перед бронзовым уровнем для
консолидации данных SAP в SAP-системах перед их передачей на нашу платформу данных в Azure. Это потребует потоковой передачи данных из разных
SAP-систем (например, S4 и более старых версий) в процессе преобразования.
Консолидируя и обрабатывая данные в SAP (где эта задача упрощается доступными метамоделями и технологией SAP), мы затем можем извлечь уточненные
представления для аналитики на нашей платформе Azure. Такой подход значительно упростит процесс интеграции и загрузки.
Питхейн Стренгхольт: Что происходит на первом уровне загрузки: вы сохраняете
данные как есть, используя исходный формат файла, или же применяете к данным
преобразования (например, преобразование к формату Delta)?
1

Учетная запись хранения (Storage Account) в Azure — это административный контейнер, который объединяет различные службы хранения данных: BLOB-объекты, файлы,
очереди, таблицы и диски.

  

316

Глава 10. Пример: стратегические преобразования данных в ZEISS

Саша Сомер: На первом уровне мы обычно сохраняем данные в том виде, в каком они к нам поступили, без применения преобразований. Может возникнуть
необходимость в незначительных технических корректировках, например, если
имя столбца содержит специальные символы, которые нельзя сохранить в неизменном виде. Тем не менее это исключения. В идеале мы поддерживаем данные как
можно ближе к исходной форме, чтобы сохранить независимость от источника;
это может быть полезно для таких операций, как перезагрузка данных. Обычно
данные хранятся в таких форматах, как файлы JSON. Преобразования — проверка
соответствия типов данных, изменение структур данных, деструктуризация —
применяются на последующих уровнях.
Питхейн Стренгхольт: Перейдем к серебряному уровню. Какие операции здесь
обычно выполняются?
Саша Сомер: На серебряном уровне обычно решаются такие задачи, как изменение типа данных или преобразование формата от многих мелких файлов JSON
к большим, более компактным файлам. Также здесь выполняется очистка данных
и модификация схем. Например, может попасться столбец, в котором хранятся
данные измерений, а каждая ячейка содержит XML с переменным количеством
измерений и структур. На серебряном уровне такие данные стандартизируются
созданием правильно структурированного формата.
Питхейн Стренгхольт: Объединяете ли вы данные из разных источников на
серебряном уровне?
Саша Сомер: Хороший вопрос. Если рассматривать все 30 посадочных зон, я бы
сказал, что объединение данных из разных источников в основном происходит
на золотом уровне. В некоторых ситуациях может возникнуть необходимость
в выполнении отображения данных на серебряном уровне, но обычно такие интеграции выполняются на поздней стадии.
Питхейн Стренгхольт: А как вы управляете историзацией данных? Например,
партиционированием данных или обработкой их в SCD?
Саша Сомер: В некоторых посадочных зонах мы используем SCD, обычно
типа 2, где просто добавляем новые записи для сохранения истории. Что касается
историзации, многие зоны ограничиваются хранением только новейшей версии
данных на серебряном уровне. Однако в других посадочных зонах, где должен
храниться полный исторический протокол, мы сохраняем всю историю на сереб­
ряном уровне, а иногда даже на золотом. Это особенно полезно, когда требуется
проанализировать, как данные изменялись со временем.
Питхейн Стренгхольт: Переходим на золотой уровень. Какие процессы происходят здесь?
Саша Сомер: На золотом уровне мы обычно концентрируемся на интеграции
нескольких источников данных. Здесь выполняются такие задачи, как соединение данных, вычисление ключевых показателей производительности (KPI)

  

Продукты данных и обмен данными

317

и выполнение исходных агрегаций. Мы также создаем представления разных
подмножеств сырых данных для управления разрешениями доступа и упрощения виртуализации. В общем случае средства получения информации, такие как
Microsoft Power BI, подключаются к золотому уровню для визуализации данных.
Питхейн Стренгхольт: Представления, создаваемые на золотом уровне, предназначены для семантических уровней? И в Power BI в основном используется
режим Import?
Герт Кристен: С золотым уровнем может быть довольно сложно. Как вы уже
знаете, мы в основном реализуем архитектуру медальона на нашей главной
платформе сетки данных eVA 3.0. Тем не менее сейчас ведется дискуссия о том,
действительно ли продукты данных, которые мы публикуем и делаем доступными для потребления в eVA 3.0, принадлежат золотому уровню или они должны
классифицироваться на серебряном. Это обусловлено значительным объемом
моделирования на стороне Power BI, вследствие чего эти модели также можно
размещать на золотом уровне. Следовательно, границы между уровнями могут
размываться. Но да, мы в основном используем в Power BI режим Import. Кроме
того, мы применяем прямые сценарии запросов там, где требуется доступ к данным в реальном времени или когда мы работаем с очень большими моделями
данных.

Продукты данных и обмен данными
Питхейн Стренгхольт: Можете ли вы объяснить концепцию продукта данных
и свое видение этой концепции?
Маркус Моргнер: Упрощенно говоря, продукт данных — нечто, служащее конкретной цели, напрямую связанное с практической ценностью или конкретным
сценарием использования. Технические реализации продукта данных могут быть
разными: дашборд, API, таблица и т. д. Принципиально здесь то, что он служит
определенной цели и в идеале добавляет практическую ценность. И хотя мы используем эту схему не везде, нашей целью является связывание OKR с каждым
продуктом данных для отслеживания его эффективности и влияния.
Питхейн Стренгхольт: Как организовано совместное использование данных
между командами? Можете рассказать подробнее?
Саша Сомер: Тема совместного использования данных между командами всегда
вызывает живой интерес. У нас еще нет полностью завершенной концепции, но
мы активно работаем над ней. В настоящее время метод совместного использования зависит от конкретного сценария и применяемой технологии. Например,
в классическом пакетном сценарии, когда обмен данными происходит каждую
ночь, доступны как push-, так и pull-варианты. Команды могут получать данные
от эндпоинтов средствами SQL или REST API, или мы можем отправлять им
данные, обычно в файлах бэкенд-формата.

  

318

Глава 10. Пример: стратегические преобразования данных в ZEISS

В сценариях реального времени мы часто создаем подписки на обновления данных, когда команды получают много мелких обновлений в виде событий вместо
одного большого пакета.
Технически мы часто используем Microsoft Purview для управления подключениями и подписками. В сценариях, специфических для Azure Databricks, мы
применяем Unity Catalog для организации совместного доступа к ресурсам из
нескольких экземпляров или посадочных зон данных. Такой подход обеспечивает
гибкость и адаптируемость наших процессов совместного использования данных.
Питхейн Стренгхольт: Вы упоминали два каталога: Unity Catalog и Microsoft
Purview. Они интегрированы друг с другом?
Саша Сомер: Вообще говоря, все сложнее. В настоящее время мы используем три
каталога. Корпоративный каталог данных будет работать на базе Collibra. Ранее
мы использовали Informatica, но каталог на базе Collibra еще в разработке и не
готов к эксплуатации. Мы использовали Microsoft Purview для некоторых задач
управления на нашей платформе и Unity Catalog конкретно для задач, связанных
с Databricks. Пока у нас нет интеграции ни между Purview и Unity Catalog, ни
между Purview и Collibra, хотя она планируется.
Герт Кристен: И даже это еще не все. Помимо согласованных с источником
и агрегированных доменов eVA 3.0, мы используем домены, ориентированные
на потребителя, как это происходит на стороне Power BI. Передача данных из
продуктов данных eVA 3.0 в Power BI в настоящее время осуществляется через
шлюз, потому что наши продукты данных в eVA 3.0 снабжены защитой VNET,
и Power BI не сможет обратиться к ним иначе.
С помощью Power BI и будущей версии Microsoft Fabric мы запускаем Fabric
Catalog. Этот встроенный каталог охватывает весь функционал Fabric и вводит
средства обнаружения и обмена данными.
Для улучшения организации данных мы исследуем схему «каталог каталогов».
В настоящее время нашим основным каталогом является Collibra, который мы
собираемся интегрировать с Unity Catalog, Fabric Catalog и любыми будущими
каталогами. Эта интеграция еще не завершена.
Питхейн Стренгхольт: Ранее вы упоминали о совместном использовании данных.
Я слышал, что в некоторых компаниях для совместного использования данных
между доменами или платформами применяются контракты данных. Вы также
реализуете этот подход?
Саша Сомер: Мы рассматривали контракты данных на концептуальном уровне
и провели ряд экспериментов, но они не реализованы или не используются. Это
то, что мы планируем сделать, но еще не сделали.
Питхейн Стренгхольт: Допустим, вы вернулись в прошлое, зная нынешнее
положение дел. Что бы вы сделали иначе? А может, вы ожидаете улучшений
в будущем?

  

Рекомендации и лучшие практики

319

Маркус Моргнер: Мы стремимся к улучшению каталога данных, интегрируя
различные репозитории метаданных и организуя данные разных платформенных
областей в каталог каталогов. Единый бизнес-каталог предоставляет полную
видимость всех ресурсов данных, принадлежности, преобразований и происхождения для всех экземпляров платформ. Он также упрощает запросы авторизации,
управления доступом и связь с бизнес-глоссарием, таким образом повышая прозрачность и наблюдаемость в нашей вселенной данных. Эти изменения принципиальны, так как SAP остается основным источником данных и продолжит им
оставаться в будущем.
Питхейн Стренгхольт: Существует ли интеграция преобразований данных со
средствами моделирования данных?
Маркус Моргнер: Да, мы исследовали возможности интеграции моделирования
данных, особенно через общие модели данных. Мы экспериментировали в конкретных областях, например в секторе устройств, где стремились к консолидации
разных источников данных в единую модель. Это позволило бы нам обращаться
ко всем данным в одном месте независимо от того, поступили ли они из SAP CRM,
Salesforce или напрямую от устройств. Тем не менее создание общей модели данных остается сложной задачей, и мы еще не достигли желаемого в полной мере.
Работа в этой области продолжается.

Рекомендации и лучшие практики
Питхейн Стренгхольт: Будут ли у вас рекомендации для читателей книги?
Маркус Моргнер: Когда мы изначально принимали принципы сетки данных, мы
сознавали важность управления данными, но нам не хватало возможностей для
его полноценной реализации. Мы начали с технологий, но, возможно, это было
преждевременно. Теперь мы видим необходимость вернуться назад, потому что
управление данными требует четкого разделения обязанностей, определения
ролей и ответственности, а также концептуального фреймворка выделения и детализации доменов (slicing and dicing) и распределения ответственности.
Также важную роль играет такое определение политик (наряду с их автоматизацией), чтобы они отвечали темпам разработки платформы. Изначально у нас
были хорошие политики «на бумаге», и все были согласны с тем, как должно
происходить поступление и использование данных. Однако нам не хватало технических средств для обеспечения этих политик в реальных условиях, и именно
здесь контракты данных будут очень важны. Контракты данных на техническом
уровне определяют, что разрешено делать с данными, что должен делать продукт
данных, когда должно происходить шифрование или удаление данных и на какой
уровень качества можно рассчитывать.
Мы стремимся автоматизировать эти определения вместе с интеграцией каталога
данных, хотя для этого могут понадобиться дополнительные компоненты, так

  

320

Глава 10. Пример: стратегические преобразования данных в ZEISS

как каталог данных может только ссылаться на контракт данных, но не строить
его. Автоматизация этих политик чрезвычайно важна для обеспечения текущего
контроля соблюдения стандартов и проверок обработки данных.
Читателям, рассматривающим решение с сеткой данных, я не рекомендую с ходу
браться за эту технологию. Составьте полное представление, установите четкие
границы и убедитесь, что все хорошо продумано. Помните: единого решения на
все случаи не существует. Вы должны оценить специфические потребности своей
организации и сформировать собственный план адаптации этого решения.
Питхейн Стренгхольт: Герт, вы что-нибудь порекомендуете читателям по поводу
Power BI, отчетов и семантических моделей? Какие лучшие практики вы предложите?
Герт Кристен: Откровенно говоря, конкретных рекомендаций у меня немного,
поскольку развитие Power BI в нашей компании шло от концепции самообслуживания. Обычно в ней задействуются небольшие подразделения и аналитики
данных, которые не всегда хорошо разбираются в сложных архитектурах. Они
могут применять некоторые практики, не рассматривая их как часть формальной
архитектуры, такой как медальон.
Однако картина меняется с появлением Fabric. Теоретически Fabric позволяет
создавать сквозные сценарии. В нашем контексте для операций, ориентированных
на источники, и операций агрегатных доменов используется eVA 3.0, наша сетка
данных Azure. Это означает, что базовые продукты данных, уже находящиеся на
бронзовом и серебряном уровнях, а возможно и на золотом, создаются именно
здесь. Соответственно, мы позиционировали Fabric для стороны, ориентированной на потребителя, где могли потребоваться дополнительные преобразования
для отчетов, ИИ или других целей. Стоит заметить, что Microsoft Fabric только
вступает в фазу «ограниченного релиза», а полнофункциональный выпуск ожидается во второй половине 2025 года.
Кроме того, мы еще не пришли к однозначному мнению, насколько необходимо
данным, уже находящимся на серебряном уровне, снова проходить через все три
уровня на стороне потребителя. Мы выясняем, будет ли достаточно процесса из
двух этапов: использования уже курируемых продуктов данных, применения
преобразований и прямого перехода на золотой уровень, так что бронзовый
фактически пропускается.
Питхейн Стренгхольт: Саша, поделитесь своими соображениями о процессе
с множественными средами и его отношении к управлению данными на бронзовом, серебряном и золотом уровнях в крупных организациях, таких как ваша.
Саша Сомер: Работая в крупной компании, мы часто сталкиваемся с тем, что необходимо пройти несколько этапов, прежде чем будет достигнута сквозная среда. Такое прохождение может начинаться с посадочной зоны данных, ориентированной
на источник, из которой мы извлекаем данные, а затем снова запускаем процесс.

  

Рекомендации и лучшие практики

321

Мы постоянно сталкиваемся с вопросом: насколько часто нужно реализовывать
бронзовый, серебряный и золотой уровни в цепочке общего потока данных?
Тут есть ряд более общих соображений. Важный момент — баланс между стандартизацией, с одной стороны, и гибкостью/настраиваемостью — с другой. Когда мы
пытаемся заставить всех следовать определенным стандартам, всегда существует
потребность в нестандартных решениях. Это приводит к бесконечным спорам
о том, до какой степени следует навязывать стандарты, особенно в областях не
настолько очевидных, как безопасность, где необходимость соблюдения стандартов выражена более четко.
Другой ключевой вопрос — самообслуживание. Мы как платформа стремимся
автоматизировать распространенные сценарии и сделать их доступными для самообслуживания. Однако очень важно регулярно пересматривать эти допущения
и проверять, соответствуют ли они фактическому использованию. В крупных
организациях, как наша, реализация самообслуживания затрудняется зависимостями от других подразделений или областей, которые могут еще не работать
в режиме самообслуживания. Это может заметно усложнить его реализацию.
Питхейн Стренгхольт: Герт, можете ли вы подробнее описать проблемы, связанные с управлением данными, особенно с платформой eVA и Fabric?
Герт Кристен: Безусловно, мы сталкиваемся со значительными проблемами
управления данными. На стороне платформы eVA мы сформировали надежную
исходную схему управления данными. Она включает связывание команд с группами безопасности, контроля за соблюдением стандартов и конфиденциальности
данных, обеспечивая хорошо управляемую конфигурацию на начальных этапах.
Тем не менее в ходе эволюции среды возникают проблемы. После первой установки люди начинают добавлять новые элементы, и пока у нас нет четкой концепции
для управления этими текущими изменениями в eVA 3.0 или Fabric.
Сложность Fabric растет, потому что она предоставляет пользователям большую
степень свободы. Пользователи могут начать с простых задач получения отчетов
и постепенно переходить к более сложным процессам (например, машинное
обу­чение). Обнаруживать такие переходы и выполняемые действия становится
труднее.
В обоих сценариях становится важна (а также рекомендуется в литературе о сетках данных) концепция вычислительного управления данными. Она подразумевает наличие механизмов сканирования и мониторинга того, что происходит на
платформе, и выявление любых нежелательных закономерностей. К сожалению,
в настоящее время нам не хватает полномочий для полноценной реализации такого уровня управления данными. Необходимо найти промежуточные решения на то
время, пока мы не сможем провести полную разработку этой функциональности.
Питхейн Стренгхольт: Можно ли в итоге сказать, что ваша стратегия позволяет
разрабатывать продукты данных до серебряного уровня или даже золотого?

  

322

Глава 10. Пример: стратегические преобразования данных в ZEISS

В сущности, команды обеспечивают поступление больших корпоративных
данных на платформу eVA 3.0 и переход к разработке и публикации продуктов
данных в доменах, ориентированных на источник, и агрегированных доменах. Для
доменов, ориентированных на потребителя, существует гибкость для использования либо eVA 3.0, либо Fabric. В такой конфигурации продукты данных eVA
3.0 должны служить источником. Насколько точно эта формулировка отражает
ваш подход?
Герт Кристен: Да, все верно. В отношении управления данными мы совершенствуем и проясняем терминологию. Изначально существовало различие между
продуктами данных и ресурсами данных, но теперь мы используем термин «продукт данных» во всех случаях. Сейчас мы работаем над определением глобальных
и локальных продуктов данных.
Глобальные продукты данных предназначены для передачи в масштабах всей
компании, они требуют жесткого управления, потому что влияют на всё. Они
согласуются с действиями, ориентированными на источник, и действиями агрегатных доменов на стороне платформы eVA Player. Прямое размещение данных
предприятия в Fabric не считается желательным паттерном. Тем не менее оно может встречаться с меньшими и/или редко используемыми источниками данных,
где внедрение данных через eVA 3.0 и организация совместного использования
данных не принесут никакой пользы.
А локальные продукты данных могут использоваться малыми подразделениями
для внутренних отчетов и не требуют жесткого централизованного управления.
В таком случае мы допускаем федеративное управление для локальных продуктов
данных, которые совместно используются в рамках отдела или бизнес-юнита.
Таким образом сокращается необходимость централизованного вмешательства.
Питхейн Стренгхольт: Спасибо за ваши ответы. Ваши наблюдения и практический опыт будут очень полезны для наших читателей. Я благодарен за ваше время
и за ваши подробные объяснения.
Маркус Моргнер: Спасибо за возможность поделиться тем, что мы узнали в ходе
нашего пути. Надеемся, наш опыт поможет другим разобраться в сложностях
управления данными.

Часть IV
Масштабирование, управление
данными и будущее
архитектур медальона

Организациям, стремящимся к удовлетворению растущих потребностей при
сохранении контроля за их средами данных, очень важно понимать сложности
масштабирования и управления данными в архитектуре медальона. Многие организации находят эти области особенно сложными, однако их освоение крайне
важно для стабильного роста бизнеса и комплаенса. Четвертая часть книги,
построенная на основе ранее рассмотренных концепций (например, доменов
и продуктов данных), содержит более детальную информацию и практические
решения для создания масштабируемых, безопасных и перспективных архитектур медальона.
Глава 11 предоставляет подробное руководство по эффективному масштабированию архитектур медальона и управлению несколькими экземплярами в пределах
одной организации. В ней рассматриваются лучшие практики, типичные ловушки
и стратегии, позволяющие архитектурам расти вместе с компанией.
В главе 12 рассматриваются важнейшие вопросы управления данными и безо­
пасности в архитектуре медальона. В ней исследуются вызовы и возможности
реализации надежного управления данными и мер безопасности для защиты
ресурсов данных и обеспечения комплаенса.
Глава 13 посвящена будущему архитектур медальона, особенно в контексте
генеративного искусственного интеллекта. Она завершается размышлениями
касательно вопросов эволюции ландшафта архитектур данных.

ГЛАВА 11

Масштабирование
архитектур медальона
В первой и второй частях книги мы занимались созданием единственной архитектуры медальона. Тем не менее в реальных условиях организации часто управляют
несколькими такими архитектурами, чтобы удовлетворять разнообразные потребности разных команд и доменов данных. С этим согласится каждый, кто имеет практический опыт корпоративного проектирования. С ростом организации приходится
масштабировать систему управления данными, чтобы она поддерживала больше
данных, больше пользователей и больше разнообразных сценариев использования.
По этой причине в организациях часто применяются децентрализованные архитектуры вместо централизованного решения «на все случаи жизни».
Однако с таким положением дел согласны не все. Некоторые эксперты выступают
за полную децентрализацию всех аспектов технологии, организации и управления данными, хотя это решение не всегда будет лучшим. Децентрализация
создает свои сложности, особенно в управлении процессами и в наблюдении.
Важно выдержать правильный баланс, так как степень централизации зависит от
организации. Чтобы глубже изучить эту тему, рассмотрим следующие вопросы:
1. Масштабирование через децентрализованное управление данными с использованием нескольких архитектур медальона.
2. Масштабирование через вариации внутренних архитектур медальона, включающее такие темы, как управление мастер-данными (MDM) и корпоративные
модели данных.
К концу этой главы вы станете хорошо понимать, как эффективно масштабировать архитектуру медальона и управлять несколькими архитектурами медальона
в пределах одной организации. Это подготовит вас к главе 12, где будут рассматриваться темы управления данными, контрактов данных и безопасности данных
в федеративной архитектуре.

Децентрализация управления данными
В главах 1 и 6 была представлена концепция сетки данных. Этот паттерн проектирования концентрируется вокруг децентрализации владения данных

  

Децентрализация управления данными

325

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

Централизованная модель
Операционные
системы

Задачи
загрузки

Промежуточное
хранение

Очистка и
преобразование

Продукт
данных

Совместное
использование

Практическое
использование

Совместное
использование

Практическое
использование

Операции смещаются в бизнес-домен

Операционные
системы

Задачи
загрузки

Промежуточное
хранение

Очистка и
преобразование

Федеративная модель

Продукт
данных

Бизнес

Центральный IT-отдел

Рис. 11.1. Реализация сетки данных подразумевает перенос ответственности с центрального IT-отдела
на бизнес-юниты
В верхней части рис. 11.1 изображена традиционная модель централизованных
операций. Центральный IT-отдел управляет всеми стадиями управления данными, включая контроль операционных систем, задачи загрузки, промежуточное
хранение, очистку, преобразования данных, производство продуктов данных
и совместное использование. В этом случае бизнес отвечает только за использование данных.
В нижней части рис. 11.1 представлена федеративная модель, воплощающая сущность сетки данных. В этой модели бизнес-юниты, или бизнес-домены, получают
больше ответственности, особенно в задачах загрузки, промежуточного хранения,
очистки, преобразования данных и создания продуктов данных. Центральный ITотдел все еще играет важную роль, но его работа направлена на сопровождение
сложных операционных систем и предоставление централизованных сервисов
управления данными бизнес-доменам. Такая структура предоставляет бизнесдоменам инструменты, необходимые для управления данными как продуктом.

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

  

326

Глава 11. Масштабирование архитектур медальона
Этот материал отчасти повторяет другую книгу, написанную мной. Если вам
будет интересна общая картина, обратитесь к книге «Data Management at
Scale», 2-е изд.1 (O’Reilly).

Степень федеративности между бизнес-доменами в пределах одной организации
может изменяться. Не все бизнес-домены могут управлять своими данными на
одном уровне независимости. Кому-то может понадобиться больше поддержки
от центрального IT-отдела, другие могут быть более самодостаточными.
Резюме: сетка данных не должна рассматриваться как жесткая концепция; это
набор возможностей, адаптируемых к уникальным обстоятельствам, влияющим
на дизайн архитектуры данных. Что это означает для архитектуры медальона?
Давайте разберемся.

Сетка медальона (medallion mesh)
Со временем концепция сетки данных набирала популярность, рыночные тренды
смещались, и компании-разработчики это заметили. Провайдеры технологий начали корректировать свои стратегии и приводить их в соответствие с принципами
сетки данных, разрабатывая инструменты и платформы, поддерживающие децентрализованное управление данными. Это изменение стимулировало инновации
в управлении данными и совместимости, упрощая совместное использование
и управление данными для разных бизнес-доменов. Например, такие платформы
данных, как Azure Databricks и Microsoft Fabric, приняли принципы сетки данных
и дали возможность командам доменов независимо управлять своими данными
с использованием конкретных доменов и рабочих пространств.
В архитектуре медальона применение принципов сетки данных может помочь
масштабировать архитектуру между разными бизнес-доменами, командами или
доменами данных. Принимая концепцию сеток, организации могут развертывать
разные платформы данных, адаптированные к конкретным потребностям бизнеса
при поддержании централизованного управления данными. Пример представлен
на рис. 11.2.
Изучим эту схему. Говоря о сетке медальона (medallion mesh)2, мы подразумеваем
сетку архитектур медальона в пределах одной организации, способных обмениваться данными друг с другом. В такой конфигурации несколько команд работают
параллельно, при этом каждая команда управляет собственной архитектурой
медальона с тремя классическими уровнями: бронзовым, серебряным и золотым.
В этом контексте использование Unity Catalog (паттерн 1 на рис. 11.2) и Delta
1

2

Стренгхольт П. «Масштабируемые данные. Высоконагруженные архитектуры, Data
Mesh и Data Fabric». 2-е изд.
Термин «сетка медальона» был предложен Франко Патано (Franco Patano) и описан
в статье The Emergence of the Medallion Mesh (https://oreil.ly/nFHtn).

  

Децентрализация управления данными

327

Share (паттерн 2 на рис. 11.2) считается лучшей практикой для организации совместного доступа к данным между средами Azure Databricks.
Azure Databricks Workspace #3
Unity
Catalog

Операционные
системы
Посадочная
зона
(CSV, JSON,
Parquet и т. д.)

Azure Databricks

Third party
consumers

(non-Databricks)

Azure
Databricks
Workspace #1

Бронзовый

Серебря- Золотой
ный

Azure Databricks Workspace #2

2
Delta
share
1

Совместный
ресурс Delta
(внешний)

Azure Databricks

Azure Databricks
Unity Catalog

Рабочее
пространство
Azure
Databricks

Бронзовый

Серебря- Золотой
ный

Бронзовый

Серебря- Золотой
ный

Рис. 11.2. Сетка медальона с использованием Azure Databricks
Microsoft Fabric позволяет создать сеть из нескольких архитектур медальона,
где каждый домен имеет собственную архитектуру медальона с логическим
озером данных. Такие логические озера хранятся вместе в общей сущности
OneLake, что дает множество преимуществ, например улучшенное управление
данными и упрощенное совместное использование данных. Такая структура
отличается от «чистой» сетки данных, где каждый домен имеет собственную
инфраструктуру.

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

  

328

Глава 11. Масштабирование архитектур медальона

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

Количество архитектур медальона
При планировании масштабируемости необходимо четко определить границы, или «разграничительные линии», в архитектуре, включая количество
доменов и экземпляров платформ. В данном случае экземпляр платформы
подразумевает одно развертывание, основанное на архитектуре медальона.
Эти элементы должны быть хорошо согласованы, чтобы домены и платформы
не перекрывались. Без полной ясности относительно архитектуры вы своими
руками создаете хаос и долгие споры касательно количества платформ, принципов архитектуры и т. п.
Типичный вопрос, часто встречающийся на начальной стадии — сколько доменов
и архитектур медальона следует использовать. В этом контексте под «доменом»
понимается бизнес-юнит или конкретная предметная область внутри организации. Подробнее см. во врезке «Неоднозначное понятие “домен”» в главе 7, с. 254.
А пока будем считать, что каждый домен поддерживает собственную архитектуру
медальона, управление которой осуществляется в выделенном рабочем пространстве — логическом контейнере в рамках общей платформы данных. Неочевидные
следствия этого предположения будут рассмотрены позже, когда мы займемся
внутренней архитектурой.
Количество требуемых архитектур медальона зависит от многих факторов. Единственно правильного ответа не существует, так как количество доменов может
сильно зависеть от размера организации, ее структуры, зрелости и потребности
в данных. Вот ряд факторов, которые необходимо учитывать:
Размер организации
Размер организации и количество доменов играют очень важную роль для
определения количества необходимых архитектур медальона и рабочих пространств. Например, очень маленькой организации с небольшим штатом инженеров обычно хватает одной архитектуры медальона и нескольких рабочих
пространств для разработки, тестирования и эксплуатации.
Более крупной организации может понадобиться центральный домен для
управления всеми пайплайнами загрузки и интеграции, а также несколько
отдельных доменов для разных бизнес-юнитов или проектов. Такой сценарий
может потребовать нескольких архитектур медальона.
Очень большая организация может определить домен для каждого бизнесюнита или проекта, а также несколько доменов для общих сервисов (например, MDM), корпоративных данных с централизованным управлением и т. д.
В этом случае могут потребоваться множественные архитектуры медальона.

  

Децентрализация управления данными

329

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

Зрелость организации
Зрелость организации влияет на размер и количество ее доменов. Для более
зрелых организаций характерно большое количество малых, более специализированных доменов. Такие организации уже уточнили свои процессы и системы,
что позволяет им разбить операции по конкретным предметным областям.
Специализация означает, что границы точно определяются, а количество
систем и приложений в них уменьшается. В таком случае каждая команда
приложения может обеспечивать работу собственной архитектуры медальона,
а каждый домен концентрируется на конкретной предметной области.
В менее зрелых организациях может использоваться меньшее количество
более крупных доменов. Такие расширенные домены из-за менее развитой
структуры часто охватывают несколько функций или областей. Как следствие,
они включают больше контекста. В таком случае можно наблюдать меньшее
количество архитектур медальона, соответствующих большим доменам. С ростом и становлением таких организаций большие домены часто разбиваются
на более мелкие и более целенаправленные, что повышает эффективность
управления данными и эксплуатации.
Требования к безопасности и комплаенсу
Разные отделы могут подчиняться разным нормативным требованиям, которые делают необходимым более жесткое управление данными. Это может
привести к созданию отдельных доменов, обеспечивающих выполнение
нормативов.
Отслеживание затрат и бюджетирование
Отдельные рабочие пространства способствуют более точному отслеживанию
и распределению затрат по конкретным отделам и проектам. Таким образом,
если контроль бюджета и распределение затрат относятся к числу основных
приоритетов, можно подумать над созданием отдельных рабочих пространств.
Здесь фокус сдвигается с количества архитектур медальона на разбиение
архитектуры на меньшие блоки для повышения эффективности контроля за
бюджетом и затратами.
Исследования и разработки
Если ваша организация уделяет значительное внимание исследованиям, разработке, обнаружению данных и прототипированию, вам могут понадобиться

  

330

Глава 11. Масштабирование архитектур медальона

разные рабочие пространства для разных исследовательских проектов. Такое
разделение помогает поддерживать целостность данных и предотвращать нежелательные перемещения или интеграции данных между проектами. Существуют разные способы реализации этого паттерна, что потенциально может
привести к увеличению количества архитектур медальона.
Региональные границы
Если ваша организация работает в нескольких регионах, вам могут понадобиться разные домены и рабочие пространства для всех регионов. Часто это
происходит по двум причинам: 1) ради соблюдения местных нормативов, относящихся к данным, и обеспечения суверенности данных; 2) чтобы данные
обрабатывались и хранились вблизи от места их использования для сокращения задержки и повышения производительности.
Количество доменов в организации не задается раз и навсегда; оно должно органически эволюционировать в зависимости от изменяющихся потребностей и роста организации. Вы должны управлять эволюцией. Действуйте целесообразно
и увеличивайте это количество по мере необходимости. Ваша цель — развитие,
а не совершенство. Это означает, что архитектура будет эволюционировать по
мере появления новых требований и зрелости организации.
При слишком быстром росте вы, скорее всего, столкнетесь с некоторыми препятствиями, потому что затраты, разрастание технологий и трудоемкие процессы
выйдут из-под контроля. Кроме того, существует центральный полномочный
орган — центральная команда, которая осуществляет надзор и устанавливает
стандарты и рекомендации для доменов и рабочих пространств, следя за тем,
чтобы они сочетались с общей стратегией данных и архитектурой организации.
Помимо этого, очень важно, чтобы в процессе роста поддерживалась оптимальная
производительность, эффективность затрат и соответствие нормативам. Управление данными и автоматизация являются ключевыми условиями управления
сложностью. Мы вернемся к ним позднее в этой главе.
Из сказанного в предыдущих разделах можно сделать вывод, что количество
и размеры доменов могут значительно различаться между организациями. Одни
стремятся к множеству зрелых и детализированных доменов, другие довольствуются несколькими более крупными. Выбор влияет на общий дизайн архитектуры
и количество требуемых архитектур медальона. Проблема в том, чтобы найти
баланс, соответствующий потребностям своей организации.
Чтобы расширить понимание сеток данных и подробнее поговорить об определении количества доменов, перейдем к особенностям, упомянутым выше, и исследуем способы адаптации архитектур медальона к различным средам.

  

Разновидности внутренней архитектуры медальона

331

Разновидности внутренней архитектуры медальона
В следующих разделах рассматриваются различные способы масштабирования
архитектур медальона, основанные на вариациях внутренней архитектуры. Начнем с масштабирования архитектуры, а именно с масштабирования архитектуры
посредством реализации специального уровня для управления продуктами данных. Затем мы изучим вариации медальона, включая модели, ориентированные
на провайдера и на потребителя, конгломератные бронзовые модели и дополнительные золотые уровни для конкретных сценариев и потребителей. Мы также
обсудим управление архитектурой медальона с использованием моделирования
данных предприятия и MDM. К концу этого раздела вы убедитесь, что масштабирование не сводится к добавлению новых архитектур или уровней; его суть
в том, чтобы найти нужные компоненты. За дело!

Отдельные уровни продуктов данных
Децентрализованная модель влияет на модель данных, превращая ее в модель
интерфейса, — то, что сейчас называется продуктами данных. Чтобы это превращение прошло успешно, необходимо обратить внимание на моделирование
данных, их качество и управление ими. Описание лучших практик и факторов,
которые необходимо учитывать, см. в разделе «Продукты данных» главы 7, с. 250.
Чтобы преобразовать модель данных в модель интерфейса, возьмем для примера
сценарий, где несколько доменных команд являются владельцами своих рабочих
приложений и аналитических данных. Каждая команда обеспечивает загрузку
данных, обработку и курирование продуктов данных. Чтобы масштабировать
архитектуру медальона в таких условиях, можно добавить уровень, предназначенный для проектирования и распространения продуктов данных. Дополнительный уровень помогает разграничить внутреннее потребление данных команды
от данных, используемых совместно с другими командами, — принципиальное
отличие, так как повторно используемые, обобщенные продукты данных часто
не удовлетворяют конкретным требованиям практических сценариев. Пример
такого рода представлен на рис. 11.3.
В практическом плане в архитектуре медальона это может означать разбиение
серебряного или золотого уровня на два отдельных уровня. Один занимается
стабильными данными продуктов данных, которые обычно тщательно каталогизируются и передаются другим командам и у которых всегда имеется владелец.
Другой уровень управляет динамическими данными конкретных доменов или
сценариев, используемыми приложениями команды. Такое разбиение, часто
встречающееся в более зрелых организациях, позволяет командам независимо
управлять своими продуктами данных, при этом не теряя согласованности с основными принципами архитектуры медальона.

  

332

Глава 11. Масштабирование архитектур медальона

Microsoft Fabric Workspace
Инженерия данных Synapse
Отдельный
уровень для
продуктов
данных

Уровень
продуктов
данных
работает
как бронзовый

Workspace

Серебряный

Золотой

Workspace

Отдельный
уровень для
продуктов
данных

Инженерия данных Synapse

Инженерия данных Synapse
Для
внутренних
потребителей

Бронзовый

Серебряный

Отдельный
уровень для
продуктов
данных

Золотой

Бронзовый

Нет
золотого уровня
из-за отсутствия
Серебрявнутренних
ный
потребителей

Рис. 11.3. В этой архитектуре на базе Microsoft Fabric для потребления используются два разных уровня:
сущность Lakehouse (золотой уровень) для данных конкретных сценариев и сущность Lakehouse (уровень
продуктов данных), представляющая данные, готовые для потребления из других доменов
Метаданные и стандарты совместимости, включая распространение открытых
табличных форматов, исключительно важны для распространения данных
в большом масштабе. Чтобы эффективно добиться этой цели, вам понадобятся надежные практики управления данными. Эти практики гарантируют,
что все домены в пределах организации будут придерживаться установленных
стандартов.

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

  

Разновидности внутренней архитектуры медальона

333

Адаптированные архитектуры медальона
Не все домены требуют одинаковой структуры уровней. Особенно в конфигурации сетки данных, где используются множественные архитектуры медальона,
требования к отдельным доменам могут значительно различаться. Требования
часто изменяются в диапазоне от потребности в сложных интеграциях и распространении до простого потребления данных.
В часто встречающемся сценарии создаются изолированные среды для разных
команд или бизнес-юнитов, которым нужно обращаться к данным, находящимся
под управлением других команд. Например, команда может использовать рабочее пространство, состоящее из одного уровня (одного озера-хранилища), с доступными только для чтения ссылками на данные, которыми управляет другая
команда. Пример такой конфигурации изображен на рис. 11.4 вместе с другими
вариантами, которые мы рассмотрим позже в этом разделе.
Другой интересный сценарий: возьмем две архитектуры медальона — одна адаптирована для системы-источника, другая для потребления. В этом случае очень
важным становится взаимодействие между уровнями. Можно возразить, что золотой уровень или уровень продуктов данных в архитектуре, ориентированной на
источник, фактически действует как бронзовый в архитектуре, ориентированной
на потребление. Такой подход создает более компактную архитектуру, устраняя
необходимость в дублировании уровня продуктов данных на бронзовом уровне
в конфигурации потребления.
Построить сложную архитектуру медальона на основе принципов сетки данных
может быть непросто, особенно при участии многих команд, каждая из которых
должна обращаться к данным других команд. В таких сценариях можно подумать
о создании для каждой команды отдельной архитектуры медальона с собственными бронзовым, серебряным и золотым уровнями. Для этого может быть полезно
спроектировать несколько шаблонов решений. Следующие примеры помогут
вам сориентироваться:
Провайдер простых данных
Если вы — провайдер данных с небольшим количеством источников и не
потребляете собственные данные в конкретных сценариях, то может хватить
всего двух или трех уровней (например, бронзового и уровня продуктов
данных).
Провайдер сложных данных для внутреннего использования
Провайдеру, который работает с множественными источниками, но использует полученные данные только для своих внутренних целей, может хватить
конфигурации с тремя или четырьмя уровнями (например, бронзовым, серебряным и золотым).

  

334

Глава 11. Масштабирование архитектур медальона

Провайдер простых данных
Workspace
Загрузка
Операционные
системы

Lakehouse
Bronze

Lakehouse
Silver

Lakehouse
Gold

Ссылки

Провайдер сложных данных для внутреннего использования
Workspace
Загрузка

Операционные
системы

Lakehouse
Bronze

Lakehouse
Silver

Lakehouse
Gold

Ссылки

Warehouse
Gold

Базовый потребитель
Lakehouse
Gold

Отчет

Basic consumer
Lakehouse
Silver

Lakehouse
Gold

Отчет

Потребитель-распространитель
Workspace
Lakehouse
Bronze

Lakehouse
Silver

Lakehouse
Gold

Ссылки

Warehouse
Gold

Рис. 11.4. Разные архитектурные стили: два базовых потребителя, простой провайдер простых данных,
провайдер сложных данных для внутреннего использования и потребитель

  

Разновидности внутренней архитектуры медальона

335

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

  

336

Глава 11. Масштабирование архитектур медальона

потребителей. Мы вернемся к этой концепции позже, в разделе «Корпоративные
модели данных», с. 339.
В другом сценарии процесс интеграции может оптимизироваться через модель делегирования, например, созданием Unity Catalog. В такой конфигурации каждый
домен, согласованный с его системами-источниками, создает продукты данных
в своем контексте, а затем перемещает их в отдельные каталоги. Кроме того, существует центральный каталог, который описывает, как эти локальные продукты
данных должны консолидироваться в гармонизированное представление. Такая
схема поддерживает модель делегирования, в которой домены-провайдеры сопоставляют свои локальные продукты данных с гармонизированными продуктами
данных с централизованным управлением, дополнительно упрощая управление
данными в пределах организации.
Во всех вариантах необходимо стандартизировать и формализировать эти паттерны проектирования, чтобы оптимизировать управление данными и повысить
качество данных в пределах организации. Я рекомендую предоставлять рекомендации по проектированию каждого паттерна решения, его структуре и управлению
продуктами данных, как упоминалось в разделе «Продукты данных» главы 7,
с. 250. Это поможет командам структурировать свои архитектуры и бесшовно
интегрировать продукты данных в разные варианты дизайна.
До сих пор мы говорили о масштабировании и проектировании архитектур медальона посредством добавления или удаления уровней. Однако эти архитектуры
можно масштабировать или оптимизировать и за счет вариаций на самих уровнях.

Адаптируемость бронзового уровня
Бронзовый уровень можно разделить для эффективного управления разными
потоками загрузки данных. Возьмем, например, разновидность бронзового
уровня, когда он работает как конгломерат пулов данных. В конфигурации на
базе Microsoft Fabric, показанной на рис. 11.5, разные сущности Lakehouse на
бронзовом уровне управляют разными пулами данных.
В этой модели разные паттерны загрузки данных работают параллельно. Вот
некоторые компоненты, показанные на рис. 11.5:
Ссылки
Для данных, не требующих глубокой обработки1, можно создать ссылки на
данные на бронзовом уровне. Такое решение хорошо работает для данных,
уже хранящихся в совместимом формате (например, Delta Lake или Iceberg)
и не нуждающихся в технических преобразованиях.

1

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

Amazon S3

Текущие
отчеты и
аналитика

Dataverse

Другие
области
хранения

Инженерия
данных Synapse

Ссылки

Загрузка
данных в
Data Factory

Серебряный
уровень

Золотой
уровень

Предоставление
данных
другим
доменам

Отчеты

Data
science

Бронзовый
уровень

Операционные
системы

SQL

Обработка

Инженерия
данных Synapse

Ссылки

Landing
area

Cosmo DB

Обработка

337

  

Разновидности внутренней архитектуры медальона

Репликация
данных
в реальном
времени

Оркестрация с использованием Data Factory

Snowflake
Базы или
хранилища
данных

Рис. 11.5. Бронзовый уровень работает как конгломерат сущностей Lakehouse, использующий физическое
копирование, ссылки и репликацию
Физические копии
В этом сценарии могут загружаться данные из разных источников на бронзовом уровне, в результате чего будут создаваться физические копии данных.
Такая конфигурация идеально подходит для данных, требующих глубокой
обработки или преобразований перед использованием на серебряном или
золотом уровне.
Репликация
Синхронизация в реальном времени (например, зеркалирование или
CDC) — еще один вариант для данных, которые необходимо реплицировать между доменами. Такая конфигурация гарантирует, что данные всегда
будут оставаться актуальными и доступными для использования в разных
приложениях.
В этом примере бронзовый уровень разделяется на разные пулы, которые соответствуют разным методам загрузки данных. Тем не менее также можно рассмотреть разбиение в соответствии с разными командами приложений. Представьте
сценарий, когда разные команды хотят загружать данные из разных источников
на бронзовом уровне большего домена, но у этих команд нет доступа к данным
других команд. В таком случае можно добавить на бронзовом уровне дополнительные сущности Lakehouse для управления загрузкой данных для каждой команды
по отдельности. Такая конфигурация гарантирует, что данные будут храниться

  

338

Глава 11. Масштабирование архитектур медальона

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

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

Вариации на золотом уровне
На золотом уровне создается ценность для бизнеса. Этот уровень можно адаптировать для удовлетворения конкретных бизнес-потребностей за счет добавления
вариаций. Например, некоторые организации могут добавлять дополнительные
уровни, чтобы упростить распределение данных между платформами или командами. В частности, это может включать выбор и предварительную фильтрацию данных
для конкретных сценариев и сохранение их на вновь созданных уровнях. Такой
подход уже встречался вам при обсуждении архитектуры AP Pension в главе 8.
Более того, если ваша организация требует разных политик управления для
разных типов данных, рассмотрите возможность разбиения золотого уровня на
несколько подуровней, каждый из которых имеет собственный набор политик.
Это особенно полезно в больших доменах, где, например, одна инженерная и бизнес-команда обеспечивает работу большой архитектуры медальона. Четкого распределения прав владения разными частями золотого уровня можно достичь за
счет разделения его на подуровни, каждый из которых находится под управлением
владельца, ответственного за качество данных, их безопасность и управление ими.

  

Разновидности внутренней архитектуры медальона

339

Эта модель обычно используется в крупных финансовых организациях, которым
необходимы отчеты о различных частях своего бизнеса при поддержании общей
модели данных. В большой команде важно установить понятные процессы,
каналы коммуникаций и провести обучение, чтобы все работали согласованно
и эффективно для достижения единых целей.
Золотые уровни особенно выделяются своим соблюдением общекорпоративных
стандартов. Несмотря на сложность и затраты времени в моделировании данных предприятия, многие организации внедряют ту или иную разновидность
гармонизации данных в масштабах предприятия для обеспечения возможности
многократного использования и стандартизации данных. Процесс организации
и управления данными с целью упрощения их интеграции также называется
курированием данных (data curation).

Корпоративные модели данных
В методе сетки медальона (medallion mesh) компании часто создают дополнительные домены для интеграции или курирования. Такие домены управляют
сложными и большими моделями данных для обеспечения стандартов масштаба
предприятия. Из этих доменов (данных) вновь созданные продукты данных распространяются на другие домены. Такой подход, часто называемый построением
агрегатов (по аналогии со сценарием потребителя-провайдера, рассмотренным
выше), помогает организациям эффективно масштабировать свои схемы управления данными. Кроме того, гибкость переключения между серебряным и золотым
уровнями и агрегатными уровнями в зависимости от конкретных потребностей
удобна для пользователей (см. схему на рис. 11.6).
Как правило, центральная команда либо управляет этими доменными агрегатами, либо осуществляет надзор за ними, занимаясь главным образом поддержкой
качества данных, их управлением и комплаенсом. Такие агрегаты не являются
готовыми к использованию продуктами данных для конкретных сценариев; их
основная роль — предварительная интеграция и распространение данных между
разными доменами. Это гарантирует, что все команды будут иметь доступ к одним и тем же качественным данным. Результат представляет собой аккуратно
организованный продукт данных, который бесшовно переходит в другие домены.
Стоит заметить, что таким доменом-потребителем даже могут быть доменыпроизводители в левой части схемы архитектуры (рис. 11.6). Такая стратегия
предотвращает дублирование усилий бизнес-юнитов и способствует оптимизации
процессов в компании.
Может возникнуть вопрос: как узнать, к каким данным следует применять предварительную интеграцию или агрегирование? как выдержать баланс, моделируя
только то, что действительно важно? В федеративной архитектуре с огромными
объемами данных задача определения того, какие данные пересекаются и должны
проходить предварительную интеграцию, может показаться устрашающей. Ниже
описан стратегический подход к ее решению.

  

340

Глава 11. Масштабирование архитектур медальона

Загрузка
Операционные
системы

Lakehouse
Bronze

Lakehouse
Silver

Ссылки

Lakehouse
Gold

Warehouse
Gold

Загрузка

Операционные
системы

Lakehouse
Bronze

Lakehouse
Silver

Ссылки

Lakehouse
Gold

Warehouse
Gold

Доменный агрегат

Lakehouse
Silver

Lakehouse
Gold

Потребитель

Lakehouse
Gold

Отчет

Ссылки

Потребитель

Lakehouse
Gold

Отчет

Рис. 11.6. Доменные агрегаты позволяют бизнес-юнитам выполнять бесшовную интеграцию
без дополнительных усилий
Сначала выявите самые важные домены данных и установите отношения между
ними и их нижележащими системами-источниками. Затем на ранней стадии пообщайтесь со стейкхолдерами, чтобы узнать, какие датасеты они часто используют
совместно. Это поможет вам назначить приоритеты интеграции в зависимости
от того, какие данные предоставляют наибольшую ценность при объединении,
например данные клиентов из разных источников или финансовые данные между
отделами.
Кроме того, используйте метаданные из каталога данных для отображения
и отслеживания паттернов использования данных. Это поможет выявить

  

Разновидности внутренней архитектуры медальона

341

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

Управление мастер-данными
Как MDM, так и курирование данных нацелено на оптимизацию использования
данных в крупных организациях. Для этого применяются такие распространенные методы, как ETL (Extract, Transform, Load), очистка данных, data science
и управление метаданными, а также отслеживание происхождения данных
и описание моделей данных. Однако у MDM есть особая задача — установить
единый, точный и авторитетный источник истины для ключевых бизнесданных, часто называемых мастер-данными. По сути, MDM — это практика
обеспечения качества данных, которая гарантирует, что все могут положиться
на согласованные и актуальные мастер-данные в различных системах и бизнесюнитах. Заметим, что в строго регулируемых отраслях (таких, как финансы
или здравоохранение) практика MDM имеет решающее значение для комплаенса и обеспечения точности данных. Таким образом, это необходимость,
а не опция.
В контексте множественных архитектур медальона метод MDM используется
особым образом. Он назначает конкретные домены, которые могут быть как
централизованными, так и децентрализованными, для управления гармонизированными (мастер-) сущностями. Затем другие домены используют эти стандартизированные сущности, которые обычно находятся на серебряном и золотом
уровнях. Схема процесса представлена на рис. 11.7.
В этой конфигурации Dynamics (система CRM) (https://oreil.ly/UVJyF), еще одна
система-источник и MDM взаимодействуют в экосистеме данных. Разобьем
процесс на этапы.
1. Доменные данные изначально извлекаются из разных систем-источников
(таких, как Dynamics) и поставляются в разные рабочие пространства. Затем
данные перемещаются по этапам — бронзовый, серебряный золотой уровни —
для обеспечения их качества и целостности. В более крупных архитектурах
домены обычно сами осуществляют этот процесс.

  

342

Глава 11. Масштабирование архитектур медальона
Шлюз
API
Брокер
событий

4

Отображение событий MDM
на формат доменных событий
Отображение
доменных событий
на входной формат MDM

Power
apps

Преобразование

1

2

Брокер
событий

Workspace

Dynamic 365

3
5

Dataverse

Bronze

Операционная
система #1

1
Операционная
система #2

Преобразование

Пакетная
обработка

Silver

Gold

MDM
system

Gold

Последующие
потребителианалитики

Workspace
Bronze

Silver

Gold

Рис. 11.7. Архитектура, поясняющая, как данные перемещаются между системами-источниками
и системой MDM
2. Dynamics и Power Apps (https://oreil.ly/N32JY) используют данные из Dataverse
(https://oreil.ly/F3rG0) — распространенного сервиса данных. Эти компоненты могут генерировать доменные события, которые затем преобразуются
к входному формату MDM перед отправкой в систему MDM. Этот паттерн
представляет собой поток данных в реальном времени между системами-источниками и системой MDM.
3. Система MDM хранит и обрабатывает данные от разных приложений. Она
консолидирует данные в одно унифицированное представление с использованием сложных алгоритмов слияния и поиска совпадений. Как правило, этой
системой управляет центральная команда.
4. Система MDM также может генерировать события по мере необходимости.
Эти события преобразуются к формату доменных событий, и их можно отправить обратно в Dynamics или использовать в других местах.
5. Наконец, высококачественные данные, обработанные системой MDM, совместно используются разными доменами. Таким образом, гарантируется, что
все стороны имеют доступ к согласованным и надежным данным.
По сути, мастер-данные, сгенерированные доменами MDM, возвращаются
в другие домены различными способами. Один из эффективных методов — распространение их в виде (мастер-) продуктов данных, как описано в главе 7. Для
этого стоит воспользоваться технологиями из архитектуры медальона.
Кроме того, передача этих очищенных и точных данных в исходную систему-источник значительно повышает их производительность. Это повторное

  

Разновидности внутренней архитектуры медальона

343

распространение, известное как паттерн «Сосуществование» (coexistence), часто
осуществляется через события или вызовы API, как показано на рис. 11.7. Такой
подход обеспечивает бесшовное сотрудничество между старыми и новыми системами, делая возможной плавную и эффективную цифровую трансформацию.

Управление референсными данными
В отличие от мастер-данных, референсными данными (reference data) можно
управлять в отдельных доменах, потому что эти данные не нужно сравнивать
между разными доменами. Референсные данные чрезвычайно важны для определения, классификации, упорядочения, группировки или разбиения на категории других типов данных. Они часто охватывают иерархии значений, например
отношения между типами продуктов и географическими регионами. Модели
авторизации пользователей часто используют референсные данные для определения прав доступа.
Чтобы гарантировать согласованность референсных данных между доменами,
команды должны синхронизировать свои процессы распространения данных
в каждой архитектуре медальона с референсными данными, управляемыми
централизованно. Типичные примеры — коды валют, коды стран и коды товаров,
которые могут централизованно публиковаться в MDM-системе. Использование
идентификаторов из референсных данных MDM для классификации или справки
чрезвычайно важно, когда домены распространяют свои продукты данных в других доменах. Такое соответствие позволяет другим доменам быстро распознавать
и интегрировать данные с референсными данными предприятия. Автоматизация
этой интеграции в архитектуре медальона гарантирует, что референсные данные
будут оставаться согласованными и актуальными между всеми доменами.
Если вам требуется согласовать продукты данных своих доменов с референсными
данными предприятия, рассмотрите следующие решения:
Предоставьте централизованные сервисы, позволяющие доменам обнаруживать, понимать, выбирать и интегрировать референсные значения в свои
продукты данных. Например, можно отправлять их доменам напрямую, чтобы
упростить разработку их продуктов данных.
Предоставьте централизованный сервис MDM для управления согласованием
локальных уровней с уровнями предприятия или примените каталог, который
поможет доменам отображать свои столбцы продуктов данных на столбцы
централизованных референсных датасетов. В тех случаях, когда продукт данных публикуется на золотом уровне, инициируйте операции постобработки
(например, задание проверки качества данных) для выявления и устранения
любых несогласованностей.
Обеспечение согласованности и качества данных между разными доменами
чрезвычайно важно для эффективного управления референсными данными.
Согласуя референсные данные с корпоративными стандартами, вы гарантируете

  

344

Глава 11. Масштабирование архитектур медальона

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

Заключение
Вы увидели, что конфигурации можно настраивать под конкретные бизнестребования при соблюдении определенных стандартов, обеспечивающих согласованность и надежность во всех операциях данных. Однако стандартизация
не означает жесткого, фиксированного подхода «на все случаи жизни». Имеется
достаточная гибкость для определения уровней стандартизации и выбора между
централизованными и децентрализованными подходами. Такие варианты могут
сосуществовать, обеспечивая адаптируемость, необходимую для выбранной
стратегии управления данными. Например, можно определить более крупные
домены в архитектуре систем-источников и более детализированные, более
проработанные домены на стороне потребителя. Можно реализовать централизованную MDM-систему для мастер-данных, одновременно доверяя отдельным
доменам управление и отображение их специфических референсных данных (например, кодов стран и денежных единиц). Такая гибкость позволяет архитектуре
адаптироваться к постоянно изменяющемуся бизнес-ландшафту.
Контроль не менее важен, чем гибкость. Без тщательного контроля эти практики
масштабирования могут привести к росту затрат и неконтролируемому распространению применяемых технологий. Например, если команды независимо
выбирают свои фреймворки качества данных, это затрудняет сравнение метрик
между доменами. Точно так же отсутствие единой схемы преобразований усложняет отслеживание происхождения данных между доменами. Лучшая стратегия —
начать с малого и тщательно сформировать один домен, прежде чем органически
добавлять в архитектуру новые домены. Такое постепенное расширение помогает
обеспечить масштабируемость и управляемость.
В крупных организациях отдел архитектуры предприятия играет важнейшую роль
в согласовании архитектуры с бизнес-целями. Команда архитектуры предприятия должна направлять организацию на пути перехода к федеративной модели,
одновременно соблюдая баланс между централизованным управлением данными
и децентрализованной гибкостью.
По мере продвижения к децентрализованной, но контролируемой среде данных
важность управления данными и безопасности данных увеличивается. В главе 12
мы исследуем эти темы, а также концепцию контрактов данных в федеративной
архитектуре.

ГЛАВА 12

Управление данными и безопасность
в архитектуре медальона
В главе 11 мы исследовали особенности децентрализации и федеративных моделей
в архитектурах медальона, которые становятся особенно актуальными в больших
сложных организациях. В главе 12 мы переключим внимание на протоколы управления данными и безопасности. Важность этих сфер невозможно переоценить.
В этой главе приводится подробный обзор вопросов управления данными и безо­
пасности, необходимых для эффективной эксплуатации федеративных моделей.
Мы начнем с подробного обсуждения управления данными, при этом уделим особое
внимание использованию Unity Catalog как лучшей практике. Затем рассмотрим
контракты данных и их роль в безопасном и эффективном обмене данными между
доменами. Мы изучим методологии внедрения контрактов данных в каталоге данных, использования конфигурации метахранилищ, а также развертывания YAMLшаблонов вместе с Git для контроля версий и совместной работы.
В завершение главы мы подробно изучим вопросы безопасности данных и управления доступом. Мы сосредоточимся на безопасности таких платформ данных,
как Microsoft Fabric и Azure Databricks, и мерах, которые гарантируют, что доступ
к данным тщательно контролируется и соответствует установившимся протоколам безопасности.
К концу этой главы читатель будет хорошо понимать, какие основные меры
управления данными и меры безопасности необходимы для эффективной работы
с архитектурами медальона, чтобы данные оставались ценным и защищенным
ресурсом.

Управление данными
Управление данными (data governance) в крупной федеративной архитектуре —
довольно сложная сфера. Оно требует структурированного подхода, который
обеспечит должное управление качеством данных, их целостностью и безопасностью. Это подразумевает наличие четких рекомендаций для эффективной работы
с данными в каждом экземпляре архитектуры медальона. Для этого необходимо
определить роли, установить границы и управлять данными между бронзовым,
серебряным и золотым уровнями.

  

346

Глава 12. Управление данными и безопасность в архитектуре медальона

Давайте исследуем, как эффективно реализовать управление данных в архитектуре медальона, и рассмотрим специфику управления данными на каждом уровне.
После этого обсудим Unity Catalog — критически важный компонент управления
данными в такой архитектуре.

Управление данными в архитектуре медальона
Реализацию принципов управления данными рекомендуется начинать с изучения
такого компонента архитектуры, как системы-источники, потому что данные
поступают именно от них. Определите, какие системы-источники генерируют
и хранят достоверные данные. Затем назначьте роли для владения приложением
и данными. Владелец приложения управляет вопросами сбора данных, а владелец данных занимается обеспечением качества данных и решает, какие данные
должны распространяться через платформу данных.
Затем очертите границы приложений. Сгруппируйте приложения, которые
работают в тесном взаимодействии и поддерживают одну бизнес-цель. После
этого назначьте владельца для каждого домена. Эта «персона» (persona) станет
основным контактом для своего домена.
«Персоны» представляют разные роли в организации, и один человек нередко может принимать несколько ролей в зависимости от структуры домена.
Например, сотрудник может быть одновременно владельцем приложения
и владельцем данных. Множественность ролей допускает гибкое участие
в решении различных вопросов управления данными, с адаптацией к потребностям каждого домена.

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

  

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

347

ограничьте данные бронзового уровня пределами своего домена; разрешите
внешнее использование только для сертифицированных датасетов серебряного
уровня или данных золотого уровня.
На бронзовом уровне очень важно поддерживать короткие циклы обратной
связи с командами приложений-источников. При возникновении проблем
с технической проверкой или загрузкой команды приложений, ответственные за
системы-источники, должны решать их быстро. Это гарантирует, что управление
данными останется эффективным и безопасным. Кроме того, убедитесь, что меры
безопасности действуют прямо с точки сбора или загрузки данных. Проследите
за тем, чтобы данные (автоматически) помечались и классифицировались прямо
при поступлении в архитектуру. Также можно воспользоваться фреймворками
симметричного шифрования для защиты персональной информации (PII) или
других чувствительных данных. Следовательно, необходимо заранее определить
на уровне организации метки конфиденциальности и схемы классификации, чтобы обеспечить согласованную защиту PII и других конфиденциальных данных.
На серебряном и золотом уровнях управление данными должно в первую очередь обеспечивать целостность, согласованность и удобство использования.
Разработайте правила для стандартизации моделирования данных: форматы
данных, соглашения об именовании, типы преобразований и т. д. Такие правила
обеспечивают единообразие между разными датасетами. Также важно обеспечить
согласованность с корпоративными стандартами данных и мастер-данных, особенно если одни данные интенсивно используются несколькими доменами. На
серебряном уровне избегайте интеграции данных между источниками, чтобы лучше согласовать владение данных с командами приложений. Регулярно проводите
аудиты, чтобы обеспечить соблюдение этих стандартов. Такой подход позволит
поддерживать качество и надежность данных при их перемещении по продвинутым стадиям архитектуры. На золотом уровне выбирайте модели данных, которые
лучше соответствуют потребностям вашей организации. Концентрируйтесь на
нюансах, а не на абсолютных показателях. Преобразуйте свою модель данных
в модель интерфейса, оптимизированную для интенсивного потребления данных.
Подведем итоги обсуждения загрузки и обработки данных до золотого уровня.
В табл. 12.1 приводится обзор самых важных целей управления данными на
каждом уровне.
После создания данных на бронзовом, серебряном и золотом уровнях обратитесь
к потребляющей части архитектуры. Ее работа упрощается благодаря наличию
золотого уровня, который может варьироваться в зависимости от требований
доменов и сценариев использования. Вместо избыточного выделения ресурсов за
счет повторного использования одной платформы предложите командам гибкие
паттерны решений, адаптированные для их специфических потребностей. Также
необходимо эффективно управлять портфелем всех сценариев потребления.
Желательно избегать ненужного увеличения количества новых экземпляров
платформ.

  

348

Глава 12. Управление данными и безопасность в архитектуре медальона

Таблица 12.1. Обзор управления данными на уровнях медальона
Уровень

Цели, связанные с управлением данными

Бронзовый

Оповещать о проблемах с технической проверкой
Размечать и классифицировать данные
(Не обязательно) шифровать данные
Контролировать доступ к сырым данным

Серебряный

Оповещать о функциональных проблемах с качеством данных
Предотвращать интеграцию источников данных
Проводить регулярные аудиты
Применять MDM
Обеспечивать включение метаданных безопасности
Определять допустимость операционного использования
Обеспечивать согласованность с бронзовым уровнем
Утверждать (sign-off) операционно выверенные продукты данных

Золотой

Фокусироваться на нюансах использования
Обеспечивать единообразие датасетов
Преобразовывать модели данных
Утверждать продукты данных

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

  

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

349

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

Unity Catalog
В главе 1 мы исследовали экосистему Hadoop, сосредоточившись на ее важнейшем
компоненте — Hive Metastore. В Hadoop, а позднее на платформе Databricks, он
выступал как хранилище метаданных для управления объектами данных и поддержки запросов. Хотя какое-то время он работал эффективно, ему недоставало
гибкости и простоты использования. Главный недостаток заключался в том, что
каждому рабочему пространству было необходимо собственное метахранилище
для управления конфигурацией, что требовало либо утомительной репликации,
либо реализации внешнего метахранилища в большем масштабе. Представьте,
что вы пытаетесь управлять разрешениями для десятков или сотен рабочих пространств, которые все должны использовать одну модель безопасности. Наладить
согласованное управление этим процессом во многих рабочих пространствах
было достаточно сложно.
Для решения этих проблем разработчики Databricks переработали свой подход
к управлению доступом, аудиту и обнаружению данных между рабочими пространствами, что привело к созданию Unity Catalog. Этот централизованный
каталог управляет активами данных в разных рабочих пространствах, значительно
упрощая управление данными.
Со временем технология Unity Catalog получила широкое распространение,
и в Databricks решили сделать ее код открытым1. Это решение изменило положение дел в отрасли, позволив организациям использовать возможности
каталога между разными платформами. Сейчас Unity Catalog является важным

1

На открытое распространение была переведена не вся функциональность Unity Catalog.
Впрочем, ожидается, что будут добавлены новые функции. Актуальная информация
доступна в официальной документации Unity Catalog (https://docs.unitycatalog.io).

  

350

Глава 12. Управление данными и безопасность в архитектуре медальона

компонентом экосистемы с открытым исходным кодом. На рис. 12.1 изображена
его структура.

Рис. 12.1. Пользовательский интерфейс продукта с открытым исходным кодом Unity Catalog с подробным
представлением различных каталогов, схем, таблиц и свойств
В открытой версии Unity Catalog предоставляет универсальный интерфейс, который поддерживает многие форматы данных и вычислительные среды. Такие
табличные форматы, как Delta Lake, Iceberg и Hudi, поддерживаются через формат
Delta Universal Format (UniForm) (https://oreil.ly/I-7Pr), автоматически генерирующий метаданные Iceberg в асинхронном режиме, что позволяет клиентам читать
таблицы Delta так, как если бы они были таблицами Iceberg или Hudi. Среди

  

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

351

клиентов можно особо выделить Microsoft Fabric (https://oreil.ly/kx_Sm), Snowflake
(https://oreil.ly/RTN2O), DuckDB (https://oreil.ly/XZ94d)1, Apache Spark (https://oreil.
ly/0IsnK), Trino и Dremio (https://oreil.ly/0F4cd).
Кроме того, Unity Catalog поддерживает внешний доступ через Credential Vending
API (https://oreil.ly/hYmcY) и такие стандарты, как Iceberg REST Catalog и интерфейс Hive Metastore. Это направление отмечает перспективное будущее для
сотрудничества вокруг стандартов метаданных для Lakehouse Table и открытых
каталогов.

Каталоги данных с открытым исходным кодом
Тенденция перевода каталогов данных на модель с открытым кодом
набирает популярность, о чем свидетельствует появление нескольких
перспективных проектов в технологическом сообществе. Unity Catalog
(https://unitycatalog.io), Project Nessie (https://projectnessie.org), Apache Polaris
(https://polaris.apache.org) и Apache Gravitino (https://gravitino.apache.org) —
основные из них. Эти платформы призваны демократизировать доступ
к данным и управление ими, упрощая управление данными в масштабе
для разработчиков и организаций. Такой переход может значительно
изменить рынок, снижая сложность входа для использования решений
каталогизации данных, что теоретически может привести к нарастанию
конкуренции или уровня стандартизации.
Какое место занимает Unity Catalog в архитектуре медальона? Узнаем в следующем разделе.

Архитектура медальона с Unity Catalog
Если вам необходимо надежное управление данными в рабочих сценариях,
Unity Catalog, особенно в архитектуре медальона, — не просто опция, а необходимость. Unity Catalog обеспечивает целостное представление активов данных
и способствует сотрудничеству между различными рабочими пространствами.
Использование Unity Catalog предоставляет ряд преимуществ, которые будут
подробно рассмотрены ниже.
Одна из ключевых особенностей Unity Catalog — оптимизация иерархии пространств имен. Традиционно в системах управления данными используется двухуровневая структура вида имя_схемы.имя_таблицы. Unity Catalog добавляет
третий уровень, создавая трехуровневый формат: имя_каталога.имя_схемы.
имя_таблицы.
1

Кайл Уэллер (Kyle Weller) продемонстрировал гибкость Unity Catalog в своем посте
Unity Catalog OSS with Hudi, Delta, Iceberg, and EMR + DuckDB (https://oreil.ly/B88jJ).

  

352

Глава 12. Управление данными и безопасность в архитектуре медальона

Если вы хотите увидеть наглядный пример его практического применения, создайте отдельные каталоги для разных команд или имен доменов и пометьте их
префиксами dev, test, prod и т. д. для разных задач CI/CD. В каждом каталоге
можно встроить в имя схемы уровень архитектуры медальона в виде префикса
bronze, silver или gold. Например, таблица для команды продаж, использующей
данные AdventureWorks, может называться prod_sales.silver_adventureworks.
clean_customer. Такая стратегия именования не только облегчает извлечение данных в разных средах, но и делает понятным преобразование данных; бронзовый
и серебряный уровни обычно ориентированы на источник, а золотой уровень —
главным образом на потребляющие приложения или продукты данных.
Соглашения об именовании играют важнейшую роль в обеспечении масштабируемости и согласованности. Централизованная команда, которая часто является
центром распространения передовых технологий, отвечает за назначение удобочитаемых и интуитивно понятных стандартов имен. Команда также играет
важную роль в публикации общих каталогов, соответствующих этим стандартам.
Единообразие соглашений об именовании также сыграет важную роль в будущих
ИИ-приложениях, так как оно способствует более быстрому поиску и интеграции
данных, в целом повышая общую эффективность системы.
Доступ к каталогу можно ограничить конкретными рабочими пространствами — для этого используется функция, называемая привязкой рабочих пространств к каталогу (workspace-catalog binding). Эта функция особенно полезна, если нужно ограничить доступ к конкретным объектам в каталоге.
Подробнее об ограничении доступа к каталогам для конкретных рабочих
пространств см. в документации Databricks (https://oreil.ly/61PgB).

Впрочем, реализация каталогов не сводится к управлению таблицами. Unity Catalog
также выполняет сторожевые функции в системе безопасности, так как позволяет
предусмотреть отдельную защиту для каждого объекта в каталоге. Такие привилегии назначаются владельцем объекта, которым обычно является создатель ресурса
данных. В таком контексте Unity Catalog также интегрируется с провайдерами
идентификационных данных, такими как Microsoft Entra ID. Это позволяет назначить уровни доступа для разных групп Entra ID (таких, как каталоги и схемы).
Например, если вы хотите предоставить группе пользователей доступ к конкретной
таблице Unity Catalog, используйте следующий синтаксис SQL:
GRANT USE CATALOG ON CATALOG <имя_каталога> TO <имя_группы>;
GRANT USE SCHEMA ON SCHEMA <имя_каталога>.<имя_схемы>
TO <имя_группы>;
GRANT
SELECT
ON <catalog_name>.<имя_группы>.<имя_таблицы>;
TO <имя_группы>;

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

  

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

353

Такой интегрированный подход обеспечивает надежность и гибкость системы
управления безопасностью. Когда привилегии назначаются на более высоком
уровне иерархии (например, уровне каталога или схемы), они наследуются всеми
подчиненными объектами, включая таблицы и представления. Подобная гибкая
конфигурация позволяет применять разные правила на каждом уровне по мере
необходимости, легко адаптируясь к различным требованиям.
Если вам захочется больше узнать о лучших практиках, я рекомендую статью
Unity Catalog Best Practices (https://oreil.ly/pkgs1).
Назовем некоторые ключевые преимущества, которые делают Unity Catalog
эффективным инструментом управления данными:
Централизованное управление данными
Unity Catalog работает как централизованная платформа для управления активами данных в пределах организации. При этом Unity Catalog наблюдает за
всеми рабочими пространствами, позволяя отслеживать происхождение данных, управлять метаданными и обеспечивать качество данных и управление
ими на всем ландшафте данных. В Unity Catalog имеется интерфейс поиска,
который предоставляет доступ к метаданным, одновременно ограничивая
доступ на основании пользовательских привилегий.
Средства контроля доступа
Эффективный контроль доступа абсолютно необходим для надежного управления данными. Unity Catalog предоставляет детализированные средства
контроля доступом, позволяя организациям задавать права доступа вплоть до
уровней каталога, схемы или объектов (уровень таблиц, столбцов или строк).
Такая конфигурация повышает как гибкость, так и безопасность. Средства
управления доступом подробнее рассматриваются в разделе «Безопасность
данных и управление доступом», с. 361.
Происхождение данных и аудируемость
Unity Catalog может использоваться для отслеживания происхождения
данных во время выполнения по запросам, выполняемым в Databricks. Эта
функция поддерживается для всех языков и реализуется вплоть до уровня
столбцов. Данные о происхождении включают блокноты, задания и дашборды,
относящиеся к запросу.
Классификация данных и тегирование
Для упрощения управления данными и контроля соблюдения стандартов Unity
Catalog поддерживает классификацию и назначение тегов данным в зависимости
от степени их чувствительности, характера использования и других критериев.
Теги помогают контролировать соблюдение политики безопасности, например
ограничивать доступ к конфиденциальным данным или реализовывать конкретные правила удержания (retention) данных. Мы вернемся к классификации
данных и тегам в разделе «Безопасность данных и управление доступом», с. 361.

  

354

Глава 12. Управление данными и безопасность в архитектуре медальона

Совместное использование данных
Unity Catalog предоставляет возможность совместного использования объектов как внутри организации, так и за ее пределами. Для этого существует
механизм Delta Sharing (https://oreil.ly/SXfQU). Он работает примерно так:
сначала вы создаете общий ресурс (share) и добавляете в него объекты. Затем добавляете получателей и предоставляете им необходимый доступ. Когда
все готово, генерируется URL. Получатели могут воспользоваться URL для
загрузки файла профиля. Этот файл содержит URL сервера Delta Sharing
и маркер носителя, который используется получателем для обращения к общему объекту. Эта функциональность не ограничивается Databricks; она также
работает с другими технологиями (Power BI, Spark, pandas и т. д.), то есть
является достаточно универсальной.
Как все эти возможности сочетаются с принципами модели управления распределенными данными, рассмотренными выше? Какую стратегию следует принять?
В соответствии с принципами модели управления распределенными данными, на
начальном этапе идентифицируются домены организации, для чего применяются
рекомендации из главы 11. Каждый домен должен иметь собственные рабочие
пространства, каталог или набор каталогов, надзор за которыми осуществляет назначенный владелец домена. Владельцу поручается управление всеми ресурсами
и обеспечение эффективного управления в пределах его домена.
Для большей ясности и упорядоченности рекомендуется создавать каталоги
для каждой команды и каждой цели, например каталоги dev_sales, test_sales
и prod_sales для простой передачи артефактов между средами. Использование
содержательных имен для этих каталогов, а также для их схем, таблиц и столбцов упрощает понимание их содержимого и управление им. Это не только поддерживает данные в организованном состоянии, но и повышает безопасность
и упрощает управление.
А теперь поговорим о разрешениях в самом домене. В табл. 12.2 приведен пример
модели доступа.

Таблица 12.2. Предоставление доступа на уровне таблиц
Каталог среды
разработки

Каталог среды
тестирования

Каталог продакшенсреды

Разработчики

Выбор и изменение

Запрет доступа

Выбор или запрет
доступа

Субъект-служба
тестирования

Запрет доступа

Выбор и изменение

Запрет доступа

Субъект-служба продакшен

Запрет доступа

Запрет доступа

Выбор и изменение

  

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

355

В этой модели управление доступом в доменах стратегически важно для поддержания безопасности и функциональности. Например, разработчики должны
иметь доступ для записи к каталогу разработки, в котором они могут свободно
тестировать и исправлять код, и доступ только для чтения к каталогу на продакшен. Это важно для целей отладки: разработчики могут просматривать, но
не изменять рабочие данные, что позволит избежать случайных нарушений
в продакшен-среде.
Кроме того, введение тестового каталога требует назначения выделенного субъекта-службы (service principal)1, или учетной записи службы. Эта учетная запись
предназначена для автоматизированных процессов тестирования (например,
тестирования при непрерывной интеграции (CI)). Она должна иметь права на
запись в тестовый каталог, чтобы активировать сценарии тестирования, но доступ
к каталогам продакшен и разработки запрещен, чтобы поддерживать жесткое
разделение сред. Такое разделение гарантирует, что автоматизированные тесты
не будут вмешиваться в процесс разработки или нарушать стабильность продакшен-среды.
Тщательно структурируя разрешения доступа, организация может сформировать
безопасный и эффективный рабочий поток, поддерживая практики разработки
без нарушения целостности рабочей среды.
Эффективное управление идентификационными данными в Unity Catalog также
играет важную роль. Рекомендуется создавать группы с конкретными разрешениями (например, INSERT, UPDATE или DELETE), адаптированными для конкретной
схемы или каталога. Затем эти группы связываются с отдельными пользователями. Эти группы должны включать разнообразные роли в организации — разработчиков, специалистов data science, бизнес-аналитиков и т. д., — наделенных
необходимыми правами для разных каталогов. Например, специалисты data
science должны обладать правами доступа к каталогу prod_sales и схемам с префиксом silver_, где они могут анализировать данные. Такой структурированный
подход не только обеспечивает безопасность данных, но и повышает эффективность эксплуатации. Мы вернемся к этой теме в разделе «Безопасность данных
и управление доступом», с. 361.
Подведем итоги. Unity Catalog значительно облегчает управление данными
в Databricks и других экосистемах с открытым исходным кодом. Unity Catalog
функционирует как рабочий каталог, упрощая такие задачи, как инженерия
данных, безопасность, происхождение данных и мониторинг. Однако если
Unity Catalog является частью более широкой инфраструктуры данных, может
1

Термин «субъект-служба» (service principal) используется в официальной русскоязычной
документации Databricks и других материалах, связанных с Unity Catalog. Субъект-служба — это учетная запись, которая используется для предоставления доступа к ресурсам
и выполнения операций в автоматизированных процессах. — Примеч. ред.

  

356

Глава 12. Управление данными и безопасность в архитектуре медальона

быть эффективнее использовать его совместно с другим каталогом (например,
Microsoft Purview). В такой конфигурации Unity Catalog работает с операционными парамет­рами управления данными в Azure Databricks. А Microsoft Purview
действует как «каталог каталогов». Одновременное использование обоих каталогов облегчает внедрение единой стратегии управления данными между разными
платформами, повышая эффективность обработки данных.
В следующем разделе мы займемся контрактами данных — важной областью
управления данными в среде децентрализованных данных.

Контракты данных
Ручные операции безопасности и управления данными безнадежно устарели.
В наши дни требуется вычислительный уровень управления данными, который
автоматизирует и оркестрирует всю платформу данных. Контракты данных
играют важную роль в автоматическом применении политик. Эти контракты
преобразуют ручные рабочие процессы в программные, сохраняя при этом необходимые защитные меры. Такая эволюция оптимизирует процессы и повышает
общий уровень безопасности.
По сути, контракт данных представляет собой формальное соглашение между
провайдером и потребителем данных, описывающее принципы и условия распространения и использования данных. В нем указываются такие подробности,
как формат данных, качество, доступность и политики безопасности, а также ответственность каждой из участвующих сторон. Если продукт данных относится
к определению и содержимому самих данных, контракт данных концентрируется
на интерфейсе данных, стремясь формализовать ожидания и ответственность,
связанную с распространением данных.
Следует помнить, что термин «контракт данных» может быть неоднозначным
(как, впрочем, и термин «продукт данных»). Разные люди могут понимать его поразному, и в отрасли не существует общепринятого определения. Следовательно,
важно четко установить его в пределах организации, чтобы избежать разногласий
и убедиться, что все понимают этот термин одинаково.
Контракты данных помогают управлять распределением данных между разными
архитектурами медальона в пределах одной организации. Эта практика задает правила поставки данных, их совместного использования и потребления, что, в свою
очередь, повышает качество данных, улучшает управление данными и ускоряет
принятие решений на основе данных.
Мы начнем с того, что научимся создавать контракты данных в каталоге данных,
а затем перейдем к использованию метахранилища. Затем узнаем, как для этого
могут пригодиться шаблоны YAML и Git, а также коснемся некоторых альтернативных подходов.

  

Контракты данных

357

Контракты в каталоге
Организации часто реализуют контракты данных или соглашения о совместном
использовании данных при помощи каталогов данных и таких инструментов
управления данными, как Microsoft Purview и Unity Catalog. Эти инструменты
служат централизованными репозиториями для хранения и управления контрактами данных. На рис. 12.2 приведен пример запроса продукта данных в Microsoft
Purview. По запросу доступа к продукту данных запускается рабочий поток,
и владелец ресурса данных или менеджер может предоставить этот доступ. Можно
сказать, что это разновидность контракта данных.
Соглашения, сохраненные в Microsoft Purview, пока еще слабо связаны с другими
сервисами данных. Microsoft Purview отслеживает запросы данных и упрощает
создание контракта через рабочий поток самообслуживания. Однако система еще
не контролирует соблюдение контракта и не распространяет сами данные. Для
этого понадобится интеграция с коннектором HTTP (https://oreil.ly/FN5dA) или
другими инструментами, такими как ServiceNow (https://oreil.ly/P2c73).

Рис. 12.2. Запрос продукта данных в Microsoft Purview

  

358

Глава 12. Управление данными и безопасность в архитектуре медальона

У сервисов, подобных Microsoft Purview, для быстрого создания контрактов
данных и управления ими, несомненно, есть преимущества. Впрочем, есть и недостаток: возможная чрезмерная зависимость от конкретной платформы. Такая
зависимость может создать сложности, если требуется расширить область применения или интегрироваться с не полностью совместимыми технологиями.
Кроме того, такие сервисы могут ограничить возможность настраивать или
адаптировать контракты данных для конкретных потребностей, выходящих за
заранее определенные рамки сервиса.
Перейдем к более общим решениям. Для начала рассмотрим применение пользовательского метахранилища для оптимизации и улучшения управления контрактами данных. Оно предоставляет больше гибкости и расширяет возможности
процессов управления данными. Затем подробнее рассмотрим управление контрактами данных с использованием файлов YAML и GitOps.

Контракты в метахранилище
Использование метахранилища может значительно повлиять на создание контрактов данных и управление ими. Прежде всего, метахранилище обеспечивает
четкое и согласованное представление всех активов данных — эта тема более подробно рассматривается в разделе «Реализация хранилища метаданных» главы 6,
с. 179. Кроме того, метахранилище может автоматизировать некоторые вопросы
управления данными (например, управление доступом и аудит), гарантируя, что
контракты данных будут последовательно соблюдаться в пределах организации.
Метахранилище можно улучшить добавлением дополнительных таблиц. Допустим, у вас уже имеется метахранилище для описания схем; его можно расширить,
добавив информацию о том, какие данные считать конфиденциальными, где и как
хранить данные, правила доступа, журналы аудита и т. д. Такая конфигурация
помогает хранить важную информацию о контрактах данных.
Практическое решение для метахранилища может включать несколько ключевых
компонентов для разных областей управления контрактами данных. Как говорилось в главе 6, в качестве метахранилища для управления контрактами можно
выбрать вариант с Azure SQL. На его основе можно интегрировать удобное и доступное веб-приложение для наглядного представления этих контрактов, чтобы
стейкхолдеры могли просмотреть и понять действующие правила.
Для упрощения процесса одобрения можно воспользоваться Logic App (https://
oreil.ly/cRcjW) — системой автоматизации рабочих потоков, управляющих после-

довательностями одобрения, гарантирующей, что контракты будут проверяться
и проходить авторизацию по заранее определенным правилам и критериям.
Наконец, внедрение Azure Functions (https://oreil.ly/YSihc) поможет запускать
процесс выделения данных. Например, после одобрения контракта можно вызвать Microsoft Fabric OneLake Shortcuts REST API (https://oreil.ly/AVb1N) для
настройки доступа к данным.

  

Контракты данных

359

Такая возможность настройки не только гарантирует безопасное управление
контрактами данных, но и обеспечивает гибкость для адаптации процесса под
конкретные потребности. Во многих организациях широко распространена
практика управления пользовательскими разрешениями доступа на основании их принадлежности к группам. Адаптируя свое решение и интегрируя его
с Microsoft Entra ID, вы можете эффективно управлять сценариями, в которых,
например, разрешения отдельных пользователей зависят от их принадлежности
к группе, а разрешения приложений определяются руководителями сервисов.
Такая адаптируемость жизненно важна для обеспечения как безопасности, так
и функциональности в динамических средах.
Помните: описанные здесь решения — всего лишь один из возможных вариантов.
Существуют и другие способы настроить необходимый баланс между управлением данными и самообслуживанием, исходя из ваших потребностей.
Рассмотрим теперь другой подход: сочетание файлов YAML и GitOps для управления контрактами данных.

Контракты данных с использованием файлов YAML и GitOps
Управление контрактами данных с использованием файлов YAML в сочетании
с процессом GitOps также может быть достаточно эффективным. Начать его внедрение лучше с определения контрактов данных в файлах YAML, которые одновременно и удобочитаемы, и легко отслеживаемы. Такие файлы можно сохранить
в системе контроля версий (такой, как Git) с помощью пул-реквестов. Подобная
механика соответствует той, что обсуждалась ранее в разделе «Конфигурации
в YAML или JSON» в главе 5, с. 167.
Например, при необходимости проверить содержимое датасета для его потреб­
ления вы сначала подготавливаете контракт данных в файле YAML. Этот файл
служит формальным описанием данных. В контракте указываются такие детали, как название датасета, SQL-команды фильтрации и владелец датасета. Вот
упрощенный пример того, как может выглядеть контракт данных в файле YAML:
owner: piethein@oceanicairlines.internal
purpose: анализ пользовательского поведения и трендов продаж.
use_case:
description: предназначен для таргетированных кампаний в Нью-Йорке.
workspace_id: 92187CE0-B7EB-4FDF-80CE-EFF76639EED8
dataset_location: https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>
dataset: dim_customer
filter_sql: customer_state = 'New York'
columns:
- name: first_name
- name: last_name
- name: birthdate

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

  

360

Глава 12. Управление данными и безопасность в архитектуре медальона

Созданный контракт данных можно проверить и одобрить. Один из эффективных механизмов основан на использовании метахранилища. Контракт можно
проверить, одобрить и загрузить прямо в метахранилище.
Также можно встроить проверку в рабочий поток CI/CD, чтобы убедиться, что
шаблон YAML соответствует стандартам данных платформы. После интеграции
контракт данных в пул-реквесте может просмотреть и одобрить команда управления данными. После одобрения можно запустить пайплайн релиза, который
использует контракт данных для назначения соответствующих прав в платформе
через предоставленные REST API. Такой подход помогает поддерживать целостность данных и контролировать соответствие стандартам организации.

Другие спецификации контрактов данных
Некоторые специалисты в области данных предпочитают использовать специ­
фикацию контракта данных — формальный документ с подробным описанием
условий совместного использования данных.
В репозиториях Open Data Contract Standard (https://oreil.ly/aIQtR) и Data Contract
Specification (https://oreil.ly/sHcPp) приводятся примеры спецификаций контрактов
данных с открытым исходным кодом. Такие спецификации являются технологически нейтральными, вследствие чего они совместимы с любыми платформами
данных. Спецификации обычно пишутся на таких языках, как YAML или JSON.
Если вам понадобится практический пример реализации контрактов данных,
прочитайте статью How To Build a Data Product with Databricks (https://oreil.ly/
uxnu_). В ней рассматривается использование CI/CD в Databricks и Azure DevOps
для создания продукта данных на основании контрактов данных. Другой ресурс,
заслуживающий внимания, — Data Contract CLI (https://oreil.ly/QSIEu), реализация
создания контрактов данных в режиме командной строки с поддержкой Unity
Catalog.
Другой подход к контрактам данных базируется на датасете (продукте данных),
всегда имеющем заранее определенную и гарантированную структуру. Например, в dbt такие гарантии называются контрактами. Этот контракт описывает
ожидания относительно данных, производимых моделью, включая схему, типы
столбцов и ограничения. По сути, это стратегия поддержания согласованности
и надежности данных. В отличие от тестов качества данных, если логика модели
или входные данные не соответствуют контракту, модель создать не получится.
Чтобы лучше понять подход к контрактам данных в dbt, ознакомьтесь с руководством по контрактам моделей (https://oreil.ly/c5GPi).
Наконец, контракты данных иногда вступают в игру во время загрузки данных.
Загружаемые данные должны соответствовать заранее определенному контракту, описывающему формат данных, схему и требования к качеству. Если данные
не соответствуют этим стандартам, они отклоняются подобно соглашениям
об уровне обслуживания (SLA, Service-Level Agreement) в разработке ПО, где

  

Безопасность данных и управление доступом

361

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

Безопасность данных и управление доступом
Управлять доступом к данным — определять, кто может видеть те или иные
данные, когда и при каких условиях, — может быть довольно сложно, особенно
в крупных организациях с детализированным разделением ролей и обязанностей. Кроме того, на разных платформах существуют уникальные функции
безопасности и требования. Следовательно, очень важно правильно реализовать
безопасность на разных уровнях платформы данных. Чтобы выполнить условия,
сформулированные в контракте данных, вам, скорее всего, придется объединять
меры безопасности и стратегии управления доступом.
В этом разделе мы подробно рассмотрим темы безопасности данных и управления
доступом на примере таких платформ, как Microsoft Fabric и Azure Databricks.
Помните, что безопасность — критически важная и притом весьма сложная область. Безопасность в Microsoft Fabric рассматривается в соответствующей статье
(https://oreil.ly/X-mBQ). Для Azure Databricks я рекомендую руководство Security
and Compliance (https://oreil.ly/nJvbw).
Доступ к данным можно организовать разными способами, управляя тем, кто
может просматривать или использовать те или иные данные. Эти способы сильно
различаются по сложности и точности, от широких до чрезвычайно детализированных уровней управления доступом. Рассмотрим некоторые распространенные
варианты, а потом сделаем выводы.
Простейшая сетевая безопасность
Изоляция сети — ключ к сетевой безопасности. Начните с блокирования
открытого доступа, используя внедрение VNET (https://oreil.ly/tyx5E) и развертывая рабочую нагрузку Spark в изолированных виртуальных сетях.
Используйте приватные эндпоинты (https://oreil.ly/UrNYd), чтобы ограничить

  

362

Глава 12. Управление данными и безопасность в архитектуре медальона

доступ исключительно доверенными сервисами. Реализуйте учетные записи
хранения с брандмауэром (https://oreil.ly/rLo-u) для дополнительной защиты
данных. Установите идентификационные данные рабочих пространств для
последовательной проверки доверенного доступа и используйте хранилища
ключей для безопасного и эффективного управления ключами безопасности.
Выполнив эти действия, вы оградите свою сеть от потенциальных угроз и повысите уровень защиты данных.
Также рассмотрите возможность использования безопасных посадочных зон.
Вместо того чтобы разрешать платформе данных (небезопасно) взаимодействовать с общедоступными эндпоинтами, можно воспользоваться экземплярами изолированной интеграционной среды Azure Data Factory (https://oreil.ly/
FQxLT) для перемещения данных из (внешних) источников в промежуточное
место хранения. Это гарантирует, что платформа данных взаимодействует
только с доверенными источниками.
Единый вход (SSO, Single Sign-On) и многофакторная аутентификация (MFA)
SSO и MFA — фундаментальные меры безопасности, помогающие защитить
платформы данных. SSO позволяет пользователям обращаться ко многим приложениям с одним набором учетных данных, что упрощает процесс входа. MFA
добавляет еще один уровень безопасности, требуя от пользователей ввести
два и более фактора верификации перед получением доступа. Например, это
может быть одноразовый код, отправляемый на телефон или в приложение.
SSO и MFA совместно помогают предотвратить несанкционированный доступ
к сервисам вашей платформы.
Полный аудит
Аудит — критически важный параметр безопасности данных. Проводя аудит
всех действий с использованием таких сервисов, как журналы диагностики
(https://oreil.ly/bJ4wx), журналы Storage Analytics (https://oreil.ly/hiBc4), журналы
NSG (Network Security Group) (https://oreil.ly/qLh07), а также отслеживание
активности пользователей (https://oreil.ly/H1zM1), вы будете знать, кто выполняет те или иные действия с тем или иным элементом. Это помогает защитить
архитектуру и выполнять такие требования, как соблюдение правовых норм
и правил хранения данных.
Реализация PIT-восстановления
PIT-восстановление (Point-In-Time recovery) — критически важный механизм
безопасности, позволяющий восстановить состояние данных на определенный
момент времени. Он особенно эффективно защищает от случайных удалений,
порчи данных или взломов, например атак вымогателей. Рене Бремер (René
Bremer) опубликовал отличную статью о защите Azure Data Lake с использованием Azure Databricks или Synapse Analytics (https://oreil.ly/7EByo). Подробнее о безопасности Microsoft Fabric можно узнать из обзора лучших практик

  

Безопасность данных и управление доступом

363

и факторов для планирования стратегии ведения бизнеса и восстановления
в случае сбоев от Николаса Харта (Nicholas Hurt) (https://oreil.ly/heWxx).
Роли и разрешения в рабочих пространствах
Microsoft Fabric и другие платформы, такие как Azure Databricks и Synapse
Analytics, включают набор встроенных ролей, которые могут назначаться
пользователям или группам в определенных рабочих пространствах. Эти
роли определяют, какие действия могут выполнять пользователи и к каким
объектам они могут обращаться. Также можно создать нестандартные роли,
адаптированные для специфических потребностей организации. Например,
одну роль для просмотра всего содержимого в рабочем пространстве и другую — для администрирования. После определения роли можно назначить
соответствующим пользователям или группам.
Эти роли и разрешения рабочих пространств применяются исключительно
к объектам рабочих пространств. Для доступа к данным рекомендуется использовать детализированные разрешения данных в таких инструментах,
как Unity Catalog. Такой подход гарантирует, что управление данными будет
эффективным и безопасным.
Разрешения уровня элементов
Разрешения уровня элементов работают примерно так же, как роли и разрешения рабочих пространств, но они обеспечивают намного более точный
и детализированный контроль доступа для отдельных элементов. Такие
платформы, как Microsoft Fabric и Azure Databricks, предоставляют возможность задавать разрешения для отдельных элементов, например пайплайнов или проектов Data Science. Этот механизм позволяет намного точнее
управлять доступом к отдельным ресурсам данных в рабочих пространствах.
В Azure Databricks можно использовать списки контроля доступа (ACL)
(https://oreil.ly/ZvXqs), чтобы устанавливать разрешения для объектов уровня
рабочего пространства. В Microsoft Fabric разрешения элементов (https://
oreil.ly/dT0zW) позволяют определить, кому разрешено просматривать отдельные элементы, изменять их и выполнять другие операции с ними
в сущностях Workspace.
Чтобы назначить эти разрешения, обычно используется рабочий процесс,
включающий задачи «создать» и «ожидать завершения» для ручной установки
ролей и разрешений для пользователей или групп. Кроме того, для управления
запросами доступа и разрешениями могут использоваться такие инструменты,
как ServiceNow. После одобрения можно применять встроенные роли для предоставления конкретных разрешений к Workspace или элементам. Назначайте
эти роли соответствующим пользователям или группам, чтобы быть уверенным, что несанкционированные пользователи не смогут обращаться к данным
и артефактам.

  

364

Глава 12. Управление данными и безопасность в архитектуре медальона

Совместное использование элементов в Microsoft Fabric
На уровнях рабочих пространств и безопасности уровня элементов также существует способ сотрудничества с участниками команд, не имеющими ролей
в Workspace. Для этого можно использовать элементы совместно с другими
пользователями. Подробнее см. в статьях Share Items in Microsoft Fabric
(https://oreil.ly/D8Zvm) и Collaborate Using Databricks Notebooks (https://oreil.
ly/2Ra16).
Использование меток конфиденциальности
Другой способ повышения уровня безопасности основан на назначении меток
конфиденциальности всем данным и артефактам. Допустим, вы используете
Microsoft Fabric вместе с Microsoft Purview. Вы можете создать в менеджере
защиты информации политику, которая автоматически помечает данные метками конфиденциальности, основанными на их содержимом. Например, если
документ содержит персональную информацию клиента (номера кредитных
карт, коды социального страхования, номера паспортов и т. д.), ему можно
автоматически присвоить метку Highly Confidential. После этого можно установить жесткие политики доступа.
Только пользователи с необходимыми разрешениями могут просматривать
конфиденциальную информацию. Это гарантирует, что конфиденциальные
данные останутся защищенными, а работать с ними будут только те, кому
действительно положено их видеть. Подробнее о назначении меток конфиденциальности см. в политиках защиты Microsoft Purview (https://oreil.ly/3N666),
статье Protected Sensitivity Labels in Fabric and Power BI (https://oreil.ly/8IyY-)
и видеоролике на YouTube «Microsoft 365 Information Protection and How it
Really Works!» (https://oreil.ly/-UVmG).
Использование Unity Catalog в Databricks
Для более точной настройки уровня управления доступом к данным между
разными схемами и связанными с ними структурами данных полезно использовать Unity Catalog в Databricks. При помощи привилегий Unity Catalog
можно управлять разрешениями на обращение к тем или иным каталогам,
таблицам, представлениям и другим объектам. Привилегии могут назначаться
как пользователям, так и группам, позволяя им выполнять определенные действия с этими объектами. В Databricks доступна более подробная информация
о привилегиях в Unity Catalog (https://oreil.ly/pr2od).
Также можно создать модель безопасности на основе атрибутов, использующую теги и правила для классификации данных и обеспечения политик.
Например, данные можно пометить тегом pii:ccn и создать правило, согласно которому пользователи будут видеть эти данные с применением регулярного выражения, заменяющего все цифры символами X. Таким образом,
конфиденциальные данные не будут видны пользователям с недостаточными

  

Безопасность данных и управление доступом

365

привилегиями. Дополнительную информацию о назначении тегов и правил
см. в демонстрационном видео (https://oreil.ly/OxaPa).
Настройка списков контроля доступа (ACL) в Azure Data Lake Storage (ADLS)
Реализация списков ACL в ADLS для управления безопасностью не рекомендуется как лучшая практика, но иногда встречается. Как правило, она приводит
к недостаточно детализированным разрешениям, точное управление которыми
будет затруднено. Вследствие этого могут возникнуть значительные риски изза предоставления слишком широкого доступа ко всем нижележащим данным.
Предоставление доступа через ссылки в Fabric
В Microsoft Fabric можно организовать совместный доступ к данным с помощью ссылок. Они позволяют предоставлять доступ к данным без открытия
доступа к самому элементу и без перемещения данных. При использовании
ссылок уровни доступа определяются комбинациями разрешений как для
пути ссылки, так и для целевого пути. При обращении пользователя к ссылке
применяется более жесткое ограничение из этих двух. Подробнее см. в документации Microsoft (https://oreil.ly/C868Z).
Реализация детализированных средств контроля доступа
Безопасность можно улучшить, ограничивая доступ к данным с использованием безопасности уровня строк (RLS, Row-Level Security), безопасности
уровня столбцов (CLS, Column-Level Security) и безопасности уровня объектов
(OLS, Object-Level Security). Допустим, у вас имеется таблица с чувствительными данными и вы хотите ограничить доступ к определенным строкам или
столбцам. RLS и CLS можно использовать для управления тем, кому разрешено просматривать или изменять конкретные строки или столбцы. OLS же
позволяет ограничить доступ к конкретным объектам, например таблицам
и представлениям. Это особенно полезно в сценариях, когда требуется управлять доступом к чувствительным данным на детализированном уровне. Этот
механизм в Microsoft Fabric описан в статьях Security for Data Warehousing
in Microsoft Fabric (https://oreil.ly/_3aSR) и OneLake Role-Based Access Control
(RBAC) (https://oreil.ly/9yTZC). Если вы работаете с Azure Databricks, обращайтесь к статье Filter Sensitive Table Data Using Row Filters and Column Masks
(https://oreil.ly/QbCf5).
Идентификация чувствительных данных
Чтобы управлять чувствительными данными, необходимо сначала идентифицировать их. Для этого можно использовать инструменты, которые автоматически обнаруживают и классифицируют такие данные на основании заранее
определенных паттернов или правил. Самые популярные инструменты —
Presidio (https://github.com/microsoft/presidio) и Data Profiler (https://github.com/
capitalone/DataProfiler).

  

366

Глава 12. Управление данными и безопасность в архитектуре медальона

Защита данных с применением маскировки или шифрования
В некоторых случаях данные должны быть защищены сразу с момента загрузки, для чего любая чувствительная информация либо маскируется, либо
шифруется. Для этого данные должны содержать метаданные, которые помогают выявить чувствительные элементы. Маскировка или шифрование
гарантируют сохранение конфиденциальности при обработке или хранении
данных. Этот способ особенно эффективен для предотвращения несанкционированного доступа и обеспечения защиты всей конфиденциальной информации на всех этапах обработки данных.
Безопасность Power BI
В Power BI пользователи могут либо импортировать данные на платформу,
либо напрямую подключаться к источнику данных. При импортировании
учетные данные пользователя сначала используются для подключения, а затем для обновления данных в Power BI. Импортированные данные можно
просматривать в отчетах и дашбордах, не обращаясь к источнику. Power BI
поддерживает единый вход (SSO) для некоторых источников данных, что
позволяет использовать учетные данные владельца семантической модели
при подключении к данным.
Для прямых подключений можно воспользоваться предварительно настроенными учетными данными или SSO. В первом случае все пользователи
обращаются к источнику данных с одними и теми же учетными данными.
Во втором используются учетные данные конкретного пользователя, что
повышает безопасность за счет потенциальной возможности использования
реализации RLS и OLS с источником данных.
При интеграции Power BI с Azure Databricks становятся доступны несколько
способов управления. Первый — импортировать данные непосредственно
из Databricks с использованием учетной записи сервиса. Второй — решение
с прямыми запросами через Databricks SQL, которое лучше реализуется с использованием сквозной аутентификации Microsoft Entra. Такой подход использует идентификационные данные конечного пользователя в Unity Catalog.
Когда вы отправляете запрос на аутентификацию хранилищу Databricks SQL,
оно проверяет привилегии доступа к данным через Unity Catalog, прежде
чем возвращать результаты запроса. Для обоих методов важно установить
детализированные политики управления доступом в Unity Catalog (для пользователей, напрямую потребляющих данные через Databricks SQL) и Power
BI. Чтобы глубже разобраться в этой интеграции и понять особенности ее
настройки, обратитесь к техническим статьям Publish to Power BI Online from
Azure Databricks (https://oreil.ly/gg1Li) и Access Control and Networking Security
with Power BI and Databricks (https://oreil.ly/N7zp9).
Интеграция между платформами (например, Azure Databricks и Microsoft
Fabric), включающая Power BI, требует поддержания согласованных политик

  

Безопасность данных и управление доступом

367

на обеих платформах. Если учесть, что каждая платформа использует собственную модель безопасности и механизмы контроля доступа, согласовать их
может быть непросто. Это потребует настройки ролей, разрешений и средств
контроля доступа между двумя системами. Кроме того, эффективное управление данными зависит от согласованных и хорошо управляемых метаданных.
При взаимодействии между платформами очень важно, чтобы метаданные
были синхронизированными и точными, отражали структуру данных, их использование и порядок получения, что, возможно, потребует дополнительных
инструментов или ручных процессов. То же относится и к контрактам данных,
которые должны быть согласованными и актуальными на всех платформах,
чтобы гарантировать, что совместное использование данных будет защищенным и безопасным.
Более того, полноценная архитектура защищает данные, объединяя разные механизмы безопасности на всех уровнях. На рис. 12.3 представлен пример архитектуры безопасности Azure Databricks.

Azure Databricks
• Мониторинг
• Unity Metastore
• Условные политики доступа
• Открытый доступ заблокирован

SaaS – подписка Microsoft
PaaS – подписка клиента

Storage
• Unity Catalog MI
• Открытый доступ
заблокирован

Databricks VNET
10.0.0.0/16

Databricks – user VNET
10.1.0.0/16

Кластеры
Databricks SQL

Рабочее место
пользователя

Подсеть хост/контейнер

Подсеть потребительского
рабочего пространства

• dps PE
Подсеть
Storage PE

• Auth PE
• Workspace PE

Entra

Подсеть
Databricks PE

• Минимальные привилегии доступа
• Требуется MFA

Рис. 12.3. Сетевая архитектура Azure Databricks с соблюдением рекомендуемых
лучших практик безопасности

  

368

Глава 12. Управление данными и безопасность в архитектуре медальона

Сетевая безопасность играет важнейшую роль, начиная с фундаментального
уровня. Ее можно значительно повысить, отделяя вычислительные кластеры от
рабочих мест пользователей и управляя как входящим, так и исходящим сетевым доступом между этими виртуальными сетями. Реализация таких мер, как
отключение открытого сетевого доступа, использование приватных эндпоинтов,
предоставление доступа только доверенным рабочим пространствам, обеспечение условного доступа и ведение списков доступа для IP-адресов, гарантирует,
что к сети будет допущен только авторизованный трафик. Эти меры не только
предотвращают несанкционированный доступ к данным, но и служат основной
линией защиты.
Рене Бремер (René Bremer) написал подробный пост (https://oreil.ly/0MMRg)
о безопасном подключении Microsoft Fabric к Databricks SQL. В нем содержится несколько архитектурных диаграмм с безопасными VNET и шлюзами.

Далее необходимо обеспечить аутентификацию и контроль доступа. Работая
с провайдерами корпоративных идентификационных данных (например, Entra
ID), а также реализуя SSO, MFA и требуя доступа только через VPN, система блокирует несанкционированный доступ с самого начала. После получения доступа
запускается авторизация. Задача этого этапа — определение ролей и разрешений.
Администраторы устанавливают конкретные правила, определяющие, к каким
данным могут обращаться пользователи и какие действия они могут выполнять, —
например, обращения к рабочим пространствам и элементам или такие действия,
как просмотр блокнотов и выполнение конкретных заданий.
Затем необходимо обеспечить безопасность данных — исключительно важный уровень архитектуры. Модель управления доступом к данным использует
подробные правила для определения того, какие приложения, пользователи
и группы могут обращаться к данным. Для улучшения этой модели используйте
пользовательские функции, а также теги или метки конфиденциальности для
классификации данных и контроля за соблюдением политик. Эти инструменты
определяют, кто может просматривать данные и как взаимодействовать с ними.
Последний элемент головоломки — мониторинг и комплаенс. Это включает
в себя отслеживание паттернов использования и проверку того, что все операции
соответствуют нормативным требованиям. Непрерывный мониторинг помогает
поддерживать целостность и безопасность всей системы.
Поверх всего этого строится фреймворк управления данными, который проверяет, что принятые меры реализуются, а процессы соблюдаются. В него входят
политики, процедуры и рекомендации, определяющие, как происходят обращения
к данным, их использование и защита. Также он включает регулярные аудиты для
обеспечения безопасности системы и комплаенса. Фреймворк поддерживается
каталогом, в котором хранятся теги, классификации, происхождение данных
и другие метаданные, например информация о владельце данных и их качестве.

  

Безопасность данных и управление доступом

369

И это еще не все. В федеративной модели метаданные безопасности и референсные данные играют важную роль в управлении доступом к данным в архитектуре медальона. Эти метаданные включают подробную информацию
об обращениях к данным, классификации и защите; они используются для
проверки того, что использование данных соответствует организационным
политикам и нормативам. Они особенно важны для контрактов данных, которые работают с чувствительной информацией (например, персональными
или финансовыми данными).
В архитектуре медальона для управления метаданными безопасности могут использоваться различные инструменты и методы. Один из эффективных методов
заключается во встраивании метаданных безопасности прямо в продукты данных.
Этот подход гарантирует, что средства контроля доступа и классификационная
информация всегда будут перемещаться вместе с данными.
Помните базу данных AdventureWorks, с которой вы работали во второй части
книги? В таблице клиентов присутствовал столбец с именем SalesPerson. Допустим, вы хотите ограничить доступ к этой таблице на основе столбца SalesPerson.
Для этого вы можете создать политику безопасности с помощью пользовательской
функции (https://oreil.ly/RM8JS). В примере ниже (https://oreil.ly/Eh3kh) приведен
фрагмент кода для ограничения доступа к таблице SalesLT.Customer в зависимости от столбца SalesPerson:
CREATE SCHEMA Security;
GO
-- Создание функции для SalesPerson
-- Предполагается, что имена в системе не длиннее 50 символов,
-- но это ограничение можно изменить
CREATE FUNCTION Security.udf_securitypredicate(@SalesPerson AS varchar(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS udf_securitypredicate_result
WHERE @SalesPerson = USER_NAME() OR IS_ROLEMEMBER('manager') = 1;
GO
-- Использование функции для создания политики безопасности
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.udf_securitypredicate(SalesPerson)
ON SalesLT.Customer
WITH (STATE = ON);
GO

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

  

370

Глава 12. Управление данными и безопасность в архитектуре медальона

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

Заключение
Завершая обсуждение масштабирования в контексте управления данными,
контрактов данных и безопасности данных, я подчеркнул важность каталогов
и метаданных в управлении и контроле за распределением данных. Но это не все.
Эффективная безопасность данных не сводится к простому созданию каталогов
или контрактов. Важная роль в ней отводится автоматизации и построению надежного фреймворка управления данными. В частности, это означает определение
ролей, создание понятных процессов и эффективных рабочих потоков, написание
политик и всестороннее обучение пользователей. Это комплексный подход, который требует большего, чем просто развертывание инструментов.
Чтобы масштабирование было эффективным, а архитектура стабильной и соответствующей нормативным требованиям, чрезвычайно важно в первую очередь
обеспечивать управление данными, стратегическое планирование и организационную согласованность. Эти условия формируют основу любой архитектуры
данных. Также необходимо, чтобы эти разные области развивались совместно.
Например, даже идеально спроектированная платформа данных бесполезна без
качественного управления данными, поскольку доверять этим данным нельзя.
С другой стороны, даже зрелая организация управления данными будет неэффективной, если ей не хватает стабильной платформы данных, так как нельзя будет
доверять обработке данных. Итак, чтобы успешно масштабировать архитектуру
медальона, убедитесь, что все ее области растут и становятся более зрелыми
параллельно.
В главе 13 мы погрузимся в интеграцию развивающихся технологий (таких, как
ИИ) и архитектуры медальона. Потенциал ИИ для автоматизации сложных
задач данных, расширения аналитики и развития интеллектуального принятия
решений открывает интересные возможности для эволюции таких архитектур.

ГЛАВА 13

Будущее архитектур медальона
с генеративным ИИ

В заключительной главе этой книги вы узнаете, как эволюционирующая структура медальона все сильнее переплетается с генеративным искусственным интеллектом1. Эта архитектура, традиционно ориентированная на структурирование
данных на бронзовом, серебряном и золотом уровнях, теперь должна учитывать
неструктурированные данные для ИИ-приложений. В этой главе рассматриваются два ключевых вопроса: 1) практично ли иметь унифицированную архитектуру
медальона для управления структурированными, полуструктурированными и неструктурированными данными? 2) в какой степени большие языковые модели
(LLM) можно интегрировать в существующие процессы, связанные с архитектурой медальона?
Открою карты: я твердо верю, что комплексное управление структурированными
и неструктурированными данными имеет огромную ценность, делая возможным
получение более разносторонних и эффективных выводов на основании данных
и ИИ. Кроме того, модели LLM кардинально меняют такие задачи управления
данными, как очистка и интеграция, что приводит к переосмыслению традиционных парадигм. Ожидается, что они повлияют на то, как инженеры и аналитики
взаимодействуют с данными, делая эти взаимодействия более доступными и пригодными на практике.
Чтобы вы лучше поняли суть этого перехода, начнем с обзора потенциальных проблем и возможностей, предоставляемых неструктурированными данными в современных ИИ-контекстах, уделяя особое внимание технологии RAG (RetrievalAugmented Generation, генерация с дополненной выборкой)2 для эффективного
использования таких данных. Затем мы опишем специфику каждого уровня
в архитектуре медальона в его отношении к ИИ, уделяя внимание процессам от

1

2

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

  

372

Глава 13. Будущее архитектур медальона с генеративным ИИ

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

Обработка неструктурированных данных
Современная архитектура медальона в основном работает со структурированными данными, хорошо организованными и удобными для поиска с использованием открытых табличных форматов (таких, как Delta Lake и Iceberg). Структурированный формат упрощает обработку и анализ, но не решает проблему
сложности управления неструктурированными данными, часто необходимыми
в современных системах.
Модели LLM в основном используются с контентом, хранящимся в полуструктурированных и неструктурированных форматах данных, включая самые разнообразные формы: файлы JSON и XML, PDF-документы, электронную почту,
контент социальных сетей, речь и изображения. Для эффективного управления
этими типами данных, обычно обладающими богатством возможностей наряду
со сложностью, требуются надежные и гибкие архитектуры. Начнем с изучения
RAG — ключевой схемы LLM для работы с неструктурированными данными.
После этого рассмотрим управление неструктурированными данными и их соответствие паттерну RAG. В завершение сделаем некоторые выводы.

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

  

Обработка неструктурированных данных

373

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

Актор

Генератор
промптов

1

Внедрение промпта

Данные
(неструктурированные
Фрагмент + внедрение
и/или
структурированные)

Передаваемый промпт +
контент

2

4

3

LLMs

Получение
семантически
связанного
контента

Векторная
база данных

Рис. 13.1. Паттерн RAG
Паттерн RAG также способен обрабатывать таблицы данных, а не только
неструктурированные данные. Он может обрабатывать ввод от различных
источников данных предприятия, таких как системы планирования ресурсов
(ERP) и управления клиентами (CRM) — как структурированных, так и неструктурированных.

После заполнения векторной базы данных система RAG дополняет исходный
промпт вспомогательным контентом, повышая его эффективность. Вот как
это происходит: когда пользователь или приложение вводит промпт (шаг 1 на
рис. 13.1), этот промпт преобразуется (шаг 2) в вектор с использованием той же
модели эмбеддинга, которая ранее применялась для заполнения базы данных.
На основе этого промпта система получает из базы данных (шаг 3) векторы,
ближайшие к нему, которые представляют наиболее релевантную информацию.
Затем этот контент интегрируется (шаг 4) с исходным промптом и обрабатывается
LLM. Сгенерированный ответ будет более точным и контекстно наполненным.
Чтобы паттерн RAG работал максимально эффективно, важно проследить, чтобы
данные были хорошо структурированными и организованными. Вот некоторые
типичные шаги для этого:
1. Сохранение сырых документов
Извлеките данные из структурированных и неструктурированных источников;
классифицируйте их по источнику, дате или бизнес-процессу.
2. Генерация метаданных документов
Сгенерируйте и извлеките метаданные: дату создания, заголовки документов,
номера страниц, URL и другую релевантную информацию.

  

374

Глава 13. Будущее архитектур медальона с генеративным ИИ

3. Организация и стандартизация документов
Проведите структурированную переработку документов в стандартном формате. Такая стандартизация документов расширяет возможности многократного
использования.
4. Фрагментация документов
Разбейте документы на меньшие, более удобные фрагменты (чанки) для эффективной обработки их моделью LLM.
5. Внедрение чанков
Модель эмбеддинга преобразует каждый чанк в числовой вектор.
6. Индексирование чанков в векторной базе данных
Загрузите векторные представления и тексты чанков в векторную базу
данных.
Чтобы эффективно управлять потенциалом неструктурированных данных в ИИсистемах и использовать его, очень важно согласовать между собой архитектурные
уровни. Мы уже очертили архитектуру медальона, состоящую из трех важнейших
уровней: бронзового, серебряного и золотого, служащих для последовательного
уточнения данных. Разберемся, как эти уровни согласуются с паттерном RAG
для оптимизации обработки данных и интеграции LLM. Затем рассмотрим более
сложные сценарии.

Бронзовый уровень
Бронзовый уровень определяет исходную стадию неструктурированного стека
данных, при этом первоочередное внимание уделяется их извлечению и загрузке.
В этой конфигурации бронзовый уровень служит той же цели, что и при сохранении и организации структурированных данных. В контексте неструктурированных данных на первый план выходит сохранение, извлечение и оптимизация
сырых данных для хранения и обработки. Этот фундаментальный уровень необходим для сбора неструктурированных данных из разных источников: файлов
логов, платформ социальных сетей, форм обратной связи от клиентов, электронной почты, документов научных исследований.
Для извлечения неструктурированных данных организации обычно применяют
такие средства, как формы отправки, веб-скрейперы, интеграция API и парсеры
файлов. В зависимости от типов данных и необходимой точности извлечения
компании могут либо разрабатывать специализированные средства, либо воспользоваться готовыми, такими как LlamaParse (https://github.com/run-llama/
llama_parse) и Tensorlake (https://github.com/tensorlakeai). Эти инструменты извлечения данных также пригодятся на серебряном и золотом уровнях, где они
обеспечивают возможность настройки с правилами парсинга и паттернами, чтобы

  

Обработка неструктурированных данных

375

лучше соответствовать потребностям извлечения конкретных данных. Мы еще
вернемся к этой теме в следующем разделе.
После извлечения данных организации переносят их в исходном файловом
формате (например, PDF, DOCX или TIFF) в систему хранения сырых данных — часто это сервис озер данных типа Azure Data Lake Storage. В ходе
переноса часто генерируются дополнительные метаданные, содержащие расширенный контекст (источник, формат, отправитель документа, дата создания
и т. д.). Эти метаданные обычно сохраняются в каталоге данных или вместе
с неструктурированными данными, обеспечивая понимание происхождения
и истории данных.
Для генерирования метаданных организации могут использовать малые языковые модели (SLM). Такие модели более эффективны и оптимизированы для
конкретных задач по сравнению с их большими аналогами. Модели SLM отлично проявляют себя в классификации, разметке, идентификации чувствительной
и персональной информации, извлечении сущностей и реферировании, что
делает их идеальными кандидатами для эффективной генерации метаданных.
Метаданные, генерируемые SLM, критически важны для последующих уровней
архитектуры медальона, так как они предоставляют контекст и дополнительную
информацию о неструктурированных данных. Эти метаданные также могут
передаваться на последующие уровни. Например, чувствительные данные
или PII-метки, сгенерированные моделями SLM на бронзовом уровне, могут
использоваться для обеспечения политик доступа к данным на серебряном
и золотом уровнях.
SLM также эффективно генерируют метаданные для структурированных
данных. Унификация управления как структурированными, так и неструктурированными данными считается лучшей практикой, повышающей согласованность и целостность систем данных. Чтобы эффективно масштабировать метаданные и управлять ими, выделите ресурсы на создание
надежного метахранилища или решения Data Fabric.

Еще одна задача бронзового этапа — первоначальная сортировка данных, создающая основу для последующей обработки. Эта задача аналогична организации
структурированных данных на бронзовом уровне, где основной целью является
сохранение данных в сырой форме при поддержании доступности. Для этого
организации часто создают папки или контейнеры, которые воспроизводят бизнес-процессы или происхождение данных, например каналы Teams или папки
SharePoint. Это помогает поддерживать порядок, упрощая обращение к данным
и их обработку. Более того, компании часто используют стратегию партиционирования, например организацию по дате для реализации версионирования разных
документов по времени. Этот метод преобразует неструктурированные данные
в архив по аналогии с использованием бронзового уровня со структурированными
данными, сохраняя их в сырой форме.

  

376

Глава 13. Будущее архитектур медальона с генеративным ИИ

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

Серебряный уровень
На серебряном уровне внимание смещается на уточнение и стабилизацию данных, что делает их подходящими для сценариев, управляемых ИИ. На этом этапе
важно обеспечить возможность многократного использования данных. Это не
только полезно для приложений RAG, но и облегчит будущую тонкую настройку
моделей — мы обсудим эту тему далее в разделе «Обучение и тонкая настройка
моделей LLM», с. 386.
На этом этапе сырые данные разбиваются на логически организованные единицы на основании семантически содержательных контекстов. Это подразумевает
детализированный процесс реструктуризации, разметки и очистки данных,
обеспечивающий их согласованность и удобство использования. В ход идут
такие приемы, как выявление шума и дубликатов, помогающее отфильтровать
неактуальную или ошибочную информацию, которая может снизить точность
вывода ИИ. Заметим, что модели LLM также полезны на этом этапе, поскольку
они помогают выявлять и исправлять ошибки в данных, гарантируя точность
и надежность информации.
Что касается качества неструктурированных данных, это в высшей степени
субъективно, и в процессе сбора в них даже может появиться смещение (bias).
Следовательно, для организаций важно создать собственные схемы оценки качества. Используйте LLM в качестве арбитра для наблюдения за работой схемы.
После проверки качества, очистки и партиционирования неструктурированные
данные часто форматируются в структурированный формат, пригодный для

  

Обработка неструктурированных данных

377

машинного чтения. Лучшей практикой для этого считается применение языков
разметки, прежде всего Markdown, поскольку они имеют простой и удобочитаемый синтаксис. Использование Markdown упрощает документы, делая их
более доступными на программном уровне и более простыми для обработки
ИИ-системами, что повышает их совместимость с различными инструментами
аналитики и платформами. Простота Markdown помогает ИИ-моделям более
эффективно парсить и усваивать контент, что особенно важно для таких задач,
как выборка информации, классификация и реферирование.
На этом этапе полезны такие фреймворки, как MarkItDown (https://oreil.ly/pLnsJ)
и PyMuPDF (https://oreil.ly/OzrQ0), поскольку они стандартизируют вывод и готовят данные к применению более сложных аналитических инструментов. После этого чистые и отформатированные данные готовы к углубленному анализу
и извлечению выводов. Благодаря простоте Markdown потенциальные ошибки,
связанные со сложным форматированием, сводятся к минимуму, это гарантирует,
что данные останутся целостными и неповрежденными.
Франческо Фава (Francesco Fava) опубликовал сквозную демонстрацию
применения Markdown для обработки данных и потребления LLM (https://
oreil.ly/uYxzE).

На этом этапе преобразования данных часто генерируются дополнительные метаданные, которые помогают ИИ-системам лучше понять контекст. Вот некоторые
из ключевых операций, выполняемых на серебряном уровне:
Реферирование больших документов и составление кратких резюме.
Разбиение сложных документов на меньшие, более удобные части. Также
может включать извлечение графики и таблиц из документов и сохранение
их отдельно, со ссылками на них. Обратите внимание: этот процесс не является частью фрагментации, которая обычно откладывается до более поздних
этапов, когда неструктурированные документы уточняются для конкретных
ИИ-приложений.
Перевод разных языков на один язык для единообразия (при помощи LLM).
Создание классификаторов и меток конфиденциальности данных. Например,
можно применить классификацию «Конфиденциально» исключительно на
основании типа контента и метку «Низкий риск» на основании средств конт­
роля доступа или потенциальных последствий раскрытия данных.
Классификация и категоризация текста.
Распознавание и извлечение сущностей, например использование LLM для
выявления и организации ключевой информации (имен сторон, дат заключения контрактов, обязательств) в структурированной базе данных для быстрого
обращения.

  

378

Глава 13. Будущее архитектур медальона с генеративным ИИ

Моделирование тем и анализ трендов.
Обработка чувствительных данных в документах посредством разбиения
файлов разметки на части, что делает возможным более детализированный
конт­роль доступа.
Сохранение метаданных в структурированном формате (например, в каталоге или хранилище метаданных) или параллельно с неструктурированными
данными в озере данных.
Для выполнения этих операций очень важно выбрать подходящие движки
обработки данных. Они различаются по разным параметрам, например по
назначению для обработки структурированных или неструктурированных
данных, а также по работе с одним узлом или в распределенной среде. Кроме
того, к данным, хранящимся на серебряном уровне, могут обращаться другие
вышележащие приложения. Например, программа для работы с графами знаний
может воспользоваться сущностями и другими метаданными, находящимися
на серебряном уровне.
После знакомства с этим разделом может возникнуть вопрос, почему в нем
такое большое внимание уделяется стандартизации и стабилизации неструктурированных данных на серебряном уровне. Запуск в эксплуатацию языковых
и обучающих моделей зависит от стабильных и предсказуемых данных, обеспечивающих надежные результаты, и серебряный уровень служит схожей цели. Он
готовит данные для быстрого развертывания новых приложений RAG и тонкой
настройки LLM для конкретных задач. Следовательно, конкретные стратегии
фрагментации придется отложить. Пройдя необходимую обработку, данные
будут готовы для дальнейшего использования в сложных ИИ-приложениях
на золотом уровне.

Золотой уровень
На золотом уровне данные адаптируются для конкретных потребностей определенных приложений. Этот уровень служит для повышения точности и специ­
фичности данных, чтобы гарантировать их идеальное соответствие целевому
использованию.
При подготовке неструктурированных данных для таких приложений, как
RAG, начать обработку необходимо с выбора самых релевантных документов
или объектов для конкретного сценария использования на основании конкретных критериев, например ключевых слов, тем или сущностей. И снова можно
провести параллель с процессом обработки структурированных данных, где
обобщенные данные выбираются и уточняются для конкретных аналитических
сценариев.
После выбора данных обычно следует шаг предварительной обработки, улучшающий данные для конкретного сценария. Такие методы, как аугментация

  

Обработка неструктурированных данных

379

данных, делают их более репрезентативными, точными и разнообразными. Этот
шаг гарантирует, что данные хорошо подойдут для предполагаемого применения,
например для обучения LLM под конкретную задачу или для эмбеддинга. И на
этом шаге важны языковые модели, так как они могут генерировать дополнительные точки данных и контекст или же уточнять существующие данные для
повышения качества датасета.
Следующий важный шаг — фрагментация данных и генерация эмбеддингов.
Именно на нем вводятся модели эмбеддинга, обеспечивающие представление
текста в виде векторов, инкапсулирующих семантический смысл данных. Мы
возвращаемся к обсуждению паттерна RAG, в котором данные преобразуются
в числовые представления и сохраняются в векторной базе данных. Обобщить
этот процесс для всех сценариев достаточно трудно, так как у каждого приложения
свои уникальные требования (какие данные нужны, стратегия фрагментации,
выбор модели представления и т. д.). Хотя фрагментация и создание эмбеддингов — разные задачи, они зависят друг от друга.
Стратегия фрагментации
Включает разбиение больших документов на меньшие, более удобные части,
или чанки, перед их обработкой моделью эмбеддинга. Эта стратегия очень
важна, поскольку в моделях эмбеддинга размер входных данных, которые они
могут эффективно обрабатывать, часто ограничен. Например, в приложениях,
отвечающих на вопросы, документы обычно разбиваются на чанки, соответствующие абзацам; это гарантирует, что каждый чанк будет содержать достаточно контекста для ответа на потенциальные вопросы. Кроме того, в моделях
также существует предельное количество лексем (токенов), после превышения
которого их производительность снижается или обработка ввода становится
невозможной. Таким образом, фрагментация необходима для эффективной
и точной обработки данных.
Модели эмбеддингов
Модели эмбеддингов играют важную роль в преобразовании текста в числовые
представления, отражающие семантический смысл контента. Выбор модели
эмбеддинга может повлиять на эффективность представления и сохранения
семантических отношений в тексте. Разные модели обладают разными возможностями в отношении отражения контекста, поддержки языков и кодировании
доменно-специфической информации. Например, модель эмбеддинга с низкой
размерностью обеспечит эффективность и минимальное потребление ресурсов, поэтому она лучше подходит для систем реального времени (например,
чат-ботов). С другой стороны, модель эмбеддинга с высокой размерностью
допускает сложные представления, которые идеально подходят для задач,
требующих тщательного анализа и точности, например академических исследований. А значит, следует выбирать модель, которая подходит для специ­
фических потребностей ваших приложений.

  

380

Глава 13. Будущее архитектур медальона с генеративным ИИ

Для упрощения эффективной выборки семантически коррелированных данных от LLM данные необходимо преобразовать в векторную форму, сохранить
и индексировать способом, поддерживающим быстрый и эффективный поиск.
Выбор подходящего способа хранения (например, векторных баз данных или
озер данных) обеспечит эффективное управление объемом и разнообразием
неструктурированных данных. Цель золотого уровня — преобразовать неструктурированные данные в форму не только структурированную, но и тщательно
курированную для конкретных приложений. Соответственно, на нем данные
теряют свою исходную неструктурированную форму и становятся более приспособленными для конкретной цели.
Такие движки баз данных, как Pinecone (https://pinecone.io) и Azure AI Search
(https://oreil.ly/SxKj8), часто применяются для обеспечения одновременно доступности и организованности данных с расчетом на поддержку процессов принятия
решений и повышения эффективности ИИ-приложений. Для архитектуры медальона это фактически означает, что данные предоставляются через сервисный
уровень, оптимизированный для ИИ-приложений.
Ожидается, что архитектуры медальона с движками, подобными Spark, будут
лучше поддерживать операции со столбцами векторных представлений, такими как точный или приближенный поиск ближайших соседей и поиск по
диапазонам. Пока такие движки с трудом справляются с большими объемами
векторных данных, из-за чего для векторных задач поиска больших данных
пользователям приходится использовать базы данных с открытым исходным
кодом, например LanceDB (https://lancedb.com), или распределенные ядра
векторных запросов, например Quokka (https://github.com/marsupialtail/quokka).
Но скорее всего, такое положение дел изменится к лучшему. Будущие разработки должны облегчить выполнение сложных операций с векторными
данными прямо в ядре Spark, что снимет необходимость в передаче данных
в специализированные векторные базы данных. Это позволит оптимизировать
процессы и объединить средства обработки данных в одной унифицированной
архитектуре.
Надежные практики управления данными чрезвычайно важны на всех уровнях
архитектуры медальона. Они помогают обеспечивать нормативно-правовое соответствие и безопасность данных. При распространении в организациях культуры,
управляемой данными, необходимо установить жесткие политики доступа к данным, использования и приватности для защиты конфиденциальной информации.
Кроме того, важно управлять связями с каталогом и внедрением семантической
контекстной информации о данных и документах. Это гарантирует, что данные
будут хорошо организованными, легко обнаруживаемыми и контекстно понятными, что обеспечит дополнительную поддержку эффективного управления
данными. Такой стратегический подход не только защищает данные, но и повышает уверенность при развертывании ИИ-приложений в различных отделах
и структурных подразделениях организации.

  

Интеграция LLM и архитектур медальона

381

Модели LLM и API Management
При разработке LLM-приложений важно понимать, что они тесно связаны с областью API Management1. Чтобы эффективно управлять этой
особенностью, необходимо добавить в архитектуру медальона связующий
уровень. Такая интеграция гармонизирует различные структуры данных
(API, продукты данных, события) в единую схему, необходимую для обес­
печения разнообразия способов потребления данных интеллектуальными
приложениями, включая LLM.
Проектирование стабильного решения интеграции приложений — сложная
задача, если учесть, что «правильных» и взаимодополняющих решений
может быть сразу несколько. Часто приходится искать компромисс между
различными параметрами: производительностью, удобством обслуживания, гибкостью, затратами, устойчивостью и т. д. Это может требовать
глубокого понимания поставленной бизнес-задачи. Следовательно, потребуется тесное взаимодействие с инженерами по интеграции приложения.
Командная работа гарантирует, что выбранное решение и паттерны будут
согласованы с целями организации.
Изучив особенности обработки неструктурированных данных, можно с уверенностью утверждать, что предписывающие маркеры архитектуры медальона отлично
подходят для повторного использования при управлении сложными неструктурированными данными. Используя иерархию архитектуры, можно обеспечить
разделение обязанностей в управлении неструктурированными данными. Более
того, использование LLM для генерирования метаданных расширяет возможности
управления как структурированными, так и неструктурированными данными.
Следовательно, унифицированная архитектура медальона подходит для обоих
типов данных, так как в ней согласуются разнородные дисциплины, что повышает
качество итогового результата.
Учитывая все сказанное об управлении неструктурированными данными, перей­
дем к тому, как объединить ИИ, и особенно модели LLM, с архитектурами медальона. Для этого рассмотрим несколько практических примеров.

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

API Management — процесс создания и публикации программных интерфейсов
веб-приложений (API) — Примеч. ред.

  

382

Глава 13. Будущее архитектур медальона с генеративным ИИ

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

Озеро
данных
(бронзовый)

Неструктурированные
документы,
файлы и т. д.

Фреймворки
парсинга
документов
и модели
LLM

Модели
LLM/SLM

1
Данные
в реальном
времени

Операционные
системы

Аналитика
в реальном
времени

Загрузка
данных
с Data
Factory

Аугментация

Инженерия
данных
Synapse

Модели LLM
Векторная
БД
(золотой)

Озеро
данных
(серебряный)

Использование вычислений
с большими данными
2
для генерирования
векторов

Аналитика
в реальном
времени

Инженерия
данных
Synapse

3

Хранилище
данных
Synapse

Общение
в диалоговом
режиме

Пользователи

Предоставление
дополнительного
контекста
Структурированные
данные
(бронзовый)

Структурированные
данные
(серебряный)

Структурированные данные
(золотой)

Рис. 13.2. Три сценария интеграции архитектуры медальона с LLM для оптимизации обработки данных
и улучшения интеграции приложений в разнообразных средах, управляемых ИИ
Ниже все три сценария рассматриваются более подробно.
Повышение качества преобразований данных, очистки и обогащения с помощью
LLM
Модели LLM отлично проявляют себя в преобразовании сложных полуструктурированных и неструктурированных датасетов, с чем у традиционных
методов нередко возникают затруднения. Как показано в сценарии № 1 на
рис. 13.2, модели LLM и SLM способны парсить данные в сложных форматах,
например извлекать ценную информацию из текстов, смешанных с числовыми

  

Интеграция LLM и архитектур медальона

383

данными из логов, электронной почты или отчетов. Для примера рассмотрим
организацию, которая работает с большим количеством файлов XML из
разных источников, каждый из которых имеет уникальную структуру. Традиционные методы интеграции данных плохо справляются с файлами XML
переменной структуры, потому что они работают по заранее определенным
схемам. В таких случаях языковые модели имеют значительное преимущество.
Им не нужно заранее знать структуру XML, так как они могут динамически
интерпретировать уникальное строение и контент каждого файла. Например,
если нужно извлечь такие специфические подробности, как дата транзакции
или информация о клиенте, из тысяч разных документов XML, модель LLM
справится с этим независимо от того, где именно в файлах эта информация
находится.
Другое важное преимущество LLM — то, что они подходят для обогащения
данных, предварительной обработки или генерации признаков. Для примера
возьмем Marvin (https://github.com/prefecthq/marvin). Система отлично проявляет себя в анализе тональности, структурировании данных и многозначной
классификации. Фреймворки на базе LLM повышают качество датасетов,
заполняя пропуски, расширяя точки данных и исправляя такие ошибки, как
опечатки или непоследовательность.
Помимо LLM, такие фундаментальные модели, как Nixtla TimeGPT-1
(https://github.com/Nixtla/nixtla), демонстрируют широкие возможности сложной обработки данных в области прогнозирования. Для этого они анализируют данные последовательностей (временн ы х рядов), чрезвычайно
важные в отраслях, зависящих от прогнозирования тенденций и закономерностей. Например, авиаперевозчик может использовать TimeGPT-1 для
анализа исторических данных бронирований и отмен заказов авиабилетов
для прогнозирования будущих объемов перевозок. Эта модель не только
прогнозирует будущие тенденции, но и повышает качество датасетов, выявляя сезонные колебания и возможные аномалии спроса (например, из-за
праздников или погодных условий). В отличие от традиционных алгоритмов
машинного обучения, требовавших обширного исходного обучения на данных, относящихся к конкретной организации, эти фундаментальные модели
предварительно обучаются на огромных массивах датасетов и поэтому
способны предоставлять полезную информацию сразу же. Это упрощает
процесс интеграции моделей в существующие архитектуры данных, что облегчает применение возможностей ИИ для обогащения и предварительной
обработки данных.
Использование Big Data для крупномасштабной обработки документов
Широкие возможности архитектуры медальона по обработке Big Data, как
показано в сценарии № 2 на рис. 13.2, обеспечивают надежные средства для разделения данных или документов на содержательные чанки. Такие фрагменты
могут обогащаться метаданными, тегами или другими (структурированными)

  

384

Глава 13. Будущее архитектур медальона с генеративным ИИ

данными. При хранении как структурированных, так и неструктурированных данных в одной архитектуре становятся возможными более сложные
приемы обогащения и их комбинации. После аугментации данные можно
преобразовать в векторы высокой размерности и хранить в специализированных векторных базах данных, таких как Azure AI Search (https://oreil.ly/hIhb).
Подобное использование обработки Big Data для эмбеддинга чанков может
снять ограничения традиционных методов эмбеддинга, устраняя такие проблемы, как ограниченная масштабируемость и неэффективность обработки
разнообразных типов данных.
Прямая поставка данных с уровней медальона в LLM
Прямая поставка данных с уровня медальона в модели LLM может значительно облегчить реализацию ИИ-приложений. Такой подход показан в сценарии
№ 3 на рис. 13.2. В качестве примера рассмотрим приложение для поддержки
клиентов. Прежде чем отправлять запрос моделям LLM, приложение собирает
структурированные данные (например, подробную информацию о клиенте) на
уровне архитектуры медальона. Затем пересматривает промпт, чтобы модель
LLM отвечала более точно. Объединяя типы данных в цепочку, LLM может
генерировать ответы, которые будут не только точными, но и релевантными
для специфического контекста пользователя.
Для простоты я не стал затрагивать такие темы интеграции сложных приложений, как использование шлюзов API (API Gateway). В реальных приложениях
подобная интеграция часто подразумевает частичное пересечение со стратегиями
API Management, как говорилось выше.
Интегрируя архитектуру медальона с LLM и паттернами интеграции приложений,
организации могут полноценно использовать свои данные, повышать рабочую
эффективность за счет автоматизации и предоставлять более персонализированные и отзывчивые сервисы, управляемые ИИ. Так можно не только получить от
данных максимальную практическую пользу, но и создавать более сложные приложения, которые без проблем взаимодействуют друг с другом и адаптируются
к потребностям пользователей в реальном времени.
Попробуем заглянуть в будущее. Применение ИИ значительно повлияет на
дизайн архитектур медальона, позволяя реализовывать более сложные сценарии. Эта эволюция будет сопровождаться увеличением значимости автономных
агентов, которые расширят архитектурные возможности динамического взаимодействия и обработки сложных структур данных.

Роль агентов
Архитектура медальона пока в основном используется для обработки табличных данных, но благодаря достижениям в области генеративного ИИ в ней
появляется все больше возможностей для управления неструктурированными

  

Роль агентов

385

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

Агенты

Процесс
эмбеддинга

Неструктурированные данные

Посадочная
зона

Парсинг
документов
(чанки)

Операционные
системы

Загрузка
с использованием
Data
Factory

Lakehouse
(Bronze)

Движок
промптов

Модели
LLM

Сохранение
чанков

Вектор
(серебряный
уровень)

Lakehouse
(Silver)

Warehouse
(Gold)

Рис. 13.3. Роли векторных баз данных и LLM в архитектуре медальона
Представим, как архитектура медальона может изменить будущее более сложными приложениями на базе ИИ. Допустим, компания-авиаперевозчик хочет
повысить уровень обслуживания клиентов при помощи интеллектуальных агентов, использующих такой фреймворк, как CrewAI (https://github.com/crewAIInc/
crewAI) или LangChain (https://github.com/langchain-ai). В таком сценарии несколько агентов взаимодействуют между собой, используя архитектуру медальона
с паттернами RAG или SQL. Каждый агент работает с конкретным датасетом,
например маршрутами пассажиров, профилями клиентов, часто пользующихся
услугами компании, графиками рейсов или поведением при покупке билетов.
Они применяют специально построенные промпты для получения релевантных
данных, которые, скорее всего, будут содержать смесь структурированных и неструктурированных данных.
Такие агенты не ограничиваются статическими данными; они также подключают
обновления в реальном времени от систем управления полетами, сервисов такси
и отчетов о воздушном трафике. Этот широкий набор паттернов помогает ИИ
адаптировать свои ответы к текущей ситуации и давать практические советы.
Например, если рейс пассажира задерживается, один агент может предложить
варианты компенсации, а другой изменит его дату заселения в гостиницу.

  

386

Глава 13. Будущее архитектур медальона с генеративным ИИ

При этом третий агент может объединить всю эту информацию в понятное
и доступное для пассажира сообщение. Такая совместная работа агентов позволяет авиакомпании предоставить быстрый и качественный сервис. Многоуровневая структура гарантирует, что ответ будет практичным и дружелюбным,
что улучшит опыт пассажира. В таком сценарии архитектура медальона служит
важной основой данных, обеспечивая бесшовные и персонализированные взаимодействия.
Несмотря на некоторый скепсис, ИИ-агенты быстро набирают популярность1. Согласно опросу State of AI Agents от LangChain (https://langchain.com/stateofaiagents),
включавшему 1300 участников, 51 % опрошенных компаний уже используют
агентов в рабочих системах, а 78 % планируют внедрить их в ближайшее время.
Таким образом, описанный сценарий — не мечты о будущем, а реальность, которая
уже воплощается в жизнь.
Итак, объединение архитектуры медальона с LLM и паттернами интеграции приложений позволит выявить новые возможности для сред, управляемых ИИ. Это
не только поможет извлечь максимальную ценность из существующих данных,
но и упростит разработку сложных интеллектуальных приложений, которые
бесшовно интегрируются и адаптируются к потребностям пользователей в реальном времени.
Посмотрим, как можно использовать архитектуру медальона для обучения и тонкой настройки моделей LLM.

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

1

Санджив Мохан (Sanjeev Mohan) объясняет принципы работы ИИ-агентов в своей
статье FAQ on Demystifying AI Agents (https://oreil.ly/eIGow).

  

Будущее архитектур медальона

387

Чтобы провести тонкую настройку модели (такой, какую предоставляет OpenAI),
сначала выберите соответствующие промпты из обучающего датасета. Эти промпты подаются на вход модели LLM, которая затем генерирует ответы. Эти примеры необходимо отформатировать (например, в JSON), чтобы каждый из них
содержал пару <промпт, ответ>. Далее необходимо выбрать базовую модель и два
датасета, обучающий и проверочный; модель проходит тонкую настройку на обучающем датасете. На последнем шаге производительность модели оценивается
на проверочных данных, и полученные результаты могут сравниваться с результатами более мощной модели или с ответами, сгенерированными человеком, для
достижения высокой эффективности.
В контексте управления данными с использованием архитектуры медальона
важно следовать установившимся лучшим практикам на бронзовом, серебряном
и золотом уровнях. На бронзовом уровне осуществляется сохранение сырых
документов и генерирование метаданных. Серебряный уровень служит для организации, стандартизации и подготовки документов, а золотой предназначен
для сбора датасетов, используемых в процессе тонкой настройки. Соблюдение
этих практик обеспечивает правильное разделение обязанностей и эффективное
повторное использование данных.
Тонкая настройка LLM — эффективный метод адаптации заранее обученных моделей для удовлетворения специфических требований различных задач или предметных областей, значительно повышающий их эффективность и релевантность.
Используя архитектуру медальона, можно адаптировать LLM для получения
точных и контекстуальных ответов, полностью соответствующих задачам бизнеса.
В свете влияния ИИ будущее архитектур медальона и их роль в формировании
управления данными выглядит весьма многообещающе.
Прежде чем завершить книгу, рассмотрим некоторые тенденции в этой области.

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

  

388

Глава 13. Будущее архитектур медальона с генеративным ИИ

ближайшие магазины, определять уровни срочности и т. д. Как показано
в главе 6, эта технология способна произвести революцию в области обогащения данных. Она сделает процесс более быстрым, точным и простым
в использовании.
Формирование генеративной бизнес-аналитики
Ожидается, что генеративный ИИ преобразует сферу бизнес-аналитики,
оптимизируя создание дашбордов и отчетов. Эта инновационная технология
позволяет пользователям формулировать запросы на естественном языке
и получать точные ответы, основанные на данных. Она упрощает создание
визуализаций и отчетов, устраняя необходимость в ручном написании кода
или проектировании. Возможно, в будущем благодаря этой технологии традиционные отчеты уйдут в прошлое. Вместо того чтобы проектировать отчет,
его можно будет просто сгенерировать по сохраненному промпту.
Однако важно признать, что для эффективной генеративной бизнес-аналитики
(GenBI) требуются обширные метаданные. GenBI должна иметь доступ к бизнес-терминам и определениям, популярным датасетам, часто используемым
отчетам, взаимосвязям между датасетами и т. д. Эти метаданные необходимы,
чтобы ИИ понимал бизнес-контекст и генерировал точные отчеты.
Контроль качества данных на базе ИИ
ИИ преобразует управление данными за счет интеллектуальных решений в области качества данных. Используя сложные алгоритмы машинного обучения,
ИИ может быстро проверять огромные объемы данных в поисках аномалий
и несоответствий. Это значительный шаг вперед по сравнению с традиционными ручными методами, которые работают медленнее и создают более высокий
риск ошибок. Например, Microsoft Purview использует машинное обучение
и генеративный ИИ, чтобы предлагать новые правила качества данных на
основании существующих метаданных.
Оптимизация интеграции данных с помощью ИИ
Традиционная интеграция данных может быть весьма трудоемкой задачей,
требующей ручных отображений и преобразований. ИИ помогает их автоматизировать, выявляя закономерности и взаимосвязи в данных, что обеспечивает
более точные и эффективные интеграции. Такие инструменты, как Prophecy
(https://prophecy.io), используют ИИ, чтобы помочь пользователям более эффективно создавать пайплайны данных и управлять ими, повышая качество
как приложений, так и аналитики на основе ИИ. В будущем интеграция данных с большой вероятностью будет включать семантическую информацию
о данных, чтобы автоматически выявлять и интегрировать данные за счет применения перекрестной корреляции с существующими бизнес-взаимосвязями.
Также можно подключить генеративный ИИ к процессу интеграции данных,
чтобы автоматически генерировать логику интеграции для преобразования
данных.

  

Будущее архитектур медальона

389

Управление данными с помощью ИИ
Также ожидается, что ИИ возьмет на себя главную роль в управлении данными, автоматизируя процессы для соблюдения нормативных стандартов и защиты ресурсов данных. Например, машинное обучение может использоваться для
соблюдения политик управления данными и мониторинга рисков нарушения
стандартов в реальном времени, снижая вероятность взлома. Генеративный
ИИ может использоваться для автоматической разметки и классификации
данных. Эта технология также расширяется для управления метаданными,
повышая обнаруживаемость и удобство использования данных.
ИИ для повышения производительности разработки
Инструменты генеративного ИИ, такие как GitHub Copilot, Copilot в Micro­soft
Fabric, Databricks Assistant, помогают разработчикам и специалистам в области данных повышать производительность своего труда. Эти инструменты
предоставляют рекомендации по кодингу и ответы на вопросы, что позволяет
ускорить процесс разработки и повысить качество кода. Подключая к своей
работе ИИ-ассистентов, пользователи могут повысить точность и релевантность генерируемых результатов.
Чаты с данными
Весьма вероятно, что в будущем появится возможность взаимодействия с данными через диалоги. Генеративный ИИ может интерпретировать датасеты,
облегчая и ускоряя выборку данных и принятие решений, чтобы дать бизнесу
конкурентные преимущества. Эта инновационная технология напоминает
генеративную бизнес-аналитику, но работает бесшовно, без традиционных
дашбордов.
Развитие навыков работы с ИИ
Создание диалоговых систем «вопрос — ответ» на таких платформах, как
Microsoft Fabric, позволяет пользователям получать точные, управляемые
данными ответы, просто задавая вопросы. Обучение ИИ на конкретных
инструкциях и примерах позволит ему лучше понять контекст организации,
повышая ее эффективность и расширяя область применения этой технологии. Подробнее об этом см. в статье AI Skill Example with the AdventureWorks
Dataset (Preview) (https://oreil.ly/laZJS).
Векторный поиск
Динамический механизм, который позволяет находить элементы со сходной
семантикой в любом датасете1. Применяемый метод основан на векторных
базах данных, которые хранят данные в формате, оптимизированном для по1

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

  

390

Глава 13. Будущее архитектур медальона с генеративным ИИ

иска на основании сходства. Эти базы данных особенно полезны при работе со
сложными типами данных, например изображениями, текстом или товарами
в электронном каталоге. Если преобразовать данные в векторы — математические представления данных в многомерном пространстве, векторный
поиск позволит запрашивать элементы, наиболее близкие к запросу. Такая
возможность чрезвычайно полезна для многих приложений (например, рекомендательных систем, извлечения изображений или поиска документов), она
улучшает пользовательские взаимодействия и позволяет извлекать больше
ценности из существующих данных.
GraphRAG
Метод, объединяющий графовые базы данных с паттерном RAG для повышения эффективности извлечения и генерации данных. Анализируя отношения
между сущностями в графовой базе данных, GraphRAG может выдавать более
контекстно-релевантные ответы на запросы. Это особенно полезно при работе
с взаимосвязанными данными: новостными источниками, исследовательскими статьями или базами знаний. Дополнительную информацию по этой теме
можно найти в исследовании Microsoft «GraphRAG: Unlocking LLM Discovery
on Narrative Private Data» (https://oreil.ly/rNr1d).
В конце нашего пути вернемся к исходным вопросам: какова общая практическая
ценность управления структурированными, полуструктурированными и неструктурированными данными? стоит ли интегрировать LLM в архитектуру
медальона? На оба вопроса я однозначно отвечу «да».
Управление сразу всеми типами данных имеет существенные преимущества,
обеспечивая более полную и эффективную аналитику. Кроме того, модели LLM
совершают революцию в таких задачах, как очистка данных и интеграция, заставляя нас переосмысливать традиционные методы. И хотя ИИ-технологии
пока находятся на стадии принятия, их потенциал в изменении организационных
процессов огромен и чрезвычайно интересен.
Завершая наше знакомство с архитектурой медальона, перечислим ключевые
выводы из нашего исследования.

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

  

Заключение

391

медальона. Команды должны понимать, к какому уровню относится то или иное
действие, — это чрезвычайно важно для сохранения ясности и последовательности
архитектуры. Разработка иерархического стандарта медальона в масштабах организации поможет убедиться, что действия всех участников синхронизированы.
Во второй части книги мы заполнили пробел между теорией и практикой, реализовав архитектуру медальона с использованием таких сервисов, как Microsoft Fabric
и Azure Databricks. Вы узнали, что создание бронзового уровня с поддержкой
запросов может быть сложной задачей, требующей надежной загрузки данных,
адаптированной к специфике систем-источников. Разбираясь в технических подробностях развертывания и управления пайплайнами данных, блокнотами и продуктами данных, вы узнали, как ориентироваться в этой многогранной задаче.
Вы узнали, что на серебряном уровне преобразование данных играет важнейшую
роль в общем пайплайне обработки. В частности, мы подчеркнули важность выполнения операций очистки данных, денормализации, обогащения и историзации данных в правильной последовательности, чтобы процесс проходил плавно.
Упрощая подход и включая методы, управляемые метаданными, мы обеспечили
простоту преобразования данных.
Говоря о золотом уровне, мы обсудили важность создания доступных, понятных
и рабочих продуктов данных. Вы увидели, как создать продукт данных, обладающий ценностью для бизнеса, и как обеспечить его надлежащее документирование
и простоту в обслуживании. Вы также узнали, что создание продукта данных — это
совместная работа, которая требует большого объема руководства.
В третьей части рассматривались препятствия, с которыми сталкиваются различные предприятия, и ценные выводы, которые можно сделать, устраняя эти
препятствия. У каждой организации свои специфические сложности и точки
роста, и ключом к успеху является выявление и решение своих проблем за счет
адаптированной архитектуры. Наши исследования продемонстрировали, как
можно гибко использовать архитектуры медальона для продвижения инноваций в бизнесе, повышения эффективности принятия решений и оптимизации
операций. Вы узнали, что архитектура медальона наиболее успешна, когда она
реализуется вместе с грамотными мерами по управлению данными и прочной
культурой инженерии данных.
В четвертой части мы изучили, как несколько архитектур медальона в федеративных и распределенных средах могут работать одновременно. При этом мы
столкнулись с проблемой разброса излишне фрагментированных продуктов
данных по разным доменам, которая решается внедрением надежных стандартов
и уполномоченного органа, наблюдающего за созданием продуктов данных. Это
потребует стандартизации в области моделирования данных и в области координации изменений и поставки данных. Надо признать, что это довольно сложные
задачи, поэтому для работы над ними важны продуманные схемы безопасности
и управления данными. Такие инструменты, как каталоги данных, помогут организациям управлять и более эффективно распоряжаться своими продуктами

  

392

Глава 13. Будущее архитектур медальона с генеративным ИИ

данных и бизнес-концепциями. Наконец, мы сделали вывод о практической
ценности внедрения LLM и целостного управления как структурированными,
так и неструктурированными данными с использованием единой схемы (архитектуры медальона).
В нашем исследовании создания архитектур медальона мы заложили гибкую
основу управления данными. Мы показали, как важно рассматривать уровни
этой архитектуры как логические, а не физические структуры. Универсальных
правил, которые подходят на все случаи жизни, не существует; необходимость
трех разных уровней зависит от специфических целей и сложности данных. Еще
важнее, что ключевым условием успеха является эффективное моделирование
данных. Как и в традиционных хранилищах данных, некачественное моделирование снижает целостность и удобство использования данных. Следовательно,
организации должны поощрять развитие навыков моделирования данных в своих
командах, чтобы архитектура медальона (или любая архитектура данных) работала эффективно и результативно.
Эффективное управление преобразованием данных не менее важно, чем наличие
надежной архитектуры. Чтобы начать этот путь, необходимо сосредоточиться
на коммуникациях, обучении, тщательной организации управления данными
и согласованности действий внутри организации. Все эти области чрезвычайно
важны, не стоит их недооценивать. Вам понадобятся компетентные руководители, способные контролировать и согласовывать разнообразные процессы.
Они должны обладать четким видением и умением организовывать проектные
и стратегические сессии. Они должны быть практиками и обладать лидерскими
качествами, чтобы мотивировать сотрудников. Необходимо разработать хорошо
продуманный план преобразований данных, включающий четкую дорожную
карту для достижения осязаемых результатов. Потенциальные сложности связаны с необходимостью работать сразу в нескольких направлениях. Вам придется параллельно создавать и совершенствовать технологические архитектуры,
внедрять схемы управления данными, заботиться о повышении квалификации
и обучении, формировать культуру работы с данными и обеспечивать согласованность с интересами бизнеса. И при всей сложности это просто необходимо для
успеха инициативы преобразования данных.
Интеграция генеративного ИИ в управление данными открывает интересные
новые возможности. Хотя технология генеративного ИИ все еще развивается,
ее потенциал для преобразования процесса управления данными огромен, и ему
стоит уделять первоочередное внимание, поскольку, скорее всего, именно он
окажет наибольшее влияние на эволюцию архитектур данных.

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

Иллюстрация на обложке
На обложке книги изображен серогрудый краснохвостый попугай (Pyrrhura
griseipectus). Этот вид, находящийся под угрозой исчезновения, на момент написания книги встречается только в северовосточных лесах Бразилии, хотя активисты
достигли заметных успехов в защите этого вида от браконьеров и вырубки лесов.
Серогрудые краснохвостые попугаи невелики (обычно 20–22 см от головы до
хвоста) и лишены полового диморфизма. И у самцов, и у самок зеленые тела,
красно-белые головы, ярко-красные хвосты и серые перья на груди, благодаря
которым этот вид получил свое название. Это социальные животные, живущие
группами от 4 до 15 особей. Они вьют гнезда в стволах старых деревьев.
Сейчас популяция серогрудых краснохвостых попугаев понемногу растет. Многие животные на обложках книг O’Reilly находятся под угрозой вымирания; все
они важны для мира. Иллюстрация на обложке принадлежит Хосе Марзану мл.
(José Marzan Jr.), она была создана на основе античной гравюры из Королевской
естественной истории Лидеккера. Дизайн серии был разработан Эди Фридментом (Edie Freedman), Элли Волкхаузен (Ellie Volckhausen) и Карен Монтгомери
(Karen Montgomery).

Питхейн Стренгхольт
Архитектура медальона.
Проектирование с помощью Delta Lake и Spark
Перевел с английского Е. Матвеев
Научный редактор Н. Марков

Изготовитель: ТОО «Спринт Бук». Место нахождения и фактический адрес:
010000, Казахстан, город Астана, район Алматы, проспект Ракымжан Кошкарбаев, д. 10/1, н. п. 18.
Дата изготовления: 04.2026. Наименование: книжная продукция. Срок годности: не ограничен.
Подписано в печать 25.03.26. Формат 70×100/16. Бумага офсетная. Усл. п. л. 32,250. Тираж 500. Заказ 0000.

Джеймс Серра

АРХИТЕКТУРЫ ДАННЫХ:
СОВРЕМЕННЫЕ РЕШЕНИЯ
ДЛЯ ЛЮБЫХ ЗАДАЧ

Ткань данных, озеро данных и сетка данных появились относительно недавно и стали рассматриваться как конкурентные альтернативы современному хранилищу данных. У новых архитектур действительно есть весомые
преимущества, но, помимо этого, они окружены ореолом предубеждений
и мифов. Книга содержит практический обзор архитектур данных, который
поможет специалистам в области обработки данных понять преимущества
и недостатки каждой из них.
Джеймс Серра, архитектор решений Big Data и хранилищ данных, работающий в Microsoft, рассматривает общие концепции архитектур данных, в том
числе то, как хранилищам данных пришлось эволюционировать, чтобы работать с функциями озер данных. Вы узнаете, чем хороши озера-хранилища
данных, а также как отличить раздуваемый вокруг сеток данных ажиотаж от
их реальных возможностей. А самое главное, вы научитесь определять наиболее подходящую архитектуру данных для своих нужд.

Билджин Ибрам, Роланд Хасс

ПАТТЕРНЫ KUBERNETES:
ШАБЛОНЫ РАЗРАБОТКИ
ОБЛАЧНЫХ ПРИЛОЖЕНИЙ
2-е издание

«Паттерны Kubernetes» — это не очередное справочное руководство по настройке кластеров или описанию API. Это фундаментальный труд, который
отвечает на самый главный вопрос: как эффективно проектировать и строить
приложения, предназначенные для работы в Kubernetes? Билджин Ибрам
и Роланд Хасс систематизировали лучшие практики сообщества, преобразовав их в паттерны. Книга учит не просто использовать Kubernetes, а мыслить
категориями платформы, правильно комбинируя примитивы для создания
отказоустойчивых, масштабируемых и удобных в эксплуатации систем. Это
must-read для любого разработчика, который хочет выйти за рамки простого
деплоя контейнеров и овладеть всеми возможностями Kubernetes.
Каждый паттерн включает описание проблемы и решение с использованием Kubernetes. Все паттерны сопровождаются конкретными примерами
кода. Это обновленное издание идеально подходит для разработчиков
и архитекторов, которые знакомы с базовыми концепциями Kubernetes, но
хотят узнать, как решать задачи проектирования с помощью проверенных
паттернов.

Питхейн Стренгхольт

МАСШТАБИРУЕМЫЕ ДАННЫЕ.
ВЫСОКОНАГРУЖЕННЫЕ
АРХИТЕКТУРЫ, DATA MESH
И DATA FABRIC
2-е издание

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

Эндрю Блок, Кристиан Эрнандес

ARGO CD. БЫСТРЫЙ СТАРТ

Узнайте, как управлять кластерами Kubernetes и конфигурациями приложений с помощью Argo CD — простого и удобного инструмента GitOps
с открытым исходным кодом. Благодаря этому практическому руководству
команды разработчиков быстро освоят базовые навыки использования Argo
CD для развертывания контейнерных приложений и управления ими — без
полного доступа к существующей среде Kubernetes.
С тех пор как Kubernetes прочно утвердился в качестве фундамента всей
облачной экосистемы, его способность эффективно управлять конфигурациями платформы превратилась в первоочередную задачу. Авторы этой
книги — Эндрю Блок из Red Hat и Кристиан Эрнандес из Akuity — расскажут,
как с помощью Argo CD уверенно управлять и одной, и даже тысячами сред
Kubernetes. Сначала вы познакомитесь с основами технологии Argo CD,
а затем будете развивать эти знания, пока не научитесь быстро и безопасно
развертывать свои приложения.

Кори Джей Болл

ХАКИНГ API: ВЗЛОМ
ПРОГРАММНЫХ ИНТЕРФЕЙСОВ
ВЕБ-ПРИЛОЖЕНИЙ

«Хакинг API» — это экспресс-курс по тестированию безопасности веб-API.
Взламывайте API, ищите уязвимости, которые часто упускают даже опытные
специалисты, и обеспечивайте безопасность ваших собственных API.
Сначала вы разберетесь, как на самом деле работают REST API и какие уязвимости для них наиболее характерны. Затем создадите эффективную среду
тестирования API с помощью Burp Suite, Postman, Kiterunner, OWASP Amass
и других инструментов, предназначенных для разведки, анализа и тестирования защищенности конечных точек. Затем, вооруженные этими знаниями,
научитесь проводить самые популярные виды атак для взлома механизмов
аутентификации, искать ошибки в бизнес-логике и выявлять специфические
слабые места API. Узнаете, что такое межсайтовый скриптинг и массовое
переназначение параметров, а также какие уязвимости, связанные с инъекцией кода, часто встречаются в веб-приложениях.