Projetar a lógica de ingestão e a configuração da fonte de dados

A criação da lógica de ingestão exige que você tome decisões críticas sobre como os dados são movidos dos sistemas de origem para o Azure Databricks. Essas decisões afetam a atualização de dados, a eficiência de processamento e a confiabilidade do sistema. Antes de selecionar ferramentas ou escrever código, você precisa entender as características de suas fontes de dados e definir estratégias de extração que se alinham aos seus requisitos de negócios.

Nesta unidade, você explorará as principais considerações de design para a lógica de ingestão de dados e a configuração da fonte de dados no Azure Databricks. O foco aqui é na lógica conceitual e nos padrões de design– detalhes específicos de seleção e implementação de ferramentas são abordados em unidades posteriores.

Entender os tipos de extração

O tipo de extração determina como você captura dados de sistemas de origem e afeta a pontualidade e a eficiência do pipeline de dados. O Azure Databricks dá suporte a três padrões de extração primários, cada um adequado para cenários diferentes.

Extração completa

A extração completa lê todo o conjunto de dados do sistema de origem durante cada execução de ingestão.

Essa abordagem funciona bem quando:

• Os sistemas de origem não dão suporte ao controle de alterações
• Os volumes de dados são pequenos o suficiente para reprocessar com eficiência
• Periodicamente, é necessário recompilar tabelas de destino do zero
• As relações de dados são complexas e a lógica incremental seria propensa a erros

A extração completa torna-se impraticável à medida que os volumes de dados crescem. Reprocessar milhões de registros quando apenas alguns milhares foram alterados desperdiça recursos computacionais e atrasa os consumidores seguintes.

Extração incremental

O processo de extração incremental processa apenas registros novos ou alterados desde a última execução de ingestão. O mecanismo rastreia quais dados foram processados e consulta apenas para atualizações.

Esse padrão requer:

• Um indicador de alteração confiável nos dados de origem (carimbo de data/hora, número de sequência ou coluna de versão)
• Gerenciamento de estado para rastrear a última posição processada
• Lógica para lidar com registros de chegada tardia ou fora de ordem

A extração incremental melhora significativamente a eficiência para grandes conjuntos de dados. Em vez de ler milhões de linhas, você pode processar apenas milhares de alterações por execução.

Extração de streaming

A extração de streaming fornece captura de dados quase em tempo real por meio do processamento contínuo. Em vez de serem executados conforme um cronograma, os trabalhos de streaming permanecem ativos e processam registros à medida que chegam.

Considere o streaming quando:

• Os processos empresariais exigem a atualização de dados medida em segundos ou minutos
• Sistemas de origem publicam eventos em barramentos de mensagens ou feeds de alteração
• Você precisa reagir aos eventos conforme eles ocorrem

A extração de streaming requer infraestrutura sempre ativa, mas oferece menor latência para a disponibilidade dos dados.

Design para captura de dados de alteração

Captura de Dados de Alteração (CDC) é um padrão de extração especializado que captura alterações individuais no nível de linha, incluindo inserções, atualizações e exclusões. O CDC difere da extração incremental simples porque preserva o tipo de operação para cada alteração.

Ao projetar para CDC, considere como seu sistema de origem produz registros de alteração:

• Logs de transações de bancos de dados: bancos de dados como o SQL Server podem expor alterações em nível de linha usando o recurso CDC baseado em log de transações. Sistemas downstream, como o Azure Databricks, podem ler essas alterações e processá-las como parte do pipeline de ingestão.
• Alterar feeds de dados: tabelas Delta e alguns bancos de dados, como o Azure Cosmos DB, fornecem rastreamento de alterações interno que revela alterações em linhas com metadados.
• Instantâneos periódicos: alguns sistemas não dão suporte à CDC contínua, o que exige a comparação de instantâneos para determinar alterações.

O CDC permite casos de uso que uma simples extração incremental não pode suportar. Você pode replicar com precisão as exclusões, manter trilhas de auditoria e processar atualizações que modificam colunas-chave.

Identificar características do tipo de arquivo de origem

Quando os dados chegam como arquivos e não em sistemas transacionais, o formato de arquivo influencia seu design de ingestão. Cada formato tem características distintas que afetam o processamento.

Formatos baseados em texto

Arquivos CSV e JSON são formatos de origem comuns porque são legívels por humanos e amplamente suportados. No entanto, eles apresentam desafios para o processamento eficiente:

• Variabilidade do esquema: os arquivos podem ter pedidos de coluna inconsistentes, campos ausentes ou variações de tipo de dados
• Sem eficiência de compactação: formatos de texto normalmente consomem mais armazenamento do que alternativas binárias
• Sobrecarga de análise: cada valor requer conversão de texto em tipo durante as leituras

Use formatos baseados em texto quando os sistemas de origem só podem produzir esses formatos ou quando os volumes de dados são pequenos o suficiente para que as preocupações com a eficiência não se apliquem.

Formatos de colunas

Os arquivos Parquet e ORC armazenam dados no formato columnar, permitindo consultas analíticas eficientes. Estes formatos oferecem:

• Compactação: o armazenamento columnar obtém melhores taxas de compactação agrupando valores semelhantes
• Poda de coluna: as consultas leem apenas as colunas de que precisam, reduzindo a E/S
• Esquema inserido: o arquivo contém metadados que descrevem nomes e tipos de coluna

Configure sua ingestão para favorecer formatos colunares de origem quando você tiver controle sobre como os sistemas upstream exportam dados.

Formatos semiestruturados

Arquivos JSON aninhados e XML representam dados hierárquicos que não se ajustam a uma estrutura tabular simples. Ao ingerir dados semiestruturados:

• Planeje a extração ou definição de esquema.
• Determine se deve nivelar a estrutura ou preservar o aninhamento.
• Considerar estruturas de documentos variáveis dentro da mesma fonte.

Considerações sobre a conexão da fonte de dados

A configuração da fonte de dados define como o Azure Databricks se conecta e se autentica com sistemas de origem. Seu design deve abordar a segurança de conexão, o gerenciamento de credenciais e os padrões de acesso.

Fontes de armazenamento de objetos de nuvem

O armazenamento em nuvem (Azure Data Lake Storage, Amazon S3 ou Google Cloud Storage) serve como a zona de destino mais comum para ingestão. Ao configurar conexões de armazenamento:

• Use locais externos do Catálogo do Unity para controlar o acesso aos caminhos de armazenamento.
• Configure os métodos de autenticação apropriados (identidade gerenciada, entidades de serviço ou credenciais de armazenamento).
• Projetar estruturas de pastas que suportem o processamento incremental eficiente.

A estrutura de pastas afeta significativamente a eficiência com que o Azure Databricks pode identificar e processar novos arquivos. Considere estes padrões:

Particionamento baseado em data: organizar arquivos por hierarquia de data para habilitar a poda de partição durante as leituras incrementais:

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

Essa estrutura permite que as consultas examinem apenas partições de data relevantes em vez de listar todos os arquivos.

Organização baseada na origem: ao ingerir de várias fontes, separe dados por sistema de origem para simplificar a lógica de processamento:

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

Processando pastas de estado: use pastas separadas para acompanhar o status de processamento de arquivos:

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

Ao projetar estruturas de pastas, considere:

• Sobrecarga de descoberta de arquivos: estruturas planas com milhares de arquivos retardam as operações de listagem. Estruturas particionadas reduzem os arquivos que o Azure Databricks deve enumerar.
• Compatibilidade do Carregador Automático: o Carregador Automático do Azure Databricks controla com eficiência novos arquivos no armazenamento em nuvem. Estruturar pastas para se alinhar com a forma como o Carregador Automático descobre e verifica arquivos.
• Extração de coluna de partição: use particionamento no estilo Hive (key=value) para que o Azure Databricks possa extrair automaticamente valores de partição como colunas sem analisar o conteúdo do arquivo.

Fontes de banco de dados

Conectar-se a bancos de dados transacionais requer considerações diferentes do armazenamento em nuvem:

• Conectividade de rede entre o Azure Databricks e o servidor de banco de dados.
• Credenciais de autenticação armazenadas com segurança (usando segredos em vez de valores codificados).
• Funcionalidades Pool de conexões e pushdown de consultas.
• Impacto no desempenho do sistema de origem durante a extração.

Fontes de streaming

Os barramentos de mensagens e os fluxos de eventos (como Hubs de Eventos do Azure ou outras plataformas de mensagens comuns) exigem:

• Detalhes de conexão do broker e autenticação.
• Configuração do grupo de consumidores para processamento paralelo.
• Gerenciamento de deslocamento para rastrear a posição de consumo.
• Integração do registro de esquema para validação de formato de mensagem.

Fontes de aplicativo SaaS

Aplicativos empresariais como Salesforce, ServiceNow ou SAP expõem dados por meio de APIs com características exclusivas:

• Limites de taxa de API que restringem a velocidade de extração.
• Estratégias de paginação para grandes conjuntos de resultados.
• Fluxos de autenticação (OAuth, chaves de API ou baseados em certificado).
• Controle de alterações ou recursos de webhook disponíveis.

Aplicar uma estrutura de design orientada a requisitos

O design de ingestão efetivo começa com a análise de requisitos antes de selecionar tipos de extração ou formatos de arquivo. Use a estrutura repetível a seguir para orientar suas decisões de design.

Etapa 1: reunir requisitos

Antes de tomar decisões técnicas, responda a estas principais perguntas:

Categoria Requisito	Perguntas a serem respondidas
Volume de dados	Quantos dados existem na origem? Quantas alterações entre as execuções? Qual é a taxa de crescimento?
Requisitos de latência	Quão novos devem ser os dados para consumidores downstream? Há SLAs para cumprir?
Capacidades de origem	A origem dá suporte ao rastreamento de alterações, CDC ou somente à extração completa? Quais formatos de arquivo ele pode produzir?
Qualidade dos dados	Quão confiáveis são os dados de origem? Qual validação ou limpeza é necessária?
Restrições de rede	Qual largura de banda existe entre a origem e o Azure Databricks? Há requisitos de firewall ou VPN?
Implicações de custo	Quais são os custos de computação, armazenamento e transferência de dados de diferentes abordagens?

Etapa 2: Mapear requisitos para o tipo de extração

Use a análise de requisitos para selecionar o padrão de extração apropriado:

Se seus requisitos indicarem...	Em seguida, escolha...
Volume de dados pequeno (< 100 mil linhas), sem controle de alterações disponível, reconstrução simples aceitável	Extração completa
O volume de dados é grande, existe um indicador de alteração confiável (carimbo de data/hora ou sequência), e uma atualização por hora ou diária é suficiente.	Extração incremental
Atualização em tempo real ou quase em tempo real necessária: origem publica eventos, infraestrutura de streaming disponível	Extração de streaming
É necessário capturar exclusões e tipos de operação, a trilha de auditoria obrigatória, captura do log de transações com suporte da origem	Extração de CDC

Etapa 3: Selecionar o formato de arquivo de origem

Quando você controla o formato de origem ou precisa escolher um formato de destino, adeque o formato às suas necessidades.

Se o cenário envolver...	Em seguida, opte por...
Grandes conjuntos de dados analíticos, consultas columnares, precisam de compactação	Parquet
Interoperabilidade com muitos sistemas, legibilidade humana necessária	CSV ou JSON
Estruturas de dados hierárquicas ou aninhadas	JSON ou XML
Streaming de alta frequência com evolução do esquema	Avro com registro de esquema

Etapa 4: Validar seu design

Antes de implementar, verifique se o design resolve estas preocupações:

• O tipo de extração atende aos requisitos de latência. Caso contrário, os consumidores downstream receberão dados obsoletos, potencialmente causando decisões de negócios incorretas ou violações de SLA.

• A abordagem é dimensionada para lidar com o crescimento de dados projetado. Caso contrário, os pipelines que funcionam hoje podem falhar ou ficar proibitivamente lentos à medida que os volumes de dados aumentam.

• Os recursos do sistema de origem dão suporte ao padrão escolhido. Caso contrário, o pipeline falhará em runtime ou exigirá soluções alternativas dispendiosas que adicionam complexidade.

• As estimativas de custo estão dentro das restrições de orçamento. Caso contrário, a solução pode ser tecnicamente sólida, mas financeiramente insustentável para uso em produção.

• As verificações da qualidade de dados são planejadas para o pipeline. Caso contrário, dados inválidos ou corrompidos se propagam para sistemas downstream, causando erros ou análise incorreta.

Aplicar a estrutura: um exemplo prático

Uma plataforma de comércio eletrônico precisa ingerir dados do pedido. Os pedidos são armazenados em um banco de dados PostgreSQL e a empresa requer relatórios por hora.

Etapa 1 – Reunir requisitos:

• Volume: 50.000 novos pedidos diários, 2 milhões de linhas totais, 15% crescimento anual.
• Latência: atualização com uma hora de atraso é aceitável para fins de relatórios.
• Fonte: O PostgreSQL dá suporte a consultas baseadas em timestamp, mas não possui um mecanismo nativo de captura de mudanças de dados (CDC).
• Qualidade: os dados de origem são validados na entrada; limpeza mínima necessária.
• Rede: conectividade direta por meio do Link Privado do Azure.
• Custo: minimizar o uso da computação; os custos de armazenamento são secundários.

Etapa 2 – Mapear para o tipo de extração:

Volume grande com coluna de carimbo de data/hora confiável e requisito de latência por hora → Extração incremental.

Por que não os outros?

• Extração completa: reprocessar 2 milhões de linhas por hora desperdiça recursos computacionais quando apenas cerca de 2.000 pedidos são alterados por hora.
• Streaming: A latência de uma hora não justifica o custo da infraestrutura de streaming sempre ativa.
• CDC: O PostgreSQL não expõe o CDC do log de transações nativo e o caso de uso não requer controle de exclusões ou tipos de operação.

Etapa 3 – Selecionar formato de arquivo:

Os dados chegam ao Azure Data Lake Storage para processamento → Parquet para armazenamento columnar eficiente. Layout particionado por data para descoberta incremental → /landing/orders/year=2025/month=11/day=28/.

Por que não os outros?

• CSV/JSON: tamanhos de arquivo maiores, sem benefícios de compactação e desempenho de consulta mais lento para cargas de trabalho analíticas.
• Avro: mais adequado ao streaming com evolução de esquema; a ingestão em lote não precisa de recursos orientados a streaming.
• XML: aumenta a complexidade de análise sem benefícios para dados estruturados tabulares.

Etapa 4 – Validar o projeto:

• ✓ O incremento horário atende ao requisito de latência de uma hora.
• ✓ O processamento só muda escalas de forma eficiente com o crescimento.
• ✓ A coluna PostgreSQL order_updated_at habilita consultas incrementais.
• ✓ Processar milhares versus milhões de linhas reduz os custos de computação.

Decisão final: extração incremental usando order_updated_at coluna de carimbo de data/hora, agendada por hora, dados de aterrissagem como arquivos Parquet no Azure Data Lake Storage.

Com base nessa base orientada por requisitos, você está pronto para avaliar as ferramentas específicas e os métodos de carregamento que implementam seu design de ingestão.