Структура в пределах промежуточной области хранилища данных - PullRequest
15 голосов
/ 14 мая 2009

Мы работаем над хранилищем данных для банка и в значительной степени следуем стандартной модели промежуточных таблиц Kimball, схеме «звезда» и ETL для протягивания данных в процессе.

Кимбалл говорит об использовании промежуточной области для импорта, очистки, обработки и всего, пока вы не будете готовы поместить данные в звездообразную схему. На практике это обычно означает загрузку данных из источников в набор таблиц с небольшими изменениями или без изменений, с последующим необязательным переносом данных через промежуточные таблицы до тех пор, пока они не будут готовы к переходу в схему типа «звезда». Это большая работа для одного лица, никакой ответственности здесь нет.

В предыдущих системах, над которыми я работал, проводилось различие между различными наборами таблиц, в том числе:

  • Загрузить таблицы : необработанные исходные данные системы, без изменений
  • Промежуточные таблицы : промежуточная обработка, набор и очистка
  • Складские столы

Вы можете прикрепить их в отдельных схемах, а затем применить разные политики для архивирования / резервного копирования / безопасности и т. Д. Один из других сотрудников работал на складе, где есть StagingInput и StagingOutput , похожая история. Команда в целом имеет большой опыт, как хранилище данных, так и прочее.

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

Хотя, конечно, довольно очевидно, как это сделать, если мы хотим добавить больше структуры в область подготовки, но кажется очень странным, что об этом ничего не написано.

Итак, что все остальные там делают? Является ли постановка всего этого большого неструктурированного беспорядка, или у людей есть интересные проекты на этом?

Ответы [ 7 ]

4 голосов
/ 29 октября 2009

Просто примечание, есть книга Raph Kimball и Joe Caserta под названием «Инструментарий ETL хранилища данных», поэтому мистер Кимбалл приложил некоторые усилия для этого. :)

4 голосов
/ 14 мая 2009

У меня возникла такая же проблема. У нас есть большой HR DataWarehouse, и я собираю данные из систем по всему предприятию. У меня есть отличная коллекция таблиц Fact и Dimension, но область подготовки - беспорядок. Я не знаю каких-либо стандартов для дизайна этого. Я бы пошел по тому же пути, по которому вы идете, и предложил бы стандартный набор имен, чтобы все было в порядке. Ваше предложение довольно хорошо для именования. Я бы продолжал работать с этим.

3 голосов
/ 03 июня 2011

В настоящее время мы работаем над большим проектом DWH страхования, он немного сложен, но каждая из исходных системных таблиц помещается в отдельную схему в базе данных STAGING, затем у нас есть ETL, который перемещает / очищает / соответствует (MDM ) данные из промежуточной базы данных в базу данных STAGINGCLEAN, а затем дополнительный ETL, который перемещает данные в DWH Kimball.

Разделение базы данных Staging и StagingClean мы считаем очень полезным при диагностике проблем, особенно в области качества данных, поскольку у нас есть грязные промежуточные данные, а также очищенная версия перед их преобразованием в собственно DWH.

2 голосов
/ 28 июля 2009

В постановке могут быть подобласти. Называется, например, staging1, staging2.

Staging1 может быть напрямую извлечен из источников данных без преобразования. А Staging1 хранит только самые последние данные.

Staging2 сохраняет данные преобразованными и готовыми к отправке на склад. Staging2 хранит все исторические данные.

0 голосов
/ 18 января 2013

Какой замечательный вопрос.

В прошлом мы использовали суффикс _MIRR (для зеркала) для нетрансформированных данных, помещенных в базу данных, т.е. это отражает источник. Затем мы используем _STG для преобразованных данных из источника, затем _DW для звездной схемы.

Таблицы подготовки здесь будут в 3NF. Я думаю, что это ключевой момент. Данные переносятся без преобразования и хранятся отдельно от следующего шага, на котором мы полностью нормализуем данные, а затем объединяем их в нашей звездной схеме для отчетности.

0 голосов
/ 13 сентября 2010

Посмотрите на этот пост здесь . Это дает хороший обзор обязанностей области подготовки в DW.

0 голосов
/ 14 мая 2009

Лично я не собираюсь искать проблемы ни в Кимбалле, ни где-либо еще.

Какую "структуру" вы ищете? Какую «структуру» вы считаете нужной? Какие проблемы вы видите из-за отсутствия «структуры» у вас сегодня?

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

...