ClickHouse Data Lineage : Suivi des colonnes à travers les vues matérialisées

Traçabilité des données ClickHouse Il s'agit de la cartographie du flux des colonnes dans votre pipeline ClickHouse : quelles tables du moteur Kafka, quelles tables MergeTree et quelles requêtes SELECT de vues matérialisées alimentent chaque colonne en aval, et quelles fonctions et états agrégés transforment les données tout au long du processus. Les vues matérialisées ClickHouse étant entièrement définies en SQL, la traçabilité précise des données est obtenue par l'analyse de ce code SQL. Gudu SQLFlow Il utilise pour cela un analyseur syntaxique ClickHouse dédié et renvoie des diagrammes de lignage interactifs au niveau des colonnes.

Pourquoi la traçabilité des données de ClickHouse est un problème de vue matérialisée

Dans la plupart des entrepôts de données, la logique de transformation est gérée par des traitements par lots planifiés. Dans ClickHouse, elle est gérée par des vues matérialisées. Une vue matérialisée ClickHouse est un déclencheur d'insertion : chaque bloc écrit dans la table source est traité par la requête SELECT de la vue matérialisée et inséré dans une table cible. Les pipelines de production les enchaînent : une table du moteur Kafka alimente une vue matérialisée qui stocke les lignes brutes dans une table MergeTree ; d'autres vues matérialisées lisent cette table et alimentent les cumuls SummingMergeTree ou AggregatingMergeTree ; enfin, les tableaux de bord interrogent ces cumuls.

Cette conception est rapide, mais elle disperse votre flux de données sur de nombreux petits processus. CRÉER UNE VUE MATÉRIALISÉE relevés. Lorsqu'une donnée du tableau de bord semble incorrecte ou qu'une personne souhaite supprimer une colonne d'un sujet Kafka, il faut reconstruire la chaîne manuellement : requête système.tables, lisez chaque clip vidéo créer_requête_table, suivez chaque À Répétez l'opération jusqu'à atteindre les feuilles. Chaque itération correspond à une requête SELECT avec ses propres expressions, filtres et GROUP BY ; ainsi, pour analyser correctement une seule colonne, il faut analyser le code SQL, et non rechercher des noms de tables.

SQLFlow automatise précisément cette étape. Son analyseur ClickHouse est l'un des 39 analyseurs spécifiques à un dialecte (et non une grammaire ANSI générique), donc les constructions propres à ClickHouse — les clauses du moteur, Fonction d'agrégation colonnes, -État combinateurs, fonctions comme à ce jour et unique — sont comprises plutôt qu'ignorées.

Exemple : suivi d’une colonne de Kafka vers un AggregatingMergeTree

Voici une chaîne d'ingestion ClickHouse typique à deux sauts : une table du moteur Kafka, une MV qui stocke les événements bruts dans MergeTree et une seconde MV qui conserve un cumul pré-agrégé dans une table AggregatingMergeTree.

CREATE TABLE events_kafka ( event_time DateTime, user_id UInt64, event_type LowCardinality(String), revenue Decimal(18, 2) ) ENGINE = Kafka SETTINGS kafka_broker_list = 'kafka:9092', kafka_topic_list = 'events', kafka_format = 'JSONEachRow'; CREATE TABLE events_raw ( event_time DateTime, user_id UInt64, event_type LowCardinality(String), revenue Decimal(18, 2) ) ENGINE = MergeTree ORDER BY (event_type, event_time); CREATE MATERIALIZED VIEW mv_events_raw TO events_raw AS SELECT event_time, user_id, event_type, revenue FROM events_kafka; CREATE TABLE revenue_daily ( day Date, event_type LowCardinality(String), total_revenue AggregateFunction(sum, Decimal(18, 2)), buyers AggregateFunction(uniq, UInt64) ) ENGINE = AggregatingMergeTree ORDER BY (day, event_type); CREATE MATERIALIZED VIEW mv_revenue_daily TO revenue_daily AS SELECT toDate(event_time) AS day, event_type, sumState(revenue) AS total_revenue, uniqState(user_id) AS buyers FROM events_raw WHERE event_type = 'purchase' GROUP BY day, event_type;

Injectez ces quatre instructions dans SQLFlow, qui résout la chaîne complète. Pour le tableau récapitulatif, il affiche, par colonne de sortie :

• revenu_quotidien.revenu_total vient de événements_raw.revenu à travers sommeState(), qui à son tour provient de événements_kafka.revenu à travers mv_events_raw — un chemin complet de Kafka à rollup dans un seul diagramme.
• revenu_quotidien.jour dérive de événements_brut.temps_événement via à ce jour(); la fonction appliquée est enregistrée sur le bord, elle n'est pas supprimée.
• revenus_quotidiens.acheteurs dérive de événements_raw.user_id via uniqState().
• events_raw.event_type influences chaque colonne de cumul indirectement, en raison de OÙ type_événement = 'achat' filtre et le GROUPER PAR — SQLFlow les considère comme une lignée indirecte, distincte des arêtes de flux de données direct.

Ce dernier point est plus important dans ClickHouse que dans la plupart des autres moteurs. L'exactitude des cumuls dépend souvent de colonnes de filtre qui n'apparaissent jamais dans le résultat. Si quelqu'un renomme type_événement Dans le sujet Kafka, la traçabilité au niveau de la table indique « le cumul dépend de events_raw » — vrai et inutile. La traçabilité au niveau de la colonne avec des liens indirects indique «revenu_total et acheteurs « Les deux sont filtrés par cette colonne précise », ce qui constitue la réponse dont vous avez besoin avant de déployer la modification. La plupart des outils de traçabilité ne modélisent pas du tout la traçabilité indirecte ; SQLFlow, quant à lui, en fait une couche activable/désactivable séparément dans le diagramme.

Que SQLFlow extrait-il de ClickHouse SQL ?

• Lignée au niveau de la colonne : Pour chaque colonne de sortie, les colonnes sources exactes qui l'alimentent, ainsi que les fonctions, conversions, sous-requêtes, jointures et opérateurs ensemblistes utilisés. Les références aux colonnes sont résolues via des CTE, des sous-requêtes, des vues, etc. SÉLECTIONNER * expansion.
• Lignée directe vs. indirecte : Les arêtes de flux de données pur sont maintenues séparées des arêtes d'influence (colonnes utilisées dans OÙ, GROUPER PAR, et les conditions de jonction), et chaque couche peut être activée/désactivée indépendamment.
• Chaînes MV multi-sauts : Étant donné que chaque requête SELECT de MV est analysée et que sa table cible est liée, les vues matérialisées chaînées se résolvent en un seul graphe continu allant de la table d'ingestion au cumul final.
• Diagrammes interactifs et données structurées : Explorez le diagramme en détail, exportez la lignée au format JSON, CSV ou PNG, ou récupérez-la par programmation via l'API REST.

Comment importer votre SQL ClickHouse dans SQLFlow

1. Coller ou télécharger. Copiez les définitions DDL et MV (par exemple, le créer_requête_table valeurs hors de système.tablesVous pouvez les intégrer à votre navigateur ou télécharger vos fichiers de migration. C'est la méthode la plus rapide pour auditer un pipeline.
2. Se connecter via JDBC. SQLFlow peut extraire les métadonnées d'une base de données en direct via JDBC, de sorte que les définitions de tables et de vues proviennent directement du serveur au lieu de fichiers potentiellement obsolètes.
3. Automatiser l'extraction. Le Grabit/Ingéreur SQLFlow Cet utilitaire extrait les métadonnées selon une planification permettant des analyses complètes et répétables.

Dans tous les modes, SQLFlow effectue uniquement une analyse statique du code SQL. Il ne lit jamais les lignes de vos tables. Édition sur site (Docker/Kubernetes, compatible avec l'isolation physique) même le texte SQL ne quitte jamais votre réseau — pertinent si votre cluster ClickHouse transporte des données d'événements que vous ne pouvez pas envoyer à un SaaS.

Méthodes d'obtention de la lignée à partir de ClickHouse, comparées

Approche	Bon en	Gap pour les chaînes ClickHouse MV
En lisant système.tables manuellement	Gratuit, toujours à jour, sans outil	Vous devenez l'analyseur syntaxique ; les chaînes à sauts multiples et les chemins par colonne sont reconstruits manuellement et finissent par devenir obsolètes dans votre mémoire.
Analyseurs syntaxiques open source (SQL Lineage, sqlglot)	Scripting des vérifications de lignage pour les requêtes individuelles au sein de vos propres outils	Ce sont des bibliothèques, et non des produits de lignage : l’assemblage d’instructions MV chaînées en un graphe navigable au niveau des colonnes, avec des diagrammes et une séparation de lignage indirect, est du code que vous écrivez et maintenez.
Plateformes axées sur le catalogue	Flux de gouvernance, propriété, glossaire métier pour l'ensemble de la pile	La profondeur de la lignée dépend de leur analyse SQL par dialecte ; un analyseur spécialisé va généralement plus loin dans l’analyse de la lignée ClickHouse au niveau des colonnes.
Gudu SQLFlow	Traçabilité ClickHouse au niveau des colonnes à partir d'un analyseur syntaxique de dialecte dédié, avec séparation directe/indirecte et diagrammes	Outil commercial ; analyse statique par conception — il cartographie la logique SQL, et non la télémétrie des tâches d'exécution.

Ces approches combinent également les avantages suivants : les déploiements SQLFlow d’entreprise exportent la traçabilité vers DataHub, Microsoft Purview et OpenMetadata, permettant ainsi à SQLFlow de servir de moteur d’analyse syntaxique pour le catalogue existant. À grande échelle, il effectue des analyses par lots de plus de 100 bases de données et de plus d’un million de colonnes grâce à des analyses incrémentales et un référentiel de traçabilité persistant — ClickHouse s’intègre parfaitement à votre infrastructure.

ClickHouse vit rarement seul

Le service en temps réel dans ClickHouse fonctionne généralement en parallèle avec d'autres moteurs : une couche de fédération, des outils d'analyse locale et un entrepôt de données par lots. SQLFlow analyse tous ces éléments avec le même moteur : le General SQL Parser, développé commercialement depuis le milieu des années 2000 et validé sur environ 13 600 jeux de test par dialecte. Ainsi, la traçabilité est conservée au niveau des colonnes, indépendamment du moteur utilisé. Si votre infrastructure inclut ces moteurs, consultez les guides associés. Traçabilité des données Trino pour les couches de requêtes fédérées et Traçabilité des données DuckDB pour les analyses en temps réel, ou parcourez le base de connaissances sur la traçabilité des données.

Foire aux questions

SQLFlow peut-il retracer la lignée à travers des vues matérialisées ClickHouse chaînées ?

Oui. Chaque requête SELECT de vue matérialisée est analysée et sa table cible est liée au graphe. Ainsi, une table du moteur Kafka alimentant une vue matérialisée, qui alimente une table MergeTree, qui alimente une autre vue matérialisée dans un AggregatingMergeTree, se résout en un seul chemin continu au niveau des colonnes.

SQLFlow comprend-il la syntaxe SQL spécifique à ClickHouse ?

Oui. ClickHouse est l'un des 39 analyseurs syntaxiques spécifiques à un dialecte de SQLFlow. Il s'agit d'une grammaire dédiée, et non d'un analyseur ANSI générique ; par conséquent, les constructions ClickHouse telles que les clauses du moteur et les colonnes d'état des fonctions d'agrégation sont analysées et non ignorées.

SQLFlow a-t-il besoin d'accéder à mes données ClickHouse ?

Non. SQLFlow effectue une analyse statique du code SQL et, en option, des métadonnées de schéma récupérées via JDBC. Il ne lit jamais les lignes de vos tables, et l'édition sur site conserve même le texte SQL au sein de votre réseau.

Que signifie « lignée indirecte » pour un regroupement ClickHouse ?

Une colonne utilisée dans le filtre WHERE ou le GROUP BY d'une vue matérialisée n'apparaît jamais dans le résultat du cumul, mais elle détermine les lignes agrégées. SQLFlow enregistre ces lignes comme des liens de lignage indirects, distincts du flux de données direct, et permet d'afficher ou de masquer chaque couche dans le diagramme.

Quel est le coût de SQLFlow pour la traçabilité ClickHouse ?

SQLFlow Cloud propose une version gratuite ; la version Premium coûte 49,99 £/mois. SQLFlow On-Premise coûte 500 £/mois ou 4 800 £ (paiement unique) par type de base de données sélectionné, et peut être installé sur deux serveurs. Plus d'informations sont disponibles sur le site web. page de tarification.