Доступ к данным для ETL для ежедневной нагрузки SQL Сервер

Question

Мне нужен ваш опыт в выяснении наилучшего возможного варианта хранения данных в базе данных перед их использованием в DWH / ETL или использования их непосредственно из источника и создания ETL.

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

Мы хотели бы автоматизировать процесс загрузки данных с этого LinkedServer в хранилище данных. Следуя опциям / задачам, у нас есть, где мы хотели бы, чтобы ваши мысли помогли нам!

Мы бы хотели, чтобы наш ETL запускался ежедневно ночью!

1. Храним ли мы данные сначала с Связанный сервер в SQL таблицах до того, как мы напишем несколько запросов с несколькими объединениями в эти таблицы, чтобы подготовить данные для загрузки в хранилище данных?
2. Если мы храним данные из LinkedServer в таблицах на SQL сервере, я предпочитаю вместо этого выполнить усечение и загрузку для дополнительной загрузки из OLTP в таблицы на SQL сервере (от 1 до 1) для всех этих таблиц, поскольку мы не можем получить дифференциальную нагрузку от транснациональной системы, и люди могут go вернуть и изменить данные в транзакционной системе и определение новых и обновленных записей может оказаться непростым делом.

ИЛИ

мы просто напрямую используем исходную систему через LinkedServer для написания нескольких объединений и подготовки данных на лету и загрузить в какой-то стол предварительной подготовки? (С этой опцией проблема, с которой мы сталкиваемся в настоящее время, заключается в том, что, когда мы пишем несколько соединений непосредственно на LinkedServer, мы получаем только 1 строку, независимо от общего количества результатов / строк, но если мы сохраняем все таблицы, используемые в этих запросах, объединяются в отдельную временную таблицу и запустив из него запрос, мы получим ожидаемые результаты) - Пожалуйста, дайте нам знать, если кто-то уже сталкивался с этой проблемой раньше и каково было ее решение?

Answer 1

Традиционный способ построения хранилища данных - следовать первому варианту.

1. Извлечение реплики данных из исходной системы.
2. Локальная обработка данных в промежуточных таблицах.
3. Помещение оптимизированных данных в уровень хранилища для потребления. .

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

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

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

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

Эффективное выявление различий

Только SSIS извлекает изменения Delta