Семь этапов успешного проекта построения хранилища данных

Мишель Пуле (mapoolet@mountvernondatasystems.com) — редактор SQL Server Pro и один из основателей компаний Mount Vernon Data Systems и Six Sigma Uptime. Обучает проектированию баз данных и программированию, имеет докторскую степень и звание Zachman Certified Enterprise Architect

Создание хранилища данных (data warehouse) – это масштабная задача, которую не решают в одиночку. Поскольку хранилище данных объединяет все лучшее из информационных технологий и бизнес-практики предприятия, необходимо взаимодействие бизнеса и ИТ с целью постоянной координации задач и требований для успешного внедрения хранилища данных. В этой статье вашему вниманию предлагается подход, используемый для планирования и управления проектами баз данных, в том числе транзакционных и гибридных баз данных, а также хранилищ данных. Я работаю с реляционными базами данных и хранилищами данных, в которых существенны процессы извлечения, преобразования и загрузки, то есть процессы ETL – extraction, transformation, loadin. Соответственно, предлагаемый метод применяется к этим процессам. Данный метод не ограничивается реляционной моделью и может с успехом применяться и к другим задачам – кубам OLAP, приложениям для выборки информации, например отчетов, специальных видов анализа по требованию, ключевых показателей и панелей оперативного управления.

.

В проекте построения хранилища данных можно выделить три уровня: уровень данных, уровень технологии и уровень прикладных систем (см. рисунок), соответственно data track, technology track и application layer track. При составлении схемы проекта базы данных я рекомендую задействовать эти три уровня как шаблон для организации, управления и синхронизации работ. Можно пользоваться приведенной на рисунке схемой для объяснения плана техническим исполнителям, заказчикам, которым приходится принимать решения (представителям бизнес-подразделений) и другим специалистам, участвующим в разработке проекта хранилища данных.

Рисунок. Жизненный цикл управления проектом построения хранилища данных

Метод управления жизненным циклом 7D Method

Рекомендую использовать ресурсы предприятия, например по технологии и методологии проектирования и по созданию и внедрению систем и программного обеспечения. Если на предприятии нет формализованной методологии для выполнения подобных задач, можно воспользоваться предложенным в статье подходом, который был разработан для моих проектов баз данных. Речь идет о методе управления жизненным циклом баз данных 7D Method (полное название: 7D Database Lifecycle Management Method). Предлагаемый метод 7D назван так, потому что состоит из 7 этапов: Discover (определение требований), Design (проектирование), Develop (разработка), Deploy (внедрение), Day to Day (повседневные операции), Defend (защита) и Decommission (вывод из эксплуатации).

В предлагаемом методе 7D рассматривается управление жизненным циклом баз данных без учета жизненного цикла аппаратного или программного обеспечения (прикладных программ) базы данных. На рисунке уровни аппаратного или программного обеспечения (hardware, software track) учтены, но в данной статье управление их жизненным циклом не рассматривается. Для успешного внедрения методологии жизненного цикла баз данных необходимо синхронизировать контрольные точки жизненных циклов баз данных с учетом аппаратных и программных средств.

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

Этап 1. Определение требований — Discover

Можно с уверенностью сказать, что любой проект базы данных ощутимого размера и сложности потерпит крах, если пропустить хоть шаг или допустить ошибку на этапе определения требований (Discover). На данном этапе проводится анализ и определение требований, учитываются задачи бизнеса, что особенно важно для проектов создания хранилищ данных, поскольку хранилище данных формируется для решения задач предприятия. На этой стадии проводится всестороннее исследование, в рамках которого формулируются ответы на шесть основных вопросов: Что? Как? Где? Кто? Когда? и Зачем? (what, how, where, who, when, why). Ответы на эти вопросы должны быть учтены при разработке проекта хранилища.

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

На стадии определения требований менеджер проекта собирает информацию со всех трех уровней (technology, data и application layer – соответственно, уровня технологии, данных и уровня приложений), как показано на рисунке. Для других задач менеджер проекта определяет заказчиков (stakeholder) и пользователей (user). Кроме того, он определяет их роли и требования по данным и визуализации (data/visualization). Менеджер проекта должен четко представлять стратегию управления его реализацией, а также понимать, какие цели, инициативы, метрики и ключевые показатели (KPI) при этом используются. В противном случае велика вероятность того, что проект потерпит неудачу, поскольку требования конечного пользователя не будут удовлетворены, что приведет к низким эксплуатационным показателям и отсутствию финансирования в будущем.

Этап 2. Проектирование — Design

Во главу угла на этапе проектирования ставится разработка семантической и схематической моделей хранилища данных. Эти модели должны соответствовать задачам информационных систем управления management information system (MIS) для бизнес-пользователей и отражать аналитические потребности бизнес-анализа business intelligence (BI). Для проекта хранилища данных можно построить концептуальные и логические модели данных и пространственные модели для представления многомерных кубов. Можно использовать матрицы принятия решений, чтобы точнее определить требования, которые должны быть включены в каждую пространственную модель. Можно перечислить ключевые бизнес-процессы, поддерживаемые хранилищем данных (по оси Y), а также предлагаемые размерности (по оси X). Эта матрица (X, Y) послужит руководством в процессе разработки и может быть использована в случае расширения и модификации системы и интеграции участников-предприятий в будущем. Модели, созданные на этапе проектирования, должны отвечать на шесть главных вопросов, которые сформулированы на первом этапе (что, как, где, кто, когда и зачем).

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

Обычно для технологического уровня (Technology Track) назначается специальный менеджер проекта, но вполне возможно, что и эту задачу придется выполнять вам. Контент хранилища данных может вырасти до значительных размеров, как по объему данных, так и по тематическому охвату (scope), поэтому необходимо правильно оценить размер хранилища данных до его развертывания. Сначала оцените эти размеры, чтобы определить дисковую емкость и процессорные мощности, необходимые для промышленной эксплуатации хранилища данных. Следует определить число конечных бизнес-пользователей, а также какие прикладные системы они будут использовать (например, будут ли они выполнять анализ кубов по требованию или получать кэшированные отчеты из хранилища реляционных данных). Кроме того, необходимо оценить, какой объем данных будет добавляться в течение года. Следует учесть прогноз на два года и на пять лет, поскольку хранилище данных постоянно пополняется и число требований, предъявляемых к работе хранилища, будет со временем возрастать. Для установки хранилища данных понадобится широкий спектр аппаратных, коммуникационных и программных решений, которые должны работать согласованно в соответствии с требованиями конечных пользователей. Планирование и тестирование совместной работы сложного аппаратно-программного комплекса может занять много времени.

За уровень прикладных систем (Application Track), как и за уровень технологии, может отвечать руководитель проекта или главный разработчик (архитектор) программного обеспечения. Уровень прикладных систем (Application layer) включает в себя результаты работы хранилища данных для формирования отчетов информационной системы управления (MIS) и результатов бизнес-анализа. Отчеты MIS представляют собой экраны индикаторов (screen display), панели показателей (dashboard) и печатные отчеты, которые помогают менеджерам принимать тактические бизнес-решения. Как правило, эти результаты несложно определить, запрограммировать и ввести в работу в качестве регулярных процессов, выполняемых по заранее определенному графику. Часть бизнес-анализа (BI) на уровне прикладных систем представляет собой набор запросов и ответов, получаемых из хранилища. Решения, принимаемые в процессе бизнес-анализа, часто не структурированы и не поддаются классификации, потому что они анализируют данные в произвольном режиме. Информационные табло (scoreboard), графики и сводные таблицы (pivot table) – вот примеры приложений бизнес-анализа, которые стимулируют дальнейшее исследование данных и в результате могут повлиять на стратегические решения и привести к реструктуризации предприятия.

На данном этапе многие методологии, как правило, предполагают использование прототипа или пилотного проекта. В предлагаемом методе 7D отдельный этап по созданию прототипа не выделяется. И все же в процессе проектирования на уровне прикладной системы (Application layer) может понадобиться создать упрощенную модель с экранами ввода/вывода, которая почти не требует программирования. Такая модель даст заказчикам визуальное представление о концепции и не отнимет много времени и ресурсов. Если прототип или пилотный проект все же понадобятся, выделите часть работы из общего объема и создайте прототип в соответствии с этапами метода 7D. Таким образом, в предлагаемом методе прототипы, экспериментальные и промышленные модели являются полноценными проектами и в методологическом смысле неразличимы.

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

Этап 3. Разработка — Develop

Этап разработки уровня данных (Data Track Develop) состоит из двух основных частей. В первой части строится отображение моделей данных на соответствующие физические составные части проекта (модели хранилищ реляционных данных и кубы OLAP), при необходимости задаются размеры баз данных и осуществляется разбиение таблиц, определяются соглашения по именованию для объектов хранилища данных бизнес-пользователей и технологических пользователей. Кроме того, разрабатывается стратегия индексирования данных и определяется порядок индексирования. Во второй части разрабатывают технологии схем ETL (извлечение, преобразование и загрузка данных из внешних источников в хранилище), настраивают и тестируют пакеты для служб преобразования данных Data Transformation Services (DTS) и служб интеграции SQL Server (SSIS, SQL Server Integration Services). Здесь отлаживаются процессы импорта/экспорта, разрабатываются и настраиваются сценарии T-SQL, а также тестируется процесс интеграции данных с внешними компонентами источников данных, не импортированными в хранилище данных.

На этапе разработки уровня технологий (Technology Track Develop) проводится анализ, тестирование и выделение продуктов, которые будет поставлять данная часть проектирования архитектуры системы. Эту работу необходимо выполнить для различных уровней (физического, передачи данных, сетевого, транспортного, сеанса и представления) коммуникационных каналов. Хотя многие продукты прозрачно объединяют несколько уровней в одно решение, необходимо учитывать требования будущей загрузки и технические условия реализации каждого из этих уровней, чтобы удовлетворять технические требования. Следует выделить серверы для хранилища данных и решения хранилищ, а также новые аппаратные средства для конечных пользователей, которые понадобятся для получения данных из нового хранилища. Эту работу нужно выполнить для производственного хранилища данных и для технологической подготовки базы данных – здесь будут выполняться пакеты DTS/SSIS и сценарии T-SQL, импорт данных из внешних источников данных и экспорт обработанных и собранных данных в реляционные хранилища данных и кубы OLAP. В зависимости от требований, определенных на стадии Discover, можно поддерживать витрины данных (data mart), моментальные снимки (snapshot) и базы данных отчетов (reporting database) как части среды хранилищ, которые необходимо также создать для планирования их технических условий.

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

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

Этап 4. Внедрение — Deploy

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

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

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

Этап 5. Повседневные операции — Day to Day

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

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

Этап 6. Защита — Defend

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

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

Логические угрозы носят более сложный характер в силу самой природы хранилища данных. Могут дать сбой сервер, операционная система, система управления базой данных. Данные могут быть намеренно или случайно повреждены приложениями, удалены или неверно введены либо преобразованы (особенно в процессах ETL при наполнении хранилища данных). Пользовательские интерфейсы, например браузеры, могут оказаться незащищенными от вложенных запросов SQL, которые могли содержать угрозу атаки типа инъекции SQL. Каждая потенциальная угроза должна быть обнаружена и локализована; лучше разработать средство предотвращения инцидента, чем ликвидировать последствия. Работа менеджера проекта заключается во всесторонней защите всего хранилища данных. Хорошо бы иметь опытного администратора по безопасности, к которому можно обратиться за консультацией и помощью.

Этап 7. Вывод из эксплуатации — Decommission

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

Как правило, вывод из эксплуатации выполняется одним из трех способов: без замены (Decommission with no replacement), с переключением (Decommission with cutover) и с постепенным переносом функций (Decommission with phase in/phase out). В первом случае база данных выводится из эксплуатации без замены, потому что функции, которые она выполняла, более не нужны. Например, база устарела или анализ хранящихся в ней данных уже не требуется. Второй случай: есть другая база данных, которая замещает устаревшую, при этом функции будут быстро перенесены со старой базы на новую. В данном случае пользователи просто будут переключены с одной базы данных на другую. В случае постепенного переноса функций (Decommission with phase in/phase out) старая и новая базы данных функционируют в течение некоторого времени одновременно до полного переноса функций и перехода пользователей с одной базы данных на другую. Когда это произойдет, старая база выводится без замены. Каждая схема имеет свои недостатки и достоинства. Менеджер проекта определяет, какая схема вывода из эксплуатации целесообразна в той или иной ситуации. Необходимо спланировать и выполнить данный этап вместе с другими специалистами по технологиям и пользовательским приложениям, для плавного перехода с одной базы на другую.

Эффективный цикл

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

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