- 30 ноября 2001 г.
Семь шагов по оптимизации производительности Хранилища данных
Предлагаемая вашему вниманию рубрика посвящена вопросам производительности
Хранилищ данных. В первой статьей предлагается несколько способов повышения
производительности. Рассмотренные методы затрагивают в основном оптимизацию
скорости выполнения запросов.
Чтобы удовлетворить потребности пользователей в более функциональном анализе, можно использовать поэтапный переход от поддержания детальной информации к использованию агрегированных данных.
Опыт развития технологии Хранилищ данных показывает, что технический прогресс иногда идет вразрез с достижением более высокой потребительской ценности. Речь идет об автоматическом использовании агрегатов данных или моделей данных в одном приложении.Первоначально компании просто извлекали информацию из оперативных систем и помещали ее в другую базу данных, как правило, в ту, которая использовалась для OLTP-процессов (online transaction processing). Благодаря этому более мощный и сложный анализ не входил в конфликт с OLTP-процессами, в большей степени зависящими от целевого назначения.
Большинство оперативных систем осуществляют хранение данных в форме нормализованной модели (normalized model), в которой посредством определенных алгоритмов устраняется избыточность и упрощаются отношения между данными. Но, несмотря на то, что данная модель подходит для работы с OLTP-процессами, аналитические запросы не могут выполняться эффективно на тех OLTP-базах.Рост объема анализируемых данных сопровождался увеличением времени выполнения запросов. Поскольку аналитическим системам не нужно было поддерживать OLTP-процессы, многие разработчики стали пытаться "предвосхитить" выполняемые запросы, применяя следующие приемы:
- создание таблиц предварительно агрегированных данных;
- индексирование (чтобы избежать необходимость просматривать слишком большие объемы данных);
- "денормализация" модели - размещение данных в одной таблице, а не в нескольких, которые необходимо соединять;
- хранение данных в отсортированном виде, устраняющем необходимость в процессе "and sort".
Для того чтобы реализовать любой из вышеперечисленных методов оптимизации, разработчикам необходимо прежде всего понять как структуру запросов, так и организацию данных.
В самом начале многие разработчики аналитических систем не имели опыта работы с технологией Хранилищ данных - их практические навыки заключались в умении оптимизировать производительность, манипулируя различными параметрами и моделями данных, что считалось шагом вперед, так как в то время базы данных выдавали крайне мало информации.По мере увеличения контингента пользователей и усложнения запросов, пользователи уже не могли сформулировать, какой анализ они хотели бы выполнить, но даже если это им и удавалось, время, необходимое на обработку и хранение результатов запросов становилось слишком большим. Решением этой проблемы стало предложение еще раз извлечь данные - на этот раз для OLAP-систем, которые позволяют выполнять "продольные и поперечные срезы" данных ("slicing and dicing").
СОВРЕМЕННЫЙ АСПЕКТ ПРОБЛЕМЫ
Сегодня пользователи хотят не только выполнять более сложный и гибкий анализ, но и использовать более актуальную и своевременную информацию. Данные должны быть доступны круглосуточно и семь дней в неделю, и многие пользователи пытаются добиться возможности реагировать на событие в течение часов (а в некоторых случаях, минут или секунд) после его возникновения.
Необходимость в перемещение данных на различные платформы, манипулирование и предварительная подготовка данных для запросов, а также знание наперед того, какие запросы будет необходимо выполнить, стала серьезным препятствием на пути развития компаний. Вместо того, чтобы усложнять имеющуюся архитектуру, разработчики должны научиться использовать технологии Хранилищ данных для выработки решений, направленных на упрощение систем, в результате чего сократится перемещение и передача данных.В идеале компании должны хранить детализированную информацию в наименее агрегированном виде, так как данная модель является нейтральной с точки зрения функциональности. Это дает возможность задавать более широкий спектр вопросов. Основная идея состоит в том, что детальную информацию можно агрегировать всегда, а агрегаты данных разложить на составные части невозможно. Это не означает, что нужно избегать использования таблиц агрегатов; смысл в том, что не стоит замещать детальные данные только агрегатами.
Основная цель построения таблиц агрегатов и денормализации данных - увеличение производительности. Если бы у вас была возможность использовать неограниченный объем информации для того, чтобы задавать любые запросы и получать мгновенные ответы, вам бы никогда не потребовалось создавать агрегаты. Эти структуры - это ухищрение, чтобы обойти имеющиеся ограничения. Но использование агрегатов требует большего дискового объема и дополнительных затрат на управление данными и приводит к увеличению времени между возникновением события и реагированием на него.ОПТИМИЗАЦИЯ ПРОИЗВОДИТЕЛЬНОСТИ
Процесс перехода от уровня детальных данных к уровню агрегатов не должен осуществляться без понимания его возможных последствий. Это процесс можно разделить на семь отдельных этапов (см. рисунок 1). Важно помнить, что если используемая вами технология не поддерживает работу с данными на низших уровнях, следует задуматься, соответствует ли она потребностям вашей компании.
Нейтральная модель данных
При работе на низшем уровне происходит использование атомарных данных в форме нормализованной модели, не имеющей соответствия с какой-либо группой или функцией. Данные находятся в наиболее детализированном формате, необходимом для достижения целей организации. Это не обязательно должны быть данные по операциям за каждый день, однако должна оставаться возможность спуститься до соответствующего уровня в случае необходимости.
В целях безопасности и взаимосовместимости во многих компаниях используются аналитические выборки доступа (access view) , чтобы определить таблицы детальных данных. Аналитические выборки доступа добавляют блокирующий модификатор (locking modifier), который позволяет пользователям выбирать данные из таблицы, даже если в тот момент другие пользователи осуществляют запись в ту таблицу (эта технология известна как "read without intent", или "dirty read" - "непреднамеренное чтение", или "грязное чтение"). При этом запросы выполняются на основе данных этих аналитических выборок, а не таблиц, что помогает избежать сложностей, связанных с блокировкой (locking). Аналитические выборки можно использовать только при условии, что они в точности отражают базовые таблицы деталей.Зачастую для определения того, возможно ли достичь требуемой производительности, достаточно просто задать оптимизированный SQL-запрос к детальным данным. Часто низкие показатели производительности являются следствием использования неподходящего инструмента или невыполнением наиболее эффективных операторов запроса. Многие процветающие компании применяют подобный подход, что во многом и обуславливает их успех.
Рис. 1. Семь шагов оптимизации
Реализация аналитических выборок
Первый шаг к повышению производительности заключается в переходе к использованию аналитических выборок для таблиц, что позволяет существенно облегчить навигацию. И хотя аналитические выборки, как правило, не оказывает значительного влияния на производительность, в случаях, когда требуется специфическая модель данных, их использование может "помочь" инструменту сгенерировать "лучший" SQL-запрос. Так как аналитические выборки могут быть оптимизированы для конкретной базы данных, нет необходимости обращаться к отдельному поставщику для получения информации по каждой из существующих баз.
Вы также можете встроить оптимизированные технологии соединения в аналитические выборки вместо того, чтобы требовать от инструментов и пользователей понимания этих соединений. Другое преимущество данного подхода заключается в том, что его использование способствует повышению безопасности хранения данных в таблицах; примером может служить телекоммуникационная компания, которая использовала аналитические выборки для создания модели логической схемы "звезда" для работы с конкретным инструментом. Связи, необходимые для нормализованной модели данных, были скрыты в определении аналитической выборки для модели, зависящей от инструмента; инструмент запроса "видел" модель данных как схему "звезда", несмотря на ее фактическое отсутствие.Администратор баз данных может таким образом использовать аналитические выборки, чтобы обеспечить логическую функциональность для каждой структурной единицы предприятия. Аналитические выборки предоставляют информацию пользователям в том виде, в котором они ожидают ее увидеть, даже если один и тот же элемент определяется по-разному. Например, одно подразделение желает получить какую-то величину в футах, а другое - в дюймах. При использовании аналитических выборок данные необходимо сохранить только один раз, а затем конвертировать их в логическое определение аналитической выборки. При этом снижается избыточность хранимой информации, обеспечивается постоянство и упрощается механизм управления данными.
Добавление индексов
При добавлении индексов можно остановиться на более простой технологии, например, применение вторичных индексов, или же использовать более сложные схемы, такие, как скрытые (covered), агрегатные (aggregate) индексы или индексы соединения (join indexes). В большинстве случаев введение индексов улучшает производительность. Главным достоинством данного метода является то, что система сохраняет их в соответствие с таблицами базы данных. И хотя поддержка и автоматическое обновление индексов требует дополнительных накладных расходов, данные для запросов всегда находятся в соответствии с детальной информацией. сопоставление с детальными данными - обычная практика в случае с небольшими справочными таблицами, однако использование этой технологии применительно к крупным и часто обновляемым таблицам требует более серьезного отношения.
Расширение системы
В случае если индексы и представления не приводят к желаемому повышения производительности, имеет смысл переоценить методы управления данными и определиться на предмет долгосрочных бизнес перспектив. Прежде всего необходимо задаться следующими двумя вопросами:
- Какое расширение необходимо для достижения требуемого уровня производительности?
- Что в конечном итоге принесет достижение этого уровня?
Если ваша цель - Хранилище данных, способное работать с данными в режиме реального времени, создание таблиц агрегатов и последующее извлечение и манипулирование данными создадут препятствие для ее достижения. Если же вы хотите оправдать понесенные расходы, одним из выходов является расширение системной конфигурации. Успешность этого шага, однако, зависит от возможностей базы данных: многие из них используют последовательную обработку данных для таких операций, как создания связей, сортировка или агрегирование. Если ваша база данных работает по такой схеме, расширение системы может не дать увеличения производительности, поскольку не ускорит выполнение запросов.
Если расширение системы невозможно с технической точки зрения или же экономически неоправданно, вы можете рассмотреть другие альтернативы, которые требуют поддержания извлеченных данных отдельно от исходных детальных данных. Эти варианты имеют некоторые недостатки, такие, как повышение издержек, увеличение требуемого дискового пространства и времени обработки, усложнение управления данными. К примеру, одна торговая компания предпочитает хранить данные на низком уровне без дополнительной обработки. Это предприятие решило, что получение ответа на запрос в течение двух минут через несколько часов после проведения соответствующей операции лучше, чем ответ, полученный за доли секунды, через неделю после события.Рациональное создание агрегатов и денормализация
Для того чтобы усилить возможности используемой базы данных, необходимо, чтобы данные физически располагались на той же платформе, что и детальная информация.
Переход к денормализации означает, что вы предпочли более высокую производительность гибкости анализа. Чтобы убедиться в том, что это не приведет к ограничению деловых возможностей вашей компании, следует придерживаться стратегии сосуществования (а не замещения), то есть продолжать использовать детальные таблицы для мощного анализа и добавлять денормализованные структуры.На данном этапе происходит создание таблиц агрегатов без конкретной привязки к какой-либо функции (например, на уровне филиала, а не на уровне счета), чтобы получить те же данные, но на более высоком уровне агрегирования. Это также относится и к денормализации. Например, при нормализованной модели данных zip-код, город и штат (регион) никогда не будут содержаться в одной таблице адресов. Если у вас есть zip-код, вы используете справочную таблицу для получения города и региона. Когда вы запрашиваете zip-код, вы, как правило, также запрашиваете регион и город, поэтому одни и те же таблицы содержат эти столбцы, чтобы исключить соединения.
Рациональное создание агрегатов нацелено на универсальность, а не на решение конкретной задачи. В некоторых случаях подобные таблицы встречаются в исходной модели данных, так как пользователи предполагают, что они необходимы для обработки запросов. Рациональное создание агрегатов может способствовать различным целям пользователей или целых отделов, оправдывая затраты руководства. Повторим, что данный подход возможен в относительно небольших и не слишком часто обновляемых справочных таблицах, однако его использование становится более проблематичным по мере роста объема данных и/или частоты их обновления.Создание "иррациональных" агрегатов и денормализация
Если рациональная денормализация не помогла достичь требуемой производительности, вы можете предпринять шаг построения "иррациональных" агрегатов и моделей данных, направленных на достижение отдельной функции. Таблицы, созданные таким образом, будут иметь именно те столбцы, которые необходимы вам для создания отчетов. Тем не менее при использовании данного подхода вы частично жертвуете гибкостью анализа. Кроме того, данные таблицы требуют больше времени на управление данными и больших объемов дискового пространства.
Примером разработки модели для достижения отдельной функции может служить практика медицинского обслуживания, где для распределения клиентов на сегменты представляет собой достаточно сложный процесс. Поскольку отношения с клиентами, как правило, не афишируются, и правила отношений с ними довольно запутанные, проведение анализа детальных данных в режиме реального времени представляется затруднительным.В некоторых случаях разработка модели данных может оказаться абсолютно нерациональным шагом, поскольку может вызвать ряд скрытых проблем. Например, одна торговая компания использовала для хранения информации о клиентах 30 таблиц, каждая из которых содержала одинаковый набор столбцов. Когда работников спросили, зачем это было сделано, они ответили, что у них попросили тридцать различных запросов, каждый из которых требовал один и тот же тип информации. Очевидно, что подобный подход при создании пользовательской модели данных очень быстро станет неуправляемым.
Экспорт данных
Если до сих пор не удалось достичь требуемой производительности, вы должны принять ряд серьезных решений. Вы можете расширить конфигурацию для достижения большей эффективности, экспортировать данные в специальную систему функционального анализа или же пересмотреть требования, предъявляемые к производительности. Каждый из перечисленных шагов достаточно дорог. Как и раньше, вы должны стараться найти баланс между ожидаемой полезностью и необходимыми для ее достижения усилиями.
ОБОСНОВАНИЕ ШАГОВ
Прежде чем предпринять перечисленные выше действия, нужно четко отдавать себе отчет в том, какую пользу принесет тот или иной шаг и какие издержки повлечет за собой его осуществление. При этом требуется принимать решения как в рамках долгосрочной, так и краткосрочной стратегии. В некоторых случаях вы можете создавать таблицы агрегатов или добавлять денормализованные модели, от которых вы неизбежно откажитесь по мере изменения функций. Такой подход приемлем до тех пор, пока удаление таблиц не вызывает перебоев или значительных изменений в приложении.
Одним из способов определения того, насколько далеко имеет смысл зайти при осуществлении изменений, является проведение анализа затрат и выгод (cost-benefit analysis). Какие издержки возникнут при осуществлении индексирования, создании таблиц агрегатов или денормализации модели данных? Под затратами подразумеваются такие аспекты, как физическое пространство на диске, ресурсы, требуемые для управления созданной структурой, а также упущенная выгода из-за задержек, возникших при поддержании процесса. Выгодой является более высокая производительность при выполнении запросов, а также дополнительные возможности как следствие сокращения времени ответа. К другим достоинствам можно отнести согласованность и повышение производительности работы пользователей, а также удовлетворенность пользователей вкупе с улучшением использования продуктов "третьих фирм". На рис. 2 представлена базовая процедура из шести шагов, с помощью которой можно быстро определить возможности оптимизации той или иной организации.
Рис. 2. Оценка возможностей оптимизации
Еще один важный вопрос - частота и регулярность поступления запросов и постоянство производительности. Например, около 70% из 1000 запросов к детальным данным, которые задавались в течение недели в одной компании, было составлено на основе вопросов, для формулирования которых достаточно данных на уровне агрегатов. При использовании таблиц агрегатов выполнение этих запросов происходило приблизительно за 6 секунд вместо 4 минут (общая разница во времени обработки составляет ((4х60 - 6)/60)х(1000х0,7) = 2730 мин.). Даже при условии, что использование данной схемы потребует дополнительных 105 мин./нед. для поддержки таблиц агрегированных данных, экономия 2730 мин./нед. при обработке запросов полностью оправдывает этот шаг. По прошествии определенного периода времени компания обнаружила, что теперь большинство запросов используют детальную информацию. В этом случае таблицы агрегатов могут быть просто удалены без нанесения ущерба другим процессам.
Тем не менее анализ затрат и выгод не является единственным критерием при определении целесообразности того или иного шага, хоть и говорит о многом. Среди других факторов - приоритеты организации и потребности конечного потребителя. Пользователи должны осознавать техническую сторону проблемы и понимать, какие затраты может повлечь за собой выполнение запроса в течение нескольких секунд.Как правило, большинство соображений при реализации проектов Хранилищ данных опираются на возможность быстрого получения информации. Тем не менее преимущества, которые дает анализ и гибкость, являются более важными в долгосрочной перспективе. Стремясь оптимизировать процесс в краткосрочной перспективе, многие сразу переходят к использованию таблиц агрегированных данных и функциональных моделей. Однако, уделив некоторое время анализу реальных задач и выработав корректное обоснования, можно более дальновидно подойти к реализации проектов Хранилищ данных.
Лица, ответственные за реализацию Хранилищ данных (а не пользователи), должны определять, нужно ли использовать таблицы агрегатов или функциональные модели. С другой стороны, именно пользователи, а не группа разработчиков, должна решать, какие возможности нужно реализовать для достижения тех или иных бизнес-целей. Если требуемый анализ базируется на детальных данных, использование только таблиц агрегатов нецелесообразно, несмотря на техническую возможность их построения. Таким образом, разработчики и пользователи должны сотрудничать при определении целей и наиболее оптимальных средств их достижения. Чем больше вы работаете над формированием наборов данных для запросов, тем более гибкой становится среда для удовлетворения будущих нужд компании.Автор: Роб Армстронг (Rob Armstrong)