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..

Mappature del tipo di dati

Lo schema di origine iniziale si basa su un campione dei dati prelevato prima della fase PREPARE durante la creazione del progetto pipeline, e l'evoluzione dello schema viene gestita al momento della lettura. Le attività di mirroring e altre attività a valle che non supportano STRUCT e ARRAY utilizzano un tipo JSON. I dati possono essere analizzati utilizzando SQL.

Le seguenti mappature dei tipi di dati si applicano a tutte le sorgenti dati supportate, ma variano in base al tipo di file di origine, e si dovrebbe notare quanto segue:

• I tipi di dati sono dedotti da un campione dei dati in fase di onboarding. Ad esempio, se un campo contiene solo valori interi nel campione, viene creato come INT8 nelle attività di trasferimento e trasformazione in flusso. Se i dati successivi includono valori frazionari a doppia precisione, i file di trasferimento contengono tali valori; tuttavia, nell'attività di trasformazione in flusso, se l'impostazione Modifica tipo di dati campo è impostata su Ignora, la colonna rimane INT8 e i valori frazionari vengono troncati. Per evitare troncamenti involontari, assicurarsi che i dati campione includano l'intera gamma di valori previsti prima dell'onboarding, o configurare Modifica tipo di dati del campo su Interrompi attività durante le fasi iniziali e regolare i tipi di dati secondo necessità.

• Se un campo viene aggiunto a una struct nell'origine, viene sempre aggiunto alla destinazione di trasferimento. Per la trasformazione in flusso, il comportamento viene applicato in base all'opzione scelta in Impostazioni attività di trasformazione in flusso > Evoluzione dello schema > Aggiungi campi alla struct (Applica alla destinazione, Ignora, Interrompi attività).

• Se un campo è mancante in un record specifico o un array è vuoto, vengono trattati come null.

• Se un set di dati viene appiattito da un array e arriva un record in cui tale array è vuoto o null, il sistema crea una riga e il campo appiattito è null. Non è escluso automaticamente. Se si desidera escludere queste righe, aggiungere manualmente un filtro, ad esempio, array_element IS NOT NULL.

• I tipi di dati visualizzati nell'interfaccia utente riflettono la granularità del set di dati selezionato. Per gli array appiattiti, viene mostrato il tipo di dati del singolo elemento anziché la struttura dell'array stessa.

• Un nuovo attributo non può essere aggiunto all'interno di una struct in un campo JSON nidificato, ma solo a livello radice.

• Nelle attività di trasformazione in streaming, l'appiattimento è supportato solo per un singolo livello di un array. Quando l'appiattimento viene applicato a un array multilivello, ad esempio ARRAY<ARRAY<STRUCT>>, solo l'array esterno viene appiattito, risultando in ARRAY<STRUCT> anziché in una STRUCT completamente appiattita. Inoltre, l'interfaccia utente attuale consente di configurare l'appiattimento solo a livello di colonna. Di conseguenza, la selezione di un array multilivello applica implicitamente l'appiattimento solo al primo livello dell'array.

JSON

Nei file JSON, il valore numerico nella sorgente determina il tipo di dati di destinazione:

• INT8 viene utilizzato per valori interi che rientrano nell'intervallo di interi supportato e non includono una componente frazionaria.

• REAL8 (DOUBLE) viene utilizzato quando il valore contiene una componente frazionaria (numero in virgola mobile).

• STRING viene utilizzato quando il valore numerico supera l'intervallo massimo di interi supportato.

I tipi di dati sono mappati come segue:

CSV, TSV, REGEX e SPLIT

Per impostazione predefinita, tutti i tipi di dati di origine vengono acquisiti come stringa. Usa l'opzione, Deduci automaticamente i tipi, per mappare i tipi di origine e di destinazione come segue:

Parquet

I file Parquet supportano tipi di dati fisici e logici. I tipi di dati fisici definiscono come i valori vengono memorizzati su disco, come INT32, DOUBLE o BYTE_ARRAY. I tipi di dati logici forniscono un significato semantico oltre la rappresentazione fisica, ad esempio, identificando se un valore intero rappresenta una data. Quando un tipo logico è allegato a una colonna Parquet ed è supportato in Qlik Open Lakehouse (come elencato di seguito), l'attività di trasferimento in streaming utilizza il tipo logico quando definisce lo schema di destinazione, anziché il tipo fisico sottostante. Ciò garantisce che i dati vengano interpretati correttamente, preserva la semantica prevista come precisione, scala e significato temporale e si traduce in schemi più accurati quando i dati vengono scritti in formati a valle.

I dati provenienti da file Parquet sono mappati come segue:

Avro

Le seguenti mappature si applicano ai file Avro con schema registry.

ORC

Le seguenti mappature si applicano ai file ORC.

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.

Sorgenti supportate