Как запрограммировать бизнес-логику в куб OLAP?

Question

Мы стремимся построить куб OLAP из реляционной БД. Но база данных содержит только необработанные данные. «Доменная логика», такая как вычисления, условная логика и пользовательские агрегации (то есть суммируют все строки, которые удовлетворяют этим условиям, и не существует другой строки, такой как бла-бла-бла), содержится в коде .NET. Я хотел бы, чтобы значения, сгенерированные этим кодом, были включены в куб.

Вопрос 1: Какую архитектуру вы рекомендуете включать в куб в доменной логике? Я бы предпочел НЕ ...

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

Сохранение моей бизнес-логики в .NET-коде упрощает обслуживание, масштабирование и тестирование.

Вопрос 2: Это хорошая архитектура?

• Создание вторичной базы данных OLTP в качестве хранилища данных.
• Затем создайте пользовательский процесс ETL для извлечения данных из исходной системы, проведите вычисления и запишите эту информацию обратно в базу данных DW,
• Пусть куб обрабатывает базу данных DW

Answer 1

Я бы сказал, что это зависит. Как правило, если вы можете избежать построения каких-либо вычислений MDX и просто использовать опцию из второго вопроса, вы получите быстрый куб. Однако MDX обычно используется, потому что бизнес-вычисления выполняются легче, чем в .NET или SQL.

В общем, некоторые вызовы лучше в .NET или SQL, а другие лучше, чем в MDX. В частности, низкозернистые кальки, работающие с данными уровня детализации, обычно быстрее выполняются до того, как попадают в куб, тогда как другие, особенно те, которые работают с агрегатами, быстрее и проще в SSAS.

Сказав все это, если у вас уже все это реализовано и вы можете легко использовать то, что у вас есть, я бы не советовал тиражировать бизнес-логику в SSAS, даже если она работает на агрегатах, если только у вас не возникли конкретные проблемы. Если все работает нормально и вам нужен только слой OLAP, то нет ничего плохого в том, чтобы использовать результаты ваших вычислений в SSAS - это могло бы и ускорило бы кубы, поскольку во время выполнения не будет выполнено никаких вычислений.

Answer 2

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