Вход



Поиск по сайту
Google на mf.grsu.by

  
Главная страница >> Учебный процесс >> Букинист >> OLAP >> Средства аналитической обработки >> Аналитические службы в концепции Windows DNA

Аналитические службы в концепции Windows DNA


Алексей Шуленин, Microsoft

Реферат доклада

Введение

В прошлом году на конференции "Корпоративные информационные системы" в докладе "Технологии Microsoft в области анализа данных" (см.http://citforum.ru/seminars/cis99/ms.shtml) были рассмотрены основные компоненты и принципы работы OLAP-служб в составе Microsoft SQL Server. Опираясь на этот материал, мы постараемся дать краткий обзор развития идей, лежащих в основе Microsoft DataWarehousing Framework и ее интеграции в технологию Windows DNA.

Напомню, что в аналитические службы для SQL Server входит OLAP-сервер, клиент PivotTable Service и открытые интерфейсы доступа к многомерным данным OLE DB для OLAP и ADO MD. OLAP-сервер является главным элементом данной архитектуры. Задачи его администрирования могут выполняться как через графический интерфейс утилиты OLAP Manager, так и программным путем с помощью административных ActiveX-объектов DSO (Decision Support Objects). OLAP-сервер может работать с данными из реляционных баз SQL Server, а также Oracle и других внешних источников, к которым можно получить доступ по ODBC или OLE DB. В наполнении хранилищ важную роль играют службы преобразования данных DTS, которые входят в состав SQL Server и которые были очень подробно рассмотрены в одноименном докладе на прошлогодней конференции "Корпоративные базы данных". Хранилища данных под управлением OLAP-сервера могут располагаться в самой реляционной базе (ROLAP), в собственной многомерной структуре OLAP-сервера (MOLAP), либо вычисленные агрегаты можно хранить в кубе OLAP-сервера, а детальные данные - в реляционной базе по месту их исходного нахождения (HOLAP). С точки зрения клиента все эти кубы выглядят одинаково.

OLAP-службы обладают кооперативным клиент-серверным кэшем. Кэш на стороне клиента обеспечивает компонент PivotTable Service. Клиентский кэш предназначен для уменьшения нагрузки на сервер и минимизации сетевого трафика. Так, например, если сначала запрашиваются данные за январь, февраль, март текущего года, а затем - за 1 квартал этого года в сравнении с аналогичным периодом предыдущего, то на сервер уйдет запрос только по данным за 1-й квартал предыдущего года.

OLAP-сервер имеет встроенные архитектурные решения, позволяющие эффективно бороться с такими характерными для хранилищ проблемами, как пустоты и взрывной рост данных. Используя известную аналогию с правилом "20:80", можно сказать, что 20% агрегатов дают 80%-выигрыш в производительности. Aggregation Wizard при проектировании структуры хранилища на основе эмпирического алгоритма определяет только действительно необходимые агрегаты, т.е. те, от которых за минимальное число операций можно вычислить остальные. Таким образом достигается оптимальный баланс между производительностью обработки аналитических запросов и местом, которое хранилище занимает на диске.

Существуют и другие решения. Так, Usage-Based Optimization Wizard позволяет дополнительно оптимизировать структуру агрегатов в зависимости от конкретной рабочей нагрузки за определенный период.

Простейшим клиентом для OLAP служит MS Excel 2000, чьи средства построения сводных таблиц и графиков прекрасно адаптированы для работы с хранилищами как на базе Microsoft OLAP, так и других производителей, поддерживающих интерфейсы OLE DB для OLAP. В состав MS Office 2000 входят Web-компоненты, позволяющие легко строить клиентские приложения для анализа данных. Наконец, клиентские приложения любого уровня сложности могут быть созданы с использованием любого высокоуровневого средства разработки, такого как Visual C++, Visual Basic, Visual InterDev и т.д. и открытых интерфейсов OLE DB для OLAP и ADO MD.

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

Усовершенствования в OLAP-службах Microsoft SQL Server 2000

Ниже будет приведен краткий перечень новой функциональности Microsoft OLAP Services for SQL Server 2000 из того, что было открыто объявлено на момент подготовки данного доклада.

  • Безопасность
    • OLAP-службы в составе SQL Server 7.0 поддерживали только интегрированную с Windows NT модель аутентификации. В новой версии к ней была добавлена аутентификация средствами Internet Information Server (IIS): NT Challenge / Response, анонимный доступ и поддержка Secured Socket Layer (SSL).
    • Расширена безопасность уровня ячеек, появившаяся в Service Pack 1 к SQL Server 7.0. Можно ограничить доступ той или иной роли к любому диапазону ячеек, который описывается операторами MDX (MultiDimensional eXtensions к SQL). Администратор может запретить роли запись в определенную область куба, ее чтение (так что она будет не видна для данной роли), либо производное чтение (ячейка, произведенная от других ячеек будет видна только в том случае, если роль имеет права на их чтение). Для управления ролевой безопасностью появился удобный графический интерфейс.
    • В SQL Server 2000 администратор может контролировать доступ не только к фактам, но и к измерениям. Для каждой роли можно оговорить доступные ей измерения, уровни этих измерений и конкретные члены измерения на каждом из уровней.
  • Архитектура
    • Добавлена поддержка прямой записи в измерение (write-enabled dimensions)
    • Поддержка измерений типа "родитель-потомок" (parent-child dimensions). Простейший пример - измерение "Сотрудники", где в одной колонке таблицы могут существовать члены разных уровней измерения, связанные друг с другом отношением подчиненности.
    • Поддержка ROLAP-измерений. Теперь в Dimension Editor в свойствах измерения можно выбирать тип его представления. По умолчанию он всегда равен MOLAP, что означает, что измерение хранится в многомерном кубе. Такой способ обеспечивает наиболее производительную обработку. Однако для измерений с числом членов порядка десятков миллионов и выше разумнее выбрать тип ROLAP и хранить его в реляционной таблице или таблицах, чтобы не раздувать объем куба. Эта возможность доступна только в корпоративной редакции SQL Server 2000.
    • Поддержка изменяющихся измерений (сhanging dimensions), т.е. таких, чья структура оптимизирована для частых изменений без необходимости полной обработки данного измерения или содержащего его куба. Для отражения изменений необходимо только дифференциальное обновление куба (incremental update), которое, в отличие от полной обработки, не требует отключения пользователей.
    • Поддержка зависимых измерений (dependent dimensions). Если существует измерение, чьи члены определяются членами другого измерения, то эту зависимость можно указать явно в свойствах зависимого измерения, так как это позволит ускорить расчет структуры агрегатов.
    • Поддержка неоднородных измерений (ragged dimensions), у которых количество дочерних уровней зависит от значения члена измерения. В случае примера с измерением "Сотрудники" это соответствует ситуации, когда сотрудники C и D подчиняются начальнику отдела B, который, в свою очередь, подчиняется руководителю предприятия А, в то же время сотрудник того же отдела Е подчиняется непосредственно А.
    • Улучшена поддержка виртуальных измерений (virtual dimensions), т.е. тех, чьи члены берутся из полей таблицы, относящихся к другому измерению, либо являются дополнительной информацией, относящейся к членам физического измерения (member properties). Виртуальные измерения являются логической сущностью и не увеличивают физический объем хранилища.
    • Сократить размер хранилища можно также с помощью фильтров на измерения, которые позволяют отбрасывать данные из реляционных таблиц, реально не участвующие в кубе. По сути, это предикат WHERE.
    • Поддержка пользовательских формул свертки (Custom Rollup). Формулы пишутся на MDX и перекрывают действие агрегатов по умолчанию. Например, если продажи за некоторый год составили по кварталам: 1кв. - 600, 2-й кв. - 200, 3-й кв. - 300 и 4-й кв. - 400, то, поставив на уровень года формулу агрегации вида Time.CurrentMember.LastChild, мы получим за этот год итоговую цифру не 1500, а 400.
    • Группировка членов измерения. Предположим, мы имеем измерение из двух уровней, верхний уровень имеет относительно небольшое число членов, а нижний - на несколько порядков его превосходящее. Для удобства анализа имеет смысл создать промежуточный уровень, разбив нижний уровень на группы и назначив каждой группе родителя на промежуточном уровне. Автоматически это можно сделать с использованием новой функциональности member groups. Кроме того, эту технологию можно применять, если количество "детей" у некоторого члена превосходит максимально допустимую величину в 64000.
  • Масштабируемость
    • Максимальное число измерений в кубе увеличено с 64 до 128
    • Максимальное число уровней в иерархии также теперь составляет 128
    • Поддержка прилинкованных кубов (linked cube). Куб может быть создан на одном сервере и затем определен как прилинкованный на другом. Пользователи другого сервера могут обращаться к данному кубу как к своему локальному несмотря на то, что физически он расположен в другом месте.
    • Удаленные части куба (remote partitions). Данные и определение такой части куба хранятся на разных серверах. Собрав определения всех частей на одном сервере, можно администрировать куб, несмотря на то, что физически данные хранятся на других серверах. Для пользователя работа с распределенным кубом происходит совершенно прозрачно, как если бы все данные и метаданные хранились в одном месте. Данная функциональность позволяет "размазать" куб по нескольким серверам и повысить производительность обработки запросов, так как каждый из серверов будет отрабатывать только ту часть, которая относится к хранящимся на нем данным. Хранение удаленных фрагментов куба, определенного на SQL Server 2000, на серверах SQL Server 7.0 не поддерживается.

Поиск закономерностей

7 марта 2000 г. Microsoft опубликовала пресс-релиз, в котором говорится о выпуске бета-версии OLE DB for Data Mining - спецификации открытых интерфейсов, базирующихся на языке SQL, которые позволят фирмам-производителям программных продуктов и независимым разработчиков более эффективно и просто интегрировать функциональность поиска закономерностей в профильные бизнес-приложения и приложения электронной торговли.

Спецификация OLE DB for Data Mining находилась на совместном тестировании ведущих поставщиков решений в области поиска закономерностей с мая 1999 г. Она включает в себя стандарты Predictive Model Markup Language (PMML), разработанные промышленным консорциумом Data Mining Group (http://www.dmg.org/) и основанные на языке XML.

О своей поддержке OLE DB for Data Mining уже объявили такие фирмы, как ANGOSS Software Corp., AppSource Corp., Comshare Inc., DB Miner Technology Inc., Knosys Inc., Magnify Inc., Megaputer Intelligence Inc., Maximal Innovative Intelligence Ltd., NCR Corp., PolyVista Inc., SPSS Inc. и другие, известные своими разработками продуктов Data Mining и Business Intelligence.

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

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

Итак, задачи поиска закономерностей актуальны для предприятий любого масштаба. Тем не менее до сегодняшнего момента их могли позволить себе только самые крупные из них, поскольку большинство существующих на рынке систем относится к разряду высшего ценового диапазона, требует усиленной аппаратной конфигурации и отличается сложностью в администрировании и использовании. Еще одним препятствием на пути широкого распространения систем поиска закономерностей являлось отсутствие открытых интерфейсов и слабая интеграция приложений такого рода друг с другом. Мы надеемся, что с выходом SQL Server 2000 все эти препятствия будут сняты.

При подготовке реферата использована документация Books On-Line в составе MS SQL Server 2000 Beta 2

 

  
За содержание страницы отвечает Гончарова М.Н.
©
Кафедра СПиКБ, 2002-2017