Ingerir e transformar dados
07. Real-Time Intelligence — Eventhouse e aceleração
Uma plataforma de telemetria precisa receber eventos, estruturar campos usados com frequência e consultar tanto dados locais quanto referências no OneLake. Eventhouse e KQL oferecem recursos para esse percurso, mas tabelas nativas, tabelas externas e transformações de ingestão têm contratos diferentes.
Uma plataforma de telemetria precisa receber eventos, estruturar campos usados com frequência e consultar tanto dados locais quanto referências no OneLake. Eventhouse e KQL oferecem recursos para esse percurso, mas tabelas nativas, tabelas externas e transformações de ingestão têm contratos diferentes.
Eventhouse, bancos e tabelas
Eventhouse organiza recursos de análise em tempo real, incluindo bancos KQL. Tabelas nativas recebem dados gerenciados pelo mecanismo e participam dos recursos suportados de ingestão e processamento. Tabelas externas acessam conjuntos mantidos em outro local. A distinção determina operações disponíveis, manutenção e dependência da origem.
Uma consulta pode combinar eventos com dados de contexto, mas isso não elimina a necessidade de uma chave confiável. Quando a análise precisa preservar contexto histórico, a modelagem de dimensões e suas versões continua relevante. Os princípios de grão e histórico são desenvolvidos no capítulo de modelagem dimensional, inclusive para conceitos cobrados no acervo deste tópico.
Uma consulta operacional pode precisar da última leitura por equipamento, enquanto uma auditoria precisa de todas as leituras. Armazenar somente o agregado mais recente elimina parte da rastreabilidade. O desenho de tabelas deve preservar o conjunto necessário a cada contrato, seja com dados brutos, transformados ou materializados. A escolha entre tabela nativa e referência externa também precisa considerar quais operações serão realizadas, e não apenas se uma consulta de demonstração consegue retornar algumas linhas.
Mappings e contrato de ingestão
Mappings relacionam a representação recebida às colunas de destino. Em formatos delimitados, o identity mapping depende da ordem; em formatos nomeados, como JSON, depende dos nomes e pode ser sensível à caixa. Trocar dois campos numéricos pode produzir dados semanticamente incorretos sem disparar erro de tipo.
Use mapping explícito quando o contrato exigir correspondências que não podem ser inferidas com segurança. Uma mudança de grafia ou estrutura na origem deve ser tratada como mudança de esquema, com amostras e validação. Tipos devem representar o domínio completo: converter uma medida fracionária para um tipo que não conserva frações perde informação.
Uma estratégia comum extrai campos frequentes para colunas tipadas e preserva atributos adicionais em dynamic. Evite duplicar desnecessariamente no objeto residual os campos já extraídos. Para rastreabilidade, número de linha sozinho não identifica globalmente um evento; combine artefato, localização e versão quando necessário.
Continue lendo de graça
O capítulo inteiro está liberado no plano gratuito
Criar conta leva menos de um minuto e não pede cartão. Você destrava o texto completo, o mapa mental, o PDF para estudar off-line e ainda resolve questões inéditas todo dia.
Leu o resumo? Agora pratique.
São 90 questões inéditas de Real-Time Intelligence — Eventhouse e aceleração, todas comentadas alternativa por alternativa.
Você volta para este capítulo depois de criar a conta.
Fontes consultadas
- https://learn.microsoft.com/en-us/kusto/management/mappings?view=microsoft-fabric
- https://learn.microsoft.com/en-us/kusto/management/update-policy?view=microsoft-fabric
- https://learn.microsoft.com/en-us/fabric/real-time-intelligence/query-acceleration-overview
- https://learn.microsoft.com/en-us/fabric/real-time-intelligence/onelake-shortcuts