Проект хранилища данных - периодический снимок с часто меняющимися ключами измерений - PullRequest
Новая
       19

Проект хранилища данных - периодический снимок с часто меняющимися ключами измерений

0 голосов
/ 08 сентября 2018

Представьте таблицу фактов с суммированием мер за период времени, скажем, 1 час. 

Start Date          | Measure 1 | Measure 2
-------------------------------------------
2018-09-08 00:00:00 | 5         | 10
2018-09-08 00:01:00 | 12        | 20

В идеале мы хотим сохранить зерно таким, чтобы каждый ряд составлял ровно 1 час. Однако каждая строка ссылается на измерения, которые могут «сломать» зерно Например: 

Start Date          | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5         | 10        | key 1
2018-09-08 00:01:00 | 12        | 20        | key 2

Возможно, что значение измерения может измениться на 30 минут в час, и в этом случае приведенное выше будет неточным и должно быть представлено следующим образом: 

Start Date          | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5         | 10        | val 1
2018-09-08 00:00:30 | 5         | 10        | val 2
2018-09-08 00:01:00 | 12        | 20        | val 2

В нашем сценарии данные должны быть разрезаны по крайней мере на 5 ключей измерения с такими запросами: 

sum(measure1) where dim1 = x and dim2 = y..

Существует ли шаблон проектирования для этого требования? Я рассмотрел «периодические снимки», но я нигде не читал об этом виде разделения строк при изменениях размеров.

Я вижу только два варианта:

  1. Сохраните значения измерений, которые наиболее присутствовали в каждой строке (например, если значение измерения было истинным в течение большей части времени в часе, используйте это значение). Это приведет к некоторой потере точности.
  2. Разделять каждую строку при каждом изменении размера. Это сложно в ETL, создает больше данных и нарушает правило гранулярности в таблице фактов.

Вариант 2 является текущим решением и служит цели, но его сложнее поддерживать. Есть ли лучший способ сделать это или другие варианты?

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

Line   | Date                | Crew   | Product   | Running Time (mins)
-----------------------------------------------------------------------
Line 1 | 2018-09-08 00:00:00 | Crew A | Product A | 60

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

1 Ответ

0 голосов
/ 20 марта 2019

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

Start Date          | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5         | 10        | val 1
2018-09-08 00:01:00 | 5         | 10        | val 1
2018-09-08 00:01:00 | 12        | 10        | val 2

Вам необходимо будет принять во внимание и другие меры и убедиться, что все они входят в правильное ведро (значение 1 или значение 2). Я разделил их равномерно в примере.

Теперь, если вы нарежете по часу 1 и по диму 1, значение 2, вы увидите только 12 (мера 1), а если вы порежете по часу 1, дим 1, значение 1, вы увидите только 5, и если вы только нарезать на час 1, вы увидите 17.

Помните, ваше зерно определяется уровнем каждого измерения, а не только измерением времени. НТН.

...