DeepEdit!

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

Область применения:

Oracle Data Integrator - начиная с версии 3.2.03.01...

Информация в этом документе применима к любым платформам.

Цель:

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

Причины высокопроизводительной работы ETL проектов, построенных с использованием Oracle Data Integrator (ODI) заключаются в архитектуре (принципы E-LT - выгрузка, загрузка, преобразование), использовании родных для задействованных СУБД особенностей SQL кода, родных загрузчиков и доступных в этих СУБД сложных операций по трансформации данных. Тем не менее могут возникнуть ситуации, когда будет необходимо улучшить производительность ODI.

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

Оптимизация интерфейсов.

Уменьшение объема пересылаемых между серверами данных.

Правильное определение местоположения области стейджа.

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

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

Правильное указание места выполнение трансформаций - соединений, фильтров, маппингов.

Место выполнения преобразований (источник, область стейджа, целевая БД) обычно выбираются исходя из возможностей используемых вами СУБД, но также следует принимать во внимание объем передаваемых данных.

Например, исходя из следующих соображений:

- При фильтрации данных источника, рекомендуется местом применения фильтра указывать сервер источник, чтобы уменьшить объем передаваемых данных из источника в область стейджа.

- При соединении таблиц источников, если ожидаемый объем соединения меньше, чем суммарный объем всех источников, то соединение следует делать на источнике. Если же объем соединенных данных больше, чем суммарный объем источников, тогда это соединение должно выполняться в промежуточной области (стейдж), например, в случае кросс джоинов.

Это также применимо и при агрегациях, выполняемых на источнике, для уменьшения объема передаваемых на стейдж данных.

Использование журнализации или возможностей CDC

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

ODI предоставляет два метода отслеживания, один основан на использовании триггеров, второй на чтении логов СУБД.

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

Ускорение передачи данных путем выбора наилучших методов загрузки. Методы, используемые для передачи набора данных с одного сервера на другой полностью определяются выбранным для источника загрузочным модулем знаний (LKM). ODI использует три основных подхода для передачи данных с сервера на сервер:

Передача данных через Агента.

Передача данных с использованием загрузчиков.

Специфические методы.

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

Передача данных через Агента.

Передача потока данных через агента означает что агент занимается чтением пакета данных через соединение с источником (обычно через JDBC драйвер) и записью этого пакета данных в целевую БД.

Следующие параметры помогут настроить параметры этого потока:

- Array Fetch параметр для сервера источника данных.

Определяет размер пакета (количество записей), который будет прочитан за одну операцию чтения из источника и сохранен в памяти агента.

- Batch Update параметр для сервера приемника данных.

Определяет размер пакета (количество записей), записываемых за один раз в целевую БД.

Обратите внимание, что Array Fetch и Batch Update это параметры Java. Для более детального описания смотрите Note 424482.1 "Как влияют значения параметров Array Fetch и Batch Update на производительность процессов ODI?"

Установка значений для параметров Array Fetch/Batch Update должна учитывать следующие соображения:

- Большее значение параметра позволит передать то же количество строк меньшим количеством пакетов, что снизит нагрузку на сетевое взаимодействие.

- Выбранные значения Array Fetch/Batch Update это компромис между нагрузкой на агента и нагрузкой на сеть. В случае достаточно быстрой сети можно оставить небольшое значение этих параметров (меньше 30, например). В случае же медленной сети, вы можете использовать значения побольше (100 и больше).

Типичные значения для параметров Array Fetch и Batch Update от 30 до 500.

Для подбора значений Array Fetch и Batch Update для систем источников и приемников данных рекомендуется изменять значения этих параметров с шагом в 10 за одно изменение, а затем проводить измерения производительности.

Передача данных с использованием загрузчиков.

Когда для загрузки данных используются утилиты разработчиков СУБД, агент делегирует свою работу внешним загрузчикам, таким как Oracle SQL*Loader, Microsoft SQLServer BCP, Teradata Fastload/Multiload и т.п.

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

Вызов утилит выгрузки/загрузки предполагает, что эти утилиты будут проинсталлированы на той же машине, на которой выполняется агент. С другой стороны есть возможность использовать для выгрузки данных встроенную утилиту ODI - OdiSQLUnload.

Утилиты загрузки/выгрузки обычно показывают наилучшую производительность в процессах извлечения-добавления сверхбольших объемов данных в/из БД.

Модуль знаний, использующий такие загрузчики, обычно учитывает особенности конкретной утилиты и настраивает загрузчик на оптимальную производительность.

Примечание: утилита OdiSQLUnload обеспечивает наилучшую производительность если выгружает только одну колонку. Соответственно, при использовании OdiSQLUnload наилучшим подходом будет конкатенация нескольких колонок в одну колонку с разделителями, выполняться такая операция должна средствами СУБД

Специфические методы.

Специфические для разных СУБД методы, включая:

- Межсерверное взаимодействие, организованное по принципам Oracle Database links (используя OCI) или Microsoft SQLServer Linked Servers.

- Автоматическое преобразование файл - таблица, как в механизме Oracle External Tables

- Создание AS/400 DDM файлов и загрузка их при помощи команды CPYF.

- Использование загрузчиков совместно с механизмом перенаправления ввода-вывода (UNIX pipes) чтобы не создавать очень большие файлы с данными.

На выбор стратегии загрузки влияют технические ограничения:

Можно ли создать временные файлы на диске?

Есть ли право на запуск загрузчиков на машине, на которой выполняется агент?

Разрешит ли DBA создавать ДБ линки?

Есть ли возможность использования перенаправления ввода-вывода?

Какова пропускная способность сети?

Как много памяти/процессора может быть задейстовано для агента?

Рекомендации в этом случае стандартны - для получения наилучшей производительности использовать специфические для платформ модули знаний, позволяющие задействовать родные для технологий инструменты и достичь приемлемой скорости как выгрузки данных из источника, так и загрузки на приемник. Например, использование подхода передачи данных через агента (и соответствующего модуля знаний SQL-SQL) для передачи данных из Oracle в Oracle не выглядит хорошей идей, так как использование DBLINK-ов или SQL*Loader в несколько раз производительней.

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

Оптимальное соединение больших источников данных. Соединения - второе наиболее затратное по времени выполнения действие в интеграции данных. У разных серверов разные возможности по выполнению соединений. Критическим является размещение операций соединения на том сервере, где для этого достаточно ресурсов (память, процессор и т.п.) Таким образом, размещение области стейджа на сервере с доступным процессорным временем и выполнение операций соединения в области стейджа является наилучшей практикой. Так как ODI генерирует SQL для каждого соединения, участвующего в преобразованиях, анализ планов выполнения этих кодов на участвующих СУБД поможет оптимизировать скорость выполнение интерфейса. Так же нужно понимать, что соединения могут замещать другие типы обработок записей и увеличивать, в итоге, производительность. Например, фильтр

TABLE1.COLUMN1 in (SELECT COLUMN2 from getObjectName(TABLE2))

Может быть замещен соединением этих двух таблиц:

TABLE1.COLUMN1 и TABLE2.COLUMN2

Подходы к интеграции данных. Главное - избегать ненужных соединений и использовать оптимальный набор шагов интеграции. Количество операций в интеграционном модуле знаний (IKM) напрямую зависит от сложности выбранного метода интеграции. Рекомендуется избегать использования сложных модулей знаний при интеграции больших массивов данных. Типичные примеры неправильных подходов:

Использование модуля знаний с инкрементальным добавлением строк и включенными опциями DELETE TARGET и INSERT. Более правильное использование опций инкрементального модуля знаний позволит иметь тот же результат с точки зрения набора данных и более высокую производительность.

Включение в интерфейсе опции DISTINCT когда дубликаты не могут возникнуть или могут возникнуть лишь вследствие ошибок разработки. Операция поиска уникальных значений является очень ресурсоемкой для СУБД.

Подходы к проверке целостности данных. Ускоряйте загрузку данных в целевую таблицу путем исключения ненужных проверок целостности. Количество условий (constraints) проверяемых в модуле знаний (CKM) добавляет в процесс выполнения дополнительные операции, что приводит к общему снижению скорости ETL преобразований. Рекомендуется избегать ненужных проверок при работе с большими массивами данных. Включайте опцию Flow Control только если это является обязательным требованием, так как выполнение проверок оказывает существенное влияние на производительность. Пример лишних операций:

Проверка одних и тех же по сути данных несколько раз на разных этапах преобразований.

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

В продолжении перевода данного документа советы по настройке агентов, отказоустойчивости и совместимости драйверов: