Влияние на размерность таблицы фактов - PullRequest
Новая
       73

Влияние на размерность таблицы фактов

0 голосов
/ 12 ноября 2018

Я начинаю строить звездную схему, и мне это нравится ^^

У меня проблема дизайна с размерным моделированием.

У меня есть таблица фактов для каждой транзакции в схеме «звезда» (наибольшее зерно) Нечто подобное (упрощенная версия) 

transaction_facts
- id
- account_dim
- date_dim
- status_dim
- amount

status_dim
- id
- code
- description
- final

Для транзакции статус не четко определен во время процесса. Большинство всех статусов попадают в эти случаи:

  • транзакция в порядке
  • транзакция составляет
  • транзакция в порядке, но должна быть подтверждена.

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

Как мне справиться с такими поздними изменениями? Интуитивно я хотел бы просто изменить существующие транзакции к новому измерению, но это заставляет меня думать о 2 вещах:

  • Это хорошая практика? (не переписывать историю и т.д ...)
  • Как справиться с такого рода изменениями в BigQuery или Redshift или любой добавляемой системе? При очень большом количестве строк это будет проблемой, поскольку эти системы плохо работают с обновлениями

1 Ответ

0 голосов
/ 12 ноября 2018

Если

  • это не обязательно должна быть настоящая таблица «финансовых транзакций» И
  • вам не нужно вести историю значений (например, что было значение на какую-то предыдущую дату)

Тогда вы можете / должны обновить значение.

Если вы используете Redshift, то вы можете сделать это эффективно, записав пакет обновлений в промежуточную таблицу (копия из s3), а затем применив все это за один раз.

...