Architettura del set di dati in un Qlik Open Lakehouse
Quando 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 Changes: 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.
-
-
-
Partizione Asset_state: 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.
-
-
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 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.
-
-
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 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.
-
-
Partizione Reload
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.
-
Partizione Current
| 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. |
Partizione Prior
| 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. |
Partizione Changes
| 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. |
Partizione Asset_state
| 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. |
Partizione Reload
Le colonne utilizzate dalla partizione Reload sono identiche a quelle della partizione Current.
Viste
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. |