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

Ответ 1

Ниже точки взяты из статьи DWBI Organization

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

• Delta Loading. Ваши данные считываются постепенно из источника, и вам нужно промежуточное хранилище, где инкрементный набор ваших данных может временно храниться для целей преобразования.
• Необходимость преобразования: вам необходимо выполнить очистку данных, проверку и т.д., прежде чем использовать данные на складе.
• Декомпозиция. Ваша обработка занимает много времени, и вы не хотите оставаться подключенным к вашей исходной системе (предположительно, система-источник постоянно используется фактическими бизнес-пользователями) в течение всего время обработки и, следовательно, предпочитают просто читать данные из исходной системы в режиме "один", отключать от источника, а затем продолжать обработку данных со своей "стороны".
• Цель отладки. Вам не нужно постоянно возвращаться к исходному коду и вы можете устранить проблемы (если есть) только из промежуточной области.
• Восстановление отказа. Исходная система может быть временной и состояние данных может меняться. Если вы столкнулись с каким-либо сбоем восходящего потока, вы не сможете повторно извлекать ваши данные, поскольку исходный код изменился к тому времени. Наличие локальной копии помогает

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

Ответ 2

ETL = Извлечь, Трансформация и Загрузить. Поддержка базы данных с битом Transform. Лично я всегда включаю шаг промежуточного DB и ETL.

База данных Staging помогает получить ваши исходные данные в структуры, эквивалентные вашим местам хранения данных FACT и DIMENSION. Он также отделяет ваш склад и склад ETL от ваших исходных данных.

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

• В конечном итоге привязка вашего хранилища данных прямо к вашему исходная база данных.
• Скорее всего, с очень сложным шагом ETL
• Может закончиться гоночными условиями/сиротскими записями из-за изменения в исходной базе данных во время процесса ETL
• Данные Складские люди могут создавать звуки типа "hrumph".

Скорее всего, вы будете выполнять какое-то манипулирование данными (преобразование дат в ключи 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 будет усекать и заполнять этап, так что БД STAGING содержит все новые/обновленные записи, которые идут на склад.

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

Ответ 3

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

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

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

Ответ 4

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

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