Структура внутри промежуточной области хранилища данных

Question

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

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

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

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

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

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

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

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

Answer 1

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

Answer 2

Просто обратите внимание: существует книга Рафа Кимбалла и Джо Казерты под названием «Инструментарий ETL для хранилища данных», поэтому г-н.Кимбалл приложил к этому некоторые усилия.:)

Answer 3

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

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

Answer 4

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

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

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

Answer 5

Посмотрите этот пост здесь.Он дает хороший обзор обязанностей промежуточной области внутри DW.

Answer 6

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

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

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

Answer 7

Лично я не ищу неприятностей ни в Кимбалле, ни где-либо ещё.

Какую «структуру» вы ищете?Какая «структура», по вашему мнению, необходима?Какие проблемы вы видите из-за отсутствия у вас сегодня «структуры»?

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