Arquitetura do conjunto de dados em um Qlik Open Lakehouse

Fontes de streaming têm sua própria arquitetura no Qlik Open Lakehouse, pois não exigem o Data Movement gateway para carregar dados no compartimento de aterrissagem, mas são alimentadas pelo cluster lakehouse.

Ao ingerir dados de arquivos que incluem um padrão de dados no nome do arquivo, isso permite que o cluster lakehouse execute operações de lista direcionadas no S3, o que acelera drasticamente o tempo para ler a lista de arquivos. Além disso, o Qlik Open Lakehouse pode prever arquivos que chegam com base no padrão de data. A tarefa de aterrissagem de fluxo não precisa listar o compartimento inteiro a cada vez, mas, em vez disso, pode solicitar os arquivos do S3 dentro de um intervalo de datas específico. Ter uma lista de arquivos menor leva a um melhor desempenho. A configuração opcional Excluir após o carregamento pode ser usada para manter um número pequeno de arquivos. Nenhum carregamento total é realizado, os primeiros registros são considerados alterações inseridas.

Em um Qlik Open Lakehouse, a tarefa de transformação de streaming substitui a tarefa de armazenamento. Essa tarefa é usada para transformar e armazenar dados de aterrissagem como tabelas do Iceberg. Uma tarefa de transformação de fluxo só pode ser adicionada após uma tarefa de aterrissagem de fluxo. A tarefa de transformação de fluxo suporta dois modos para atualizar registros:

• Somente anexar: Adiciona novos registros sem modificar os dados existentes, e as restrições de chave não são aplicadas se registros duplicados chegarem.

• Aplicar alterações (Mesclar): atualiza os registros existentes e insere novos registros com base em campos chave. Esse modo oferece a opção de usar uma exclusão suave ou reter dados históricos (Tipo 2).

A tarefa de transformação de fluxo é uma tarefa baseada em destino, que mapeia entre origem e destino e inclui recursos de evolução de esquema. Ela oferece recursos de transformação estendidos, incluindo o desaninhamento de estruturas aninhadas e o nivelamento de arrays. Para obter mais informações sobre as funções que você pode usar na tarefa de transformação de fluxo, consulte Funções de transformação.

Ao ingerir de uma fonte de fluxo, você tem a capacidade de configurar o particionamento do Iceberg, gerenciamento de retenção, colunas de classificação, expiração de snapshot para controlar os custos de armazenamento e otimizar o desempenho da consulta.

Tabelas de preparação

Os seguintes campos de cabeçalho são adicionados às tabelas de aterrisagem. Esses campos sempre existem nos dados de aterrissagem, mas por padrão não na transformação downstream. Você pode adicionar os campos à transformação usando uma expressão.

Esquemas

Artefatos são gerados em um esquema interno e um esquema de tarefa de dados.

• O esquema interno contém uma tabela física com várias partições.

• O esquema de tarefa de dados contém as exibições que você pode usar para consumir os dados.

  Quando um esquema está associado a mais de uma tarefa de dados, cada tarefa de dados deve usar um prefixo exclusivo para tabelas e exibições. Você pode definir o prefixo nas configurações da tarefa de dados.

Somente os esquemas internos são verificados quanto a conflitos de nomenclatura. Para outros esquemas, você deve garantir que não haja conflitos de nomenclatura nos nomes das tabelas. A melhor prática é nomear o esquema interno com o mesmo nome do esquema de tarefa de dados com _internal adicionado. Isso garante que cada combinação de esquema e prefixo seja única.

Tabelas

Para cada tabela de origem, é criada uma tabela no esquema interno com o sufixo _internal, usando o formato:

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Essa tabela contém cinco partições no modo Aplicar alterações (Mesclar), cada uma servindo a um propósito distinto na forma como os dados são processados e armazenados. Cada partição utiliza um subconjunto das colunas da tabela com base em sua função no ciclo de vida dos dados. No modo Somente anexar, a tabela não tem partições e se comporta como a partição Current (ODS).

O conjunto de dados interno é estruturado para gerenciar com eficiência os dados recebidos do seu sistema de origem, suportando a ingestão em tempo real e o rastreamento histórico. O fluxo de dados é gerenciado por meio de várias partições especializadas, cada uma descrita abaixo:

• Partição Changes – ingestão em tempo real

  Todas as alterações do sistema de origem – inserções, atualizações e exclusões – são primeiro anexadas à partição Changes.

  • Atuando como um log de alterações bruto, a partição fornece um feed completo da atividade de origem antes que qualquer transformação ocorra.

  • Cada alteração é marcada com um tipo (I, U ou D), indicando como ela é processada.

  • Os eventos são capturados da fonte à medida que ocorrem. A partição é atualizada quase em tempo real.

  • A partição Changes está disponível quando as seguintes configurações são aplicadas na tarefa de dados de aterrisagem no lake.

    • Na guia Geral, o Método de atualização está definido como CDC.

    • O carregamento total está ativado.

• Partição Asset_state – acompanhamento do progresso

  À medida que as alterações são ingeridas, a partição Asset_state registra dois carimbos de data/hora importantes:

  • Quando as alterações foram anexadas pela última vez à partição Changes.

  • Quando as alterações foram aplicadas pela última vez à partição Current.

  Isso proporciona visibilidade total do pipeline de sincronização e ajuda no monitoramento ou na solução de problemas de atrasos.

• Partição Current (ODS) – última réplica da fonte

  As alterações da partição Changes são aplicadas periodicamente à partição Current para manter uma cópia atualizada e otimizada para consulta da fonte de dados.

  • Uma tarefa em segundo plano é executada automaticamente para aplicar essas atualizações. Isso se baseia no volume de alterações acumuladas, e não em um cronograma fixo.

  • O carregamento total inicial é gravado diretamente na partição Current.

  • Essa partição reflete o estado atual dos dados e foi projetada para uma consulta eficiente.

• Partição Prior (HDS) – dados históricos

  Quando um registro é atualizado ou excluído na partição Current, uma cópia da versão anterior é gravada na partição Prior. 

  • Os registros contêm metadados, incluindo o histórico de alterações e o intervalo de datas em que os dados são válidos.

  • Isso suporta a dimensão de alteração lenta do Tipo 2 (SCD2).

  • A partição Prior está disponível quando a opção Manter registros históricos e arquivar registros de alterações está ativada na guia Geral das configurações da tarefa Dados de armazenamento.

  • Quando uma versão atualizada de um registro entra na partição Current, o registro anterior é movido para a partição Prior para acompanhamento histórico.

• Partição Reload

  A partição Reload atua como uma área de preparação temporária durante recargas completas manuais ou programadas:

  • Os novos dados são gravados primeiro na partição Reload.

  • As tarefas de manutenção regulares limpam as alterações pendentes antes de serem pausadas.

  • Os dados são comparados com a partição Current e somente as diferenças são movidas para a partição Current.

  • A partição Reload é limpa quando a operação é concluída.

  Esse processo garante o mínimo de interrupção do conjunto de dados principal durante as operações de recarga completa.

Partição Current

Partição Prior

Partição Changes

Partição Asset_state

Partição Reload

As colunas usadas pela partição Reload são idênticas às da partição Current.

Exibições

Todas as visualizações criadas são atualizadas quase em tempo real. As seguintes exibições estão disponíveis para simplificar as consultas e os relatórios:

Atual

A exibição Atual reflete o estado mais recente dos dados. Essa exibição representa uma réplica da tabela de origem, atualizada quase em tempo real. Ela mescla dados das partições Current e Changes.

Nome: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

Nenhuma coluna de cabeçalho é adicionada à estrutura da tabela.

Histórico

Uma visualização Histórico é gerada no esquema de ativo de dados para cada tabela de origem selecionada quando o Histórico estiver habilitado nas configurações da tarefa de dados. A visualização Histórico mescla dados das partições Prior e Changes. Ela fornece uma linha do tempo completa das alterações, ideal para auditoria ou análise histórica.

Nome: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

Os seguintes campos de cabeçalho são adicionados à visualização Histórico: