Преобразование реляционной базы данных OLTP в модель хранилища данных

Question

Какие общие подходы к проектированию используются при загрузке данных из типичной модели базы данных Entity-Relationship OLTP в модель Data Warehouse / Marts со звездообразной схемой Kimball?

• Используете ли вы промежуточную зону для преобразования, а затем загрузки на склад?
• Как связать данные между хранилищем и базой данных OLTP?
• Где / как вы управляете процессом преобразования - в базе данных в виде sprocs, пакетов dts / ssis или SQL из кода приложения?

Answer 1

Лично я работаю следующим образом:

1. Сначала спроектируйте хранилище данных. В частности, проектируйте таблицы, которые необходимы как часть DW, игнорируя любые промежуточные таблицы.
2. Разработайте ETL, используя SSIS, но иногда с SSIS, вызывающим хранимые процедуры в задействованных базах данных.
3. Если какие-либо промежуточные таблицы требуются как часть ETL, хорошо, но в то же время убедитесь, что они очищены. Промежуточная таблица, используемая только как часть одной серии шагов ETL, должна быть усечена после того, как эти шаги будут выполнены, с успехом или без успеха.
4. У меня есть пакеты SSIS, которые ссылаются на базу данных OLTP, по крайней мере, для извлечения данных в промежуточные таблицы. В зависимости от ситуации они могут обрабатывать таблицы OLTP непосредственно в хранилище данных. Все такие запросы выполняются с (NOLOCK).
5. Документ, Документ, Документ. Дайте понять, какие входы используются каждым пакетом и куда идут выходные данные. Обязательно задокументируйте критерии, по которым выбираются входные данные (последние 24 часа? С момента последнего успеха? Новые значения идентификаторов? Все строки?)

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

Answer 2

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

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

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

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

Answer 3

Я согласен с высоко оцененным ответом, но решил добавить следующее:

<цитата> родовое слово

загрузить на склад?

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

<цитата> родовое слово

Полезно загрузить бизнес-ключи (или фактические первичные ключи, если они доступны) в хранилище данных в качестве ссылки на систему OLTP. Кроме того, аудит в процессе DW должен записывать происхождение каждого бита данных путем записи процесса загрузки, который его загрузил.

<цитата> родовое слово

база данных как sprocs, пакеты dts / ssis, или SQL из кода приложения?

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

Answer 4

Объяснение процесса Джона Сондерса хорошее.

Если вы хотите реализовать проект Datawarehouse на SQL Server, вы найдете всю информацию, необходимую для реализации всего проекта, в превосходном тексте " Набор инструментов Microsoft Data Warehouse " ;.

Как ни странно, одним из авторов является Ральф Кимбалл :-)

Answer 5

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