Architettura del set di dati in un Qlik Open Lakehouse

Le sorgenti di streaming hanno la propria architettura in Qlik Open Lakehouse in quanto non richiedono il Data Movement gateway per caricare i dati nel bucket di trasferimento, ma sono alimentate dal cluster lakehouse.

Quando si acquisiscono dati da file che includono un modello di dati all'interno del nome del file, ciò consente al cluster lakehouse di eseguire operazioni di elenco mirate in S3, accelerando notevolmente i tempi di lettura dell'elenco dei file. Inoltre, Qlik Open Lakehouse può prevedere i file in arrivo in base al modello di data. L'attività di trasferimento Streaming non deve elencare l'intero bucket ogni volta, ma può invece richiedere i file da S3 entro un intervallo di date specifico. Avere un elenco di file più piccolo porta a prestazioni migliori. L'impostazione opzionale Elimina dopo il caricamento può essere utilizzata per mantenere un numero ridotto di file. Non viene eseguito alcun caricamento completo, i primi record sono considerati modifiche inserite.

In un Qlik Open Lakehouse, l'attività Streaming Transform sostituisce l'attività di archiviazione. Questa attività viene utilizzata per trasformare e archiviare i dati trasferiti come tabelle Iceberg. Un'attività Streaming Transform può essere aggiunta solo dopo un'attività di trasferimento Streaming. L'attività Streaming Transform supporta due modalità per l'aggiornamento dei record:

• Solo accodamento: aggiunge nuovi record senza modificare i dati esistenti e i vincoli di chiave non vengono applicati se arrivano record duplicati.

• Applica modifiche (Unisci): aggiorna i record esistenti e inserisce nuovi record in base ai campi chiave. Questa modalità offre l'opzione di utilizzare un'eliminazione temporanea o di conservare i dati storici (Tipo 2).

L'attività Streaming Transform è un'attività basata sulla destinazione, che mappa tra sorgente e destinazione e include funzionalità di evoluzione dello schema. Fornisce funzionalità di trasformazione estese, tra cui l'annullamento dell'annidamento di strutture annidate e l'appiattimento di array. Per ulteriori informazioni sulle funzioni che è possibile utilizzare nell'attività Streaming Transform, vedere Funzioni di trasformazione.

Quando si acquisisce da una sorgente di streaming, si ha la possibilità di configurare il partizionamento Iceberg, la gestione della conservazione, le colonne di ordinamento, la scadenza degli snapshot per controllare i costi di archiviazione e ottimizzare le prestazioni delle query.

Tabelle di trasferimento

I seguenti campi di intestazione vengono aggiunti alle tabelle di trasferimento. Questi campi esistono sempre nei dati di trasferimento, ma per impostazione predefinita non nella trasformazione a valle. È possibile aggiungere i campi alla trasformazione utilizzando un'espressione.

Schemi

Gli artefatti vengono generati in uno schema interno e in uno schema dell'attività dati.

• Lo schema interno contiene una tabella fisica con più partizioni.

• Lo schema dell'attività dati contiene le viste che è possibile utilizzare per consumare i dati.

  Quando uno schema è associato a più di un'attività dati, ogni attività dati deve utilizzare un prefisso univoco per tabelle e viste. È possibile impostare il prefisso nelle impostazioni dell'attività dati.

Solo gli schemi interni vengono controllati per i conflitti di denominazione. Per gli altri schemi, è necessario assicurarsi che non vi siano conflitti di denominazione nei nomi delle tabelle. La procedura consigliata è quella di assegnare allo schema interno lo stesso nome dello schema dell'attività dati con l'aggiunta di _internal. Ciò garantisce che ogni combinazione di schema e prefisso sia univoca.

Tabelle

Per ogni tabella sorgente, viene creata una tabella nello schema interno con il suffisso _internal, utilizzando il formato:

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Questa tabella contiene cinque partizioni in modalità Applica modifiche (Unisci), ognuna con uno scopo distinto nel modo in cui i dati vengono elaborati e archiviati. Ogni partizione sfrutta un sottoinsieme di colonne della tabella in base al suo ruolo nel ciclo di vita dei dati. In modalità Solo accodamento la tabella non ha partizioni e si comporta come la partizione Current (ODS).

Il set di dati interno è strutturato per gestire in modo efficiente i dati in arrivo dal sistema sorgente, supportando l'acquisizione in tempo reale e il tracciamento storico. Il flusso di dati è gestito attraverso diverse partizioni specializzate, ciascuna descritta di seguito:

• Partizione Changes – Acquisizione in tempo reale

  Tutte le modifiche dal sistema sorgente (inserimenti, aggiornamenti ed eliminazioni) vengono prima accodate alla partizione Changes.

  • Agendo come un registro delle modifiche non elaborato, la partizione fornisce un feed completo dell'attività della sorgente prima che si verifichi qualsiasi trasformazione.

  • Ogni modifica è contrassegnata da un tipo (I, U o D), che indica come viene elaborata.

  • Gli eventi vengono acquisiti dalla sorgente non appena si verificano. La partizione viene aggiornata quasi in tempo reale.

  • La partizione Changes è disponibile quando le seguenti impostazioni vengono applicate nell'attività dati di trasferimento Lake.

    • Nella scheda Generale, il Metodo di aggiornamento è impostato su CDC.

    • Il caricamento completo è abilitato.

• Partizione Asset_state - Tracciamento dei progressi

  Man mano che le modifiche vengono acquisite, la partizione Asset_state registra due timestamp chiave:

  • Quando le modifiche sono state accodate per l'ultima volta alla partizione Changes.

  • Quando le modifiche sono state applicate per l'ultima volta alla partizione Current.

  Ciò fornisce piena visibilità sulla pipeline di sincronizzazione e aiuta a monitorare o risolvere i ritardi.

• Partizione Current (ODS) – Ultima replica della sorgente

  Le modifiche dalla partizione Changes vengono applicate periodicamente alla partizione Current per mantenere una copia aggiornata e ottimizzata per le query dei dati sorgente.

  • Un'attività in background viene eseguita automaticamente per applicare tali aggiornamenti. Questo si basa sul volume delle modifiche accumulate, piuttosto che su una pianificazione fissa.

  • Il caricamento completo iniziale viene scritto direttamente nella partizione Current.

  • Questa partizione riflette lo stato corrente dei dati ed è progettata per query efficienti.

• Partizione Prior (HDS) – Dati storici

  Quando un record viene aggiornato o eliminato nella partizione Current, una copia della versione precedente viene scritta nella partizione Prior. 

  • I record contengono metadati, tra cui la cronologia delle modifiche e l'intervallo di date in cui i dati sono validi.

  • Questo supporta la dimensione a variazione lenta di Tipo 2 (SCD2).

  • La partizione Prior è disponibile quando Mantieni record storici e archivio dei record di modifica è abilitato nella scheda Generale delle impostazioni dell'attività dati di archiviazione.

  • Quando una versione aggiornata di un record entra nella partizione Current, il record precedente viene spostato nella partizione Prior per il tracciamento storico.

• Partizione Reload

  La partizione Reload funge da area di staging temporanea durante i ricaricamenti completi manuali o pianificati:

  • I nuovi dati vengono prima scritti nella partizione Reload.

  • Le normali attività di manutenzione cancellano eventuali modifiche in attesa prima di essere messe in pausa.

  • I dati vengono confrontati con la partizione Current e solo le differenze vengono spostate nella partizione Current.

  • La partizione Reload viene cancellata al termine dell'operazione.

  Questo processo garantisce un'interruzione minima del set di dati principale durante le operazioni di ricaricamento completo.

Partizione Current

Partizione Prior

Partizione Changes

Partizione Asset_state

Partizione Reload

Le colonne utilizzate dalla partizione Reload sono identiche a quelle della partizione Current.

Viste

Tutte le viste create vengono aggiornate quasi in tempo reale. Le seguenti viste sono disponibili per semplificare le query e i report:

Current

La vista Current riflette lo stato più recente dei dati. Questa vista rappresenta una replica della tabella sorgente, aggiornata quasi in tempo reale. Unisce i dati dalle partizioni Current e Changes.

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

Nessuna colonna di intestazione viene aggiunta alla struttura della tabella.

History

Una vista History viene generata nello schema asset di dati per ogni tabella sorgente selezionata quando la Cronologia è abilitata nelle impostazioni dell'attività dati. La vista History unisce i dati dalle partizioni Prior e Changes. Fornisce una sequenza temporale completa delle modifiche, ideale per l'audit o l'analisi storica.

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

I seguenti campi di intestazione vengono aggiunti alla vista History: