get Oracle SmartView plugin

Типы сжатия файла многомерных данных в EssBase

 

Настройка распределения дискового пристранства и сжатия данных

 

Essbase позволяет выбрать тип того , как будут сжиматься и хранится блоки данных на дисковом хранилище. При включенной опции компрессии, EssBase сжимает данные прежде чем их записать на диск, при чтении , он распаковывает блок данных, в выделенной области памяти (Data Cache), включая пустые ячейки . Обычно, опции компрессии оптимальны для использования, для определения насколько эффективно сжимается блок данных – нужно проверять параметр Compression Ratio.

 

Essbase поддерживает следующие типы сжатия данных:

  • Bitmap compression – по умолчанию. Essbase хранит только значимые ячейки с использованием схемы bitmap.
  • Run-length encoding (RLE) – Essbase сжимает повторяющиеся значения, включая нули и #MISSING.
  • Zlib. Essbase создает словарь данных. Эффективно только при большом коэффициенте плотности блока (более 5%) и для приложений, у которых данные обновляются централизованно.
  • Index Value Pair. Essbase сам выбирает данные тип компрессии ( он не доступен для настройки администратором)
  • No compression. Блоки хранятся как есть.

     

    Так как Essbase сжимает блоки данных перед тем как записать на диск есть несколько правил для bitmap, RLE и uncompressed блоков данных которых нужно знать, что бы эффективно настраивать систему хранения данных.

    • Когда сжатые данные попадают в Data cache, EssBase распаковывает блок до полного размера основываясь на алгоритме выбранной схемы хранения.
    • Когда EssBase сохраняет блок на диск, он Essbase он применяет к нему выбранные алгоритм работы по сжатию данных.
    • Если тип сжатия не был выбран, то блок записывается на диск как есть.
    • Единственным аргументом в пользу отказа от сжатия является очень большая плотность блока данных – более 90%.

     

    Bitmap Data Compression

     

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

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

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

     

    В этом примере системе требовалось бы 64 байта для сохранения этих данных в виде полностью развернутого блока, однако в действительности используется только один байт (восемь бит) для хранения битовой матрицы сжатых данных на диске. (Для каждого блока также используется заголовок из 72 байтов независимо от сжатия.)

     

    RLE Data Compression

    При использовании схемы сжатия на основании кодирования длин серий (RLE) система сжимает все значения, последовательно повторяющиеся три или более раз, в том числе нули. Система отслеживает каждое повторяющееся значение и количество последовательных повторений.

    В примере на рисунке системе требовалось бы 64 байта для хранения данных в полностью развернутом блоке, но в действительности для хранения сжатых данных на диске используется только 56 байт. (Система также использует 72-байтовый заголовок для каждого блока независимо от его сжатия.) Для того что бы эффективно использовать данный тип сжатия в матрице плотных направлений первым дожно идти то направление, которое содержит в себе наименьшее число хранимых элементов – например периоды.

     

    .

     

    zlib Compression

    Index Value Pair Compression

    – не рассматриваются ввиду крайне редкой области применения.

Определение среза данных

 

Идентификация значений в многомерной базе данных

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

У приведенной базы данных три аналитических направления: Счета (Accounts), Период (Time) и Сценарий (Scenario). У аналитического направления Счета четыре элемента: Продажи (Sales), Стоимость проданных товаров (COGS – Cost of Goods Sold), Маржа (Margin), Процент маржи (Margin%). Аналитическое направление Time состоит из четырех кварталов. В данном примере рассматривается только элементы первого квартала – Qtr1. У аналитического направления Scenario два дочерних элемента: Budget для плановых значений и Actual для фактических. На каждом пересечении аналитических направлений возникает один элемент базы данных. В нашем примере аналитических направлений три; их и значения их данных можно представить в виде куба, как на рисунке :

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

Фактические продажи (Actual Sales) в нашем примере представлены четырьмя значениями:

Каждое значение хранится в отдельной ячейке базы данных. Чтобы обозначить определенное значение в многомерной базе данных, нужно указать его элемент по каждому аналитическому направлению. На рисунке выделена ячейка, содержащая значение фактических продаж за январь (Sales,Jan,Actual). Это же значение может быть обозначено и как Sales,Actual,Jan или, с помощью оператора пересечения аналитических направлений (->): Sales->Actual->Jan.

Настройка протоколов аудита работы Essbase

 

Essbase предоставляет простую и мощную систему для контроля своей работы, которую можно масштабировать, в зависимости от предъявляемых требований к системе. Существует несколько уровней логирования от info до critical, определяемых параметрами AGENTLOGMESSAGELEVEL и LOGMESSAGELEVEL в конфигурационном файле essbase.cfg, располагающимся в каталоге %HYPERION_HOME%\AnalyticServices\bin.

 

В системе предусмотрено двухуровневое логирование : на уровне сервера и на уровне приложения.

1 Анализ логов

Происходит посредством «ручного» просмотра файла с логами работы системы. Обычно это требуется при возникновении «внешних» признаков неработоспособности системы

•    неприемлемо долгое время ответа системы на запрос получения данных

•    генерация *.xcp файлов

•    и прочие ошибки

На основе файла логов приложения можно , с помощью инструментария предоставляемого Administration Service Console, анализировать активность пользователей и загрузку сервера.

Подробности о количестве и составе файлов, в которых пишется деятельность сервера, и о протоколируемой информации в Analytic Server смотрите в документе

2 Настройки системы, влияющие на состав и уровень протоколируемой информации

 

2.1. Настройки протоколирование на уровне сервера

AGENTLOGMESSAGELEVEL – настройка файла essbase.cfg, которая определяет, что бы Analytic Server писал все сообщения (INFO), либо сообщения о предупреждениях (WARNING), либо только сообщения об ошибках (ERROR) в файл протоколирования Analytic Server.

PORTUSAGELOGINTERVAL – настройка файла essbase.cfg, которая определяет интервал для записи в лог количество свободных и занятых портов

2.2. Настройки протоколирование на уровне приложения

LOGMESSAGELEVEL (INFO,WORNING,ERROR) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал либо все сообщения, либо предупреждения, либо ошибки в файл логов приложения

TIMINGMESSAGES (TRUE | FALSE) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал длительность выполнения каждого пользовательского запроса на получения данных.

SSLUNKNOWN (TRUE | FALSE) настройка файла essbase.cfg, которая определяет что бы Analytic Server писал сообщения о ошибке включающие в себя запросы на получение значений с несуществующих элементов.

SET MSG настройка в файле скрипта, которая определяет как и что Analytic Server буде писать в лог приложения (Суммарную статистику по этому скрипту, расширенную стистику, настрйку уровней сообщений (без них, ошибки, предупреждения, все сообщения)

2.3. Настройка протоколирования пользовательских запросов

Для включения опции протоколирования пользовательских запросов, создайте файл dbname.cfg в директории базы данных используя следующей синтаксис:

•    Определение направления, обращения к которому будет протоколироваться QUERYLOG [dimension_name]

•    Глубина протоколирования по поколениям или по уровням: QUERYLOG GENERATION generation-range or QUERYLOG LEVEL level-range)

•    Исключение из протокола запросов: QUERYLOG NONE GENERATION generation-range or QUERYLOG NONE LEVEL level-range

•    Включать в протокол запросы к элементам нулевого уровня при HOLAP QUERYLOG LOGHAMBRS ON | OFF

•    Месторасположение файла логов QUERYLOG LOGPATH path-expression

•    Формат логов файлов QUERYLOG LOGFORMAT CLUSTER | TUPLE

•    Размер одного файла логов QUERYLOG LOGFILESIZE n

•    Общий размер всех файлов QUERYLOG TOTALLOGFILESIZE n

•    Включить или выключить логирование при следующем запуске базы QUERYLOG ON | OFF

 

Пример файла
# Log the Product dimension
QUERYLOG [Product]
# Log Hybrid Analysis members of Product, if applicable
QUERYLOG LOGHAMBRS ON
# Log the Market dimension
QUERYLOG [Market]
# Log members of generation 2 of Market by generation number
QUERYLOG GENERATION 2
# Display log output in cluster format
QUERYLOG LOGFORMAT CLUSTER
# Create log file in C:\QUERYLOG\
QUERYLOG LOGPATH C:\QUERYLOG\
# Start a new log file after an individual log file size reaches 2 MB
QUERYLOG LOGFILESIZE 2
# Turn off query logging after the total size of all log files reaches 1024 MB (1 GB)
QUERYLOG TOTALLOGFILESIZE 1024
# Enable query logging
QUERYLOG ON

2.4. Настройка протоколирование изменений структуры метаданных

OUTLINECHANGELOG (TRUE | FALSE) настройка файла essbase.cfg, которая имеет значение TRUE, для создания файла протоколов изменений

OUTLINECHANGELOGFILESIZE n настройка файла essbase.cfg, которая определяет максимальный размер файла протокола.

2.5. Настройка протоколирования создания направлений

DATAERRORLIMIN n настройка файла essbase.cfg, которая определяет максимальное количество записей в файле dataload.err

2.6. Очистка файла протоколов работы сервера

CLEARLOGFILE (TRUE | FALSE) настройка файла essbase.cfg, в значении TRUE очищает лог сервера или приложений в случае их перезапуска

Описание иерархий

Связи между направлениями и элементами.

Essbase использует иерархическую ( поколения(generations) и уровни(level); и корни (roots) и листья(leaves)) и «родительские» описание ( родители(parents), дети(children), братья(siblings); потомки(descendants) и прародители(ancestors)) для определения ролей и связей элементов в измерениях в описании метаданных МДБ.

 Member Generation and Level Numbers


Родители (parents), дети (children) и братья (siblings)

 

Потомки(descendants) и прародители(ancestors)

Узлы(roots) и листья (leaves )

Поколения (generations) и уровни (levels)

Элементы направлений и Измерения

В данном разделе объясняются понятия Outlin’a, измерений и направлений в многомерной базе данных (МБД).

Измерения(направления) – это самый верхний уровень в описании метаданных МБД. Описание метаданных (Outline) содержит в себе древовидную структуру с выделенными связями консолидации. Например, на картинке , элемент Year – это направление ( с типом Time) и Qtr1 это элемент.

Essbase имеет как стандартные так и атрибутивные направления.

Стандартные направления – это центральный компонент бизнес планирования , напрямую отображающее предметную функциональность реализованную в модели. Примеры стандартных измерений : Time, Accounts, Product Line, Market и Division. Измерения изменяются гораздо менее чаще, чем элементы, из которых они состоят.

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

Элементы направления – это независимые друг от друга сущности измерений. Например , Product A, Product B, and Product C могут быть элементами направления Product. Каждый элемент должен иметь уникальное имя (данное поведение определяется настройками МБД), и иметь множество псевдонимов (10?32?) определенных в алиасных таблицах. Essbase хранит данные элементы ассоциировано и сменем этого элемента, и это напрямую влияет на перестройку модели в случае массового переименования элементов. Так же данные могут быть рассчитаны динамически , на основании формулы, хранимой в свойствах элемента.