Architettura del set di dati per sorgenti CDC in un Qlik Open Lakehouse
Last updated: 25/08/2026Quando si generano set di dati in un Qlik Open Lakehouse, Qlik Talend Data Integration genera automaticamente tabelle di archiviazione, tabelle di modifica e visualizzazioni. È possibile eseguire query relative a queste viste per accedere ai dati attuali e storici archiviati nel formato di tabella aperto Iceberg.
Un'interfaccia utente intuitiva e guidata aiuta a creare, modellare ed eseguire pipeline di dati. È possibile generare automaticamente schemi per archivi di dati operativi (ODS) e archivi di dati storici (HDS) senza codifica manuale.
Architettura per una pipeline di dati Qlik Open Lakehouse che utilizza un Qlik Data Gateway - Movimento dati. I dati vengono trasferiti in S3 e vengono archiviati in un open lakehouse di Iceberg. Opzionalmente, come illustrato di seguito, è possibile eseguire il mirroring delle tabelle in un data warehouse.
Schemi
Gli artefatti vengono generati in uno schema interno e nello schema di un'attività dati.
-
Lo schema interno contiene una tabella fisica con più partizioni.
-
Lo schema dell'attività dati contiene le visualizzazioni che puoi utilizzare per utilizzare i dati.
Quando uno schema viene associato a più di un'attività dati, ogni attività dati deve utilizzare un prefisso unico per le tabelle e le visualizzazioni. È possibile impostare il prefisso nelle impostazioni delle attività dati.
Vengono controllati solo gli schemi interni per verificare la presenza di conflitti di denominazione. Per gli altri schemi, è necessario assicurarsi che nei nomi della tabella non vi siano conflitti di denominazione. La procedura consigliata è denominare lo schema interno con lo stesso nome dello schema dell'attività dati più il suffisso _internal. In questo modo, è possibile assicurarsi che ogni schema e combinazione di prefissi siano univoci.
Tabelle
Per ogni tabella di origine, viene creata una tabella nello schema interno con il suffisso _internal, utilizzando il formato:
<INTERNAL_SCHEMA>.<TABLE_NAME>_internal
Questa tabella contiene cinque partizioni, ognuna delle quali ha uno scopo distinto nel modo in cui i dati vengono elaborati e archiviati. Ogni partizione utilizza un sottoinsieme delle colonne della tabella in base al suo ruolo nel ciclo di vita dei dati.
Il set di dati interni è strutturato in modo da gestire in modo efficiente i dati in arrivo dal sistema di origine, supportando l'ingestione in tempo reale e il tracciamento cronologico. Il flusso di dati viene gestito attraverso diverse partizioni specializzate, ciascuna descritta di seguito:
-
Partizione delle modifiche: ingestione in tempo reale
Tutte le modifiche dal sistema di origine, come inserimenti, aggiornamenti ed eliminazioni, vengono prima aggiunte alla partizione Changes.
-
Fungendo da registro non elaborato delle modifiche, la partizione fornisce un feed completo dell'attività di origine prima che avvengano le trasformazioni.
-
Ogni modifica è contrassegnata da un tipo (I, U o D), che indica come viene elaborata.
-
Gli eventi vengono acquisiti dalla sorgente nel momento in cui si verificano. La partizione viene aggiornata praticamente in tempo reale.
-
La partizione Changes è disponibile quando le seguenti impostazioni sono applicate nell'attività Dati di trasferimento su data lake.
-
Nella scheda Generali, il Metodo di aggiornamento è impostato su CDC.
-
Il caricamento completo è abilitato.
-
-
-
Asset_state partizione - Monitoraggio dell'avanzamento
Quando le modifiche vengono acquisite, la partizione Asset_state registra due timestamp chiave:
-
Quando le modifiche sono state aggiunte per l'ultima volta alla partizione Changes.
-
Quando le modifiche sono state applicate per l'ultima volta alla partizione Current.
Questo consente di disporre di una visibilità completa della pipeline di sincronizzazione e aiuta a monitorare o a risolvere i ritardi.
-
-
Corrente partizione (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 di origine.
-
Un'attività in background viene eseguita automaticamente per applicare questi aggiornamenti. Questa si basa sul volume delle modifiche accumulate, piuttosto che su un programma fisso.
-
Il caricamento completo iniziale viene scritto direttamente nella partizione Current.
-
Questa partizione riflette lo stato attuale dei dati ed è progettata per eseguire query efficienti.
-
-
Precedente partizione (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 i metadati, tra cui la cronologia delle modifiche e l'intervallo di date in cui i dati sono validi.
-
Sono supportate le dimensioni di Tipo 2 con modifica lenta.
-
La partizione Prior è disponibile quando l'opzione Mantieni i registri cronologici e l'archivio dei record delle modifiche è abilitata nella scheda Generali delle impostazioni dell'attività dati di archiviazione.
-
Quando una versione aggiornata di un record viene aggiunta alla partizione Current, il record precedente viene spostato nella partizione Prior per la tracciabilità storica.
-
-
Ricaricamento partizione
La partizione Reload funge da area di sosta temporanea durante i ricaricamenti completi manuali o programmati:
-
I nuovi dati vengono prima scritti nella partizione Reload.
-
Le attività di manutenzione regolari cancellano tutte le modifiche in attesa prima che vengano messe in pausa.
-
I dati vengono confrontati con la partizioneCurrent e solo le differenze vengono spostate nella partizione Current.
-
La partizione Reload viene rimossa al termine dell'operazione.
Questo processo assicura un'interruzione minima del set di dati principale durante le operazioni di ricaricamento completo.
-
Current partizione
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash di tutte le chiavi primarie dei record. Il formato Hash è SHA1. Le colonne sono separate da un carattere backspace. |
| hdr__from_timestamp | TIMESTAMP |
Data e ora in UTC:
|
| hdr__operation | VARCHAR (1) |
L'ultima operazione del record.
|
| hdr__inserted_timestamp | TIMESTAMP | Data e ora UTC della prima volta in cui è stata aggiunta la chiave. Quando si usa il caricamento completo, l'ora d'inizio del caricamento completo. |
| hdr__modified_timestamp | TIMESTAMP | Data e ora in UTC dell'ultimo aggiornamento applicato. |
Prior partizione
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash di tutte le chiavi primarie dei record. |
| hdr__from_timestamp | TIMESTAMP | Data e ora in UTC. |
| hdr__to_timestamp | TIMESTAMP | Data e ora in UTC. |
| hdr__operation | STRINGA (1) |
L'ultima operazione del record.
|
| hdr__was_current_from_timestamp | TIMESTAMP | Il timestamp in UTC per il primo record temporale era quello corrente. |
| hdr__was_current_to_timestamp | TIMESTAMP | Il timestamp in UTC per l'ultimo record temporale era quello corrente. |
Changes partizione
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
L'identificatore di modifica è una stringa con due parti:
|
| hdr__operation | VARCHAR (1) |
L'ultima operazione del record.
|
| hdr__timestamp | TIMESTAMP | Data e ora in UTC. |
| hdr__key_hash | BINARIO (20) | Hash di tutte le chiavi primarie dei record. |
| hdr__inserted_timestamp | TIMESTAMP | Timestamp in UTC dell'ora in cui la modifica è stata elaborata da Qlik. |
Asset_state partizione
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | L'identificatore delle modifiche dell'ultima modifica applicata alla partizione Current. |
| hdr__copy_change_identifier | VARCHAR (50) | L'identificatore delle modifiche dell'ultima modifica aggiunta alla partizione Changes. |
Reload partizione
Le colonne utilizzate dalla partizione Reload sono identiche a quelle della partizione Current.
Visualizzazioni
Tutte le viste create vengono aggiornate praticamente in tempo reale. Le seguenti viste sono disponibili per semplificare l'esecuzione di query e la creazione di report:
Corrente
La vista Corrente riflette lo stato più recente dei dati. Questa vista rappresenta una replica della tabella di origine, aggiornata praticamente in tempo reale. Unisce i dati delle partizioni Current e Changes.
Nome: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>
Alla struttura della tabella non viene aggiunta alcuna colonna di intestazione.
Cronologia
Una visualizzazione cronologia viene generata nello schema asset di dati per ogni tabella di origine selezionata se Cronologia è abilitata nelle impostazioni dell'attività dati. La vista Cronologia unisce i dati dalle partizioni Prior e Changes. Fornisce una linea 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 Cronologia:
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | BINARIO (20) | Hash di tutte le chiavi primarie dei record. |
| hdr__from_timestamp | TIMESTAMP | Il timestamp in cui si è verificata la modifica nel sistema di origine. Questo riflette il momento in cui l'utente ha apportato la modifica. |
| hdr__to_timestamp | TIMESTAMP | Il timestamp in cui la modifica è stata annullata o aggiornata nel sistema di origine. |
| hdr__store | VARCHAR (10) |
Questi campi indicano dove risiede il record.
|
| hdr__operation | STRINGA (1) |
L'ultima operazione del record.
|
| hdr__deleted | BIT | Indica se il record è stato eliminato temporaneamente, a seconda che hdr__operation sia D o d. |
| hdr__was_current_from_timestamp | TIMESTAMP | L'ora (UTC) in cui la riga è stata aggiunta alla partizione Current. Ciò avviene tipicamente quando è stato eseguito il processo di archiviazione e la modifica è stata applicata. |
| hdr__was_current_to_timestamp | TIMESTAMP | L'ora (UTC) in cui la riga è stata rimossa dalla tabella Current, ad esempio a causa di una versione più recente. |