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

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

2. ПРОВОДИМЫЕ РАБОТЫ

2.1 Выработка понимания требований к DW

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

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

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

2.2 Определение и сопровождение архитектуры DW/BI

Архитектура DW/BI должна описывать, откуда берутся, куда и когда отправляются дан ные, зачем и как собираются в хранилище. При этом ответы на вопрос «как» должны быть

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

489

				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

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

2.2.1 Определение технической архитектуры DW/BI

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

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

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

2.2.2 Определение процессов управления DW/BI

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

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

490	Г Л А В А 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

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

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

2.3 Проектирование и разработка хранилища и витрин данных

Обычно работы по проектированию DW/BI ведутся параллельно по трем направлениям.

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

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

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

2.3.1 Мэппинг источников данных в целевые структуры

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

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

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

491

				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. Обычно таксономия определяется логической моделью данных, а зачастую оба эти понятия и вовсе эквивалентны. В процессе мэппинга допускается присоединение, перестановка или вставка элементов данных в различные структуры при условии соблюдения требования со хранения логической целостности.

2.3.2 Исправление и преобразование данных

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

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

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

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

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

492	Г Л А В А 11