Sélectionnez un composant pour découvrir son rôle ou suivez un événement de paiement.
Exemple illustratif, sans données de paiement réelles. Valkey enrichit le traitement et OpenMetadata documente la traçabilité du flux.
01 Stockage
02 Accès aux données
03 Ingestion
04 Traitement
05 Gouvernance des données
06 Plateforme
Flux de données
L’exemple commence par un événement de paiement publié dans Kafka. Le journal conserve cet événement pour que les traitements suivants puissent le consommer et le relire si nécessaire.
Flink consomme le flux et maintient les caractéristiques d’activité utilisées pour évaluer le paiement. Le traitement combine l’événement avec des informations opérationnelles, comme les agrégations temporelles et le profil client.
Le profil client et les compteurs opérationnels sont lus dans Valkey pour enrichir le traitement Flink. Cette étape représente un accès à la mémoire, sans transmettre chaque requête au warehouse.
Le parcours représente ensuite l’écriture de l’événement et de ses résultats dans des tables Iceberg. Un snapshot identifie l’état des données disponible pour les traitements analytiques et les revues ultérieures.
Le stockage objet conserve les fichiers Parquet, métadonnées et snapshots qui sous-tendent les tables Iceberg. Cette étape montre le socle de stockage du lakehouse, partagé entre ses différents moteurs.
Lors du traitement par lots, Spark valide et transforme les données du lakehouse en jeux préparés pour l’analyse. Les résultats retournent dans Iceberg et alimentent les chargements suivants du warehouse.
Cloudberry ou Greenplum permet d’interroger et d’agréger les données préparées avec SQL distribué. Dans cet exemple, elles alimentent rapports et analyses métiers avec une source identifiable.
OpenMetadata relie les tables et rapports à leurs sources, transformations et responsables. Le parcours se termine par ce lignage, même si catalogue et contrôles de qualité interviennent sur l’ensemble de la plateforme.
Cas d’usage de la plateforme
Reporting métier traçable
Un flux gouverné relie transactions, tables versionnées et rapports traçables jusqu’aux sources.
Capturer l’événement
Kafka reçoit événements et changements en conservant l’horodatage source.
Kafka
Conserver les données brutes
Iceberg enregistre les événements bruts et conserve des snapshots consultables.
Iceberg
Valider et transformer
Spark applique les règles de qualité et isole les données à examiner.
Spark
Charger l’entrepôt
Cloudberry reçoit les données préparées avec partitionnement et distribution adaptés aux requêtes.
Cloudberry
Calculer le rapport
Les modèles SQL expriment les règles du rapport et les références versionnées.
SQL
Enregistrer le lignage
OpenMetadata relie les champs aux tables et emplacements sources.
OpenMetadata
Archiver les preuves
Le rapport, les identifiants de snapshots et les requêtes sont conservés.
Object storage
Fraude et lutte antiblanchiment en temps réel
Le traitement événementiel combine profils, règles et modèles pour les décisions et investigations sur un socle commun.
Recevoir les autorisations
Kafka ordonne les événements liés par partition de carte ou compte.
Kafka
Ajouter le contexte comportemental
Flink enrichit l’événement avec agrégats temporels et tendances.
Flink
Lire le profil
Valkey ou GemFire fournissent profil, limites et niveau de risque.
Valkey / GemFire
Exécuter le modèle
Flink calcule un score et enregistre version et caractéristiques utilisées.
Flink
Renvoyer la décision
La décision retourne au système d’autorisation et devient un événement.
GemFire
Indexer l’investigation
OpenSearch rassemble alertes, scores et caractéristiques pour l’investigation.
OpenSearch
Réinjecter les résultats
Les résultats confirmés sont stockés dans Iceberg pour de futurs entraînements Spark.
Iceberg
Vision client à 360 degrés
La plateforme réunit canaux, CRM et systèmes métiers pour l’analytique, les applications et le service client.
Ingérer les données des canaux
Kafka et CDC collectent les changements et les déposent dans Iceberg.
Kafka / CDC
Résoudre l’identité
Spark rapproche les enregistrements selon des règles d’identification.
Spark
Construire la table client
Iceberg conserve attributs, produits et droits avec historique des snapshots.
Iceberg
Servir l’analytique SQL
Cloudberry expose les modèles client et transaction aux outils BI.
Cloudberry
Publier les profils en mémoire
Valkey fournit les profils actuels aux applications et équipes de service.
Valkey
Rechercher des profils
Solr recherche noms, comptes et documents sans identifiant exact.
Solr
Gouverner les données personnelles
OpenMetadata enregistre classification, responsables et contexte du consentement.
OpenMetadata
Rapatriement d’un entrepôt cloud
La migration déplace données, schémas, pipelines et consommateurs avec exécution parallèle et validation avant bascule.
Inventorier la source
Schémas, requêtes, connexions BI, comptes et coûts sont analysés.
Assessment
Exporter vers des formats ouverts
Les données sont exportées en Parquet puis enregistrées dans Iceberg.
Iceberg
Reconstruire les schémas
Cloudberry adapte DDL, partitions et distribution aux requêtes.
Cloudberry
Déplacer pipelines et requêtes
Airflow, Spark et dbt reprennent les traitements et valident les dialectes.
Airflow / dbt
Exécuter en parallèle
Les résultats sont comparés et les écarts entre plateformes documentés.
Validation
Basculer par domaine
Chaque domaine bascule ses consommateurs avec acceptation et retour arrière définis.
Cutover
Clôturer et documenter
Le retrait de la source respecte les conservations convenues et garde les preuves.
Evidence
Journaux et audit sur votre infrastructure
Les journaux applicatifs et de plateforme sont collectés, normalisés et indexés, avec archivage et conservation documentés.
Collecter les journaux
Kafka reçoit les journaux applicatifs, bases, réseau et plateforme.
Kafka
Normaliser et enrichir
Flink applique un schéma commun et des étiquettes de système, environnement et classification.
Flink
Indexer les données récentes
OpenSearch fournit recherche, tableaux de bord et alertes aux équipes.
OpenSearch
Archiver l’historique
Les données anciennes passent en snapshots et tables Iceberg sur objets.
Iceberg
Interroger les preuves
La recherche reconstitue accès et activités sur la période conservée.
OpenSearch
Vérifier conservation et intégrité
Verrouillage d’objets, sommes de contrôle et catalogue documentent la protection.
Object storage
Socle de données pour l’IA privée
Jeux de données gouvernés, caractéristiques et index documentaires alimentent modèles et assistants avec traçabilité des sources.
Préparer les données gouvernées
Iceberg identifie par snapshots les données utilisées par chaque modèle.
Iceberg
Calculer les caractéristiques
Spark partage les définitions entre Iceberg pour l’entraînement et Valkey pour l’inférence.
Spark / Valkey
Traiter les documents
Spark prépare fragments et embeddings en conservant document et page sources.
Spark
Indexer texte et vecteurs
OpenSearch associe recherche par mots-clés et similarité vectorielle.
OpenSearch
Récupérer le contexte autorisé
Le RAG filtre les passages selon les droits avant de les transmettre au modèle.
RAG
Journaliser questions et réponses
Requêtes, sources récupérées et réponses sont conservées pour examen.
OpenSearch
Modèles de déploiement
Starter : un site et un cluster Kubernetes
Kafka, RabbitMQ et CDC alimentent les objets RustFS et les tables Iceberg ; Spark traite les données, tandis que Cloudberry, Valkey et OpenSearch les exposent. OpenMetadata apporte catalogue et traçabilité sur Kubernetes.
Exemple d’architecture de la référence. Les chiffres sont indicatifs ; dimensionnement et disponibilité sont validés par projet.
Ingestion
Kafka3 brokers
RabbitMQQuorum de 3 nœuds
Connecteurs CDCSystèmes centraux, cartes et canaux
Stockage lakehouse
Stockage objet RustFS4 nœuds, codage à effacement
Tables IcebergACID, instantanés
Traitement et accès
Spark sur KubernetesTraitements par lots et qualité
Cloudberry1 coordinateur, 4 segments
ValkeyAccès en mémoire
OpenSearchJournaux et recherche
Consommation et plateforme
BI et rapports métierOutils de requête SQL
OpenMetadataCatalogue et traçabilité
Kubernetes sur un site12–16 nœuds, exemple
Connexions entre composants
Connecteurs CDC → Kafka: Événements de modification
Kafka → Tables Iceberg: Persistance
RabbitMQ → Tables Iceberg: Messages
Stockage objet RustFS → Tables Iceberg: Fichiers
Tables Iceberg → Spark sur Kubernetes: Lecture / écriture
Spark sur Kubernetes → Cloudberry: Chargement harmonisé
Cloudberry → BI et rapports métier: SQL
Spark sur Kubernetes → Valkey: Publication des profils
Kafka → OpenSearch: Journaux
OpenMetadata → Tables Iceberg: Traçabilité
Kubernetes sur un site → Spark sur Kubernetes: Exécution
Enterprise : trois zones dans un centre de données
Répartit Kafka, le stockage et Kubernetes sur trois zones. Spark et Flink couvrent les lots et le streaming ; Cloudberry, Valkey ou GemFire et Solr ou OpenSearch offrent SQL, mémoire et recherche, avec la gouvernance OpenMetadata.
Exemple d’architecture de la référence. Les chiffres sont indicatifs ; dimensionnement et disponibilité sont validés par projet.
Ingestion
Kafka9 brokers, 3 zones
RabbitMQFiles à quorum
Ingestion CDC et fichiersSystèmes centraux, cartes et trésorerie
Stockage lakehouse
RustFS / CephCodage à effacement réparti par zone
Tables Iceberg600 To–1,5 Po utiles, exemple
HDFSHistorique étendu, facultatif
Traitement et accès
Apache SparkTraitements par lots et variables
Apache FlinkStreaming et scoring
Cloudberry MPP8–16 segments répliqués
Valkey / GemFireGrille de données en mémoire
Recherche, gouvernance et plateforme
Solr / OpenSearchRecherche, journaux et vecteurs
Kubernetes sur 3 zonesOpenMetadata, supervision et sauvegarde
Connexions entre composants
Ingestion CDC et fichiers → Kafka: Événements
Kafka → Apache Flink: Flux
Kafka → Tables Iceberg: Persistance
RabbitMQ → Apache Flink: Messages
RustFS / Ceph → Tables Iceberg: Fichiers
HDFS → Apache Spark: Historique
Tables Iceberg → Apache Spark: Lecture / écriture
Apache Flink → Tables Iceberg: Upsert en streaming
Apache Flink → Valkey / GemFire: État et décisions
Kubernetes sur 3 zones → Cloudberry MPP: Exploitation
DR : deux sites avec réplication active
Réplique événements, objets et services entre sites principal et secondaire via MirrorMaker 2, réplication des buckets et services de secours. Inclut une exploitation commune, le choix du site actif et des exercices de reprise ; les objectifs sont convenus par projet.
Exemple d’architecture de la référence. Les chiffres sont indicatifs ; dimensionnement et disponibilité sont validés par projet.
Site principal
Kafka et RabbitMQIngestion principale
Stockage objet + IcebergLakehouse principal
Warehouse, mémoire et rechercheAccès principal
Réplication
MirrorMaker 2Topics et offsets
Réplication des bucketsContinue et chiffrée
Secours et grille WANWarehouse et GemFire
Site secondaire
Kafka et RabbitMQIngestion secondaire
Stockage objet + IcebergLakehouse secondaire
Warehouse, mémoire et rechercheRapports et reprise
Exploitation
Exploitation unifiéeSupervision, sauvegarde et procédures
Aiguillage du traficSélection du site actif
Exercice périodique de basculePreuves de reprise
Connexions entre composants
Kafka et RabbitMQ → Stockage objet + Iceberg: Ingestion
Stockage objet + Iceberg → Warehouse, mémoire et recherche: Accès
Kafka et RabbitMQ → MirrorMaker 2: Miroir des événements
Stockage objet + Iceberg → Réplication des buckets: Réplication
Warehouse, mémoire et recherche → Secours et grille WAN: Transfert et réplication
MirrorMaker 2 → Kafka et RabbitMQ: Application
Réplication des buckets → Stockage objet + Iceberg: Application
Secours et grille WAN → Warehouse, mémoire et recherche: Application
Exploitation unifiée → Warehouse, mémoire et recherche: Supervision
Exploitation unifiée → Warehouse, mémoire et recherche: Supervision
Aiguillage du trafic → Warehouse, mémoire et recherche: Actif
Exercice périodique de bascule → Warehouse, mémoire et recherche: Validation
Une plateforme lakehouse intégrée
Nuxia Data Intelligence réunit stockage, ingestion, traitement, restitution et gouvernance. Les formats ouverts permettent à plusieurs moteurs de partager les données. Les versions des services sont sélectionnées et validées par projet.
Architecture par couches
Socle : Kubernetes sur virtualisation ou serveurs physiques, avec identité, réseau et observabilité communs.
Ingestion : Kafka pour les événements, RabbitMQ pour les messages et connecteurs CDC pour les bases.
Stockage : objets S3 avec RustFS ou Ceph, fichiers Parquet et tables Iceberg ; HDFS pour l’historique existant.
Traitement : Spark pour les lots et le machine learning, Flink pour les flux et Airflow pour l’orchestration.
Restitution : Cloudberry ou Greenplum pour SQL ; Valkey et GemFire/Geode pour la mémoire ; Solr et OpenSearch pour la recherche.
Les systèmes métiers publient événements et changements. L’ingestion conserve données brutes et positions pour la relecture. Spark ou Flink valident et transforment, Iceberg conserve les snapshots, SQL, BI, applications et IA consomment les résultats. Le catalogue relie sources et responsables.
Cas d’usage
Reporting traçable : relier chaque chiffre à ses sources, règles de qualité et snapshots.
Analyse du risque et des activités : historique complet avec SQL et traitements distribués.
Données pour l’IA : associer recherche documentaire, caractéristiques opérationnelles et évaluation.
Préparer la migration
Nous partons d’un domaine et d’un résultat mesurable. Inventaire, socle et premier flux sont comparés à l’existant avant extension des domaines, tests de reprise et transfert d’exploitation. Le coût total inclut matériel, énergie, licences et exploitation.
Versions, licences, compatibilités, couverture et objectifs de service sont définis après analyse de l’environnement. Le dimensionnement et les résultats sont validés sur des charges et des tests représentatifs.
Questions fréquentes
Peut-on adopter une partie du catalogue ?
Oui. L’évaluation détermine ce qu’il faut conserver, intégrer et modifier. Le projet peut commencer par une base, un flux ou un domaine lakehouse puis s’étendre.
Peut-elle fonctionner en environnement isolé ?
L’étude porte sur chaque composant et version : dépendances, images, licences, mises à jour et observabilité. L’isolement exige dépôts internes et imports vérifiés.
