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

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

  1. производственная БД ----> хранилище данных (звездная схема) - - - - > OLAP Cube
  2. DB продукции - - - ->Промежуточная База Данных ----> хранилище данных (звездная схема) - - - - > OLAP Cube

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

какой подход вы находите лучше при проектировании хранилища данных ?

14
data-warehouse database-design olap

4 ответов

ниже точки берутся, DWBI организации статьи

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

  1. Загрузка Дельта: ваши данные считываются постепенно из источника, и вам нужно промежуточное хранилище, где инкрементный набор ваших данных может быть временно сохранен для целей преобразования
  2. трансформация нужен: необходимо выполнить очистку данных , проверки и т. д. перед потреблением данных в хранилище
  3. ограждения: ваша обработка занимает много времени, и вы не хотите оставаться подключенным к исходной системе (предположительно, исходная система постоянно используется фактическими бизнес-пользователями) в течение всего времени вашей обработки и, следовательно, предпочитаете просто читать данные из исходной системы за один раз, отключиться от источника, а затем продолжить обработку данных на своем " собственном сторона"
  4. отладки цели: вам не нужно возвращаться к источнику все время, и вы можете устранить проблемы (если таковые имеются) только из промежуточной области
  5. Восстановление После Сбоя: исходная система может быть временной, и состояние данных может изменяться. Если вы столкнулись с каким-либо сбоем восходящего потока, вы не сможете повторно извлечь свои данные, поскольку источник изменился к этому времени. Наличие локальной копии помогает

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

19

ETL = извлечь,преобразование и нагрузки. Помощь промежуточной базы данных с битом преобразования. Лично я всегда включаю этап DB и ETL.

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

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

  1. в конечном итоге свяжет ваше решение хранилища данных непосредственно с вашим исходная база данных
  2. , скорее всего, в конечном итоге с очень сложным шагом ETL
  3. может закончиться с условиями гонки / сиротскими записями из-за изменения в исходной базе данных в ходе ЭТЛ процесс
  4. данные Warehousey люди могут сделать "хрумпх" типа звучит на вас

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

возможно, вы также сталкивались с такого рода выкройка:

[PROD DB] -(ETL)->  [RAW DB] -(ETL)-> [STAGING DB] -(ETL)-> [DW DB]  -(ETL)-> [DM DB]

что, если соображения производительности важны, вы можете посмотреть. В вашем случае RAW_DB может быть точной копией 1: 1 вашей производственной базы данных, а шаг ETL, который создает ее, может быть просто воссозданием БД из последней ночной резервной копии. (Традиционно RAW_DB использовался для получения данных из различных внешних источников с каждым полем в виде чистого текста, эти поля затем преобразуются в ожидаемый тип данных с исключениями, обрабатываемыми как встречающийся. Это не такая большая проблема, когда у вас есть один источник и его хорошая строго типизированная нормализованная база данных)

из этого RAW_DB следующий процесс ETL будет усекать и заполнять промежуточную БД таким образом, что промежуточная БД содержит все новые/обновленные записи, которые поступают на склад.

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

7

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

  • если это уместно, вы можете сделать снимок вашей производственной базы данных (у вас уже может быть ежедневная резервная копия или снимок горячего сайта), а затем сделать ETL из восстановленной резервной копии или снимка. Это может сэкономить нагрузку на производство база данных.
  • вам может понадобиться сложная обработка для вашего ETL, которая требует много промежуточных таблиц, которые не имеют никакой пользы, кроме процесса ETL. Возможно, вы не захотите загромождать хранилище данных этими промежуточными таблицами.
  • ваши необработанные данные могут быть доступны не все сразу, и вам нужно где-то накопить их перед началом процесса ETL для создания хранилища данных.
  • ваше хранилище данных может иметь требования к производственному окну, которые не могут быть встреченный вашим ETL, и поэтому вам нужно выполнить "вывод" (т. е. новые записи для хранилища данных), а не или в дополнение к вашей производственной базе данных.
  • производственная система может находиться в высокозащищенной среде и по какой-либо причине может быть принято решение не предоставлять процессу ETL полный доступ к необработанным производственным данным. Группа, управляющая производственной базой данных, может захотеть извлечь только необходимые данные в промежуточную базу данных, чтобы процесс ETL мог только посмотрите, что ему нужно. Я видел это, когда производственная система и процесс ETL управляются разными сторонними поставщиками.
  • возможно, ваш процесс ETL создает большие промежуточные таблицы. Иногда управление пространством проще, если вы начинаете с пустой базы данных модели для промежуточной области ETL, а затем "выбрасываете ее" каждый день, а не пытаетесь восстановить пространство более хирургическим способом, как вы могли бы сделать с производством или отчетностью база данных.

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

4

действительно промежуточная зона не является необходимостью, если мы можем справиться с этим на лету. Но можем ли мы? Вот несколько причин, почему вы не можете избежать плацдарм: 1. Исходные системы доступны только для извлечения во время конкретного временной интервал, который обычно меньше, чем общая загрузка данных время. Это хорошая идея, чтобы извлечь и сохранить вещи на вашем конце, прежде чем вы теряете связь с исходными системами. 2. Вы хотите извлечь данные на основе некоторых условий, которые требуют, чтобы вы присоединились к двум или более разные системы вместе. Е. Г. вы хотите извлекать только те клиенты, которые также существуют в некоторых других системы. Вы не сможете выполнить SQL-запрос, соединяющий две таблицы из двух физически разных баз данных. 3. Различные системы источников имеют различное отведенное время для извлечения данных. 4. Частота загрузки данных хранилища данных не совпадает с частотой обновления исходных систем 5. Извлеченные данные из одного и того же набора исходных систем будут использоваться в нескольких местах (загрузка хранилища данных, загрузка ODS, сторонние приложения и т. д.) 6. Процесс ETL включает в себя сложные преобразования данных, которые требуют дополнительного пространства для временного этапа данных 7. Существует конкретное требование согласования / отладки данных, которое гарантирует использование промежуточной области для проверки данных до, во время или после загрузки

ясно промежуточная зона дает гибкость серии во время загрузки данных. Разве мы не должны всегда иметь отдельный плацдарм? Есть ли какое-либо влияние наличия сценическая площадка? Да есть несколько. 1. Промежуточная область увеличивает задержку-это время, необходимое для изменения исходной системы в хранилище данных. Во многих приложениях реального времени / почти реального времени промежуточная область скорее избегается данных в промежуточной области занимает дополнительное пространство 2. Для меня, во всех практических смыслах, преимущество наличия промежуточной зоны перевешивает ее проблемы. следовательно, в целом я предложу обозначить определенную промежуточную область в хранилище данных проекты.

1