Business Intelligence средствами MS SQL Server 2008 R2 в компании, использующей системы учета 1С

В этой статье я бы хотел описать основные этапы построение системы аналитической отчетности средствами MS SQL Server 2008 R2 в организации, использующей OLTP системы учета на платформе . В статье описан мой первый опыт построения решений Business Intelligence.

image

Общие вводные данные


Компания, в которой я работаю, занимается оптовой торговлей и состоит приблизительно из 30 офисов, расположенных в регионах России. В каждом офисе существует информационная база данных 1С, в которой регистрируются данные о продажах. В организации используется два вида конфигураций баз данных 1С. Одна конфигурация используется в центральном офисе в Москве, вторая — в филиалах (в регионах России). В качестве СУБД, обеспечивающей работу систем 1С, используется Microsoft SQL Server 2008 R2 (SP2) Standard Edition (64-bit). Единая общая нормативно-справочная информация (НСИ) отсутствует. Справочник «Продукция» и некоторые другие справочники, являющиеся классификаторами продукции и контрагентов, синхронизируются по коду или другому идентификатору, которые хранятся в системах 1С. Одним из основных отчетов, используемых в организации, является отчет о продажах. Существующий отчет о продажах позволяет извлекать данные только из той системы, в которой он формируется. Сформированные отчеты выгружаются в MS Excel, где происходит их дальнейшая обработка. В связи с ростом компании и появлением новых офисов руководство поставило перед IT-подразделением задачу о разработке консолидированного отчета, позволяющего автоматически получать информацию о продажах в разрезе всех офисов организации.

Требования бизнеса


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

Отчет должен позволять накладывать фильтры на выборку по любому из аналитических разрезов. В качестве фильтра может быть задано произвольное количество значений. Отчет должен формироваться не дольше минуты. Формирование отчета не должно существенно влиять на производительность учетных систем 1С. Реализация и дальнейшее сопровождение отчета должны быть минимально затратными.

Предварительная оценка и выбор решения


На основании имеющихся вводных данных и требований заказчику было предложено следующее решение:
  • Разработать хранилище данных, включающее всю информацию, необходимую для формирования консолидированного отчета о продажах.
  • Развернуть хранилище данных на экземпляре SQL-севера SQL Server Database Engine в центральном офисе.
  • Разработать многомерную модель данных, содержащую меры и измерения, необходимые для формирования отчета о продажах.
  • Развернуть многомерную базу данных, содержащую многомерную модель, на экземпляре SQL-севера SSAS в центральном офисе.
  • Разработать ETL-пакеты SSIS, с помощью которых будет производиться обновление данных в хранилище данных и в многомерной базе данных.
  • Развернуть пакеты SSIS на экземпляре SQL-сервера SSIS в центральном офисе.
  • Обеспечить автоматическое выполнение пакетов SSIS с уведомлением по e-mail специалистов технической поддержки о статусе выполнения пакетов.
  • Обеспечить доступ сотрудникам компании к многомерной базе данных для формирования консолидированного отчета о продажах с помощью объекта PivotTable Report в MS Excel.
  • Выполнить обучение сотрудников, занимающихся формированием отчетов о продажах.

Реализация решения


Этап №1. Сбор информации об источниках данных в системах 1С. Создание представлений (View) для получения доступа к необходимым данным

Перед началом проектирования хранилища я создал представления (View) в базах данных SQL, обеспечивающих работу систем 1С. У меня получилось два набора представлений: набор для базы данных в центральном офисе (см. рис. 1) и набор для баз данных в филиалах (рис. 2). Напомню, что структура баз данных в филиалах организации одинаковая, но отличается от структуры базы данных в центральном офисе.

image
Рис. 1. Представления в SQL-базе данных центрального офиса

image
Рис. 2. Представления в SQL-базах данных филиалов

Состав представлений в центральном офисе и филиалах получился разный, так как часть НСИ является общей и хранится в полном объеме в базе данных в центральном офисе. В частности речь идет о представлениях:
  • dbo.ChainStores (Торговые сети клиентов).
  • dbo.Countries (Классификатор стран мира).
  • dbo.Products (Продукция).
  • dbo.ProductAnalogs (Аналоги продукции).
  • dbo.ProductTypes (Классификатор типов продукции).
  • dbo.Projects (Классификатор видов клиентов).
  • dbo.ProjectsForProductMatrix (Классификатор видов продукции).
  • dbo.CrossProductsAndProjectsForProductMatrix (представление для обеспечения связи типа «много-ко-многим» между представлениями dbo.Products и dbo.ProjectsForProductMatrix).

Создание представлений в SQL-базах данных позволяет сделать решение более универсальным. Например, при изменении структуры таблиц в базах данных 1С нам не придется вносить изменения в ETL-пакеты, достаточно будет переделать представления.

Этап №2. Разработка структуры хранилища данных. Развертывание хранилища данных

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

image
Рис. 3. Представление dbo.Clients

Обратите внимание, что в представлении dbo.Clients существует поле ParentId. С помощью этого поля в последствии мы сможем построить иерархию Parent-child в многомерной модели данных для измерения «Клиенты». Аналогичное поле присутствует в представлениях dbo.Products и dbo.Managers.

Прежде чем начать проектировать хранилище данных, необходимо определиться с его схемой. Существует две схемы хранилища данных — это звезда и снежинка. Обе схемы имеют свои плюсы и минусы, и их сравнение выходит за пределы данной статьи. Я выбрал схему снежинка, руководствуясь тем, что при переходе на SQL Server 2012 и использовании в будущем self-service BI пользователям, вероятно, будет удобнее оперировать более нормализованными данными из хранилища данных при разработке собственных моделей данных в PowerPivot for Excel. Структура разработанного мной хранилища данных изображена на следующем рисунке.

image
Рис. 4. Структура хранилища данных

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

Этап №3. Разработка многомерной модели данных. Развертывание многомерной базы данных

При создании многомерной модели данных было создано представление Data Source View, в которое были включены все таблицы из хранилища данных, кроме таблицы stage.FactSales. Эта таблица будет использоваться только для временного хранения данных о продажах перед загрузкой в таблицу фактов fact.FactSales.

В кубе Sales реализованы две группы мер (см. рис. 5).

image
Рис. 5. Меры

Группа мер Cross Products And Projects For Product Matrix обеспечивает связь много-ко-многим между измерениями Товары и Каналы сбыта для товарной матрицы.

Список измерений изображен на рисунке 6.

image
Рис. 6. Измерения

Для измерений Товары, Клиенты, Менеджеры реализована иерархия Parent-child.

image
Рис. 7. Измерение Товары

Для управления доступом к многомерной базе данных создана роль Analists, которой предоставлены права Read и Drillthrough для куба Sales. Права Drillthrough позволяют пользователям получать расшифровку с информацией о том, как были рассчитаны значения ячеек в отчете.

image
Рис. 8. Роль Analists

Чтобы развернуть многомерную базу данных на сервере, указываем в свойствах проекта имя экземпляра SQL-сервера SSAS, имя базы данных на сервере и в меню BIDS нажимаем Deploy. Подключаемся к экземпляру SSAS с помощью SMS и видим, что многомерная база данных была создана.

image
Рис. 9. Многомерная база данных Sales OLAP

Этап №4. Разработка ETL-пакетов. Развертывание ETL-пакетов. Настройка автоматического выполнения ETL-пакетов

Наиболее трудоемкий этап при проектировании решений Business Intelligence — это, разработка ETL-пакетов. Связано это с тем, что источники данных, как правило, имеют разную структуру, а данные, хранящиеся в них, содержат ошибки и имеют различный формат. Например, пол сотрудника в разных базах данных, может быть представлен буквами М и Ж или цифрами 0 и 1, и перед загрузкой этих данных в хранилище, необходимо выполнить их очистку и приведение к общему виду. Кроме того, в хранилище данных необходимо обновлять только те данные, которые были введены или изменены с момента последней загрузки. Это только основные сложности, на самом деле их гораздо больше. Однако благодаря инструментам SSIS большинство подобных проблем могут быть решены. В моей реализации данные в таблицах измерений обновляются полностью, т.е. новые записи добавляются, а существующие записи перезаписываются. Таблица фактов очищается и заполняется снова за период по умолчанию равный трем месяцам. Глубина обновления таблицы фактов в месяцах хранится в конфигурации SSIS пакетов, которая представляет из себя отдельную таблицу в хранилище данных.

image
Рис. 10. Пакеты SSIS

На рисунке 10 изображены 4 пакета SSIS, назначение которых следующее:
  • Update DW and Process Sales OLAP.dtsx — мастер-пакет, в котором реализована общая логика ETL-процесса и который запускает все остальные пакеты.
  • Import Dimensions and Facts from Moscow.dtsx — пакет для загрузки данных в таблицы измерений и фактов из базы данных центрального офиса в хранилище данных.
  • Import Dimensions and Facts from Filials.dtsx — пакет для загрузки данных в таблицы измерений и фактов из баз данных филиалов в хранилище данных.
  • Process Sales OLAP.dtsx — пакет, который выполняет обновление данных (процессинг) в многомерной базе данных.

Логика (Control Flow) мастер-пакета следующая (см. рис. 11).

image
Рис. 11. Пакет Update DW and Process Sales OLAP

Рассмотрим каждый элемент этой схемы:
  • Сначала выполняется Set Package's Variables Values (Execute SQL Task). Задача этого элемента — получить значения из конфигурации пакета и записать их в переменные пакета. В конфигурации пакета в том числе хранится информация о глубине обновления таблицы фактов в месяцах. Конфигурации пакета хранится в отдельной таблице в хранилище базы данных и может изменяться IT-специалистами.
  • Далее Insert Default Values In Dimensions (Execute SQL Task) выполняет проверку и заполнение хранилища данных пустыми элементами. Например, в таблице dim.DimProducts после выполнения этого задания должен появиться элемент с идентификатором (Id), равным нулю. Записи с нулевыми идентификаторами будут созданы во всех таблицах измерений для обеспечения логической целостности данных, так как все поля таблицы фактов определены как NOT NULL и имеют значение по умолчанию равное нулю. Наличие NULL-ов в таблице фактов приводит к ошибкам при процессинге многомерной базы данных.
  • Get List of Source OLTP Databases in Moscow (Execute SQL Task) получает список баз данных центрального офиса (в моем случае такая база данных одна, но для большей универсальности решения, я предположил, что их может быть несколько). Список баз данных хранится в таблице dim.DimOffices. Так же в этой таблице хранятся строки подключения к базам данных. Полученная выборка записывается в переменную пакета.
  • For All OLTP Databases in Moscow (Foreach Loop Container) выполняет обход выборки, полученной на предыдущем шаге, и для каждой строки выборки (т.е. для каждой базы данных) выполняет пакет Import Dimensions and Facts from Moscow.dtsx. Передача параметров из мастер-пакета вызываемому пакету происходит с помощью установки значений конфигурации пакета, которую выполняет задача Set Package Configurations (Execute SQL Task).
  • Следующие два шага Get List of Source OLTP Databases in Filials (Execute Package Task) и For All OLTP Databases in Filials (Foreach Loop Container) аналогичны двум предыдущим, только выполняются для баз данных филиалов.
  • Последний шаг Process Sales OLAP (Execute Package Task) запускает пакет обновления данных в многомерной базе данных.

Описанные выше пакеты развернуты на экземпляре SQL-сервера SSIS. Для автоматического запуска мастер-пакета на SQL-сервере создано задание Update DW and Process Sales OLAP (см. рис. 12).

image
Рис. 12. SQL Job для запуска пакета SSIS

Для контроля выполнения ETL-процесса в задании настроено уведомление специалистов службы поддержки по e-mail о завершении задания (см. рис. 13).

image
Рис. 13 Настройка уведомления о выполнении задания по e-mail

Этап №5. Предоставление доступа к многомерной база данных

Доступ к многомерной базе данных предоставлен сотрудникам организации с помощью включения их доменных учетных записей в роль Analists многомерной базы данных с помощью SMS (см. рис. 14).

image
Рис. 14. Членство в роли Analists

Этап №6. Обучение сотрудников организации

Для обучение пользователей был записан 15 минутный видео-ролик, в котором были продемонстрированы возможности MS Excel, позволяющие подключиться к многомерной базе данных и построить отчет с помощью объекта PivotTable Report. Один из возможных вариантов отчета изображен на рисунке 15.


Рис. 15. Пример отчета PivotTable Report в Excel

Выводы


Требования заказчика были реализованы в полной мере. Бета-тестирование выполнялось ключевыми пользователями компании, ежедневно формирующими отчеты о продажах. В своем отчете ключевые пользователи охарактеризовали созданное решение как очень удобное, быстрое и достаточное для проведение всестороннего анализа продаж. Для оценки решения привожу некоторые цифры:
  • На реализацию данного решения было потрачено 40 человеко-часов. Все описанные было выполнено одним человеком, т.е. мной. Предварительно я посетил курсы и успешно сдал экзамены Microsoft, получив сертификат Microsoft Certified Solutions Expert в области Business Intelligence.
  • Таблица фактов в рабочей базе данных содержит ~40 миллионов строк.
  • ETL-процесс выполняется приблизительно 20 минут.
  • Формирование отчетов выполняется в пределах нескольких секунд.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 20

    0
    Очень хотелось бы узнать, как можно извлекать данные из 1С через ее штатные интерфейсы, а не залезая в БД.

    Наличие NULL-ов в таблице фактов приводит к ошибкам при процессинге многомерной базы данных
    Обработка NULL-ов при процессинге настраивается: Cube — Dimension Usage — Define Relationship — Advanced — Measure Group Bindings — Null Processing. Там есть несколько вариантов.
      0
      Для этого существует механизм распределенных информационных баз http://v8.1c.ru/overview/RaspredBases.htm

      За подсказку по поводу обработки NULL-ов большое спасибо, буду знать.

      Поскольку это мое первое BI решение, очень хотелось бы услышать комментарии знатоков, на что еще обратить внимание. В том же вопросе с NULL-ами, как правильнее поступить? Оставить NULL-ы в хранилище и обрабатывать их в кубе при процессинге? Или сразу в хранилище от них избавляться?
        0
        У вас не так много деталей реализации описано, чтобы обратить на что-то внимание. Вот за NULL-ы зацепился. Вы, в общем, правильно сделали, что не стали пропускать NULL-ы в хранилище по умолчанию. Возможно, вам когда-нибудь пригодится отразить в хранилище именно _отсутствие связи_, а не просто неизвестную ссылку. Вот тогда ими и воспользуетесь.

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

        Еще не видно, используете ли вы суррогатные ключи для измерений или родные 1С-вские. Перейдя с char(9) на int можно здорово уменьшить размер таблиц фактов и, следовательно, увеличить скорость выполнения запросов. Еще бы они вам пригодились для Distinct Count'ов при секционировании, но у вас Standard Edition и секционирования у вас нет.
          0
          Спасибо. Деталей действительно не много. Описал, можно сказать, вершину айсберга, иначе бы статья получилась слишком большая.

          По поводу снежинки. Я решил проверить, насколько быстро будет происходить обновление данных в хранилище и многомерной БД при снежинке. Получилось 20 минут, вполне приемлемо. Решил оставить как есть, но будущее учту ваше замечание. Microsoft в книжке «Implementing a Data Warehouse with Microsoft SQL Server 2012» пишет: «If you do not use OLAP cubes and your reports query your data warehouse directly, then using a Star instead of a Snowflake schema might speed up the reports, because your reporting queries involve fewer joins». Сейчас мы не используем хранилище непосредственно для отчетов.

          Я использую суррогатные ключи типа int, 1С-вские char(9) используются только для сопоставления записей в хранилище и базах данных 1С.
            0
            Да, вы поступили совершенно правильно (исходя из ваших вводных). Просто в моем случае самый большой известный мне куб (мы делаем серийное решение и данные не обо всех инсталляциях мне известны) процессится порядка 200 минут. Не могу не обращать на это внимание.
            Свой первый куб я делал вообще без хранилища. Прямо на представлениях поверх 1Совских таблиц. И знаю, что многие и сейчас так делают. Создавать хранилище действительно дорого.
      0
      Чем не устроил вариант использования0 стандартного механизма распределенной информационной базы? Помимо отчета по продажам можно было бы использовать все остальные стандартные отчеты 1С + разрабатывать отчеты используя СКД
        +1
        Дело в том, что для целей упр. учета у нас используется очень доработанная конфигурация «1С: Торговля и склад 7.7». Нужно было конечно раньше переходить на 1С 8, но тогда у бизнеса были другие задачи и требования. Сейчас проект по переходу обсуждается, и будущая архитектура решения очень вероятно будет использовать стандартный механизм РИБ, но сколько будет длиться этот переход пока не понятно, очевидно что долго и мучительно. Кроме того, я не думаю, что стандартные отчеты в 1С могут в полной мере заменить возможности анализа данных с помощью многомерных данных, так что BI решение будет развиваться параллельно, вне зависимости от архитектуры решения 1С.
          0
          Что ж Вы сразу не признались, что ведете учет в системе, которая была разработана 15 лет назад (хорошо еще не под DOS-ом). Она же даже с Microsoft SQL Server 2008 R2 не работает без бубна — подмены dll 1C.
          Интересно было бы сравнить современные решения от 1С (Управление торговлей 8, 1С: Консолидация) и OLAP на SQL Server через Pivot Table в Excel по скорости формирования отчетов, удобству настройки измерений, затратам на внедрение.
            0
            Да, мне тоже было бы интересно сравнить эти продукты. Одно могу предположить смело, что решение на SQL Server и PivotTable Report в Excel будет работать быстрее. Еще один большой плюс решения на SQL Server — это возможность использования других «плюшек» от Microsoft, таких как интеграция с SharePoint, интерактивные отчеты на Power View, подписки на отчеты и т.д…

            Если 1С: Консолидация умеет работать с другими источниками данных кроме баз данных на основе конфигураций 1С 8, то это хорошо, а если нет, то при переводе OLTP на другую платформу придется внедрять другой инструмент BI. Моё же решение будет работать вне зависимости от платформы, на которой работает OLTP.

            Предполагаю, что 1С максимально упростила процесс настройки решения BI, и, возможно, внедрение этого продукта будет по трудозатратам выгоднее, однако нужно помнить, что 1С: Консолидация стоит денег, а в моем случае решение было построено без покупки дополнительного ПО.

            Один критерий, по которому 1С однозначно выигрывает — это количество специалистов на рынке, которых очевидно больше, чем девелоперов Microsoft BI.
              0
              Удобство исполнения отчетов от 1С зависят от того можно ли выбрать все данные из одной базы. Если имеется зоопарк из десятка бессвязных баз, из которых нужно сделать единую выборку, то построение отчета превратится в танцы с бубном по скрещиванию ежа с ужом.

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

              1) Создаем в конфигураторе новый отчет, открываем схему компоновки данных, нажимаем кнопку конструктор запросов

              2) Выбираем в конструкторе запросов необходимые поля и характеристики (характеристики в данном случае используются для создания дополнительных реквизитов в пользовательском режиме)
              s017.radikal.ru/i441/1402/dc/ebf9ae2e3fde.png
              s018.radikal.ru/i523/1402/c6/9bd5aeb7a56e.png
              Получается вот такой запрос:
              s006.radikal.ru/i213/1402/4c/c17df7f4d661.png

              3) Добавляем в СКД ресурсы (суммируемые поля)
              s52.radikal.ru/i137/1402/87/f08a35a041e8.png

              4) Создаем настройки по-умолчанию. В данном случае будут продажи в разрезе контрагентов и номенклатуры с отображением количества и стоимости.
              s52.radikal.ru/i137/1402/1c/ffade7bbb6a9.png

              5) Сохраняем и проверяем
              По-умолчанию будет сформирован отчет вот в таком виде:
              s006.radikal.ru/i213/1402/ce/ed5830e6853a.png

              Далее пользователь может перенастроить отчет в том виде, в котором ему необходимо, например, добавить группировки:
              s52.radikal.ru/i138/1402/c0/48f06e227fb5.png

              Или фильтры по периодам и реквизитам:
              s57.radikal.ru/i158/1402/9b/991d2c52be39.png

              Можно разложить по периодам, например, помесячно (немного коряво получилось, там запрос нужно поправить, чтобы красиво отображалось).
              s017.radikal.ru/i443/1402/99/52353e0e0c13.png

              Любую цифру можно расшифровать по документам, периодам, договорам и т.д.
              i065.radikal.ru/1402/56/05a164ac7922.png

              Для отборов, группировок, расшифровок доступны также реквизиты и свойства объектов.
              s006.radikal.ru/i213/1402/d5/d013cecea65b.png

              На написание отчета у меня ушло минут 10. По скорости наверняка будет проигрывать решениям BI, но не уложиться в норматив одну минуту на нашей рабочей базе мне не удалось. Дамб базы весит около 60Гб, MSSQL.
              Кроме того подобный отчет уже есть из коробки в базах 1С + еще десятки полезных и не очень готовых отчетов
                0
                Спасибо за такой развернутый ответ.

                Некоторый опыт работы с 1С у меня есть, поэтому описанное не вызывает вопросов. Очевидно в будущем мы будем использовать и РИБ и СКД.
                  0
                  Наша OLTP БД в ЦО весит 150 Гб. Плюс 30 филиалов, в каждом БД примерно по 15 Гб. Итого 600 Гб.
            0
            Для формирования отчетов есть прекрасная вещь под названием SQL Server Reporting Services (MS SSRS). У вас она тоже есть. Формируемые в ней отчеты можно потом экспортировать куда угодно, от PDF до Excel. Крайне рекомендую.
            Плюс, например, в том, что вы для каждого отчета один раз создаете хранящийся на сервере шаблон, и он един для всех, и любое исправление также сразу доступно всем. Также плюс в доступности отчета в любой момент из любого места, откуда доступен сервер SSRS. Например, генеральный может видеть отчет о продажах, лёжа на пляжу в Бали в красных труселях с айфуном в одной руке и пина-коладой — в другой…
            А если бы у вас был Enterprise Edition, то вам были бы доступны рассылки отчетов, управляемые данными (data-driven subscription), которые позволяют автоматически, по расписанию, направлять нужный отчет выбранным людям по e-mail либо сохранять в выбранную папку.
              0
              SSRS хорошо подходит для создания регламентированной отчетности. Но совершенно не подходит для аналитической (ad-hoc). Просмотр информации по стране в целом (как в случае у автора поста) — это скорее аналитическая отчетность. Тут OLAP-у не будет равных.
              Более того, SSRS — это средство доступа к данным (front-end) и в этом смысле его корректнее сравнивать с Excel-ем, а не с SSAS.
                0
                Именно так, SSRS это замена Excel. Я именно об этом и пишу: «Для формирования отчетов...».
                0
                SSRS мы используем. Собственно с него и началось мое знакомство с BI от Microsoft. Подписки действительно очень понравились пользователям, привыкшим работать в 1С. У 1С аналога я не видел. Кроме того, большой плюс SSRS заключается в возможности кеширования отчетов. Это позволяет существенно разгрузить SQL-сервер.
                  0
                  Да, всё так.
                0
                Не до конца понял из ETL части: вы данные каким-то образом аггригируете? Одно из серьезных преимуществ OLAP. У нас в компании наиболее объемные таблицы с фактами продаж на еженедельной основе аггригируются по неделям/месяцам/годам и для вывода этих значений созданы дополнительные условия. К примеру, если в репорте присуствуют только dimension'ы Year или Month, то факты брать из заранее посчитанных годовых или месячных таблиц. Так что пересчитывать в real-time ничего не нужно. Очень серьезно увеличивает производительность.
                  0
                  В случае с OLAP кубами агрегировать на уровне ETL, как правило, не надо. Достаточно определить агрегаты на уровне куба (это делается с помощью простого визарда). Сервер рассчитает агрегаты в момент процессинга куба, а при выполнении запроса сам определит, какой из агрегатов использовать наиболее выгодно. В этом и есть фишка ОЛАП.
                    0
                    ETL-процесс собирает данные из источников, экспортирует их в хранилище и процессит куб. В таблице фактов есть поле с датой, это означает, что все продажи одного офиса по одному покупателю и одному товару за один день агрегируются в одну строку. Эта агрегация выполняется на уровне view в источнике. Т.е. view dbo.Sales в базе данных 1С представляет данные в сгруппированном виде по офису, клиенту, товару, дню. Агрегация по дням, месяцам, годам происходит не в хранилище, а в многомерной модели данных, путем создания иерархии в измерении «Календарь». Если вы агрегируете данные прямо в хранилище, то, вероятно, вы не используете SSAS, а строите отчеты непосредственно из хранилища данных. Если я прав, то советую вам использовать колоночные индексы в таблице фактов, при условии, что у вас SQL Server 2012.

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

                  Самое читаемое