hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
w				to							Г Л А В А 1 1
w Click
									o	m
	w
	.							.c
		p					g
			df			n		e
				-xcha

Ведение хранилищ данных и бизнес-аналитика

Архитектура

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

	проектирование
Моделирование		данных	операции
			данными
и		Хранение
			с

Метаданные	Руководство	Безопасность данных
	данными

		данных				и
						документамиинтероперабельность
и
	-аналитика						Интеграция
	Ведение				данные
хранилищ			Справочные			и	данных
	бизнес					Управление
				основные		контентом
			и

DAMA-DMBOK2 Data Management Framework

1. ВВЕДЕНИЕ

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

Ведение хранилищ данных и бизнес-аналитика

471

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

ВЕДЕНИЕ ХРАНИЛИЩ ДАННЫХ И БИЗНЕС-АНАЛИТИКА

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

Цели:

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

2.Поддержка и обеспечение эффективного бизнес-анализа и принятия решений

Входные материалы:

•Бизнес-требования

•Требования по масштабируемости, проведению операций, инфраструктуре, а также технической поддержке

•Требования по качеству, безопасности и доступу к данным

•ИТ-стратегия

•ИТ-политики и стандарты

•Внутренние источники данных

•Справочные и основные данные

•Отраслевые и внешние данные

Бизнесдрайверы

Проводимые работы:

1.Выработка понимания требований (П)

2.Определение и сопровождение архитектуры DW/BI (П)

3.Проектирование и разработка хранилища и витрин данных (Р)

4.Заполнение хранилища данных (Р)

5.Внедрение портфеля инструментов BI (Р)

6.Сопровождение информационных продуктов (O)

Поставщики:

•Руководители направлений бизнеса

•Совет по руководству данными

•Корпоративные

архитекторы

•Производители данных

•Потребители информации

•Эксперты в предметных областях

Участники:

•Спонсоры и владельцы продукта

•Архитекторы и аналитики

•Специалисты в области DW/BI (платформа BI, хранилища, управление информацией)

•Руководители проектов

•Ответственные за управление изменениями

Технические

драйверы

Результаты:

•Архитектура DW/BI

•Информационные

продукты

•Процесс заполнения

•Деятельность по руководству

•Описание происхождения

•План обучения и перехода к применению на практике

•План выпуска релизов

•Процесс сопровождения информационного продукта

•Меры по оптимизации нагрузки

•Мониторинг использования средств BI

Потребители:

•Потребители информации

•Клиенты

•Руководители

именеджеры

Методы:	Инструменты:	Метрики:
• Прототипирование	• Репозитории метаданных	• Метрики использования
с целью уточнения	• Средства интеграции данных	• Удовлетворенность
требований	• Аналитические приложения	потребителей/
• Бизнес-аналитика		пользователей
самообслуживания		• Востребованность данных
• Данные аудита,		по предметным областям (%)
доступные по запросам		• Время ответа /
		Производительность

(П) Планирование, (К) Контроль, (Р) Разработка, (О) Операции

Рисунок 79. Контекстная диаграмма: ведение хранилищ данных и бизнес-аналитика

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

472	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

Всерьез строительство хранилищ данных развернулось в 1990-е годы. С тех пор, особенно в связи с одновременным развитием бизнес-аналитики (Business Intelligence, BI) как основного драйвера принятия бизнес-решений, корпоративные хранилища данных успели стать обыденной вещью. В большинстве организаций есть хранилища данных, и их ведение рассматривается как ключевой компонент корпоративного управления данными1. Хотя концепция хранилища дан ных и считается устоявшейся, ее развитие не прекращается. По мере появления всё новых форм данных и концепций, таких как озеро данных (data lake), неизбежно продолжится и эволюция представлений о хранилище данных (см. главы 8 и 15).

1.1 Бизнес-драйверы

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

1.2 Цели и принципы

Организации внедряют хранилища данных в следующих целях:

поддержка деятельности в области BI;

повышение эффективности бизнес-анализа и принятия решений;

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

При планировании и внедрении хранилища данных следует руководствоваться следующими принципами.

1 http://bit.ly/2sVPIYr

Ведение хранилищ данных и бизнес-аналитика

473

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

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

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

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

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

Выстраивайте метаданные параллельно с хранилищем. Критическим фактором успеха хра нилища данных является способность объяснять смысл и происхождение данных. В частно сти, нужно всегда иметь готовые ответы на базовые вопросы вроде: «Почему в поле суммы указано X? Как было рассчитано это значение? Откуда взяты исходные цифры?» Структура метаданных должна моделироваться на стадии проработки модели данных, а учет и управле ние — входить в состав рабочих процессов и текущих операций.

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

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

1.3 Основные понятия и концепции

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

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

474	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

к успеху и залог превосходства над конкурентами, люди, по сути, расписываются в том, что без BI трудно рассчитывать на радужные перспективы: без правильной постановки вопросов в области сбора и анализа данных организация не получит адекватных ответов о характеристиках своих продуктов, услуг и клиентов, а без всестороннего анализа и учета потребительского спроса руководству не удастся находить оптимальные пути к реализации стратегических целей и пла нов. Во-вторых, под бизнес-аналитикой понимается еще и комплекс технологий, используемых для такого анализа данных. Являясь логическим развитием инструментов поддержки принятия решений, инструменты BI предоставляют возможности по формированию и обработке запро сов (querying), извлечению информации (data mining), проведению статистического анализа (statistical analysis), формированию отчетности (reporting), сценарному моделированию (scenario modeling), визуализации данных (data visualization), а также созданию и применению информа ционных панелей (dashboarding). Средства BI сегодня находят применение во всех областях — от бюджетного планирования до расширенной аналитики (advanced analytics).

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

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

Корпоративным хранилищем данных (Enterprise Data Warehouse, EDW) называют централи зованное DW, предназначенное для информационного обеспечения BI-потребностей всей орга низации. EDW поддерживает корпоративную модель данных, что обеспечивает согласованность данных, используемых для принятия решений в масштабах организации.

1.3.3 Ведение хранилища данных

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

В традиционном понимании ведение DW относится только к структурированным данным: элементы данных хранятся в полях определенного формата, объединенных в файлы или таблицы, структура которых задокументирована в модели данных. Однако с появлением новейших про грессивных технологий к области BI/DW стали относить и управление полуструктурированными

Ведение хранилищ данных и бизнес-аналитика

475

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

и неструктурированными данными. Полуструктурированные данные определяются как электрон ные элементы, организованные в семантические сущности, атрибуты которых не упорядочены и не связаны (форматы XML и EDI к таковым относятся, HTML — нет). К неструктурированным данным относятся данные, не описываемые какой-либо предопределенной моделью данных. Поскольку су ществует огромное количество форматов неструктурированных данных (e-mail, текстовые файлы, видео, фото, веб-страницы и т. д.), определение подходящей архитектуры и структуры хранилища, которое обеспечивало бы возможность комплексного анализа всего этого разнообразия в рамках единой системы руководства ведением хранилищ данных, — задача до сих пор не решенная.

1.3.4 Подходы к организации хранилища данных

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

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

Данные поступают в DW из внешних систем.

При сохранении данные упорядочиваются и систематизируются с целью повышения их цен ности.

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

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

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

1.3.5 Корпоративная информационная фабрика (архитектура Инмона)

Предложенная Биллом Инмоном архитектура DW известна под названием «корпоративная ин формационная фабрика» (Corporate Information Factory, CIF). DW, согласно определению Инмона, представляет собой «предметно-ориентированный, интегрированный, поддерживающий привязку

1 Уильям «Билл» Инмон (англ. William «Bill» Inmon, р. 1945), Ральф Кимбалл (англ. Ralph Kimball, р. 1944) — американ ские специалисты по информатике. — Примеч. пер.

476	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

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

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

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

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

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

Концептуальная модель управления DW в контексте корпоративной информационной фабрики (CIF) описана в книге Инмона, Клаудии Имхофф (Claudia Imhoff) и Райана Соузы (Ryan Sousa) (см. рис. 80).

Архитектура CIF включает следующие компоненты.

Приложения: поддерживают операционные процессы и поставляют детализированные дан ные в основное хранилище данных и хранилище операционных данных (Оperational Data Stores, ODS), где они могут анализироваться и обобщаться.

Ведение хранилищ данных и бизнес-аналитика

477

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

		Справочные				Исторические
						справочные
		данные				данные
Приложения							Витрины данных
данныедетализированные«Сырые»	App					DM	DM	DM	Анализ
			преобразованиеиИнтеграция
	App								Разведочный
							DW		анализ

App

					OpDM	Оперативный
						анализ
		App			ODS
Операционные отчеты
				Операционные отчеты
		(раздельно
				(интегрированные)
по приложениям)

Рисунок 80. Корпоративная информационная фабрика (CIF)

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

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

Хранилище операционных данных (ODS) представляет собой интегрированную базу опе рационных данных, поступающих от приложений и/или из других баз данных. В ODS обычно содержатся только текущие данные или данные за относительно небольшой отчетный период (30–90 суток), в то время как в главном DW накапливаются еще и исторические данные (ча сто за многие годы). Главное же отличие ODS от DW заключается в том, что операционные данные динамически изменяются по мере поступления новых данных из среды интеграции в отличие от статичных данных в главном хранилище. ODS используются далеко не во всех организациях, а только в тех, где требуется минимизировать время запаздывания. При его наличии ODS может также служить первоисточником данных для DW или, как альтернатива, контрольным источником для проверки корректности данных в DW.

478	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

Витрины данных: в витринах данных (Data Marts, DM) отображаются подготовленные к ана лизу данные. Обычно это подмножества данных из DW, структурированные специально для нужд узкоспециализированных аналитиков или иных категорий потребителей. Например, в витрины могут выводиться агрегированные данные для быстрого анализа. Многомерные модели часто позволяют использовать приемы формирования быстрых (ненормализован ных) выборок данных для пользовательских витрин различного профиля.

Витрина операционных данных: витрина операционных данных (Operational Data Mart, OpDM) стоит особняком, поскольку в ней отображается выборка данных, требующихся для оперативного принятия тактических решений. Данные в OpDM поступают напрямую из ODS, вследствие чего OpDM наследует многие характеристики ODS. В частности, в ней при сутствуют только текущие или новейшие данные, которые быстро меняются.

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

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

Справочные, основные и внешние данные: помимо транзакционных данных, поступающих из приложений, CIF использует данные, необходимые для понимания транзакций, — напри мер, справочные и основные данные. Доступ к общим для всех компонентов определениям таких данных существенно упрощает интеграцию DW. Хотя приложения используют исклю чительно текущие значения справочных и основных данных, самому DW требуются и их исторические наборы, и данные о сроках их действия для правильной интерпретации всего массива накопленных данных (см. главу 10).

Рисунок 80 также отражает потоки данных внутри CIF, начиная со сбора или создания данных приложениями (слева) вплоть до выдачи и анализа информации системами витрин данных (спра ва). При продвижении слева направо данные претерпевают ряд изменений. Например:

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

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

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

Требовательность ко времени ответа снижается (так как стратегические решения спешки не требуют).

Для обработки любой операции, запроса или процесса требуется значительно больше данных.

Ведение хранилищ данных и бизнес-аналитика

479

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Данные в DW и витринах отличаются от данных приложений следующими особенностями:

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

интеграция вместо узкой специализации;

рассматриваются переменные значения по времени, а не текущие значения данных;

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

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

1.3.6 Многомерное хранилище данных (архитектура Кимбалла)

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

Многомерные модели, часто называемые также звездообразными схемами (Star Schema), пред ставляют собой подборки фактов (facts), под которыми понимаются числовые данные или харак теристики бизнес-процессов (например, объем продаж) в проекции на измерения (dimensions), которые используются для описания атрибутов, соответствующих фактам и позволяющих поль зователям правильно интерпретировать фактические данные (например, с объемом продаж сопоставляются артикул продукта X и отчетный квартал). Таблица фактов связана со множе ственными таблицами измерений, и в графическом представлении такая схема организации данных имеет форму звезды, откуда и обиходное название (см. главу 5). При наличии в модели множественных таблиц фактов они проецируются на общие для различных таблиц так называе мые «конформные» (conformed) измерения через «шину» (bus), подобную компьютерной шине2 Множественные витрины данных на корпоративном уровне могут интегрироваться посредством подключения их к общей шине конформных измерений.

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

1 http://bit.ly/1udtNC8

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

480	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

Таблица 27. Пример матрицы шины DW предприятия

			Предметные области
Бизнес-процессы	Дата	Продукт		Магазин		Поставщик	Склад
Продажи	X	X		X
Запасы	X	X		X		X	X
Заказы	X	X				X
Потенциальная конформность измерения	Да	Да		Да		Да	Нет

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

Схематическое представление архитектуры DW/BI по Кимбаллу (см. рис. 81) часто называют «шахматным» (Kimball’s Data Warehouse Chess Pieces — «шахматные фигуры хранилища данных Кимбалла»). Обратите внимание, что в модели Кимбалла функциональная роль самого храни лища данных значительно шире, чем в модели Инмона, и включает все компоненты подготовки/ загрузки и представления/выдачи данных.

Оперативные системы — источники данных: оперативные/транзакционные приложения ор ганизации. Именно ими создаются исходные данные, интегрируемые в ODS и DW. В принципе, этот компонент эквивалентен области «Приложения» на схеме архитектуры CIF (см. рис. 80).

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

Ведение хранилищ данных и бизнес-аналитика

481

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

	Область		Область		Средства
Оперативные	временного		представления		доступа
	хранения		данных		к данным
системы —
источники
данных	СЕРВИСЫ:
	• Очистка				ТЕКУЩИЕ
Extract	• Объединение	Load	Витрина №1	Access
	• Стандартизация				ЗАПРОСЫ
	• Конформные
	измерения
Extract	БЕЗ ИЗМЕНЕНИЙ	Load	Витрина №2	Access	ГЕНЕРАТОРЫ
			Шина Конформные		ОТЧЕТОВ
	• Реляционные				АНАЛИТИЧЕСКИЕ
	СРЕДСТВА
	ХРАНЕНИЯ:
	• Плоские файлы
Extract	таблицы	Load	DW измерения	Access	ПРИЛОЖЕНИЯ
	• Наборы данных
	в XML-формате				МОДЕЛИ:
	ОБРАБОТКА:
			Витрина №n		• Прогнозные
Extract	• Сортировка	Load		Access
	• Упорядочение				• Скоринговые
					• Data Mining

Рисунок 81. Пример «шахматного» представления архитектуры DW по Кимбаллу1

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

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

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

1.3.7 Архитектурные компоненты DW

Среда хранилища данных включает ряд архитектурных компонентов, которые нужно выстроить таким образом, чтобы она наилучшим образом соответствовала потребностям предприятия. Ри сунок 82 отражает компоненты архитектуры DW/BI в связке со средой обработки больших дан ных, обсуждению которой посвящен настоящий раздел. Дело в том, что с развитием концепции

1 Переработанная версия иллюстрации из: Kimball and Ross (2002). Используется с разрешения правообладателя.

482	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

больших данных изменилось и представление об архитектуре DW/BI, поскольку среда обработки больших данных стала дополнительным магистральным каналом притока данных в информационную среду организации.

Рисунок 82 отражает также и фазы жизненного цикла данных. Из систем-источников данные поступают в область временного хранения, где подвергаются очистке и обогащению, интегри руются и отправляются на хранение в DW и/или ODS. Доступ к данным из DW осуществляется через витрины или кубы; также они используются для генерирования разнообразных отчетов. Параллельно аналогичной обработке подвергаются и входящие потоки больших данных, но с од ним принципиальным отличием: в большинстве хранилищ данные интегрируются перед загруз кой в таблицы; обработка же больших данных требует их предварительной загрузки до интегра ции. BI больших данных может включать функции прогностического анализа и статистического анализа на предмет выявления скрытых закономерностей, а также более традиционные формы аналитической отчетности (см. главу 14).

Концептуальная архитектура DW/BI и среды обработки больших данных

Источники

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

BI

Приложения

Подготовка данных

Операционная

Повышение качества

отчетность

Обогащение и дополнение

Зависимые

Временное

Операционная отчетность

хранение

хранилища

и аналитика

Оперативные

Очистка

ODS

Геопространственная

Интеграция

и демографическая аналитика

Центральное

системы

Обогащение

Стандартизация

хранилище

Управление

Витрины

эффективностью

Предметно-ориентированные

	DaaS				Неизменяющиеся			Визуализация данных
					C привязкой ко времени
				Справочные
	Результаты				Атомарные			Data & Text
			и основные данные
	обработки	MDM			Исторические данные
							Кубы	Mining
	больших			Конформные
				измерения
	данных							Анализ
					Большие данные			неструктурированных данных
	E-mail
	Мультимедиа							Предиктивный анализ
	Датчики						Модель
	Интернет вещей	Прием		Озеро	Интеграция	Изучение
	Соцсети						оценки
				данных
	Web DaaS							Машинное обучение
	DW

Рисунок 82. Архитектурная концепция DW и BI в условиях доступности больших данных

Обучение Прогноз Оценка Сравнение Настройка Отчетность

1.3.7.1 СИСТЕМЫ-ИСТОЧНИКИ

Системы-источники в левой части схемы (рис. 82) включают как внутренние оперативные си стемы, так и внешние источники данных, привносимых в среду DW/BI. Под оперативными си стемами в данном контексте понимаются прикладные системы управления взаимоотношения ми с клиентами (CRM), бухгалтерским учетом и кадровыми ресурсами, а также прочие системы

Ведение хранилищ данных и бизнес-аналитика

483

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

1.3.7.2 ИНТЕГРАЦИЯ ДАННЫХ

Интеграция данных включает алгоритмы извлечения, преобразования и загрузки (ETL), виртуа лизацию данных и другие технические средства унификации, формализации и доставки данных по месту назначения. В случае сервис-ориентированной архитектуры (SOA) уровни сервисов данных также относятся к этому компоненту. На иллюстрации (рис. 82) все стрелки соответству ют различным интеграционным процессам (см. главу 8).

1.3.7.3 ОБЛАСТИ ХРАНЕНИЯ ДАННЫХ

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

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

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

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

ваемые ими:

определение связей между бизнес-ключами и суррогатными ключами для повышения про изводительности;

индексация и определение внешних ключей с целью поддержки множественных измерений;

реализация алгоритмов регистрации изменений данных (Change Data Capture, CDC), что позволяет выявлять, учитывать и сохранять историю изменений.

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

484	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

Витрины данных — разновидность систем хранения данных, используемых для выдачи или

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

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

вразличных витринах.

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

1.3.8 Типы технологий загрузки

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

1.3.8.1 ИСТОРИЧЕСКИЕ ДАННЫЕ

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

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

Ведение хранилищ данных и бизнес-аналитика

485

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

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

1.3.8.2 ПАКЕТНАЯ РЕГИСТРАЦИЯ ИЗМЕНЕНИЙ ДАННЫХ

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

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

486	Г Л А В А 11

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

Таблица 28 в обобщенном виде описывает основные различия между известными методами регистрации изменений данных (CDC) по параметрам, определяющим их относительную слож ность, оперативность и ресурсоемкость. В столбце «Повторы» указано, возможны ли ситуации дублирования в исходных системах изменений, которые ранее уже были перенесены в целевую среду. Если там стоит «+», значит, не исключены ситуации с многократной перезаписью одних и тех же фактов. В столбце «Удаления» «+», напротив, свидетельствует о пригодности метода CDC для отслеживания удаленных записей в системе-источнике, что бывает весьма полезно для выявления устаревших измерений, фактические данные по которым более не регистрируются, а потому подлежащих изъятию из многомерной модели. В тех случаях, когда удаления в систе ме-источнике не отслеживаются, приходится предпринимать дополнительные усилия для того, чтобы их фиксировать (см. главу 8).

Таблица 28. Сравнительные характеристики различных методов регистрации изменений данных (CDC)

	Метод CDC	Требования к системе-источнику	Уровень	Загрузка	Загрузка	Повторы	Удаления
			сложности	фактов	измерений
	Загрузка «дельт»	Система-источник поддерживает
	данных с метками	ведение записей с метками системных	Низкий	Быстрая	Быстрая	+
	времени	даты/времени
	Загрузка таблиц	Изменения в системе-источнике
	журналов «дельт»	фиксируются в табличной форме	Средний	Средняя	Средняя	+	+
	данных	в регистрационных журналах
	Журнал транзакций	Система регистрирует все изменения	Высокий	Средняя	Средняя		+
	СУБД	в БД на уровне журнала транзакций
	Публикация	Система-источник публикует сообщения
		об изменениях в режиме реального	Сложнейший	Медленная	Медленная		+
	изменений
		времени
	Полная загрузка	Отметки об изменениях отсутствуют.	Простейший	Медленная	Средняя	+	+
		Таблицы переписываются целиком

1.3.8.3 РЕЖИМ РЕАЛЬНОГО ВРЕМЕНИ И РЕЖИМ, БЛИЗКИЙ К РЕАЛЬНОМУ ВРЕМЕНИ

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

Ведение хранилищ данных и бизнес-аналитика

487

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
	w Click										m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

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

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

Мелкие партии (буферизация в системе-источнике). Сам алгоритм регистрации новых дан ных в данном случае не отличается от алгоритма пакетной загрузки данных раз в сутки, но данные передаются в DW мелкими партиями и значительно чаще (например, каждые 15 ми нут) или по достижении порогового объема данных в буфере (например, 300 транзакций или 1Gb данных). Это позволяет переносить процессинг на дневное время, не создавая столь ин тенсивной нагрузки на системные ресурсы, как при ночной пакетной обработке транзакци онных данных за сутки. При таком подходе важно предусмотреть очередь ожидания, в кото рую будут последовательно отправляться последующие пакеты в тех случаях, если обработка какого-то пакета затянулась, чтобы соблюсти правильную хронологическую очередность за грузки данных в хранилище.

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

488	Г Л А В А 11