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

Рассмотрим две следующие архитектуры DWH:

DWH с хранилищем необработанных данных, слои:

  • Исходные системы
  • Промежуточная область (усекается при каждой загрузке, точная схема исходных таблиц)
  • Хранилище сырых данных (смоделировано как хранилище данных, содержит историю записей, хабы / спутники / ссылки, смоделированные по структуре исходных систем, НИКАКИЕ бизнес-правила не применяются)
  • Витрины данных (размерные модели, применяемые бизнес-правила)

DWH с постоянной промежуточной областью (PSA или HDA), слои:

  • Исходные системы
  • Промежуточная область (усекается при каждой загрузке, точная схема исходных таблиц)
  • PSA (содержит историю записей, схему исходных таблиц + столбцы date_load / date_load_end и т. Д.)
  • Витрины данных (размерные модели, применяемые бизнес-правила)

Имеет ли концепция raw Data Vault какие-либо преимущества по сравнению с концепцией PSA? На мой взгляд, моделирование Data Vault добавляет ненужной сложности с точки зрения ETL, а также снижает производительность.

Трудно найти по-настоящему хороший ответ на этот вопрос, есть мысли?

Спасибо!


sql database data-warehouse etl data-vault
person user3596100    schedule 20.01.2020    source источник
comment
Это будет закрыто как основанное на мнении. Но обратите внимание, что постоянная промежуточная область теперь чаще называется Data Lake, что должно указывать на популярность подхода :)   -  person David Browne - Microsoft    schedule 22.01.2020
comment
Для меня это во многом зависит от ваших исходных систем. Сколько их? Как качество их моделей данных и так далее? Мой опыт показывает, что необработанное хранилище может быть проблемой, если целостность модели данных исходной системы имеет низкое качество.   -  person Cedersved    schedule 31.01.2020

Ответы (2)


arrow_upward
0
arrow_downward

Data Vault и постоянная промежуточная область звучат для меня как яблоки и груши - трудно сравнивать. Вы не должны пытаться определить Data Vault для сбора исходных данных, не зная бизнес-онтологии - в противном случае вы создаете хранилище исходной системы, которое не принесет бизнесу никакой выгоды или принесет ей небольшую пользу. Для меня создание хранилища данных на PSA или озере данных имеет гораздо больший смысл. Получение данных в качестве образа исходных систем, а затем пошаговое построение на их основе устойчивого сбора данных.

person Andreas    schedule 04.03.2020

arrow_upward
0
arrow_downward

Добавленная сложность соответствует реляционной модели, представленной ранее в случае Data Vault. Я предполагаю, что это зависит от того, на каком уровне вы хотите моделировать свои данные и делать их повторно используемыми в разных сценариях использования, что приводит к разным витринам данных. Я имею в виду, что витрины данных предназначены для конкретных бизнес-кейсов, а модель хранилища данных больше предназначена для того, чтобы быть всеобъемлющей (модель предприятия). Следовательно, витрины данных, основанные на модели DV, вообще не нуждаются в физической материализации каких-либо данных. Можно настроить слой представлений, которые выглядят как таблицы звездообразной схемы, но на самом деле имеют:

•   Zero maintenance cost.
•   Zero storage costs.
•   High flexibility.

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

person y4nnick    schedule 31.03.2020