Оптимизация производительности ODI.

Продолжаем начатый здесь перевод документа 423726.1 "What Are The Best Approaches For Performance Optimization Strategies For ODI Scenario Execution".

Оптимизация выполнения.

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

1. Правильное расположение агентов.
   Необходимо учесть следующие соображения при выборе места расположения:
   
   • Ограничения пропускной способности сети.
     При чтении больших объемов данных через JDBC, лучше всего устанавливать агент на сервере с данными; желательно, чтобы было локальное подключение к серверу, на который эти данные будут загружаться.
     
     • Инсталлируйте агента на сервере источнике данных, если большая часть данных будет выгружаться с этого сервера.
     • Инсталлируйте агента на стейдж/целевом сервере если основные преобразования будут выполняться на этих серверах.
     • При работе с большими файлами, лучше настроить копирование файлов (используя ftp, например) на тот сервер, на котором работает агент, до начала работы интеграционного интерфейса. Шаг копирования файла может быть встроен как в пакет выполнения сценария загрузки с помощью команд snpsFTP или odiFileCopy а также добавлен непосредственно в модуль знаний для использования во многих интерфейсах.
   • Ограничения производительности сервера.
     Если вы планируете использовать агента для перекачки потока данных между источником и приемником, то он должен быть проинсталлирован на сервере с достаточным количеством свободных ресурсов (память, ЦПУ)
     
     Вы можете менять параметры ODI_INIT_HEAP и ODI_MAX_HEAP в файле конфигурации ODI - "odiparams" для настройки начального и максимального значений объема памяти, выделяемой для JVM.
     
   • Настройки параметров Batch Update и Array Fetch для серверов.
   • Возможность использования родных для СУБД утилит для ускорения обработки данных.
     Устанавливайте агента на ту же машину, на которой работает СУБД, чтобы мочь воспользоваться утилитами СУБД.
     
     Типичный случай, когда правильное месторасположение агента очень важно, это использование утилиты OdiSqlUnload для выгрузки данных из источника и записи во временный файл, который позже будет загружен при помощи утилит СУБД в некую целевую БД.
     
     В таком случае лучше расположить агента на сервере источнике. Если он будет расположен на целевом сервере, то весь объем данных будет передаваться через сеть с использованием JDBC драйверов.
     
     Обратите внимание:
     - Агент является многопотоковым приложением.
     - Несколько агентов, слушающих разные TPC/IP порты могут быть запущены одновременно и работать в параллельном режиме на одном и том же сервере. Используйте один агент на один сервер только в случае, если сервер не является многопроцессорным/многопотоковым, так как каждый агент требует дополнительных ресурсов для своего выполнения.
2. Использование балансировки загрузки.
   ODI может быть настроен на режим использования нескольких агентов для балансировки нагрузки.
   
   Балансировка нагрузки это возможность достичь большей производительности за счет распределения задачи по выполнению сценариев на нескольких агентов. Если один агент имеет несколько подчиненных агентов, он автоматически распределяет сценарии, которые отдаются ему на выполнение, на подчиненных агентов.
   
   Использование нескольких агентов приводит к тому, что выполнение сценария делится на несколько частей, на создание сессии и ее выполнение. Если вы хотите, чтобы родительский агент не только распределял сессии, но и выполнял некоторые из них - просто сделайте его дочерним по отношению к самому себе.
   
3. Развертывание ODI 11g Java EE Агентов на Oracle WebLogic Server
   Начиная с Oracle Data Integrator 11g компоненты, входящие в ODI могут быть интегрированы в сервер приложений Oracle WebLogic Application Server (WLS) и получить в использование возможности этого сервера, в частности, балансировку нагрузки, используемую в WLS.
   
   Подробнее описано здесь, а также в руководстве по инсталляции ODI 11g (или по ссылке на сайте Oracle.)
   
4. Разработка высокоустойчивых конфигураций агентов ODI.
   Oracle Data Integrator (ODI) 11g включает полный набор компонентов для разработки, развертывания и управления процессами интеграции данных.
   
   Процесс интеграция данных - перемещение и преобразование данных из серверов источников в сервера приемники данных с использованием подхода Выгрузить-Загрузить-Преобразовать (ELT). Такой алгоритм не предполагает наличия отдельного приложения для преобразования данных, так как работа по трансформациям перекладывается на СУБД источник и/или приемник данных.
   
   Документ, указанный ниже, предоставляет описание компонентов ODI с точки зрения устойчивости к сбоям в работе интеграционных процессов и описывает принципы построения высокоустойчивых конфигураций ODI.
   Note 424105.1 "Настройка ODI агентов в режим высокой доступности".
   
5. Настройка уровня логирования.
   В среде промышленного выполнения устанавливайте уровень логирования в 1. Только сообщения об ошибках будут отображаться в Операторе.
   
   Для более полного описания смотри: Note 424557.1 "Уровни логирования процедур и модулей знаний и ODI Оператор".
   

Решение проблем производительности ODI.

Прим. перев.: ниже речь идет именно о тех аспектах, на производительность которых непосредственно влияет ODI как Java приложение. Предполагается, что уже используются правильные алгоритмы загрузки и обработки данных.

Решение такого типа проблем начинаются с двух основных шагов:

1. Найти в Операторе ODI тот шаг или задачу, которая занимает максимальное время.
2. Скопировать код и запустить его прямо на СУБД. Это позволит сравнить два времени выполнения.

1. Сложный SQL запрос с построчной обработкой данных.
Как правило, проблемы с производительностью появляются при использовании процедурных языков в БД (PL/SQL, Transact SQL), которые обрабатывают данные в построчном режиме.

Старайтесь, по возможности, избегать таких процедур, используя вместо этого интерфейсы, или, если это невозможно (например, при обработке Long или LOB объектов), попросите DBA выполнить оптимизацию этого кода.

2. Несовместимость между JVM и версией JDBC драйверов.
ODI совместим с разными версиями Java и JDBC драйверов.

Использование JDBC драйверов несовместимых с версией JVM или несовместимых с СУБД может привести к проблемам с производительностью.

Например, некий интерфейс, который загружает таблицу большого объема из Microsoft SQL Server 2005 в таблицу Oracle 11g. Иногда скорость выполнения приемлема, в других случаях скорость очень низка, и шаг "Load data" занимает большую часть времени. Так получается потому, что существуют JDBC драйвера для Microsoft SQLServer 2005 и Oracle которые:

• Не совместимы с JVM используемой для запуска пакета ODI для загрузки.
• Не совместимы (устарели) с СУБД, содержащей данные.

Не забывайте, что не рекомендуется использовать:

• Версию 1.2 JDBC драйверов для Microsoft SQLServer 2005 с JVM 1.5 или более поздней.
• JDBC драйвера для Oracle "ojdbc14.jar" с JVM 1.5 или более поздней.
• JDBC драйвера для версии Oracle 10.x не подходят для Oracle 11g

Матрица совместимости между версиями Java Virtual Machine и JDBC драйверами доступна на металинке по ссылке: Note 807235.1 "Матрица совместимости для Java и JDBC драйверов используемых в ODI".