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.

Fare clic per visualizzare a dimensioni complete — 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.

Tutte le tabelle e visualizzazioni sono gestite tramite Qlik Talend Data Integration. Non alterare i dati usando altri strumenti.

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.

La tabella nello schema interno è soggetta a modifiche senza preavviso. Si consiglia di utilizzare principalmente le viste per consumare i dati, ove possibile.

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:

Changes Partition: ingestione in tempo reale

Tutte le modifiche dal sistema di origine, inserimenti, aggiornamenti ed eliminazioni, vengono prima aggiunte alla partizione Changes Partition.
- 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 Partition è 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 partition - 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 Partition.
- Quando le modifiche sono state aggiunte per l'ultima volta alla partizione Current Partition.
Questo consente di disporre di una visibilità completa della pipeline di sincronizzazione e aiuta a monitorare o a risolvere i ritardi.
Current Partition (ODS) - Ultima replica della sorgente

Le modifiche dalla partizione Changes Partition vengono applicate periodicamente alla partizione Current Partition 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 Partition.
- Questa partizione riflette lo stato attuale dei dati ed è progettata per eseguire query efficienti.
Prior Partition (HDS) - Dati storici

Quando un record viene aggiornato o eliminato nella partizione Current Partition, una copia della versione precedente viene scritta nella partizione Prior Partition.
- 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 Partition è 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 Partition, il record precedente viene spostato nella partizione Prior Partition per la tracciabilità storica.
Partizione Ricaricamento

La partizione Ricaricamento funge da area di sosta temporanea durante i ricaricamenti completi manuali o programmati:
- I nuovi dati vengono prima scritti nella partizione Ricaricamento.
- Le attività di manutenzione regolari cancellano tutte le modifiche in attesa prima che vengano messe in pausa.
- I dati vengono confrontati con la partizione Current Partition e solo le differenze vengono spostate nella partizione Current Partition.
- La partizione Ricaricamento viene cancellata al termine dell'operazione.
Questo processo assicura un'interruzione minima del set di dati principale durante le operazioni di ricaricamento completo.

Partizione Current Partition

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: Per i dati ricavati da un caricamento completo, questa è l'ora di inizio del caricamento completo. Per una modifica proveniente dalla partizione Changes, questo è il campo timestamp del record.
hdr__operation	VARCHAR (1)	L'ultima operazione del record. D - eliminato dalla partizione Change Partition. U - aggiornato dalla partizione Change Partition. I - inserito dalla partizione Change Partition. L - inserito dall'attività di caricamento completo. d - cancellato da confronta e applica. u - aggiornato da confronta e applica. i -inserito da confronta e applica.
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 Partition

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. D - eliminato dalla partizione Change Partition. U - aggiornato dalla partizione Change Partition. I - inserito dalla partizione Change Partition. L - inserito dall'attività di caricamento completo. d - cancellato da confronta e applica. u - aggiornato da confronta e applica. i -inserito da confronta e applica.
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 Partition

Campo	Tipo	Descrizione
hdr__change_identifier	VARCHAR (50)	L'identificatore di modifica è una stringa con due parti: Il timestamp dell'inizio dell'esecuzione del batch in millisecondi dal 1/1/1970 (stringa di 10 cifre) Sequenza di modifica dal gateway replication (35 caratteri)
hdr__operation	VARCHAR (1)	L'ultima operazione del record. D - eliminato dalla partizione Changes. U - aggiornato dalla partizione Change Partition. I - inserito dalla partizione Change Partition. L - inserito dall'attività di caricamento completo. d - cancellato da confronta e applica. u - aggiornato da confronta e applica. i -inserito da confronta e applica.
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 Partition.
hdr__copy_change_identifier	VARCHAR (50)	L'identificatore delle modifiche dell'ultima modifica aggiunta alla partizione Changes Partition.

Partizione Ricaricamento

Le colonne utilizzate dalla partizione di ricaricamento sono identiche a quelle della partizione Current Partition.

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 Partition e Changes Partition.

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 visualizzazione 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. CURRENT: se il record risiede nella tabella corrente. PRECEDENTE - se il record risiede nella partizione Precedente con i dati storici.
hdr__operation	STRINGA (1)	L'ultima operazione del record. D - eliminato dalla partizione Changes. U - aggiornato dalla partizione Change Partition. I - inserito dalla partizione Change Partition. L - inserito dall'attività di caricamento completo. d - cancellato da confronta e applica. u - aggiornato da confronta e applica. i -inserito da confronta e applica.
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 questa riga è entrata nella partizione Corrente.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 Corrente, ad esempio a causa di una versione più recente.

Le viste Corrente e Cronologia si basano sulla partizione Changes e sono sempre quasi in tempo reale. Tuttavia, se le prestazioni della query sono lente, ciò potrebbe essere dovuto a un gran numero di modifiche che non sono ancora state applicate alle partizioni Corrente o Prior Partition. I delta non uniti richiedono una maggiore elaborazione al momento dell'esecuzione della query, rendendo l'accesso più lento.

Hai trovato utile questa pagina?

Se riscontri problemi con questa pagina o con il suo contenuto – un errore di battitura, un passaggio mancante o un errore tecnico – ti pregiamo di farcelo sapere!

Lascia qui il tuo feedback