Architecture des jeux des données dans un Qlik Open Lakehouse
Lorsque vous générez des jeux de données dans un Qlik Open Lakehouse, des tables de stockage, des tables de modifications et des vues sont automatiquement générées par Qlik Talend Data Integration. Vous pouvez interroger ces vues pour accéder aux données actuelles et historiques stockées au format de table ouverte Iceberg.
L'interface utilisateur intuitive et assistée vous aide à créer, modéliser et exécuter des pipelines de données. Vous pouvez générer automatiquement des schémas pour les magasins de données opérationnelles (Operational Data Stores ou ODS) et les magasins de données historiques (Historical Data Stores ou HDS), sans codage manuel.
Architecture d'un pipeline de données Qlik Open Lakehouse à l'aide de Passerelle de données Qlik - Déplacement des données. Les données sont temporairement déposées dans S3 et stockées dans un Open Lakehouse Iceberg. Éventuellement, comme indiqué ci-dessous, les tables peuvent être mises en miroir dans un data warehouse.
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, 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.
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
| Champ | Type | Description |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hachage de toutes les clés primaires des enregistrements. Le format de hachage est SHA1. Les colonnes sont séparées par un caractère de retour arrière. |
| hdr__from_timestamp | TIMESTAMP |
Horodatage au format UTC :
|
| hdr__operation | VARCHAR (1) |
Dernière opération de cet enregistrement.
|
| hdr__inserted_timestamp | TIMESTAMP | Horodatage UTC du premier ajout de la clé. En cas d'utilisation du chargement complet, il s'agit de l'heure de début du chargement complet. |
| hdr__modified_timestamp | TIMESTAMP | Horodatage UTC de la dernière mise à jour. |
Partition Prior
| Champ | Type | Description |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hachage de toutes les clés primaires des enregistrements. |
| hdr__from_timestamp | TIMESTAMP | Horodatage au format UTC. |
| hdr__to_timestamp | TIMESTAMP | Horodatage au format UTC. |
| hdr__operation | STRING (1) |
Dernière opération de cet enregistrement.
|
| hdr__was_current_from_timestamp | TIMESTAMP | Horodatage UTC de la première fois où l'enregistrement est apparu comme actuel. |
| hdr__was_current_to_timestamp | TIMESTAMP | Horodatage UTC de la dernière fois où l'enregistrement est apparu comme actuel. |
Partition Changes
| Champ | Type | Description |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
L'identifiant de la modification est une chaîne composée de deux parties :
|
| hdr__operation | VARCHAR (1) |
Dernière opération de cet enregistrement.
|
| hdr__timestamp | TIMESTAMP | Horodatage au format UTC. |
| hdr__key_hash | BINARY (20) | Hachage de toutes les clés primaires des enregistrements. |
| hdr__inserted_timestamp | TIMESTAMP | Horodatage UTC de l'heure à laquelle la modification a été traitée par Qlik. |
Partition Asset_state
| Champ | Type | Description |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | Identificateur de modification de la dernière modification appliquée à la partition Current. |
| hdr__copy_change_identifier | VARCHAR (50) | Identificateur de modification de la dernière modification ajoutée à la partition Changes. |
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 :
| Champ | Type | Description |
|---|---|---|
| hdr__key_hash | BINARY (20) | Hachage de toutes les clés primaires des enregistrements. |
| hdr__from_timestamp | TIMESTAMP | Horodatage du moment où la modification s'est produite dans le système source. Cela reflète le moment où l'utilisateur a initialement effectué la modification. |
| hdr__to_timestamp | TIMESTAMP | Horodatage du moment où la modification a été annulée ou mise à jour dans le système source. |
| hdr__store | VARCHAR (10) |
Cela indique l'emplacement de l'enregistrement :
|
| hdr__operation | STRING (1) |
Dernière opération de cet enregistrement.
|
| hdr__deleted | BIT | Indique si la suppression de l'enregistrement est réversible, selon que l'opération hdr_operation est D ou d. |
| hdr__was _current_from_timestamp | TIMESTAMP | Heure (UTC) à laquelle cette ligne est arrivée dans la partition Current. Il s'agit généralement du moment où la tâche de stockage a été exécutée et où la modification a été appliquée. |
| hdr__was _current_to_timestamp | TIMESTAMP | Heure (au format UTC) à laquelle la ligne a été retirée de la table Current, par exemple en raison d'une version plus récente. |