Как OLAP обращается к измерениям, которые являются числовыми диапазонами? - PullRequest
1 голос
/ 29 июля 2009

В предисловии я совсем не знаком с OLAP, поэтому, если терминология отключена, не стесняйтесь предлагать исправления.

Я читаю об OLAP, и, похоже, все дело в трейдинге для скорости, где вы производите предварительный расчет (или рассчитываете по требованию) и сохраняете статистические данные о ваших данных, определенные по определенным параметрам. Я понимаю, как это работает для измерений, которые имеют дискретный набор значений, таких как {Male, Female} или {Jan, Feb, ... Dec} или {@US_STATES}. Но как насчет измерений, которые имеют совершенно произвольные значения, такие как (0, 1.25, 3.14156, 70000.23, ...)?

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

Буду признателен за любую другую помощь в изучении OLAP. На первый взгляд, Google и SO кажутся немного сухими (по сравнению с другими, более популярными темами).

Редактировать: Был запрошен размер, в котором есть произвольные значения.

  • СКОРОСТЬ экспериментов: 1,256 м / с, -2,234 м / с, 33,78 м / с
  • СТОИМОСТЬ транзакций: $ 120,56, $ 22,47, $ 9,47

Ответы [ 2 ]

3 голосов
/ 30 июля 2009

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

Однако я сказал обычно . В нашей схеме OLAP у нас есть хороший пример столбца, о котором вы думаете: event_time (поле даты и времени, с гранулярностью до второго). В наших данных это будет почти уникально - в одну и ту же секунду не будет происходить двух событий, но поскольку в нашей таблице хранятся данные за годы, это все еще означает, что существуют сотни миллионов потенциально дискретных значений, и когда мы запускаем наши Запросы OLAP мы почти всегда хотим ограничивать на основе временных диапазонов.

Решение состоит в том, чтобы сделать то, что сказал Дэвид Разник, - вы создаете «стоимостную» версию значения. Таким образом, в нашей таблице, в дополнение к столбцу event_time, у нас есть столбец event_time_bucketed, который является просто датой события с временной частью 00:00:00. Это уменьшает количество различных значений с сотен миллионов до нескольких тысяч. Затем во всех запросах, ограничивающих дату, мы ограничиваем как столбец с реальными значениями (так и столбец с реальными значениями (так как этот столбец будет недостаточно точным, чтобы дать нам реальное значение), например ::10000

   WHERE event_time BETWEEN '2009.02.03 18:32:41' AND '2009.03.01 18:32:41'
     AND event_time_bucketed BETWEEN '2009.02.03' AND '2009.03.01'

В этих случаях конечный пользователь никогда не видит столбец event_time_bucketed - он просто предназначен для оптимизации запросов.

Для значений с плавающей запятой, о которых вы упомянули, стратегия группирования может потребовать немного больше внимания, так как вы хотите выбрать метод, который приведет к относительно равномерному распределению значений и сохранит смежность. Например, если у вас есть классическое распределение колоколов (с хвостами, которые могут быть очень длинными), вы хотите определить диапазон, в котором проживает основная часть населения (скажем, 1 или 2 стандартных отклонения от среднего), разделите его на равномерное и создайте еще два сегмента для «все меньше» и «все больше».

1 голос
/ 29 июля 2009

Я нашел эту ссылку полезной http://www.ssas -info.com /

Ознакомьтесь с разделом веб-трансляций, в котором они рассказывают о различных аспектах, начиная с того, что такое BI, Warehousing TO для проектирования куба, измерения, вычисления, агрегации, KPI, перспективы и т. Д.

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

В службах аналитики SQL Server имеется мастер оптимизации на основе использования, который помогает в проектировании агрегации путем анализа запросов, отправленных клиентами (такими как клиенты отчетов, такие как SQL Server Reporting Services, Excel или любые другие), и соответственно уточняет дизайн агрегирования.

Надеюсь, это поможет.

ура

...