Compartilhar via


Migre seu data warehouse para o Databricks lakehouse

Este artigo descreve algumas das considerações e advertências a serem consideradas ao substituir seu data warehouse corporativo pelo lakehouse do Databricks. A maioria das cargas de trabalho, consultas e painéis definidos nos data warehouses corporativos pode ser executada com refatoração mínima de código assim que os administradores concluírem a configuração inicial de migração e governança de dados. Migrar cargas de trabalho de data warehouse para o Azure Databricks não se trata de eliminar o data warehouse, e sim de unificar seu ecossistema de dados. Para obter mais informações sobre data warehousing no Databricks, consulte Data warehousing no Azure Databricks.

Muitas workloads do Apache Spark extraem, transformam e carregam (ETL) dados de sistemas de origem em armazéns de dados para suportar as análises subsequentes. A substituição do seu data warehouse corporativo por um lakehouse permite que analistas, cientistas de dados e engenheiros de dados trabalhem nas mesmas tabelas na mesma plataforma, reduzindo a complexidade geral, os requisitos de manutenção e o custo total de propriedade. Consulte O que é um data lakehouse?. Para ter uma visão geral de como aplicar padrões de projeto de data warehouse em um lakehouse, consulte Arquitetura de armazenamento de dados.

Carregar dados no lakehouse

O Azure Databricks fornece várias ferramentas e recursos para facilitar a migração de dados para o lakehouse e configurar trabalhos de ETL para carregar dados de diversas fontes de dados. Os seguintes artigos apresentam estas ferramentas e opções:

Como a Plataforma de Data Intelligence do Databricks é diferente de um data warehouse corporativo?

A Plataforma de Data Intelligence do Databricks foi compilada com base no Apache Spark, no Unity Catalog e no Delta Lake, oferecendo suporte nativo para cargas de trabalho de Big Data para análise, ML e engenharia de dados. Todos os sistemas de dados corporativos têm garantias transacionais, padrões de indexação e otimização e sintaxe SQL ligeiramente diferentes. Algumas das maiores diferenças que você pode descobrir incluem as seguintes:

  • Todas as transações são no nível da tabela. Não há transações, bloqueios nem garantias no nível do banco de dados.
  • Não há constructos BEGIN e END, o que significa que cada instrução ou consulta é executada como uma transação separada.
  • A nomenclatura de três níveis usa o padrão catalog.schema.table. Os termos database e schema são sinônimos devido à sintaxe herdada do Apache Spark.
  • As restrições de chave primária e chave estrangeira são somente informativas. As restrições só podem ser impostas no nível da tabela. Confira Restrições no Azure Databricks.
  • Os tipos de dados nativos com suporte no Azure Databricks e no Delta Lake podem ser ligeiramente diferentes dos sistemas de origem. A precisão necessária para tipos numéricos deve ser claramente indicada antes que os tipos de destino sejam escolhidos.

Os artigos a seguir fornecem um contexto adicional relativo a considerações importantes: