Динамичная архитектура интеграции данных с использованием WebSphere DataStage и сервера интеграции WebSphere Federation Server

Введение в архитектуру T-ETL

Объедините WebSphere® DataStage и WebSphere Federation Server для создания эффективной и динамичной архитектуры перемещения и преобразования данных. В статье рекламируется использование сервера интеграции WebSphere Federation Server в качестве модуля предварительной обработки данных для DataStage и демонстрируются ситуации, в которых такая комбинация сокращает время выполнения (приблизительно на 91 процент) и суммарное потребление ресурсов заданием. Автор не предлагает использовать комбинацию сервера интеграции Federation Server и DataStage для всех сценариев консолидации данных, скорее, в ней делается попытка описания тех ситуаций, в которых эта комбинация оказывается наиболее эффективной.

Сьюзен Энглерт , старший инженер-программист, IBM

Сьюзен Энглерт (Susanne Englert) работает в группе производительности Websphere Federation Server; данным продуктом она занимается с 2001 года. Все это время Сьюзен увлеченно работает в области производительности баз данных, уделяя особое внимание вопросам оптимизации запросов, параллельной обработки запросов, объединенных запросов и практическому применению продуктов клиентами. Сьюзен окончила университет в г. Бонне; ранее она была председателем подкомитета TPC по разработке тестов на содействие принятию решений (Decision Support benchmark development).



Саймон Харрис, старший инженер-программист, IBM

Саймон Харрис (Simon Harris) - инженер по производительности в лаборатории IBM в Силиконовой Долине, группа по разработке программы WebSphere Federation Server. Саймон занимается технологией интегрированных баз данных с момента своего прихода в IBM в 1995 году, за это время он оказал техническую поддержку многим клиентам в странах Европы, Среднего Востока и Африки в рамках предпродажного и послепродажного сопровождения программных продуктов.



21.06.2007

Введение

Многие производители на рынке традиционных технологий консолидации данных позиционируют свои программные продукты как инструменты "извлечения, преобразования, загрузки" (Extract-Transform-Load, ETL), "извлечения, загрузки, преобразования" (Extract-Load-Transform, ELT), а может быть даже и "преобразования, извлечения, загрузки" (Transform-Extract-Load, TEL). Естественно, каждый производитель превозносит сильные стороны выбранного им принципа и указывает на слабые стороны подхода своих конкурентов.

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

WebSphere DataStage - это подлинно гибкий инструмент консолидации данных, обладающий встроенными механизмами поддержки топологии ETL, ELT и TEL. В этой статье демонстрируется, как сочетание продуктов WebSphere DataStage и WebSphere Federation Server может расширить применяемый набор сокращений благодаря эффективной поддержке топологий консолидации данных "преобразование, извлечение, преобразование, загрузка" (Transform-Extract-Transform-Load, T-ETL). В рамках топологии T-ETL продукты WebSphere DataStage и WebSphere Federation Server дополняют друг друга особым образом, который позволяет добиться существенного выигрыша в производительности и экономии ресурсов ЦПУ по сравнению с использованием только WebSphere DataStage. В этой ситуации сервер интеграции WebSphere Federation Server способен осуществлять обработку близко к входным источникам, чтобы на стадию извлечения передавалось меньшее количество данных, а WebSphere DataStage нужно было выполнять меньше преобразований. Преимущество достигается за счет того, что архитектура T-ETL использует исключительно сильные стороны этих двух продуктов: оптимизатор стоимости и обеспечение эффективности обработки в неоднородном окружении WebSphere Federation Server и эффективный механизм параллельного преобразования и потоков данных WebSphere DataStage .

В следующем разделе данной статьи, до перехода к подробному описанию архитектуры T-ETL, приводится краткое введение в программу WebSphere Federation Server. Далее в разделах, посвященных конкретным сценариям использования, подробно описываются четыре различных ситуации, подчеркивающие преимущества T-ETL. Затем мы обобщаем характерные признаки таких заданий WebSphere DataStage, которые, вероятнее всего, окажутся в выигрыше от использования подобной архитектуры.

Сервер интеграции WebSphere Federation Server

Сервер интеграции WebSphere Federation Server поддерживает развивающуюся отраслевую категорию "Интеграция корпоративной информации" (Enterprise Information Integration, EII). Он позволяет приложениям обращаться к неоднородным данным и источникам контента и интегрировать их таким образом, как будто это единый ресурс, независимо от того, где размещена информация, сохраняя автономность и целостность систем-источников.

Лежащий в основе этой технологии принцип интеграции с точки зрения пользователей означает возможность видеть все используемые ими данные так, как если бы они были размещены в едином источнике. Представляя этот единый образ источника, технология интеграции защищает пользователя, выполняющего запрос, от всех сложностей, связанных с доступом к данным, хранящимся в различных местах, в том числе, сложностей подключения, семантики, форматов и методов доступа. Промежуточное ПО позволяет пользователям или приложениям, действующим от их имени, прозрачно обращаться к информации, не задумываясь о ее физической реализации. Следовательно, сервер интеграции WebSphere Federation Server аккуратно и прозрачно располагается за обычными аналитическими инструментами и инструментами создания отчетов, средами разработки, порталами и другими стандартными компонентами инфраструктуры IT.

С помощью сервера интеграции WebSphere Federation Server можно посылать распределенные запросы к нескольким источникам данных в пределах одной инструкции SQL; например, в одной инструкции SQL можно соединить данные, размещенные в таблице DB2 , таблице Oracle и структурированном файле XML. Когда приложение передает запрос интегрированной системе, сервер интеграции выявляет релевантные источники данных и создает план выполнения запроса для получения запрашиваемых данных. Этот план обычно разбивает исходный запрос на фрагменты, которые представляют собой задания для передачи отдельным источникам данных, а также задания по дополнительной обработке, которые должны быть выполнены интегрированным сервером для дальнейшей фильтрации, агрегации или слияния данных. Благодаря возможности дальнейшей обработки интегрированным сервером данных, полученных от источников, приложения могут в полной мере использовать язык запросов, даже если часть запрашиваемой информации происходит из источников данных с недостаточной или не встроенной возможностью обработки запросов, например, из простых текстовых файлов. Кроме управления интеграцией, сервер интеграции представляет собой также полнофункциональную реляционную базу данных с возможностью хранения и управления локальными данными.

Итак, эффективность сервера интеграции WebSphere Federation Server обеспечивается возможностью:

  • Сопоставлять данные из локальных таблиц и удаленных источников данных, как будто все данные хранятся локально в интегрированной базе данных;
  • Обновлять данные в реляционных источниках данных, как будто все данные хранятся в интегрированной базе данных;
  • Использовать преимущества обработки источников данных и уникальные возможности оптимизации посредством отправки распределенных запросов для обработки источникам данных;
  • Компенсировать ограничения SQL в источниках данных, обрабатывая части распределенного запроса на сервере интеграции.

Интеграционный подход к получению EII дополняется более традиционным методом консолидации данных. Консолидированные хранилища данных, которые обычно используются для извлечения, преобразования, загрузки (ETL) или репликации данных, сегодня являются стандартным вариантом интеграции информации. Они стали лучшим способом достижения быстрого, отличающегося высокой доступностью и интегрированного доступа к связанной информации. Создание всего одной физической копии позволяет предприятиям соответствовать требованиям производительности и доступности, получать моментальные снимки, являющиеся целостными на данный момент времени, и осуществлять сложные преобразования для достижения семантической целостности.

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

Архитектура T-ETL с использованием WebSphere DataStage и WebSphere Federation Server

В данной статье речь идет, главным образом, о преимуществах использования сочетания продуктов WebSphere DataStage и WebSphere Federation Server для консолидации данных. Мы предлагаем использовать сервер интеграции WebSphere Federation Server в качестве модуля предварительной обработки данных для WebSphere DataStage, выполняющего, главным образом, первоначальное преобразование данных либо до, либо в момент извлечения данных из одного или более источников. Предлагаемая архитектура T-ETL используется для объединения, агрегации и фильтрации данных до их поступления в WebSphere DataStage, при этом WebSphere DataStage использует параллельный механизм для выполнения более сложных преобразований и обслуживания получателя данных. Предлагаемая архитектура показана на рисунке 1:

Рисунок 1. Архитектура T-ETL с использованием WebSphere Federation Server и WebSphere DataStage
Архитектура T-ETL с использованием Federation Server и DataStage

Эта архитектура для создания высокоэффективного решения для консолидации данных использует сильные стороны обоих продуктов: возможности соединения и обработки SQL WebSphere Federation Server и параллельные потоки данных и эффективную логику преобразований WebSphere DataStage. Кроме того, оптимизатор затрат сервера интеграции WebSphere Federation Server позволяет архитектуре T- ETL динамично реагировать на изменения в объемах и шаблонах данных, не изменяя задание.

T-ETL не является новой концепцией, и многие задания ETL и сейчас могут использовать некоторые формы преобразований при извлечении данных -- например, фильтрацию или агрегацию данных или выполнение объединения между двумя исходными таблицами, которые размещаются в одной исходной базе данных. Однако то, что исходные объекты должны существовать в одном и том же источнике данных, до последнего времени существенно ограничивало область применения решений T-ETL. Сервер интеграции WebSphere Federation Server устраняет это ограничение и позволяет расширить фазу начальных преобразований на неоднородные источники данных, поддерживаемые WebSphere Federation Server. Например, WebSphere Federation Server допускает использование T-ETL в том случае, когда источники данных - таблица Oracle, таблица Teradata и "плоский" файл. Кроме расширения области применения этапа начальной трансформации данных, интеграция способствует повышению эффективности этого этапа, поскольку в ее основе лежит механизм реляционной базы данных с 30-летней историей разработки эффективной фильтрации и объединений наборов данных.

Примеры использования, подчеркивающие эффективность T-ETL

Следующие четыре сценария использования разработаны для демонстрации потенциальных преимуществ, которые может дать использование WebSphere DataStage и WebSphere Federation Server при консолидации данных. В каждом примере сначала показан сценарий консолидации данных с помощью задания WebSphere DataStage, при дальнейшем рассмотрении демонстрируется, как можно использовать WebSphere Federation Server в сочетании с WebSphere DataStage для сокращения времени выполнения и потребления ресурсов. Кроме того, описывается, как можно изменить исходное задание WebSphere DataStage, чтобы при его выполнении использовались функции сервера интеграции WebSphere Federation Server. В конце раздела приводятся характерные признаки, которыми должны обладать задания WebSphere DataStage, чтобы такая оптимизация оказалась выгодной.

На рисунке 2 показана программная конфигурация, которая использовалась для тестирования сценариев использования.

Рисунок 2. Конфигурация для тестирования сценариев использования
Конфигурация для тестирования сценариев использования

В зависимости от конфигурации задания, данные поступают из нескольких различных UNIX систем. Аналогично, получатель может располагаться на одной или более UNIX -системах. Этап DB2 UDB API WebSphere DataStage используется для доступа к исходным базам DB2, целевым базам данных и серверу интеграции WebSphere Federation Server. Все исходные и целевые базы данных не секционированы. Информационный сервер IBM Information Server (который включает продукты WebSphere DataStage Enterprise Edition V8.0 и WebSphere Federation Server V9.0) установлен на двухпроцессорном компьютере под управлением ОС Windows Server 2003. Каждое задание в любом из четырех сценариев использования - это параллельное задание, разработанное с целью максимального использования возможностей параллельной обработки WebSphere DataStage. Поскольку на сервере WebSphere DataStage два ЦПУ, используемая степень параллелизма также равна 2.

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

  • Таблица CUSTOMER содержит одну строку для каждого неповторяющегося ключа клиента. Каждая строка содержит (наряду с другой информацией) имя и остаток на счете этого клиента, а также название сегмента рынка, к которому он принадлежит;
  • Таблица ORDERS содержит одну строку для каждого неповторяющегося ключа заказа. Каждая строка также содержит ключ клиента, разместившего заказ, общую стоимость заказа, дату размещения заказа и код приоритетности выполнения. Обычно каждому клиенту соответствует несколько заказов в базе данных, но у некоторых клиентов либо совсем нет заказов, либо они не размещали заказы в течение длительного промежутка времени;
  • Таблица LINEITEM содержит одну строку для каждой позиции, являющейся частью заказа. Каждая строка содержит ключ заказа, к которому она относится. Обычно заказ содержит несколько позиций. Строка каждой позиции ссылается на ключ определенной запчасти и включает заказанное количество, дату отправки запчастей и используемый метод доставки;
  • Таблица STOCK связывает ключи запчастей и ключи поставщиков, а также хранит записи о количестве запчастей, полученных от каждого поставщика.

Пример 1: Несколько неоднородных источников

Задача (task) ProjectedBalance вычисляет текущий остаток на счетах клиентов, исходя из последней записи об остатке в таблице CUSTOMER и совокупной стоимости заказов, которые они разместили за последние 30 дней (по записям в таблице ORDERS). Имена клиентов и их расчетный остаток вносятся в список, причем вывод сортируется по убыванию суммы долга. Информация о клиентах и информация о транзакциях по заказам хранятся в разных базах данных, что сегодня типично для многих организаций.

Рассмотрим следующее задание (job) WebSphere DataStage, осуществляющее расчет ProjectedBalance :

Рисунок 3. Задание ProjectedBalance WebSphere DataStage
ProjectedBalance DataStage job

Задание ProjectedBalance, показанное на рисунке 3, извлекает информацию о заказах за последний месяц из таблицы ORDERS и вычисляет их совокупную стоимость для каждого ключа клиента. Затем эта информация объединяется с таблицей CUSTOMER для извлечения имени, адреса и текущего остатка на счету каждого клиента. Расчетный остаток высчитывается суммированием текущего остатка на счету клиента и совокупной стоимости заказов, размещенных им в течение последнего месяца. В завершение перед созданием плоского выходного файла выполняется вставка этих записей (примерно 70 000) в таблицу ProjectedBalance или сортировка (чтобы клиенты с наибольшей суммой долга отображались в верхней части отчета).

Задание WebSphere DataStage, показанное на рисунке 3, использует обычный процесс ETL, чтобы получить нужный результат в структурированном виде. Однако в этом конкретном случае (и других аналогичных случаях), можно получить тот же результат более эффективным способом, если использовать комбинацию WebSphere Federation Server и WebSphere DataStage и немного изменить задание. Используя сервер интеграции WebSphere Federation Server в качестве модуля предварительной обработки данных для WebSphere DataStage, и переложив часть функций задания WebSphere DataStage на механизм интегрированной базы данных, можно существенно сократить затраченное время и общее время использования процессора этим заданием.

Рассмотрим следующее эквивалентное предыдущему задание ProjectedBalance DataStage:

Рисунок 4. Задание ProjectedBalance WebSphere DataStage с использованием интеграции
Задание ProjectedBalance DataStage с использованием интеграции

Показанное на рисунке 4 задание достигает того же результата, что и исходное задание ProjectedBalance, показанное на рисунке 3, но объединение между таблицами CUSTOMER и ORDERS, а также агрегирование общей стоимости заказов сжаты в один этап (stage) (Join_CustOrds) и переданы серверу интеграции WebSphere Federation Server, который может обработать их с большей эффективностью. Остальные этапы выполнения задания не изменились.

Для передачи операции объединения серверу интеграции WebSphere Federation Server этапы Orders, AggOrdersByCustomer, Customer и Join_CustOrds были записаны в виде инструкций SQL, выполняющих эквивалентные функции. Для индивидуального выполнения каждого этапа и разбиения SQL на отдельные компоненты можно использовать общие табличные выражения SQL (Common Table Expressions, CTE), которые упрощают написание и понимание инструкций. Например, код SQL, показанный на рисунке 5, с помощью CTE делится на четыре управляемых фрагмента -- каждый фрагмент является прямым эквивалентом одной из четырех фаз WebSphere DataStage, которую он заменяет. Фактически, выражения CTE Customer и Orders используют точно такой же код SQL, что и фазы исходного задания CUSTOMER и ORDERS. Такое использование выражений CTE значительно упрощает процесс перевода этапов WebSphere DataStage в термины SQL, поскольку позволяет разработчику работать с транзакцией по частям, рассматривая каждый этап индивидуально.

Рисунок 5. Код SQL, переданный серверу интеграции WebSphere Federation Server для задания ProjectedBalance
Код SQL, переданный серверу интеграции WebSphere Federation Server для задания ProjectedBalance

После выполнения задания ProjectedBalance, показанного на рисунке 4, этап Join_CustOrds устанавливает соединение с интегрированной базой данных, а код SQL этого этапа передается серверу интеграции WebSphere Federation Server. Сервер интеграции WebSphere Federation Server с помощью оптимизатора стоимости определяет наиболее эффективный метод соединения данных. От выбора оптимального плана выполнения, а также от эффективности обработки наборов данных полнофункциональным реляционным механизмом базы данных DB2 во многом зависит экономия времени и ресурсов ЦПУ. После того как код SQL этапа Join_CustOrds будет обработан интегрированной базой данных, данные переходят к WebSphere DataStage, и выполнение задания продолжается. Еще один существенный выигрыш в производительности обусловливается тем, что начальное объединение, выполняемое сервером интеграции WebSphere Federation Server, является "понижающим", то есть, на его выходе получается гораздо меньше данных, чем было считано из источников. Это означает, что WebSphere DataStage в комбинированной реализации с WebSphere Federation Server считывает меньше данных (70 663 строк), чем первоначальная реализация (2,4 миллиона + 77 636 строк).

Псевдонимы

Поскольку WebSphere Federation Server используется для объединения данных Oracle и DB2, то таблицы SIMON.CUSTOMER и SIMON.ORDERS на рисунке 5 на самом деле ссылаются на псевдонимы, определенные в интегрированной базе данных. В свою очередь, псевдонимы указывают на таблицы в источниках данных.

При использовании сервера интеграции WebSphere Federation Server для выполнения определенной предварительной обработки данных до того, как они поступят в WebSphere DataStage, эффективно используется принцип T- ETL, подчеркивающий гибкость сочетания WebSphere DataStage и WebSphere Federation Server.

Время выполнения исходного задания ProjectedBalance, показанного на рисунке 3, составило 204 секунды. Задание T-ETL, показанное на рисунке 4, было выполнено всего за 127 секунд -- общая экономия времени составила 38 процентов. Использование ресурсов ЦПУ для компьютера с установленными WebSphere DataStage и WebSphere Federation Server также показывает аналогичную экономию без заметного увеличения потребления ресурсов ЦПУ на источниках данных. Следовательно, в этом конкретном случае, после того как комбинация продуктов WebSphere DataStage и WebSphere Federation Server заменила WebSphere DataStage, затраченное время и потребление ресурсов ЦПУ заданием было снижено на 38 процентов.

Пример 2: Типичный сценарий ELT

Задача OrderPriority генерирует список незавершенных заказов, размещенных клиентами из сегмента рынка "Строительство". Список упорядочивается по неполученной выручке за ожидающие оплаты товары в заказе и дате размещения заказа. На рисунке 6 показана реализация задачи OrderPriority в WebSphere DataStage.

Рисунок 6. Задание WebSphere DataStage OrderPriority
Задание DataStage OrderPriority job

Сначала задание OrderPriority извлекает ключи тех клиентов, которые принадлежат к рыночному сегменту "Строительство", а затем информацию о размещенных ими заказах из таблицы ORDERS. Информация об отдельных позициях, которые входят в заказы, но к настоящему моменту не отправлены, затем извлекается из таблицы LINEITEM. Выручка по каждой недопоставленной позиции вычисляется этапом задания LineitemRevenue и суммируется для определения ожидаемой выручки по каждому заказу. Затем заказы упорядочиваются в соответствии с приоритетами выполнения, сначала по ожидаемой выручке, а затем по дате заказа. В конце концов выполняется вставка данных (приблизительно 45 000 записей) в таблицу ORDERPRIORITY.

Задание OrderPriority, показанное на рисунке 6 - одно из тех заданий, которое для достижения желаемого результата может также использовать принцип ELT. С помощью этого механизма данные DB2 LINEITEM и ORDERS и Oracle CUSTOMER были бы извлечены из систем-источников и загружены в базу данных SQL Server, в которой размещена целевая таблица. После размещения данных в базе данных SQL Server, можно использовать SQL для выполнения перевода и загрузки результирующей таблицы. Однако при использовании принципа ELT задание загрузило бы в базу данных SQL Server гораздо больше данных, чем это на самом деле необходимо --ему обязательно нужно было бы загрузить тот же объем данных, которые задание WebSphere DataStage извлекло из источников. После загрузки в целевую базу данных мы также теряем все преимущества, предоставляемые индексами или другими механизмами оптимизации, которые могут быть доступны в базе данных - источнике. Поэтому на оценку запроса, вероятно, будет затрачено больше ресурсов, чем необходимо.

На рисунке 7 показано задание OrderPriority, использующее сервер интеграции WebSphere Federation Server для реализации принципа T-ETL:

Рисунок 7. Задание OrderPriority с использованием WebSphere DataStage и WebSphere Federation Server
Задание OrderPriority с использованием DataStage и Federation Server

Трехстороннее объединение между CUSTOMER, ORDERS и LINEITEM оригинального задания OrderPriority было передано на выполнение серверу интеграции WebSphere Federation Server. И снова для перевода шагов оригинального задания в код SQL были использованы выражения CTE. Этот код SQL показан на рисунке 8:

Рисунок 8. Код SQL, переданный серверу интеграции WebSphere Federation Server в рамках задания OrderPriority
Код SQL, переданный серверу интеграции WebSphere Federation Server в рамках задания OrderPriority

Код SQL, используемый для выражений Customer, Orders и Lineitem в точности соответствует коду SQL в оригинальном задании OrderPriority. Остальные этапы выполнения задания не изменились.

Без использования WebSphere Federation Server было бы невозможно обработать трехстороннее объединение между таблицами CUSTOMER, ORDERS и LINEITEM в одной инструкции SQL, потому что данные размещены в двух неоднородных источниках. Большинство других продуктов ETL ограничены только возможностью передачи объединений с одним однородным источником данных (или целевым объектом), это единственная причина использования в них стратегии ELT -- извлечения из нескольких источников и загрузки в один целевой объект перед выполнением обработки SQL. Обладающая большой гибкостью комбинация продуктов WebSphere DataStage и WebSphere Federation Server позволяет разработчикам ETL выбрать наиболее подходящие средства для решения задач консолидации данных, не ограничиваясь конкретным принципом ETL.

Порядок объединения, который сервер интеграции WebSphere Federation Server использует для объединения таблиц Customer, Orders и Lineitem в задании T-ETL OrderPriority, отличается от порядка, используемого разработчиками WebSphere DataStage в оригинальном задании. WebSphere Federation Server сначала принимает решение об объединении таблиц Orders и Lineitem, а затем передает операцию объединения удаленному серверу DB2, который может выполнить ее с большей эффективностью. В результате решения о передаче операции объединения между таблицами Orders и Lineitem серверу DB2 сокращается объем данных, извлекаемых из источника данных. Это изменение в стратегии соединения версии T-ETL по сравнению с оригинальным заданием OrderPriority - по меньшей мере, одна из причин ее большей эффективности.

Оптимизатор стоимости WebSphere Federation Server

Сервер интеграции WebSphere Federation Server принимает решение о способе доступа к данным на основе статистических данных для таблиц, имеющихся к моменту выполнения задания. Благодаря передаче ответственности за выбор оптимального плана доступа (а, следовательно, и стратегии объединения) серверу интеграции WebSphere Federated Server, разработчики WebSphere DataStage избавляются от необходимости вручную определять наилучшую стратегию при объединении двух или более наборов данных.

Оригинальное задание WebSphere DataStage OrderPriority выполняется в течение 70 мин 45 с (4 246 секунд). T-ETL-версия этого задания, использующая сервер интеграции WebSphere Federation Server в качестве модуля предварительной обработки данных, выполняется всего за 12 мин 11 с (731 секунду), экономя около 83 процентов временных затрат.

Если WebSphere Federation Server выполняет объединения и преобразования по мере извлечения данных и передает их WebSphere DataStage, то при этом часто можно использовать индексы и другие механизмы оптимизации, доступные в исходной базе данных способом, который был бы невозможен в любой другой ситуации. WebSphere Federation Server использует встроенный оптимизатор стоимости для определения наиболее эффективных средств разрешения запроса к нескольким источникам. Это может означать передачу объединений между таблицами одного источника данных, автоматическое использование тестового поиска в подходящих ситуациях и применение самых эффективных методов соединения с использованием индексов и статистической информации, доступной на момент выполнения запроса. Если эти ранние объединения и преобразования, осуществляемые сервером интеграции WebSphere Federation Server, также "понижающие" (то есть, если на выход поступает меньше данных, чем считывается), то благодаря им можно предоставить WebSphere DataStage меньше данных для дальнейших преобразований. В результате, WebSphere DataStage, возможно, обработает гораздо меньше данных в комбинированной реализации, что даст выигрыш в общей производительности. Например, в задании OrderPriority WebSphere DataStage считывает 119 642 строк от этапа OrderDetails, который представляет собой вывод объединения, выполненного сервером интеграции WebSphere Federation Server. В оригинальной реализации задания OrderPriority (без сервера интеграции WebSphere Federation Server) WebSphere DataStage необходимо прочитать более 52 миллионов строк из источников DB2 и Oracle .

Пример 3: Источник и получатель - одна и та же база данных

Задача ShipPriority выполняет анализ приоритетов заказов с определенными способами доставки. Задание подсчитывает количество позиций, отправленных почтой или морем за последние шесть месяцев, входящих в состав обычных или высокоприоритетных заказов, и делит эти данные по приоритету заказа. Задание иллюстрирует довольно типичный сценарий, в котором источник и получатель - это одна и та же база данных, а преобразования, выполняемые в рамках задания, относительно просты. Задание WebSphere DataStage для задачи ShipPriority показано на рисунке 9.

Рисунок 9. Задание ShipPriority WebSphere DataStage
Задание ShipPriority DataStage

Сначала из таблицы LINEITEM извлекаем ключи заказов на позиции, отправленные почтой или морем за квалифицирующий промежуток времени. Эти ключи заказов ищем в таблице ORDERS, чтобы определить приоритет заказа, к которому принадлежит данная позиция. Задание использует этап разреженного поиска (GetOrderInfo), чтобы исследовать таблицу ORDERS. После извлечения приоритета заказа, соответствующего каждой квалифицирующей позиции, позиции подсчитываются, и количества суммируются в соответствии с приоритетами заказов и способами доставки позиций. В завершение выполняется вставка данных в таблицу SHIP_PRIORITY, которая размещается в той же базе данных Oracle, что и исходные таблицы ORDERS и LINEITEM . Вывод этого задания - это подсчет количества позиций, являющихся частью срочных или нормальных заказов, которые были отправлены почтой или морем:

L_SHIPMODE URGENT_COUNT NORMAL_COUNT 
---------- ------------ ------------ 
MAIL               2079         3159 
SHIP               2150         3171

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

Задание ShipPriority DataStage, показанное на рисунке 10, иллюстрирует такой перевод, в котором вся логика оригинального задания была сжата в один этап DB2 (ShippingPriority) и выражена на языке запросов SQL. Этап ShippingPriority на самом деле устанавливает соединение с сервером интеграции WebSphere Federation Server, который, в свою очередь, для диалога с Oracle использует псевдонимы.

Рисунок 10. Задание ShipPriority, использующее WebSphere DataStage и WebSphere Federation Server
Задание ShipPriority, использующее DataStage и Federation Server

Этап RowGenerator

Этап DummyRowGenerator на рисунке 10 показан потому, что для выполнения задание WebSphere DataStage должно содержать более одного этапа. Этап RowGenerator используется в этом примере для генерации одного значения (которое в дальнейшем отбрасывается).

В этом случае WebSphere Federation Server выполняет всю обработку, необходимую для задания. Поскольку источник и получатель находятся в одной базе данных, в данном примере нет строгой необходимости использовать интеграцию. Код SQL можно просто передать базе данных Oracle . Однако постоянное использование сервера интеграции WebSphere Federation Server таким образом обеспечивает разработчикам WebSphere DataStage непротиворечивость данных, а также возможность легко менять источник и получатель, не изменяя задание WebSphere DataStage. В этом конкретном примере сервер интеграции WebSphere Federation Server несет минимальные затраты в сравнении с взаимодействием напрямую с Oracle, поскольку он просто принимает инструкцию INSERT..SELECT на этапе ShippingPriority и передает ее непосредственно Oracle.

На рисунке 11 показан код SQL, используемый в шаге ShippingPriority:

Рисунок 11. Код SQL, переданный WebSphere Federation Server для задания ShipPriority
Код SQL, переданный серверу интеграции WebSphere Federation Server для задания ShipPriority

Как и раньше, SQL разбит на отдельные, простые для понимания фрагменты с помощью выражений CTE; каждый фрагмент представляет отдельный этап оригинального задания WebSphere DataStage. Выражения CTE LineItem и OrdersLookup, показанные выше, используют тот же код SQL для извлечения информации из исходных таблиц, что и оригинальное задание WebSphere DataStage.

При выполнении новой версии ShipPriority WebSphere DataStage устанавливает соединение с интегрированной базой данных и выполняет инструкцию INSERT..SELECT, показанную на рисунке 11. Интегрированная база данных просто принимает эту инструкцию SQL, переводит ее в корректную синтаксическую конструкцию Oracle и передает базе данных Oracle для обработки. База данных Oracle разрешает запрос и выполняет вставку строк в таблицу SHIP_PRIORITY перед возвращением результата.

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

Оригинальное задание ShipPriority выполнялось на тестовой системе в течение 68 секунд. Задание, переписанное с использованием WebSphere DataStage и WebSphere Federation Server, выполнялось всего 6 секунд, общая экономия затраченного времени более 91 процента. Кроме того, ЦП на компьютере с размещенными продуктами WebSphere DataStage и WebSphere Federation Server практически не использовался адаптированным заданием, а общее потребление ресурсов ЦПУ в источнике данных Oracle было сокращено примерно на 47 процентов. Сокращение потребления ресурсов ЦПУ на сервере Oracle стало возможным благодаря тому, что новое задание смогло лучше использовать для разрешения запроса возможности оптимизации, предлагаемые базой данных Oracle. В других ситуациях передача обработки базе данных может вызвать более интенсивное потребление ресурсов на сервере базы данных; это может быть нежелательным в тех случаях, когда ресурсы ограничены, или время отклика других рабочих нагрузок, которые выполняются на той же машине, является критически важным.

Передача кода SQL непосредственно Oracle

Аналогичное задание ShipPriority, использующее WebSphere DataStage для передачи инструкции INSERT..SELECT непосредственно Oracle, также было выполнено за 6 секунд. Это делает очевидным тот факт, что в данном конкретном примере WebSphere Federation Server минимально влияет на стоимость выполнения и так же эффективен, как и переход непосредственно к исходной базе данных.

Постоянное использование WebSphere DataStage в ситуациях, в которых вся работа может быть передана и выполнена в одной базе данных, гарантирует разработчикам ETL использование одного общего инструмента для удовлетворения всех требований по консолидации данных. Кроме того, метаданные для задания WebSphere DataStage хранятся в репозитории метаданных IBM Information Server , поэтому данную информацию можно использовать совместно с другими возможностями пакета IBM Information Server. Имея одну общую версию метаданных, которая совместно используется процессами обнаружения, очистки, консолидации и доступа к данным, можно моментально оценить влияние какого-либо изменения в любом фрагменте информации или в любом процессе на все остальные компоненты процесса информационной интеграции на уровне корпорации.

Задания, аналогичные описанным в нашей статье, почти определенно должны иметь зависимости от других заданий и вряд ли будут выполняться изолированно. Планировщик последовательностей заданий (job sequencer) в WebSphere DataStage - это графический инструмент для указания последовательности запуска заданий, обработки исключений с управлением циклами и выполнением. Последовательности могут содержать контрольную информацию, которая соответствует различным операциям в зависимости от успешности или неуспешности выполнения задания. Разрабатывая задание ShipPriority в WebSphere DataStage, можно воспользоваться планировщиком последовательностей заданий -- например, задание ShipPriority может быть запущено событием успешного завершения задания по консолидации информации о заказах за два года.

Постоянно используя сервер интеграции WebSphere Federation Server в таких ситуациях, разработчик ETL получает единый непротиворечивый образ данных, независимо от того, где они могут размещаться (реляционные или нереляционные источники данных) и единый диалект языка SQL, который можно использовать для обращения к любым данным. Таким образом, разработчик может повторно использовать код SQL, разработанный для передачи обработки в базу данных Oracle, чтобы выполнить тот же процесс в базе данных DB2 на Z/OS (например). Тот факт, что WebSphere Federation Server использует псевдонимы для ссылки на исходные объекты базы данных, также повышает гибкость задания WebSphere DataStage.

Рассмотрим предприятие, осуществляющее миграцию с Oracle на Microsoft SQL Server, на котором в отделе информационных технологий есть готовый набор заданий WebSphere DataStage, передающих операции по обработке базе данных Oracle. Чтобы выполнить перенос этих заданий, разработчику ETL придется изменить каждое задание по отдельности, удалив из задания этапы Oracle и заменив их этапами SQL Server, а затем конвертировать диалект Oracle SQL в диалект Microsoft SQL Server. Эти новые задания затем необходимо протестировать, чтобы убедиться в их согласованности с исходными заданиями. Если оригинальные задания были развернуты с помощью сервера интеграции WebSphere Federation Server, то процесс миграции просто вызвал бы удаление псевдонимов Oracle и создание соответствующих псевдонимов SQL Server -- сами задания WebSphere DataStage изменять не было бы необходимости. Поскольку задание не нужно было бы изменять, то тестирование также было бы значительно сокращено.

Пример 4: Сценарий заполнения витрины данных

Задача StockCheck создает отчет о запчастях, по которым поставщики компании с наибольшей вероятностью имеют достаточный запас на следующий квартал. Прогноз строится на предположении о 5-процентном росте продаж запчастей в течение трех предшествующих месяцев, а также на информации о текущем запасе у каждого поставщика. Список генерируется для каждого региона, в котором обнаруживается недостаточный запас запчастей, названий поставщиков в этом регионе, которые их поставляют, и размер вероятного дефицита.

Задание WebSphere DataStage, которое реализует проверку запаса (StockCheck) показано на рисунке 12.

Рисунок 12. Задание WebSphere DataStage StockCheck
Задание DataStage StockCheck

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

Это задание использует таблицу LINEITEM (Oracle) для подсчета количество запчастей каждого вида, проданных в течение предшествующего квартала. Таблица STOCK (DB2) используется для извлечения ключей поставщиков и текущего уровня запаса для запчастей. Затем задание вычисляет 5-процентный рост продаж для каждой запчасти и сравнивает получившееся значение с текущим запасом у поставщика. Информация о поставщике (имя и адрес) затем извлекается для тех запчастей, по которым у поставщика, вероятно, имеется дефицит запаса. Информация о поставщике поступает от внешней утилиты через этап GetSuppliers. Заключительный этап - это разделение поставщиков по регионам, в которых они работают, и вставка записи в соответствующую витрину данных, в которой по ним может быть создан отчет и предприняты соответствующие действия.

Сложность задания StockCheck говорит о том, что конвертация его в схему ELT может оказаться непростой задачей. И на этапе GetSuppliers, который использует для получения названий и адресов поставщиков внешнее приложение, и на этапе SelectRegion Switch, который распределяет записи по различным целевым базам данных в зависимости от региона поставщика, становятся очевидными сложности выражения задания на языке запросов SQL.

Однако конвертация задания StockCheck в схему T-ETL посредством конвертации только небольшой части задания, а именно, объединения между таблицами LINEITEM и STOCK - это сравнительно простая задача. Ситуация иллюстрируется рисунком 13.

Рисунок 13. Задание StockCheck, использующее WebSphere DataStage и WebSphere Federation Server
Задание StockCheck, использующее DataStage и Federation Server

В рассмотренном выше задании двухстороннее объединение между таблицами LINEITEM и STOCK было свернуто в этап PartsSoldLastPeriod и конвертировано в SQL с помощью выражений CTE, причем каждое выражение CTE представляло отдельный этап оригинального задания StockCheck. Выражения CTE, используемые для обращения к таблицам LINEITEM и STOCK, точно соответствуют коду SQL, который использовался в оригинальном этапе. Этот код SQL показан на рисунке 14:

Рисунок 14. Код SQL, переданный WebSphere Federation Server для задания StockCheck
SQL, переданный сервером интеграции Federation Server для задания StockCheck

Серверу интеграции WebSphere Federation Server необходимо выполнить начальное преобразование в этом примере T-ETL, поскольку таблицы LINEITEM и STOCK находятся в различных источниках данных. Попытка перенести все функции, содержащиеся в оригинальном задании WebSphere DataStage либо на уровень получателя, либо на уровень интеграции, просто оказалась бы непродуктивной, поскольку большую часть обработки можно лучше выразить (и обработать с большей эффективностью) в виде параллельных потоков данных в WebSphere DataStage. Код SQL, необходимый для выполнения такого сложного комплекса преобразований, оказался бы громоздким и сложным в обслуживании. Эффективность этого решения проистекает из гибкости и механизма параллельных вычислений программы WebSphere DataStage и эффективности уровня интеграции в области рациональной предварительной обработки данных как из однородных, так и из неоднородных источников -- наряду с предоставлением единого, простого интерфейса SQL.

Оригинальное задание WebSphere DataStage StockCheck было выполнено за 682 секунды, тогда как версия T-ETL этого задания была выполнена за 124 секунды; примерная экономия временных затрат составила 82 процента.

Идентификация заданий, которые выиграют от использования T-ETL

Четыре описанных выше сценария использования представляют собой типичные сценарии консолидации данных, которые выигрывают от использования принципа T-ETL для перемещения и преобразования данных. Почти любой сценарий консолидации данных с задачами (такими как объединения, слияния, фильтрации и агрегирования), способными уменьшить объем входных данных в начале потока данных, может выиграть от обработки T-ETL. Использование сервера интеграции WebSphere Federation Server для выполнения операций, которые перемещают рабочий набор как можно ближе к самим данным, часто более эффективно либо потому, что обработка выполняется в механизме базы данных, либо потому, что можно использовать преимущества оптимизаций (таких как индексы или материализованные представления), которые доступны в источнике. Не менее важно то, что ранняя редукция входных данных также уменьшает объем считываний данных программой WebSphere DataStage. В результате временные затраты и потребление ресурсов комбинированным заданием, вероятно, будут меньше, чем заданием, которое использует только WebSphere DataStage .

Связь с чтением данных

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

Наибольший выигрыш от подхода T-ETL получают такие сценарии консолидации, в которых выборка данных из систем-источников составляет существенную долю от общих временных затрат на выполнение задания. Следовательно, задание связывается с чтением данных в WebSphere DataStage. Подходящие задания можно идентифицировать с помощью функции Job Performance Analysis программы WebSphere DataStage V8. На рисунке 15 показан пример вывода Job Performance Analysis для задания ProjectedBalance, из которого ясно видно, что большая часть временных затрат задания уходит на чтение таблицы CUSTOMER.

Рисунок 15. Пример вывода инструмента Job Performance Analysis
Пример вывода инструмента Job Performance Analysis

Точка в потоке данных, в которой входной набор данных существенно сокращается, обычно соответствует самой выигрышной граничной точке между интеграцией данных и WebSphere DataStage. Эту граничную точку можно идентифицировать либо в соответствии с вашим собственным пониманием данных, либо, если задание уже существует, посредством использования статистических показателей производительности для строк в WebSphere DataStage. На рисунке 16 показана статистика производительности для первых нескольких этапов примера StockCheck:

Рисунок 16. Граничная точка для задания StockCheck
Граничная точка для задания StockCheck.

Сокращение операторов

Все четыре задания, описанные в этой статье, содержат этапы (ранее определенные в задании), сокращающие рабочие наборы данных; их можно выразить на SQL.

Статистический показатель количества считанных строк ясно показывает, что наилучшей граничной точкой для этого конкретного задания была бы точка между этапами JoinOnPart и Calc5PctIncrease. Именно в этой точке рабочий набор данных существенно сокращается с записей размером в 11, 2 Мбайт и 900 Кбайт с двух входов до записей всего лишь немногим более 1 Мбайт. Может также оказаться возможным включение последующих этапов в код SQL, который передается серверу интеграции WebSphere Federation Server (в этом случае подходящими кандидатами могут оказаться оба этапа - и Calc5PctIncrease, и GetLowStock). Добавление дополнительных этапов после точки, в которой набор данных подвергается наибольшему сокращению, может привести к дополнительному повышению производительности. Однако это повышение, скорее всего, будет намного менее существенным и во многом зависеть от доступных ресурсов и уровня параллелизма, заданного в механизме WebSphere DataStage.

Если взять эту порцию потока данных и выполнить ее в WebSphere Federation Server, то мы получим два благоприятных эффекта:

  1. Сокращается размер набора данных, который первоначально должна извлечь программа WebSphere DataStage. Дальнейшая обработка, выполняемая WebSphere DataStage, ускорится, поскольку придется работать с меньшим объемом входных данных;
  2. Поскольку сервер интеграции WebSphere Federation Server способен использовать преимущества широкого диапазона методов оптимизации, время выполнения работы на начальных этапах часто сокращается по сравнению с выполнением этой же работы в WebSphere DataStage, что вызывает сокращение временных затрат и потребления ресурсов на все задание.

В любом случае изменение с задания ETL на задание T-ETL выполняется путем пере записи части задания WebSphere DataStage в виде кода SQL. Из этого следует, что этапы, передаваемые серверу интеграции WebSphere Federation Server, должны быть записаны в синтаксисе SQL. Этот код SQL включается в этап DB2 и передается серверу интеграции WebSphere Federation Server для обработки. Использование выражений CTE для перевода отдельных этапов оригинального задания в код SQL обеспечивает удобство и простоту понимания метода, для которого необходимы только базовые навыки программирования на SQL.

Код SQL в задании T-ETL ссылается на предварительно заданные псевдонимы, существующие в интегрированной базе данных, а не на сами реальные исходные таблицы. Конечно, псевдонимы, в свою очередь, ссылаются на исходные таблицы. Создание псевдонима - это очень простой процесс в одно действие; после создания один псевдоним может использоваться в нескольких заданиях для ссылки на один и тот же удаленный объект.

Сервер интеграции WebSphere Federation Server использует оптимизатор затрат, чтобы определить оптимальный путь доступа для извлечения и обработки данных. Это избавляет разработчиков WebSphere DataStage от необходимости вручную определять лучшую стратегию объединения при сочетании двух или более наборов данных. Выбор неправильного метода объединения или порядка ссылок на этапе объединения может понизить производительность задания на порядок. При использовании WebSphere DataStage для объединения и слияния данных именно разработчик должен определить оптимальную стратегию, исходя из своего понимания данных.

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

Естественно, один и тот же процесс применяется к заданиям, которые извлекают данные из одного источника данных. Передавая отдельные этапы задания источнику данных и уменьшая объем данных, поступающих в WebSphere DataStage, можно повысить общую производительность.

Заключение

Эффективность программы WebSphere DataStage как инструмента консолидации данных заключается в ее гибкости --программа способна поддерживать много разных сценариев консолидации и разновидностей ETL, в том числе ETL, ELT и TEL (для одного источника данных). Комбинирование продуктов WebSphere DataStage и WebSphere Federation Server открывает совершенно новую область сценариев консолидации, под названием T- ETL, для однородных и разнородных источников данных.

Преимущество использования комбинации WebSphere DataStage и WebSphere Federation Server в сценарии T-ETL заключается в том, что решение использует исключительно сильные стороны обоих продуктов: эффективность обработки наборов данных сервера и оптимизацию стоимости в неоднородном окружении сервера интеграции WebSphere Federation Server и гибкость и эффективность механизма параллельных преобразований и моделирования потоков данных WebSphere DataStage . Используя сервер интеграции WebSphere Federation Server для предварительной обработки и сокращения объема данных в наборе, а затем передавая данные в WebSphere DataStage, где можно выполнить дальнейшие преобразования в механизме с высокой масштабируемостью и параллелизмом, можно существенно повысить эффективность всего задания.

Статья знакомит со сценариями консолидации данных, которые лучше всего подходят для стратегии T-ETL и подкрепляет эти сценарии эмпирическими показателями. Четыре основных найденных характерных признака:

  1. Выборка наборов данных из источников данных занимает значительный объем от общих затрат времени на выполнение задания, если осуществляется с помощью только WebSphere DataStage;
  2. Входные наборы данных на ранних этапах задания WebSphere DataStage проходят несколько операций (фильтрации, агрегирования или соединения), которые сокращают их размер. Другими словами, выходной поток данных одной из начальных стадий должен быть меньше, чем сумма его входных потоков;
  3. По меньшей мере одна из ранних "понижающих" операций (фильтрация, агрегирование или объединение), считывающая данные из одного или более входных источников данных, может быть выражена в виде запроса SQL к псевдонимам сервера интеграции WebSphere Federation Server;
  4. Исходные базы данных не секционированы. Если исходная система не секционирована, то WebSphere DataStage сначала читает данные последовательно, а затем секционирует, чтобы использовать преимущества параллелизма. Если заменить часть задания, считывающую данные в WebSphere DataStage, механизмом обработки наборов, который сокращает входной набор данных, можно повысить эффективность задания.

Благодаря использованию интегрированного оптимизатора решение T-ETL также избавляет разработчиков WebSphere DataStage от выбора лучшего метода соединения и коррекции порядка ссылок на этапах слияния и объединения -- решения, которое может на порядок увеличить или уменьшить величину рабочего цикла задания . Интегрированный оптимизатор также позволяет решению T-ETL быть адаптивным, поскольку лучшую стратегию соединения и порядок ссылок можно изменять по мере изменения характеристик данных в задании. Оптимизатор учитывает эти изменения и выбирает оптимальный план доступа при выполнении задания.

В статье показано, что разумно распределяя работу, входящую в задание, между WebSphere DataStage и сервером интеграции WebSphere Federation Server, можно добиться значительной экономии временных затрат. В таблице 1 приводится краткий обзор четырех описанных выше сценариев использования.

Таблица 1. Сводная информация по сценариям использования
Имя заданияВремя на выполнение оригинального задания (с)Время на выполнение задания с T-ETL (с)Процент повышения производительности
ProjectedBalance20412738%
ShipPriority68691%
OrderPriority424673183%
StockCheck68212482%

Даже самое малое значение этой шкалы, соответствующее 38-процентному сокращению затраченного времени, представляет собой существенное улучшение, которое, скорее всего, даст значительную экономию затрат для организации. Безусловно, как при любых экспериментах с производительностью, экономия временных затрат, которой можно добиться, применяя принцип T-ETL с использованием WebSphere Federation Server и WebSphere DataStage, может быть различной. Однако, выявляя подходящие случаи с помощью описанных четырех характерных признаков, можно существенно повысить вероятность того, что применение принципа T-ETL приведет к значительному снижению времени на выполнение задания.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, WebSphere
ArticleID=232328
ArticleTitle=Динамичная архитектура интеграции данных с использованием WebSphere DataStage и сервера интеграции WebSphere Federation Server
publish-date=06212007