E-Book
7 Tage kostenlos im Abo
E-Book
13,99 €

Масштабируемые данные. Высоконагруженные архитектуры, Data Mesh и Data Fabric E-Book

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

0,0

Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.

Herausgeber: Спринт Бук
Kategorie: Wissenschaft und neue Technologien
Sprache: Russisch

Beschreibung

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

Details

Sie lesen das E-Book in den Legimi-Apps auf:

Android

iOS

von Legimi
zertifizierten E-Readern

Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 575

Veröffentlichungsjahr: 2025

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android

iOS

Bewertungen

0,0

Rezensionen(0 Rezensionen)

Ähnliche

Leseprobe

Переводчик Л. Киселева

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

Масштабируемые данные. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд.. — Астана: "Спринт Бук", 2025.

ISBN 978-601-09-9693-9

Предисловие

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

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

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

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

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

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

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

Джей Крепс (Jay Kreps), соучредитель и генеральный директор Confluent

Введение

Управление данными — это новая и революционная тема. Датафикация (https://bigenc.ru/c/datafikatsiia-b25456) присутствует повсеместно. Эта трансформация происходит повсюду: в смартфонах, телевизорах, электронных книгах, промышленных машинах, автомобилях с автопилотами, роботах и т.д. Она стремительно меняет нашу жизнь.

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

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

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

• Предприятия испытывают трудности с интерпретацией таких новых понятий, как сетка данных (data mesh) и фабрика, или ткань, данных (data fabric), потому что отсутствуют практические рекомендации и опыт. Кроме того, сетка данных в полной мере реализует децентрализованный подход, что является революционным изменением не только для архитектуры данных и технологий, но и для организации и производственных процессов. Это означает, что изменение касается не только ИТ-инфраструктуры, но и самого бизнеса.

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

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

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

Почему я написал эту книгу и почему сейчас

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

Термин сетка данных (data mesh) как описание социотехнического подхода к использованию данных был придуман примерно в то время, когда рукопись первого издания была практически готова. Когда статья Жамака Дехгани (Zhamak Dehghani), описывающая эту концепцию, появилась на сайте Мартина Фаулера (Martin Fowler; https://oreil.ly/Metdq), она раскрыла конкретные названия концепций, которые мы уже использовали в ABN AMRO много лет. Эти названия стали отраслевыми терминами, и концепция быстро начала находить отклик в крупных организациях как решение проблем, с которыми сталкиваются предприятия при масштабировании.

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

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

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

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

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

Для кого предназначена эта книга

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

Руководители и архитекторы

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

Аналитические группы

Дата-сайентисты, дата-инженеры, аналитики данных и руководители аналитических отделов.

Команды разработчиков

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

Группы контроля и управления

Руководители службы информационной безопасности, специалисты по защите данных, аналитики информационной безопасности, руководители по соблюдению нормативных требований, операторы баз данных и бизнес-аналитики.

Как работать с этой книгой

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

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

Чтобы вам было проще ориентироваться в книге, в табл. В.1 приводится общий обзор тем, которые будут подробно обсуждаться в каждой главе.

Таблица В.1. Ключевые темы, рассматриваемые в каждой главе

Гл. 1

Гл. 2

Гл. 3

Гл. 4

Гл. 5

Гл. 6

Гл. 7

Гл. 8

Гл. 9

Гл. 10

Гл. 11

Гл. 12

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



Стратегия данных



Архитектура данных



Интеграция данных



Моделирование данных



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



Защита данных



Качество данных



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



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



Бизнес-аналитика



Продвинутая аналитика



Архитектура предприятия



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

В следующих главах обсуждаются особенности распределения данных. Глава 4 фокусируется на продуктах данных, разделении ответственности на команды и запросы (Command Query Responsibility Segregation, CQRS) и руководящих принципах, а также представляет пример разработки решения. Глава 5 обсуждает управление API, а глава 6 — управление событиями и уведомлениями. Глава 7 объединяет сведения из предыдущих глав в общий обзор, дополненный рекомендациями по организации архитектуры и примерами из личного опыта.

Далее мы погрузимся в более сложные темы управления данными. В главе 8 изучается подход к управлению данными и обеспечению безопасности с применением способов, практичных и устойчивых в долгосрочной перспективе — даже в быстро меняющихся обстоятельствах. В главе 9 подробно рассказывается об использовании, значении и потенциале демократизации метаданных. Глава 10 предлагает руководство по управлению основными данными (master data management, MDM) для обеспечения их единообразия в распределенных, широкомасштабных активах, а глава 11 рассматривает превращение данных в ценность. Глава 12 завершает книгу примером архитектуры предприятия и будущего управления данными.

Условные обозначения

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

Курсив

Обозначает новые или важные термины.

Интерфейс

Используется для обозначения URL, адресов электронной почты.

Моноширинный шрифт

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

Этот элемент обозначает совет или предложение.

Этот элемент обозначает общее примечание.

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

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

Я хотел бы поблагодарить Джессику Стренгхольт-Гайтенбек (Jessica Strengholt-Geitenbeek) за то, что она позволила мне написать эту книгу. Она поддерживала меня на всем пути, заботясь о наших детях и создавая благоприятные условия для моей работы. Она — любовь всей моей жизни.

Я также хотел бы поблагодарить ABN AMRO и особенно Сантоша Пиллаи (Santhosh Pillai) за доверие и за то, что он был моим наставником на протяжении всей моей карьеры в этой компании. Многие идеи зародились именно в его голове. Эта книга не появилась бы без наших с ним дискуссий. Также я хотел бы поблагодарить корпорацию Microsoft за поддержку в написании этого второго издания. Кроме того, множество других людей поддержали книгу и написали к ней отзывы: в частности, Тим Уорд (Tim Ward; директор CluedIn), Батухан Тутер (Batuhan Tuter), Насим Мехршид (Nasim Mehrshid), Роб Уорралл (Rob Worrall), Фрэнк Лейстен (Frank Leisten) и др.

Спасибо техническим рецензентам книги Джону Маллиндеру (John Mallinder) и Оле Олесен-Банье (Ole Olesen-Bagneux). Ваши ценные идеи и отзывы помогли сделать эту книгу лучше.

Наконец, спасибо замечательной команде O’Reilly за их поддержку и доверие. Шира (Shira), спасибо вам за заботу обо мне. Мне нравилось беседовать с вами, и я благодарен вам за ваши конструктивные отзывы. Кэти, спасибо вам за вашу постоянную поддержку и проницательность. Спасибо моему замечательному редактору Рэйчел Хэд (Rachel Head) за проделанную работу по просмотру и редактированию текста всей книги. Вы приложили титанические усилия, чтобы привести в порядок написанный мною текст.

1 В книге я выражаю личные взгляды. Они не отражают точку зрения ABN AMRO и Microsoft.

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

От издательства

Мы выражаем огромную благодарность клубу рецензентов ИТ-литературы ReadIT Club за помощь в работе над русскоязычным изданием книги и их вклад в повышение качества переводной литературы.

Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство SprintBook, компьютерная редакция).

Мы будем рады узнать ваше мнение!

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

Дмитрий Бардин — ведущий разработчик, архитектор решений, один из авторов курса «Архитектор ПО» от «Яндекс Практикума». В настоящее время занимается разработкой бэкенда «КиноПоиска» с применением языков Go и Java. В прошлом руководитель службы продуктовой разработки и ресурс-менеджер. Опыт в ИТ — более 15 лет.

Глава 1. Дорога в мир, управляемый данными

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

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

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

Последние технологические разработки и тенденции в отрасли

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

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

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

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

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

• Фабрика, или матрица, данных (data fabric, https://oreil.ly/bjl2F) — это подход к решению современных проблем управления данными и масштабируемости за счет добавления искусственного интеллекта и упрощения доступа к данным путем внедрения методов самообслуживания. В отличие от сетки данных, этот подход больше фокусируется на технологическом уровне. Это архитектурное видение, основанное на использовании унифицированных метаданных и интегрированного сквозного уровня (матрицы) для упрощения доступа, интеграции, предоставления и использования данных.

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

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

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

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

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

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

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

Под управлением данными (data management) подразумеваются процедуры и процессы, применяемые для организации данных. Руководство DAMA International по комплексу знаний об управлении данными (DAMA-DMBOK) (https://oreil.ly/BKIm6) дает более развернутое определение: «Управление данными — это разработка, выполнение и контроль планов, политик, программ и практик, которые доставляют, контролируют, защищают и повышают ценность данных и информационных активов на протяжении их жизненного цикла»4.

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

Рис. 1.1. Одиннадцать функциональных областей управления данными

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

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

• Архитектура данных. Это мастер-план данных. Позволяет шире взглянуть на вашу архитектуру, включая схемы6, эталонные архитектуры, видение перспективы и зависимости. Управление этими аспектами помогает организациям принимать решения. Тематика всей книги вращается вокруг архитектуры данных в целом, но сама область и ее задачи полностью раскрываются в главах 2 и 3.

• Моделирование и проектирование данных. Это структурирование и представление данных в определенном контексте и конкретных системах. Сюда относятся обнаружение, проектирование и анализ требований к данным. Эти темы мы обсудим в главах 4, 7 и 11.

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

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

• Интеграция и согласованность по данным включают в себя все дисциплины и действия по транспортировке, сбору, объединению и трансформации данных для эффективного их перемещения из одного контекста в другой. Согласованность по данным — это возможность взаимодействия путем вызова функций или передачи данных между различными приложениями способами, не требующими знания характеристик приложения. Интеграция данных — это объединение данных из разных (нескольких) источников в одно представление. Этот процесс, который я считаю наиболее важным, часто поддерживается такими дополнительными инструментами, как инструменты репликации и ETL (extract transform and load — «извлечение, преобразование и загрузка»). Процесс подробно описан в главах 4, 5 и 6.

• Управление документами и их содержимым — это процесс управления данными, хранящимися в неструктурированных документах. Некоторые стороны этой деятельности будут рассматриваться в главах 5 и 6.

• Управление справочными и основными данными проводится для обеспечения доступности, точности, безопасности, прозрачности и надежности данных. Эта область более подробно описана в главе 107.

• Хранение данных и бизнес-аналитика включают все виды деятельности, помогающие понять происходящее в бизнесе и принять обоснованное решение. Эта область описана в главе 11.

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

• Управление качеством данных необходимо, чтобы гарантировать пригодность данных к использованию. Некоторые дисциплины из этой области описаны в главах 2 и 3.

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

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

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

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

Аналитика фрагментирует ландшафт данных

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

Новая языковая модель ChatGPT от OpenAI (https://openai.com) — ошеломляющий пример способностей ИИ. Модели, лежащие в основе OpenAI, в том числе серия генеративных предварительно обученных трансформеров (Generative Pre-trained Transformer, GPT), способны справляться с весьма сложными заданиями, такими как анализ математических задач, написание фрагментов кода, создание эссе для книг, составление рецептов с использованием списка ингредиентов и многие другие.

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

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

Развитие аналитических методов означает ускоренный рост объема данных: соотношение чтения и записи значительно меняется. Например, аналитические модели, которые постоянно переобучаются, считывают большие объемы данных. Это влияет на приложения и структуру БД, требуя оптимизировать доступность данных для чтения, и может означать следующее: чтобы избавить системы от необходимости постоянно обслуживать данные, их нужно дублировать. Это также может означать необходимость дублирования данных для их предварительной обработки из-за разнообразия и большого количества вариантов использования и шаблонов чтения, которые сопутствуют этим вариантам. Кроме того, может понадобиться создать различные представления одних и тех же данных для разных потребителей. Сложно привести в порядок такое разнообразие шаблонов чтения при одновременном дублировании данных и сохранении контроля. Решение этой проблемы описано в главе 4.

Скорость доставки программного обеспечения меняется

В современном мире программные сервисы составляют основу бизнеса. Это означает, что нужно быстро выпускать обновления. В ответ на требования большей гибкости в таких компаниях, как Amazon, Netflix, Meta, Google и Uber, появились новые идеологии: они продвинули свою практику разработки программного обеспечения на основе двух убеждений.

Первое убеждение: разработку (development, Dev) и эксплуатацию программного обеспечения (operations, Ops) нужно объединять. Это поможет сократить жизненный цикл разработки и обеспечить непрерывную поставку качественного ПО. Такая методология называется DevOps. Она требует новой культуры, где есть место для большей автономии, открытого общения, доверия, прозрачности и междисциплинарной командной работы.

Второе убеждение касается размера разрабатываемого приложения. Ожидается, что гибкость и скорость разработки системы возрастут, если приложения превратятся в более мелкие сервисы, выполняющие различные задачи. Этот подход к разработке характеризуется несколькими модными словами: микросервисы (https://microservices.io/), контейнеры, Kubernetes (https://kubernetes.io/), предметно-ориентированное проектирование, бессерверные вычисления и т.д. Я не буду вдаваться в подробности каждой концепции, но эта эволюция разработки программного обеспечения связана с повышенными сложностью и спросом на модернизированный контроль данных.

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

Сдвиг в разработке ПО требует создания архитектуры, позволяющей более детализированным приложениям распределять свои данные. К тому же нужна новая культура DataOps (https://oreil.ly/G8Bt4) и другая философия проектирования с большим упором на совместимость данных, фиксацию неизменяемых событий, а также воспроизводимые и слабые связи. Мы подробнее обсудим это в главе 2.

Влияние облачных технологий на управление данными не поддается измерению

Сети становятся быстрее, а пропускная способность из года в год увеличивается. Крупные поставщики облачных услуг доказали возможность перемещения терабайтов данных в облаке за считаные минуты, что позволяет реализовать интересный подход: вместо увеличения вычислительной мощности для обработки данных в одном месте, что было распространенной практикой из-за сетевых ограничений, мы можем распределить данные и обрабатывать в разных местах. Сеть больше не является препятствием, поэтому мы можем быстро перемещать терабайты данных между средами, давая приложениям возможность потреблять и использовать их. Такая модель становится особенно интересной с ростом популярности рынков программного обеспечения как услуги (Software as a Service, SaaS) и машинного обучения как услуги (Machine Learning as a Service, MLaaS). Вместо того чтобы выполнять сложные операции самостоятельно, мы можем использовать сети для передачи данных другим сторонам.

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

Приоритет — вопросы конфиденциальности и безопасности

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

UpGuard (https://oreil.ly/TzrsU) ведет длинный список крупнейших утечек данных, многие из которых обусловлены повторением одних и тех же ошибок. Утечка в Cambridge Analytica (https://oreil.ly/lLZSG) и 500 миллионов взломанных учетных записей в Marriott (https://oreil.ly/0zJdf) — впечатляющие примеры разразившихся скандалов. Правительства принимают все более активное участие в управлении данными, потому что наша личная и профессиональная жизнь теперь связана с интернетом. Пандемия COVID-19, вынудившая многих из нас работать и общаться из дома, ускорила эту тенденцию. Предприятия не могут позволить себе игнорировать угрозы нарушения прав интеллектуальной собственности и скандалы, связанные с конфиденциальностью данных.

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

Это лишь один пример ненадлежащего использования данных. Компании будут совершать ошибки и пересекать границы этических норм. Я думаю, что правительства ужесточат регулирование, требуя большей безопасности, контроля и внимания. Я перечислил лишь малую часть проблем, связанных с конфиденциальностью данных и этическими сложностями. Новые европейские законы об управлении данными (https://oreil.ly/phxAG) и искусственном интеллекте (https://oreil.ly/NiT1T) заставят большие компании быть честными в плане того, какие данные собираются, покупаются, объединяются, анализируются и распространяются (продаются). Крупным компаниям необходимо задуматься о подходах, ориентированных на прозрачность и конфиденциальность, и о том, как решать серьезные вопросы регулирования.

Регулирование — сложная тема. Представьте ситуацию, когда имеется несколько облачных регионов и SaaS-сервисов, между которыми распределены данные. Добиться соответствия таким нормативным актам, как GDPR (https://gdpr-info.eu), CCPA (https://oreil.ly/xzWpY), BCBS 239 (https://oreil.ly/zFj8I) и новая трансатлантическая программа защиты персональных данных (Trans-Atlantic Data Privacy Framework; https://oreil.ly/qDuto), в подобной ситуации довольно сложно, поскольку компании должны управлять всеми персональными данными независимо от того, где они хранятся. Управление данными и правильная обработка персональных данных являются главными задачами современной повестки дня для многих крупных компаний10.

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

Необходимо интегрировать аналитические системы и системы обработки транзакций

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

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

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

Организации работают в экосистемах сотрудничества

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

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

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

Предприятия обременены устаревшими архитектурами данных

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

Корпоративное хранилище данных: единственный источник истины

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

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

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

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

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

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

Большой ком грязи

Большой ком грязи (https://oreil.ly/8bY2t) — хаотично устроенные, раскидистые джунгли из спагетти-кода, скрепленного изолентой и проволокой. Этот популяризированный термин был впервые введен Брайаном Футом (Brian Foote) и Джозефом Йодером (Joseph Yoder). Большой ком грязи описывает системную архитектуру — монолитную, трудную для понимания и обслуживания и тесно связанную из-за множества зависимостей. На рис. 1.3 показана иллюстрирующая это диаграмма зависимостей (https://oreil.ly/Fdckr). Каждая линия означает связь между двумя программными компонентами.

Рис. 1.3. Диаграмма зависимостей, образующих большой ком грязи

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

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

Качество данных тоже часто оставляет желать лучшего. Кому принадлежат данные в хранилищах? Кто несет ответственность, если исходные системы доставляют поврежденные данные? Я анализировал ситуации, когда инженеры сами решали вопросы качества данных. В одном случае они исправляли данные на промежуточном уровне, чтобы правильно загрузить их в хранилище. Эти исправления стали постоянными, и со временем пришлось применить сотни дополнительных сценариев, прежде чем можно было начать обработку данных. Подобные сценарии не являются частью заслуживающих доверия процессов ETL и не позволяют отследить происхождение данных (https://oreil.ly/tGbQC).

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

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

Озеро данных: централизованное хранилище структурированных и неструктурированных данных

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

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

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

Создавать озера данных, как и хранилища, непросто. Такие компании, как Gartner, VentureBeat AI и Deloitte, сообщают о высокой доле неудачных проектов внедрения озер данных — больше 60 %17. Реализации озер обычно терпят неудачу отчасти из-за их огромной сложности, проблем с обслуживанием и общих зависимостей.

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

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

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

Эти проблемы — лишь часть причин, по которым терпят неудачу многие проекты, связанные с big data. К прочим можно отнести сопротивление руководства, внутреннюю политику, недостаток опыта, а также проблемы безопасности и управления.

Тяготы централизации

Хранилища и озера данных можно масштабировать с помощью таких технологий, как ELT на основе метаданных, виртуализация данных (https://oreil.ly/g_dve), облачные технологии, распределенная обработка, прием данных в реальном времени, машинное обучение для обогащения и т.д. Но есть гораздо более серьезная проблема: централизованное мышление, лежащее в основе этих архитектур. Здесь подразумеваются централизованное управление и владение данными, кластерные ресурсы и централизованные модели, предполагающие, что все должны использовать одинаковые термины и определения. У такой централизации есть еще один негативный эффект: убирая дата-специалистов из бизнес-областей, мы лишаемся бизнес-идей и креативности. Команды вынуждены постоянно взаимодействовать друг с другом. Модель централизованных операций является узким местом: центральная группа не в состоянии быстро обрабатывать все вопросы и запросы. Не зря современные технологические компании принимают на вооружение децентрализованные методологии, такие как сетка данных, и отстаивают предметно-ориентированное проектирование. Отличным решением может оказаться федеративная модель с предметными группами: она способствует независимости и подотчетности; обеспечивает масштабирование, потому что автономные группы управляют данными, передают и потребляют их параллельно; гарантирует повышение качества и производительности.

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

Определение стратегии данных

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

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

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

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

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

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

• Установите четкие и измеримые контрольные точки. Создайте план, который поможет определить, когда ваша стратегия данных преуспеет и начнет приносить пользу. Определите метрики и ключевые показатели эффективности (Key Performance Indicators, KPI) для оценки результатов.

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

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

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

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

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

• Определите, как выглядит культура, основанная на данных. Например, выясните, какие навыки и образование необходимы. Планируете ли вы разрешить бизнес-пользователям полностью самостоятельное использование данных? Готовы ли они делиться данными с другими?

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

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

• Установите, как будет выглядеть переход к будущему — как радикальная реконструкция или естественная эволюция?

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

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

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

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

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

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

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

Итоги главы

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

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

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

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

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

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

3 Рынок аналитики данных стремительно растет. По сведениям IDC (https://oreil.ly/8OZzk), в 2022 году траты компаний на этом рынке превысили 200 млрд долларов.

4 Комплекс знаний разработан сообществом DAMA. Он редко обновляется: первый релиз был в 2008 году, второй — в 2017 году.

5 Под архитектурой понимаются организация и высокоуровневая структура программного обеспечения, необходимого для разработки системы, соответствующей бизнес-требованиям, и обладающего такими характеристиками, как гибкость, масштабируемость, осуществимость, возможность повторного использования и безопасность. Если вы хотите узнать больше об архитектуре программного обеспечения, я рекомендую прочитать книгу Fundamentals of Software Architecture Марка Ричардса (Mark Richards) и Нила Форда (Neal Ford) (O’Reilly). (Книга вышла в издательстве «Питер» в 2022 году под названием «Фундаментальный подход к программной архитектуре: паттерны, компоненты, проверенные методы». — Примеч. ред.).

6 Схемой также называют эталонную реализацию. Она состоит из определений инфраструктуры как кода (Infrastructure as Code, IaC), необходимых для успешного создания набора сервисов в данном конкретном случае.

7 В книге я использую термин «управление основными данными» (Master Data Management, MDM), потому что он широко принят и на момент написания этих строк не имел общеотраслевой альтернативы, но вы можете свободно использовать более инклюзивные альтернативные термины, обозначающие понятия «ведущий/ведомый».

8 Больше подробностей о различных этапах моделирования данных вы найдете в моей статье Data Integration and Data Modeling Demystified (https://oreil.ly/qEuCE). Концептуальную модель иногда также называют бизнес-моделью, моделью предметной области, объектной моделью предметной области или объектной моделью анализа.

9Хранилище характеристик (признаков) (feature store) — это инструмент для хранения часто используемых признаков (отдельных измеримых свойств или характеристик явления).

10Персональные данные — это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу.

11Открытые данные — это данные, которые могут свободно использоваться и являются общедоступными.

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

13 За дополнительной информацией о (корпоративных) хранилищах данных и о том, почему они не масштабируются, отсылаю вас к моей статье в блоге The Extinction of Enterprise Data Warehousing (https://oreil.ly/RO6Hv).

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

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

16 Термин «озеро данных» придумал Джеймс Диксон (James Dixon), бывший технический директор Pentaho (https://oreil.ly/4E_WB).

17 Информация с сайта Брайана Т. О’Нила (Brian T. O’Neill) (https://oreil.ly/oxZ_D).