Architettura di Qlik Open Lakehouse

Qlik Open Lakehouse offre una soluzione end-to-end completamente gestita in Qlik Talend Cloud per ingerire, elaborare e ottimizzare i dati in un lakehouse basato su Iceberg. Questa soluzione offre prestazioni di query a bassa latenza e operazioni sui dati efficienti su larga scala.

L'architettura di Qlik Open Lakehouse combina comunicazioni sicure, calcoli scalabili e l'elaborazione efficiente dei dati, per offrire un'esperienza di lakehouse avanzata. Qlik Open Lakehouse sfrutta i componenti nativi di AWS, tra cui EC2, S3 e Kinesis.

Componenti chiave

Le seguenti entità sono necessarie per creare un Qlik Open Lakehouse.

Gateway di Data Movement (CDC)

Il gateway di Data Movement funziona nell'ambiente on-premise o cloud dell'utente. Acquisisce le modifiche dai sistemi di origine, come RDBMS, SAP o mainframe, e invia i dati a un'area di trasferimento di Amazon S3.

Agente di integrazione di rete (istanza EC2)

L'agente di integrazione di rete è un'istanza EC2 che facilita la comunicazione sicura tra i servizi di Qlik nel cloud e i cluster lakehouse nell'ambiente dell'utente. L'agente viene distribuito automaticamente come Istanza On-Demand durante il processo di integrazione di rete, ed è completamente gestito da Qlik. Le nuove versioni vengono distribuite automaticamente al momento del rilascio.

Quando l'integrazione di rete funziona correttamente, lo stato Connesso viene visualizzato nella vista dei Cluster lakehouse nel centro attività di Amministrazione. Lo stato cambia in Disconnesso se si verificano problemi di connessione.

Cluster lakehouse (gruppo di scalabilità automatica EC2)

Il cluster lakehouse è un gruppo di istanze AWS EC2 responsabili dell'elaborazione dei dati. Le istanze del cluster coordinano ed eseguono i carichi di lavoro per elaborare i dati in arrivo dall'area di trasferimento e, dopo l'elaborazione, memorizzano i dati nella posizione di destinazione in formato Iceberg.

Un cluster lakehouse con una singola istanza Spot AWS viene creato automaticamente durante la configurazione dell'integrazione di rete. È possibile gestire e creare cluster aggiuntivi per supportare le continue esigenze del proprio lakehouse. Quando si configura un cluster, si concede a Qlik l'autorizzazione per creare, avviare, arrestare, scalare o eseguire il rollback dei server per soddisfare i requisiti di elaborazione dei dati. Ogni cluster è associato a una singola integrazione di rete, anche se più cluster possono essere eseguiti nella stessa integrazione di rete. Un singolo cluster può eseguire molte attività del lakehouse.

Un'istanza Spot AWS utilizza la capacità di riserva di Amazon EC2 a un costo inferiore rispetto alle istanze normali, ma può essere interrotta da AWS con poco preavviso. Per impostazione predefinita, Qlik usa istanze Spot temporanee per l'elaborazione dei dati. Se non è disponibile un numero sufficiente di istanze Spot nel mercato Spot AWS, Qlik utilizzerà automaticamente le Istanze on-demand per garantire la continuità. Il sistema torna alle istanze Spot quando sono disponibili. La tecnologia dei cluster lakehouse è progettata per eseguire una transizione graduale tra istanze Spot e On-Demand, spostando i processi tra i nodi. Questo processo avviene automaticamente, senza richiedere un intervento manuale. Nelle impostazioni del cluster, è possibile configurare il numero di istanze Spot e On-Demand da utilizzare nel cluster. L'utilizzo di istanze Spot aiuta a ridurre i costi di calcolo correnti del Qlik Open Lakehouse.

Oltre a definire il numero di istanze Spot e On-Demand da utilizzare, è possibile configurare una strategia di scalabilità che si adatti al meglio al carico di lavoro e al budget del progetto. Le seguenti strategie di scalabilità possono essere applicate a un cluster:

• Costo ridotto: ideale per gli ambienti di sviluppo o QA e per i carichi di lavoro che non dipendono da dati attuali e in tempo reale. Qlik tenta di mantenere il costo il più basso possibile, con conseguenti periodi occasionali di latenza elevata.

• Bassa latenza: progettata per i carichi di lavoro che non sono critici, dove è accettabile un'attualità dei dati quasi in tempo reale. Sebbene questa strategia miri a una bassa latenza, si possono verificare brevi picchi.

• Bassa latenza costante: adatta per gli ambienti di produzione con dati su larga scala che devono essere attualizzati in tempo reale. Qlik scala in modo proattivo le istanze per garantire una bassa latenza, che può comportare costi più elevati.

• Nessuna scalabilità: una buona opzione per i carichi di lavoro che elaborano un volume consistente di dati. Selezionare questa opzione per mantenere un numero statico di istanze senza scalabilità automatica e con costi prevedibili.

Flusso Kinesis (coordinamento del carico di lavoro)

Qlik richiede un flusso Kinesis per raccogliere e trasmettere lo stato di ogni server del cluster lakehouse. I server riportano lo stato delle attività e le metriche operative, come CPU e memoria, direttamente a Kinesis, in quanto i server non comunicano tra loro. Ogni server esegue il polling dei dati dal flusso Kinesis per rilevare le informazioni sugli altri server all'interno del cluster. Questo scambio di informazioni consente la sincronizzazione dei processi.

Bucket Amazon S3

I bucket Amazon S3 vengono utilizzati come segue:

• Bucket per il trasferimento dei dati: i dati CDC non elaborati vengono trasferiti in un bucket S3 prima della trasformazione.

• Bucket di configurazione: memorizza i metadati e le configurazioni utilizzate dal sistema lakehouse.

• Archiviazione in tabelle Iceberg: i dati vengono archiviati e ottimizzati in tabelle in formato Iceberg.

Flusso di lavoro di alto livello

Configurazione iniziale

1. Provisioning di VPC e infrastruttura: configurare un VPC nell'account AWS oltre a sottoreti, bucket S3, flussi Kinesis e ruoli IAM seguendo le istruzioni contenute nella documentazione di Qlik.

2. Configurazione dell'integrazione di rete: l'amministratore tenant crea un'integrazione di rete in Qlik Talend Cloud utilizzando i dettagli dell'infrastruttura precedentemente forniti.

3. Distribuzione dei componenti Qlik: Qlik distribuisce automaticamente il gateway del piano dati e un cluster lakehouse nel VPC.

4. Stabilisci comunicazione: il gateway del piano dati stabilisce in modo sicuro la comunicazione con Qlik Talend Cloud.

5. Distribuzione gateway: distribuire un Data Movement Gateway (CDC) locale o nell'ambiente cloud, compreso il VPC nel piano dati.

6. Pronto per l'uso: una volta completata la configurazione, è possibile creare e gestire i progetti e le attività di Qlik Open Lakehouse in base alle autorizzazioni di accesso.

Creazione di un progetto Qlik Open Lakehouse

Sono disponibili i seguenti tipi di attività:

Attività dati di trasferimento

1. Configurazione della sorgente: il gateway di Data Movement è configurato per acquisire le modifiche dai sistemi di origine, tra cui RDBMS, SAP, mainframe e altro.

2. Trasferimento dei dati: l'attività CDC invia continuamente i dati non elaborati delle modifiche al bucket di trasferimento S3 designato nell'account AWS.

Attività dati di archiviazione

1. Registrare la connessione a un catalogo Iceberg, ad esempio AWS Glue Data Catalog.

2. Definire un'attività di archiviazione in Qlik Talend Cloud.

3. Qlik Talend Cloud invia una definizione delle attività al gateway del piano dati.

4. Il gateway del piano dati inoltra in modo sicuro le istruzioni delle attività al cluster lakehouse Qlik.

5. Il cluster legge continuamente i dati non elaborati da un bucket di trasferimento in S3, li elabora e scrive l'output nelle tabelle Iceberg in S3.

6. Il cluster lakehouse scala automaticamente verso l'alto o verso il basso in base al carico, secondo le preferenze predefinite nelle impostazioni del cluster lakehouse.

7. I dati di monitoraggio vengono inviati a Qlik Talend Cloud, mentre i log e le metriche vengono inoltrati a Qlik.

Mirroring delle attività dati

È possibile creare tabelle Iceberg esterne per consentire l'esecuzione di query sui dati archiviati nel data lake da Snowflake senza duplicarli. Ciò consente di utilizzare il motore analitico di Snowflake sopra i dati gestiti da Iceberg e archiviati in formati come Parquet su S3. Facendo riferimento alle tabelle esterne anziché duplicare i dati in Snowflake, si riducono i costi di archiviazione, si mantiene un'unica fonte di verità e si garantisce la coerenza tra ambienti lakehouse e warehouse.

La comunicazione tra l'integrazione di rete e Qlik Talend Cloud

L'integrazione di rete stabilisce una connessione protetta in uscita (HTTPS) a Qlik Talend Cloud. In caso di accettazione, la connessione viene convertita in un socket Web protetto (WSS). Inoltre, un canale di comunicazione dedicato (WSS) viene stabilito tra l'integrazione di rete e Qlik Talend Cloud per ricevere i comandi e i controlli delle attività specifiche per il lakehouse. Periodicamente, l'integrazione di rete stabilisce una connessione sicura (HTTPS) con Qlik Talend Cloud per ricevere e inviare eventi relativi ai dati. Le metriche e i registri vengono inviati a Qlik dai cluster lakehouse.

Le seguenti misure sono adottate per garantire la sicurezza dei dati:

• Tutte le connessioni dall'integrazione di rete a Qlik Talend Cloud sono in uscita. Non è richiesto alcun accesso in entrata.

• I metadati, i comandi e le richieste di controllo vengono trasmessi utilizzando canali di comunicazione protetti con HTTPS, creando un ulteriore livello di crittografia tra l'integrazione di rete e Qlik Talend Cloud.

• Tutti i flussi di dati tra le risorse di proprietà dell'utente. I dati non vengono mai inviati a Qlik Talend Cloud. I metadati, come i nomi di tabelle e colonne, ad esempio, vengono inviati a Qlik Talend Cloud per consentire la definizione delle attività.

• I dati vengono anonimizzati prima di essere inviati a Qlik. Qlik utilizza dati anonimizzati per supportare in modo proattivo l'utente se i registri o le metriche indicano un problema.