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

Производительность систем поддержки принятия решений
(Decision Support Systems, DSS), основанных на технологии Хранилищ данных

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

Первым шагом по оптимизации производительности в DSS-среде является описание ее структуры.

Что такое производительность хранилища данных?

Что же подразумевается под производительностью DSS-систем, основанных на технологии Хранилищ данных? Прежде всего - это время, которое проходит с момента размещения запроса пользователем до получения готового результата. Запрос может быть элементарным или очень сложным. К тому же он может служить различным целям. На рис.1 изображен процесс измерения производительности DSS-системы. 

Возникает вопрос: если производительность в среде Хранилища данных не является принципиально важной для решения критически важных задач, зачем вообще нужно оптимизировать производительность данной среды? Обработка данных в системе Хранилища данных носит эвристический и итеративный характер. Каждый следующий шаг остается неизвестным до тех пор, пока не завершен текущий процесс и не готов результат для дальнейшего анализа. Эффективность работы аналитика в DSS-системе сильно зависит от того, насколько быстро может быть завершен анализ. Иными словами, если аналитик А получает результат в течение получаса, он работает более продуктивно, нежели аналитик В, который вынужден в течение суток дожидаться необходимого ответа. Следовательно, чем быстрее осуществляется каждый отдельный шаг, тем плодотворнее работает аналитик (см. рис. 2). 

Итак, уменьшая время обработки запросов, можно снизить общее время, затрачиваемое DSS-аналитиком.

Кроме того, можно говорить о косвенной, однако не менее важной связи между временем обработки запросов в DSS-среде и производительностью, которая достижима в этой среде.

"Исследователи" и "фермеры"

Одним из факторов, снижающих производительность DSS-среды, является различие в типах DSS-аналитиков. Условно их можно поделить на две категории: "исследователи" и "фермеры" (см. рис.3). 

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

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

Взгляд на производительность хранилища данных для DSS-системы

Существует три подхода к производительности DSS-среды: стратегический, тактический и оперативный (см. рис. 4). 

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

Препятствия повышению производительности

Наиболее значительным препятствием (см. рис. 5) достижения оптимальной производительности DSS-Хранилища является огромное количество информации, которая "оседает" в базе данных и препятствует эффективному доступу и анализу.

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

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

Стратегический/тактический/оперативный способы повышения производительности

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

Стратегический способ

Параллельное управление данными

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

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

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

СУБД на основе технологии хранилищ данных

Второй подход к повышению производительности DSS-Хранилища (см. рис. 7) состоит в выборе подходящего программного обеспечения (т.е. СУБД).

Большинство СУБД являются полнофункциональными, поэтому осуществляют поддержку типов анализа, которые зачастую не используются в DSS-Хранилище. Например, полнофункциональная СУБД поддерживает процессы обновления (update processing), для чего требуется инфраструктура, которая выполняет фиксацию (COMMIT), блокировки (LOCK), копирование в контрольных точках (CHECKPOINT) и синхронизацию (SYNC POINT) и так далее. По мимо этого для поддержки процессов обновления необходимы ведение журнала (log tapes) и реализация механизмов резервного копирования (backup) и возврата к исходному состоянию (recovery). Все это приводит к росту накладных расходов. Между тем СУБД, разработанная специально для Хранилища данных, не содержит ненужных функций и, следовательно, может работать значительно быстрее, по сравнению с полнофункциональной СУБД. Если бы соображения производительности были единственными, то СУБД, разработанные специально под конкретное Хранилище, были бы чрезвычайно популярны. К сожалению, есть и другие аспекты, как, например, зрелость продукта, открытость технологии и т.д. Именно поэтому специальные СУБД не столь популярны.

Тем не менее, если организация стремится максимизировать производительность, можно добиться этого, используя СУБД, специализированное под данное Хранилище данных.

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

Единственная проблема, которая может возникнуть, - стоимость самой СУБД. Кроме того, может понадобиться дополнительное программное обеспечение другого производителя, что повлечет дополнительные издержки.

Настройка глубины детализации

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

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

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

Случайная выборка (living sample data)

Другой стратегический подход к повышению эффективности функционирования DSS-среды - работа с подмножествами детальных данных (выборкой). При осуществлении статистического анализа такой информации иногда имеет смысл осуществить случайную выборку данных Хранилища и производить анализ над ней. Например, если величина выборки составляет 1/1000 от объема данных Хранилища, время, которое потребуется на ее анализ, также будет в 1000 раз меньше, чем при анализе всего массива. Таким образом, мы получаем увеличение производительности на три порядка.

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

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

Однако при использовании случайной выборки возникает определенная опасность: она пригодна ТОЛЬКО для проведения статистического анализа, но ни в коем случае не для многоцелевого анализа информации Хранилища. Базы данных, построенные по закону случайной выборки, имеют свои собственные индивидуальные особенности, такие, как частота обновления данных, отбор информации для включения в выборку и т.д.

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

Однако существует ряд недостатков, связанных с выборкой: для создания соответствующей базы данных требуется отдельная платформа и СУБД.

Выборочные подмножества (selective subsets of data)

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

Использование метаданных

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

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

На стыке стратегического и тактического подхода: объединения по схеме "звезда" (star joins)

Создание специальных структур, подходящих для обработки в DSS-среде, лежит на стыке тактического и стратегического подходов (см. рис. 12). Один из наиболее известных методов, предложенных Ральфом Кимбаллом (Ralph Kimball), получил название объединения по схеме "звезда" (star join). Это структура, где данные организованы в так называемые таблицы фактов, содержащие множество данных. Наряду с таблицами фактов создаются таблицы измерений, включающие вспомогательную информацию о таблицах фактов. 

Использование star join может быть полезно для аналитика по двум причинам: во-первых, данные хранятся в наиболее удобном для пользователя виде; а во-вторых, соединение по схеме "звезда" хорошо налажено, и аналитику не нужно соединять факты с другими данными; иными словами, такие соединения являются простыми и "обкатанными", то есть именно то, что и нужно аналитику.

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