O Propósito Real da Landing Zone: Desacoplamento e Segurança

Olá, aqui é o Michel Santana. Se você já sentiu o frio na barriga de ver um pipeline quebrar porque o sistema de origem mudou o formato de um arquivo ou porque um banco de dados transacional "travou" durante uma extração pesada, este artigo é para você.

Hoje, quero mergulhar no que considero ser o "porto seguro" de qualquer arquitetura de dados moderna: a Landing Zone. Quando comecei a estudar arquiteturas de dados, percebi que muitos problemas de corrupção de dados nas camadas permanentes (como a Bronze ou Silver) poderiam ter sido evitados se tivéssemos um processo de ingestão mais resiliente e bem estruturado logo na entrada.

Neste artigo, vou compartilhar minha visão prática sobre como construir uma camada de pouso que não apenas recebe dados, mas garante a soberania e a segurança do seu ecossistema.

Frequentemente me perguntam: "Michel, por que não posso carregar o dado direto para a Bronze?". A resposta é simples: desacoplamento.

A Landing Zone (ou zona transiente) é o ponto de entrada único para dados externos. Seu propósito fundamental é isolar os sistemas de origem da nossa arquitetura interna. Se uma extração falha no meio do caminho ou se um arquivo vem corrompido, o impacto fica contido ali, sem "sujar" as camadas permanentes do seu Data Lakehouse.

A Regra de Ouro: Zero Transformação

Nesta fase, seguimos um princípio norteador rígido: o dado deve ser uma cópia fiel da origem (Raw Copy). É terminantemente proibido aplicar regras de negócio, filtros complexos ou mesmo casts de tipos. Queremos a "Verdade Técnica" absoluta. Se o sistema de origem envia um número como string, ele "pousa" como string.

Estrutura e Organização: O Poder do Particionamento Físico

Não adianta ter um lugar para colocar os dados se ele virar um "pântano" (Data Swamp). Uma Landing Zone profissional precisa de ordem. No meu dia a dia, implemento obrigatoriamente uma estrutura de pastas que permite ao Spark — ou qualquer motor de processamento — utilizar o Partition Discovery.

A estrutura que recomendo e utilizo segue este padrão:

.../sistema/entidade/ano=YYYY/mes=MM/dia=DD/.

Essa organização não é apenas estética. Ela permite que leiamos apenas os dados necessários para um processamento específico, economizando custos massivos de I/O de rede e processamento.

Mesmo para cargas incrementais que trazem dados retroativos, os arquivos devem ser salvos na estrutura de pastas da data de extração. Isso facilita a auditoria e o reprocessamento caso o pipeline falhe em um dia específico.

O Padrão de Nomenclatura

Com certeza. No meu dia a dia, eu costumo dizer que a organização de um Data Lakehouse começa pelo nome. Se você não consegue identificar a origem, o ambiente e o propósito de uma tabela só de olhar para ela, sua governança já nasceu com um problema sério.

Em ambientes corporativos complexos, é muito comum termos entidades com o mesmo nome vindo de sistemas diferentes — imagine ter uma tabela clientes no ERP, outra no CRM e mais uma no Portal Web. Sem um padrão de namespace (espaço de nomes), a sobrescrita de dados é inevitável e o caos se instala.

Para resolver isso, eu sigo e recomendo um padrão de nomenclatura rigoroso que funciona como uma "certidão de nascimento" para o dado.

O modelo que implementamos segue a estrutura:

[Ambiente].[Sistema]_[Módulo].[Entidade] 

Vamos decompor cada parte para você entender a lógica por trás:

• [Ambiente]: É o que isola o ciclo de vida do software. Utilizamos obrigatoriamente dev (desenvolvimento), hml (homologação) ou prd (produção). Isso evita que testes sujem dados produtivos.

  
  

• [Sistema]_[Módulo]: Funciona como o "Sobrenome" do dado. Exemplo: sap_financeiro ou protheus_compras. Isso garante que o Data Lake aceite o objeto clientes de múltiplas fontes sem qualquer conflito.

  
  

• [Entidade]: O nome do conjunto de dados, sempre no plural (ex: pedidos, usuarios).

  
  

Por que usar Schemas (Databases) por Sistema?

Eu defendo o uso de Schemas separados por sistema por um motivo principal: Segurança (RBAC). Ao organizar dessa forma, conseguimos aplicar políticas de acesso granulares. Por exemplo, podemos dar acesso ao time de RH apenas ao schema prd_silver.totvs_rh, sem expor dados sensíveis do financeiro que estão em outro schema.

Boas Práticas de "Etiqueta" Técnica

Além da estrutura, existem regras de ouro que não abro mão nos meus projetos:

1. Snake_case: Todos os nomes devem estar em letras minúsculas e separados por sublinhado (_). Esqueça espaços ou CamelCase; eles costumam causar problemas em diferentes motores de processamento.

   
   

2. Semantic Names: Evite siglas obscuras da fonte. Se no banco original a tabela chama Z001_CLI, na nossa arquitetura ela deve ser renomeada para algo legível como clientes.

   
   

3. Documentação Inline (SQL COMMENT): Nenhuma tabela é considerada concluída sem uma breve explicação do seu propósito injetada diretamente no catálogo via Spark SQL.

   
   

Ter nomes claros e padronizados facilita até a automação. Quando o seu pipeline segue um padrão, você consegue criar scripts genéricos que "descobrem" as tabelas sozinhos, economizando centenas de horas de codificação manual.

Estratégias de Ingestão: Escolhendo a Ferramenta Certa para o Trabalho

Nem todo dado nasce igual. Por isso, a forma como ele sai da origem define a confiabilidade de todo o ciclo de vida. No guia técnico que consolidei, dividimos as estratégias em três pilares principais:

1. Ingestão Incremental (Data de Corte)

Ideal para sistemas transacionais via JDBC/ODBC onde não temos CDC (Change Data Capture) habilitado, mas possuímos colunas de controle como updated_at.

Sempre aplico uma "janela de segurança" ou Lookback Window (ex: extrair sempre T-2). Isso mitiga o risco de perder registros que estavam em transação (lock) no banco de origem no exato momento da extração anterior.

2. Change Data Capture (CDC)

Esta é a forma mais robusta para alta volumetria. Ela captura inserções, atualizações e deleções lendo os logs de transação da fonte.

• O Ponto Crítico: Se o seu extrator ficar offline por mais tempo que a retenção do log da fonte, você perde dados. Por isso, na Landing, é vital que o arquivo CDC contenha o LSN (Log Sequence Number) para garantir a ordenação correta das alterações.

  
  

3. Carga Full (Snapshot)

Reservada para tabelas pequenas ou sistemas legados sem colunas de controle. Como o volume é repetitivo, costumo configurar um TTL (Time-To-Live) menor na Landing Zone para essas entidades para evitar custos desnecessários.

A Matriz de Decisão Técnica

Para facilitar o trabalho do time e garantir consistência, utilizamos uma matriz que dita como o dado deve "pousar" na Landing Zone:

Tipo de Fonte	Cenário	Estratégia Recomendada	Requisito na Landing
Relacional (SQL)	Tabelas > 10M linhas / Alto turnover	CDC	Preservar LSN e Op_Type
Relacional (SQL)	Tabela com update_date	Incremental	Aplicar Janela de Segurança
Relacional (SQL)	Tabela pequena/Sem controle	Full (Snapshot)	Formato Parquet obrigatório
Arquivos/APIs	Terceiros, Logs, SFTP	Event-Driven	Verificação de Hash Binário

O Coração da Eficiência: Configurando Políticas de Ciclo de Vida (TTL)

Agora, entramos em um ponto vital: a Landing Zone é uma zona de passagem, não de moradia. Deixar dados parados ali para sempre é um erro comum que gera custos inúteis e riscos de conformidade. Para resolver isso, configuramos o TTL (Time-To-Live).

Na minha experiência, o padrão ideal é manter os dados por 7 a 15 dias. Esse tempo é suficiente para que, caso um pipeline de transformação para a Bronze falhe, tenhamos o dado bruto disponível para reprocessamento sem precisar onerar novamente o sistema de origem (banco de produção).

Como configurar na prática:

No Azure Data Lake Storage (ADLS Gen2)

No Azure, utilizamos o Lifecycle Management. Eu costumo criar uma regra específica para o container da Landing:

1. Filtro de Prefixo: Aplico a regra apenas para a pasta /landing/.

2. Ação: "Delete Blob".

3. Condição: "Days after modification" = 15. Isso garante que, de forma totalmente automatizada e sem código extra no pipeline, o Azure limpe os arquivos antigos.

No AWS S3

No S3, utilizamos as Lifecycle Rules:

1. Defino a regra para o prefixo da landing zone.

2. Configuro a "Expiration" para objetos atuais.

3. Defino "Days after object creation" como 15.

4. Para versões antigas (se o versionamento estiver ativo), configuro a limpeza para 2 dias após se tornarem não-atuais.

No Google Cloud Storage (GCS)

A lógica é similar através do Object Lifecycle Management:

• Crio uma regra com a ação Delete.

• A condição é age maior que 15 dias.

Ao configurar essas políticas, você remove a responsabilidade de "limpeza" do seu código Python ou SQL. O infraestrutura cuida disso, tornando seu pipeline mais simples e focado apenas no movimento e qualidade do dado.

Qualidade e Governança na "Porta de Entrada"

Um aspecto que muitos negligenciam é a rastreabilidade. Desde o momento em que o dado toca a Landing Zone, ele deve ser acompanhado por metadados de auditoria.

Para garantir essa observabilidade e capacidade de auditoria total, implementamos uma matriz obrigatória de colunas técnicas. Essa estrutura permite que, em caso de qualquer inconsistência, a gente consiga rastrear o dado até o bit original sem precisar consultar catálogos externos.

Aqui está a tabela que utilizamos como padrão de governança para cada registro que entra no nosso ecossistema:

Matriz de Colunas Técnicas (Metadados de Auditoria)

Coluna	Tipo	Descrição	Justificativa Técnica
metadataingestion_at	Timestamp	Data/Hora da primeira carga no Lake.	Identifica o freshness do dado e a data de criação do registro no ecossistema.
metadataupdate_at	Timestamp	Data/Hora da última alteração via Merge/Update.	Inicia como NULL. Essencial para processos incrementais. Se houver valor, o dado foi alterado após a criação.
metadatasource_system	String	Nome do sistema de origem.	Permite auditoria rápida e filtros de linhagem (lineage) de forma simplificada.
metadatasource_file	String	Path/Nome do arquivo de origem.	Em caso de erro de leitura, permite isolar exatamente qual arquivo corrompeu o pipeline.
metadatarow_hash	String	Hash SHA2 das colunas de negócio.	Usado para comparar se houve mudança entre as camadas. Se o Hash mudar, o registro sofreu Update.
metadatarow_bin	Binary	Binário original da linha/arquivo.	Segurança Máxima: Usado para provar que o dado não foi adulterado (Non-repudiation) e verificação de integridade bit-a-bit.
metadatafile_modification_time	Timestamp	Data/Hora da última alteração do arquivo.	Registra o timestamp da última modificação física do arquivo na origem.

O Fingerprint Binário (SHA-256)

Em ingestões baseadas em arquivos onde o nome pode mudar, mas o conteúdo é o mesmo, utilizamos o Fingerprint Binário. Antes de processar, geramos um hash SHA-256 do conteúdo bruto. Se o hash já existir na nossa base de controle, o processamento é abortado. Isso evita a ingestão de dados duplicados e economiza processamento downstream.

Por que isso é inegociável?

Ao incluir o metadatarow_bin, por exemplo, garantimos o que chamamos de integridade bit-a-bit. Se houver uma contestação sobre a veracidade de um dado na camada Gold, podemos voltar até a Landing e provar, através do binário original, que o dado não sofreu manipulação indevida durante o processo de engenharia.

Além disso, o uso do metadatarow_hash é o que viabiliza um CDC (Change Data Capture) eficiente e barato, pois evitamos reprocessar registros que não sofreram alterações reais na fonte.

Considerações sobre Formatos e Retenção

Na minha prática, o Parquet é o formato mandatório para extrações de bancos relacionais devido à sua eficiência colunar. Formatos como CSV ou JSON são aceitos apenas como exceção para APIs de terceiros.

Lembre-se: a Landing Zone é uma zona de passagem. Eu costumo configurar uma política de retenção de 7 a 15 dias. Após o sucesso da carga na camada Bronze, os arquivos são mantidos apenas para uma auditoria rápida e depois deletados automaticamente via política de ciclo de vida do Storage. Isso mantém o ambiente limpo e os custos sob controle.

Conclusão e Próximos Passos

Construir uma Landing Zone eficiente é sobre ser pragmático. É entender que falhas vão acontecer e que sua arquitetura deve ser resiliente o suficiente para suportar essas instabilidades sem comprometer a decisão de negócio que depende daquele dado.

Ao adotar padrões claros de nomenclatura, particionamento e estratégias de ingestão bem definidas, você para de "apagar incêndios" e começa a focar no que realmente importa: gerar valor.

No próximo artigo, vamos subir um degrau e falar sobre como transformar essa "Verdade Técnica" em uma base persistente e imutável na camada Bronze.

Gostou dessa abordagem técnica? Se você está implementando um Data Lakehouse no Databricks ou Azure, como tem estruturado sua porta de entrada de dados? Vamos trocar uma ideia nos comentários!

Michel Santana

Engenheiro de Dados