Два мощных правила

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

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

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

Разделяйте свои системы

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

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

• промышленные системы обработки транзакций (системы-источники);
• промежуточные системы хранения данных;
• системы представления хранилища данных, в том числе клиент-серверные и Web-средства создания запросов и отчетов;
• дополнительные аналитические инструменты класса high-end, поддерживающие data mining, прогнозирование, количественную оценку или распределение затрат.

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

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

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

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

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

В области представления доминируют такие структуры данных, как реляционная схема «звезда» и OLAP-кубы данных. Здесь должна обеспечиваться обработка массированных потоков больших и мелких запросов, освещающих данные со всех возможных углов. Не следует полагаться на то, что установится определенная структура запросов — они все время будут разными. Некоторые разработчики называют это атакой специальных запросов (ad hoc attack).

Четвертая система в списке — дополнительный (необязательный) уровень аналитических инструментальных средств класса high end, которые часто обращаются за данными к хранилищу данных, инициируя пакетные запросы. Инструменты извлечения данных (data mining), прогнозирования, количественной оценки или распределения затрат зачастую используют специализированные алгоритмы, выходящие за рамки компетентности архитектора хранилища данных.

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

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

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

Симметричные звезды и кубы

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

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

Симметрия обеих структур — и схемы «звезда», и OLAP-куба — также позволяет создавать:

• предсказуемые пользовательские интерфейсы, которые способны «учиться» операциям, выполняемым в процессе обработки запроса;
• предсказуемые сценарии управления в промежуточных системах, поскольку все структуры данных обладают знакомым видом и функциями;
• предсказуемую реакцию приложения при развертывании новых типов данных.

Конечно, между схемой «звезда» и OLAP-кубом существует глубокая связь. Первая больше всего подходит для работы с большими наборами данных, состоящими из миллионов или миллиардов численных измерений или многих миллионов элементов объектов-клиентов либо объектов-изделий. OLAP-кубы хороши для обработки меньших наборов данных, в которых аналитические инструментальные средства применяются для вычислений и сложного сравнительного анализа данных. Почти во всех средах с OLAP-кубами рекомендуется размещать исходные данные в звездообразных структурах и только затем использовать «мастера» для преобразования данных в OLAP-куб. Таким образом, все сложные ETL-средства промежуточных систем, которые имеют дело с однородными файлами и схемой «сущность-отношение», могут стать частью канала OLAP-данных. И, конечно, гибридные системы «звездообразная схема + OLAP» позволяют развертывать небольшие OLAP-кубы данных в огромные наборы данных в формате «звезда», и все это в едином пользовательском интерфейсе.

Замечательный результат

Конечное преимущество создания системы представления в хранилище данных на базе симметричных схем «звезда» и OLAP-кубов заключается в предсказуемом наборе точек подобия для связывания воедино данных со всего предприятия.

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

Чего же мы добились?

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

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

Ральф Кимбалл (Ralph Kimball) — соавтор Star Workstation в компании Xerox и учредитель компании Red Brick Systems. Автор трех бестселлеров о технологиях информационных хранилищ, в том числе The Data Warehouse Toolkit (Wiley, 2000). Преподает архитектуру многомерных хранилищ данных в Kimball University. Выполняет оценку проектов крупных хранилищ данных. Связаться с ним можно через Web-сайт http://www.rkimball.com.