ETL Processing Design and Performance

Question

Я работаю над процессом ETL для хранилища данных с использованием C #, который поддерживает как SQL Server, так и Oracle.Во время разработки я писал хранимые процедуры, которые синхронизировали бы данные из одной базы данных в другую базу данных.Код хранимых процедур довольно уродлив, потому что он включает в себя динамический SQL.Необходимо построить строки SQL, поскольку у нас есть динамическое имя базы данных.

Мой руководитель группы хочет использовать код C # для создания ETL.У нас есть генерация кода, которая автоматически генерирует новые классы при изменении определения базы данных.Вот почему я решил не использовать Rhino ETL.

Вот плюсы и минусы:

Хранимая процедура:

Плюсы:

• быстрая загрузка, все обрабатывается базой данных
• простота развертывания, компиляция не требуется

Минусы

• плохая читаемость из-за динамического SQL
• Необходимо поддерживать как T-SQL, так и PL / SQL-скрипты при изменении определения базы данных
• Медленная разработка, поскольку нет смысла при написании динамического SQL

C # Код:

Плюсы:

• проще в разработке процесса ETL, потому что мы получаем intellisense из нашего сгенерированного класса
• , проще в обслуживании, потому что сгенерированный класс
• улучшает ведение журнала иобработка ошибок

Минусы:

• низкая производительность по сравнению с хранимой процедурой

Я бы предпочел использовать код приложения для выполнения процесса ETL,но производительность была ужасна по сравнению с сохраненным профессионаломцедуры.В одном тесте, когда я пытаюсь обновить 10000 строк.Хранимые процедуры заняли всего 1 секунду, а мой код ETL - 70 секунд.Даже если мне удастся как-то сократить накладные расходы, 20% из 70-х просто вызывают оператор обновления из кода приложения.

Может ли кто-нибудь предоставить мне предложения или комментарии о том, как ускорить процесс ETL с помощью кода приложения?

Моя следующая идея - попытаться выполнить параллельный процесс ETL, открыв несколько соединений с базой данных, выполнить обновление и вставить.

Спасибо

Answer 1

Если ваш код C # уже медленный с 10 000 строк, я не могу представить его в реальном окружении ...

Большинство ETL выполняются либо внутри базы данных ( хранимые процедуры , пакетыили даже скомпилирован в базе данных (PL / SQL, Java для Oracle)).Они могут обрабатывать миллионы строк.

Или могут использоваться некоторые профессиональные инструменты (Informatica или другие), но они все равно будут работать медленнее, чем хранимые процедуры, но проще в управлении.

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

Кроме того, если вам приходится работать с различными типами баз данных ( SQL Server , Oracle), вы НЕ МОЖЕТЕ создать универсальное приложение и одновременно оптимизировать его, это выбор.Поскольку Oracle работает не так, как SQL Server.

Чтобы дать вам представление, в ETL для Oracle используются подсказки (например, подсказки параллельного выполнения), а также могут быть удалены некоторые индексы или отключена целостность.временно оптимизировать ETL.

Я не знаю, как можно точно сказать, что в SQL Server (у них могут быть похожие параметры, но другой синтаксис).Так что «один ETL для всех баз данных» вряд ли можно сделать без потери эффективности и скорости.

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

Answer 2

Вы говорите, что у вас есть генерация кода, которая автоматически генерирует новые классы - почему у вас нет генерации кода, которая автоматически генерирует новые хранимые процедуры?

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

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

Answer 3

Возможно, вы захотите настроить приложение.

Несколько моих хитростей:

• Не используйте connection.Open () и conenction.Close () слишком много.
• В некоторых случаях LINQ будет замедлять процесс
• Используйте процедуру и передайте больше параметров при загрузке, чтобы уменьшить количество вызовов, например, proc_load_to_table(p1 text) изменить на proc_load_to_table(p1 text, p2 text, p3 text, p4 tex, p5 text)