Что я должен иметь в виду при создании решения OLAP с нуля?

У меня есть только опыт работы с Microsoft OLAP, поэтому вот мои два цента относительно того, что я знаю:

1. Если вы реализуете Кубы, отделите производственный SQL Server от источника для кубов. Кубам требуется много SELECT DISTINCT column_name из источника.таблица. Вы не хотите, чтобы обработка Куба блокировала вашу критически важную производственную систему.

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

3. OLAP может быть излишним для вашей среды. Основная проблема, которую вы подняли, заключалась в том, что ваши отчеты статичны и пользователи хотят получить доступ к данным напрямую. Можно создать модель данных и предоставить пользователям доступ к построителю отчетов в службах SSRS или доступ к записи отчетов в других BI-пакетах, таких как Cognos, Business Objects, так далее. Я обычно не рекомендую этот подход, так как он выходит за рамки того, что большинство пользователей должны знать, чтобы получить данные, но в небольшом магазине этого может быть достаточно, и это легко реализовать. Давайте посмотрим правде в глаза-пользователи обычно просто хотят получить данные в Excel, чтобы манипулировать ими дальше. Поэтому, если вы не хотите предоставлять им веб-интерфейс, и вы просто хотите, чтобы они получили данные из Excel, вы можете предоставить им прямой доступ к базе данных к копии производственных данных. Недостатком этого подход заключается в том, что пользователи обычно не понимают отношений SQL или базы данных. OLAP помогает избежать принуждения пользователей изучать SQL или отношения, но это не легко реализовать на вашем конце. Если у вас есть только несколько опытных пользователей, которым нужен такой доступ, может быть достаточно легко научить нескольких опытных пользователей, как выполнять основные запросы в Excel против базы данных, и они будут рады получить это завтра. ОЛАП не будет готов к завтрашнему дню.

4. Если у вас есть только несколько видов систем исходных данных, вы могли бы уйти с построением супер-динамического статического отчета. Например, у меня есть отчет, написанный на C#, который в основном позволяет пользователям выбирать столько столбцов, сколько они хотят из списка из 30 столбцов, и фильтровать данные по нескольким полям диапазона дат и спискам фильтров полей. Этот простой отчет охватывает около 40% всех запросов специальных отчетов от конечных пользователей, поскольку он охватывает все основные, основные показатели и поля клиента. Недавно мы перенесли этот доклад на SSRS и это позволило нам увеличить количество полей до 100 и улучшить общий пользовательский интерфейс. Независимо от платформы отчетности, можно предоставить пользователям некоторую динамическую гибкость даже в рамках статической системы отчетности.

5. Если у вас есть только несколько баз данных, вы, вероятно, можете создавать резервные копии и восстанавливать базы данных в качестве ETL. Однако, если вы хотите сделать что-то помимо этого, вы можете также укусить пулю и использовать SSIS (или некоторые другой инструмент ETL). Как только вы попадете в ETL для хранения данных, вы будете использовать графический инструмент дизайна. Кодирование хорошо работает для приложений, но ETL больше о рабочих процессах, и именно поэтому инструменты имеют тенденцию сходиться на графическом интерфейсе. Вы можете обойти это и попытаться закодировать хранилище данных из текстового редактора,но в конце концов вы потеряете много. см. этот пост для получения более подробной информации о различиях между загрузкой данных из кода и загрузкой данных из SSIS.

ОТЗЫВЫ О ТОМ, КАК ИСПОЛЬЗОВАТЬ КУБЫ С РЕЛЯЦИОННЫМ ХРАНИЛИЩЕМ ДАННЫХ

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

преимущество этого подхода заключается в следующем:

1. Это относительно легко реализовать, так как вам не нужно создавать целую подсистему ETL, чтобы начать работу с OLAP.

2. этот подход хорошо работает для прототипирования того, как вы хотите построить более долгосрочное решение. Вы можете прототипировать его в 1-2 днях и показать некоторые из преимущества OLAP сегодня.

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

недостатки этого подхода заключаются в следующем:

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

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

3. возможно, вам придется построить систему дважды, если вы начнете с реляционного хранилища данных, а затем перейдете к сплющенной базе данных. Честно говоря, я думаю, что количество дублированной работы тривиально. Большая часть того, что вы узнали, создавая куб из реляционного хранилища данных, будет преобразована в настройку нового Куба OLAP. Основная проблема, однако, заключается в том, что вы, вероятно, создадите новый куб вообще, а затем любые пользователи старого Куба должны будут перейти на новый куб. Любые отчеты, построенные в SSRS или Excel, вероятно, сломаются в этот момент и должны быть переписаны с нуля. Таким образом, основная стоимость перестройки Куба заключается в перестройке зависимых объектов, а не в перестройке самого Куба.

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