Lógica de ingestão de projeto e configuração da fonte de dados

Desenhar lógica de ingestão exige que tomes decisões críticas sobre como os dados passam dos sistemas fonte para o Azure Databricks. Estas decisões afetam a frescura dos dados, a eficiência do processamento e a fiabilidade do sistema. Antes de escolher ferramentas ou escrever código, precisa de compreender as características das suas fontes de dados e definir estratégias de extração que estejam alinhadas com os requisitos do seu negócio.

Nesta unidade, explora 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 está na lógica conceptual e nos padrões de design — a seleção específica de ferramentas e detalhes de implementação são abordados em unidades posteriores.

Compreender os tipos de extração

O tipo de extração determina como captura dados dos sistemas de origem e impacta tanto a pontualidade como a eficiência do seu pipeline de dados. O Azure Databricks suporta três padrões principais de extração, cada um adequado a diferentes cenários.

Extração total

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

Esta abordagem funciona bem quando:

• Os sistemas fonte não suportam o rastreio de alterações
• Os volumes de dados são suficientemente pequenos para serem reprocessados de forma eficiente
• É preciso reconstruir completamente as tabelas dos destinos desde o início periodicamente
• As relações de dados são complexas e a lógica incremental seria propensa a erros

A extração total torna-se impraticável à medida que os volumes de dados aumentam. Reprocessar milhões de registos quando apenas alguns milhares se alteram desperdiça recursos computacionais e atrasa os utilizadores a jusante.

Extração incremental

A extração incremental processa apenas registos novos ou alterados desde a última execução de ingestão. O motor regista os dados que foram processados e consulta apenas para atualizações.

Este padrão exige:

• Um indicador de alteração fiável nos dados de origem (carimbo temporal, número de sequência ou coluna de versão)
• Gestão de estado para acompanhar a última posição processada
• Lógica para lidar com registos atrasados ou desordenados

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

Extração em transmissão contínua

A extração em streaming proporciona captura de dados quase em tempo real através de processamento contínuo. Em vez de funcionar segundo um horário, as tarefas de streaming mantêm-se ativas e processam os registos à medida que chegam.

Considere fazer streaming quando:

• Os processos empresariais requerem frescura dos dados medida em segundos ou minutos
• Os sistemas de origem publicam eventos em buses de mensagens ou feeds de alterações
• Tens de reagir aos acontecimentos à medida que acontecem

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

Desenho para captura de alteração de dados

A captura de dados de alteração (CDC) é um padrão de extração especializado que capta alterações individuais ao nível da linha, incluindo inserções, atualizações e eliminações. O CDC difere da extração incremental simples porque preserva o tipo de operação para cada alteração.

Ao desenhar para CDC, considere como o seu sistema de origem produz registos de alterações:

• Registos de transações da base de dados: Bases de dados como o SQL Server podem expor alterações ao nível das linhas usando a sua funcionalidade CDC baseada em registos de transações. Sistemas subsequentes como o Azure Databricks podem depois ler essas alterações e processá-las como parte do pipeline de ingestão.
• Alterar feeds de dados: Tabelas Delta e algumas bases de dados, como o Azure Cosmos DB, fornecem monitorização de alterações incorporada que apresenta alterações de linha com metadados.
• Snapshots periódicos: Alguns sistemas não suportam CDC contínuo, exigindo que compare as capturas instantâneas para determinar alterações.

O CDC permite casos de uso que a extração incremental simples não suporta. Pode replicar com precisão as eliminações, manter registos de auditoria e processar atualizações que modificam colunas-chave.

Identificar características do tipo de ficheiro fonte

Quando os dados chegam sob a forma de ficheiros em vez de provirem de sistemas de transações, o formato do ficheiro influencia o design da ingestão. Cada formato tem características distintas que afetam o processamento.

Formatos baseados em texto

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

• Variabilidade do esquema: Os ficheiros podem ter ordens de colunas inconsistentes, campos em falta ou variações no tipo de dados
• Sem eficiência de compressão: Os formatos de texto normalmente consomem mais espaço de armazenamento do que as alternativas binárias
• Sobrecarga de análise: Cada valor requer conversão de texto para tipo durante as leituras

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

Formatos colunares

Os ficheiros Parquet e ORC armazenam dados em formato colunar, permitindo consultas analíticas eficientes. Estes formatos oferecem:

• Compressão: O armazenamento colunar alcança melhores razões de compressão ao agrupar valores semelhantes
• Corte de colunas: As consultas leem apenas as colunas de que precisam, reduzindo a E/S
• Esquema incorporado: O ficheiro contém metadados que descrevem nomes e tipos de colunas

Projete a sua ingestão para favorecer formatos de fonte colunar quando tem controlo sobre como os sistemas a montante exportam dados.

Formatos semi-estruturados

Ficheiros XML e JSON aninhados representam dados hierárquicos que não se encaixam numa estrutura tabular plana. Ao ingerir dados semi-estruturados:

• Planeia a extração ou definição de esquemas.
• Decida se deve aplanar a estrutura ou preservar o ninho.
• Tenha em conta as diferentes estruturas de documentos dentro da mesma fonte.

Considerações sobre a ligação à fonte de dados

A configuração da fonte de dados define como o Azure Databricks se liga e autentica com os sistemas fonte. O seu design deve abordar a segurança da ligação, gestão de credenciais e padrões de acesso.

Fontes de armazenamento de objetos na cloud

O armazenamento na cloud (Azure Data Lake Storage, Amazon S3 ou Google Cloud Storage) serve como a zona de aterragem mais comum para ingestão. Ao configurar ligações de armazenamento:

• Use as localizações externas do Unity Catalog para gerir o acesso aos caminhos de armazenamento.
• Configure os métodos de autenticação apropriados (identidade gerida, princípios de serviço ou credenciais de armazenamento).
• Projete estruturas de pastas que suportem processamento incremental eficiente.

A estrutura das pastas impacta significativamente a eficiência com que o Azure Databricks consegue identificar e processar novos ficheiros. Considere estes padrões:

Particionamento baseado em datas: Organize ficheiros por hierarquia de datas para permitir a poda de partições durante leituras incrementais:

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

Esta estrutura permite que as consultas escaneiem apenas partições de datas relevantes em vez de listar todos os ficheiros.

Organização baseada em fonte: Ao ingerir de múltiplas fontes, separe os dados por sistema de origem para simplificar a lógica de processamento:

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

Pastas de estado de processamento: Use pastas separadas para acompanhar o estado do processamento de ficheiros:

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

Ao desenhar estruturas de pastas, considere:

• Sobrecarga de descoberta de ficheiros: Estruturas planas com milhares de ficheiros atrasam as operações de listagem. Estruturas particionadas reduzem os ficheiros que o Azure Databricks deve enumerar.
• Compatibilidade com o Auto Loader: O Azure Databricks Auto Loader acompanha eficientemente novos ficheiros em armazenamento na cloud. Estrutura as pastas para alinharem com a forma como o Auto Loader descobre e controla ficheiros.
• Extração de colunas de partição: Use partição ao estilo Hive (key=value) para que o Azure Databricks possa extrair automaticamente valores de partição como colunas sem analisar o conteúdo dos ficheiros.

Fontes da base de dados

A ligação a bases de dados transacionais requer considerações diferentes do armazenamento na cloud:

• Conectividade de rede entre o Azure Databricks e o servidor de base de dados.
• Credenciais de autenticação armazenadas de forma segura (usando segredos em vez de valores codificados fixamente).
• Pooling de ligações e capacidades de repressão de consultas .
• Impacto no desempenho do sistema de origem durante a extração.

Fontes de streaming

Barramentos de mensagens e fluxos de eventos (como Azure Event Hubs ou outras plataformas comuns de mensagens) requerem:

• Detalhes da ligação ao corretor e autenticação.
• Configuração do grupo de consumidores para processamento paralelo.
• Gestão de offsets para monitorizar a posição de consumo.
• Integração do registo de esquemas para validação de formatos de mensagem.

Fontes de aplicações SaaS

Aplicações empresariais como Salesforce, ServiceNow ou SAP expõem dados através de APIs com características únicas:

• Limitações de taxa da API que limitam o débito de extração.
• Estratégias de paginação para grandes conjuntos de resultados.
• Fluxos de autenticação (OAuth, chaves API ou baseados em certificados).
• Capacidades disponíveis de rastreamento de alterações ou webhook.

Aplicar uma estrutura de design orientada por requisitos

Um design eficaz de ingestão começa com a análise dos requisitos antes de selecionar os tipos de extração ou formatos de ficheiro. Use a seguinte estrutura repetível para orientar as suas decisões de design.

Etapa 1: reunir requisitos

Antes de tomar qualquer decisão técnica, responda a estas perguntas-chave:

Categoria do requisito	Perguntas a Responder
Volume de dados	Quantos dados existem na fonte? Quanto muda entre as corridas? Qual é a taxa de crescimento?
Requisitos de latência	Quão frescos devem ser os dados para os consumidores a jusante? Existem SLAs para cumprir?
Capacidades de origem	A fonte oferece suporte a rastreio de alterações, CDC ou apenas extração total? Que formatos de ficheiro pode produzir?
Qualidade dos dados	Quão fiáveis são os dados de origem? Que validação ou purificação é necessária?
Restrições de rede	Que largura de banda existe entre a fonte e o Azure Databricks? Existem requisitos de firewall ou VPN?
Implicações de custos	Quais são os custos de computação, armazenamento e transferência de dados das diferentes abordagens?

Passo 2: Mapear os requisitos para o tipo de extração

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

Se os seus requisitos indicarem...	Então escolhe...
Volume de dados pequeno (< 100K linhas), sem rastreio de alterações disponível, reconstrução simples aceitável	Extração total
Grande volume de dados, existe um indicador de alteração fiável (carimbo de tempo/sequência), atualização suficiente por hora ou diariamente	Extração incremental
É necessária atualização em tempo real ou quase em tempo real, a fonte publica eventos, e há infraestrutura de streaming disponível.	Extração em streaming
É necessário capturar eliminações e tipos de operações, requer registo de auditoria, a origem suporta captura de registos de transações	Extração CDC

Passo 3: Selecionar o formato do ficheiro fonte

Quando controla o formato de origem ou precisa de escolher um formato de zona de aterragem, adapte o formato às suas necessidades:

Se o seu cenário envolver...	Então prefere...
Grandes conjuntos de dados analíticos, consultas colunares, precisam de compressã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 de esquemas	Avro com registro de esquemas

Passo 4: Valide o seu design

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

• O tipo de extração cumpre os requisitos de latência. Caso contrário, os consumidores a jusante recebem dados obsoletos, podendo causar decisões empresariais incorretas ou violações do SLA.

• A abordagem escala para lidar com o crescimento projetado dos dados. Caso contrário, os pipelines que funcionam hoje podem falhar ou tornar-se proibitivamente lentos à medida que os volumes de dados aumentam.

• As capacidades do sistema de origem suportam o padrão escolhido. Caso contrário, o pipeline falha em tempo de execução ou requer soluções dispendiosas que acrescentam complexidade.

• As estimativas de custos estão dentro de restrições orçamentais. Se não, a solução pode ser tecnicamente sólida, mas financeiramente insustentável para uso em produção.

• Estão planeadas verificações de qualidade dos dados para o pipeline. Se não, dados inválidos ou corrompidos propagam-se para sistemas a jusante, causando erros ou análises incorretas.

Aplicar o enquadramento: Um exemplo prático

Uma plataforma de comércio eletrónico precisa de absorver dados de encomendas. As encomendas são armazenadas numa base de dados PostgreSQL, e o negócio necessita de relatórios horários.

Passo 1 - Recolher os requisitos:

• Volume: 50.000 novas encomendas diárias, 2 milhões de linhas no total, 15% crescimento anual.
• Latência: Uma hora de frescura aceitável para relatórios.
• Fonte: PostgreSQL suporta consultas baseadas em marca temporal, mas não suporta CDC nativo.
• Qualidade: Os dados de origem são validados na entrada; É necessário uma limpeza mínima.
• Rede: Conectividade direta via Azure Private Link.
• Custo: Minimizar o uso de computação; Os custos de armazenamento são secundários.

Passo 2 - Mapear para o tipo de extração:

Grande volume com coluna de carimbo de tempo fiável e requisito de latência horária → extração incremental.

Porque não os outros?

• Extração total: O reprocessamento de 2 milhões de linhas por hora desperdiça recursos computacionais quando apenas ~2.000 encomendas mudam por hora.
• Streaming: Uma 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 nativo dos registos de transações, e o caso de uso não exige rastreio de eliminações ou tipos de operações.

Passo 3 - Selecionar o formato do ficheiro:

Os dados são recepcionados pelo Azure Data Lake Storage para processamento utilizando Parquet para armazenamento colunar eficiente. Esquema particionado por data para descoberta incremental → /landing/orders/year=2025/month=11/day=28/.

Porque não os outros?

• CSV/JSON: Ficheiros de maior tamanho, sem benefícios de compressão e desempenho de consultas mais lento para cargas de trabalho analíticas.
• Avro: Mais adequado para streaming com evolução de esquemas; a ingestão em lote não precisa de funcionalidades orientadas para streaming.
• XML: Adiciona complexidade de análise sintática sem benefícios para dados estruturados de ordem tabular.

Passo 4 - Validar design:

• ✓ Incremental por hora cumpre o requisito de latência de uma hora.
• ✓ O processamento só muda de forma eficiente com o crescimento.
• ✓ A coluna PostgreSQL order_updated_at permite consultas incrementais.
• ✓ Processar milhares vs. milhões de linhas reduz os custos de computação.

Decisão final: extração incremental usando a order_updated_at coluna de carimbo temporal, agendada a cada hora, como dados de aterragem armazenados em ficheiros Parquet no Azure Data Lake Storage.

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