Оглавление
- Введение
- Что такое масштабируемость?
- Линейная масштабируемость
- Вертикальная и горизонтальная масштабируемость
- Высокая доступность и надежность
- Масштабируемость: резюме
- Эволюция многоуровневой архитектуры систем бизнес-аналитики
- Трехуровневые системы бизнес-аналитики
- Пятиуровневые системы бизнес-аналитики
- Современная система бизнес-аналитики
- Уровень Web
- Уровень сервера приложений
- Уровень репозитория и управления
- Уровень обработки бизнес-аналитики
- Уровень данных
- Резюме. Cистемы бизнес-аналитики с четырехуровневой архитектурой
- Контрольные тесты
- Заключение
Введение
По мере все большего увеличения объема данных бизнес-аналитики (BI - Business Intelligence), к которым может получать доступ через интранет или экстранет постоянно растущая аудитория, поставщики, производители и все те, чей интерес к этому сектору не является проходящим, основное внимание начинают уделять масштабируемости. В последнее время создается такое впечатление, что все поставщики решений для бизнес-аналитики заявляют о наилучшей масштабируемости их решения среди всех прочих.
Перенос на Web-платформы убрал определенные барьеры между потребителями и продуктами бизнес-аналитики, которые могут предоставлять данные большему количеству пользователей как внутри, так и за пределами компаний. Но простого переноса продукта на Web-платформу недостаточно. Предоставление данных бизнес-аналитики большему количеству пользователей требует создания системы, которая сможет справиться с потенциальным ростом количества пользователей.
Пока поставщики решений для бизнес-аналитики претендуют на масштабируемость и демонстрируют результаты тестов, которые это как будто подтверждают, конкретные стандарты, определяющие это понятие по отношению к системам бизнес-аналитики, отсутствуют. В результате поставщики определяют такие стандарты масштабируемости, которые наилучшим образом подходят к их конкретному продукту, и публикуют графики результатов контрольных тестов, которые удовлетворяют этим стандартам. В условиях отсутствия общих стандартов определения масштабируемости и публикаций поставщиками неубедительных результатов тестов, которые невозможно сравнить между собой, выбор системы бизнес-аналитики становится для потребителей достаточно сложной проблемой. Для легкого определения того, подходит ли система такого типа для их нужд, сейчас слишком много шума и слишком мало понимания того, что на самом деле она делает.
В данном документе представлен общий обзор масштабируемости в той мере, в какой он применим к системам бизнес-аналитики. В документе рассматривается эволюция многоуровневых систем предоставления данных бизнес-аналитики, назначение и функции каждого уровня современной системы и, наконец, исследуется, как необходимо масштабировать каждый уровень для соответствия требованиям потребителя. Хотя этот документ и не определяет конкретные меры по диагностической оценке, его следует использовать как основу, на которой можно разрабатывать подобные мероприятия.
Что такое масштабируемость?
До того, как проводить любое сравнение масштабируемости конкурирующих систем бизнес-аналитики, необходимо дать четкое определение самого этого понятия. Это может стать запутанным делом, поскольку о масштабируемости часто говорят в сочетании с высоким уровнем доступности и надежности. Истина же заключается в том, что хотя и надежность, и архитектура с высоким уровнем доступности являются факторами масштабируемости, одно их существование в дизайне системы масштабируемость не гарантирует. В данном документе подразумевается архитектура с высоким уровнем доступности и надежность системы бизнес-аналитики.
Примечание: масштабируемость - способность работать с дополнительными пользователями или транзакциями путем наращивания ресурсов без фундаментальной перестройки архитектуры или модели реализации.
Для того чтобы система бизнес-аналитики была масштабируемой, потребитель при росте нагрузки должен иметь возможность поддерживать неизменную производительность простым добавлением дополнительных ресурсов, например, серверов, процессоров или памяти. Главной целью является достижение линейной зависимости между объемом добавляемых ресурсов и итоговым увеличением производительности при поддержании постоянной скорости транзакций. Полностью линейно масштабируемая система бизнес-аналитики при удвоении аппаратного обеспечения должна иметь возможность обслуживать в два раза больше пользователей за то же количество времени. И наоборот, если аппаратное обеспечение имеет фиксированную мощность, а количество пользователей или, в особенности, количество транзакций увеличивается, то для обслуживания запросов должно потребоваться в два раза больше времени. Именно здесь становятся важными надежность и архитектура с высоким уровнем доступности. Система бизнес-аналитики не должна прекращать работать при росте нагрузки в виде пользователей, ее работа должна просто плавно замедляться.
Линейная масштабируемость
"В реальной жизни линейная масштабируемость важна и разработчиками не контролируется" (Методы оценки производительности базы данных Oracle9i - версия 1 (9.0.1)). Лишние непроизводительные затраты на управление ресурсами и обмен данными между службами уменьшает возможность линейного масштабирования приложения по отношению к ограничивающим ресурсам. На приведенном ниже графике можно увидеть отличие линейной и нелинейной системы. Линейно масштабируемая система будет постоянно наращивать преимущества использования дополнительного аппаратного обеспечения, а нелинейно масштабируемая система в некоторый момент уже не сможет его использовать. Можно ожидать, что для нелинейно масштабируемой системы дополнительное аппаратное обеспечение на самом деле даже ухудшит общую производительность. Большинство потребителей предпочло бы кривую производительности, показывающую линейную масштабируемость, но поскольку это фактически невозможно, то разумному потребителю следует рассматривать только такие системы бизнес-аналитики, которые демонстрируют как можно более близкое к 1:1 отношение производительности к объему дополнительного программного обеспечения.
Вертикальная и горизонтальная масштабируемость
Есть два метода масштабирования, используемых системами бизнес-аналитики: вертикальное и горизонтальное.
Примечание: вертикальное масштабирование (часто называемое scaling up) представляет собой способность системы бизнес-аналитики увеличивать производительность, используя дополнительное аппаратное обеспечение на одном сервере.
Поскольку существуют физические ограничения на объем памяти, используемой одним процессом, а операционные системы не допускают линейную масштабируемость управления потоками в пределах одного процесса, то все компоненты системы бизнес-аналитики должны иметь возможность работать параллельно на одной физической машине. Если вертикальная масштабируемость невозможна, то система бизнес-аналитики может масштабироваться только горизонтально.
Примечание: горизонтальное масштабирование (часто называемое scaling out) представляет собой способность системы бизнес-аналитики увеличивать производительность, используя дополнительные серверы.
Процесс предоставления форматированных данных пользователям интенсивно использует ресурсы, так что в силу самой своей природы системы бизнес-аналитики в основном требовательны к аппаратному обеспечению. Также компьютерные системы имеют физические ограничения на объем аппаратных ресурсов, которые на них могут быть установлены. Из-за этого все масштабируемые системы бизнес-аналитики должны иметь возможность горизонтального масштабирования, поскольку системы только с горизонтальным масштабированием, в конце концов, используют всю память и процессор, которые физически и/или экономически могут быть установлены на одной машине.
При использовании как горизонтального, так и вертикального масштабирования, важно, чтобы система бизнес-аналитики демонстрировала строго линейный тренд своей производительности.
Высокая доступность и надежность
Как уже было ранее замечено, надежность и высокий уровень доступности прямо не влияют на масштабируемость, но эти три понятия часто объединяют вместе. Основной причиной такого объединения служит то, что многие используемые методы как горизонтального, так и вертикального масштабирования систем те же, что и для надежности или высокого уровня доступности. Приложения с высоким коэффициентом доступности должны продолжать работать, несмотря на сбой в любом компоненте.
Примечание: для того, чтобы предоставить заказчику наибольшую гибкость, следует обеспечить возможность реализации высокого уровня доступности, независимо от использования методик вертикального или горизонтального масштабирования.
Наиболее широко используемым системами методом поддержки высокого уровня доступности вне зависимости от реализованного метода масштабирования является резервирование аппаратного обеспечения. При объединении масштабируемости и высокого уровня доступности путем резервирования сервера стоимость аппаратного обеспечения сохраняется минимальной, а надежность и производительность оптимальны.
Масштабируемость: резюме
Коротко говоря, из-за растущей тенденции развертывания систем бизнес-аналитики через Web становится все более важным развертывание систем бизнес-аналитики таким образом, чтобы с ростом пользовательской нагрузки дополнительные аппаратные ресурсы поддерживали производительность на прежнем уровне, не вызывая необходимости повторного развертывания или перестроения архитектуры.
Примечание: для того, чтобы быть масштабируемой, система бизнес-аналитики должна иметь возможность полностью использовать дополнительное аппаратное обеспечение, добавляется ли оно на одну машину или в виде дополнительного сервера к развернутой системе.
При использовании этого дополнительного аппаратного обеспечения система бизнес-аналитики должна масштабироваться с отношением производительности к объему дополнительного программного обеспечения, как можно более близким к 1:1. Наконец, система бизнес-аналитики должна иметь возможность развертывания для обеспечения отказоустойчивости или высокого уровня доступности, идеально используя преимущества любого резервированного оборудования.
Эволюция многоуровневой архитектуры систем бизнес-аналитики
Трехуровневые системы бизнес-аналитики
Основной движущей силой эволюции систем бизнес-аналитики за последние десять лет были общие проблемы внедрения средств бизнес-аналитики. Зародившиеся изначально как однопользовательские системы или системы, рассчитанные на настольные компьютеры, эти средства позволяли пользователям получать оперативную отчетность и выполнять анализ данных. Необходимость распространения, вместе с постоянно растущим объемом исходных данных, заставили поставщиков начать применять для своих решений серверный уровень. Введение этого промежуточного звена между пользователем и данными дало дальнейший простор для развития. Разработка графика генерации автономных отчетов была одним из таких усовершенствований, освободившим пользователей, которые смогли более продуктивно использовать то время, пока ожидалось получение их отчетов. Дальнейшие изменения, вызвавшие появление наборов средств бизнес-аналитики, по-прежнему основаны на клиент-серверной архитектуре, обладающей большими специальными возможностями, такими как создание документов и анализ методами OLAP (аналитическая обработка в реальном времени).
Трехуровневая архитектура системы бизнес-аналитики
С появлением Web-технологий и их широкого использования в организациях, обладающих возможностями работы с Web, наборы средств бизнес-аналитики стали обеспечивать возможность использования и взаимодействия с данными бизнес-аналитики через Web-клиентов (изначально управляющие элементы ActiveX или Java-апплеты). В последнее время эти системы развились до предоставления данных пользователям через Web-интерфейсы нулевых или тонких клиентов, а некоторые из них даже обеспечивают создание новых данных через Web, при этом все более используются интерфейсы нулевых клиентов. Это происходит благодаря возможности развертывания тонких или нулевых клиентов и создания такого информационного содержания бизнес-аналитики, которое должно было изменить саму фундаментальную архитектуру систем бизнес-аналитики.
Пятиуровневые системы бизнес-аналитики
Системы бизнес-аналитики достигли предоставления большей интерактивности и больших возможностей создания данных средствами нулевого и тонкого клиента. Идеальная архитектура для систем бизнес-аналитики из трехуровневой стала пятиуровневой. Эти многоуровневые системы были разработаны для решения двух проблем: предоставить необходимую гибкость, в соответствии с требованиями безопасности и построения инфраструктуры для развертывания через Web, и обеспечить методику масштабирования в соответствии с требованиями предоставления данных бизнес-аналитики через World Wide Web.
Система бизнес-аналитики с пятиуровневой архитектурой
Большинство систем бизнес-аналитики имеют четыре следующих основных уровня:
- Уровень Web - обеспечивает некоторый уровень интеграции с коммерчески доступными Web-серверами.
- Уровень приложений - реализуется одним из двух способов. Одни поставщики систем бизнес-аналитики предоставляют COM-объекты или java-классы, которые можно размещать на серверах приложений сторонних фирм (например, серверах J2EE или .Net framework от Microsoft), а другие разработали свои собственные сервера приложений, которые позволяют взаимодействовать с их серверным уровнем.
- Уровень репозитория и управления - большинство систем бизнес-аналитики в той или иной форме располагают уровнем репозитория и управления, который отвечает за управление документами бизнес-аналитики, включая уровни безопасности, службы планирования и управление вводом-выводом. Часто этот уровень также управляет и координирует деятельность других уровней системы.
- Уровень обработки - отвечает за управлением ядром системы, которое формирует данные бизнес-аналитики. Некоторые системы для дробления или преобразования документов в подходящие для программ Web-просмотра тонких и нулевых клиентов форматы (например, DHTML, XML) обладают на этом уровне некоторой логикой. Также этот уровень обычно обеспечивает работу служб экспорта в форматы сторонних фирм, такие как Microsoft Word и Excel или переносимый формат документа Adobe Acrobat (PDF).
- Уровень данных - это лежащая в основе системы база данных. Данный уровень отвечает за реально выполняемые запросы и возврат необработанных наборов результирующих данных уровню обработки. Поскольку от систем бизнес-аналитики требуется в основном получение данных по требованию или в режиме реального времени, скорость и время реагирования уровня данных становится для общей масштабируемости важным фактором.
Современная система бизнес-аналитики
Хотя конкретные реализации систем бизнес-аналитики могут отличаться друг от друга, большинство этих систем соответствуют этой четырехуровневой архитектуре. Даже если они обладают большим количеством уровней, истина заключается в том, что каждый из этих уровней должен масштабироваться по самой своей природе. Система бизнес-аналитики способна масштабироваться ровно настолько, насколько это способен делать ее наименее масштабируемый компонент.
Для того, чтобы понять трудности масштабирования каждого уровня, важно подробно рассмотреть различные функции, которые выполняет каждый уровень.
Уровень Web
Системы бизнес-аналитики весьма интенсивно используют ресурсы, поскольку они предоставляют конечным пользователям интерактивные, персонифицированные и часто уникальные данные. Создание и предоставление интерактивного содержания Web-страниц требует более интенсивного использования аппаратных ресурсов, чем статичный материал, и часто для обеспечения приемлемого быстродействия при взаимодействии пользователя с данными требуется поддерживать информацию о состоянии. Из-за требовательности к ресурсам и необходимости управления информацией состояния, большинство поставщиков систем бизнес-аналитики разработали дополнительные модули к Web-серверам или расширения, которые осуществляют перенаправление запросов к данным на серверный уровень приложений.
Некоторые из таких модулей работают как proxy-клиенты для пользователей Web, хотя такой подход и уменьшает масштабируемость уровня Web. Это происходит из-за того, что на Web-сервере необходимо производить достаточно сложную обработку данных. Также требования к управлению состоянием означают, что невозможно свободно производить балансировку нагрузки Web-серверов. В итоге при работе приложения бизнес-аналитики рассматриваются результирующие ресурсы Web-сервера, а не просто обслуживание Web-страниц. Это не только влияет на производительность и масштабируемость системы бизнес-аналитики, но и негативно отражается на всех других приложениях, которые используют Web-сервер для доступа или развертывания.
Для поддержания масштабируемости уровня Web, система бизнес-аналитики должна:
- прекрасно поддерживать группы Web-серверов с балансировкой нагрузки
- позволять перенаправлять последовательные запросы на любой Web-сервер, то есть не зависеть от состояния Web-серверов
- выполнять на Web-сервере как можно меньше обработки данных
Если система бизнес-аналитики не оказывает значительной нагрузки на Web-сервер и позволяет организовывать объединение Web-серверов в кластеры и балансировку нагрузки между ними, то уровень Web будет способствовать линейному масштабированию системы бизнес-аналитики.
Примечание: Хорошим тестом масштабирования уровня Web системы бизнес-аналитики может стать сравнение количества обрабатываемых Web-сервером транзакций в минуту до и после внедрения уровня Web.
Уровень сервера приложений
Большинство систем бизнес-аналитики создали новые интерфейсы пользователя. Обычно они обеспечиваются уровнем приложений, который, как уже обсуждалось в предыдущем разделе, можно включить в уровень Web в качестве дополнительного модуля. Поскольку системы бизнес-аналитики все больше развертываются через Экстранет, то растет необходимость настройки пользовательского интерфейса для его соответствия стандартам корпоративных Web-узлов. Для удовлетворения этой потребности поставщики систем бизнес-аналитики разработали свой собственный настраиваемый уровень приложений и использовали преимущества существующей технологии серверов приложений, предоставляя интерфейсы прикладного программирования API, Java-классы и объекты COM.
Независимо от того, разработал ли поставщик свой собственный уровень приложений или использовал сервера приложений сторонних фирм, уровень приложений должен иметь возможность вертикального и горизонтального масштабирования. Это означает, что уровень приложений должен иметь возможность параллельного запуска нескольких экземпляров на одной или нескольких машинах.
Другим фактором масштабируемости в пределах уровня приложений является эффективность его интерфейсов. Системы бизнес-аналитики предоставляют репозиторий и службы управления объектами, и эти репозитории могут вырасти до довольно большого размера. Для масштабирования клиентский и программный интерфейсы должны предлагать возможность поддерживать объем обслуживаемой информации, относящейся к объекту или группе объектов, на минимуме. Это обеспечивает эффективное использование памяти расположенными на уровне приложений интерфейсами и объектами и оптимальную производительность. Это обеспечивает также перемещение минимального количества данных уровнем приложений и уровнем репозитория.
Последний фактор масштабируемости на данном уровне - это возможность управления состоянием. Часто системы бизнес-аналитики требуют где-то внутри себя поддержания некоторой информации о состоянии. Сохранение состояния обычно увеличивает производительность небольших систем. Однако, на зависящую в некоторых случаях от архитектуры и реализации конкретной системы бизнес-аналитики производительность может негативно повлиять дополнительная нагрузка, вызванная поддержанием состояния большого количества одновременно работающих пользователей. Масштабируемая система бизнес-аналитики должна позволять выбирать между полным и частичным сохранением состояния, либо допускать работу уровня приложений без сохранения состояния.
Для обеспечения линейной масштабируемости уровень приложений должен:
- позволять распределять процессы между несколькими процессорами и машинами;
- работать с оптимальным объемом информации об объектах и эффективными интерфейсами;
- быть гибким с точки зрения сохранения состояния и приспосабливаться к различным платформам и реализациям.
Коротко говоря, для обеспечения общей масштабируемости уровень приложений должен масштабироваться как вертикально, так и горизонтально, и иметь возможность распараллеливания на одной либо нескольких машинах.
Примечание: хорошими мерами масштабируемости уровня приложений являются количество транзакций в секунду и количество килобайт в секунду.
Обеспечение линейного увеличения этих величин при горизонтальном и вертикальном масштабировании системы положительно скажется на линейности масштабирования системы бизнес-аналитики в целом. К тому же пользовательский и программный интерфейсы должны позволять эффективно использовать ресурсы серверов приложений при появлении новых пользователей.
Уровень репозитория и управления
Уровень репозитория и управления является главной частью системы. Обычно этот уровень предоставляет следующие возможности:
- хранение и управление документами бизнес-аналитики;
- составление плана обновлений данных для документов бизнес-аналитики;
- обеспечение безопасности пользователей и документов бизнес-аналитики;
- управление другими службами (серверами) в системе.
Репозиторий должен поддерживать быстрый доступ к пользовательской информации и информации об объектах, чтобы предоставлять ее конечным пользователям. Большинство серверов хранилищ загружает часть репозитория в память, но для больших объемов данных требуется быстрый доступ и к устройствам постоянного хранения. Есть несколько различных стратегий хранения данных. В них входят хранение информации репозитория в реляционной базе данных, хранение ее в собственном репозитории с памятью на дисках и комбинация этих двух способов. Основной фактор масштабируемости, который необходимо рассматривать, - это производительность репозитория при увеличении его размера. Падение производительности здесь в конечном итоге скажется на времени реакции системы и ее масштабируемости.
Как уже было замечено ранее, репозитории систем бизнес-аналитики могут стать довольно большими. Могут иметь место случаи, когда из-за проблем с безопасностью на уровне данных большое количество пользователей может затребовать каждый свою версию документов бизнес-аналитики. Со временем, по мере добавления пользователей и документов, репозиторий будет постоянно расти и станет испытывать те же проблемы с производительностью, что и реляционные базы данных, таблицы которых становятся очень большими.
Одно из решений проблемы увеличения размера репозитория - это его разбиение на меньшие подмножества информации. Это довольно хорошо срабатывает для рабочих групп, пользователи в которых нуждаются в доступе только к ограниченному набору документов, или заинтересованы только в какой-то отдельной области данных. Этот тип решения помогает обеспечить масштабируемость только в том случае, если заранее была проделана большая работа по планированию разбиения репозитория. Также это создает проблемы, если конечный пользователь нуждается в доступе к документам, хранящимся в разных репозиториях. Этот подход хорош для улучшения масштабируемости, но он не может служить заменой возможности линейного масштабирования единой системы, поскольку плохое планирование на начальном этапе проектирования системы может потребовать повторного развертывания всей системы.
Большинство поставщиков систем бизнес-аналитики решили эту проблему теми же способами, что и поставщики баз данных, а именно через параллельную обработку данных. Параллельная обработка означает управление несколькими ядрами репозитория одной физической базой данных. Каждое ядро обслуживает какое-то подмножество всего сообщества пользователей. Репозиторий должен иметь возможность параллельной работы вне зависимости от вертикального или горизонтального масштабирования системы. Это поможет обеспечить линейность общего масштабирования системы. Важно, чтобы поставщики систем бизнес-аналитики демонстрировали линейную масштабируемость по всем функциям этого уровня. Сюда входит:
- регистрация пользователей в системе;
- перемещение пользователей по репозиторию;
- автоматическое и определяемое пользователем упорядочивание документов;
- просмотр документов пользователями.
Каждый из этих пунктов имеет непосредственное влияние на удобство работы пользователей. Исследования показывают, что пользователи Web не будут ждать информацию, если ее появление занимает больше 10 секунд. Линейная масштабируемость этих функций при увеличении количества пользователей и объема данных очень важна для успеха системы. Репозиторию необходимо хорошо справляться с большим количеством пользователей, хранимых в нем документов и упорядоченных объектов. Система должна предоставлять механизмы для репозиториев, которые серверы будут запускать параллельно при масштабировании как на одной машине, так и на нескольких.
Для содействия общей масштабируемости системы репозиторий и уровень управления должны:
- иметь возможность предоставления непрерывного быстрого доступа к пользовательской информации и информации об объектах, независимо от других нагрузок
- иметь возможность эффективно справляться с ростом объема репозитория
Уровень обработки бизнес-аналитики
Уровень обработки содержит ядро системы бизнес-аналитики. Все другие уровни окружают уровень обработки, который генерирует и обрабатывает документы бизнес-аналитики, обеспечивает интеграцию с данными бизнес-аналитики и преобразует эти данные в другие форматы. Подобно всем прочим компонентам системы бизнес-аналитики, данный уровень должен линейно масштабироваться как при вертикальном, так и при горизонтальном масштабировании системы. Однако реальные достоинства систем бизнес-аналитики лежат в пределах этого уровня, и есть возможности, которые требуются для масштабирования этих систем.
Раздел/страница по требованию
Документы бизнес-аналитики могут быть большими. В результате большинство систем бизнес-аналитики пытается достичь более удобного для конечного пользователя варианта работы путем предоставления данных меньшими порциями и использования таких функций, как страница по требованию (page on demand), навигация по документу и переход к более подробному представлению данных по определенному критерию (drill down). Эти типы возможностей не только увеличивают производительность с точки зрения конечного пользователя, но и обеспечивают некоторую интерактивность, которая делает документы бизнес-аналитики более ценными, нежели документы в других статичных форматах. Для обеспечения масштабирования система бизнес-аналитики должна иметь возможность разбиения документа на меньшие разделы, которые быстрее обслуживаются при работе через Web. Кроме того, эти методы уменьшают сетевой трафик, предоставляя пользователям приемлемую производительность даже через линии связи с небольшой пропускной способностью.
Кэширование
В некоторых случаях идентичные документы бизнес-аналитики просматривают несколько пользователей. Если это происходит, система бизнес-аналитики может лучше масштабироваться с помощью кэширования данных бизнес-аналитики и использования этого кэша для обслуживания запросов вместо повторной генерации одинаковых страниц или всего документа. Возможность кэширования просматриваемых одновременно документов бизнес-аналитики увеличит масштабируемость уровня обработки.
Фильтры на период просмотра
В ситуациях, когда из-за безопасности на уровне данных пользователям требуются их собственные отдельные версии документов, системы бизнес-аналитики применяют разработанные решения для организации фильтров на период просмотра документов. Эти решения позволяют конкретным пользователям просматривать только определенные разделы документов. Обычно это делается на уровне страницы или строки с помощью фильтрации на уровне данных или страницы. Это может уменьшить количество объектов, которые репозиторий должен хранить, но требует на данном уровне большей обработки данных. На практике документы бизнес-аналитики и ядро репозитория не столь эффективно фильтруют данные, как это делают реляционные базы данных, и подобные этим решения обычно эффективны только для небольших или средних по объему данных документов.
Обработка документов по требованию
Некоторые документы бизнес-аналитики не нуждаются в постоянном хранении в репозитории. Это небольшие параметрически управляемые документы, которые создаются "на лету" и существуют только тот период времени, в течение которого пользователь их просматривает. Возможность генерации таких документов бизнес-аналитики облегчает работу системы по управлению большим количеством документов, которые просматриваются лишь однажды. При выполнении оперативной обработки данных важно, чтобы база данных была оптимизирована с точки зрения быстрого возврата данных на уровень обработки, а ядро системы бизнес-аналитики имело бы возможность быстрой генерации документов для их представления конечному пользователю. Технология обработки по требованию должна быть оптимизирована не только для быстрого предоставления документов, но также для генерации страниц или разделов документов на основании самой последней информации, так чтобы пользователю не нужно было ждать окончания генерации всего документа для начала его просмотра и работы с ним.
Многопоточные сервера обработки данных
Система бизнес-аналитики должна эффективно использовать ресурсы. Процесс генерации документов с высокой степенью форматирования на основе большого объема данных обычно очень ресурсоёмкие. Чтобы отвечать требованиям конечных пользователей к производительности, ядро системы бизнес-аналитики использует при получении документов значительные ресурсы. Однако для масштабирования система бизнес-аналитики должна иметь возможность одновременной генерации нескольких документов на каждом процессоре. Реальной мерой эффективности уровня обработки является количество документов, которое он может генерировать одновременно на каждом процессоре. Более масштабируемое ядро системы бизнес-аналитики может работать в многопоточном режиме, при котором один экземпляр ядра (один процесс) обслуживает несколько документов. При работе в многопоточном режиме уровень обработки использует системные ресурсы более эффективно, при этом поддерживая на том же уровне, а иногда даже выше, производительность по сравнению с подобным ядром, не использующим многопоточный режим. Компания Oracle применила эту модель в своей архитектуре, когда она представила на рынок многопоточный сервер в Oracle 8i, поскольку "многопоточный сервер допускает большую масштабируемость, а при заданном объеме памяти он позволяет обслуживать большее количество пользователей, чем при использовании выделенных серверов" 2 (Концепции параллельного сервера Oracle 8. Версия 2(8.1.6)). При наличии возможности работы в многопоточном режиме ядро системы бизнес-аналитики с наибольшей масштабируемостью также будет способно поддерживать большее количество пользователей при меньшем аппаратном обеспечении.
Большие объемы данных
Некоторые поставщики систем бизнес-аналитики могут возразить, что пользователи не могут использовать большие документы бизнес-аналитики, а ценность системы заключается в ее возможности быстрого доступа и представления данных, а также выполнения вычислений. Хотя это может быть и верным предположением, однако человеческая натура такова, что конечные пользователи по-прежнему хотят иметь документы, полные детальной справочной информации, что неизбежно влечет за собой наличие больших документов со значительным объемом данных. В результате ядро системы бизнес-аналитики должно иметь возможность генерации таких больших документов по запросу пользователей. Необходимость в больших документах, наполненных данными, придает большее значение методам, используемым для эффективного перемещения по таким документам. Для таких случаев поставщики выбрали много разных методов, каждый из которых наилучшим образом подходит к возможностям их конкретного ядра. Но в основном все эти методы позволяют пользователям затребовать страницы по мере надобности или перемещаться по документу и подробнее рассматривать некоторые его области, не загружая документ полностью. Чтобы быть масштабируемым, ядро системы бизнес-аналитики должно выполнять эти действия быстро и эффективно. Возможность управлять большим количеством данных важна для ядра, но должна измеряться в одном контексте с производительностью.
Резюме: уровень обработки данных
Масштабируемость этого уровня системы бизнес-аналитики зависит от возможности быстрой и эффективной работы с любыми объемами данных. Он должен обеспечивать:
- Методы или средства, позволяющие пользователю быстро выбирать и взаимодействовать с теми страницами или разделами отчета, которые интересуют пользователя, без пересылки ненужных данных.
- Метод кэширования данных и уменьшения ненужных обращений к базе данных.
- Динамические фильтры периода просмотра, помогающие в целях безопасности избежать дублирование документов.
- Возможность обработки или вызова, которая допускает работу ядра в одном или нескольких экземплярах для осуществления одновременного доступа к нескольким документам бизнес-аналитики.
- Генерацию документов по требованию и пакетную генерацию, что обеспечивает работу с различными объемами данных.
Уровень данных
Уровень данных является важным элементом в общей масштабируемости системы бизнес-аналитики, поскольку неправильное использование конфигурации этого уровня может значительно на нее повлиять. Данный уровень должен обеспечивать достаточно малое время реакции, чтобы управлять запросами к небольшим объемам данных, предоставляемых по требованию, и при этом достаточно мощным, чтобы также время от времени выполнять большие запросы к данным.
Хорошо спроектированная система бизнес-аналитики должна делать все возможное, чтобы оградить уровень данных от всех запросов, кроме наиболее важных, а также должна по мере возможности минимизировать сложность и объем запросов. Это позволяет базе данных быстро выдавать данные и обслуживать транзакционные запросы от других приложений. На практике это означает запрашивание только достаточного для обслуживания определенного пользовательского запроса объема данных, кэширование информации на уровне репозитория для уменьшения повторяемости запросов и предоставление службы планирования для переноса выполнения сложных или длительно выполняющихся запросов на ночное время.
Для обеспечения эффективного масштабирования уровень данных должен:
- Обладать такой архитектурой, чтобы наиболее частые запросы выполнялись быстро.
- Управлять большим количеством одновременных подключений, не уменьшая время отклика на запросы.
Резюме. Cистемы бизнес-аналитики с четырехуровневой архитектурой
Четырехуровневая система бизнес-аналитики предоставила поставщикам гибкость и возможность предоставления данных через Web. Чтобы обеспечивать общее масштабирование, каждый уровень системы сам должен иметь возможность масштабирования линейного вида, независимо от других уровней, на основании нужд любой конкретной реализации. Для оценки наиболее важны уровни репозитория и бизнес-аналитики, и для достижения линейной масштабируемости эти уровни должны обладать возможностью параллельной обработки данных.
- Уровень Web должен поддерживать группы Web-серверов с балансировкой нагрузки, не зависеть от Web-состояния и выполнять на Web-сервере минимальный объем вычислений.
- Уровень приложений должен работать с оптимальной информацией об объектах и эффективными интерфейсами. Он должен позволять гибко управлять состоянием и отвечать различным требованиям реализации.
- Уровень репозитория и управления должен обеспечивать непрерывный и быстрый доступ к пользовательской и объектной информации независимо от других нагрузок, а также иметь возможность эффективно справляться с растущим объемом репозитория.
- Уровень обработки данных должен иметь простой метод навигации по документу, позволяющий выбирать его отдельные части и избегать пересылки ненужных данных пользователю, а также обеспечивать эффективное кэширование данных и механизмы фильтрации во время просмотра. Также он должен допускать параллельную обработку данных и доступ к нескольким документам.
Контрольные тесты
Поскольку все поставщики стремятся продемонстрировать, что их система бизнес-аналитики самая масштабируемая из всех, которые есть на рынке, они производят контрольные тесты, которые доказывают сильные стороны масштабируемости их систем. Для потребителя важно, чтобы эти тесты были ясными и воспроизводимыми, и чтобы они реально отражали ситуации из реальной жизни. Большинство документов бизнес-аналитики представляет собой нечто большее, чем просто форматированные списки данных. Документы бизнес-аналитики могут содержать различные объемы данных, а также итоговые сводки, вычисления, диаграммы и возможность получения более подробных данных по определенным критериям. Часто они имеют большое количество форматирующей информации и содержат очень сложные структуры сгруппированных данных и средства управления макетом документа. Это составляет большую часть ценности документа бизнес-аналитики. Любые контрольные тесты должны выполняться с полным диапазоном документов бизнес-аналитики: от маленького до большого, и от простого до сложного.
Необходимо выполнять контрольные тесты таким образом, чтобы определить приемлемый уровень производительности для всех основных типов транзакций в системе. Время ответа системы должно учитывать восприятие конечного пользователя и составлять от 10 до 15 секунд. Кроме того, тесты должны учитывать увеличение количества пользователей и мощностей аппаратного обеспечения системы, обеспечивая поддержание производительности в соответствии с определенными стандартами. Это должно отражать способность системы к линейному масштабированию. Также контрольные тесты следует выполнять на репозитории разумного размера. Это означает, что кроме пользователей в системе должно присутствовать достаточное количество шаблонов и архивных документов. Это обеспечит эффективное управление соответствующего уровня большими репозиториями. Прежде всего, эти контрольные тесты должны демонстрировать линейную масштабируемость всей системы по всем пользовательским функциям, включая регистрацию в системе, перемещение по репозиторию, просмотр документов бизнес-аналитики и навигацию по ним. Все эти действия должны производиться одновременно, как это и происходит в реальной жизни в большинстве случаев. Масштабируемость системы бизнес-аналитики подобна цепочке. Она крепка ровно настолько, насколько крепко ее самое слабое звено.
Заключение
В данном документе была определена масштабируемость как способность обслуживания дополнительных пользователей или транзакций путем добавления ресурсов, не меняя с принципиальной точки зрения архитектуру или проект реализации отдельной развернутой системы. Были исследованы вертикальная и горизонтальная масштабируемость и определена их необходимость для систем бизнес-аналитики, для достижения идеального масштабирования.
Были также исследованы эволюция систем бизнес-аналитики до существующей в настоящее время четырехуровневой архитектуры. Исследован каждый уровень в системе и определено, как каждый компонент должен масштабироваться сам по себе и как, с точки зрения архитектуры, система бизнес-аналитики должна проявлять возможность выполнять параллельную обработку данных на всех своих уровнях. Возможность выполнять параллельную обработку данных на каждом уровне вносит вклад в общую линейную масштабируемость системы бизнес-аналитики.
Были рассмотрены проблемы систем бизнес-аналитики, возможность значительного увеличения объема репозиториев и необходимость стратегии работы с такими большими репозиториями для поставщиков. Эти стратегии должны позволять системе линейно масштабироваться, не требуя для нее пересмотра архитектуры или повторного развертывания.
Также были рассмотрены функции масштабирования, разработанные поставщиками систем бизнес-аналитики для уровня обработки, которые предоставляют работающим через Web конечным пользователям возможность более удобной работы.
Наконец, была определена необходимость предоставления поставщиками систем бизнес-аналитики реалистичных контрольных тестов, которые демонстрируют линейную масштабируемость.
Главной мыслью данного документа является необходимость того, чтобы поставщик системы бизнес-аналитики демонстрировал линейную масштабируемость всей системы и предоставлял реалистичные результаты контрольных тестов. Если он этого сделать не может, то, скорее всего, потребитель будет вынужден повторно развертывать свою систему бизнес-аналитики или переделывать ее архитектуру, чтобы не отставать от связанных с ростом системы требований.