Connexion à des flux de données

Les services de flux suivants sont supportés dans les projets Qlik Open Lakehouse. Les données d'événement sont ingérées en continu pour garantir une disponibilité quasiment en temps réel pour l'intégration de données en aval, l'analyse et l'IA, permettant des pipelines à faible latence qui reflètent l'activité opérationnelle la plus récente.

Les services de flux tels qu'Apache Kafka et Amazon Kinesis fournissent des pipelines haut débit durables pour capturer les événements opérationnels à mesure qu'ils se produisent. Contrairement aux sources basées sur des fichiers qui reposent sur l'ingestion par lots, les sources de flux fournissent des données en continu à mesure que les événements se produisent, permettant un traitement quasiment en temps réel sans attendre que les fichiers soient générés ou planifiés. Les producteurs publient des messages structurés ou semi-structurés qui conservent leur schéma et supportent le partitionnement. Toutes les mises à jour et suppressions du même enregistrement doivent utiliser la même clé de partition. Kafka et Kinesis garantissent l'ordre uniquement au sein d'une seule partition ou d'un seul shard, et non sur l'ensemble de la rubrique ou du flux, de sorte que l'utilisation d'une clé de partition cohérente garantit le traitement dans le bon ordre des modifications d'un enregistrement donné. Qlik supporte également Amazon S3 comme source de flux pour l'ingestion continue de données d'événements.

Différence entre l'ingestion de flux et l'ingestion par lots

La différence entre les sources de données de flux et par lots est la suivante :

• Avec les deux sources, les événements sont ingérés efficacement à chaque minute, supportant le traitement à faible latence et l'analyse quasiment en temps réel.

• Avec les sources hors flux, il commence par se produire un chargement complet des données existantes, puis les modifications sont ingérées. Vous pouvez également actualiser les données de chargement complet à partir de la source.

• Avec les sources de flux, il n'existe pas de distinction claire entre le chargement initial et les événements ultérieurs. Qlik peut gérer la conservation et supporte également les partitions.

Dans un projet Qlik Open Lakehouse, les sources de flux peuvent être utilisées uniquement avec la Tâche de dépôt temporaire de flux et la Tâche de transformation de flux :

• Les données de flux sont ingérées à l'aide d'une Tâche de dépôt temporaire de flux, et, au lieu de traiter des fichiers discrets, la Tâche de dépôt temporaire de flux lit les événements à mesure qu'ils arrivent, dépose temporairement les données dans Amazon S3 et persiste les événements sous forme de fichiers Avro. Cette approche préserve l'évolution du schéma, supporte les types de données complexes tels que les structs et offre un stockage efficace avec des performances de requête optimisées tout en maintenant un modèle d'ingestion continu.

• Lorsque vous intégrez des données à partir d'une source de flux, une Tâche de transformation de flux est automatiquement ajoutée pour chaque jeu de données qui sera stocké au format Iceberg. En option, la Tâche de transformation de flux peut être utilisée pour standardiser les structures, enrichir les charges utiles d'événements ou aligner les données sur les modèles de consommation en aval.

• Une Tâche Refléter les données permet de mettre en miroir des jeux de données provenant de sources de flux dans des entrepôts de données cloud, pour que les systèmes en aval puissent consommer des événements de flux sans dupliquer de données. Pour plus d'informations, consultez Mise en miroir des données dans un entrepôt de données cloud.

Mappage de types de données

Le schéma source initial est basé sur un échantillon des données prélevées avant la phase PREPARE lors de la création de votre projet de pipeline, et l'évolution du schéma est traitée lors de la lecture. Les tâches de mise en miroir et les autres tâches en aval qui ne supportent pas STRUCT et ARRAY utilisent un type JSON. Les données peuvent être analysées via SQL.

Les mappages de types de données suivants s'appliquent à toutes les sources de données compatibles, mais varient en fonction du type de fichier source, et il convient de tenir compte des points suivants :

• Les types de données sont déduits d'un échantillon des données en cours d'intégration. Par exemple, si un champ ne contient que des valeurs entières dans l'échantillon, il est créé en tant qu'INT8 dans les tâches de dépôt temporaire et de transformation de flux. Si les données ultérieures incluent des valeurs fractionnaires à double précision, les fichiers de dépôt temporaire contiennent ces valeurs ; cependant, dans la tâche de transformation de flux, si le paramètre Modifier le type de données du champ est défini sur Ignorer, la colonne reste INT8 et les valeurs fractionnaires sont tronquées. Pour éviter une troncature involontaire, assurez-vous que l'échantillon de données inclut la gamme complète des valeurs attendues avant l'intégration, ou configurez Modifier le type de données du champ sur Arrêter la tâche lors des premières étapes et ajustez les types de données, si nécessaire.

• Si un champ est ajouté à une struct dans la source, il est toujours ajouté à la cible de dépôt temporaire. Pour la transformation de flux, le comportement est appliqué en fonction de l'option sélectionnée dans Paramètres de la tâche de transformation de flux > Évolution du schéma > Ajouter des champs à la struct (Appliquer à la cible, Ignorer, Arrêter la tâche).

• S'il manque un champ dans un enregistrement spécifique, ou si une séquence est vide, ce champ ou cette séquence est traité(e) comme nul(le).

• Si un jeu de données est aplati par une séquence et qu'un enregistrement arrive avec cette séquence vide ou nulle, le système crée une ligne et le champ aplati est nul. Il n'est pas automatiquement exclu. Si vous souhaitez exclure ces lignes, ajoutez manuellement un filtre, par exemple, array_element IS NOT NULL.

• Les types de données affichés dans l'IU reflètent la granularité du jeu de données sélectionné. Pour les séquences aplaties, le type de données de l'élément individuel est affiché plutôt que la structure de séquence elle-même.

• Un nouvel attribut ne peut pas être ajouté à l'intérieur d'une struct dans un champ JSON imbriqué, seulement au niveau racine.

• Dans les tâches de transformation de flux, l'aplatissement n'est supporté que pour un seul niveau d'une séquence. Lorsque l'aplatissement est appliqué à une séquence à plusieurs niveaux, par exemple, ARRAY<ARRAY<STRUCT>>, seule la séquence externe est aplatie, ce qui donne ARRAY<STRUCT> plutôt qu'une STRUCT entièrement aplatie. De plus, l'IU actuelle permet de configurer l'aplatissement uniquement au niveau de la colonne. Par conséquent, la sélection d'une séquence à plusieurs niveaux applique implicitement l'aplatissement uniquement au premier niveau de la séquence.

JSON

Dans les fichiers JSON, la valeur numérique dans la source détermine le type de données cible :

• INT8 est utilisé pour les valeurs entières qui se situent dans la plage d'entiers supportée et n'incluent pas de composante fractionnaire.

• REAL8 (DOUBLE) est utilisé lorsque la valeur contient une composante fractionnaire (nombre à virgule flottante).

• STRING est utilisé lorsque la valeur numérique dépasse la plage d'entiers maximale supportée.

Les types de données sont mappés comme suit :

CSV, TSV, REGEX, et SPLIT

Par défaut, tous les types de données sources sont ingérés sous forme de chaîne. Utilisez l'option Déduire automatiquement les types pour mapper les types sources et cibles comme suit :

Parquet

Les fichiers Parquet supportent les types de données physiques et logiques. Les types de données physiques définissent la manière dont les valeurs sont stockées sur le disque, comme INT32, DOUBLE ou BYTE_ARRAY. Les types de données logiques fournissent une signification sémantique en plus de la représentation physique, par exemple en identifiant si une valeur entière représente ou non une date. Lorsqu'un type logique est joint à une colonne Parquet et est supporté dans Qlik Open Lakehouse (comme indiqué ci-dessous), la tâche de dépôt temporaire de flux utilise le type logique lors de la définition du schéma cible plutôt que le type physique sous-jacent. Cela garantit l'interprétation correcte des données, préserve les sémantiques prévues telles que la précision, l'échelle et la signification temporelle et aboutit à des schémas plus précis lorsque les données sont écrites dans des formats en aval.

Les données provenant de fichiers Parquet sont mappées comme suit :

Avro

Les mappages suivants s'appliquent aux fichiers Avro avec registre de schémas.

ORC

Les mappages suivants s'appliquent aux fichiers ORC.

Limitations

Les limitations suivantes s'appliquent à toutes les sources de données :

• Si vos fichiers sont de types différents, ce qui peut se produire lorsqu'ils proviennent de plusieurs sources ou versions, la tâche de transformation créée à l'aide d'un seul fichier d'échantillon (par exemple, lors de l'intégration) ne tient pas automatiquement compte de ces différences.

• Si vous modifiez les types de données dans la tâche de dépôt temporaire, par exemple parce que vous devez hacher les données, assurez-vous que les types de données de transformation correspondent aux nouveaux types de données.

Sources supportées