Escolher uma ferramenta de ingestão de dados

Ao projetar pipelines de dados no Azure Databricks, a seleção da ferramenta de ingestão correta afeta diretamente a confiabilidade do pipeline, o esforço de manutenção e os custos de longo prazo. Cada ferramenta aborda diferentes cenários, fontes de dados e requisitos operacionais. Entender essas diferenças ajuda você a tomar decisões informadas que se alinham às necessidades da sua organização.

Entender o panorama das ferramentas de ingestão

O Azure Databricks fornece várias opções de ingestão que abrangem um espectro de serviços totalmente gerenciados a estruturas altamente personalizáveis. As ferramentas escolhidas dependem de fatores como o tipo de fonte de dados, os requisitos de latência e a quantidade de controle necessária sobre o processo de ingestão.

No final mais gerenciado, o Lakeflow Connect oferece conectores turnkey para aplicativos empresariais e bancos de dados. Esses conectores lidam com autenticação, controle de alterações, recuperação de erros e evolução do esquema automaticamente. Na extremidade personalizável, Spark Structured Streaming oferece controle completo sobre como os dados fluem pelo seu pipeline, embora exija mais trabalho de desenvolvimento e manutenção.

Entre esses extremos, você encontra ferramentas como Carregador Automático para arquivos de armazenamento em nuvem, COPY INTO para carregamento em lote baseado em SQL e abordagens baseadas em notebook usando conexões JDBC/ODBC . Além disso, o Azure Data Factory serve como uma camada de orquestração que pode coordenar a movimentação de dados no Azure Databricks do ecossistema mais amplo do Azure.

Lakeflow Connect

O Lakeflow Connect representa a abordagem moderna para a ingestão de dados no Azure Databricks. Ele oferece conectores totalmente gerenciados e conectores padrão que se integram aos pipelines do Lakeflow para uma experiência simplificada.

Conectores gerenciados são organizados em três tipos:

• os conectores SaaS fornecem integração pronta para uso com aplicativos empresariais, como Salesforce, ServiceNow, SharePoint, HubSpot, Jira, Microsoft Dynamics 365, Workday, Zendesk e muitos outros. Esses conectores lidam com autenticação específica da origem, leituras incrementais, limitação de taxa de API, evolução do esquema e repetições automatizadas. Eles são executados na computação sem servidor e gravam em tabelas de streaming controladas pelo Catálogo do Unity.

• Os conectores de banco de dados ingestam dados de bancos de dados relacionais, incluindo MySQL, PostgreSQL e SQL Server, com CDC (captura de dados de alteração). Como os conectores baseados em CDC leem a partir dos logs de transações de banco de dados em vez de consultar tabelas diretamente, eles exigem um gateway de ingestão implantado em sua rede e um volume de armazenamento temporário para carregar as alterações capturadas.

• Conectores de comunidade são conectores de software livre criados e mantidos pela comunidade. Eles estendem o Lakeflow Connect para fontes que ainda não têm um conector gerenciado. Você pode usar um conector de comunidade existente ou contribuir com um próprio.

Os conectores padrão estendem o Lakeflow Connect ao armazenamento de objetos de nuvem e aos barramentos de mensagens. Você pode ingerir dados do Amazon S3, do Azure Data Lake Storage ou do Google Cloud Storage usando o Carregador Automático. Para dados em tempo real, os conectores padrão dão suporte a Apache Kafka, Google Pub/Sub e Apache Pulsar.

Considere o Lakeflow Connect quando precisar de ingestão confiável e de baixa manutenção de fontes compatíveis. Os conectores gerenciados reduzem significativamente o tempo de desenvolvimento e a manutenção contínua em comparação com soluções personalizadas. No entanto, se a fonte de dados não tiver suporte ou você precisar de uma lógica de ingestão altamente especializada, talvez seja necessário explorar outras opções.

O Lakeflow Connect dá suporte à ingestão agendada (por hora, diária, semanal) e gatilhos sob demanda, tornando-o adequado para ciclos regulares de atualização de dados e cenários de carregamento ad hoc.

Conectores baseados em consulta

Conectores baseados em consultas são uma alternativa leve aos conectores de banco de dados do CDC para a ingestão agendada de bancos de dados relacionais. Em vez de ler logs de transações, eles consultam a tabela de origem diretamente usando uma coluna de cursor: um carimbo de data/hora ou inteiro monótono que rastreia quais linhas são novas ou atualizadas desde a última vez que o pipeline foi executado.

Como elas consultam a origem diretamente, os conectores baseados em consulta não exigem um gateway de ingestão ou armazenamento de preparo. Em cada execução programada, o conector recupera todas as linhas com um valor de coluna de cursor maior que a marca d'água alta da execução anterior e grava os resultados em tabelas de streaming no catálogo Unity.

As fontes com suporte incluem Oracle, Teradata, SQL Server, MySQL, MariaDB, PostgreSQL e todas as fontes de dados da Federação lakehouse.

Os conectores baseados em consulta dão suporte a três modos de acompanhamento de histórico para tabelas de destino:

• SCD Tipo 1: substitui a linha existente com a linha de origem mais recente. Nenhuma história é preservada.
• SCD Tipo 2: preserva o histórico completo adicionando novas linhas com metadados de versão.
• Somente acréscimo: adiciona todas as linhas ingeridas sem mesclar ou substituir.

Escolha conectores baseados em consulta em vez de conectores de banco de dados CDC quando a infraestrutura CDC ou binlog não estiver disponível, mas houver uma coluna de cursor confiável na origem. Escolha conectores CDC quando precisar de cada estado de linha intermediária entre execuções de pipeline ou quando o rastreio de exclusão reversível for crítico. A compensação é que os conectores baseados em consulta colocam mais carga diretamente nas tabelas de origem em comparação com os conectores CDC, que leem a partir do binlog.

Carregador Automático

O Carregador Automático fornece processamento incremental de arquivos para os dados que chegam ao armazenamento em nuvem. Em vez de verificar diretórios inteiros para encontrar novos arquivos, o Carregador Automático controla com eficiência quais arquivos foram processados e ingere apenas os recém-chegados.

O Carregador Automático funciona mantendo o estado em um local de ponto de verificação que rastreia arquivos processados. Quando novos arquivos chegam ao armazenamento em nuvem, o Carregador Automático os descobre por meio da listagem de diretórios ou do modo de notificação de arquivo. A listagem de diretório verifica periodicamente novos arquivos, enquanto o modo de notificação de arquivo usa eventos nativos de nuvem para detecção imediata.

Os principais recursos do Carregador Automático incluem:

• Inferência e evolução de esquema: detecta automaticamente o esquema de arquivos de entrada e manipula as alterações de esquema normalmente.
• Processamento exatamente uma vez: garante que cada arquivo seja processado uma vez, mesmo entre falhas e reinicializações.
• Escalabilidade: lida eficientemente com bilhões de arquivos para preenchimentos retroativos ou migrações.
• Suporte a formatos: processa arquivos JSON, CSV, Parquet, Avro, ORC, XML, texto e binário.

O Carregador Automático se ajusta a cenários em que os dados chegam como arquivos no armazenamento em nuvem— os padrões comuns incluem arquivos de log, exportações de sistemas upstream e zonas de aterrissagem de dados. Você pode usar o Auto Loader com pipelines Lakeflow para uma experiência gerenciada ou com o Streaming Estruturado para obter mais controle.

COPY INTO

O COPY INTO comando SQL carrega dados do armazenamento em nuvem em tabelas Delta. Ao contrário do Carregador Automático, que é executado continuamente como um fluxo, COPY INTO é executado como uma operação em lote que você agenda ou dispara manualmente.

COPY INTO rastreia quais arquivos ele já processou, tornando a operação idempotente. A execução do mesmo comando várias vezes não duplica os dados porque os arquivos carregados anteriormente são ignorados. Essa característica torna COPY INTO útil para trabalhos em lotes agendados em que você deseja um comportamento previsível e repetível.

Cenários comuns para COPY INTO incluem migrações de dados únicas, cargas em lotes agendadas de zonas de aterrissagem e fluxos de trabalho que priorizam SQL, onde se prefere sintaxe declarativa em vez de APIs de streaming.

Escolha COPY INTO em vez do Carregador Automático quando estiver realizando uma carga única e em lote de um conjunto de dados grande. COPY INTO fornece um modelo de configuração mais simples sem a necessidade de infraestrutura de streaming, tornando-o ideal para carregar centenas de gigabytes ou até mesmo terabytes de dados em uma única operação. O modelo de processamento contínuo do Carregador Automático e o gerenciamento de ponto de verificação adicionam complexidade desnecessária quando você só precisa carregar dados uma vez.

No entanto, para ingestão incremental contínua em escala, o Carregador Automático fornece melhor desempenho e descoberta de arquivos mais robusta.

Streaming estruturado do Spark

O Streaming Estruturado do Spark fornece a base para o processamento de dados em tempo real no Azure Databricks. Isso permite a ingestão contínua de várias fontes de streaming com garantias de processamento precisamente uma única vez.

As fontes de streaming com suporte incluem:

• Hubs de Eventos do Apache Kafka e do Azure: para arquiteturas controladas por eventos e processamento de fila de mensagens.
• Feeds de alteração do Delta Lake: para propagar alterações entre tabelas Delta.
• Armazenamento em nuvem via Carregador Automático: para ingestão de streaming baseada em arquivo.
• Soquete e fontes personalizadas: para cenários de ingestão especializados.

Escolha Streaming Estruturado quando precisar de controle refinado sobre comportamento de streaming, marca d'água personalizada ou lógica de janela ou ao trabalhar com fontes não compatíveis com abstrações de nível superior.

Conexões JDBC e ODBC

A ingestão baseada em notebook usando JDBC ou ODBC continua sendo uma abordagem prática para extrair dados de bancos de dados relacionais. Você escreve um código que se conecta diretamente a bancos de dados de origem, executa consultas e carrega resultados em tabelas Delta.

Essa abordagem dá suporte a praticamente qualquer banco de dados com um driver JDBC ou ODBC: SQL Server, Oracle, PostgreSQL, MySQL e muitos outros. Você implementa cargas completas ou incrementais, gravando consultas apropriadas, muitas vezes usando colunas de marca d'água para rastrear o progresso da extração.

Embora os conectores gerenciados do Lakeflow Connect estejam substituindo JDBC/ODBC em muitos cenários, as conexões baseadas em notebook permanecem valiosas quando:

• Seu banco de dados não é compatível com conectores gerenciados do Lakeflow Connect.
• Você precisa de uma lógica de extração personalizada que os conectores gerenciados não possam acomodar.
• Você está mantendo pipelines existentes que usam esse padrão.
• Você precisa de otimizações de pushdown de consulta específicas para tabelas grandes.

Ao usar JDBC/ODBC, armazene as credenciais com segurança usando segredos do Databricks em vez de codificar-as em notebooks. Considere o impacto no desempenho nos sistemas de origem e implemente a limitação ou o agendamento apropriados para evitar sobrecarregar bancos de dados transacionais.

Para bancos de dados on-premises, é necessária uma infraestrutura de rede adicional — o Azure ExpressRoute/VPN para conectividade JDBC direta do Databricks ou o Azure Data Factory com um Self-Hosted Integration Runtime para transferir dados primeiro para o armazenamento em nuvem.

Azure Data Factory

O AdF (Azure Data Factory) serve como uma plataforma de orquestração e movimentação de dados dentro do ecossistema do Azure. Ele se destaca na coordenação de fluxos de trabalho que abrangem vários serviços e dados de aterrissagem de diversas fontes no armazenamento em nuvem, em que o Azure Databricks pode processá-los.

O ADF integra-se extensivamente aos serviços da Microsoft, como o Dynamics 365, o Banco de Dados SQL do Azure e o Microsoft Fabric. Quando seus dados se originam dessas fontes, o ADF fornece conectividade simples e pode armazenar os dados no Azure Data Lake Storage para processamento subsequente com o Databricks.

Entender a função apropriada do ADF é importante. Use o ADF para:

• Orquestração: Coordenação de fluxos de trabalho que envolvem vários serviços do Azure.
• Aterrissagem inicial de dados: mover dados de fontes do Azure para o armazenamento em nuvem.
• Integração empresarial: quando a política da empresa obriga o ADF para a movimentação de dados.

Evite usar o ADF para transformações de ETL principais dentro do Databricks. A execução de transformações por meio de atividades do ADF introduz complexidade desnecessária e tem um desempenho menos eficiente do que o processamento nativo do Databricks. Deixe o ADF lidar com a movimentação de dados em seu "lakehouse" e, em seguida, use as ferramentas do Azure Databricks para a lógica de transformação.

Aplicar uma estrutura de decisão

A seleção de uma ferramenta de ingestão fica mais clara quando você avalia seu cenário em relação aos principais critérios de decisão.

Comece identificando o tipo de fonte de dados e, em seguida, considere os requisitos operacionais e o contexto organizacional.

Para aplicativos empresariais (Salesforce, ServiceNow, SharePoint), os conectores gerenciados do Lakeflow Connect oferecem o caminho mais rápido para a produção com manutenção mínima. Esses conectores lidam com a complexidade da integração de API, limitação de taxa e controle de alterações.

Para bancos de dados relacionais com tipos com suporte, o Lakeflow Connect oferece dois caminhos gerenciados: conectores de banco de dados (baseados em CDC, requer gateway) para captura de alterações contínuas e conectores baseados em consulta para ingestão agendada mais simples usando uma coluna de cursor. Para bancos de dados sem suporte, a extração JDBC/ODBC baseada em notebook continua sendo uma abordagem viável.

Para arquivos no armazenamento em nuvem, o Carregador Automático fornece descoberta e processamento incrementais eficientes. Use COPY INTO para cenários de lote mais simples ou quando preferir fluxos de trabalho orientados a SQL.

Para dados em streaming de barramentos de mensagens (Kafka, Hubs de Eventos, Pub/Sub), conectores padrão com pipelines lakeflow equilibram a automação com flexibilidade. Para requisitos complexos de streaming, o Streaming Estruturado oferece controle máximo.

Para fontes de ecossistema do Azure que exigem coordenação com outros serviços, o Azure Data Factory pode orquestrar o destino de dados no lakehouse. Mantenha a lógica de transformação no Azure Databricks em vez de nos fluxos de dados do ADF.

Sua escolha também depende de habilidades de equipe e padrões organizacionais. Documente suas decisões e o raciocínio por trás delas para ajudar os futuros membros da equipe a entender a arquitetura do pipeline.