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

Question

Я работаю в компании, использующей программный продукт на базе сервера баз данных MS SQL, и за эти годы я разработал 20-30 довольно сложных отчетов на PHP, получающих данные непосредственно из базы данных.Это было очень успешно, и люди довольны этим.

Но у него есть некоторые недостатки:

• Для новых изменений это может быть довольно интенсивным развитием
• Пользователь не может много экспериментировать с данными - он заблокирован жестко закодированным представлением
• Это может быть медленным для больших отчетов

Я планирую постепенно перейти на OLAPна основе подхода, который можно запросить из Excel или какого-либо веб-сервиса.Но я хотел бы сделать это таким образом, чтобы внести наименьшее количество новых сложностей в ИТ-среду - наименьшее количество различных служб, заданий синхронизации и т. Д.

У меня есть несколько вопросов на этот счет:

1) Связанный с рабочим процессом:

• Каков хороший путь разработки от «черного сервера SQL Server» до «OLAP готов к использованию»?
• Какие серверы и службы должны быть настроены, и какие сценарии должны быть написаны?
• Какие самые трудные / самые важные / самые трудоемкие части?

2) ETL:

• ПолагаюЛучше всего иметь отдельные серверы для хранилища данных и производственного SQL?
• Как они синхронизируются (push / pull)?Использование каких технологий / языков?
• Для меня SSIS выглядит слишком сложным, и графический рабочий процесс меня мало привлекает - я бы предпочел текстовый скрипт, который выполняет эту работу.Это возможно?
• Или выгодно использовать графический клиент только с одним источником и одним адресатом?

3) Разработка:

• Сколько из этого (интеграция данных, услуги анализа) может быть эффективно поддержано с помощью CLI-инструмента?
• Можно ли легко перенести установку между производством и разработкой?

Я рад любому ответу, который охватывает только некоторые из этих вопросов - и даже при том, что это MSокружающая среда, мне также интересно услышать о преимуществах в других технологиях.

Answer 1

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

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

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

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

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

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

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

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

Answer 2

Вы в основном задаете вопрос на миллион долларов о том, «Как построить DWH».На самом деле это не тот вопрос, на который можно окончательно ответить.

Тем не менее, вот кикстарт:

Если вы ищете минимально жизнеспособный продукт, знайте, что вы находитесь в среде данных, а не чисто программный.В средах с большим объемом данных постепенно сложнее создать продукт, потому что количество усилий для внесения изменений в систему намного больше.Думайте об этом, как будто каждое изменение, которое вы делаете в программном обеспечении, должно быть как-то обратно совместимо со всем, что вы когда-либо делали.Теперь вы понимаете, к черту Microsoft, в :-).

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

Хотя вы можете начать с клонирования БД, которое будет основано на простых копируемых SQL-кодах.и затем, агрегируя или вставляя его в OLAP, я бы с самого начала рекомендовал испачкать руки настоящим инструментом ETL.Это особенно верно, если вы предвидите необходимость роста.В 9 из 10 раз потребность в будет расти.

MS-SQL - хороший выбор для БД, если вы не возражаете против затрат.Естественным инструментом ETL будет SSIS, а также надежный инструмент.

Даже если ваши первые преобразования просто «возьмите эту таблицу и выбросьте ее туда», вы все равно получите много с точки зрения управления процессами (выполнено ли задание? Что произойдет, если оно не выполнится? И т. Д.) И отладки,Кроме того, легче расти органически, поскольку необходимо учитывать требования и / или особые случаи.