Вопрос

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

Идея состоит в том, чтобы иметь агрегированное представление обо всех наших транзакциях и иметь что-то, что может указывать на то, что что-то не так (например, что мы отправляем на 20% меньше статей, чем в среднем).

Моя идея состоит в том, чтобы перенести вчерашние данные в СССАС каждую ночь там хранятся совокупное значение количества транзакций и фактическое количество транзакций из вчерашних данных.Надеемся, что использование SSAS ускорит подготовку отчетов.

Как вы думаете, это правильная идея?Должен ли я пропустить SSAS и получать отчеты непосредственно на основе необработанных данных?Я знаю, как использовать службы отчетов для необработанных данных с помощью стандартных запросов SQL, но как это изменится при запросе SSAS?Я не знаю СССАС - с чего начать..?

Это было полезно?

Решение

Особенность SSAS заключается в том, что вы можете довольно легко получить те показатели, о которых вы говорите, либо создав вычисляемые показатели, либо используя ключевые показатели эффективности.

Я начал с Предоставление бизнес-аналитики с помощью Microsoft SQL Server 2005.У него было хорошее введение, но, к сожалению, оно слишком многословно, когда дело касается деталей.Но если вы хотите понять SSAS, OLAP и отчетность с использованием этой структуры, это хорошее начало.

У Моши Пасуманского есть блог по SSAS и многомерные выражения с великим ссылки.

Кроме этого, я бы порекомендовал книги Microsoft Online.

Другие советы

Вы уверены, что не путаете SSAS (службы анализа) и SSIS (службы интеграции)?

SSAS — это не ETL, это инструмент OLAP.

SSIS — это инструмент ETL.

Я согласен со всем, что сказал Роуэн.Меня просто смущают термины.

ССАС – это ЭТЛ инструмент.По сути, вы откуда-то получаете данные (ваши исходящие статьи), что-то делаете с ними (агрегируете) и помещаете их куда-то еще (ваша таблица агрегатов, хранилище данных и т. д.).Подробности смотрите по ссылке.

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

ТЛ;ДР:Определите таблицу агрегированной истории с учетом будущих потребностей в отчетности.Используйте SSAS, чтобы заполнить таблицу и обновить ее на основе ежедневных обновлений.Отчет из этой таблицы.Дальнейшее чтение:Звездообразные схемы и хранилища данных.

@Серджио и @Роуэн

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

@Riri, возможно, SSAS излишен для ситуации, которую вы представили.Если вам нужно только ежедневно заполнять таблицы суммирования, вы можете сделать это, создав обычное задание JOB в SQL Server и выполнив его в обычном сценарии T-SQL.

Я использовал этот подход в течение нескольких лет в ежедневном процессе для расчета бизнес-показателей на основе примерно 9 ГБ новых данных в день.Он работает, быстро, просто и использует технологию, к которой вы уже привыкли.Если ваш ежедневный процесс усложняется (необходимо читать файлы, использовать FTP, отправлять электронные письма), вы можете перейти на пакет SSIS (или любой другой инструмент ETL, который вам нравится), но я не могу рекомендовать использовать SSAS, если вам не нужно предоставить OLAP. возможности для ваших пользователей.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top