Connessione ai flussi di dati
Sono supportati i seguenti servizi di streaming nei progetti Qlik Open Lakehouse. I dati degli eventi vengono continuamente acquisiti per garantire la disponibilità quasi in tempo reale per l'integrazione dei dati a valle, l'analisi e l'IA, consentendo pipeline a bassa latenza che riflettono l'attività operativa più attuale.
Servizi di streaming come Apache Kafka e Amazon Kinesis forniscono pipeline durevoli e ad alta velocità per l'acquisizione di eventi operativi man mano che si verificano. A differenza delle origini basate su file che si basano sull'acquisizione in batch, le origini di streaming forniscono dati continuamente man mano che gli eventi vengono prodotti, consentendo l'elaborazione quasi in tempo reale senza attendere che i file vengano generati o pianificati. I produttori pubblicano messaggi strutturati o semi-strutturati che mantengono il loro schema e supportano il partizionamento. Tutti gli aggiornamenti e le eliminazioni per lo stesso record devono utilizzare la stessa chiave di partizione. Kafka e Kinesis garantiscono l'ordinamento solo all'interno di una singola partizione o shard, non attraverso l'intero argomento o flusso, quindi l'utilizzo di una chiave di partizione coerente assicura che le modifiche per un dato record vengano elaborate nella sequenza corretta. Qlik supporta anche Amazon S3 come sorgente di flusso per l'ingestione continua di dati di eventi.
Ingestione in streaming rispetto all'ingestione in batch
La differenza tra sorgenti dati di flusso e batch è la seguente:
-
Con entrambe le sorgenti, gli eventi vengono acquisiti in modo efficiente ogni minuto, supportando l'elaborazione a bassa latenza e l'analisi quasi in tempo reale.
-
Con le sorgenti non di flusso, c'è prima un caricamento completo dei dati esistenti e poi vengono acquisite le modifiche. È anche possibile ricaricare i dati di caricamento completo dalla sorgente.
-
Con le sorgenti di flusso, non c'è una chiara distinzione tra il caricamento iniziale e gli eventi successivi. Qlik può gestire la conservazione e supporta anche le partizioni.
In un progetto Qlik Open Lakehouse, le origini di streaming possono essere utilizzate solo con l'attività di trasferimento di streaming e l'attività di trasformazione di streaming:
-
I dati di streaming vengono acquisiti utilizzando un'attività di trasferimento di streaming e, invece di elaborare file discreti, l'attività di trasferimento di streaming legge gli eventi man mano che arrivano, trasferisce i dati in Amazon S3 e rende persistenti gli eventi come file Avro. Questo approccio preserva l'evoluzione dello schema, supporta tipi di dati complessi come le struct e fornisce uno storage efficiente con prestazioni di query ottimizzate, mantenendo un modello di acquisizione continuo.
-
Quando si integra un flusso di dati, viene aggiunta automaticamente un'attività di trasformazione in streaming per ogni set di dati che verrà archiviato in formato Iceberg. Facoltativamente, l'attività di trasformazione in streaming può essere utilizzata per standardizzare le strutture, arricchire i payload degli eventi o allineare i dati con i modelli di consumo a valle.
-
Un'attività di mirroring dei dati consente di replicare i set di dati provenienti da origini di streaming nei data warehouse cloud, permettendo ai sistemi a valle di consumare gli eventi di streaming senza duplicare i dati. Per ulteriori informazioni, vedere Mirroring dei dati in un data warehouse cloud..
Limitazioni
Si applicano le seguenti limitazioni a tutte le sorgenti dati:
-
Se i file sono di tipi diversi, il che può verificarsi quando provengono da più origini o versioni, l'attività di trasformazione creata utilizzando un singolo file di esempio (ad esempio, durante l'onboarding) non tiene conto automaticamente di tali differenze.
-
Se si modificano i tipi di dati nell'attività di trasferimento, ad esempio perché è necessario eseguire l'hashing dei dati, assicurarsi che i tipi di dati di trasformazione corrispondano ai nuovi tipi di dati.
