Architecture des jeux des données dans un Qlik Open Lakehouse

Les sources de flux ont leur propre architecture dans Qlik Open Lakehouse, car elles ne nécessitent pas Data Movement gateway pour charger des données dans le compartiment de dépôt temporaire, mais sont alimentées par le cluster du lakehouse.

Lorsque vous ingérez des données provenant de fichiers qui incluent un modèle de données dans le nom du fichier, cela permet au cluster du lakehouse d'effectuer des opérations de liste ciblées dans S3, ce qui accélère considérablement la vitesse de lecture de la liste de fichiers. De plus, Qlik Open Lakehouse peut prédire les fichiers entrants en fonction du modèle de date. La tâche de dépôt temporaire de flux n'a pas à répertorier l'intégralité du compartiment à chaque fois, mais peut au lieu de cela demander les fichiers auprès de S3 dans une plage de dates spécifique. Si la liste de fichiers est plus petite, cela améliore les performances. Le paramètre facultatif Supprimer après le chargement peut être utilisé pour conserver un petit nombre de fichiers. Aucun chargement complet n'est effectué et les premiers enregistrements sont considérés comme des modifications insérées.

Dans un Qlik Open Lakehouse, la tâche de transformation de flux remplace la tâche de stockage. Cette tâche est utilisée pour transformer et stocker les données déposées temporairement sous forme de tables Iceberg. Une tâche de transformation de flux ne peut être ajoutée qu'après une tâche de dépôt temporaire de flux. La tâche de transformation de flux supporte deux modes de mise à jour des enregistrements :

• Écrire à la suite uniquement : ajoute de nouveaux enregistrements sans modifier les données existantes et les contraintes de clé ne sont pas appliquées si des enregistrements en double arrivent.

• Appliquer les modifications (Fusionner) : met à jour les enregistrements existants et insère de nouveaux enregistrements en se basant sur les champs clés. Ce mode vous offre la possibilité d'utiliser une suppression réversible ou de conserver les données historiques (Type 2).

La tâche de transformation de flux est une tâche basée sur la cible qui effectue un mappage entre la source et la cible et inclut des capacités d'évolution de schéma. Elle offre des capacités de transformation étendues, notamment la désimbrication des structures imbriquées et l'aplatissement des tableaux. Pour plus d'informations sur les fonctions que vous pouvez utiliser dans la tâche de transformation de flux, consultez Fonctions de transformation.

Lorsque vous procédez à une ingestion à partir d'une source de flux, vous avez la possibilité de configurer le partitionnement Iceberg, la gestion de la rétention, les colonnes de tri, l'expiration des instantanés pour contrôler les coûts de stockage ainsi que d'optimiser les performances des requêtes.

Les tables de dépôt temporaire.

Les champs d'en-tête suivants sont ajoutés aux tables de dépôt temporaire. Ces champs existent toujours dans les données de dépôt temporaire, mais, par défaut, ils n'existent pas dans la transformation en aval. Vous pouvez ajouter les champs à la transformation à l'aide d'une expression.

Schémas

Les artefacts sont générés dans un schéma interne et un schéma de tâche de données.

• Le schéma interne contient une table physique avec plusieurs partitions.

• Le schéma de tâche de données contient les vues que vous pouvez utiliser pour consommer les données.

  Lorsqu'un schéma est associé à plus d'une tâche de données, chaque tâche de données doit utiliser un préfixe unique pour les tables et les vues. Vous pouvez définir le préfixe dans les paramètres de tâche de données.

Les conflits de nommage sont recherchés uniquement dans les schémas internes. Pour les autres schémas, vous devez vous assurer qu'il n'existe aucun conflit de nommage dans les noms de table. La bonne pratique consiste à donner au schéma interne le même nom que celui du schéma de tâche de données en y ajoutant _internal. Cela garantit que chaque combinaison de schéma et de préfixe est unique.

Tables

Pour chaque table source, une table est créée dans le schéma interne avec le suffixe _internal via le format :

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Cette table contient cinq partitions en mode Appliquer les modifications (Fusionner), chacune ayant une fonction distincte dans la manière dont les données sont traitées et stockées. Chaque partition exploite un sous-ensemble de colonnes de la table en fonction de son rôle dans le cycle de vie des données. En mode Écrire à la suite uniquement, la table n'a pas de partitions et se comporte comme la partition Current (ODS).

Le jeu de données interne est structuré de sorte à gérer efficacement les données entrantes de votre système source, en supportant l'ingestion en temps réel et le suivi historique. Le flux de données est géré par plusieurs partitions spécialisées, chacune étant décrite ci-dessous :

• Partition Changes : ingestion en temps réel

  Toutes les modifications provenant du système source (insertions, mises à jour et suppressions) commencent par être ajoutées à la partition Changes.

  • Jouant le rôle de journal des modifications brut, la partition fournit un flux complet d'activité source avant toute transformation.

  • À chaque modification est affecté un type (I, U ou D), qui indique la manière dont elle est traitée.

  • Les événements sont capturés auprès de la source à mesure qu'ils se produisent. La partition est mise à jour quasiment en temps réel.

  • La partition Changes est disponible lorsque les paramètres suivants sont appliqués dans la tâche Dépôt temporaire de données dans un lac.

    • Dans l'onglet Général, la Méthode de mise à jour est définie sur CDC.

    • Le Chargement complet est activé.

• Partition Asset_state : suivi de l'état d'avancement

  À mesure de l'ingestion des modifications, la partition Asset_state consigne deux horodatages clés :

  • La date à laquelle les modifications ont été ajoutées pour la dernière fois à la partition Changes.

  • La date à laquelle les modifications ont été appliquées pour la dernière fois à la partition Current.

  Cela permet d'avoir une visibilité totale sur le pipeline de synchronisation et facilite la surveillance ou le dépannage.

• Partition Current (ODS) : réplique la plus récente de la source

  Les modifications de la partition Changes sont périodiquement appliquées à la partition Current afin de maintenir une copie des données sources qui soit à jour et optimisée pour les requêtes.

  • Une tâche d'arrière-plan s'exécute automatiquement pour appliquer ces mises à jour. Elle est basée sur le volume des modifications accumulées et non sur une planification fixe.

  • Le Chargement complet initial est écrit directement dans la partition Current.

  • Cette partition reflète l'état actuel des données et est conçue pour garantir l'efficacité des requêtes.

• Partition Prior (HDS) : données historiques

  Lorsqu'un enregistrement est mis à jour ou supprimé dans la partition Current, une copie de la version précédente est écrite dans la partition Prior. 

  • Les enregistrements contiennent des métadonnées, notamment l'historique des modifications et la plage de dates de validité des données.

  • Ce comportement supporte la dimension à changement lent de type 2 (SCD2).

  • La partition Prior est disponible lorsque l'option Conserver les enregistrements historiques et l'archive des enregistrements des modifications est activée dans l'onglet Général des paramètres de la tâche de données de stockage.

  • Lorsqu'une version mise à jour d'un enregistrement entre dans la partition Current, l'enregistrement précédent est déplacé vers la partition Prior à des fins de suivi de l'historique.

• Partition Reload

  La partition Reload sert de zone intermédiaire temporaire lors des chargements complets manuels ou planifiés :

  • Les nouvelles données commencent par être écrites dans la partition Reload.

  • Des tâches de maintenance régulières effacent toutes les modifications en attente avant qu'elles ne soient mises en pause.

  • Les données sont comparées à la partition Current et seules les différences sont déplacées vers la partition Current.

  • Une fois l'opération terminée, la partition Reload est effacée.

  Ce processus garantit une perturbation minimale du jeu des données principal lors des opérations de chargement complet.

Partition Current

Partition Prior

Partition Changes

Partition Asset_state

Partition Reload

Les colonnes utilisées par la partition Reload sont identiques à celles de la partition Current.

Vues

Toutes les vues créées sont mises à jour quasiment en temps réel. Les vues suivantes sont disponibles pour simplifier le lancement de requêtes et la génération de rapports :

Current

La vue Current reflète l'état le plus récent des données. Cette vue représente une réplique de la table source, mise à jour quasiment en temps réel. Elle fusionne les données des partitions Current et Changes.

Nom : <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

Aucune colonne d'en-tête n'est ajoutée à la structure de la table.

Historique

Une vue Historique est générée dans le schéma de ressources de données pour chaque table source sélectionnée lorsque Historique est activé dans les paramètres de la tâche de données. La vue Historique fusionne les données des partitions Prior et Changes. Elle fournit une chronologie complète des modifications, idéale pour l'audit ou l'analyse historique.

Nom : <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

Les champs d'en-tête suivants sont ajoutés à la vue Historique :