Сайзинг хранилищ данных

🕛 09.10.2008, 09:44

Сегодня большинство успешных предприятий проявляет серьезный интерес к средствам Business Intelligence (BI) и Хранилищам данных (ХД), так как они обеспечивают понимание бизнеса и позволяют поддерживать конкурентную позицию на рынке. Однако одна из самых ярких тенденций последних лет - невероятный темп роста объемов данных. Чтобы адаптироваться к этим объемам, необходимо грамотно строить крупные Хранилища, которые смогут успешно функционировать и обеспечивать постоянно растущую окупаемость вложений.

Для эффективной обработки больших объемов данных необходимо выйти за рамки простого хранения их в ХД, и поставить задачу определения оптимальной конфигурации аппаратно-программных средств - сайзинга (sizing).

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

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

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

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

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

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

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

Каждый проект сайзинга подразумевает некоторый уровень точности и диапазон допустимой ошибки в зависимости от сложности приложений. Эта задача требует расчета рисков и планирования непредвиденных затрат.

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

По мере повышения качества данных сайзинговые оценки становятся более точными.
Этапы сайзинга Хранилища данных

Чтобы грамотно оценить размеры системы и добиться оптимальной эффективности, необходимо выполнить ряд шагов:
1. понять возможности и границы эффективности системы; 2. оценить нагрузку и характеристики использования ресурсов; 3. установить бизнес-требования и ожидания в отношении системы; 4. провести сайзинг системы для оптимального применения ресурсов.

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

Три основных системных ресурса, которые зависят от нагрузки Хранилища - следующие:
* ресурсы запоминающего устройства/устройств; * ресурсы процессора (ЦП); * ресурсы системы ввода-вывода (I/O): o сеть; o диск: + последовательное сканирование; + случайное сканирование.

Существует два основных фактора, связанных с нагрузкой:
* физическое хранение информации в ХД; * обработка данных.

Требования к хранению и обработке влияют на все системные компоненты. Рассмотрим каждый фактор в отдельности.
Требования к объему запоминающих устройств (к дисковому пространству)

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

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

Если бюджет проекта ограничен, то приходится регулировать поступление тех или иных данных в Хранилище. Решения должны приниматься на основе их ценности для бизнеса. Далее нужно провести вычисление минимальных объемов. Затем можно проанализировать ситуацию и выяснить, что еще необходимо включить в Хранилище в зависимости от ресурсов проекта.

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

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

Среди компонентов, требующих пространства на запоминающем устройстве, нужно назвать следующие:
* данные таблиц; * данные индексов; * журналы СУБД (database logs); * временные базы данных; * пространство для этапа развертывания, необходимое для хранения необработанных данных.

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

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

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

Большинство проектов ХД требует некоторого дискового пространства для подготовки исходных данных - этапа развертывания. В зависимости от операционных процедур требования к пространству могут сильно различаться.

Описаные выше оценки - это минимальные требования к объему запоминающих устройств. Существует еще несколько факторов, которые влияют на конфигурацию Хранилища в целом. В том числе:
* количество дисков, необходимых для выполнения требований к производительности; * количество дисков, необходимых для балансировки эффективности ввода/вывода.

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

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

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

Отдельно взятая функциональная единица ХД - запрос - может быть распараллелена, чтобы максимально повысить потребление ресурсов и добиться ответа за кратчайшее время. Время на выполнение запроса в ХД-системе может колебаться в зависимости от ситуации, в том числе, от сочетания запросов, выполняемых в один и тот же момент времени.

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

Для систематизации и упрощения анализа проводится классифицирование запросов. Этот процесс начинается с четкого исследования схемы БД, характеристик данных и запросов. Цель состоит в следующем:
1. оценить размеры базы данных, доступной каждой из групп пользователей; 2. разбить запросы на категории, в зависимости от основных потребностей в ресурсах; 3. подобрать наиболее сложные запросы из каждой категории; 4. использовать эти запросы в качестве образца для расчета параметров сайзинга системы.

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

Запросы можно классифицировать по-разному, например:
* небольшие: для получения результата используется менее 15 % данных; * средние: в выполнение запроса вовлечено от 15 до 50% данных; * крупные: в запросе используется более 50% данных.

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

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

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

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

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

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

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

После сбора всех соответствующих данных о нагрузке, бизнес-требованиях и данных информацию можно объединить в единое руководство по сайзингу и конфигурированию Хранилища. А именно провести:
1. Сайзинг запоминающих устройств. 2. Сайзинг процессоров и памяти. Для этого требуется большой опыт и хорошее знание нагрузки. В частности, используется опыт тестирования различных запросов и знание относительной эффективности предыдущих систем по сравнению с целевыми системами. Помимо использования прошлого опыта, группы, занимающиеся сайзингом, должны выполнять ряд экспериментов и делать своего рода научные догадки. Для оценки вычислительных требований к сложным запросам можно взять упрощенную систему с одним процессором и некоторые фрагменты данных, дабы сделать приблизительную оценку производительности выполнения запросов. Затем нужно соотнести мощность процессора в тестовой и целевой системах и далее приблизительно вычислить эффективность обработки запроса в итоговом ХД. 3. Сайзинг сети. Различные базы данных имеют разную сетевую пропускную способность, даже при одинаковой нагрузке. Выполняя сайзинг сети для кластеризованного Хранилища, необходимо проконсультироваться с поставщиком СУБД и учесть его рекомендации.

Заключение

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

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

Публикации:
1. Введение в сайзинг систем для Хранилищ данных (An Introduction to System Sizing for Data Warehousing Workloads), Тони Петроссиан (Tony Petrossian), Эн Мэтцоу (Ann Matzou), Кваи Вонг (Kwai Wong). 2. Сайзинг BI-среды (Sizing a Business Intelligence Environment), Энэнд Бондре (Anand Bondre).