Architecture de Qlik Open Lakehouse

Qlik Open Lakehouse fournit une solution complète entièrement gérée dans Qlik Talend Cloud pour ingérer, traiter et optimiser les données dans un lakehouse basé sur Iceberg. Cette solution offre des performances de requête à faible latence et des opérations de données efficaces à grande échelle.

L'architecture Qlik Open Lakehouse associe communications sécurisées, calcul évolutif et traitement efficace des données afin d'offrir une expérience de lakehouse moderne. Qlik Open Lakehouse s'appuie sur des composants natifs AWS, notamment EC2, S3 et Kinesis.

Composants essentiels

Les entités suivantes sont nécessaires pour pouvoir créer un Qlik Open Lakehouse.

Data Movement gateway (CDC)

La passerelle Data Movement gateway s'exécute dans votre environnement sur site ou dans le cloud. Elle capture les modifications des systèmes sources tels que les SGBDR, SAP ou les mainframes et envoie les données à une zone de dépôt temporaire Amazon S3.

Agent d'intégration réseau (instance EC2)

L'agent d'intégration réseau est une instance EC2 qui facilite la communication sécurisée entre les services Qlik dans le cloud et les clusters de lakehouse au sein de votre environnement. L'agent est automatiquement déployé en tant qu'instance à la demande au cours du processus d'intégration réseau et entièrement géré par Qlik. Les nouvelles versions sont automatiquement déployées lors de leur publication.

Lorsque l'intégration réseau fonctionne correctement, le statut Connecté s'affiche sur la vue Clusters de lakehouse dans le centre d'activités Administration. En cas de problèmes de connectivité, le statut devient Déconnecté.

Cluster de lakehouse (groupe à mise à échelle automatique EC2)

Le cluster de lakehouse est un groupe d'instances EC2 AWS chargées du traitement des données. Les instances du cluster coordonnent et exécutent les charges de travail pour traiter les données entrantes provenant de la zone de dépôt temporaire et, après le traitement, stocker les données à l'emplacement cible au format Iceberg.

Un cluster de lakehouse comportant une seule instance Spot AWS est automatiquement créé lors de la configuration de votre intégration réseau. Vous pouvez gérer et créer des clusters supplémentaires pour répondre à vos besoins en lakehouse continus. Lorsque vous configurez un cluster, vous accordez à Qlik l'autorisation de créer, de démarrer, d'arrêter, de mettre à l'échelle ou de restaurer les serveurs afin de répondre aux exigences en matière de traitement des données. Chaque cluster est associé à une seule intégration réseau, bien que plusieurs clusters puissent être exécutés au sein de la même intégration réseau. Un seul cluster peut exécuter de nombreuses tâches de lakehouse.

Une instance Spot AWS utilise la capacité EC2 Amazon disponible à un coût inférieur à celui des instances normales, mais elle peut être interrompue par AWS avec très peu de préavis. Par défaut, Qlik provisionne des instances Spot éphémères pour traiter les données. S'il n'existe pas suffisamment d'instances Spot disponibles sur le marché Spot AWS, Qlik utilise automatiquement des instances à la demande pour assurer la continuité. Le système revient aux instances Spot lorsqu'elles se libèrent. La technologie de cluster de lakehouse est conçue pour assurer une transition harmonieuse entre les instances Spot et à la demande, en déplaçant les tâches entre les nœuds. Ce processus se déroule automatiquement, sans intervention manuelle. Dans les paramètres du cluster, vous pouvez configurer le nombre d'instances Spot et à la demande à utiliser dans le cluster. L'utilisation d'instances Spot permet de réduire les coûts de calcul continus de votre Qlik Open Lakehouse.

En plus de définir le nombre d'instances Spot et à la demande à utiliser, vous pouvez configurer la stratégie de mise à l'échelle correspondant le mieux à la charge de travail et au budget de votre projet. Les stratégies de mise à l'échelle suivantes peuvent être appliquées à un cluster :

• Coût bas : idéal pour les environnements de développement ou d'assurance qualité et les charges de travail qui ne dépendent pas de données actualisées en temps réel. Qlik s'efforce de maintenir le coût le plus bas possible, ce qui se traduit par des périodes occasionnelles de forte latence.

• Latence basse : conçu pour les charges de travail non essentielles pour lesquelles l'actualisation des données quasiment en temps réel est acceptable. Bien que cette stratégie vise une faible latence, il peut se produire quelques pics brefs.

• Latence basse cohérente : convient aux environnements de production avec des données à grande échelle qui doivent être actualisées en temps réel. Qlik dimensionne proactivement les instances afin de garantir une faible latence, ce qui peut entraîner des coûts plus élevés.

• Pas de mise à l'échelle : bonne option pour les charges de travail qui traitent un volume constant de données. Sélectionnez cette option pour conserver un nombre statique d'instances sans mise à l'échelle automatique et avec des coûts prévisibles.

Flux Kinesis (coordination des charges de travail)

Qlik nécessite un flux Kinesis pour assembler et relayer l'état de chaque serveur du cluster de lakehouse. Les serveurs signalent le statut des tâches et les métriques opérationnelles telles que l'UC et la mémoire directement à Kinesis, car les serveurs ne communiquent pas entre eux. Chaque serveur interroge les données du flux Kinesis pour découvrir des informations sur les autres serveurs du cluster. Cet échange d'informations permet de synchroniser le travail.

Compartiments Amazon S3

Les compartiments Amazon S3 sont utilisés comme suit :

• Compartiment de données de dépôt temporaire : les données CDC brutes sont déposées temporairement dans un compartiment S3 avant d'être transformées.

• Compartiment de configuration : stocke les métadonnées et les configurations utilisées par le système de lakehouse.

• Stockage des tables Iceberg : les données sont stockées et optimisées dans des tables au format Iceberg.

Flux général

Configuration initiale

1. Provisionnement du VPC et de l'infrastructure : configurez un VPC dans votre compte AWS ainsi que des sous-réseaux, des compartiments S3, des flux Kinesis et des rôles IAM en suivant les instructions de la documentation Qlik.

2. Configuration de l'intégration réseau : l'administrateur de clients crée une intégration réseau dans Qlik Talend Cloud en utilisant les détails d'infrastructure précédemment fournis.

3. Déploiement de composants Qlik : Qlik provisionne automatiquement la passerelle du plan de données et un cluster de lakehouse au sein de votre VPC.

4. Établir la communication : la passerelle du plan de données établit en toute sécurité la communication à Qlik Talend Cloud.

5. Déploiement de passerelle : déployez une passerelle Data Movement gateway (CDC), sur site ou dans votre environnement cloud, y compris le VPC du plan de données.

6. Prêt à fonctionner : une fois la configuration terminée, vous pouvez créer et gérer des projets et des tâches Qlik Open Lakehouse en fonction de leurs autorisations d'accès.

Création d'un projet dans Qlik Open Lakehouse

Les types de tâche suivants sont disponibles :

Tâche de données de dépôt temporaire

1. Configuration de la source : la passerelle Data Movement gateway est configurée de sorte à capturer les modifications des systèmes sources, notamment les SGBDR, SAP, les mainframes, etc.

2. Dépôt temporaire des données : la tâche CDC envoie en continu les données de modification brutes au compartiment de dépôt temporaire S3 désigné sur votre compte AWS.

Tâche de données de stockage

1. Enregistrez une connexion de catalogue Iceberg, par exemple AWS Glue Data Catalog.

2. Définissez une tâche de stockage dans Qlik Talend Cloud.

3. Qlik Talend Cloud envoie des définitions de tâche à la passerelle du plan de données.

4. La passerelle du plan de données transmet en toute sécurité les instructions de tâche au cluster de lakehouse Qlik.

5. Le cluster lit en continu les données brutes auprès d'un compartiment de dépôt temporaire dans S3, les traite et écrit la sortie dans des tables Iceberg dans S3.

6. Le cluster de lakehouse augmente ou réduit automatiquement sa capacité en fonction de la charge, selon des préférences prédéfinies dans les paramètres du cluster de lakehouse.

7. Les données de surveillance sont envoyées à Qlik Talend Cloud et les journaux et les métriques sont transmis à Qlik.

Tâche de données en miroir

Vous pouvez créer des tables Iceberg externes pour permettre l'interrogation des données stockées dans votre lac de données depuis Snowflake sans les dupliquer. Cela vous permet d'utiliser le moteur analytique Snowflake en plus des données gérées par Iceberg stockées dans des formats tels que Parquet sur S3. Le référencement des tables externes au lieu de la duplication des données dans Snowflake permet de réduire les coûts de stockage, de conserver une seule source de vérité et de garantir la cohérence entre les environnements de lakehouse et d'entrepôt.

Communication entre votre intégration réseau et Qlik Talend Cloud

L'intégration réseau établit une connexion sécurisée sortante (HTTPS) à Qlik Talend Cloud. En cas d'acceptation, la connexion est convertie en WebSocket sécurisé (Web Socket Secured ou WSS). Un canal de communication supplémentaire dédié (WSS) est établi entre l'intégration réseau et Qlik Talend Cloud pour recevoir les commandes et les contrôles des tâches spécifiques au lakehouse. Périodiquement, l'intégration réseau établit une connexion sécurisée (HTTPS) à Qlik Talend Cloud pour recevoir et envoyer des événements associés aux données. Les métriques et les journaux sont envoyés à Qlik à partir des clusters de lakehouse.

Les mesures suivantes sont prises pour garantir la sécurité de vos données :

• Toutes les connexions de votre intégration réseau à Qlik Talend Cloud sont sortantes. Aucun accès entrant n'est nécessaire.

• Les métadonnées, les commandes et les requêtes de contrôle sont transmises via des canaux de communication sécurisés par HTTPS, ce qui crée une couche de chiffrement supplémentaire entre l'intégration réseau et Qlik Talend Cloud.

• Tous les flux de données entre les ressources vous appartiennent. Les données ne sont jamais envoyées à Qlik Talend Cloud. Les métadonnées telles que les noms des tables et des colonnes sont envoyées à Qlik Talend Cloud pour permettre la définition des tâches.

• Les données sont anonymisées avant d'être envoyées à Qlik. Qlik utilise des données anonymisées pour vous aider de manière proactive si les journaux ou les métriques indiquent un problème.