Architettura dei dataset in un Qlik Open Lakehouse
Quando si generano dataset in un Qlik Open Lakehouse, le tabelle di archiviazione, le tabelle delle modifiche e le viste vengono generate automaticamente da Qlik Talend Data Integration. È possibile interrogare queste viste per accedere ai dati correnti e storici archiviati nel formato di tabella aperta 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 utilizzando Qlik Data Gateway - Movimento dati. I dati vengono trasferiti in S3 e archiviati in un open lakehouse Iceberg. Facoltativamente, come mostrato di seguito, le tabelle possono essere sottoposte a mirroring in un data warehouse.
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 eventuali conflitti di denominazione. Per gli altri schemi, è necessario assicurarsi che non vi siano conflitti di denominazione nei nomi delle tabelle. La best practice consiste nel denominare lo schema interno con 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 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 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.
Il dataset interno è strutturato per gestire in modo efficiente i dati in arrivo dal sistema di origine, supportando l'inserimento in tempo reale e il tracciamento storico. Il flusso di dati è gestito tramite diverse partizioni specializzate, descritte di seguito:
-
Partizione Changes – Inserimento in tempo reale
Tutte le modifiche dal sistema di origine (inserimenti, aggiornamenti ed eliminazioni) vengono prima aggiunte alla partizione Changes.
-
Agendo come un changelog grezzo, la partizione fornisce un feed completo dell'attività di origine 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 dall'origine nel momento in cui si verificano. La partizione viene aggiornata quasi in tempo reale.
-
La partizione Changes è disponibile quando vengono applicate le seguenti impostazioni nell'attività dati di trasferimento Lake.
-
Nella scheda Generale, il Metodo di aggiornamento è impostato su CDC.
-
Il caricamento completo è abilitato.
-
-
-
Partizione Asset_state - Tracciamento dell'avanzamento
Man mano che le modifiche vengono inserite, 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.
Ciò fornisce piena visibilità sulla pipeline di sincronizzazione e aiuta a monitorare o risolvere i ritardi.
-
-
Partizione Current (ODS) – Ultima replica dell'origine
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 tali aggiornamenti. Ciò 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.
-
Ciò supporta la dimensione a variazione lenta di tipo 2 (SCD2).
-
La partizione Prior è disponibile quando l'opzione Mantieni record storici e archivio dei record di modifica è abilitata 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 caricamenti 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 dataset principale durante le operazioni di caricamento completo.
-
Partizione Current
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash di tutte le chiavi primarie del record. Il formato dell'hash è SHA1. Le colonne sono separate da un carattere backspace. |
| hdr__from_timestamp | TIMESTAMP |
Timestamp in UTC:
|
| hdr__operation | VARCHAR (1) |
Ultima operazione di questo record.
|
| hdr__inserted_timestamp | TIMESTAMP | Timestamp UTC della prima volta in cui è stata aggiunta la chiave. Quando si utilizza il caricamento completo, l'ora di inizio del caricamento completo. |
| hdr__modified_timestamp | TIMESTAMP | Timestamp UTC dell'ultimo aggiornamento effettuato. |
Partizione Prior
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash di tutte le chiavi primarie del record. |
| hdr__from_timestamp | TIMESTAMP | Timestamp in UTC. |
| hdr__to_timestamp | TIMESTAMP | Timestamp in UTC. |
| hdr__operation | STRING (1) |
Ultima operazione di questo record.
|
| hdr__was_current_from_timestamp | TIMESTAMP | Timestamp in UTC per la prima volta in cui il record era corrente. |
| hdr__was_current_to_timestamp | TIMESTAMP | Timestamp in UTC per l'ultima volta in cui il record era corrente. |
Partizione Changes
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
L'identificatore della modifica è una stringa con due parti:
|
| hdr__operation | VARCHAR (1) |
Ultima operazione di questo record.
|
| hdr__timestamp | TIMESTAMP | Timestamp in UTC. |
| hdr__key_hash | BINARY (20) | Hash di tutte le chiavi primarie del record. |
| hdr__inserted_timestamp | TIMESTAMP | Timestamp UTC del momento in cui la modifica è stata elaborata da Qlik. |
Partizione Asset_state
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | L'identificatore della modifica dell'ultima modifica applicata alla partizione Current. |
| hdr__copy_change_identifier | VARCHAR (50) | L'identificatore della modifica dell'ultima modifica aggiunta alla partizione Changes. |
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 di origine, 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 di origine selezionata quando l'opzione History è abilitata nelle impostazioni dell'attività dati. La vista History unisce i dati dalle partizioni Prior e Changes. Fornisce una cronologia completa delle modifiche, ideale per audit o analisi storiche.
Nome: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>
I seguenti campi di intestazione vengono aggiunti alla vista History:
| Campo | Tipo | Descrizione |
|---|---|---|
| hdr__key_hash | BINARY (20) | Hash di tutte le chiavi primarie del 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 originariamente 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) |
Questo indica dove risiede il record:
|
| hdr__operation | STRING (1) |
Ultima operazione di questo record.
|
| hdr__deleted | BIT | Indica se il record è stato eliminato in modo logico (soft delete), in base al fatto che hdr__operation sia D o d. |
| hdr__was_current_from_timestamp | TIMESTAMP | L'ora (UTC) in cui questa riga è entrata nella partizione Current. Questo avviene in genere quando è stato eseguito il processo di archiviazione ed è stata applicata la modifica. |
| 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. |