Data migration, ETL, and load for Teradata migrations

This article is part two of a seven-part series that provides guidance on how to migrate from Teradata to Azure Synapse Analytics. O foco deste artigo são as práticas recomendadas para ETL e migração de carga.

Considerações sobre migração de dados

Initial decisions for data migration from Teradata

When migrating a Teradata data warehouse, you need to ask some basic data-related questions. Por exemplo:

• As estruturas de tabela não utilizadas devem ser migradas?

• Qual é a melhor abordagem de migração para minimizar o risco e o impacto no usuário?

• When migrating data marts: stay physical or go virtual?

The next sections discuss these points within the context of migration from Teradata.

Migrar tabelas não utilizadas?

Faz sentido migrar apenas as tabelas que estão em uso no sistema existente. As tabelas que não estão ativas podem ser arquivadas em vez de migradas, para que os dados estejam disponíveis, se necessário, no futuro. É melhor usar metadados do sistema e arquivos de log em vez de documentação para determinar quais tabelas estão em uso, porque a documentação pode estar desatualizada.

If enabled, Teradata system catalog tables and logs contain information that can determine when a given table was last accessed—which can in turn be used to decide whether a table is a candidate for migration.

Here's an example query on DBC.Tables that provides the date of last access and last modification:

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

If logging is enabled and the log history is accessible, other information, such as SQL query text, is available in table DBQLogTbl and associated logging tables. For more information, see Teradata log history.

Qual é a melhor abordagem de migração para minimizar o risco e o impacto nos usuários?

Essa pergunta surge com frequência porque as empresas podem querer diminuir o impacto das mudanças no modelo de dados do data warehouse para melhorar a agilidade. As empresas geralmente veem uma oportunidade de modernizar ou transformar ainda mais seus dados durante uma migração de ETL. Esta abordagem acarreta um risco mais elevado porque altera múltiplos fatores em simultâneo, dificultando a comparação dos resultados do sistema antigo com o novo. Making data model changes here could also affect upstream or downstream ETL jobs to other systems. Devido a esse risco, é melhor redesenhar nessa escala após a migração do data warehouse.

Mesmo que um modelo de dados seja intencionalmente alterado como parte da migração geral, é uma boa prática migrar o modelo existente como está para o Azure Synapse, em vez de fazer qualquer reengenharia na nova plataforma. Esta abordagem minimiza o efeito nos sistemas de produção existentes, ao mesmo tempo que beneficia do desempenho e da escalabilidade elástica da plataforma Azure para tarefas pontuais de reengenharia.

When migrating from Teradata, consider creating a Teradata environment in a VM within Azure as a stepping-stone in the migration process.

Use a VM Teradata instance as part of a migration

One optional approach for migrating from an on-premises Teradata environment is to leverage the Azure environment to create a Teradata instance in a VM within Azure, collocated with the target Azure Synapse environment. This is possible because Azure provides cheap cloud storage and elastic scalability.

With this approach, standard Teradata utilities, such as Teradata Parallel Data Transporter—or third-party data replication tools, such as Attunity Replicate—can be used to efficiently move the subset of Teradata tables that need to be migrated to the VM instance. Then, all migration tasks can take place within the Azure environment. Esta abordagem tem várias vantagens:

• After the initial replication of data, migration tasks don't impact the source system.

• The Azure environment has familiar Teradata interfaces, tools, and utilities.

• The Azure environment provides network bandwidth availability between the on-premises source system and the cloud target system.

• Tools like Azure Data Factory can efficiently call utilities like Teradata Parallel Transporter to migrate data quickly and easily.

• O processo de migração é orquestrado e controlado inteiramente no ambiente do Azure.

When migrating data marts: stay physical or go virtual?

In legacy Teradata data warehouse environments, it's common practice to create several data marts that are structured to provide good performance for ad hoc self-service queries and reports for a given department or business function within an organization. Como tal, um data mart normalmente consiste em um subconjunto do data warehouse e contém versões agregadas dos dados em um formato que permite aos usuários consultar facilmente esses dados com tempos de resposta rápidos por meio de ferramentas de consulta fáceis de usar, como Microsoft Power BI, Tableau ou MicroStrategy. Este formulário é normalmente um modelo de dados dimensionais. One use of data marts is to expose the data in a usable form, even if the underlying warehouse data model is something different, such as a data vault.

Você pode usar data marts separados para unidades de negócios individuais dentro de uma organização para implementar regimes robustos de segurança de dados, permitindo apenas que os usuários acessem data marts específicos que são relevantes para eles e eliminando, ofuscando ou anonimizando dados confidenciais.

Se esses data marts forem implementados como tabelas físicas, eles exigirão recursos de armazenamento adicionais para armazená-los e processamento adicional para criá-los e atualizá-los regularmente. Além disso, os dados no mart estarão tão atuais quanto a última operação de atualização e, portanto, podem ser inadequados para dashboards que lidam com dados altamente voláteis.

Com o advento de arquiteturas MPP escaláveis de custo relativamente baixo, como o Azure Synapse, e as características de desempenho inerentes a essas arquiteturas, pode ser que você possa fornecer funcionalidade de data mart sem ter que instanciar o mart como um conjunto de tabelas físicas. Isso é conseguido virtualizando efetivamente os data marts por meio de exibições SQL no data warehouse principal ou por meio de uma camada de virtualização usando recursos como exibições no Azure ou os produtos de visualização de parceiros da Microsoft. Essa abordagem simplifica ou elimina a necessidade de armazenamento adicional e processamento de agregação e reduz o número total de objetos de banco de dados a serem migrados.

Há outro benefício potencial nessa abordagem. Ao implementar a lógica de agregação e junção dentro de uma camada de virtualização e apresentar ferramentas de relatórios externos por meio de uma exibição virtualizada, o processamento necessário para criar essas exibições é "empurrado para baixo" no data warehouse, que geralmente é o melhor lugar para executar junções, agregações e outras operações relacionadas em grandes volumes de dados.

Os principais drivers para escolher uma implementação de data mart virtual em vez de um data mart físico são:

• Mais agilidade: um data mart virtual é mais fácil de alterar do que as tabelas físicas e os processos ETL associados.

• Menor custo total de propriedade: uma implementação virtualizada requer menos armazenamentos de dados e cópias de dados.

• Eliminação de trabalhos de ETL para migrar e simplificar a arquitetura de data warehouse em um ambiente virtualizado.

• Desempenho: embora os data marts físicos tenham sido historicamente mais eficientes, os produtos de virtualização agora implementam técnicas inteligentes de cache para mitigar.

Data migration from Teradata

Compreender os seus dados

Parte do planejamento da migração é entender em detalhes o volume de dados que precisa ser migrado, pois isso pode afetar as decisões sobre a abordagem de migração. Use metadados do sistema para determinar o espaço físico ocupado pelos "dados brutos" dentro das tabelas a serem migradas. Neste contexto, "dados brutos" significa a quantidade de espaço utilizada pelas linhas de dados dentro de uma tabela, excluindo despesas gerais como índices e compressão. Isto é especialmente verdadeiro para as maiores tabelas de fatos, uma vez que estas normalmente compreendem mais de 95% dos dados.

Você pode obter um número preciso para o volume de dados a ser migrado para uma determinada tabela extraindo uma amostra representativa dos dados — por exemplo, um milhão de linhas — para um arquivo de dados ASCII simples delimitado não compactado. Em seguida, use o tamanho desse arquivo para obter um tamanho médio de dados brutos por linha dessa tabela. Por fim, multiplique esse tamanho médio pelo número total de linhas na tabela completa para fornecer um tamanho de dados brutos para a tabela. Use esse tamanho de dados brutos em seu planejamento.

Considerações sobre migração de ETL

Initial decisions regarding Teradata ETL migration

For ETL/ELT processing, legacy Teradata data warehouses may use custom-built scripts using Teradata utilities such as BTEQ and Teradata Parallel Transporter (TPT), or third-party ETL tools such as Informatica or Ab Initio. Sometimes, Teradata data warehouses use a combination of ETL and ELT approaches that's evolved over time. When planning a migration to Azure Synapse, you need to determine the best way to implement the required ETL/ELT processing in the new environment while minimizing the cost and risk involved. Para saber mais sobre o processamento de ETL e ELT, consulte Abordagem de design ELT vs ETL.

As seções a seguir discutem as opções de migração e fazem recomendações para vários casos de uso. Este fluxograma resume uma abordagem:

O primeiro passo é sempre construir um inventário dos processos ETL/ELT que precisam ser migrados. Tal como acontece com outras etapas, é possível que os recursos padrão "internos" do Azure tornem desnecessária a migração de alguns processos existentes. Para fins de planejamento, é importante entender a escala da migração a ser realizada.

No fluxograma anterior, a decisão 1 está relacionada a uma decisão de alto nível sobre migrar para um ambiente totalmente nativo do Azure. Se você estiver migrando para um ambiente totalmente nativo do Azure, recomendamos que reprojete o processamento de ETL usando Pipelines e atividades no Azure Data Factory ou Azure Synapse Pipelines. Se você não estiver migrando para um ambiente totalmente nativo do Azure, a decisão 2 será se uma ferramenta ETL de terceiros existente já está em uso.

In the Teradata environment, some or all ETL processing may be performed by custom scripts using Teradata-specific utilities like BTEQ and TPT. In this case, your approach should be to re-engineer using Data Factory.

Se uma ferramenta ETL de terceiros já estiver em uso, e especialmente se houver um grande investimento em habilidades ou vários fluxos de trabalho e agendas existentes usarem essa ferramenta, a decisão 3 será se a ferramenta pode dar suporte eficiente ao Azure Synapse como um ambiente de destino. Idealmente, a ferramenta incluirá conectores "nativos" que podem aproveitar recursos do Azure, como PolyBase ou COPY INTO, para o carregamento de dados mais eficiente. Há uma maneira de chamar um processo externo, como PolyBase ou COPY INTO, e passar os parâmetros apropriados. Nesse caso, aproveite as habilidades e fluxos de trabalho existentes, com o Azure Synapse como o novo ambiente de destino.

Se você decidir manter uma ferramenta ETL de terceiros existente, pode haver benefícios em executar essa ferramenta no ambiente do Azure (em vez de em um servidor ETL local existente) e fazer com que o Azure Data Factory lide com a orquestração geral dos fluxos de trabalho existentes. Um benefício específico é que menos dados precisam ser baixados do Azure, processados e, em seguida, carregados de volta no Azure. Portanto, a decisão 4 é deixar a ferramenta existente em execução as-is ou movê-la para o ambiente do Azure para obter benefícios de custo, desempenho e escalabilidade.

Re-engineer existing Teradata-specific scripts

If some or all the existing Teradata warehouse ETL/ELT processing is handled by custom scripts that utilize Teradata-specific utilities, such as BTEQ, MLOAD, or TPT, these scripts need to be recoded for the new Azure Synapse environment. Similarly, if ETL processes were implemented using stored procedures in Teradata, then these will also have to be recoded.

Alguns elementos do processo ETL são fáceis de migrar, por exemplo, por meio de uma simples carga de dados em massa em uma tabela de preparo a partir de um arquivo externo. It may even be possible to automate those parts of the process, for example, by using PolyBase instead of fast load or MLOAD. If the exported files are Parquet, you can use a native Parquet reader, which is a faster option than PolyBase. Outras partes do processo que contêm SQL complexo arbitrário e/ou procedimentos armazenados levarão mais tempo para serem reformuladas.

One way of testing Teradata SQL for compatibility with Azure Synapse is to capture some representative SQL statements from Teradata logs, then prefix those queries with EXPLAIN, and then—assuming a like-for-like migrated data model in Azure Synapse—run those EXPLAIN statements in Azure Synapse. Qualquer SQL incompatível gerará um erro e as informações de erro podem determinar a escala da tarefa de recodificação.

Microsoft partners offer tools and services to migrate Teradata SQL and stored procedures to Azure Synapse.

Usar ferramentas de ETL de terceiros

Conforme descrito na seção anterior, em muitos casos, o sistema de data warehouse herdado existente já será preenchido e mantido por produtos ETL de terceiros. Para obter uma lista de parceiros de integração de dados da Microsoft para o Azure Synapse, consulte Parceiros de integração de dados.

Data loading from Teradata

Choices available when loading data from Teradata

When it comes to migrating data from a Teradata data warehouse, there are some basic questions associated with data loading that need to be resolved. You'll need to decide how the data will be physically moved from the existing on-premises Teradata environment into Azure Synapse in the cloud, and which tools will be used to perform the transfer and load. Considere as seguintes perguntas, que serão discutidas nas próximas seções.

• Você vai extrair os dados para arquivos, ou movê-los diretamente através de uma conexão de rede?

• Você orquestrará o processo a partir do sistema de origem ou do ambiente de destino do Azure?

• Quais ferramentas você usará para automatizar e gerenciar o processo?

Transferir dados através de ficheiros ou ligação de rede?

Once the database tables to be migrated have been created in Azure Synapse, you can move the data to populate those tables out of the legacy Teradata system and into the new environment. Existem duas abordagens básicas:

• File extract: extract the data from the Teradata tables to flat files, normally in CSV format, via BTEQ, Fast Export, or Teradata Parallel Transporter (TPT). Use TPT whenever possible since it's the most efficient in terms of data throughput.

  Essa abordagem requer espaço para pousar os arquivos de dados extraídos. The space could be local to the Teradata source database (if sufficient storage is available), or remote in Azure Blob Storage. O melhor desempenho é alcançado quando um arquivo é gravado localmente, uma vez que isso evita a sobrecarga da rede.

  Para minimizar os requisitos de armazenamento e transferência de rede, é uma boa prática compactar os arquivos de dados extraídos usando um utilitário como o gzip.

  Once extracted, the flat files can either be moved into Azure Blob Storage (collocated with the target Azure Synapse instance) or loaded directly into Azure Synapse using PolyBase or COPY INTO. O método para mover fisicamente dados do armazenamento local local para o ambiente de nuvem do Azure depende da quantidade de dados e da largura de banda de rede disponível.

  Microsoft provides different options to move large volumes of data, including AZCopy for moving files across the network into Azure Storage, Azure ExpressRoute for moving bulk data over a private network connection, and Azure Data Box where the files are moved to a physical storage device that's then shipped to an Azure data center for loading. Para obter mais informações, consulte transferência de dados.

• Direct extract and load across network: the target Azure environment sends a data extract request, normally via a SQL command, to the legacy Teradata system to extract the data. Os resultados são enviados pela rede e carregados diretamente no Azure Synapse, sem a necessidade de colocar os dados em arquivos intermediários. The limiting factor in this scenario is normally the bandwidth of the network connection between the Teradata database and the Azure environment. For very large data volumes this approach may not be practical.

Há também uma abordagem híbrida que usa ambos os métodos. Por exemplo, você pode usar a abordagem de extração direta de rede para tabelas de dimensão menor e amostras das tabelas de fatos maiores para fornecer rapidamente um ambiente de teste no Azure Synapse. For the large volume historical fact tables, you can use the file extract and transfer approach using Azure Data Box.

Orchestrate from Teradata or Azure?

The recommended approach when moving to Azure Synapse is to orchestrate the data extract and loading from the Azure environment using Azure Synapse Pipelines or Azure Data Factory, as well as associated utilities, such as PolyBase or COPY INTO, for most efficient data loading. This approach leverages the Azure capabilities and provides an easy method to build reusable data loading pipelines.

Other benefits of this approach include reduced impact on the Teradata system during the data load process since the management and loading process is running in Azure, and the ability to automate the process by using metadata-driven data load pipelines.

Que ferramentas podem ser utilizadas?

A tarefa de transformação e movimentação de dados é a função básica de todos os produtos ETL. If one of these products is already in use in the existing Teradata environment, then using the existing ETL tool may simplify data migration from Teradata to Azure Synapse. Essa abordagem pressupõe que a ferramenta ETL dê suporte ao Azure Synapse como um ambiente de destino. Para obter mais informações sobre ferramentas que dão suporte ao Azure Synapse, consulte Parceiros de integração de dados.

If you're using an ETL tool, consider running that tool within the Azure environment to benefit from Azure cloud performance, scalability, and cost, and free up resources in the Teradata data center. Outro benefício é a redução da movimentação de dados entre a nuvem e os ambientes locais.

Resumo

To summarize, our recommendations for migrating data and associated ETL processes from Teradata to Azure Synapse are:

• Planeie com antecedência para garantir um exercício de migração bem-sucedido.

• Crie um inventário detalhado de dados e processos a serem migrados o mais rápido possível.

• Use metadados do sistema e arquivos de log para obter uma compreensão precisa dos dados e do uso do processo. Não confie na documentação, pois ela pode estar desatualizada.

• Entenda os volumes de dados a serem migrados e a largura de banda de rede entre o data center local e os ambientes de nuvem do Azure.

• Consider using a Teradata instance in an Azure VM as a stepping stone to offload migration from the legacy Teradata environment.

• Aproveite os recursos padrão "internos" do Azure para minimizar a carga de trabalho de migração.

• Identify and understand the most efficient tools for data extraction and loading in both Teradata and Azure environments. Utilize as ferramentas adequadas em cada fase do processo.

• Use Azure facilities, such as Azure Synapse Pipelines or Azure Data Factory, to orchestrate and automate the migration process while minimizing impact on the Teradata system.

Próximos passos

To learn more about security access operations, see the next article in this series: Security, access, and operations for Teradata migrations.