Design e desempenho para migrações Teradata

Este artigo faz parte de uma série de sete partes que fornece orientação sobre como migrar do Teradata para o Azure Synapse Analytics. O foco deste artigo são as práticas recomendadas para design e desempenho.

Descrição geral

Muitos usuários existentes dos sistemas de data warehouse da Teradata querem aproveitar as inovações fornecidas pelos modernos ambientes de nuvem. Os ambientes de nuvem de infraestrutura como serviço (IaaS) e plataforma como serviço (PaaS) permitem delegar tarefas como manutenção de infraestrutura e desenvolvimento de plataforma ao provedor de nuvem.

Embora o Teradata e o Azure Synapse Analytics sejam bancos de dados SQL que usam técnicas de processamento paralelo maciço (MPP) para obter alto desempenho de consulta em volumes de dados excepcionalmente grandes, há algumas diferenças básicas na abordagem:

• Os sistemas Teradata herdados geralmente são instalados no local e usam hardware proprietário, enquanto o Azure Synapse é baseado em nuvem e usa o Armazenamento do Azure e recursos de computação.

• Como os recursos de armazenamento e computação são separados no ambiente do Azure e têm capacidade de dimensionamento elástico, esses recursos podem ser dimensionados para cima ou para baixo de forma independente.

• Você pode pausar ou redimensionar o Azure Synapse conforme necessário para reduzir a utilização de recursos e o custo.

• Atualizar uma configuração do Teradata é uma tarefa importante que envolve hardware físico extra e reconfiguração ou recarga de banco de dados potencialmente demorada.

O Microsoft Azure é um ambiente de nuvem globalmente disponível, altamente seguro e escalável que inclui o Azure Synapse e um ecossistema de ferramentas e recursos de suporte. O diagrama seguinte resume o ecossistema do Azure Synapse.

O Azure Synapse fornece o melhor desempenho de banco de dados relacional usando técnicas como MPP e vários níveis de cache automatizado para dados usados com freqüência. Você pode ver os resultados dessas técnicas em benchmarks independentes, como o executado recentemente pela GigaOm, que compara o Azure Synapse a outras ofertas populares de data warehouse na nuvem. Os clientes que migram para o ambiente do Azure Synapse veem muitos benefícios, incluindo:

• Melhor desempenho e preço/desempenho.

• Maior agilidade e menor tempo de valorização.

• Implantação de servidor e desenvolvimento de aplicativos mais rápidos.

• Escalabilidade elástica — pague apenas pelo uso real.

• Maior segurança/conformidade.

• Custos reduzidos de armazenamento e recuperação de desastres.

• Menor TCO geral, melhor controle de custos e despesas operacionais simplificadas (OPEX).

Para maximizar esses benefícios, migre dados e aplicativos novos ou existentes para a plataforma Azure Synapse. Em muitas organizações, a migração inclui a movimentação de um data warehouse existente de uma plataforma local herdada, como o Teradata, para o Azure Synapse. Em um alto nível, o processo de migração inclui estas etapas:

Este artigo fornece informações gerais e diretrizes para otimização de desempenho ao migrar um data warehouse de um ambiente Netezza existente para o Azure Synapse. O objetivo da otimização de desempenho é obter o mesmo ou melhor desempenho de data warehouse no Azure Synapse após a migração do esquema.

Considerações de design

Âmbito da migração

Quando estiver se preparando para migrar de um ambiente Teradata, considere as seguintes opções de migração.

Escolha a carga de trabalho para a migração inicial

Normalmente, os ambientes Teradata herdados evoluíram ao longo do tempo para abranger várias áreas temáticas e cargas de trabalho mistas. Ao decidir por onde começar em um projeto de migração, escolha uma área na qual você poderá:

• Comprove a viabilidade da migração para o Azure Synapse oferecendo rapidamente os benefícios do novo ambiente.

• Permita que sua equipe técnica interna ganhe experiência relevante com os processos e ferramentas que eles usarão quando migrarem outras áreas.

• Crie um modelo para migrações adicionais que seja específico para o ambiente Teradata de origem e as ferramentas e processos atuais que já estão em vigor.

Um bom candidato para uma migração inicial de um ambiente Teradata suporta os itens anteriores e:

• Implementa uma carga de trabalho de BI/Analytics em vez de uma carga de trabalho OLTP (processamento de transações online).

• Tem um modelo de dados, como um esquema de estrela ou floco de neve, que pode ser migrado com modificações mínimas.

O volume de dados migrados em uma migração inicial deve ser grande o suficiente para demonstrar os recursos e benefícios do ambiente do Azure Synapse, mas não muito grande para demonstrar valor rapidamente. Um tamanho na faixa de 1-10 terabytes é típico.

Para seu projeto de migração inicial, minimize o risco, o esforço e o tempo de migração para que você possa ver rapidamente os benefícios do ambiente de nuvem do Azure, confine o escopo da migração apenas aos data marts, como a parte OLAP DB de um armazém Teradata. As abordagens lift-and-shift e phased migration limitam o escopo da migração inicial apenas aos data marts e não abordam aspetos mais amplos da migração, como migração ETL e migração de dados históricos. No entanto, você pode abordar esses aspetos em fases posteriores do projeto, uma vez que a camada de data mart migrada é preenchida com dados e os processos de compilação necessários.

Migração de elevação e deslocamento versus abordagem faseada

Em geral, existem dois tipos de migração, independentemente da finalidade e do âmbito da migração planeada: o lift and shift no estado em que se encontra e uma abordagem faseada que incorpora alterações.

Migração lift-and-shift

Em uma migração de elevação e deslocamento, um modelo de dados existente, como um esquema em estrela, é migrado inalterado para a nova plataforma Azure Synapse. Essa abordagem minimiza o risco e o tempo de migração, reduzindo o trabalho necessário para obter os benefícios da mudança para o ambiente de nuvem do Azure. A migração de elevação e deslocamento é uma boa opção para estes cenários:

• Você tem um ambiente Teradata existente com um único data mart para migrar, ou
• Você tem um ambiente Teradata existente com dados que já estão em um esquema de estrela ou floco de neve bem projetado, ou
• Você está sob pressão de tempo e custo para migrar para um ambiente de nuvem moderno.

Abordagem faseada que incorpora alterações

Se um data warehouse herdado tiver evoluído durante um longo período de tempo, talvez seja necessário reprojetá-lo para manter os níveis de desempenho necessários. Você também pode ter que fazer uma nova engenharia para dar suporte a novos dados, como fluxos de Internet das Coisas (IoT). Como parte do processo de reengenharia, migre para o Azure Synapse para obter os benefícios de um ambiente de nuvem escalável. A migração também pode incluir uma alteração no modelo de dados subjacente, como uma mudança de um modelo Inmon para um cofre de dados.

A Microsoft recomenda mover seu modelo de dados existente no estado em que se encontra para o Azure (opcionalmente usando uma instância Teradata de VM no Azure) e usar o desempenho e a flexibilidade do ambiente do Azure para aplicar as alterações de reengenharia. Dessa forma, você pode usar os recursos do Azure para fazer as alterações sem afetar o sistema de origem existente.

Usar uma instância do Azure VM Teradata como parte de uma migração

Ao migrar de um ambiente Teradata local, você pode aproveitar o armazenamento em nuvem e a escalabilidade elástica no Azure para criar uma instância Teradata em uma VM. Essa abordagem aloca a instância Teradata com o ambiente Synapse do Azure de destino. Você pode usar utilitários Teradata padrão, como o Teradata Parallel Data Transporter, para mover com eficiência o subconjunto de tabelas Teradata que estão sendo migradas para a instância da VM. Em seguida, todas as outras tarefas de migração podem ocorrer no ambiente do Azure. Esta abordagem tem várias vantagens:

• Após a replicação inicial dos dados, o sistema de origem não é afetado pelas tarefas de migração.

• Interfaces, ferramentas e utilitários familiares do Teradata estão disponíveis no ambiente do Azure.

• O ambiente do Azure evita quaisquer problemas potenciais com a disponibilidade de largura de banda de rede entre o sistema de origem local e o sistema de destino na nuvem.

• Ferramentas como o Azure Data Factory podem chamar utilitários como o Teradata Parallel Transporter para migrar dados de forma eficiente e rápida.

• Você pode orquestrar e controlar o processo de migração inteiramente dentro do ambiente do Azure.

Usar o Azure Data Factory para implementar uma migração orientada por metadados

Você pode automatizar e orquestrar o processo de migração usando os recursos do ambiente do Azure. Essa abordagem minimiza o impacto no desempenho no ambiente Netezza existente, que pode já estar sendo executado perto da capacidade.

O Azure Data Factory é um serviço de integração de dados baseado na nuvem que suporta a criação de fluxos de trabalho orientados por dados na nuvem que orquestram e automatizam a movimentação e a transformação de dados. Você pode usar o Data Factory para criar e agendar fluxos de trabalho controlados por dados (pipelines) que ingerem dados de armazenamentos de dados diferentes. O Data Factory pode processar e transformar dados usando serviços de computação como Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Quando você estiver planejando usar os recursos do Data Factory para gerenciar o processo de migração, crie metadados que listem todas as tabelas de dados a serem migradas e sua localização.

Diferenças de design entre o Teradata e o Azure Synapse

Como mencionado anteriormente, há algumas diferenças básicas na abordagem entre os bancos de dados Teradata e Azure Synapse Analytics e essas diferenças são discutidas a seguir.

Vários bancos de dados versus um único banco de dados e esquemas

O ambiente Teradata geralmente contém vários bancos de dados separados. Por exemplo, poderia haver bancos de dados separados para: tabelas de ingestão e preparo de dados, tabelas de armazém principais e data marts (às vezes referidos como camada semântica). Os processos de pipeline ETL ou ELT podem implementar junções entre bancos de dados e mover dados entre os bancos de dados separados.

Por outro lado, o ambiente do Azure Synapse contém um único banco de dados e usa esquemas para separar tabelas em grupos logicamente separados. Recomendamos que você use uma série de esquemas no banco de dados Synapse do Azure de destino para imitar os bancos de dados separados migrados do ambiente Teradata. Se o ambiente Teradata já usa esquemas, talvez seja necessário usar uma nova convenção de nomenclatura ao mover as tabelas e exibições Teradata existentes para o novo ambiente. Por exemplo, você pode concatenar o esquema Teradata existente e os nomes de tabela no novo nome de tabela do Azure Synapse e usar nomes de esquema no novo ambiente para manter os nomes de banco de dados separados originais. Se a nomenclatura da consolidação de esquema tiver pontos, o Azure Synapse Spark poderá ter problemas. Embora você possa usar exibições SQL sobre as tabelas subjacentes para manter as estruturas lógicas, há desvantagens potenciais nessa abordagem:

• As exibições no Azure Synapse são somente leitura, portanto, todas as atualizações dos dados devem ocorrer nas tabelas base subjacentes.

• Pode já existir uma ou mais camadas de vistas e adicionar uma camada extra de vistas pode afetar o desempenho e a capacidade de suporte porque as vistas aninhadas são difíceis de resolver.

Considerações sobre a tabela

Quando você migra tabelas entre ambientes diferentes, normalmente apenas os dados brutos e os metadados que os descrevem são migrados fisicamente. Outros elementos de banco de dados do sistema de origem, como índices, geralmente não são migrados porque podem ser desnecessários ou implementados de forma diferente no novo ambiente. As otimizações de desempenho no ambiente de origem, como índices, indicam onde você pode adicionar otimização de desempenho no novo ambiente. Por exemplo, se uma tabela dentro do ambiente Teradata de origem tiver um índice secundário não exclusivo (NUSI), isso sugere que um índice não clusterizado deve ser criado no Azure Synapse. Outras técnicas nativas de otimização de desempenho, como a replicação de tabelas, podem ser mais aplicáveis do que a criação direta de índices semelhantes.

Alta disponibilidade para o banco de dados

O Teradata oferece suporte à replicação de dados entre nós por meio da FALLBACK opção, que replica linhas de tabela que residem fisicamente em um determinado nó para outro nó dentro do sistema. Essa abordagem garante que os dados não serão perdidos se houver uma falha de nó e fornece a base para cenários de failover.

O objetivo da arquitetura de alta disponibilidade no Azure Synapse Analytics é garantir que seu banco de dados esteja ativo e funcionando 99,9% do tempo, sem se preocupar com o impacto das operações de manutenção e interrupções. Para obter mais informações sobre o SLA, consulte SLA para Azure Synapse Analytics. O Azure lida automaticamente com tarefas de manutenção críticas, como patches, backups e atualizações do Windows e SQL. O Azure também lida automaticamente com eventos não planejados, como falhas no hardware, software ou rede subjacentes.

O backup do armazenamento de dados no Azure Synapse é feito automaticamente com instantâneos. Esses instantâneos são um recurso interno do serviço que cria pontos de restauração. Não tem de ativar esta capacidade. Atualmente, os usuários não podem excluir pontos de restauração automática que o serviço usa para manter contratos de nível de serviço (SLAs) para recuperação.

O pool SQL dedicado do Azure Synapse tira instantâneos do data warehouse ao longo do dia para criar pontos de restauração que ficam disponíveis por sete dias. Este período de retenção não pode ser alterado. O Azure Synapse dá suporte a um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de oito horas. Pode restaurar o seu armazém de dados na região principal a partir de qualquer um dos instantâneos tirados nos últimos sete dias. Se você precisar de backups mais granulares, poderá usar outra opção definida pelo usuário.

Tipos de tabela Teradata não suportados

O Teradata suporta tipos de tabela especiais para séries temporais e dados temporais. A sintaxe e algumas das funções para esses tipos de tabela não são suportadas diretamente no Azure Synapse. No entanto, você pode migrar os dados para uma tabela padrão no Azure Synapse mapeando para tipos de dados apropriados e indexando ou particionando a coluna de data/hora.

O Teradata implementa a funcionalidade de consulta temporal usando a reconfiguração de consulta para adicionar filtros adicionais dentro de uma consulta temporal para limitar o intervalo de datas aplicável. Se você planeja migrar essa funcionalidade do ambiente Teradata de origem, adicione a filtragem adicional às consultas temporais relevantes.

O ambiente do Azure dá suporte a insights de séries temporais para análises complexas em dados de séries cronológicas em escala. Esta funcionalidade destina-se a aplicações de análise de dados IoT.

Diferenças de sintaxe do SQL DML

Existem diferenças de sintaxe do SQL Data Manipulation Language (DML) entre o Teradata SQL e o Azure Synapse T-SQL:

• QUALIFY: Teradata suporta o QUALIFY operador. Por exemplo:

  SELECT col1
  FROM tab1
  WHERE col1='XYZ'
  QUALIFY ROW_NUMBER () OVER (PARTITION by
  col1 ORDER BY col1) = 1;
  

  A sintaxe equivalente do Azure Synapse é:

  SELECT * FROM (
  SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
  FROM tab1 WHERE col1='XYZ'
  ) WHERE rn = 1;
  

• Aritmética de data: o Azure Synapse tem operadores como DATEADD e DATEDIFF, que podem ser usados em DATE campos ou DATETIME . O Teradata suporta subtração direta em datas como SELECT DATE1 - DATE2 FROM...

• GROUP BY: para o ordinal, forneça explicitamente um nome de GROUP BY coluna T-SQL.

• LIKE ANY: Teradata suporta LIKE ANY sintaxe como:

  SELECT * FROM CUSTOMER
  WHERE POSTCODE LIKE ANY
  ('CV1%', 'CV2%', 'CV3%');
  

  O equivalente na sintaxe do Azure Synapse é:

  SELECT * FROM CUSTOMER
  WHERE
  (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
  

• Dependendo das configurações do sistema, as comparações de caracteres no Teradata podem não diferenciar maiúsculas de minúsculas por padrão. No Azure Synapse, as comparações de caracteres diferenciam sempre maiúsculas de minúsculas.

Funções, procedimentos armazenados, gatilhos e sequências

Ao migrar um data warehouse de um ambiente maduro como o Teradata, você provavelmente precisará migrar elementos diferentes de tabelas e exibições simples. Os exemplos incluem funções, procedimentos armazenados, gatilhos e sequências. Verifique se as ferramentas no ambiente do Azure podem substituir a funcionalidade de funções, procedimentos armazenados e sequências, porque geralmente é mais eficiente usar ferramentas internas do Azure do que recodificar esses elementos para o Azure Synapse.

Como parte da fase de preparação, crie um inventário de objetos que precisam ser migrados, defina um método para manipulá-los e aloque recursos apropriados em seu plano de migração.

Os parceiros de integração de dados oferecem ferramentas e serviços que podem automatizar a migração de funções, procedimentos armazenados e sequências.

As seções a seguir discutem ainda mais a migração de funções, procedimentos armazenados e sequências.

Funções

Como acontece com a maioria dos produtos de banco de dados, o Teradata suporta funções definidas pelo sistema e pelo usuário dentro de uma implementação SQL. Quando você migra uma plataforma de banco de dados herdada para o Azure Synapse, as funções comuns do sistema geralmente podem ser migradas sem alterações. Algumas funções do sistema podem ter uma sintaxe ligeiramente diferente, mas quaisquer alterações necessárias podem ser automatizadas.

Para funções do sistema Teradata ou funções arbitrárias definidas pelo usuário que não têm equivalente no Azure Synapse, recodifice essas funções usando uma linguagem de ambiente de destino. O Azure Synapse usa a linguagem Transact-SQL para implementar funções definidas pelo usuário.

Procedimentos armazenados

A maioria dos produtos de banco de dados modernos suporta procedimentos de armazenamento dentro do banco de dados. Teradata fornece a linguagem SPL para esta finalidade. Um procedimento armazenado normalmente contém instruções SQL e lógica de procedimento e retorna dados ou um status.

O Azure Synapse dá suporte a procedimentos armazenados usando T-SQL, portanto, você precisa recodificar quaisquer procedimentos armazenados migrados nesse idioma.

Acionadores

O Azure Synapse não dá suporte à criação de gatilhos, mas a criação de gatilhos pode ser implementada usando o Azure Data Factory.

Sequências

O Azure Synapse lida com sequências de maneira semelhante ao Teradata e você pode implementar sequências usando colunas IDENTITY ou código SQL que gera o próximo número de sequência em uma série. Uma sequência fornece valores numéricos exclusivos que você pode usar como valores de chave substituta para chaves primárias.

Extrair metadados e dados de um ambiente Teradata

Geração de linguagem de definição de dados (DDL)

O padrão ANSI SQL define a sintaxe básica para comandos DDL (Data Definition Language). Alguns comandos DDL, como CREATE TABLE e CREATE VIEW, são comuns ao Teradata e ao Azure Synapse, mas também fornecem recursos específicos de implementação, como indexação, distribuição de tabela e opções de particionamento.

Você pode editar Teradata CREATE TABLE e CREATE VIEW scripts existentes para obter definições equivalentes no Azure Synapse. Para fazer isso, talvez seja necessário usar tipos de dados modificados e remover ou modificar cláusulas específicas do Teradata, como FALLBACK.

No entanto, todas as informações que especificam as definições atuais de tabelas e exibições dentro do ambiente Teradata existente são mantidas nas tabelas do catálogo do sistema. Estas tabelas são a melhor fonte desta informação, uma vez que é garantido que estão atualizadas e completas. A documentação mantida pelo usuário pode não estar sincronizada com as definições de tabela atuais.

No ambiente Teradata, as tabelas do catálogo do sistema especificam a definição atual de tabela e exibição. Ao contrário da documentação mantida pelo usuário, as informações do catálogo do sistema estão sempre completas e sincronizadas com as definições de tabela atuais. Usando modos de exibição no catálogo, como DBC.ColumnsV, você pode acessar informações do catálogo do sistema para gerar CREATE TABLE instruções DDL que criam tabelas equivalentes no Azure Synapse.

Você também pode usar ferramentas de migração e ETL de terceiros que processam informações do catálogo do sistema para obter resultados semelhantes.

Extração de dados do Teradata

Você pode extrair dados brutos de tabelas Teradata para arquivos delimitados simples, como arquivos CSV, usando utilitários Teradata padrão como Basic Teradata Query (BTEQ), Teradata FastExport ou Teradata Parallel Transporter (TPT). Use o TPT para extrair dados da tabela da forma mais eficiente possível. O TPT usa vários fluxos paralelos do FastExport para alcançar a taxa de transferência mais alta.

Chame o TPT diretamente do Azure Data Factory. Essa é a abordagem recomendada para a migração de dados de instâncias locais Teradata e instâncias Teradata executadas em uma VM no ambiente do Azure.

Os arquivos de dados extraídos devem conter texto delimitado em formato CSV, Optimized Row Columnar (ORC) ou Parquet.

Para obter mais informações sobre como migrar dados e ETL de um ambiente Teradata, consulte Migração de dados, ETL e carga para migrações Teradata.

Recomendações de desempenho para migrações Teradata

O objetivo da otimização de desempenho é o mesmo ou melhor desempenho do data warehouse após a migração para o Azure Synapse.

Diferenças na abordagem de ajuste de desempenho

Esta seção destaca as diferenças de implementação de ajuste de desempenho de baixo nível entre o Teradata e o Azure Synapse.

Opções de distribuição de dados

Para desempenho, o Azure Synapse foi projetado com arquitetura de vários nós e usa processamento paralelo. Para otimizar o desempenho da tabela individual no Azure Synapse, você pode definir uma opção de distribuição de dados em CREATE TABLE instruções usando a DISTRIBUTION instrução. Por exemplo, você pode especificar uma tabela distribuída por hash, que distribui linhas de tabela entre nós de computação usando uma função de hash determinística. O objetivo é reduzir a quantidade de dados movidos entre nós de processamento ao executar uma consulta.

Para junções de tabela grande a tabela grande, o hash distribua uma ou, idealmente, ambas as tabelas em uma das colunas de junção, que tem uma ampla gama de valores para ajudar a garantir uma distribuição uniforme. Execute o processamento de junção localmente porque as linhas de dados que serão unidas são colocadas no mesmo nó de processamento.

O Azure Synapse também dá suporte a junções locais entre uma tabela pequena e uma tabela grande por meio da replicação de tabela pequena. Por exemplo, considere uma tabela de dimensões pequenas e uma tabela de fatos grande dentro de um modelo de esquema em estrela. O Azure Synapse pode replicar a tabela de dimensão menor em todos os nós para garantir que o valor de qualquer chave de associação para a tabela grande tenha uma linha de dimensão correspondente disponível localmente. A sobrecarga de replicação de tabela de dimensão é relativamente baixa para uma tabela de dimensão pequena. Para tabelas de grandes dimensões, uma abordagem de distribuição de hash é mais apropriada. Para obter mais informações sobre opções de distribuição de dados, consulte Diretrizes de design para usar tabelas replicadas e Orientação para projetar tabelas distribuídas.

Indexação de dados

O Azure Synapse dá suporte a várias opções de indexação definidas pelo usuário que são diferentes das opções de indexação implementadas no Teradata. Para obter mais informações sobre as diferentes opções de indexação no Azure Synapse, consulte Índices em tabelas de pool SQL dedicadas.

Os índices existentes no ambiente Teradata de origem fornecem uma indicação útil do uso de dados e das colunas candidatas para indexação no ambiente do Azure Synapse.

Criação de partições de dados

Em um data warehouse corporativo, as tabelas de fatos podem conter bilhões de linhas. O particionamento otimiza a manutenção e o desempenho de consulta dessas tabelas, dividindo-as em partes separadas para reduzir a quantidade de dados processados. No Azure Synapse, a CREATE TABLE instrução define a especificação de particionamento para uma tabela. Particione apenas tabelas muito grandes e certifique-se de que cada partição contém pelo menos 60 milhões de linhas.

Você só pode usar um campo por tabela para particionamento. Esse campo geralmente é um campo de data porque muitas consultas são filtradas por data ou intervalo de datas. É possível alterar o particionamento de uma tabela após o carregamento inicial usando a CREATE TABLE AS instrução (CTAS) para recriar a tabela com uma nova distribuição. Para obter uma discussão detalhada sobre particionamento no Azure Synapse, consulte Particionamento de tabelas no pool SQL dedicado.

Estatísticas da tabela de dados

Você deve garantir que as estatísticas em tabelas de dados estejam atualizadas, criando uma etapa de estatísticas para trabalhos ETL/ELT.

PolyBase ou COPY INTO para carregamento de dados

O PolyBase suporta o carregamento eficiente de grandes quantidades de dados para um armazém de dados usando fluxos de carregamento paralelos. Para obter mais informações, consulte Estratégia de carregamento de dados do PolyBase.

COPY INTO também suporta ingestão de dados de alta taxa de transferência e:

• Recuperação de dados de todos os arquivos dentro de uma pasta e subpastas.

• Recuperação de dados de vários locais na mesma conta de armazenamento. Você pode especificar vários locais usando caminhos separados por vírgula.

• Azure Data Lake Storage (ADLS) e Azure Blob Storage.

• Formatos de arquivo CSV, PARAT e ORC.

Gestão de cargas de trabalho

A execução de cargas de trabalho mistas pode representar desafios de recursos em sistemas ocupados. Um esquema de gerenciamento de carga de trabalho bem-sucedido gerencia efetivamente os recursos, garante uma utilização altamente eficiente dos recursos e maximiza o retorno sobre o investimento (ROI). A classificação da carga de trabalho, a importância da carga de trabalho e o isolamento da carga de trabalho oferecem mais controle sobre como a carga de trabalho utiliza os recursos do sistema.

O guia de gerenciamento de carga de trabalho descreve as técnicas para analisar a carga de trabalho, gerenciar e monitorar a importância da carga de trabalho e as etapas para converter uma classe de recurso em um grupo de carga de trabalho. Use o portal do Azure e as consultas T-SQL em DMVs para monitorar a carga de trabalho e garantir que os recursos aplicáveis sejam utilizados de forma eficiente.

Próximos passos

Para saber mais sobre ETL e carga para migração Teradata, consulte o próximo artigo desta série: Migração de dados, ETL e carga para migrações Teradata.