20. Disponibilidade do Eventhouse no OneLake

A telemetria pode precisar sair da análise em tempo real e participar de notebooks, SQL ou modelos semânticos. A disponibilidade no OneLake cria uma representação Delta consumível por outras experiências, sem transformar o Eventhouse em warehouse.

Preparar dados é construir o caminho entre uma fonte e uma base analítica confiável. Armazenamento, ingestão, qualidade e consulta formam uma sequência: uma decisão mal resolvida no início reaparece no modelo e no relatório. Este é o capítulo 20 de 24 da disciplina Preparar dados. A leitura parte do que foi construído em Eventhouse e banco de dados KQL. Depois dele, o estudo avança para Catálogo do OneLake e hub Real-Time.

Uma representação para outros mecanismos

Ao habilitar OneLake availability, dados do banco KQL ganham uma representação lógica em Delta no OneLake. Outros mecanismos compatíveis podem lê-la por seus próprios caminhos. O Eventhouse continua responsável pela ingestão e pela experiência KQL.

Com essa base, o capítulo segue para Escopo no banco ou na tabela. O conceito que acabou de ser apresentado passa a funcionar como ponto de partida para a decisão seguinte.

Escopo no banco ou na tabela

A configuração pode abranger o banco ou tabelas selecionadas conforme o recurso atual. Escolha apenas o que precisa ser compartilhado, pois volume, descoberta e segurança aumentam com o escopo. Novas tabelas e mudanças de esquema exigem governança.

A decisão anterior ainda não encerra o problema. Em Novos dados e histórico existente, veremos o que muda quando esse mecanismo encontra outra camada, outro contexto ou uma necessidade mais específica.

Novos dados e histórico existente

Habilitar para o futuro não implica necessariamente preencher todo o passado. A opção de aplicar a dados existentes realiza o backfill quando necessário. Planeje tempo, volume e validação; consumidores não devem assumir que o histórico está completo sem evidência.

Resta ligar esse mecanismo a Retenção e sincronização. Essa passagem completa o fluxo e permite avaliar o resultado como um todo, em vez de conferir apenas uma configuração isolada.

Retenção e sincronização

A retenção do banco KQL continua relevante para os dados disponibilizados. Alterações de esquema também precisam alcançar a representação. Monitore atraso, quantidade e compatibilidade antes de conectar relatórios; disponibilidade não elimina coordenação entre produtor e consumidor.

Com as quatro partes reunidas, já é possível sair das definições e acompanhar uma situação completa. O exemplo seguinte mostra como as decisões aparecem em conjunto e em que momento cada uma precisa ser conferida.