Uma Arquitetura de Integração de Dados Flexível usando o InfoSphere DataStage e o InfoSphere Federation Server

Apresentando a arquitetura T-ETL

Combine o InfoSphere® DataStage® e o InfoSphere Federation Server para fornecer uma arquitetura eficiente e flexível para a movimentação e transformação de dados. Este artigo promove o uso do InfoSphere Federation Server como um "pré-processador de dados" do InfoSphere DataStage, e demonstra situações em que essa combinação reduz o tempo de execução decorrido (em até 91%) e o consumo geral de recursos da tarefa. O artigo não promove a combinação do InfoSphere Federation Server e InfoSphere DataStage para todos os cenários de consolidação de dados, pelo contrário, ele tenta caracterizar as situações em que a combinação é mais benéfica.

Simon Harris, Senior Software Engineer, A IBM

Simon HarrisSimon Harris é engenheiro de desempenho e pertence à equipe de desenvolvimento do WebSphere Federation Server no laboratório no Vale do Silício. Simon trabalha com a tecnologia de banco de dados federado desde a sua concepção na IBM, em 1995, e oferece suporte a muitos clientes nas capacidades de pré e pós-venda por toda Europa, Oriente Médio e África.



Susanne Englert, Senior Software Engineer, A IBM

Susanne EnglertSusanne Englert é membro da equipe de desempenho do Websphere Federation Server e trabalha com o produto desde o fim de 2001. Ela trabalhou extensivamente na área de desempenho do banco de dados e está interessada em otimização de consulta, processamento de consulta paralela, consultas federadas e casos de uso de clientes. Susanne é graduada pela Universidade de Bonn e ex-presidente do subcomitê de desenvolvimento de referência de Suporte a Decisão do TPC.



30/Out/2012

Introdução

Muitos fornecedores no mercado de consolidação de dados tradicional estão posicionando seus produtos como Extract-Transform-Load (ETL), Extract-Load-Transform (ELT), ou até mesmo como ferramentas Transform-Extract-Load (TEL). Cada fornecedor naturalmente banca os pontos fortes da abordagem que adota enquanto destaca a fraqueza inerente de seus concorrentes.

Então, qual é a melhor abordagem? A verdade é que todas as abordagens têm seus pontos fortes e fracos, e é provável que a maioria das organizações descubra a necessidade de usar uma combinação de todas essas técnicas. O verdadeiro segredo para a sopa de letras ETL vs. ELT vs. TEL é a flexibilidade e a capacidade de suportar a técnica que melhor se ajusta à tarefa em voga. A modelagem de um fluxo de dados que se ajuste bem à estrutura ETL em uma arquitetura ELT, simplesmente porque a ferramenta não tem a capacidade de suportar adequadamente um processo ou o outro, é uma receita para o desastre.

O InfoSphere DataStage é uma ferramenta de consolidação de dados flexível que pode suportar no estado nativo as topologias ETL, ELT e TEL. Este artigo mostra como a combinação do InfoSphere DataStage e do InfoSphere Federation Server pode ampliar a sopa de letras suportando efetivamente as topologias de consolidação de dados Transform-Extract-Transform-Load (T-ETL, Transformação-Extração-Transformação-Carga). Dentro de uma topologia T-ETL, o InfoSphere DataStage e o InfoSphere Federation Server se complementam mutuamente de maneira tal que podem ser obtidos benefícios de desempenho e economia de CPU significativos em relação ao uso isolado do InfoSphere DataStage. Nesse cenário, o InfoSphere Federation Server é capaz de executar processamento próximo às origens de entrada de modo que menos dados estejam presentes no estágio de extração, e menos transformação precise ser feita pelo InfoSphere DataStage. Esse benefício é obtido porque a arquitetura T-ETL reproduz exatamente os pontos fortes de ambos os produtos: o otimizador baseado em custo e a eficiência do processamento em grupo em um ambiente heterogêneo do InfoSphere Federation Server, e a transformação paralela eficiente e o mecanismo de fluxo de dados do InfoSphere DataStage.

A próxima seção deste artigo fornece uma breve introdução ao InfoSphere Federation Server antes de descrever a arquitetura T-ETL em mais detalhes. As seções dos cenários de caso de uso subsequentes detalham quatro casos diferentes que destacam os benefícios do T-ETL. As tarefas do InfoSphere DataStage que provavelmente se beneficiarão dessa arquitetura são, então, resumidas.

InfoSphere Federation Server

O InfoSphere Federation Server suporta a categoria de segmento de mercado crescente denominada Enterprise Information Integration (EII). Ela permite que os aplicativos acessem e integrem diversos dados e origens de conteúdo como se fossem um recurso único — independentemente de onde as informações residem — ao passo que mantém a autonomia e integridade dos sistemas de origem.

O princípio subjacente da federação serve para que os usuários possam ver todos os dados que usam como se eles residissem em uma única origem. Por apresentar essa única imagem de origem, a tecnologia de federação defende o solicitante contra todas as complexidades associadas com acessar dados em diversos locais, incluindo conectividade, semântica, formatos e métodos de acesso. O middleware permite que usuários ou aplicativos ajam em seu próprio interesse e acessem informações de modo transparente sem se preocuparem com sua implementação física. Consequentemente, o InfoSphere Federation Server encaixa harmoniosa e transparentemente na retaguarda das ferramentas comuns de analítica e relatórios; dos ambientes de desenvolvimento; portais; e de outros componentes padrão da infraestrutura de TI.

Com o InfoSphere Federation Server, é possível enviar solicitações distribuídas para várias origens de dados dentro de uma única instrução SQL; por exemplo, é possível fazer junção de dados que estejam localizados em uma tabela DB2, uma tabela Oracle e um arquivo de tags XML em uma única instrução SQL. Quando um aplicativo submete uma consulta para o sistema federado, o servidor federado identifica as origens de dados relevantes e desenvolve um plano de execução de consulta para obter os dados solicitados. O plano normalmente divide a consulta em fragmentos que representam o trabalho a ser delegado às origens de dados individuais e o processamento adicional a ser executado pelo servidor federado para fins de filtragem, agregação e mesclagem adicional dos dados. A capacidade do servidor federado de processar adicionalmente os dados recebidos das origens permite que os aplicativos tirem proveito da eficiência total da linguagem de consulta, mesmo se algumas das informações solicitadas venham de origens de dados com pouca ou nenhuma capacidade de processamento nativa, por exemplo, arquivos de texto sem formatação. Em adição ao gerenciamento da federação, o servidor federado também é um banco de dados relacional com todas as funções com capacidade de armazenar e gerenciar dados locais.

Para resumir, a eficiência do InfoSphere Federation Server reside na sua capacidade de:

  • Correlacionar dados das tabelas locais e origens de dados remotas, como se todos os dados estivessem armazenados localmente no banco de dados federado.
  • Atualizar dados nas origens de dados relacionais, como se os dados estivessem armazenados no banco de dados federado.
  • Aproveite os pontos fortes e as otimizações exclusivas do processamento de origem de dados, enviando solicitações distribuídas para as origens de dados para processamento.
  • Compensar as limitações da SQL na origem de dados processando as partes de uma solicitação distribuída no servidor federado.

A abordagem federada para obtenção do EII competia com o método mais tradicional de consolidação de dados. Os armazenamentos de dados consolidados, que são normalmente gerenciados para extração, transformação, carga (ETL) ou réplica de dados, são hoje a opção padrão da integração de informações e eram o melhor meio de obter acesso rápido, altamente disponível e integrado às informações relacionadas. A criação de uma única cópia física permite que as empresas atendam aos requisitos de desempenho ou disponibilidade, entreguem capturas instantâneas que sejam consistentes com o momento, e forneçam transformação sofisticada para consistência de semântica.

A federação pode ajudar os departamentos de TI a serem mais responsivos às necessidades do negócio criando protótipos e refinando rapidamente as transformações, acessando dados atualizados a cada segundo, entregando informações ricas de conteúdo de valor agregado (por exemplo, documentos e imagens), que não são práticas de replicar, e fornecendo acesso aos dados que não podem ser consolidados (por exemplo, por motivo de conformidade). Por combinar consolidação de dados com federação, as empresas obtêm a flexibilidade e responsividade que são necessárias no ambiente acelerado dos nossos dias.

Arquitetura T-ETL Usando InfoSphere DataStage e InfoSphere Federation Server

Este artigo se concentra nos benefícios de usar a combinação do InfoSphere DataStage e InfoSphere Federation Server para executar consolidação de dados. Ele promove o uso do InfoSphere Federation Server como um pré-processador de dados para o InfoSphere DataStage, executando essencialmente a transformação inicial quer antes quer durante a extração dos dados de uma ou mais origens. A arquitetura T-ETL propôs usar federação para fazer junção, agregar e filtrar dados antes que eles entrem no InfoSphere DataStage, com o InfoSphere DataStage usando seu mecanismo paralelo para executar as transformações mais complexas e a manutenção do destino. A arquitetura proposta está ilustrada na Figura 1:

Figura 1. Arquitetura T-ETL usando o InfoSphere Federation Server e o InfoSphere DataStage
Arquitetura T-ETL usando o InfoSphere Federation Server e o InfoSphere DataStage

A arquitetura se inspira nos pontos fortes em ambos os produtos, produzindo uma solução flexível e altamente eficiente para consolidação de dados; as capacidades de junção e processamento de SQL do InfoSphere Federation Server e o fluxo de dados paralelo e a lógica eficiente de transformação do InfoSphere DataStage. O otimizador baseado em custo do InfoSphere Federation Server também permite que a arquitetura T- ETL reaja dinamicamente às alterações nos volumes e padrões de dados, sem a necessidade de modificar a tarefa.

O T-ETL não é um conceito novo, e é possível que muitas tarefas ETL empreguem alguma forma de transformação durante a extração dos dados -- por exemplo, filtragem e agregação de dados, ou execução de uma junção entre duas tabelas de origem, que residam no mesmo banco de dados de origem. No entanto, a restrição que os objetos de origem deviam existir na mesma origem de dados limitava severamente o escopo das soluções T-ETL até o momento. O InfoSphere Federation Server remove essa limitação e estende esse estágio de transformação inicial para as origens de dados heterogêneas que são suportadas pelo InfoSphere Federation Server. Por exemplo, o InfoSphere Federation Server permite o T-ETL quando os dados de origem estão em uma tabela Oracle, uma tabela Teradata e um arquivo simples. Em adição à extensão do escopo do estágio de transformação inicial, a federação também é capaz de melhorar a eficiência do estágio desde o seu núcleo, e é um mecanismo de banco de dados relacional com mais de 30 anos de investimento na filtragem e junção eficiente dos conjuntos de dados.

Casos de Uso Destacando o T-ETL

Os seguintes quatro cenários de caso de uso se destinam a destacar os benefícios potenciais que podem ser obtidos do uso do InfoSphere DataStage e InfoSphere Federation Server para consolidar dados. Em cada caso, é apresentado primeiro um cenário de consolidação de dados usando uma tarefa do InfoSphere DataStage, e é desenvolvido adicionalmente mostrando como o InfoSphere Federation Server pode ser usado em conjunto com o InfoSphere DataStage para reduzir o tempo de execução e o consumo de recursos. Também é mostrado como a tarefa original do InfoSphere DataStage pode ser modificada para aproveitar as capacidades do InfoSphere Federation Server. O final desta seção destaca os traços que uma tarefa do InfoSphere DataStage deve possuir para o benefício dessa otimização.

A Figura 2 ilustra a configuração usada para testar os cenários do caso de uso.

Figura 2. Configurações usadas para os cenários de caso de uso
Configurações usadas para os cenários de caso de uso

Dependendo da configuração da tarefa, os dados se originam de uma série de diferentes sistemas UNIX. Similarmente, o destino pode ser localizado em um ou mais sistemas UNIX. O estágio InfoSphere DataStage da API DB2 UDB é usado para acessar origens DB2, destinos e o InfoSphere Federation Server. Todos os bancos de dados de origem e de destino são não particionados. O IBM Information Server (que inclui o InfoSphere DataStage Enterprise Edition V8.0 e o InfoSphere Federation Server V9.0) é instalado em uma máquina Windows Server 2003 com CPU dupla. Cada tarefa dentro dos quatro cenários de caso de uso é uma tarefa paralela projetada para tirar proveito total das capacidades de processamento paralelo do InfoSphere DataStage. Como há duas CPUs no servidor InfoSphere DataStage, o grau de paralelismo usado foi dois.

Os casos de uso se referem às seguintes tabelas de um negócio de entrega de partes hipotéticas. As tabelas estão fisicamente localizadas em um ou mais sistemas de origem, dependendo do cenário:

  • Uma tabela CUSTOMER com uma linha por chave de cliente distinta. Cada linha contém (entre outras coisas) o nome e o saldo da conta desse cliente, além de uma designação do segmento de mercado de que esse cliente é parte.
  • Uma tabela ORDERS com uma linha por chave de pedido distinta. Cada linha também contém a chave de cliente que colocou o pedido, o valor total do pedido, a data quando a pedido foi colocado e um código descrevendo sua prioridade. Há normalmente vários pedidos no banco de dados para cada cliente, mas alguns clientes não têm nenhum pedido ou não colocaram pedidos por um longo período.
  • Uma tabela LINEITEM com uma linha para cada item que é parte de um pedido. Cada linha contém a chave do pedido de que é parte. Normalmente, um pedido contém vários itens de linha. Cada linha de item de linha faz referência a uma chave de peça específica e inclui a quantidade perdida, a data que as peças foram enviadas e o método de envio usado.
  • Uma tabela STOCK que vincula as chaves de peças e chaves de fornecedores, e mantém o controle do número de peças nas mãos de cada fornecedor.

Caso 1: Várias Origens Heterogêneas

A tarefa ProjectedBalance calcula o saldo atual dos clientes com base no último saldo registrado na tabela CUSTOMER, e o valor agregado dos pedidos que eles colocaram nos últimos 30 dias (como registrado na tabela ORDERS). Os clientes e o respectivo saldo projetado são listados, pedindo a saída pelos clientes com os maiores débitos. Como é normal em muitas organizações hoje, as informações do cliente são mantidas em um banco de dados diferente das informações do pedido transacional.

Considere a seguinte tarefa do InfoSphere DataStage que implementa o cálculo ProjectedBalance:

Figura 3. Tarefa ProjectedBalance do InfoSphere DataStage
Tarefa ProjectedBalance do InfoSphere DataStage

A tarefa ProjectedBalance ilustrada na Figura 3 recupera os pedidos do último mês a partir da tabela ORDERS e calcula o valor total de cada chave de cliente. Essas informações são unidas com a tabela CUSTOMER para extrair nome, endereço e saldo atual de cada cliente. O saldo projetado é calculado adicionando o saldo atual do cliente para o valor total dos pedidos que eles colocaram no último mês. Finalmente, os registros (aproximadamente, 70.000) são inseridos na tabela ProjectedBalance ou classificados (para assegurar que os clientes com maiores débitos figurem no alto do relatório) antes saírem para um arquivo simples.

A tarefa do InfoSphere DataStage ilustrada na Figura 3 usa um processo ETL típico para obter o resultado desejado em um modo estruturado. No entanto, neste caso específico (e em outros casos similares), pode ser possível obter o mesmo resultado de um modo mais eficiente combinando o InfoSphere Federation Server com o InfoSphere DataStage e modificando um pouco a tarefa. Por usar o InfoSphere Federation Server como um pré-processador de dados do InfoSphere DataStage e por realizar o push de alguma funcionalidade da tarefa do InfoSphere DataStage no mecanismo do banco de dados federado, tanto o tempo decorrido quanto o tempo de CPU total podem ser reduzidos significativamente.

Considere a seguinte tarefa ProjectedBalance do DataStage equivalente:

Figura 4.Tarefa ProjectedBalance do InfoSphere DataStage com federação
Tarefa ProjectedBalance do InfoSphere DataStage com federação

A tarefa ilustrada na Figura 4 obtém o mesmo resultado que a tarefa ProjectedBalance original mostrada na Figura 3, mas a junção entre CUSTOMER e ORDERS, e a agregação dos valores totais dos pedidos foram reduzidas a um único estágio (Join_CustOrds) e colocadas por push no InfoSphere Federation Server, onde podem ser processadas com mais eficiência. Os outros estágios dentro da tarefa permanecem inalterados.

Para realizar o push da junção no InfoSphere Federation Server, os estágios Orders, AggOrdersByCustomer, Customer e Join_CustOrds são reescritos em SQL, que executa as funções equivalentes. As Expressões da Tabela Comum (CTEs) da SQL podem ser usadas para parar em cada estágio individualmente e componentizar a SQL, tornando a escrita e compreensão mais fáceis. Por exemplo, a SQL mostrada na Figura 5 foi dividida em quatro chunks gerenciáveis usando as CTEs, com cada chunk diretamente equivalente a um dos quatro estágios do InfoSphere DataStage que ele substitui. De fato, as CTEs Customer e Orders usam exatamente a mesma SQL que é usada nos estágios CUSTOMER e ORDERS da tarefa original. Usar CTEs dessa maneira simplifica muito o processo de exprimir um estágio do InfoSphere DataStage nos termos da SQL, enquanto permite que o desenvolvedor cuide da conversão aos poucos, considerando cada estágio individualmente.

Figura 5. SQL colocada por push no InfoSphere Federation Server para tarefa ProjectedBalance
SQL colocada por push no InfoSphere Federation Server para tarefa ProjectedBalance

Quando a tarefa ProjectedBalance na Figura 4 é executada, o estágio Join_CustOrds se conecta ao banco de dados federado e a SQL dentro do estágio é passada para o InfoSphere Federation Server. O InfoSphere Federation Server usa seu otimizador baseado em custo para determinar o método mais eficiente de fazer junção dos dados. A opção de um plano de execução ótimo e o processamento eficiente de conjuntos de dados pelo mecanismo do banco de dados relacional DB2 com todas as funções são responsáveis por boa parte da economia do tempo decorrido e CPU. Assim que a SQL dentro do estágio Join_CustOrds seja processada pelo banco de dados federado, os dados são consumidos pelo InfoSphere DataStage e o processamento da tarefa continua. Uma segunda vantagem de desempenho significativa é que a junção inicial executada pelo InfoSphere Federation Server está "reduzindo"; ou seja, gera muito menos dados em relação ao que se lê a partir das origens. Isso significa que menos dados são lidos pelo InfoSphere DataStage na implementação combinada com o InfoSphere Federation Server (70.663 linhas) do que na implementação inicial (2,4 milhões + 77.636 linhas).

Nomes alternativos

Como o InfoSphere Federation Server está sendo usado para fazer a junção dos dados do Oracle e DB2, SIMON.CUSTOMER e SIMON.ORDERS na Figura 5 se referem realmente aos apelidos definidos dentro do banco de dados federado. Os apelidos, por sua vez, apontam para as tabelas nas origens de dados.

Ao usar o InfoSphere Federation Server para executar algum pré-processamento de dados antes que eles cheguem ao InfoSphere DataStage, você adotou efetivamente uma abordagem T-ETL; destacando a flexibilidade da combinação do InfoSphere DataStage e do InfoSphere Federation Server.

O tempo de execução da tarefa ProjectedBalance original mostrada na Figura 3 era 204 segundos. A tarefa T-ETL mostrada na Figura 4 é executada em apenas 127 segundos -- uma melhoria no tempo decorrido geral de 38 por cento. Os recursos da CPU da máquina do InfoSphere DataStage e do InfoSphere Federation Server também apresentaram uma redução similar, com aumento notável no consumo da CPU nas origens de dados. Assim, nesse caso específico, o tempo decorrido e o consumo de CPU da tarefa são reduzidos em até 38% quando a combinação do InfoSphere DataStage e do InfoSphere Federation Server substitui o InfoSphere DataStage sozinho.

Caso 2: Um Cenário ELT Típico

A tarefa OrderPriority gera uma lista de pedidos incompletos colocados pelos clientes que estão no segmento de mercado "Building". A lista é priorizada com base na receita pendente dos itens de linha pendentes com o pedido e a data que o pedido foi colocado. A Figura 6 mostra uma implementação da tarefa OrderPriority do InfoSphere DataStage.

Figure 6. Tarefa do InfoSphere DataStage
Figure 6. Tarefa do InfoSphere DataStage

A tarefa OrderPriority primeiro extrai as chaves dos clientes que estão no segmento de mercado "Building" e, depois, extrai as informações sobre os pedidos colocados por eles na tabela ORDERS. As informações sobre itens de linha individuais que compõem os pedidos, mas que ainda não foram enviados, são extraídas a partir da tabela LINEITEM. A receita de cada item de linha individual não enviado é calculada pelo estágio LineitemRevenue e somada para determinar a receita pendente de cada pedido. Os pedidos são priorizados, primeiro, pela receita pendente e, em seguida, pela data do pedido. Eventualmente, os dados (aproximadamente, 45.000 registros) são inseridos na tabela ORDERPRIORITY.

A tarefa OrderPriority ilustrada na Figura 6 é uma que também pode usar a abordagem ELT para obter o resultado desejado. Usando esse mecanismo, os dados LINEITEM e ORDERS do DB2, e os dados CUSTOMER do Oracle serão extraídos dos sistemas de origem e carregados no banco de dados SQL Server que hospeda a tabela de destino. Assim que os dados estejam no banco de dados SQL Server, a SQL pode ser usada para executar a conversão e carregar a tabela de resultados. No entanto, usando a abordagem ELT, a tarefa carregará muito mais dados do que é realmente necessário no banco de dados SQL Server — ela essencialmente tem de carregar o mesmo volume de dados que a tarefa do InfoSphere DataStage extrai das origens. Uma vez carregado no banco de dados de destino, você também perde qualquer benefício de índices ou outras otimizações que podem estar disponíveis no banco de dados de origem. Portanto, a avaliação da consulta provavelmente consumirá mais recursos que o necessário.

A Figura 7 mostra a tarefa OrderPriority usando o InfoSphere Federation Server para implementar a abordagem T-ETL:

Figura 7. Tarefa OrderPriority usando o InfoSphere DataStage e o InfoSphere Federation Server
Tarefa OrderPriority usando o InfoSphere DataStage e o InfoSphere Federation Server

A junção de três vias entre CUSTOMER, ORDERS e LINEITEM da tarefa OrderPriority original teve o push realizado para executar no InfoSphere Federation Server. Mais uma vez, CTEs foram usadas para converter os estágios da tarefa original, uma por vez, para SQL. A SQL é mostrada na Figura 8:

Figura 8. SQL colocada por push no InfoSphere Federation Server para tarefa OrderPriority
SQL colocada por push no InfoSphere Federation Server para tarefa OrderPriority

A SQL usada para as CTEs Customer, Orders e Lineitem é exatamente o mesmo que a SQL na tarefa OrderPriority original. Todos os outros estágios dentro da tarefa permanecem inalterados.

Sem o InfoSphere Federation Server, não seria possível processar a junção de três vias entre CUSTOMER, ORDERS e LINEITEM em uma única instrução SQL porque os dados residem em duas origens heterogêneas. A maioria dos outros produtos ETL está limitada apenas a ser capaz de realizar o push nas junções para uma única origem de dados homogênea (ou destino). Esse é o único motivo para eles adotarem uma estratégia ELT de extrair de várias origens e carregar em um único destino antes de executar o processamento de SQL. A combinação flexível do InfoSphere DataStage e InfoSphere Federation Server permite que os desenvolvedores de ETL escolham os meios mais apropriados de obter seus objetivos de consolidação de dados - sem estarem limitados a uma abordagem ETL específica.

O pedido de junção que o InfoSphere Federation Server usa para fazer a junção das tabelas Customer, Orders e Lineitem na tarefa OrderPriority do T-ETL é diferente do pedido usado pelo desenvolvedor do InfoSphere DataStage na tarefa original. O InfoSphere Federation Server toma a decisão de fazer a junção de Orders com Lineitem, primeiro, e realiza o push dessa junção para o servidor DB2 remoto onde ela pode ser executada com maior eficiência. Como uma consequência da decisão de realizar o push da junção entre Orders e Lineitem para o servidor DB2, o volume dos dados extraídos da origem de dados é reduzido. Essa alteração na estratégia de junção entre o original e a versão T-ETL da tarefa OrderPriority é, no mínimo, parte do motivo porque a versão T-ETL da tarefa é mais eficiente.

Otimizador Baseado em Custo do InfoSphere Federation Server

O InfoSphere Federation Server toma a decisão sobre como acessar os dados baseados nas estatísticas que estão disponíveis para as tabelas no momento que a tarefa é executada. Por passar a responsabilidade de selecionar o plano de acesso ótimo (e, portanto, a estratégia de junção) para o InfoSphere Federated Server, é removido o fardo do desenvolvedor do InfoSphere DataStage de determinar manualmente a melhor estratégia para fazer a junção de dois ou mais conjuntos de dados.

A tarefa OrderPriority original do InfoSphere DataStage executa em 70 min e 45 s (4.246 segundos). A versão T-ETL da tarefa que usa o InfoSphere Federation Server como um pré-processador de dados executa em apenas 12 min e 11 s (731 segundos), uma economia de tempo decorrido de aproximadamente 83%.

Ter o InfoSphere Federation Server de executar junções à medida que os dados são extraídos e enviados para o InfoSphere DataStage frequentemente permite que os índices e outras otimizações disponíveis nos bancos de dados de origem sejam explorados de modo que talvez de outra forma não seja possível. O InfoSphere Federation Server usa o seu otimizador baseado em custo para determinar os meios mais eficientes de resolver a consulta de várias origens. Isso pode significar realizar o push das junções entre tabelas na mesma origem de dados, usando automaticamente consultas de tipo de análise quando apropriado, e recorrendo à técnica de junção mais eficiente com base nos índices e informações estatísticas disponíveis no momento que a consulta é executada. Se essas junções e transformações executadas pelo InfoSphere Federation Server também estiverem reduzindo (significando que elas geram menos dados em relação aos dados lidos), elas permitem que menos dados sejam apresentados para o InfoSphere DataStage para transformação adicional. Consequentemente, é possível que o InfoSphere DataStage precise processar muito menos dados na implementação combinada, beneficiando o desempenho geral. Por exemplo, na tarefa OrderPriority, o InfoSphere DataStage lê as linhas 119,642 do estágio OrderDetails, que representa a saída de uma junção executada pelo InfoSphere Federation Server. A implementação do OrderPriority original, sem o InfoSphere Federation Server, exigia mais de 52 milhões de linhas fossem lidas pelo InfoSphere DataStage nas origens DB2 e Oracle.

Caso 3: A Origem e o Destino Estão no Mesmo Banco de Dados

A tarefa ShipPriority executa análise de prioridades de pedido dentro de determinados modos de envio. A tarefa conta o número de itens de linha enviados por correio ou navio dentro dos últimos seis meses que são parte dos pedidos de prioridade normal e alta, e divide as contagens por prioridade de pedido. Essa tarefa ilustra um cenário bastante típico onde a origem e o destino estão no mesmo banco de dados, e as transformações feitas dentro da tarefa são relativamente simples. A tarefa do InfoSphere DataStage da tarefa ShipPriority está ilustrada na Figura 9.

Figura 9. Tarefa ShipPriority do InfoSphere DataStage
Tarefa ShipPriority do InfoSphere DataStage

Inicialmente, as chaves de pedido que correspondem aos itens de linha enviados pelo correio ou navio durante o período do tempo de qualificação são extraídos da tabela LINEITEM. Essas chaves de pedido são procuradas na tabela ORDERS para determinar a prioridade do pedido a que o item de linha pertence. A tarefa usa o estágio Lookup esparso (GetOrderInfo) para analisar ORDERS. Assim que a prioridade do pedido associada com cada item da linha de qualificação tenha sido extraída, os itens de linha são contados e as contagens resumidas por prioridade do pedido e modo de envio do item de linha. Finalmente, os dados são inseridos na tabela SHIP_PRIORITY que reside no mesmo banco de dados Oracle que as tabelas de origem ORDERS e LINEITEM. A saída dessa tarefa é uma contagem do número de itens de linha que são parte dos pedidos urgentes ou normais que foram enviados por correio ou navio, similar a:

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

Para esse tipo de tarefa, em que a origem e o destino estão dentro do mesmo banco de dados, e as transformações não são demasiadamente complexas, é muito apropriado reescrever a tarefa em uma única instrução SQL que possa ser executada integralmente dentro do mecanismo de banco de dados.

A tarefa ShipPriority do DataStage mostrada na Figura 10 ilustra uma nova escrita onde toda a lógica da tarefa original é reduzida a um único estágio DB2 (ShippingPriority) e expressa em SQL. O estágio ShippingPriority está se conectando realmente ao InfoSphere Federation Server, o qual, por sua vez, usa apelidos para conversar com o Oracle.

Figura 10. Tarefa ShipPriority usando o InfoSphere DataStage e InfoSphere Federation Server
Tarefa ShipPriority usando o InfoSphere DataStage e InfoSphere Federation Server

Estágio RowGenerator

O estágio DummyRowGenerator na Figura 10 está incluído porque uma tarefa do InfoSphere DataStage deve conter mais do que um estágio no pedido para executar. O estágio RowGenerator é usado neste exemplo para gerar um valor único (que é descartado mais tarde).

Nesse caso, o InfoSphere Federation Server executa todo o processamento necessário para a tarefa. Como a origem e o destino estão dentro do mesmo banco de dados, não é estritamente necessário usar federação neste exemplo. A SQL pode simplesmente ser passada diretamente para o banco de dados Oracle. No entanto, o uso contínuo do InfoSphere Federation Server dessa maneira fornece consistência aos desenvolvedores do InfoSphere DataStage, junto com a capacidade para modificar facilmente a origem e o destino sem alterar a tarefa do InfoSphere DataStage. Neste exemplo específico, o InfoSphere Federation Server tem gasto adicional mínimo em comparação com conectar-se por interface diretamente ao Oracle, visto que ele simplesmente toma a instrução INSERT..SELECT no estágio ShippingPriority e a passa diretamente para o Oracle.

A Figura 11 mostra a SQL usada dentro do estágio ShippingPriority:

Figura 11. SQL com push realizado para InfoSphere Federation Server para tarefa ShipPriority
SQL com push realizado para InfoSphere Federation Server para tarefa ShipPriority

Mais uma vez, a SQL foi dividida em partes individuais fáceis de entender, usando CTEs; cada parte representando um estágio específico da tarefa do InfoSphere DataStage original. Ambas as CTEs ilustradas acima, LineItem e OrdersLookup, usam a mesma SQL para extrair as informações das tabelas de origem como a tarefa do InfoSphere DataStage original.

Quando uma nova versão da tarefa ShipPriority é executada, o InfoSphere DataStage se conecta ao banco de dados federado e emite a instrução INSERT..SELECT, mostrada na Figura 11. O banco de dados federado simplesmente toma a instrução SQL, a converte para uma sintaxe válida do Oracle e a transmite para o banco de dados Oracle para processamento. O banco de dados resolve a consulta e insere as linhas na tabela SHIP_PRIORITY antes de retornar.

Ao reescrever a tarefa em SQL, você a transformou efetivamente de uma tarefa ETL típica em outra onde todo o processamento ocorre dentro do próprio mecanismo do banco de dados. Embora isso possa ser um meio eficiente de obtenção do objetivo, essa abordagem está limitada àquelas tarefas em que tanto a origem quanto o destino estão dentro do mesmo banco de dados e as transformações podem ser expressas em SQL.

A tarefa ShipPriority original executou em 68 segundos no sistema de teste. A tarefa reescrita usando o InfoSphere DataStage e InfoSphere Federation Server executou em apenas 6 segundos, uma melhoria geral no tempo decorrido de mais de 91%. Além disso, a utilização da CPU hospedando o InfoSphere DataStage e o InfoSphere Federation Server foi virtualmente eliminada pela tarefa reescrita, o consumo geral da CPU na origem de dados Oracle foi reduzido em aproximadamente 47%. A redução na CPU no servidor Oracle foi possível porque a nova tarefa era capaz de fazer melhor uso das otimizações dentro do banco de dados Oracle para resolver a consulta. Em outros casos, realizar o push do processamento para o banco de dados pode fazer com que mais recursos sejam consumidos no servidor de banco de dados; isso pode não ser desejável nos casos em que os recursos talvez sejam limitados ou os tempos de resposta de outras cargas de trabalho compartilhando a máquina sejam críticos.

Realizando o Push da SQL Diretamente no Oracle

Uma tarefa ShipPriority similar que usou o InfoSphere DataStage para realizar o push do INSERT..SELECT diretamente para o Oracle também executou em 6 segundos. Isso destaca o fato de que nesse caso específico, o InfoSphere Federation Server tem impacto mínimo e é tão eficiente quanto ir diretamente para o banco de dados de origem.

O uso contínuo do InfoSphere DataStage nos casos em que a tarefa inteira pode ter o push realizado e ser executada dentro de um único banco de dados assegura que os desenvolvedores de ETL usem uma única ferramenta comum para resolver seus requisitos de consolidação de dados. Além disso, os metadados da tarefa do InfoSphere DataStage são armazenados em repositórios de metadados do IBM Information Server, portanto, é possível para compartilhar essas informações com e aproveitar todos os outros recursos do conjunto do IBM Information Server. Se tiver uma única versão comum dos metadados que seja compartilhada pelos processos de descoberta, limpeza, consolidação e acesso aos dados, um indivíduo pode avaliar imediatamente o impacto que uma alteração de qualquer parte de informação ou processo pode causar em todos os outros componentes do processo de integração das informações no âmbito da empresa.

É quase certo que as tarefas, por exemplo, as descritas neste artigo, tenham dependências de outras tarefas e é improvável que sejam executadas de modo isolado. O sequenciador de tarefas do InfoSphere DataStage é uma ferramenta gráfica que permite que desenvolvedores especifiquem uma sequência de tarefas para ser executada, junto com a manipulação de exceção com controle de loop e fluxo. As sequências podem conter informações de controle que indicam diferentes ações dependendo de se uma tarefa na sequência é bem-sucedida ou falha. Ao projetar a tarefa ShipPriority no InfoSphere DataStage, é possível aproveitar o sequenciador de tarefas. Por exemplo, ela pode ser acionada pela conclusão bem-sucedida de uma tarefa de consolidação de ordem bianual.

Ao continuar a usar o InfoSphere Federation Server nesses casos, o desenvolvedor do ETL é fornecido com uma imagem consistente, única, dos dados -- independentemente de onde ele possa residir (origens de dados relacionais ou não relacionais) e um dialeto SQL único que possa ser usado para acessar qualquer um dos dados. Desse modo, o desenvolvedor pode usar o mesmo SQL escrito para realizar o push do processamento para um banco de dados Oracle para executar o mesmo processo dentro de um banco de dados DB2 on Z/OS (por exemplo). O fato que o InfoSphere Federation Server usa apelidos para fazer referência aos objetos da origem de dados também aumenta a flexibilidade da tarefa do InfoSphere DataStage.

Considere uma empresa que esteja migrando do Oracle para o Microsoft SQL Server, em que o departamento de TI tenha um conjunto existente de tarefas do InfoSphere DataStage que realizam o push do processamento para um banco de dados Oracle. Para migrar essas tarefas, o desenvolvedor ETL teria de alterar cada tarefa individualmente, removendo os estágios Oracle dentro da tarefa e as substituindo pelos estágios do SQL Server, e convertendo o dialeto Oracle SQL em Microsoft SQL Server. As novas tarefas teriam de ser testadas para assegurar a consistência com as tarefas originais. Se tarefas originais tiverem sido implementadas usando o InfoSphere Federation Server, o processo de migração simplesmente envolverá o descarte dos apelidos do Oracle, e criando os apelidos do SQL Server correspondentes - a própria tarefa do InfoSphere DataStage não terá de ser alterada. Como a tarefa não teria de ser alterada, o teste também seria substancialmente reduzido.

Caso 4: Cenário de Ocupação do Datamart

Os relatórios da tarefa StockCheck nas peças para quais os fornecedores da empresa provavelmente terá o estoque insuficiente no próximo trimestre. A previsão é baseada na presunção de um aumento de 5 por cento na venda de peças em relação aos três meses anteriores, além das informações sobre o estoque atual em cada fornecedor. Uma lista é gerada para cada região que identifica as peças em risco de extinção, os nomes dos fornecedores nessa região que as fornecem e o tamanho provável do déficit.

A tarefa do InfoSphere DataStage que implementa o StockCheck é ilustrada na Figura 12.

Figura 12. Tarefa StockCheck do InfoSphere DataStage
Tarefa StockCheck do InfoSphere DataStage

A saída da tarefa StockCheck está direcionada para um de cinco destinos diferentes despendendo da região do fornecedor, ou um arquivo de rejeição se a região do fornecedor não estiver classificada. Cada um dos destinos representa um datamart que está fisicamente localizado dentro de uma região específica. StockCheck é uma tarefa de ocupação de datamart bem típica, que usa a lógica ETL para mover e transformar dados de um armazém de dados para datamarts menores.

A tarefa usa a tabela LINEITEM (Oracle) para contar o número de cada tipo de peça vendido durante o trimestre anterior. A tabela STOCK (DB2) é usada para extrair chaves de fornecedores e níveis de estoque atuais das peças. A tarefa calcula um aumento de 5% nas vendas de cada peça e o compara em relação ao estoque atual que o fornecedor mantém. As informações do fornecedor, por exemplo, nome e endereço, são extraídas das peças das quais o fornecedor provavelmente terá estoque insuficiente. As informações do fornecedor são obtidas de um utilitário externo através do estágio GetSuppliers. A etapa final é separar os fornecedores pela região em que eles operam, e inserir um registro no datamart apropriado -- onde ele possa ser informado e a ação adequada tomada.

A complexidade da tarefa StockCheck significa que ela será uma tarefa muito árdua para convertê-la em um esquema ELT. Tanto o estágio GetSuppliers, que usa um aplicativo externo para obter nomes e endereços de fornecedor, quanto o estágio SelectRegion Switch, que desvia registros para diferentes bancos de dados de destino dependendo da região do fornecedor, provarão a dificuldade de expressão em SQL.

No entanto, é uma tarefa relativamente simples converter StockCheck em um esquema T-ETL por apenas converter uma pequena parte da tarefa; ou seja, a junção entre LINEITEM e STOCK. Isso é ilustrado na Figura 13.

Figura 13. Tarefa StockCheck usando o InfoSphere DataStage e o InfoSphere Federation Server
Tarefa StockCheck usando o InfoSphere DataStage e o InfoSphere Federation Server

Na tarefa acima, a junção de duas vias entre LINEITEM e STOCK foi reduzida no estágio PartsSoldLastPeriod e convertida em SQL usando CTEs, com cada CTE representando um único estágio da tarefa StockCheck original. As CTEs usadas para acessar as tabelas LINEITEM e STOCK correspondem exatamente à SQL usada nos estágios originais. A SQL completa é mostrada na Figura 14:

Figura 14. SQL com push realizado para o InfoSphere Federation Server para a tarefa StockCheck
SQL com push realizado para o InfoSphere Federation Server para a tarefa StockCheck

O InfoSphere Federation Server é necessário para executar a transformação inicial neste exemplo de T-ETL, visto que as tabelas LINEITEM e STOCK estão localizadas em diferentes origens de dados. A tentativa de realizar o push de todas as funções contidas na tarefa do InfoSphere DataStage original para o destino ou para uma camada de federação simplesmente se provará improdutiva, já que a maioria do processamento é melhor expressa (e processada mais eficientemente) como um fluxo de dados paralelo no InfoSphere DataStage. A SQL necessária para executar como um conjunto complexo de transformações se provará incômoda e difícil de manter. A força dessa solução procede da flexibilidade e do mecanismo de processo paralelo do InfoSphere DataStage, e da capacidade da camada de federação em ser capaz de pré-processar dados eficientemente de origens homogêneas ou heterogêneas -- enquanto fornece uma interface SQL única e simples.

A tarefa StockCheck original do InfoSphere DataStage executou em 682 segundos, enquanto que a versão T-ETL da tarefa executou em 124 segundos; uma melhoria aproximada no tempo decorrido de 82%.

Identifique as tarefas que se beneficiarão do T-ETL

Os quatro casos de uso descritos acima são todos cenários típicos de consolidação de dados que se beneficiam do emprego de uma abordagem T-ETL para mover e transformar dados. Praticamente qualquer cenário de consolidação com tarefas (como junções, mesclagens, filtragem e agregações) capazes de reduzir os dados de entrada precocemente no fluxo de dados pode se beneficiar do processamento de T-ETL. Usar o InfoSphere Federation Server para executar operações que reduzem o conjunto de trabalho tão próximo aos dados quanto possível é frequentemente mais eficiente, porque o processamento é executado dentro de um mecanismo de banco de dados relacional, ou porque ele é capaz de aproveitar as otimizações (como índices e visualizações materializadas) disponíveis na origem. Igualmente importante, a redução precoce dos dados de entrada também reduz o volume dos dados lidos pelo InfoSphere DataStage. Consequentemente, o tempo decorrido e o consumo de recursos da tarefa combinada devem ser provavelmente menores que os da mesma tarefa que usa o InfoSphere DataStage sozinho.

Vinculado aos Dados de Leitura

As quatro tarefas descritas neste artigo gastam uma quantidade significativa do tempo de execução decorrido lendo dados nas origens de dados.

Os cenários de consolidação que mais se beneficiarão com uma abordagem T-ETL são aqueles em que a busca dos dados nos sistemas de origem constituem uma proporção razoável do tempo total decorrido da tarefa. Ou seja, a tarefa está vinculada à leitura dos dados no InfoSphere DataStage. As tarefas candidatas podem ser identificadas usando o recurso Análise de Desempenho da Tarefa do InfoSphere DataStage V8. A Figura 15 mostra a saída de amostra da Análise de Desempenho da Tarefa para a tarefa ProjectedBalance e claramente mostra que a maioria do tempo decorrido da tarefa é consumida lendo a tabela CUSTOMER.

Figura 15. Saída de amostra da ferramenta Análise de Desempenho da Tarefa
Saída de amostra da ferramenta Análise de Desempenho da Tarefa

O ponto no fluxo de dados em que o conjunto de dados de entrada é significativamente reduzido, normalmente representa o ponto limite mais benéfico entre a federação e o InfoSphere DataStage. Esse ponto limite pode ser identificado por meio do nosso conhecimento dos dados, ou se a tarefa já existir, usando o elemento de estatísticas de desempenho das linhas do InfoSphere DataStage. A Figura 16 mostra as estatísticas de desempenho dos primeiros estágios do exemplo do StockCheck:

Figura 16. Ponto limite da tarefa StockCheck
Ponto limite da tarefa StockCheck

Reduzindo Operadores

As quatro tarefas descritas neste artigo contêm os estágios (definidos anteriormente na tarefa) que reduzem o conjunto de dados de trabalho e podem ser expressos em SQL.

A estatística de número de linhas lidas claramente indica que o melhor ponto limite para essa tarefa específica estará entre os estágios JoinOnPart e Calc5PctIncrease. Isso se dá porque, neste ponto, o conjunto de dados de trabalho é dramaticamente reduzido de 11,2M e 900K registros das duas entradas para pouco mais de 1M de registros. Também pode ser possível incluir estágios subsequentes na SQL passada para o InfoSphere Federation Server (neste caso, os estágios Calc5PctIncrease e GetLowStock serão os candidatos). Incluir os estágios adicionais para além do ponto em que o conjunto de dados é mais reduzido, pode levar a melhorias de desempenho adicionais. No entanto, as melhorias estão suscetíveis a serem muito menos dramáticas e a dependerem muito dos recursos disponíveis e os níveis do paralelismo definido dentro do mecanismo InfoSphere DataStage.

Há dois efeitos benéficos de tomar essa parte do fluxo de dados e executá-la dentro do InfoSphere Federation Server:

  1. O tamanho do conjunto de dados que o InfoSphere DataStage inicialmente tem de recuperar é reduzido. O processamento subsequente executado pelo InfoSphere DataStage é rápido porque há menos dados de entrada para lidar.
  2. Como o InfoSphere Federation Server é capaz de aproveitar uma faixa mais ampla de técnicas de otimização, o tempo de execução do trabalho dos estágios iniciais é frequentemente reduzido em relação à execução deles dentro do InfoSphere DataStage, resultando em tempo de execução e consumo de recursos reduzidos em todo o trabalho.

Em cada caso, a modificação de uma tarefa ETL para uma tarefa T-ETL é executada reescrevendo uma parte da tarefa InfoSphere DataStage em SQL. Disso decorre, portanto, que o estágio cujo push é realizado para o InfoSphere Federation Server deve poder ser expresso na sintaxe da SQL. A SQL é incluída em um estágio do DB2 e passada para o InfoSphere Federation Server para processamento. Usando CTEs para reescrever em SQL os estágios individuais da tarefa original, fornece um modo fácil e conveniente para compreender a metodologia que requer apenas conhecimentos de programação básicos em SQL.

A SQL dentro da tarefa T-ETL se refere aos apelidos predefinidos que existem dentro do banco de dados federado, em vez das próprias tabelas de origem reais. Evidentemente, os apelidos, por sua vez, se referem às tabelas de origem. A criação do apelido é um processo de uma etapa muito simples e, uma vez criada, o mesmo apelido pode ser usado em várias tarefas para fazer referência ao mesmo objeto remoto.

O InfoSphere Federation Server usa seu otimizador baseado em custo para determinar o caminho de acesso ótimo para recuperar e processar os dados. Isso remove o fardo dos ombros do desenvolvedor do InfoSphere DataStage de determinar manualmente a melhor estratégia de junção ao combinar dois ou mais conjuntos de dados. Selecionar a técnica de junção ou ordem de links errada em um estágio de junção pode afetar o desempenho de uma tarefa por ordem de grandeza. Ao usar o InfoSphere DataStage para fazer junção e mesclagem de dados, é responsabilidade do desenvolvedor determinar a estratégia ótima com base no seu conhecimento dos dados.

No entanto, os dados são dinâmicos e uma estratégia que seja apropriada quando a tarefa é desenvolvida pela primeira vez, pode não ser eficiente quando a tarefa é implementada. Como o otimizador federado toma suas decisões de plano no tempo de execução, com base nas estatísticas atuais disponíveis para os apelidos que representam as tabelas de entrada, ele pode reagir ou adaptar aos volumes de dados em alteração e às distribuições para selecionar o plano ótimo no momento que a tarefa é executada. Assim que o otimizador do InfoSphere Federated Server selecionar a estratégia de acesso ideal, a estratégia será executada. Se possível, as operações realizam o push para executar remotamente a origem de dados e aproveitar as otimizações que podem existir lá (como índices). As operações que não podem realizar o push são executadas dentro do próprio banco de dados federado, e como o banco de dados federado é um banco de dados relacional totalmente funcional, essas operações baseadas em conjunto são processadas com extrema eficiência.

Naturalmente, o mesmo processo se aplica às tarefas que extraem dados de uma única origem de dados. Por realizar o push de determinados estágios para a origem de dados e reduzir o volume de dados que flui para o InfoSphere DataStage, deve ser possível melhorar a eficiência geral.

Conclusão

A força do InfoSphere DataStage como uma ferramenta de consolidação de dados reside na sua flexibilidade -- ele é capaz de suportar vários cenários de consolidação diferentes e tipos de ETL, incluindo ETL, ELT e TEL (em relação a uma única origem de dados). Combinar o InfoSphere DataStage com o InfoSphere Federation Server abrirá toda uma nova área de cenários de consolidação, a saber, T- ETL, em relação às origens de dados homogêneas e heterogêneas.

O benefício de usar a combinação do InfoSphere DataStage e do InfoSphere Federation Server em um cenário T-ETL é que a solução reproduz exatamente os pontos fortes de ambos os produtos: a eficiência de processamento baseado em conjunto e otimização baseada em custo em um ambiente heterogêneo do InfoSphere Federation Server, e a eficiência e flexibilidade do mecanismo de transformação paralela e modelagem de fluxo de dados do InfoSphere DataStage. Por usar o InfoSphere Federation Server para pré-processar e reduzir dados em um modo baseado em conjunto, e, depois, passar os dados para o InfoSphere DataStage onde mais transformações podem ser executadas no mecanismo altamente escalável e paralelo, a eficiência da tarefa inteira é dramaticamente melhorada.

O artigo identifica os cenários de consolidação de dados que são melhores adequados para uma estratégia T-ETL, e reforça isso com medições empíricas. As quatro principais características identificadas são:

  1. Buscar os conjuntos de dados nas origens de dados constitui uma quantidade razoável do tempo decorrido geral da tarefa quando implementada usando o InfoSphere DataStage sozinha.
  2. Os conjuntos de dados de entrada passam por alguma operação (filtragem, agregação ou uma junção) nos estágios precoces da tarefa InfoSphere DataStage que reduz seu tamanho. Em outras palavras, o fluxo de dados de saída de um dos estágios iniciais deve ser menos que a soma de suas entradas.
  3. Pelo menos, uma operação de "redução" precoce (filtragem, agregação ou junção) que lê dados de uma ou mais origens de dados de entrada pode ser expressa como uma consulta SQL no que se refere aos apelidos do InfoSphere Federation Server.
  4. Os bancos de dados de origem não são particionados. Se um sistema de origem não for particionado, o InfoSphere DataStage inicialmente lê os dados sequencialmente e os particiona para aproveitar o paralelismo. Por substituir a parte da tarefa que lê os dados no InfoSphere DataStage por um mecanismo de processamento baseado em conjunto que reduz o conjunto de dados de entrada, a eficiência da tarefa pode ser melhorada.

Usando o otimizador federado, a solução T-ETL também remove a ênfase no desenvolvedor do InfoSphere DataStage para selecionar a melhor metodologia de junção, e corrigir a ordem de links dentro dos estágios de junção e mesclagem -- uma decisão que pode afetar o tempo de execução da tarefa por ordem de grandeza. O otimizador federado também permite que a solução T-ETL seja adaptável, já que a melhor estratégia de junção e ordem de links pode mudar à medida que as características dos dados na tarefa mudam. O otimizador leva em conta essas alterações e seleciona o plano de acesso ideal quando a tarefa é executada.

O artigo demonstra que por dividir prudentemente o trabalho envolvido em uma tarefa entre o InfoSphere DataStage e o InfoSphere Federation Server, é possível obter economias substanciais no tempo decorrido. A Tabela 1 resume os quatro cenários de caso de uso descritos acima.

Tabela 1. Resumo dos quatro cenários de caso de uso
Nome da tarefaTempo decorrido original (s)Tempo decorrido usando T-ETL (s)Melhoria em porcentual
ProjectedBalance20412738%
ShipPriority68691%
OrderPriority424673183%
StockCheck68212482%

Mesmo na extremidade inferior da escala, uma redução de 38% no tempo decorrido é uma melhoria significativa que está suscetível a ter economias de custo substanciais para uma organização. Naturalmente, a exemplo de todos os estudos de desempenho, as economias no tempo decorrido que alguém pode obter ao adotar uma abordagem T-ETL usando o InfoSphere Federation Server e InfoSphere DataStage pode variar. No entanto, usar as quatro características definidas acima para identificar os melhores candidatos certamente aumenta a probabilidade de que tarefas que adotam uma abordagem T-ETL resultem em uma redução substancial no tempo de execução decorrido.

Contato

Se você tiver perguntas sobre este tópico, entre em contato com Tony Curcio ou Jef Treece.

Recursos

Aprender

Obter produtos e tecnologias

  • Faça o download do Versões de avaliação de produtos IBM e coloque as mãos em ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®eWebSphere®.
  • Crie seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente do developerWorks.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management, WebSphere
ArticleID=843356
ArticleTitle=Uma Arquitetura de Integração de Dados Flexível usando o InfoSphere DataStage e o InfoSphere Federation Server
publish-date=10302012