DW - Bi - Teradata - Netezza - Hp Neoview

Teradata 12.0

20 de Janeiro de 2008 às 17:02 admin  | Enviar por e-mail Hits para esta publicação: 1139

Pessoal,

Estou incluindo uma tradução livre do artigo Teradata 12.0:Active Performance, escrito por Todd Walter e Alan Greenspan, publicado na revista Teradata Magazine Volume 7, No. 3.

Ainda não está completo, a medida que o tempo permitir pretendo incluir o artigo inteiro traduzido.

“Active Data Warehousing” (ADW) é o processo de combinar inteligência estratégica e operacional na mesma plataforma, utilizando dados corporativos atualizados. Uma aplicação ADW, submete a plataforma tecnológica a requerimentos intensos.

Primeiro, o ADW precisa de um desempenho consideravelmente bom em toda a sua carga de trabalho. Não é somente necessário gerenciar e acompanhar uma carga de trabalho ampla e variada sob qualquer circunstancia. Ele precisa ainda ser capaz de acompanhar o fluxo da mudança dos dados. Segundo, o ADW precisa permitir o desenvolvimento de novas aplicações de forma rápida e fácil.

O Teradata 12.0 é o próximo passo em direção a tornar fácil para todos a construção de um ADW de alto desempenho.

Que mudanças proporcionam novos níveis de desempenho?

O índice primário particionado (“PPI – Partitioned Primary Index”), foi estendido para múltiplos níveis, as estatísticas foram aprimoradas a fim de entregar melhores estimativas, várias melhorias no planejamento e estimativa de consultas (queries) foram adicionadas e os planos de execução (“explain plan”) foram incrementados com informações que anteriormente eram presumidas.

Como o PPI em vários níveis funciona ? (ML-PPI, Multi Level PPI)

A funcionalidade PPI atual permite que uma função determine o particionamento horizontal da tabela. Com o ML-PPI, as funcionalidades de particionamento são estendidas a vários níveis. Funções separadas dentro do ML-PPI definem o particionamento para cada nível, e podem ser utilizadas de forma conjunta ou independente possibilitando acesso muito mais granular aos dados desejados na tabela.

Por exemplo, uma companhia de seguros poderia particionar primeiro por estado (UF), depois por mês. As perguntas (queries) podem ser feitas por estado, mês ou ambos, possibilitando que a quantidade de dados acessados seja melhor adequada a analise em questão. Com a redução da quantidade de dados acessados o carga de I/O no sistema também é reduzida melhorando o desempenho geral do sistema (overall throughput).

Como as estimativas baseadas em estatísticas foram melhoradas?

Muitos e variados usuários submetem uma grande diversidade de queries, tornando a execução de estimativas precisas extremamente importante. As estatísticas são cruciais para guiar a otimização de queries baseada em custo.

O número de intervalos na estrutura de estatísticas foi dobrado, incrementando significativamente os detalhes, precisão e entendimento dos desvios (skew). As demografias das estatísticas de várias colunas (multiple column statistics) foram melhoradas com uma melhor figura sobre como os nulos aparecem nos dados.

O que acontece se as minhas estatísticas não são correntes?

Estatísticas desatualizadas podem levar a estimativas inválidas que por sua vez podem afetar negativamente o planejamento da querie. Balancear o custo de atualizar estatísticas versus o risco potencial de estatísticas imprecisas, frequentemente demantam “trade-offs”. Por exemplo, com determinadas colunas (especialmente datas), é necessário coletar estatísticas frequentemente para obter planos de execução razoáveis em queries que atuam no fim ou proximo ao fim dom do intervalo de dados.

O Teradata 12.0 reduz significativamente a perda de recursos (overhead), extrapolando valores quando as estatísticas coletadas não estão atualizadas, reduzindo a frequencia necessária de atualização estatísticas e o consumo de recursos total do ambiente.

Continuando com o cenário acima, quando estatísticas em uma coluna de datas não foi recentemente atualizada, o otimizador irá determinar quanto dado adicional foi incluído na tabela e irá estender as estatísticas contabilizando os novos intervalos de datas. O planejamento das queries será melhorado mesmo que as estatísticas não sejam coletadas diáriamente.

O que há de novo sobre estimativas e planejamento de queries ?

A complexidade das queries continua a aumentar com muitas views aninhadas, subqueries, tabelas derivadas e joins complexos. O otimizador do Teradata foi aprimorado para capturar informãções adicionais sobre cada nível aninhado da querie e então levar estas informações para o processo de planejamento. Também foram implementadas melhorias nas estimativas de custo e resultados de joins complexos. Novas regras para re-escrita de queries foram adicionadas endereçando várias oportunidades de otimização enviadas por usuários. A engrenagem de re-escrita pode agora executar múltiplas passadas, permitindo maiores oportunidades de otimização do plano. Planos de execução mais precisos e consistentes serão produzidos como resultado.

Que mudanças foram implementadas nos planos de execução (”explain plans”) ?

Tamanho dos spools, colunas chave para joins e agrupamento, nomes dos objetos referenciados na query, além de outras informações adicionais, foram incluídas na saída do plano de execução propiciando informações mais detalhadas para o usuário que estiver lendo o plano de execução.

Como o Teradata melhorou a capacidade de gerenciar a carga de trabalho ativa em constante crescimento?

Todas as implementações já citadas, relacionadas a melhoria das estimativas das queries ajudam também na precisão das regras de gerenciamento da carga de trabalho. Mais informações podem ser fornecidas sobre cada querie. Exceções de carga de trabalho (workload exceptions), foram extendidas e um “guarda de trânsito” (traffic cop) foi adicionado para automatizar mudanças nas regras de carga de trabalho (workload rules) em função de eventos do sistema ou definidos pelo usuário. Uma forma completamente nova para acesso as informações está sendo desenvolvida para fornecer informações de gerenciamento adicional para mais usuários do data warehouse.

O que é o “guarda de trânsito” (traffic cop) ?

Novos perfis de gerenciamento da carga de trabalho podem ser implementados quando as condições do sistema são alteradas ou quando eventos definidos pelo usuário, como por exemplo o final da janela de carga, ocorrem. Por exemplo, se um componente do sistema falha ou se o sistema estiver excepcionalmente carregado, o “guarda de trânsito” pode alterar as políticas de gerenciamento do sistema de acordo com as condições atuais do sistema.

Como usuários e aplicações fornecem mais informações sobre a carga de trabalho no sistema ?

Assim como marcando um pássaro para acompanhar seu vôo, uma marca na querie (”query band”) pode agora ser associada a cada querie. A marca pode conter qualquer número de atributos e valores associados proporcionando informações detalhadas que podem ser referenciadas pelas regras de gerenciamento da carga de trabalho durante a etapa de classificação de queries. Em seguida a informação é capturada pelo log, onde pode ser utilizada para analises futuras da carga que passou pelo sistema.

A marcação de queries (”querie banding”) é especialmente valiosa para aplicações que enviam trabalho através de um pool de sessões (”session pool”) tais como aplicações tradicionais, aplicações analíticas usando pool de sessões, aplicações BI utilizando pool de sessões e novas aplicações web.

Informações úteis para gerenciamento da carga de trabalho, ou para rastrear a utilização do data warehouse (como aplicação, unidade de trabalho, usuario solicitante, etc.), podem ser obtidas através da marcação de queries. Após a aplicação ser ajustada para prover estas informações, todo o acompanhamento e “linking” ao gerenciamento da carga de trabalho é manuseado automáticamente.

Quais exceções de carga de trabalho novas estarão disponíveis ?

Uma nova exceção de carga de trabalho a nível de sistema foi adicionada no Teradata 12.0. Agora, uma única regra pode ser usada para levantar exceções, independente do grupo de carga de trabalho da querie. Multiplas regras podem ser associadas a um único grupo de carga de trabalho possibilitando vários níveis de controle para requisições que não estão se comportanto como esperado.

Como as informações de gerenciamento do sistema serão fornecidas no futuro?

O Teradata 12.0 possui uma API para disponibilizar informações de gerenciamento do ambiente disponível via interface SQL padrão. Com esta funcionalidade, dados podem ser recuperados e configurações de controle alteradas. Isto torna as informações disponíveis através das interfaces ODBC e JDBC convencionais.

Sobre estas novas APIs, uma nova interface de gerenciamento do sistema foi implementada. Utilizando serviços Web e portais, uma nova forma de gerenciamento do sistema será entregue aos usuários administradores e finais.

Como o crescente fluxo de mudanças no data warehouse será manipulado ?

O contínuo fluxo de dados necessita ser carregado no banco de dados de forma eficiente e em seguida tem que ser copiado para backup sem afetar o fluxo. Se disponibilidade e “disaster recovery” requerem um sistema dual, os dados precisam sincronizados entre os 2 sistemas.

O que há de novo sobre o processo de aquisição e indegração de dados ?

Muitas implementações utilizam o processo de extração, carga e transformação (ELT), executando os passos de transformação e aplicação dentro da engrenagem de banco de dados, aproveitando a capacidade de processamento paralelo do banco de dados para realizar o trabalho. O Teradata 12.0 possui a capacidade de realizar um “merge em massa” (bulk merge, upsert), a partir de uma tabela de dados alterados, realizando todo o trabalho dentro do banco de dados.

Operações de inserção e atualização foram melhoradas com uma opção de “logar” erros em uma tabela de erros ao invés de iniciar um “abort”. Isto significa menor esforço para conseguir dados perfeitos antes de carregá-los. Em conjunto estas funções melhoram significativamente a capacidade ETL para data warehouse.

O ELT usando os SQL em lote (bulk SQL operations) elimina as restrições dos utilitários de carga, permitindo maior utilização de técnicas de “tuning” físico como índices secundários e join indexes e permitindo maior utilização de funções ativas (triggers, integridade referencial).

Como efetuar backup sem afetar um processo de carga contínuo ?

O “archive online” permite agora que o backup seja feito sem interrupção do processo de carga. Ele irá automaticamente iniciar um ckeckpoint, gravar um log de mudanças, salvar o log e copiar junto com o backup. No processo de recuperação (restore), o log será automaticamente recuperado e processado até o checkpoint garantindo que uma recuperação consistente tenha sido feita.

Publicação arquivada em: Sem Categoria

Enviar por e-mail | Hits para esta publicação: 1140