Políticas de materialização de ELT em DataStage

As políticas de materialização definem o número e os tipos de artefatos de banco de dados (visualizações ou tabelas) que são criados para dados intermediários ao executar um fluxo do DataStage no modo ELT. A política selecionada impacta o desempenho de execução e o volume de dados intermediários A execução no modo ELT usa DBT, portanto, as políticas de materialização ELT se sobrepõem às materializações DBT. Defina configurações no conector de saída do fluxo para definir a materialização do conjunto de dados de destino. Quando um conjunto de dados de destino é recriado com table action = replace, ele é materializado como uma tabela de materialização DBT padrão, enquanto table action = append usa uma materialização DBT personalizada que implementa vários modos de gravação suportados pelo DataStage, incluindo inserção, atualização, exclusão e outros.

Gerar SQL aninhado

Gerar SQL aninhado é a política de materialização padrão Quando selecionado, o fluxo constrói instruções SQL separadas para cada tabela de saída. Cada instrução contém instruções SQL aninhadas para todos os nós de envio da tabela de saída. Esta abordagem delega todo o trabalho de otimização para um motor de banco de dados

A política de materialização Nested Query geralmente evita a criação de artefatos de banco de dados intermediários. Isso simplifica a limpeza e evita sobras após a execução em caso de falha.. Se um conector de entrada usar uma instrução SQL customizada, o aninhamento não será possível, porque o modelo de álgebra relacional não pode ser construído Nesse caso, você deve selecionar uma política que gere visualizações intermediárias ou os dados intermediários não serão materializados.

Em alguns casos, os fluxos terão um desempenho mais lento com essa política Em um fluxo com diversos conectores de saída que compartilham um grande número dos mesmos estágios de envio de dados, as instruções SQL geradas para cada um deles conterão a mesma lógica, que será executada várias vezes pelo banco de dados. Para evitar essa execução repetitiva, a política Advanced é recomendada.

Avançado

A política de materialização Avançada cria uma única instrução SQL para um conjunto de nós conectados que alteram a cardinalidade de dados, ou alteradores de cardinalidade, para evitar cálculos repetitivos ao construir dados de saída. A imagem a seguir mostra como esses nós são combinados:
Figura 1. Exemplo de materialização avançada
Um exemplo mostrando como um conjunto de nós conectados é combinado para evitar computação repetida.
Os estágios definidos como alteradores de cardinalidade são agrupados em um único artefato de banco de dados.. A instrução SQL para esse artefato inclui as instruções para os alteradores de cardinalidade e seus estágios de envio de dados.. Outros estágios no fluxo usam instruções SELECT simples e não são agrupadas

Essa política é executada de forma semelhante a Gerar SQL aninhada, mas supera outras políticas quando um fluxo tem um número médio alto de links por estágio

Link como visualização

Todos os links de um fluxo são materializados como visualizações e os dados intermediários são removidos após a execução

Link como tabela

Todos os links de um fluxo são materializados como tabelas e os dados intermediários são removidos após a execução Essa política é executada de forma semelhante a Gerar SQL aninhada porque o mecanismo do banco de dados aplica algoritmos de otimização internos ao construir tabelas de saída. Consultar dados intermediários tem menos impacto no desempenho do que em Link como visualização.

Escolhendo uma política

Nos casos em que os fluxos têm várias tabelas de saída para construir em paralelo, a política Avançada pode executar melhor do que Gerar SQL aninhado, o que faz melhor na maioria dos casos O desempenho dessas políticas também varia com base no mecanismo do banco de dados..