Как агрегировать данные из SQL Server 2005

Question

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

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

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

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

Answer 1

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

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

Mosha Pasumansky имеет blog на SSAS и MDX с отличным links.

Помимо этого я бы рекомендовал книги Microsofts Online.

Answer 2

SSAS - это инструмент ETL. В основном вы получаете данные откуда-то (ваши исходящие статьи), делайте что-нибудь с ним (агрегат) и помещаете его в другое место (таблица ваших агрегатов, хранилище данных и т. Д.). Проверьте ссылку для получения дополнительной информации.

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

TL; DR: Определите таблицу сводной истории с учетом ваших будущих потребностей в отчетности. Используйте SSAS для заполнения таблицы и обновления ее из ежедневных обновлений. Отчет из этой таблицы. Дальнейшее чтение: Star Schemas и хранилище данных.

Answer 3

Уверены ли вы, что вы не смешиваете SSAS (службы Analysis Services) и службы SSIS (интеграционные услуги)?

SSAS не является ETL, это инструмент OLAP.

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

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

Answer 4

@Sergio и @Rowan

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

Answer 5

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

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