Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Методы управления данными и их интеграции быстро развиваются, хранение данных в одном месте становится все сложнее и сложнее масштабировать. Пора разобраться с тем, как перевести сложный и тесно переплетенный ландшафт данных вашего предприятия на более гибкую архитектуру, готовую к современным задачам. Архитекторы и аналитики данных, специалисты по соблюдению требований и управлению узнают, как работать с масштабируемой архитектурой и внедрять ее без больших предварительных затрат. Питхейн Стренгхольт поделится с вами идеями, принципами, наблюдениями, передовым опытом и шаблонами.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 454
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Перевод С. Черников
Питхейн Стренгхольт
Масштабируемые данные. Лучшие шаблоны высоконагруженных архитектур. — СПб.: Питер, 2022.
ISBN 978-5-4461-1461-0
© ООО Издательство "Питер", 2022
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Предисловие
Каждый раз, обсуждая программное обеспечение, в какой-то момент мы неизбежно переходим к разговору о данных: сколько их, где они хранятся, что означают, откуда получены или куда должны попасть и что происходит, когда они меняются. Эти вопросы оставались актуальными на протяжении многих лет, в то время как технологии управления данными быстро менялись. Современные базы данных обеспечивают мгновенный доступ к обширным наборам данных; аналитические системы отвечают на сложные наводящие вопросы; платформы потоковой обработки данных не только соединяют различные приложения, но и обеспечивают хранение информации и обработку запросов, предоставляют встроенные инструменты управления данными.
По мере развития этих технологий росли и ожидания пользователей. Пользователь часто подключается к множеству систем, расположенных в разных частях компании, когда переключается с мобильной версии на настольную, меняет местоположение или запускает одно приложение за другим. В то же время ему важна бесперебойная работа в реальном времени. Я думаю, что это значит намного больше, чем многие могут себе представить. Наша задача — связать программное обеспечение, данные и людей так, чтобы пользователи воспринимали их как единое целое.
Управление подобными системами в масштабах компании всегда было сродни черной магии, которую я освоил, помогая создавать инфраструктуру, поддержки LinkedIn. Данные в LinkedIn генерируются постоянно, 24 часа в сутки, процессами, которые никогда не останавливаются. Но когда я впервые пришел в компанию, инфраструктура обработки этих данных ограничивалась лишь медленными процедурами перебора больших дампов данных в конце дня и упрощенной поддержкой поисковых запросов, скомпонованной с доморощенными потоками данных. Концепция «пакетной обработки в конце дня» казалась мне наследием ушедшей эпохи перфокарт и мейнфреймов. На самом же деле в глобальном бизнесе рабочий день не заканчивается никогда.
LinkedIn рос и становился обширным программным комплексом, и мне было ясно, что готового решения для такого рода задач не существует. Более того, управляя базами данных NoSQL, на которых работает сайт LinkedIn, я понял, что придется возродить методы распределенных систем — а это значит, что нужно создавать решения, которых раньше не существовало. Это и привело к появлению Apache Kafka — технологии, сочетающей в себе масштабируемый обмен сообщениями, хранение и обработку обновлений профилей, посещений страниц, платежей и других потоков событий, лежащих в основе LinkedIn.
Создание Kafka не только упростило управление потоками данных в LinkedIn, но и повлияло на подходы к разработке приложений. Как и многие компании Кремниевой долины, на рубеже последнего десятилетия мы экспериментировали с микросервисами, и придумать что-то одновременно функциональное и стабильное удалось далеко не с первой попытки. Трудность заключалась в больших объемах данных, людях и программном обеспечении — сложной взаимосвязанной системе, которая должна была развиваться по мере роста компании. Чтобы справиться с такой серьезной задачей, требовались новые технологии и навыки.
Конечно, в то время не существовало инструкции по решению такой задачи. Нам приходилось изобретать все на ходу, но эта книга вполне могла бы стать тем самым руководством, в котором мы так нуждались. В ней Питхейн предлагает комплексную стратегию управления данными не просто в отдельной базе данных или приложении, а во многих БД, приложениях, микросервисах, уровнях хранения и в разных типах программного обеспечения, из которых складывается сегодняшний технологический ландшафт.
Питхейн также придерживается определенных взглядов на архитектуру, которые основаны на хорошо продуманном наборе принципов. Эти принципы позволяют отделить пространство принятия решений с помощью логических границ, внутри которых должно уместиться множество практических решений. Я думаю, что этот подход будет очень ценным для архитекторов и инженеров, поскольку в своей предметной области они сталкиваются с проблемами, описанными в этой книге. Фактически Питхейн приглашает вас в путешествие далеко за рамки данных и приложений и охватывает сложную материю взаимодействий, объединяющих целые компании.
Джей Крепс (Jay Kreps), соучредитель и генеральный директор Confluent
Введение
Социальные сети, потоковая передача данных и мобильные технологии — это лишь небольшая часть нововведений, благодаря которым цифровизация за последние годы изменила нашу жизнь. Цифровизации уже подверглись музыка и телевидение, шопинг и путешествия, а также многие другие отрасли. В то же время благодаря достижениям в области искусственного интеллекта и машинного обучения развиваются автономные машины — беспилотные автомобили и летательные аппараты.
Что движет этим цифровым обществом? Данные. В ХХ веке самым ценным ресурсом была нефть. Сегодня данные — это новая нефть (https://oreil.ly/ElYot). Растущий спрос на аналитику поднимет спрос на данные до прежде невиданного уровня: это лишь вопрос времени.
Вместе с количеством генерируемых данных растет и их сложность. Облачные технологии, управление API, микросервисы, открытые данные, ПО как услуга (software-as-a-service, SaaS) и новые модели доставки программного обеспечения сегодня актуальны как никогда. Только за последние несколько лет было выпущено бесчисленное множество новых баз данных и аналитических приложений.
Огромное количество новых подходов к обработке данных наполняет цифровой ландшафт. Мы наблюдаем появление двухточечных интерфейсов, становимся свидетелями бесконечных дискуссий о качестве и принадлежности данных, а также множества этических и юридических дилемм, касающихся конфиденциальности, безопасности и защищенности. Гибкость, долгосрочная стабильность и четкое управление данными соревнуются с необходимостью быстрой разработки новых бизнес-задач. Эта отрасль остро нуждается в четком видении будущего управления данными и их интеграции.
Ключевая идея этой книги, касающаяся управления данными и их интеграции, основана на моем личном опыте в качестве главного архитектора данных на крупном предприятии. Благодаря этой работе я отчетливо понял, насколько хорошая стратегия в отношении данных способна повлиять на большую компанию. До этого я работал стратегическим консультантом, проектировал множество архитектур и участвовал в крупных программах управления данными, а также применял все это на практике в качестве внештатного разработчика приложений. Если вкратце, то я провел последнее десятилетие в поисках идеального решения, которое поможет предприятиям управлять данными. Моя текущая компания, ABN AMRO Bank1, создает то, что мы называем перспективнойархитектурой2. Мы применяем на практике и в производстве идеи, изложенные в этой книге, и учимся на этом опыте. Я знаю по книгам и по опыту, что работает, а что — нет.
Этот опыт позволяет мне описать подход к управлению данными и интеграции, выходящий далеко за рамки традиционного. Здесь вы найдете новые соединяющиеся и сочетающиеся методологии и тенденции, в том числе обзор архитектуры предприятия, бизнес-архитектуры, архитектуры программного обеспечения, предметно-ориентированного проектирования, интеграции приложений, микросервисов и облачных технологий. Эта книга представляет собой исчерпывающее руководство по созданию современной масштабируемой среды данных. Она наполнена множеством схем, принципов, шаблонов стандартизации, наблюдений, примеров и передовых практик. Вы узнаете, как не запутаться в сложном и тесно связанном ландшафте данных и встроить гибкость и контроль в ДНК вашей организации. Книга рассматривает управление данными и интеграцию с разных максимально актуальных точек зрения. В зависимости от уровня вашей организации вы можете выбрать подход, который сработает конкретно в вашем случае.
Бесчисленное множество компаний совершают ошибки в управлении данными — и это неудивительно, учитывая меняющийся ландшафт данных, их быстро увеличивающийся объем и сопутствующие проблемы интеграции. Я буду напоминать вам об этом на протяжении всей книги, уделяя пристальное внимание распространенным трудностям.
Важно отметить, что мое представление о данных можно реализовать множеством различных способов. Я упоминаю продукты и поставщиков, но общая идея не зависит от технологий. Некоторые концепции особенно сложны, и поэтому их трудно развивать. Поскольку многие области управления данными и аспекты их интеграции сильно взаимосвязаны, я буду постепенно расширять основную точку зрения в книге, начиная с базовых дисциплин, которые определяют управление данными, анализируя общую архитектуру и детально исследуя разные области.
В моем понимании архитектура должна быть долговечной, современной, распределенной, учитывающей особенности предметной области и дающей бизнесу достаточно гибкости, чтобы быстро находить и интегрировать данные, сохраняя контроль над ними. Такую архитектуру я называю масштабируемой.
Масштабируемая архитектура отличается от других архитектур тем, что ее можно создать прагматически. Ее части можно проектировать независимо и поэтапно без больших предварительных вложений. Моя рекомендация: начинать с малого, смотреть, как идут дела, и продолжать. Этот подход разительно отличается от многих неудачных реализаций хранилищ данных, на получение хоть какой-то пользы от которых могут уйти годы.
Масштабируемая архитектура — это сетка данных или фабрика данных?
Идею сеток данных (data mesh) представила в своей статье (https://oreil.ly/YFj8a) разработчик и автор Жамак Дехгани (Zhamak Dehghani). Архитектура, которую описывает Дехгани, основана на современной распределенной архитектуре: предметные области рассматриваются в ней как первоочередная задача, для создания самообслуживающейся инфраструктуры данных нужно платформенное мышление, а данные интерпретируются как продукт. В некоторых отношениях она похожа на фабрику данных (data fabric) (https://oreil.ly/MI45l) — архитектуру и набор служб данных, которые обеспечивают согласованные возможности для выбора конечных точек, охватывающих локальное и облачные окружения. Наряду с этим существуют также сервисные сетки (service mesh) и сетки событий (event mesh).
С идеями и принципами, лежащими в основе этих концепций, все в порядке. Их цели совпадают. Если вам интересны эти идеи, то книга позволит глубоко погрузиться в такие дисциплины, как управление данными, безопасность данных, качество данных, управление основными данными и метаданными — в интернете такого не найти.
Для кого предназначена эта книга
Книга ориентирована на крупные предприятия, хотя может пригодиться и в небольших организациях. Ею могут особенно заинтересоваться:
• руководители и архитекторы: директора по обработке и анализу данных, технические директора, архитекторы предприятия и ведущие архитекторы данных;
• группы контроля и управления: руководители службы информационной безопасности, специалисты по защите данных, аналитики информационной безопасности, руководители по соблюдению нормативных требований, операторы баз данных и бизнес-аналитики;
• аналитические группы: специалисты по теории и методам анализа данных, аналитики и руководители аналитических отделов;
• команды разработчиков: дата-инженеры, бизнес-аналитики, разработчики и проектировщики моделей данных, а также другие специалисты по данным.
Что я узнаю?
Прочитав эту книгу, вы узнаете:
• что такое управление данными и почему оно важно;
• какие тенденции в бизнесе и технологиях влияют на ландшафт данных;
• каковы основные области управления данными существуют и как они взаимосвязаны;
• как управлять сложным ландшафтом данных в масштабе;
• чем сложна интеграция данных;
• почему корпоративное хранилище данных больше не соответствует своему назначению;
• что нужно для построения масштабной архитектуры данных;
• как интерпретировать основные шаблоны распределения данных — их характеристики и некоторые варианты использования;
• какова главная роль метаданных в управлении архитектурой;
• как масштабно управлять основными и справочными данными;
• как сделать потребление данных масштабируемым с помощью шаблонов самообслуживания;
• какое влияние на архитектуру оказывают гибридное облако и пересекающиеся сети;
• как определить, какие шаблоны лучше подходят в той или иной ситуации и как их применять на практике.
Структура книги
В главе 1 объясняется, что такое управление данными и как оно развивается. В ней описывается состояние отрасли на начало 2020 года и рассказывается о взлетах и падениях основных корпоративных платформ данных.
В главе 2 мы подробно рассмотрим идею масштабируемой архитектуры. Вы познакомитесь с ее конструкцией и получите теоретические основы, на которых построена модель. В следующих главах обсуждаются особенности архитектур интеграции, составляющих общую архитектуру данных. В главе 3 рассматривается архитектура хранилищ данных только для чтения, в главе 4 — архитектура API, а в главе 5 — архитектура потоковой передачи. Глава 6 объединяет информацию из предыдущих глав и дает общий обзор.
Далее мы подробно рассмотрим, как архитектура использует более сложные аспекты управления данными и его дисциплины. В главе 7 изучаются управление данными и обеспечение безопасности с помощью способов, практичных и устойчивых в долгосрочной перспективе — даже в быстро меняющихся обстоятельствах. В главе 8 рассматривается бизнес-модель масштабируемой архитектуры и показывается, как она помогает повысить ценность данных для предприятия. Глава 9 предлагает руководство по управлению основными данными с целью обеспечения их целостности в распределенных, широкомасштабных наборах, а в главе 10 подробно рассказывается об использовании, значении и потенциале демократизации метаданных. Глава 11 завершает книгу примером архитектуры предприятия и обзором будущего технологий управления данными.
Условные обозначения
В книге используются следующие типографские условные обозначения.
Курсив
Обозначает новые или важные термины.
Интерфейс
Используется для обозначения URL, адресов электронной почты.
Моноширинный шрифт
Используется для оформления листингов и фрагментов кода в тексте — имен переменных или функций, баз данных, типов данных, переменных окружения, операторов и ключевых слов, имен и расширений файлов.
Этот элемент обозначает совет или предложение.
Этот элемент обозначает общее примечание.
Этот элемент указывает на предупреждение или предостережение.
1В этой книге я выражаю личные взгляды. Они не отражают точку зрения ABN AMRO.
2Перспективная архитектура близка к тому, что в OpenGroup (https://www.opengroup.org/) называют стратегической и целевой архитектурой. Стратегическая архитектура задает долгосрочное видение и направление для отдела развития архитектуры предприятия. Целевая архитектура — это перспектива, направление и способы развития архитектуры.
Благодарности
Я хотел бы поблагодарить Джессику Стренгхольт-Гайтенбек (Jessica Strengholt-Geitenbeek) за то, что она позволила мне написать эту книгу. Она поддерживала меня на всем пути, заботясь о наших детях и создавая благоприятные условия для моей работы. Она — любовь всей моей жизни.
Я также хотел бы поблагодарить Сантоша Пиллаи (Santhosh Pillai), главного специалиста по архитектуре и управлению данными в ABN AMRO Bank, за доверие и за то, что он был моим наставником на протяжении всей моей карьеры. Многие идеи зародились именно в его голове. Эта книга не появилась бы без наших с ним дискуссий. Кроме того, множество других людей поддержали книгу и написали к ней отзывы: в частности, Бас ван Гилс (Bas van Gils), Дэнни Грефхорст (Danny Greefhorst), Габриэле Росси (Gabriele Rossi), Нур Спанджаард (Noor Spanjaard), Бас ван Хулсенбек (Bas van Hulsenbeek), Яцек Оффирски (Jacek Offierski), Робберт Нэстепад (Robbert Naastepad), Нил Бакстер (Neil Baxter) и др.
Наконец, спасибо замечательной команде O’Reilly за их поддержку и доверие. Сара Грей (Sarah Grey), работать с вами одно удовольствие. Ваша позитивная энергия, острый взгляд и восхитительная улыбка придавали мне сил в работе над книгой. Ким Сандовал (Kim Sandoval), спасибо за ваше умение увидеть картину в целом. Кэтрин Тозер (Katherine Tozer), большое спасибо за то, что вы довели эту книгу до конца. Мишель Смит (Michelle Smith) и Мелисса Поттер (Melissa Potter), спасибо за вашу поддержку в период адаптации.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Глава 1. Проблемы при управлении данными
Управление данными усложняется из-за датафикации (https://oreil.ly/7k6HT). Существующие архитектуры больше не могут масштабироваться. Предприятиям нужна новая стратегия обработки данных. Без смены парадигмы и изменения культуры не обойтись, потому что централизованные решения, работающие сегодня, перестанут работать в будущем.
Технологические тенденции фрагментируют ландшафт данных. Скорость доставки программного обеспечения растет с появлением новых методологий за счет увеличения сложности данных. Быстрый рост объема данных и их интенсивное потребление перегружают операционные системы. Наконец, существуют проблемы конфиденциальности, безопасности и регулирования.
Влияние этих тенденций велико: вся отрасль должна переосмыслить подход к управлению данными в будущем. В этой книге я поделюсь другой теорией управления данными. Она идет вразрез с прежней, позволившей многим предприятиям спроектировать и организовать свой нынешний ландшафт данных. Прежде чем мы подойдем к ней в главе 2, нам нужно определить, что такое управление данными и почему оно важно. После этого мы рассмотрим общую картину и сравним различные тенденции. Наконец, мы увидим, как проектируются и организуются современные корпоративные архитектуры и платформы данных.
Для начала позвольте мне раскрыть карты. Я твердо убежден в том, что следует делать в рамках централизованного управления данными, а что — на местном уровне. Распределенная природа перспективных архитектур вдохновила меня на осмысление нового видения. Хотя хранилища и озера данных — это отличные варианты для использования информации, при их разработке не учитывались высокие темпы роста требований к потреблению данных в будущем. Например, машинное обучение потребляет значительные объемы данных, а если нужны отзывчивость и короткое время реакции, то архитектура должна быстро реагировать.
Перед тем как мы продолжим, я хотел бы попросить вас сделать глубокий вдох и отбросить предубеждения. Да, нужно стремиться к гармонизации данных, учитывать контекст при выборе их объема. При этом не стоит забывать о масштабе. Если экосистема сильно распределена, то централизация данных, потребляемых пользователями и приложениями, может оказаться не лучшим решением.
Управление данными
Процедуры и процессы для организации данных называются управлением данными. Руководство DAMA International по комплексу знаний об управлении данными (DAMA-DMBOK) (https://oreil.ly/BKIm6) дает более развернутое определение: «Управление данными — это разработка, выполнение и контроль планов, политик, программ и практик, которые доставляют, контролируют, защищают и повышают ценность данных и информационных активов на протяжении их жизненного цикла»3. Очень важно глубоко внедрить эти дисциплины в вашу организацию. В противном случае вы запутаетесь и станете работать неэффективно, а ваши данные выйдут из-под контроля. В результате получение максимальной отдачи от ваших данных станет невозможным. Аналитика, например, ничего не стоит, если ваши данные некачественные.
Виды деятельности и дисциплины управления данными разнообразны и охватывают несколько областей. Некоторые из них тесно связаны с архитектурой программного обеспечения4: проектирование и высокоуровневая структура ПО, необходимого для разработки системы, которая отвечает требованиям бизнеса и имеет такие характеристики, как гибкость, масштабируемость, реализуемость, возможность повторного использования и безопасность. Я выбрал только аспекты управления данными, которые наиболее актуальны для современной архитектуры данных в масштабе. Поэтому здесь важно выделить следующие области.
• Архитектура данных. Это мастер-план данных. Она позволяет шире взглянуть на вашу архитектуру, включая схемы, эталонные архитектуры, видение перспективы и зависимости. Управление этими вещами помогает организациям принимать решения. Тематика всей книги вращается вокруг архитектуры данных в целом, но сама дисциплина и ее задачи полностью раскрываются в главах 2 и 3.
• Руководство данными. Действия по руководству данными включают реализацию и обеспечение полномочий, а также контроль над управлением данными, в том числе все соответствующие активы. Эта область более подробно описана в главе 7.
• Моделирование и проектирование данных. Это структурирование и представление данных в определенном контексте и конкретных системах. Обнаружение, проектирование и анализ требований к данным — часть этой дисциплины. Некоторые из этих аспектов рассматриваются в главе 6.
• Управление базами данных, хранение данных и операции с ними относятся к управлению проектом базы данных, правильной реализации и поддержке с целью увеличения ценности данных. Эта дисциплина также включает управление операциями с базами данных. Некоторые аспекты рассматриваются в главе 8.
• Управление безопасностью данных включает все дисциплины и действия, обеспечивающие безопасную аутентификацию, авторизацию и доступ к данным. К таким действиям относятся предотвращение, аудит и меры по смягчению последствий распространения данных. Эта область более подробно описана в главе 7.
• Интеграция и согласованность по данным включают в себя все дисциплины и действия по транспортировке, сбору, объединению и трансформации данных для эффективного их перемещения из одного контекста в другой. Согласованность по данным — это возможность взаимодействий путем вызова функций или передачи данных между различными приложениями способами, не требующими знания характеристик приложения. С другой стороны, интеграция данных — это объединение данных из разных (нескольких) источников в единое представление. Этот процесс часто поддерживается дополнительными инструментами, такими как инструменты репликации и ETL (extract transform and load — «извлечение, преобразование и загрузка»), которые я считаю наиболее важными. Процесс подробно описан в главах 3, 4 и 5.
• Управление справочными и основными данными проводится для обеспечения доступности, точности, безопасности, прозрачности и надежности данных. Эта область более подробно описана в главе 9.
• Управление жизненным циклом данных относится к процессу работы с данными в течение всего жизненного цикла — от создания и первоначального хранения данных до момента их устаревания и удаления. Такой вид управления помогает эффективнее использовать ресурсы, соответствовать правовым обязательствам и ожиданиям клиентов. Некоторые дисциплины из этой области описаны в главе 3.
• Управление метаданными. Это управление всей информацией, которая классифицирует и описывает данные. Метаданные помогают сделать данные понятными, безопасными и готовыми к интеграции. Они также могут использоваться для обеспечения качества. Эта тема более подробно раскрыта в главе 10.
• Управление качеством данных необходимо, чтобы гарантировать пригодность данных к использованию. Некоторые дисциплины из этой области описаны в главах 2 и 3.
• Управление хранением данных, бизнес-аналитикой и продвинутой аналитикой помогает понять, как действуют бизнес-законы, и принимать решения. Эта область описана в главе 8.
Есть еще одна область DAMA-DMBOK — интеграция и согласованность по данным (она-то и вдохновила меня на написание этой книги). На мой взгляд, эта область недостаточно хорошо увязана с управлением метаданными, так что над ней еще предстоит поработать. Метаданные разбросаны среди множества инструментов, приложений, платформ и окружений. Они разнообразны. Согласованность метаданных — способность двух и более систем или компонентов обмениваться описательной информацией о данных — недооценена, поскольку создание крупномасштабной архитектуры и управление ею во многом связано с интеграцией метаданных. Область архитектуры данных в контексте метаданных тоже мало изучена. При правильном использовании метаданных вы четко видите, какие данные передаются, как их можно интегрировать, распределить и защитить, а также как они связаны с приложениями, бизнес-возможностями и т.д. По этой теме не хватает документации.
Я не согласен со взглядами DAMA и многих организаций на семантическую согласованность. На сегодняшний день попытки унифицировать всю семантику для обеспечения согласованности в масштабах всего предприятия продолжаются. Это называется «единственная версия истины». Однако приложения, как и данные, всегда уникальны. Разработка приложений часто подразумевает косвенное мышление. Вы ограничены контекстом, в котором находитесь. Этот контекст наследуется проектом приложения и находит свое отражение в данных. Мы встречаемся с ним, когда переходим от концептуальной модели проекта приложения к его логической и физической формам5. Это важно, ведь контекст ставит в рамки будущую архитектуру. При перемещении данных между приложениями их всегда нужно преобразовывать. Даже если все данные унифицированы и хранятся централизованно, без переключения контекста не обойтись. Выхода из этой дилеммы трансформации данных не существует! Я еще вернусь к этой мысли в следующей главе.
Есть еще одна точка зрения — будто управление данными должно быть централизовано и связано со стратегическими целями предприятия. Многие организации считают, что за счет этого можно снизить эксплуатационные расходы. Также бытует мнение, будто централизованная платформа может избавить клиентов от проблем, связанных с интеграцией данных. Компании вложили значительные средства в корпоративные платформы данных: хранилища, озера и сервисные шины. Управление основными данными тесно связано с этими платформами, ведь объединение позволяет одновременно повышать точность наиболее важных данных.
Централизованная платформа и прилагаемая к ней централизованная модель могут потерпеть неудачу из-за развития революционных тенденций, таких как аналитика, облачные вычисления, новые методологии разработки ПО, принятие решений в реальном времени и монетизация данных. Все это ни для кого не секрет, но многие компании не осознают, какое влияние они оказывают на управление данными. Давайте рассмотрим наиболее важные тенденции и определим их масштабы.
Аналитика фрагментирует ландшафт данных
Самая заметная тенденция — это продвинутая аналитика. Она использует данные, чтобы сделать компании более гибкими, конкурентоспособными и инновационными. Но как продвинутая аналитика может менять существующий ландшафт данных? Чем больше данных, тем выше число вариантов и возможностей. Продвинутая аналитика — это анализ возможных вариантов, прогнозирование будущих тенденций, результатов или событий, автоматизация принятия решений, обнаружение скрытых отношений и поведения. Благодаря признанной ценности и стратегическим преимуществам продвинутой аналитики появилось множество методологий, фреймворков и инструментов для ее использования в разных направлениях. Мы только начали открывать возможности искусственного интеллекта, машинного обучения и обработки естественного языка.
Тренд, ускоривший продвинутую аналитику, — открытый исходный код. Высококачественные проекты ПО с открытым исходным кодом становятся основным стандартом6. Открытый исходный код способствовал росту популярности продвинутой аналитики, устранив дорогостоящий аспект лицензирования коммерческих продуктов и позволив специалистам учиться друг у друга.
Открытый исходный код также открыл сферу специализированных баз данных. Cassandra, HBase, MongoDB, Hive и Redis — вот лишь часть систем, которые изменили традиционный рынок БД, позволив хранить и анализировать огромные объемы данных. В результате появления всех этих новых возможностей резко повысилась эффективность создания и разработки современных решений. Теперь сложные задачи легко можно решить с помощью узкоспециализированной базы данных. Больше не нужно использовать устаревшую реляционную БД и сложную прикладную логику. Многие из новых продуктов баз данных имеют открытый исходный код, что повысило их популярность.
Разнообразие и рост продвинутой аналитики и баз данных привели к двум проблемам: быстрому разрастанию и увеличению объема данных.
По мере разрастания одни и те же данные распределяются по множеству приложений и БД. Корпоративное хранилище, использующее систему управления реляционными базами данных (relational database management, RDBM), например, не способно выполнять сложный анализ социальных сетей. Для этой цели лучше использовать специализированную графовую базу данных7.
Использование реляционной базы данных для централизованной платформы и связанные с этим ограничения вынуждают постоянно экспортировать данные. Таким образом, данные покидают централизованную платформу и должны быть распределены в другие системы БД. Такая ситуация может создать еще одну проблему: если данные разбросаны по всей организации, то найти и оценить их происхождение и качество труднее. Это значительно усложняет управление данными, ведь они могут распределяться и вне централизованной платформы.
Развитие аналитических методов означает ускоренный рост объема данных: соотношение чтения и записи значительно меняется. Например, аналитические модели, которые постоянно переобучаются, читают большие объемы данных. Этот аспект влияет на приложения и структуру БД, потому что приходится оптимизировать данные для чтения. Что может означать следующее: чтобы избавить системы от необходимости постоянного обслуживания данных, эти данные нужно дублировать. Это также может означать, что нужно дублировать данные для их предварительной обработки из-за разнообразия и большого количества вариантов использования и шаблонов чтения, которые сопутствуют этим вариантам. Сложно привести в порядок такое разнообразие шаблонов чтения при одновременном дублировании данных и сохранении контроля. Решение этой проблемы описано в главе 3.
Скорость доставки программного обеспечения меняется
В современном мире программные сервисы составляют основу бизнеса. Это означает, что нужно быстро выпускать обновления. В ответ на требования большей гибкости в таких компаниях, как Amazon, Netflix, Facebook, Google и Uber, появились новые идеологии: они развивают свою практику разработки программного обеспечения на основе двух убеждений.
Первое убеждение: разработку программного обеспечения (development, Dev) и практическое применение информационных технологий (operations, Ops) нужно объединять. Это поможет сократить жизненный цикл разработки и обеспечить непрерывную поставку качественного ПО. Такая методология называется DevOps. Она требует новой культуры, предполагающей бóльшую автономию, открытое общение, доверие, прозрачность и согласованную работу команды.
Второе убеждение касается размера разрабатываемого приложения. Ожидается, что гибкость системы возрастет, если приложения превратятся в мелкие сервисы, решающие узкоспециализированные задачи. Этот подход к разработке породил несколько модных словечек: микросервисы (https://microservices.io/), контейнеры, Kubernetes (https://kubernetes.io/), предметно-ориентированное проектирование, бессерверные вычисления и т.д. Я не буду вдаваться в подробности каждой концепции, но эта эволюция разработки программного обеспечения связана с увеличением сложности и спроса на улучшенный контроль данных.
Преобразование монолитного приложения в распределенное создает множество проблем, связанных с управлением данными. При дроблении приложений на более мелкие части данные распределяются по разным компонентам. Командам разработчиков приходится переводить свои (отдельные) уникальные хранилища с простыми и понятными моделями данных, на архитектуры, где объекты данных распределены. Это создает несколько сложностей: увеличение количества сетевых взаимодействий, необходимость синхронизации копий данных для чтения, обеспечение согласованности и ссылочной целостности и т.д.
Сдвиг в разработке ПО нуждается в архитектуре, позволяющей более мелким приложениям распределять свои данные. К тому же нужна новая культура DataOps (https://oreil.ly/G8Bt4) и другая философия проектирования с большим упором на совместимость данных, фиксацию неизменяемых событий, а также воспроизводимость и слабую связанность. Мы обсудим это подробнее в главе 2.
Сети становятся быстрее
Сети становятся быстрее, а пропускная способность увеличивается из года в год. Я был на саммите Gartner Data and Analytics в 2018 году, где представители Google продемонстрировали возможность перемещения сотен терабайт данных в облако менее чем за минуту.
Возможность перемещения таких больших объемов данных позволяет реализовать интересный подход: вместо увеличения вычислительной мощности источников данных, как это было принято раньше из-за сетевых ограничений, можно доставлять необработанные данные потребителям, обладающим большой вычислительной мощностью. Сеть больше не является препятствием, поэтому мы можем быстро перемещать терабайты данных из окружения в приложения, потребляющие и использующие эти данные. Интерес к такой модели неуклонно растет с увеличением популярности рынков SaaS (Software as a service — программное обеспечение как услуга) и MLaaS (Machine Learning as a Service — машинное обучение как услуга). Вместо выполнения сложных вычислений на месте можно использовать сети и передавать данные другим сторонам.
Этот шаблон распределения, основанный на копировании (дублировании) и передаче данных потребителю для обработки, находящемуся, например, в облаке, еще больше фрагментирует ландшафт данных, увеличивает важность использования четкой стратегии управления.
Приоритет — вопросы конфиденциальности и безопасности
Данные, несомненно, имеют ключевое значение для оптимизации, внедрения инноваций или дифференциации организаций. Но они также начали раскрывать себя с темной стороны, влекущей за собой негативные последствия. Файлы Cambridge Analytica (https://oreil.ly/lLZSG) и 500 миллионов взломанных учетных записей в Marriott — впечатляющие примеры скандалов, связанных с конфиденциальностью данных и их утечкой8. Правительства принимают все более активное участие в управлении данными, потому что все аспекты нашей личной и профессиональной жизни теперь связаны с интернетом. Пандемия COVID-19 расширила связи между людьми, ведь многие из нас вынуждены были работать из дома.
Тенденции объединения массивных данных, более мощной продвинутой аналитики и более быстрого распространения вызвали множество споров, этических вопросов и дискуссий об опасностях в сфере данных. По мере того как компании будут совершать ошибки и пересекать границы этических норм, правительства, как мне кажется, ужесточат регулирование и потребуют большей безопасности, контроля и внимания. Мы изучили лишь часть истинной конфиденциальности и этических проблем, связанных с данными. Регулирование заставит большие компании быть честными в плане того, какие данные собирать, покупать, объединять, анализировать и распространять (продавать). Крупным компаниям придется задуматься о подходах, ориентированных на прозрачность и конфиденциальность, и о том, как решать серьезные вопросы регулирования.
Регулирование — сложный вопрос. Представьте себе ситуации, когда имеется несколько облачных окружений и разных сервисов SaaS, использующих распределенные данные. Удовлетворить требования европейского Общего регламента по защите данных (General Data Protection Regulation, GDPR) (https://gdpr-info.eu/) и Закона штата Калифорния о защите конфиденциальности потребителей (California Consumer Privacy Act, CCPA) (https://oag.ca.gov/privacy/ccpa) сложно, потому что компании должны иметь представление о персональных данных и контролировать их независимо от того, где они хранятся. Управление персональными данными и работа с ними — приоритет для многих крупных фирм9.
Более строгие нормативные требования и этика данных в будущем приведут к дополнительным ограничениям и усилению контроля. Важнейшее значение приобретет понимание того, откуда данные пришли и как они распределяются. Потребуется более жесткое внутреннее управление. Тенденция к усилению контроля противоречит методикам быстрой разработки программного обеспечения, признаки которых — меньше документации и средств внутреннего контроля. Это приводит к появлению другой, оборонительной, точки зрения на то, как управление данными осуществляется внутри компании. Большая часть этих проблем рассмотрена в главе 7.
Необходимо интегрировать операционные системы и системы обработки транзакций
Важность быстрого реагирования на события в деловом мире диктует новые задачи. Традиционно существует четкое разделение между приложениями обработки транзакций (операционными) и аналитическими приложениями. Так происходит потому, что возможностей систем обработки транзакций обычно недостаточно для доставки больших объемов данных или их постоянного распространения. Лучшей практикой всегда считалось разделение стратегии данных на две части: 1) обслуживание транзакций и сохранение аналитических данных и 2) обработка больших данных.
В то же время это четкое разделение становится все менее очевидным. Ожидается, что операционная аналитика, которая построена вокруг прогнозирования и улучшения существующих операционных процессов, будет тесно взаимодействовать как с транзакционными, так и с аналитическими системами. Аналитические результаты необходимо снова интегрировать в ядро операционной системы, чтобы эта информация могла использоваться в операционном контексте.
Эта тенденция требует другой архитектуры интеграции, объединяющей операционные и аналитические системы. Это также требует интеграции данных для работы с разными скоростями: со скоростью операционных систем и со скоростью аналитических систем. В этой книге мы рассмотрим варианты сохранения исторических данных в исходном операционном контексте, делая их доступными одновременно для операционных и аналитических систем.
Для монетизации данных требуется экосистемная архитектура
Многие люди считают свое предприятие единой бизнес-экосистемой с четкими границами, но мнениям свойственно меняться10. Компании все чаще интегрируют свои основные бизнес-функции и услуги со сторонними организациями и их платформами. Они монетизируют данные, делают API общедоступными и используют открытые данные в целом11.
Как следствие, данные чаще распределяются между окружениями и становятся более децентрализованными. При этом используются облачные решения или SaaS. В итоге данные получаются раскиданными по разным местам, что затрудняет их интеграцию и управление. Кроме того, возникают проблемы с пропускной способностью сети, подключением и задержкой, когда данные не передаются с достаточной скоростью платформам или окружениям, где они применяются. Использование единой стратегии общедоступного облака не решит такие проблемы. Поэтому, если вам нужно, чтобы API и системы SaaS работали хорошо и использовали возможности общедоступного облака, придется освоить интеграцию данных — эта книга должна вам помочь.
Тенденции, о которых я рассказываю, важны и будут влиять на то, как люди используют данные и как компании должны организовывать свою архитектуру. Объемы данных увеличиваются все быстрее, вычислительные мощности растут, а аналитические методы развиваются. Миру нужно все больше данных, а значит, их надо быстро распространять и наладить более строгое управление данными. Управление должно быть децентрализованным из-за стремления шире использовать облачные вычисления, SaaS и микросервисы. Все эти факторы необходимо уравновесить, чтобы сократить время выхода на рынок и получить дополнительные преимущества в конкурентной борьбе. Эта рискованная комбинация заставляет нас совершенно иначе управлять данными.
Предприятия обременены устаревшими архитектурами данных
Одна из самых больших проблем, с которой сталкиваются многие предприятия, — это получение выгоды от существующих корпоративных архитектур данных12. Большинство таких архитектур используют монолитную структуру — корпоративное хранилище или озеро данных — и централизованно управляют данными, распределяя их. В сильно распределенном окружении эти архитектуры не будут отвечать потребностям будущего. Рассмотрим некоторые их характеристики.
Корпоративное хранилище данных и бизнес-аналитика
Архитектуры данных первого поколения основаны на хранилищах данных и бизнес-аналитике. Идея заключается в том, что существует единое центральное интегрированное хранилище, содержащее подробные и стабильные данные, накопленные за годы существования организации. У такой архитектуры есть свои недостатки.
Унификация корпоративных данных — очень сложный процесс, который занимает много лет. Высоки шансы, что в разных предметных областях, отделах и системах значение данных различается13. Атрибуты данных могут иметь одинаковые имена, но разные значения и определения. Поэтому мы либо создаем много вариантов, либо просто принимаем различия и несоответствия. Чем больше данных мы добавляем и чем больше противоречий и несоответствий имеется в определениях, тем труднее будет их согласовать. Скорее всего, получится единый контекст, бессмысленный для всех. Для продвинутой аналитики вроде машинного обучения исключение контекста может стать большой проблемой, ведь на бессмысленных данных не сделать точный прогноз.
Корпоративные хранилища данных (enterprise data warehouses, EDW) ведут себя как интеграционныебазы данных (рис. 1.1). Они действуют как хранилища для множества приложений, потребляющих данные. Это означает, что они являются связующим звеном для всех приложений, желающих получить доступ к хранилищу. Изменения необходимо вносить осторожно из-за множества зависимостей между различными приложениями. Некоторые изменения могут также вызвать «эффект ряби» для других изменений. В этом случае образуется большой ком грязи.
Рис. 1.1. Корпоративные хранилища данных обычно имеют множество точек сопряжения, этапов интеграции и зависимостей
Высокая сложность хранилища данных и тот факт, что им управляет одна центральная группа, плохо сказывается на гибкости. Увеличивается время ожидания, что заставляет людей искать обходные решения. Один разработчик, например, может обойти уровень интеграции и напрямую отобразить данные из промежуточного уровня в своем киоске данных. Другой создаст представление для быстрого объединения данных. Такой технический долг (будущая доработка) позже приведет к проблемам. Архитектура станет настолько сложной, что люди перестанут понимать общую структуру и обходные пути, созданные ради своевременной доставки.
Большой ком грязи
Большой ком грязи (https://oreil.ly/8bY2t) — хаотично устроенные, раскидистые, неряшливые джунгли из спагетти-кода, скрепленные изолентой и проволокой. Этот популярный термин был впервые введен Брайаном Футом (Brian Foote) и Джозефом Йодером (Joseph Yoder). Большой ком грязи описывает системную архитектуру — монолитную, трудную для понимания и обслуживания и тесно связанную из-за множества зависимостей. На рис. 1.2 показана диаграмма зависимостей, иллюстрирующая подобную архитектуру (https://oreil.ly/Fdckr). Каждая линия представляет связь между двумя программными компонентами.
Как видите, в большом коме грязи каждый компонент связан со всеми остальными, из-за чего практически невозможно изменить один компонент, не затрагивая другой.
Хранилища данных с их уровнями, представлениями, бесчисленными таблицами, взаимосвязями, сценариями, заданиями и потоками планирования часто становятся причиной появления хаотичной паутины зависимостей. Это настолько сложно, что через некоторое время вы часто получаете большой ком грязи.
Рис. 1.2. Диаграмма зависимостей — это математическая модель, часто используемая в программной архитектуре для идентификации компонентов и функциональных единиц проекта
Хранилища данных тесно связаны с выбранным базовым решением или технологией. Это означает, что потребители, которым нужны другие шаблоны чтения, будут вынуждены экспортировать данные в другие окружения. По мере того изменения рынка и появления баз данных новых типов хранилища становятся все более разбросанными, из-за чего приходится снова экспортировать данные. Эта тенденция подрывает общее видение эффективного использования единого центрального репозитория и базового (дорогостоящего) оборудования.
Управление жизненным циклом исторических данных часто сопряжено со сложностями. Хранилища данных рассматриваются как архивы истины, позволяющие операционным системам очищать ненужные им данные, зная, что они останутся в хранилище. Для продвинутой операционной аналитики, возникшей после появления хранилищ данных, это может быть проблемой. Если данные были преобразованы и больше не распознаются как пригодные для операционного использования, то быстро сделать их доступными будет непросто, учитывая, что многие хранилища обычно обрабатывают данные в течение многих часов.
Хранилища часто не имеют информации о разовом потреблении и дальнейшем распределении данных, особенно когда они передаются за пределы экосистемы. В соответствии с современным законодательством владение данными и понимание их потребления и распределения играют важную роль, потому что вы должны быть в состоянии объяснить, какие персональные данные были использованы, кем и с какой целью.
Качество данных тоже часто оставляет желать лучшего. Кому принадлежат данные в хранилищах? Кто несет ответственность, если исходные системы доставляют поврежденные данные? Я анализировал ситуации, когда инженеры сами решали вопросы качества данных. В одном случае они зафиксировали данные на промежуточном уровне, чтобы правильно загрузить их в хранилище. Эти исправления стали постоянными, и со временем пришлось применить сотни дополнительных сценариев, прежде чем можно было начать обработку данных. Эти сценарии не являются частью заслуживающих доверия процессов ETL и не позволяют отследить происхождение данных.
Замещающая миграция может стать рискованной и трудоемкой, если взять во внимание общий объем данных в хранилище, годы, которые потребовались на его разработку, человеческие знания и интенсивное использование в бизнесе. Поэтому многие предприятия продолжают использовать эту архитектуру и создавать на ее основе свои бизнес-отчеты, информационные панели и приложения, активно потребляющие данные14.
Озеро данных
По мере роста объемов данных и необходимости более быстрого анализа инженеры начали работать над другими концепциями. Озера данных возникли как альтернатива для доступа к большим объемам сырых, необработанных данных15. Используя их, потребитель может сам решать, как использовать, преобразовывать и интегрировать эти данные.
Озера, как и хранилища, считаются централизованными (монолитными) и отличаются от последних тем, что хранят данные до их преобразования, очищения и структурирования. Поэтому схемы часто определяются при чтении данных. В этом состоит отличие от хранилищ, в которых используется предопределенная и фиксированная структура. Озера данных также обеспечивают большее разнообразие данных за счет поддержки нескольких форматов: структурированных, полуструктурированных и неструктурированных.
Хранилища и озера также сильно различаются в плане используемой базовой технологии. Первые обычно создаются с помощью RDBM, а вторые — с помощью распределенных БД или систем NoSQL. Часто используются общедоступные облачные сервисы. Недавно распределенные и полностью управляемые облачные базы данных16 поверх контейнерной инфраструктуры упростили задачу масштабного управления централизованными репозиториями данных. При этом появились преимущества в виде большей гибкости и меньшей стоимости17.
Многие озера собирают чистые, неизмененные, необработанные данные из исходных систем (рис. 1.3). Сохранение данных в первозданном виде — точных копий — выполняется быстро и обеспечивает мгновенный доступ к ним специалистам по анализу и обработке данных. Но с первозданными данными есть одна сложность: они требуют предварительной обработки. Приходится решать проблемы с качеством данных, их объединением и обогащением другими данными, чтобы они соответствовали контексту. Это добавляет много рутинной работы — еще одна причина, почему озера данных обычно объединяются с хранилищами. Хранилища в этой комбинации действуют как высококачественные репозитории очищенных и согласованных данных, в то время как озера выступают в роли (специальных) аналитических окружений, содержащих много необработанных данных для облегчения анализа.
Создавать озера данных, как и хранилища, непросто. Ник Худекер (Nick Heudecker), аналитик из Gartner, написал в «Твиттере», что, по его мнению, частота отказов внедрения озер данных превышает 60 %18. Попытки реализации озера обычно терпят неудачу из-за их огромной сложности, проблем с обслуживанием и общих зависимостей.
• Данные, загружаемые в озеро, часто не обработаны и являют собой сложную совокупность различных представлений. В озере могут быть десятки тысяч таблиц, непонятные структуры данных и технические значения, понятные только самому приложению. Кроме того, данные тесно связаны с исходными системами, так как унаследованная структура является идентичной копией. К тому же существует реальная опасность нарушения работы конвейера загрузки необработанных данных, если их источники вдруг изменятся.
• Аналитические модели в озерах часто обучаются и на необработанных, и на согласованных данных. Не исключено, что инженеры и специалисты по обработке и анализу данных вручную собирают и создают данные, а также управляют конвейерами и моделями в рамках своих проектов. Как следствие, озера данных несут значительные (операционные) риски.
• Озера данных часто представляют собой единую платформу и используются во многих различных сценариях. Такие платформы очень сложно поддерживать из-за их тесной связанности, проблем совместимости, общих библиотек и конфигураций.
Рис. 1.3. Озера данных — это гигантские области хранения объектов, которые собирают необработанные данные из различных источников. Во многих случаях это просто пул таблиц без каких-либо определенных логических границ областей
Эти проблемы — лишь часть тех причин, по которым проваливается так много проектов, связанных с большими данными. К прочим можно отнести сопротивление руководства, внутреннюю политику, недостаток опыта, а также проблемы безопасности и управления.
Централизованное представление
Хранилища и озера данных можно масштабировать с помощью таких методов, как ELT на основе метаданных, виртуализация данных, облачные технологии, распределенная обработка, поглощение данных в реальном времени, машинное обучение для пополнения информации и т.д. Но есть гораздо более серьезная проблема: централизованное мышление, лежащее в основе этих архитектур. Здесь подразумеваются централизованное управление и владение данными, кластеризация ресурсов и использование централизованных моделей, предполагающих, что все должны использовать одинаковые термины и определения. У такой централизации есть еще один негативный эффект: убирая специалистов по данным из бизнес-областей, мы лишаемся бизнес-идей и творческих подходов. Команды вынуждены постоянно взаимодействовать друг с другом. Не зря современные технологические компании отстаивают предметно-ориентированное проектирование — подход к разработке программного обеспечения, впервые предложенный Эриком Эвансом (Eric Evans). Он включает лучшие общепринятые практики и стратегические, философские, тактические и технические элементы.
Итоги главы
Хранилища данных никуда не исчезнут, потому что всегда придется согласовывать данные из разных источников в рамках определенного контекста. Не исчезнут и шаблоны разделения посредством промежуточных данных, равно как и этапы очистки, исправления и преобразования схем. Любой архитектурный стиль моделирования Билла Инмона (Bill Inmon) (https://oreil.ly/wlB9w), Ральфа Кимбалла (Ralph Kimball) (https://oreil.ly/ToDNb) или моделирования хранилища данных (https://oreil.ly/Fj8JL) может подойти в зависимости от особенностей вариантов использования. То же самое относится и к озерам данных: потребность в распределенной обработке огромных объемов данных для аналитики исчезнет нескоро.
Но мы должны подумать о том, как следует в целом управлять данными и распространять их. Большие разрозненные хранилища вроде корпоративных исчезнут из-за невозможности масштабирования. Тесно связанные уровни интеграции, потеря контекста и рост потребления данных заставят компании искать альтернативы. Еще одна крайность — архитектуры озер данных, которые извлекают данные в первоначальном виде. Необработанные данные, которые могут измениться в любой момент, не позволят экспериментам и сценариям использования когда-нибудь внедрить их в производство. Работа над такими данными рутинна и скучна.
Масштабируемая архитектура
Решением проблем разрозненных данных может стать масштабируемая архитектура: типовая и предметно-ориентированная архитектура с набором схем, проектов, принципов, моделей и наилучших практик, которая упрощает и интегрирует управление данными во всей организации с помощью распределения. Я вижу это как архитектуру, которая сближает все области управления данными, предлагая единый механизм управления безопасностью, основными данными, метаданными и моделированием данных; архитектуру, которая может работать с использованием комбинации нескольких облачных провайдеров и локальных платформ, но при этом дает необходимые контроль и гибкость. Она упрощает работу команд, предоставляя не зависящие от предметной области и повторно используемые архитектурные блоки, и при этом обеспечивает гибкость, сочетая различные стили доставки данных с разнообразными технологиями. Масштабируемая архитектура позволяет командам самостоятельно превращать данные в ресурс без помощи центральной группы.
Масштабируемая архитектура, описанная в этой книге, состоит из обширного набора принципов управления данными. Она потребует от вас, например, идентифицировать и классифицировать подлинные и уникальные данные, определить их качество в источнике, обеспечить поддержку метаданных и провести четкие границы. Следуя этим принципам, предприятия дадут своим командам возможность быстро распределять и использовать данные, сохраняя свою независимость. Эта архитектура также сопровождается моделью управления: инженеры должны научиться создавать хорошие абстракции и конвейеры данных, а владельцы бизнес-данных — нести ответственность за эти данные и их качество, обеспечивая ясность контекста.
3Комплекс знаний разработан сообществом DAMA. Он редко обновляется: первый релиз был в 2008 году, второй — в 2014 году.
4Если вы хотите узнать больше об архитектуре программного обеспечения, я рекомендую прочитать книгу Fundamentals of Software Architecture Марка Ричардса (Mark Richards) и Нила Форда (Neal Ford) (O’Reilly, 2020). (Книга выходит в издательстве «Питер» в 2022 году под названием «Фундаментальный подход к программной архитектуре: паттерны, компоненты, проверенные методы». — Примеч. ред.)
5Концептуальную модель иногда также называют моделью предметной области, объектной моделью предметной области или объектной моделью анализа.
6Microsoft приобрела GitHub, популярный сервис репозиториев исходного кода, которым пользуются многие разработчики и крупные компании. IBM также признала ценность открытого исходного кода, купив RedHat, ведущего поставщика решений с открытым исходным кодом.
7Этот пример использования Neo4j (https://oreil.ly/AvEMU) показывает, что графовая база данных — лучший вариант для проведения анализа социальных сетей.
8The New York Times описала последствия взлома учетных записей Marriott (https://oreil.ly/0zJdf).
9Персональные данные — это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу.
10Джеймс Мур (James Moore), автор книги The Death of Competition (Harper, 1997), определил бизнес-экосистему как «совокупность компаний, которые работают совместно и на конкурентной основе для удовлетворения потребностей клиентов».
11Открытые данные — такие, которые можно свободно использовать и сделать общедоступными. В McKinsey считают, что монетизация данных меняет способ ведения бизнеса (https://oreil.ly/yNH8V).
12Под архитектурой данных здесь понимаются инфраструктура и данные, а также схемы, интеграция, преобразования, хранилище и рабочий процесс, необходимые для выполнения аналитических требований информационной архитектуры.
13Предметная область — это область исследования, которая определяет набор общих требований, терминологии и функциональности для любого программного обеспечения, созданного для решения проблемы в области компьютерного программирования.
14Информационные панели мониторинга более наглядны и используют различные типы диаграмм. Отчеты, как правило, имеют табличную форму, но могут содержать дополнительные диаграммы или их компоненты.
15Джеймс Диксон (James Dixon), бывший технический директор Pentaho, придумал термин «озеро данных» (https://oreil.ly/4E_WB).
16Docker , Inc. — ведущая компания, создающая инструменты на основе Docker (https://oreil.ly/15ZW9), прекрасно объясняет концепцию контейнеров (https://oreil.ly/jpyb8).
17Эластичность — это степень, в которой системы могут адаптировать изменения своей рабочей нагрузки за счет автоматического выделения и удаления ресурсов.
18TechRepublic даже заявляет, что 85 % всех проектов с большими данными оказываются неудачными (https://oreil.ly/qKmoM).
Глава 2. Введение в масштабируемую архитектуру: организация данных в масштабе
Какая архитектура нужна предприятию, чтобы управление им основывалось на данных? Как эффективно распределять данные, сохраняя гибкость, безопасность и контроль? В этой главе мы рассмотрим эти вопросы и заложим основу для управления данными.
Современные тренды толкают нас на переосмысление способов управления данными и их интеграции. Ранее мы разобрали тесную связь, возникающую при создании точных копий данных, и трудности практического анализа необработанных данных. Мы также обсудили проблемы унификации и огромные усилия, которые прилагаются к созданию интегрированного хранилища данных, и их влияние на гибкость. Нам необходимо перейти от объединения всех данных в одном хранилище к подходу, который позволяет предприятиям, командам и пользователям легко и безопасно распределять, собирать и использовать данные. Платформы, процессы и шаблоны должны упрощать работу другим. Нам нужны простые, хорошо документированные, быстрые и легкие в использовании интерфейсы. Нам нужна масштабируемая архитектура управления данными. Именно эти вопросы мы и затронем в главе. А начнем мы с того, как организовать ландшафт и интегрировать данные.
Крупномасштабная архитектура в моем представлении ориентирована на управление данными и их интеграцию. Это архитектура для предприятий, которая позволяет командам безопасно и легко предоставлять данные, сохраняя гибкость и контроль. Как и во многих других архитектурах, в ней используются архитектурные строительные блоки, которые относятся к «пакету функций, определенных для удовлетворения потребностей бизнеса»19. Эти блоки будут использоваться снова и снова, чтобы помочь вам понять, какую именно часть архитектуры мы обсуждаем.
Начнем с традиционных принципов определения наиболее важных архитектурных блоков. Далее мы обсудим дополнительную литературу и сделаем выводы. Затем, наконец, рассмотрим новую архитектуру и ее обоснование, а также раскроем, что находится внутри нее. К концу этой главы вы поймете, как различные архитектурные блоки работают и связаны между собой. Эта базовая теория необходима для понимания основных движущих сил новой архитектуры. В следующих главах мы подробнее рассмотрим шаблоны, проекты, диаграммы и рабочие процессы, и вы начнете понимать, как эта архитектура связывает воедино все области управления данными.
Общепризнанные отправные точки
Прежде чем погрузиться в обсуждение, я хочу выделить главные отправные точки. Они формируют архитектуру и содержат элементы, на которые я часто ссылаюсь.
У каждого приложения есть база данных
Приложения тесно связаны с базами данных. В контексте управления данными и их перемещения между приложениями мы можем допустить, что у каждого приложения всегда есть база данных. То есть всякий раз, сталкиваясь с необходимостью потребления данных, вы должны хранить их в БД приложения. Да, бывают приложения, хранящие свои данные в другом месте, а еще приложения, использующие одну и ту же базу данных, или приложения, выполняющие обработку в памяти. Но всем этим приложениям все равно нужно где-то хранить свои данные. Так что у них всегда есть хранилище в той или иной форме, а значит, и хранилище данных приложения.
Приложения специфичны и обладают уникальным контекстом
В главе 1 я отметил, что приложения используются для решения конкретных задач. Данные каждого приложения уникальны. Существует несколько этапов проектирования и разработки приложений. Все начинается с определения концепции и разработки проекта; затем мы трансформируем наши знания в логическую модель данных, определяющую абстрактную структуру концептуальной информации и требований. Наконец, мы создаем физическую модель данных приложения: истинный проект приложения и базы данных. Физическая модель данных уникальна и принимает как контекстные, так и нефункциональные требования к тому, как приложение и БД будут спроектированы и использованы.
Золотой источник
В фрагментированной и распределенной среде порой сложно определить авторитетные источники исходных и уникальных данных. Поэтому важно знать, откуда поступают данные и где ими управляют. В этой книге я обсуждаю основополагающие концепции золотого источника и золотого набора данных20.
• Золотой источник — это авторитетное приложение, в котором все аутентичные данные обрабатываются в определенном контексте. Он состоит из одного или нескольких золотых наборов данных21.
• Золотой набор данных — это созданные надежные оригинальные данные. Он подлинный и уникальный и должен быть точным, полным и известным22. Золотой набор данных состоит из элементов данных (https://oreil.ly/RGKhT) — элементарных единиц удобочитаемой информации, имеющих точное значение или точную семантику. У них есть определяемое имя, и они служат связующим звеном для других субъектов управления данными, таких как распоряжение данными.
Благодаря золотому источнику и золотому набору данных вы всегда сможете точно и последовательно отчитаться о своих данных. Это важно для надежного управления данными, о чем мы поговорим позже, в главе7.
Дилеммы интеграции данных не избежать
Для перемещения данных между приложениями их всегда приходится интегрировать. Это происходит из-за уникального контекста, в котором эти данные создаются. Неважно, что вы выполняете — ETL (extract, transform, and load — «извлечение, преобразование и загрузка») или ELT (extract, load, and transform — «извлечение, загрузка и преобразование»), виртуальным или физическим способом, пакетами или в реальном времени: от дилеммы интеграции данных никуда не деться. Преобразование всегда требуется при переносе данных из одного контекста в другой. Ключевое слово всегда образует новую архитектуру.
Приложения играют роли поставщиков и потребителей данных
Приложения выступают в роли либо поставщиков, либо потребителей данных, а иногда, как мы увидим, и в той, и в другой одновременно. Одно приложение использует данные, а другое создает и предоставляет их. В контексте интеграции данных во множестве приложений и систем это важно понимать. Роли поставщика и потребителя данных станут строительными блоками формальной архитектуры.
В зависимости от того, действует ли система или приложение в качестве поставщика или потребителя, правила игры меняются: применяются разные архитектурные принципы (рис. 2.1).
Рис. 2.1. Роли приложения как поставщика и потребителя данных будут формировать нашу архитектуру
Роли поставщика и потребителя данных также применимы к внешним сторонам. Внешними называют стороны, действующие за пределами логических границ экосистемы предприятия. Обычно они находятся в отдельных неконтролируемых местах в сети. В главе1 мы говорили, что компании рассматривают общедоступную сеть как кладезь (открытых) данных, которые они могут монетизировать для создания услуг и обмена ими. Этот новый способ сотрудничества изменил границы организаций. Новая архитектура, которую я представляю, требует гибкости, чтобы внешние стороны могли быть как поставщиками, так и потребителями данных. Обычно ради этого приходится применять дополнительные меры безопасности, ведь внешние стороны не всегда надежны или известны. Иногда они напрямую связаны с более широким контекстом.
Уникальный контекст, в котором работают приложения, роли поставщика и потребителя данных, а также преобразование, которое всегда происходит между приложениями, будут определять новую архитектуру. Но что еще нужно учитывать? Что делает общую архитектуру хорошей? В следующих разделах мы исследуем эти вопросы.
Основные теоретические соображения
Интеграция данных между приложениями — это управление сложностью взаимодействия и согласования данных между системами. В архитектуре предприятия мы обычно рассматриваем более широкую картину. Но как компоненты работают вместе для интеграции данных внутри приложения и что мы можем из этого извлечь?23
Интеграция приложений находится на уровне архитектуры или разработки программного обеспечения. На абстрактном уровне интеграция корпоративных данных и интеграция программного обеспечения близки, а порой и частично совпадают (рис. 2.2).
Рис. 2.2. Дисциплины интеграции данных и интеграции программного обеспечения имеют множество пересечений
Далее мы внимательно рассмотрим несколько шаблонов разработки программного обеспечения, позволяющих разобраться в повторяющихся проблемах. Их понимание помогает командам разработчиков избежать создания зависимостей и сложностей.
Принципы объектно-ориентированного программирования
Упомянутые ниже элементы — это те принципы объектно-ориентированного проектирования, которые часто используются для создания независимых программных компонентов. Они все еще применяются в современных популярных методах.
Первый принцип, который мы рассмотрим, — это объектно-ориентированное программирование (ООП). Управление сложностью приложения и кода в целом осуществляется путем абстрагирования сложной логики, реализации общих функций для выполнения повторяющихся задач и создания общих интерфейсов для других компонентов.
В брошюре Роберта К. Мартина (Robert C. Martin) Design Principles and Design Patterns (object-mentor.com, 2000) изложены идеи, идеально подходящие для интеграции данных. Многие из его принципов проектирования до сих пор применяются в стандартной практике.
• Принцип единственной ответственности. Этот принцип заключается в задании четких обязанностей и границ. Как пишет Мартин, «этот принцип — для людей. Нужно изолировать модули от сложностей организации в целом и спроектировать системы так, чтобы каждый модуль отвечал за потребности только одной бизнес-функции»24.
• Принцип инверсии (внедрения) зависимостей. Он гласит: «Модули высокого уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей — детали должны зависеть от абстракций»25. Речь идет о сокрытии внутренней сложности и деталей. Абстракция более стабильна, чем лежащая в основе логика.
• Принцип открытости/закрытости. Этот принцип гласит, что «модуль должен быть открыт для расширения, но закрыт для модификации»26. Когда мы изменяем функцию, все, что зависит от нее, также должно быть изменено. Нельзя, чтобы изменения в обмене данными вызывали каскад последующих изменений в зависимых системах или приложениях.
• Принцип устойчивых зависимостей. Принцип гласит, что «программные модули зависят от направления устойчивости. Устойчивость связана с объемом работы, необходимой для внесения изменений»27. Функциональность приложения должна основываться только на функциях, которые по крайней мере столь же устойчивы, как и модуль.
• Принцип устойчивой абстракции. Он гласит, что «компонент должен быть настолько абстрактным, насколько и стабильным»28. Преимущество абстрактных стабильных компонентов в том, что вы их легко расширять, не нарушая проект.
