☁️ Cloudera – Guide complet Data Platform, Lakehouse, Streaming & IA

Architecture hybride, Cloudera Anywhere Cloud, Iceberg, Spark/Airflow, Hive/Impala/Trino, NiFi/Kafka/Flink, Ozone/HDFS, HBase, SDX/Ranger/Atlas, Data Lineage, Cloudera AI, exploitation et migration.

Mise à jour : 27 août 2026

Objectif du guide

Ce guide présente Cloudera comme une plateforme moderne de données et d’IA, et non comme une simple distribution Hadoop. Il couvre l’héritage CDH/HDP, les déploiements cloud et on-premises, le nouveau positionnement Anywhere Cloud, le lakehouse ouvert Apache Iceberg, la couche streaming, les moteurs analytiques, la gouvernance SDX, le stockage Ozone/HDFS, l’IA d’entreprise et l’exploitation production.

Cloudera Anywhere Cloud Open Data Lakehouse Apache Iceberg Data in Motion Enterprise AI SDX On cloud / On premises

Note 2026 : Cloudera Anywhere Cloud™ a été annoncé le 19 août 2026 comme une plateforme hybride modulaire destinée à déployer des applications data/AI sur multi-cloud, infrastructure souveraine et datacenters privés. Ce guide conserve aussi le vocabulaire CDP lorsque les APIs, documents ou installations existantes l’utilisent encore.

Liens officiels utiles

Ressource	Lien	Utilité
Plateforme & produits	Products	Cartographie actuelle des produits Cloudera.
Documentation	Documentation	Guides cloud, on-premises, services et releases.
Open Data Lakehouse	Lakehouse	Apache Iceberg et interopérabilité.
Data in Motion	Streaming	NiFi, Kafka, Flink et edge.
Cloudera AI	AI	AI, Workbench, Inference, Studios, Assistants.

1.1

Vue d'ensemble Cloudera

Comprendre ce qu'est Cloudera en 2026 : plateforme hybride de données et d'IA, lakehouse, streaming, gouvernance et services analytiques.

Data & AIHybridLakehouseEnterprise

1.2

Évolution : Hadoop → CDH → plateforme hybride

Replacer Cloudera dans son histoire pour comprendre les termes CDH, HDP, CDP, Private Cloud Base et la nomenclature 2026.

CDHHDPCDP2026

2.1

Architecture globale & plans de contrôle

Décomposer Cloudera en stockage, compute, services de données, sécurité, metadata, management et réseau.

Control PlaneData PlaneSDXRuntime

2.2

Déploiements : cloud, on-premises, hybride

Comparer AWS/Azure/GCP, Base on premises, Data Services, OpenShift/ECS et nouveaux scénarios Anywhere Cloud.

AWSAzureGCPOpenShiftECS

3.1

Open Data Lakehouse & Apache Iceberg

Comprendre le format de table Iceberg, les snapshots, l’évolution de schéma, le partage multi-moteurs et le REST Catalog.

IcebergLakehouseSnapshotsOpen

3.2

Data Engineering : Spark, Airflow, CDC

Construire, orchestrer et exploiter des pipelines Spark sur Iceberg avec sessions interactives et orchestration Airflow.

SparkAirflowCDCPipelines

3.3

Data Warehouse & SQL Engines

Virtual Warehouses, Hive/Impala, Trino, BI, fédération, workload isolation et optimisation SQL.

SQLImpalaHiveTrinoBI

3.4

Operational Database : HBase, Phoenix, Solr

Base NoSQL large colonne pour accès temps réel, SQL via Phoenix, recherche Solr, haute disponibilité et DR.

HBasePhoenixSolrNoSQL

4.1

Data in Motion : NiFi, Kafka, Flink & Edge

Ingestion, transport, traitement temps réel et edge avec Data Flow, Streaming et Edge Management.

NiFiKafkaFlinkMiNiFiEdge

4.2

Cloudera AI, Inference, Studios & Assistants

Cycle de vie IA/ML et GenAI : développement, RAG, déploiement de modèles, inference, gouvernance et observabilité.

AIGenAIRAGInferenceMLOps

5.1

SDX, Ranger, Atlas, Catalog & Lineage

Sécurité et gouvernance unifiées : politiques d’accès, masking, classification, catalogue, metadata et lineage multi-systèmes.

SDXRangerAtlasCatalogLineage

5.2

Stockage : Ozone, HDFS & Object Stores

Passer du modèle HDFS aux architectures objet S3-compatible, comprendre Ozone, erasure coding, snapshots et migration.

OzoneHDFSS3Storage

6.1

Cloudera Manager & Management Console

Administrer clusters et services : agents, rôles, role groups, health, configuration, API, upgrades et monitoring.

Cloudera ManagerAgentsRolesAPI

6.2

Observabilité, performance & capacité

Construire un modèle de monitoring par couche : hosts, JVM, stockage, compute, SQL, streaming, AI, coûts et SLO.

MetricsSLOCapacityFinOps

7.1

Runbook d’exploitation production

Contrôles quotidiens, changements, sauvegardes, upgrades, certificats, capacité, incidents et DR.

RunbookOperationsBackupDR

7.2

Dépannage multi-couches

Méthode systématique de diagnostic pour réseau, stockage, metadata, sécurité, Spark, SQL, streaming, HBase et IA.

TroubleshootingLogsMetricsRCA

8.1

Migration & modernisation progressive

Moderniser CDH/HDP/HDFS/Hive vers lakehouse, Ozone, Data Services et architectures hybrides sans big-bang.

MigrationModernizationIcebergOzone

8.2

Security Hardening & Zero Trust

Durcir identité, réseau, TLS, Kerberos/LDAP, Ranger, KMS, secrets, audit, service accounts et souveraineté.

TLSKerberosRangerKMSZero Trust

9.1

Architectures de référence par cas d’usage

Modèles concrets : banque hybride, fraude temps réel, industrie edge, lakehouse BI et RAG privé.

PatternsBankingIoTFraudRAG

9.2

Automation, CI/CD & Infrastructure as Code

Industrialiser provisioning, configuration, pipelines et contrôles avec APIs, CLI, Git, tests et change management.

APICLIGitOpsCI/CD

10.1

Compétences, entretien & questions techniques

Synthèse pour expliquer Cloudera de manière crédible : concepts à maîtriser, questions d’architecture et réponses attendues.

InterviewArchitectureSkillsQuestions

10.2

Cheat-sheet & glossaire

Commandes, acronymes, arbre de décision et ressources officielles à garder sous la main.

Cheat-sheetCommandsGlossaryLinks

1.1 Vue d'ensemble Cloudera

Vue d'ensemble Cloudera — vision pratique

Cloudera fournit une plateforme de données et d’IA destinée aux environnements d’entreprise où les données peuvent rester dans plusieurs clouds, dans des centres de données privés ou à la périphérie. L’enjeu n’est plus seulement Hadoop : le cœur actuel combine lakehouse ouvert, services de données cloud-native, streaming temps réel, gouvernance unifiée et IA d’entreprise.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Sources de données
│
├── Bases / ERP / SaaS / fichiers
├── IoT / edge / logs / événements
├── Applications métier
└── Data lakes historiques
        │
        ▼
Cloudera Data & AI Platform
│
├── Data in Motion : NiFi / Kafka / Flink
├── Open Data Lakehouse : Apache Iceberg
├── Data Engineering : Spark / Airflow
├── Data Warehouse : Hive / Impala / Trino selon contexte
├── Operational DB : HBase / Phoenix / Solr
├── Cloudera AI : Workbench / Inference / Studios / Assistants
└── Unified Data Fabric : SDX / catalog / lineage / observability
        │
        ▼
Analytics • BI • Apps temps réel • ML • GenAI • Agents

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Sources de données
│
├── Bases / ERP / SaaS / fichiers
├── IoT / edge / logs / événements
├── Applications métier
└── Data lakes historiques
        │
        ▼
Cloudera Data & AI Platform
│
├── Data in Motion : NiFi / Kafka / Flink
├── Open Data Lakehouse : Apache Iceberg
├── Data Engineering : Spark / Airflow
├── Data Warehouse : Hive / Impala / Trino selon contexte
├── Operational DB : HBase / Phoenix / Solr
├── Cloudera AI : Workbench / Inference / Studios / Assistants
└── Unified Data Fabric : SDX / catalog / lineage / observability
        │
        ▼
Analytics • BI • Apps temps réel • ML • GenAI • Agents

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Cloudera Anywhere Cloud™	Nouvelle plateforme hybride modulaire annoncée en août 2026.	Déployer et gouverner des services data/AI sur cloud public, cloud souverain et on-prem.
Cloudera Platform	Socle de plateforme data & AI.	Fournir une expérience cohérente sur les données où qu’elles résident.
Open Data Lakehouse	Lakehouse ouvert basé sur Apache Iceberg.	Séparer stockage et compute, conserver l’interopérabilité.
Data in Motion	NiFi, MiNiFi, Kafka et Flink.	Ingestion, transport, traitement et analyse temps réel.
Enterprise AI	Cloudera AI, AI Inference, AI Studios, AI Assistants, AI Workbench.	Développer et industrialiser des workloads IA privés et gouvernés.
Unified Data Fabric / SDX	Sécurité, métadonnées, catalogue, lineage, observabilité.	Appliquer des politiques communes sur plusieurs moteurs et environnements.
Object Store	Stockage objet S3-compatible basé sur Apache Ozone.	Moderniser le stockage on-prem et réduire la dépendance à HDFS.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Identifier où résident réellement les données et les contraintes de souveraineté.
Séparer le plan de contrôle, les services de calcul et les couches de stockage.
Choisir les moteurs par workload : Spark pour pipelines, SQL engines pour BI, Kafka/Flink pour streaming, HBase pour accès opérationnel.
Appliquer la gouvernance avant d’ouvrir le self-service aux équipes.
Mesurer coûts, débit, latence et capacité par workload plutôt qu’au niveau global seulement.
Maintenir une stratégie hybride explicite : ce qui reste on-prem, ce qui peut aller dans le cloud, ce qui doit rester proche de l’edge.

Checklist d’exploitation :
Owner connu • SLO défini • alertes actionnables • sauvegarde/rollback • procédure de changement • capacité surveillée • sécurité testée • logs centralisés.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Carte mentale à retenir

DATA ANYWHERE -> gouvernance commune -> moteurs adaptés -> analytics/AI

Ne pas raisonner : "un cluster = une plateforme".
Raisonner : "un ensemble de services gouvernés sur des données distribuées".

Questions de cadrage

1. Où sont les données sensibles ?
2. Quels SLA de latence et de fraîcheur ?
3. Batch, SQL interactif, streaming ou serving temps réel ?
4. Quel moteur doit accéder aux mêmes tables Iceberg ?
5. Quelles politiques Ranger / IAM / masking ?
6. Quel besoin de lineage et d’audit ?
7. Quels workloads IA doivent rester privés ?

Attention : les commandes exactes doivent être validées contre la documentation de la version installée. Ne jamais copier une commande destructive d’un environnement vers un autre sans prechecks.

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Réduire Cloudera à Hadoop	La plateforme actuelle dépasse largement HDFS/MapReduce.	Présenter Hadoop comme héritage technique, pas comme définition du produit.
Mettre toutes les données au même endroit	Peut violer souveraineté, coût ou latence.	Privilégier une architecture hybride et des politiques unifiées.
Choisir un moteur unique	Spark, SQL, Kafka/Flink, HBase répondent à des besoins différents.	Choisir par workload et SLO.
Oublier la gouvernance	Le self-service devient rapidement incontrôlable.	SDX/Ranger/catalog/lineage dès la conception.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Contexte	Orientation
Data lake historique on-prem	Moderniser progressivement avec Iceberg + Ozone, sans migration big-bang.
Analytics cloud élastique	Data Services / Data Warehouse / Data Engineering sur cloud.
Données réglementées	Compute au plus près des données + gouvernance centralisée.
IA privée / souveraine	Cloudera AI + Inference sur l’environnement autorisé.
Temps réel / edge	Data Flow + Streaming + Edge Management.

Ressources officielles

Ressource	Lien	Utilité
Produits	cloudera.com/products	Cartographie actuelle de la plateforme.
Documentation	docs.cloudera.com	Portail officiel de documentation.
Anywhere Cloud	Annonce 19/08/2026	Positionnement de la nouvelle plateforme hybride.

Version du guide : contenu aligné sur la nomenclature publique Cloudera disponible au 27 août 2026. Pour une mise en œuvre, la matrice de support et les release notes de la version installée priment toujours.

1.2 Évolution : Hadoop → CDH → plateforme hybride

Évolution : Hadoop → CDH → plateforme hybride — vision pratique

La difficulté avec Cloudera vient du vocabulaire accumulé sur quinze ans. Des environnements de production utilisent encore des termes comme CDH, Hadoop, HDFS, Hive ou Impala, alors que la communication actuelle parle de Cloudera Platform, Cloudera on cloud/on premises et Anywhere Cloud. Un bon architecte doit être capable de relier ces générations sans les confondre.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

2010s
CDH / Hadoop Distribution
HDFS • YARN • Hive • Impala • HBase • Spark
        │
        ├── Fusion Cloudera + Hortonworks
        │   héritage HDP / Ranger / Atlas / NiFi
        ▼
CDP / Cloudera Data Platform
Public Cloud + Private Cloud
SDX • Data Services • Cloudera Manager
        │
        ▼
2024-2026
Lakehouse ouvert • Iceberg • Ozone • AI • Streaming
        │
        ▼
Août 2026
Cloudera Anywhere Cloud™
plateforme hybride modulaire pour data + AI

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

2010s
CDH / Hadoop Distribution
HDFS • YARN • Hive • Impala • HBase • Spark
        │
        ├── Fusion Cloudera + Hortonworks
        │   héritage HDP / Ranger / Atlas / NiFi
        ▼
CDP / Cloudera Data Platform
Public Cloud + Private Cloud
SDX • Data Services • Cloudera Manager
        │
        ▼
2024-2026
Lakehouse ouvert • Iceberg • Ozone • AI • Streaming
        │
        ▼
Août 2026
Cloudera Anywhere Cloud™
plateforme hybride modulaire pour data + AI

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
CDH	Ancienne distribution Cloudera Hadoop.	Toujours visible dans de nombreux historiques d’exploitation.
HDP	Ancienne distribution Hortonworks.	A apporté notamment une forte culture open source, Ranger, Atlas, NiFi.
Cloudera Runtime	Ensemble de services data open source intégrés et supportés.	Socle des services on-prem et de plusieurs data services.
Cloudera Base on premises	Socle cluster installé sur VM/bare metal.	Services de base, stockage, SDX Data Lake, Runtime, Cloudera Manager.
Cloudera Data Services on premises	Services conteneurisés au-dessus de Base.	Data Engineering, Data Warehouse, Cloudera AI.
Cloudera on cloud	Expérience Cloudera sur AWS/Azure/GCP.	Services data élastiques dans le compte cloud du client.
Anywhere Cloud	Nouvelle direction 2026.	Même expérience cloud sur infrastructures publiques, souveraines et privées.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Lors d’un audit, inventorier d’abord les versions réelles plutôt que de se fier au nom marketing utilisé par l’équipe.
Cartographier les dépendances historiques : HDFS paths, Hive Metastore, Ranger policies, Kerberos, scripts Oozie/Airflow, jobs Spark, clients Impala.
Repérer les workloads qui peuvent être modernisés indépendamment du stockage.
Conserver une matrice de compatibilité par version : Runtime, Cloudera Manager, OS, JDK, services.
Traiter la migration vers Iceberg/Ozone comme une modernisation incrémentale.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Traduction du vocabulaire

Ancien vocabulaire -> lecture moderne
CDH cluster            -> Cloudera Base / Runtime on premises
HDFS data lake          -> HDFS ou Ozone + tables ouvertes
Hive tables             -> Hive Metastore / Iceberg selon modernisation
Cloudera Manager        -> toujours central pour Base on premises
CDP Private Cloud       -> documentation récente : Cloudera on premises / Data Services on premises

Inventaire de migration

cluster_name
manager_version
runtime_version
os_version
jdk_version
kerberos_enabled
tls_enabled
storage = HDFS | Ozone | object store
services = Hive, Impala, HBase, Spark, Kafka, NiFi...
security = Ranger, Atlas, KMS
workloads = batch, BI, streaming, serving, ML

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Appliquer un tutoriel CDH ancien à un environnement récent	Commandes et interfaces peuvent avoir évolué.	Toujours vérifier la version de documentation.
Croire que CDP a disparu techniquement	Le terme demeure dans URLs, CLI, docs et composants historiques.	Distinguer branding actuel et APIs/produits hérités.
Faire une migration big-bang	Risque opérationnel énorme.	Découper stockage, metadata, compute, sécurité et workloads.
Supprimer HDFS trop tôt	Certains workloads peuvent encore en dépendre.	Moderniser par domaine et valider les performances.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Question	Décision pratique
Le cluster est stable et supporté ?	Éviter une migration uniquement cosmétique.
Le stockage HDFS souffre des petits fichiers / densité ?	Étudier Ozone.
Plusieurs moteurs doivent partager les mêmes tables ?	Prioriser Iceberg.
Besoin d’élasticité cloud-native on-prem ?	Étudier Data Services on premises.
Besoin multi-cloud/souverain nouvelle génération ?	Évaluer Anywhere Cloud selon disponibilité/roadmap contractuelle.

Ressources officielles

Ressource	Lien	Utilité
Docs on premises	Documentation actuelle	Releases et guides Base/Data Services.
Produits	Product map	Noms de produits actuels.

2.1 Architecture globale & plans de contrôle

Architecture globale & plans de contrôle — vision pratique

Une architecture Cloudera moderne doit être lue en couches. Le stockage et les métadonnées ont un cycle de vie différent des moteurs de calcul. Les services conteneurisés peuvent être créés, dimensionnés et supprimés sans remettre en cause le Data Lake. La gouvernance traverse toutes les couches.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

UTILISATEURS / API / BI / IDE / APPLICATIONS
                │
                ▼
MANAGEMENT & CONTROL
Management Console • Cloudera Manager • APIs • Observability
                │
      ┌─────────┴─────────┐
      ▼                   ▼
DATA SERVICES         DATA IN MOTION
Spark/Airflow         NiFi/Kafka/Flink
DW/SQL                Edge
AI/Inference
      │                   │
      └─────────┬─────────┘
                ▼
UNIFIED GOVERNANCE / SDX
Ranger • Atlas • Catalog • Lineage • IAM • Audit
                │
                ▼
METADATA + STORAGE
Hive Metastore • Iceberg catalogs • HDFS/Ozone/S3/ADLS/GCS

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

UTILISATEURS / API / BI / IDE / APPLICATIONS
                │
                ▼
MANAGEMENT & CONTROL
Management Console • Cloudera Manager • APIs • Observability
                │
      ┌─────────┴─────────┐
      ▼                   ▼
DATA SERVICES         DATA IN MOTION
Spark/Airflow         NiFi/Kafka/Flink
DW/SQL                Edge
AI/Inference
      │                   │
      └─────────┬─────────┘
                ▼
UNIFIED GOVERNANCE / SDX
Ranger • Atlas • Catalog • Lineage • IAM • Audit
                │
                ▼
METADATA + STORAGE
Hive Metastore • Iceberg catalogs • HDFS/Ozone/S3/ADLS/GCS

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Management plane	Provisioning, configuration, health, policies, API.	Cloudera Manager on Base; Management Console pour Data Services.
Environment	Contexte d’infrastructure, identité et réseau.	Unité logique de déploiement cloud/on-prem data services.
Data Lake / SDX	Sécurité, metadata, gouvernance partagées.	Évite de recréer ces fonctions pour chaque workload.
Compute services	Spark, SQL, AI, streaming.	Peuvent évoluer séparément du stockage.
Storage	HDFS, Ozone, S3, ADLS, GCS selon contexte.	Données persistantes, indépendantes du compute autant que possible.
Catalog / metadata	HMS, Iceberg, Data Catalog, lineage.	Contrat commun entre moteurs.
Network	DNS, TLS, routes, ingress/egress, private endpoints.	Conditionne sécurité et latence.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Dessiner systématiquement les flux réseau entre utilisateurs, control plane, compute, Data Lake et stockage.
Définir les boundaries de responsabilité : plateforme, data engineering, sécurité, réseau, cloud.
Éviter de coupler la durée de vie des clusters compute à celle des données.
Mettre les politiques d’accès au niveau des données, pas seulement au niveau réseau.
Documenter les endpoints et certificats utilisés par BI, JDBC/ODBC, Kafka, NiFi, API et AI.
Prévoir la collecte de logs/audits avant la mise en production.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Architecture on-premises de référence

Cloudera Base on premises
├── Cloudera Manager + agents
├── SDX Data Lake
│   ├── Ranger
│   ├── Atlas
│   └── Hive Metastore
├── HDFS / Ozone
└── Runtime services

Container platform
├── OpenShift OR Embedded Container Service
└── Data Services
    ├── Data Engineering
    ├── Data Warehouse
    └── Cloudera AI

Architecture cloud logique

Customer cloud account
├── VPC/VNet + subnets
├── object storage
├── identity / keys / security groups
├── Cloudera environment + Data Lake
└── elastic data services

Management/API plane -> provisions and governs workloads
Data remains in customer-controlled cloud resources

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Confondre control plane et data plane	Peut conduire à des règles réseau incorrectes.	Documenter chaque flux et chaque trust boundary.
Coupler stockage et compute	Augmente coût et complexité des upgrades.	Favoriser object storage / table formats ouverts.
Ignorer DNS/TLS	Nombreuses pannes “application” sont réseau/certificat.	Runbook DNS, NTP, PKI et endpoints.
Sous-estimer les métadonnées	Une table sans catalog/lineage/policies devient difficile à partager.	Traiter metadata comme un produit critique.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Décision	Principe
Séparer les workloads	Oui : isolation, coût, SLO et upgrades plus simples.
Partager les données	Oui via stockage/table format/catalog gouverné, pas via copies incontrôlées.
Centraliser toute la plateforme	Non nécessaire : centraliser gouvernance, standards et observabilité.
Multi-cloud	À justifier par souveraineté, résilience ou stratégie, pas par principe.

Ressources officielles

Ressource	Lien	Utilité
Architecture on premises	High-level architecture	Environment, Data Lake, Management Console et Data Services.
Cloudera Manager	Cloudera Manager	Gestion de Base on premises.

2.2 Déploiements : cloud, on-premises, hybride

Déploiements : cloud, on-premises, hybride — vision pratique

Cloudera est conçu pour exécuter des workloads là où les contraintes techniques, économiques et réglementaires l’exigent. Le choix du déploiement doit donc être fondé sur la localisation des données, les compétences d’exploitation, le modèle de coût, les SLA et la souveraineté.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

CHOIX DU LIEU D’EXÉCUTION
│
├── Public cloud
│   ├── AWS
│   ├── Azure
│   └── Google Cloud
│
├── On premises
│   ├── Base sur VM / bare metal
│   └── Data Services sur OpenShift ou ECS
│
├── Hybrid
│   ├── données on-prem + compute autorisé cloud
│   ├── réplication contrôlée
│   └── politiques communes
│
└── Sovereign / Anywhere Cloud
    └── cloud-like experience avec contrôle local

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

CHOIX DU LIEU D’EXÉCUTION
│
├── Public cloud
│   ├── AWS
│   ├── Azure
│   └── Google Cloud
│
├── On premises
│   ├── Base sur VM / bare metal
│   └── Data Services sur OpenShift ou ECS
│
├── Hybrid
│   ├── données on-prem + compute autorisé cloud
│   ├── réplication contrôlée
│   └── politiques communes
│
└── Sovereign / Anywhere Cloud
    └── cloud-like experience avec contrôle local

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Cloudera on cloud	Services dans le cloud public.	Élasticité et provisioning rapide.
Base on premises	Cluster traditionnel géré par Cloudera Manager.	Contrôle maximal, VM/bare metal.
Data Services on premises	Services conteneurisés au-dessus de Base.	Expérience plus cloud-native dans le datacenter.
OpenShift	Plateforme Kubernetes supportée pour Data Services on premises.	Intégration avec standards Kubernetes entreprise.
Embedded Container Service	Alternative Cloudera pour la couche containers.	Réduit la dépendance à un OpenShift séparé.
Replication Manager	Mouvement contrôlé de données entre environnements supportés.	Migration et DR.
Anywhere Cloud	Nouvelle plateforme hybride modulaire.	Placement du workload selon coût, souveraineté et politique.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Valider matrice OS/JDK/Kubernetes/support avant toute installation.
Dimensionner séparément stockage persistant, compute data services et services de management.
Réserver des réseaux et DNS stables ; ne pas improviser les noms après installation.
Vérifier MTU, NTP, proxies, firewalls, ingress, certificates et accès aux repositories.
Définir des classes de nœuds par rôle et des marges de capacité.
Préparer une stratégie de sauvegarde des métadonnées et configurations avant les premiers workloads.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Checklist de prérequis on-prem

[ ] VM/bare metal supportés
[ ] DNS direct + reverse cohérents
[ ] NTP synchronisé
[ ] comptes OS et sudo contrôlés
[ ] stockage et volumes dédiés
[ ] réseau inter-nœuds testé
[ ] certificats / PKI disponibles
[ ] Kerberos/LDAP planifiés si requis
[ ] OpenShift ou ECS dimensionné pour Data Services
[ ] capacité réservée pour monitoring / logs

Checklist cloud

[ ] compte/subscription/project dédié
[ ] VPC/VNet et subnets privés
[ ] IAM roles / service principals
[ ] object storage + encryption keys
[ ] DNS / private endpoints
[ ] egress contrôlé
[ ] quotas compute/GPU vérifiés
[ ] tagging + budgets + chargeback
[ ] logs/audit vers SIEM
[ ] DR multi-AZ selon SLA

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Sous-dimensionner le management	Les services de monitoring et metadata deviennent le goulet.	Dimensionner séparément et surveiller la rétention.
Utiliser le même subnet pour tout	Réduit isolation et contrôle.	Segmenter selon architecture et policies.
Oublier les quotas cloud	Provisioning échoue au pire moment.	Pré-vérifier quotas CPU, GPU, IP, volumes.
Kubernetes sans équipe plateforme	Complexité opérationnelle cachée.	Choisir ECS/OpenShift selon compétences et contrat.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Contrainte	Déploiement favorisé
Données très réglementées / latence locale	On premises / souverain.
Variabilité forte du compute	Cloud ou data services élastiques.
Investissement datacenter existant	Base + Data Services on premises.
Équipes multi-cloud	Standardiser gouvernance et automatisation avant de multiplier les environnements.

Ressources officielles

Ressource	Lien	Utilité
On premises overview	Data Services on premises	Architecture et services supportés.
Cloudera on cloud	Cloud documentation	Guides cloud et services.

3.1 Open Data Lakehouse & Apache Iceberg

Open Data Lakehouse & Apache Iceberg — vision pratique

Le lakehouse ouvert est aujourd’hui un axe central de Cloudera. Apache Iceberg fournit un format de table ouvert au-dessus du stockage objet ou distribué, avec métadonnées, snapshots, évolution de schéma et de partition, tout en permettant à plusieurs moteurs de travailler sur les mêmes données.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Object storage / Ozone / S3 / ADLS / GCS
        │
        ├── data files (Parquet / ORC selon moteur)
        └── Iceberg metadata
            ├── snapshots
            ├── manifests
            ├── schema evolution
            └── partition specs
                  │
                  ▼
            Iceberg Catalog
          HMS / REST Catalog
                  │
      ┌───────────┼───────────┐
      ▼           ▼           ▼
    Spark       Trino       Flink
      │           │           │
      └────── Impala / autres moteurs compatibles

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Object storage / Ozone / S3 / ADLS / GCS
        │
        ├── data files (Parquet / ORC selon moteur)
        └── Iceberg metadata
            ├── snapshots
            ├── manifests
            ├── schema evolution
            └── partition specs
                  │
                  ▼
            Iceberg Catalog
          HMS / REST Catalog
                  │
      ┌───────────┼───────────┐
      ▼           ▼           ▼
    Spark       Trino       Flink
      │           │           │
      └────── Impala / autres moteurs compatibles

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Iceberg table	Table logique avec metadata versionnées.	Évite de gérer les fichiers comme simple dossier.
Snapshot	État atomique d’une table.	Time travel, rollback, audit technique.
Manifest	Index des data files et statistiques.	Pruning et planification de lecture.
Schema evolution	Ajout/renommage/changement contrôlé de colonnes.	Évoluer sans réécrire systématiquement toutes les données.
Partition evolution	Changer la stratégie de partitionnement.	Réduire les migrations de données.
REST Catalog	Interface standard de catalogage Iceberg.	Interopérabilité avec moteurs externes.
Compaction / maintenance	Réécriture de petits fichiers et metadata.	Maintenir les performances sur la durée.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Définir une convention de namespaces, propriétés, ownership et classification.
Contrôler la taille moyenne des fichiers ; le streaming peut générer trop de petits fichiers.
Planifier expiration de snapshots et maintenance de metadata selon politique de rétention.
Tester le comportement de chaque moteur sur les mêmes tables avant certification.
Gouverner les opérations DDL et les évolutions de schéma.
Surveiller la croissance du nombre de manifests et les temps de planification de requête.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

SQL conceptuel Iceberg

-- Syntaxe exacte à adapter au moteur (Spark/Impala/Trino)
CREATE TABLE analytics.sales (
  sale_id BIGINT,
  ts TIMESTAMP,
  customer_id BIGINT,
  amount DECIMAL(18,2)
)
USING iceberg;

-- Exemple de time travel : la syntaxe varie selon le moteur
SELECT * FROM analytics.sales /* AS OF snapshot/timestamp */;

Pipeline lakehouse

Kafka/NiFi -> Flink/Spark -> Iceberg bronze
                          │
                          ├-> quality + dedup
                          ▼
                       Iceberg silver
                          │
                          ├-> business transforms
                          ▼
                       Iceberg gold
                          │
              ┌───────────┼───────────┐
              ▼           ▼           ▼
             BI          AI          APIs

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Traiter Iceberg comme un dossier Parquet	Perte des garanties transactionnelles.	Toujours passer par un moteur/catalog compatible.
Ignorer petits fichiers	Dégradation du planning et des scans.	Compaction et tuning des writers.
Conserver tous les snapshots indéfiniment	Metadata et stockage augmentent.	Politique de rétention documentée.
Mélanger writes non compatibles	Risque d’incohérence.	Certifier les writers et versions.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Besoin	Iceberg apporte
Plusieurs moteurs sur mêmes données	Interopérabilité et metadata communes.
Rollback / audit	Snapshots et time travel.
Schémas évolutifs	Schema evolution.
Migration progressive	Coexistence possible avec formats/tables hérités.
Streaming + batch	Même table cible avec discipline de maintenance.

Ressources officielles

Ressource	Lien	Utilité
Open Data Lakehouse	Open Data Lakehouse	Positionnement Iceberg et interopérabilité.
Apache Iceberg	iceberg.apache.org	Spécification et documentation upstream.

3.2 Data Engineering : Spark, Airflow, CDC

Data Engineering : Spark, Airflow, CDC — vision pratique

Cloudera Data Engineering vise l’industrialisation des pipelines : Spark conteneurisé sur Iceberg, orchestration Airflow, sessions interactives, connectivité IDE, observabilité au niveau workload et capacités CDC. Le modèle cible sépare développement, orchestration, exécution et données persistantes.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Git / IDE / Notebook
      │
      ├── Interactive Session / Spark Connect
      │
      ▼
Airflow DAG / Orchestrator
      │
      ├── validation
      ├── dependencies
      ├── retries / SLA
      ▼
Spark workload
      │
      ├── read source / CDC / stream
      ├── transform / quality
      └── write Iceberg
             │
             ▼
      Catalog + lineage + downstream BI/AI

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Git / IDE / Notebook
      │
      ├── Interactive Session / Spark Connect
      │
      ▼
Airflow DAG / Orchestrator
      │
      ├── validation
      ├── dependencies
      ├── retries / SLA
      ▼
Spark workload
      │
      ├── read source / CDC / stream
      ├── transform / quality
      └── write Iceberg
             │
             ▼
      Catalog + lineage + downstream BI/AI

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Apache Spark	Moteur de traitement distribué.	ETL/ELT, batch, transformations massives.
Apache Airflow	Orchestrateur de workflows.	Dépendances, scheduling, retries, SLA.
Sessions	Environnements interactifs.	Développement et diagnostic rapides.
Spark Connect / IDE	Développement distant sécurisé.	Travailler depuis VS Code/Jupyter selon configuration.
CDC	Capture des changements.	Rafraîchir des tables avec moins de relectures complètes.
Workload observability	Mesures par job/workload.	Coût, performance et capacity planning.
Iceberg	Cible de table ouverte.	Transactions et partage multi-moteurs.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Versionner code, DAGs et configurations ; pas de pipeline “uniquement dans l’UI”.
Établir des contrats de données en entrée/sortie.
Définir retry, timeout, idempotence et stratégie de reprise pour chaque tâche.
Surveiller skew, shuffle, spill, GC, taille des fichiers et durée par stage Spark.
Limiter les collect() et transferts massifs vers le driver.
Mettre des tests de qualité avant promotion bronze→silver→gold.
Séparer credentials des paramètres applicatifs.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

spark-submit de principe

spark-submit \
  --class com.example.Job \
  --conf spark.sql.adaptive.enabled=true \
  --conf spark.executor.instances=8 \
  app.jar --date 2026-08-27

# Dans Data Engineering, privilégier les mécanismes de jobs/sessions
# et les paramètres de runtime supportés par le service.

DAG conceptuel Airflow

extract_cdc
   │
   ▼
validate_schema ──X──> quarantine
   │
   ▼
transform_spark
   │
   ▼
write_iceberg
   │
   ├──> compact_if_needed
   └──> publish_quality_metrics

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Surprovisionner executors	Coût élevé et parfois performance pire.	Mesurer CPU, shuffle, mémoire, parallelism.
Sous-estimer le driver	OOM driver / plan énorme.	Limiter collect, partitions, metadata.
Retries non idempotents	Double écriture ou duplication.	Design idempotent + transactions Iceberg.
Airflow comme moteur de calcul	DAGs trop lourds.	Airflow orchestre ; Spark exécute.
Petits fichiers	Impact SQL et metadata.	Contrôler partitionnement et compaction.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Pattern	Recommandation
ETL massif	Spark batch + Iceberg.
Pipelines complexes multi-étapes	Airflow + jobs Spark.
Développement exploratoire	Sessions interactives, puis promotion en job versionné.
CDC	Incrémental + contrôles de déduplication et ordering.
Très faible latence événementielle	Kafka/Flink plutôt que Spark batch.

Ressources officielles

Ressource	Lien	Utilité
Data Engineering	Cloudera Data Engineering	Fonctionnalités Spark/Iceberg/Airflow.
Docs	Data Engineering docs	Guides de jobs, sessions et administration.

3.3 Data Warehouse & SQL Engines

Data Warehouse & SQL Engines — vision pratique

Cloudera Data Warehouse fournit des workloads SQL isolés et élastiques sur les données du lakehouse. Les environnements existants s’appuient fortement sur Hive et Impala ; Cloudera met aussi en avant Trino pour les requêtes fédérées et l’accès multi-systèmes. L’important est de sélectionner l’engine selon le workload et les fonctionnalités attendues.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

BI / JDBC / ODBC / Hue / Beeline / impala-shell / apps
                      │
                      ▼
              Virtual Warehouse
              │             │
              ├── Hive SQL  ├── Impala SQL
              └── Trino / federation selon service
                      │
                      ▼
              Database Catalog
                      │
                      ▼
           Iceberg / Hive tables
                      │
                      ▼
        Object Store / Ozone / cloud storage

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

BI / JDBC / ODBC / Hue / Beeline / impala-shell / apps
                      │
                      ▼
              Virtual Warehouse
              │             │
              ├── Hive SQL  ├── Impala SQL
              └── Trino / federation selon service
                      │
                      ▼
              Database Catalog
                      │
                      ▼
           Iceberg / Hive tables
                      │
                      ▼
        Object Store / Ozone / cloud storage

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Virtual Warehouse	Compute SQL isolé.	Concurrence, scaling, séparation des équipes.
Database Catalog	Point d’accès aux métadonnées du Data Lake.	Expose tables/vues aux warehouses.
Impala	SQL MPP interactif très répandu dans Cloudera.	BI, faible latence analytique.
Hive	SQL/warehouse historique et moteur présent dans Runtime.	ETL SQL et compatibilité écosystème.
Trino	Moteur SQL distribué et fédéré mis en avant actuellement.	Requêtes multi-sources et exploration ad hoc.
JDBC/ODBC	Connectivité standard.	Tableau, outils BI, apps.
Data Visualization	Visualisation intégrée selon déploiement.	Dashboards et exploration.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Séparer les Virtual Warehouses par workload ou groupe quand les SLA divergent.
Configurer limites de concurrence et autoscaling pour éviter le noisy neighbor.
Collecter query profiles, runtime, scan bytes, skew, spills et queue time.
Utiliser partition pruning et statistiques lorsque l’engine le permet.
Réduire SELECT * sur tables larges et historiques.
Certifier les drivers JDBC/ODBC ; ne pas laisser des clients trop anciens.
Surveiller coût par requête/équipe et pas uniquement coût total.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Connexion Impala de principe

# Les paramètres réels se récupèrent dans l’interface du Virtual Warehouse.
impala-shell \
  -i <host>:<port> \
  -d default \
  --ssl \
  [options Kerberos/LDAP selon environnement]

# Toujours utiliser les certificats et paramètres publiés par la plateforme.

Checklist d’analyse d’une requête lente

1. Temps en queue ?
2. Bytes scannés ?
3. Partition pruning effectif ?
4. Fichiers trop petits ?
5. Statistiques obsolètes ?
6. Join skew ?
7. Spill disque ?
8. Concurrence élevée ?
9. Catalog/metadata latency ?
10. Réseau / object store throttling ?

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Un seul warehouse pour tous	Concurrence et priorités impossibles à maîtriser.	Isoler par SLO/équipe/workload.
BI sur tables non gouvernées	Résultats incohérents et fuite possible.	Ranger + catalog + data contracts.
Drivers anciens	Bugs ou fonctionnalités manquantes.	Distribuer versions certifiées.
Tuner uniquement le SQL	Le layout Iceberg et les petits fichiers dominent parfois.	Analyser stockage + metadata + compute.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Workload	Engine/approche
BI interactif sur lakehouse	Impala souvent pertinent dans l’écosystème Cloudera.
ETL SQL / compatibilité Hive	Hive selon service/version.
Federated query multi-sources	Trino.
Transformations complexes massives	Spark/Data Engineering.
Serving milliseconde key/value	HBase, pas un warehouse SQL.

Ressources officielles

Ressource	Lien	Utilité
Data Warehouse	Cloudera Data Warehouse	Positionnement actuel et Trino.
Architecture CDW	Service architecture	Virtual Warehouses, catalogs, clients.

3.4 Operational Database : HBase, Phoenix, Solr

Operational Database : HBase, Phoenix, Solr — vision pratique

Cloudera Operational Database sert les applications nécessitant des lectures/écritures rapides sur de très grands volumes. HBase fournit le moteur wide-column, Phoenix une couche SQL et Solr peut apporter la recherche textuelle intégrée. La conception de la row key et la distribution des régions sont déterminantes.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Applications / APIs
      │
      ├── HBase client
      ├── Phoenix SQL
      └── Search / Solr
             │
             ▼
          HBase
      ┌──────┴──────┐
      ▼             ▼
 HMaster        RegionServers
                    │
                    ▼
             HDFS / storage

Policies / auth / TLS / Ranger selon configuration

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Applications / APIs
      │
      ├── HBase client
      ├── Phoenix SQL
      └── Search / Solr
             │
             ▼
          HBase
      ┌──────┴──────┐
      ▼             ▼
 HMaster        RegionServers
                    │
                    ▼
             HDFS / storage

Policies / auth / TLS / Ranger selon configuration

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
HMaster	Coordination et administration HBase.	Gestion des régions et opérations cluster.
RegionServer	Sert les régions de tables.	Read/write data path.
Row key	Clé de tri et de distribution.	Impact majeur sur hotspot et scan.
Apache Phoenix	SQL sur HBase.	Accès relationnel et JDBC.
Apache Solr	Recherche textuelle intégrée selon solution.	Search rapide sur données opérationnelles.
Snapshots	Sauvegardes point-in-time HBase.	Protection et opérations DR.
Replication	Réplication HBase.	Continuité et DR selon architecture.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Concevoir les row keys pour répartir la charge et supporter les patterns d’accès.
Surveiller region count, compactions, flushes, store files, block cache, GC et latence p95/p99.
Pré-splitter si la charge initiale est prévisible et très élevée.
Planifier snapshots et tests de restore.
Valider la sécurité Phoenix/HBase/Ranger/Kerberos/TLS selon environnement.
Éviter les scans complets non bornés dans une API temps réel.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

HBase shell de diagnostic

hbase shell
status 'detailed'
list
describe 'namespace:table'
count 'namespace:table', INTERVAL => 100000

# Utiliser les outils de support comme HBCK2 uniquement
# selon la procédure Cloudera correspondant à la version.

Design de row key

Mauvais : 2026-08-27T13:00:00Z|device_id
  -> écritures concentrées sur la fin de table

Mieux selon workload : hash(device_id)%N | device_id | reverse_timestamp
  -> répartit les writes, conserve des scans utiles

Le design dépend TOUJOURS des accès réels.

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Row key monotone	Hotspot RegionServer.	Salt/hash/prefix adaptés au pattern.
Trop de petites régions	Overhead Master et compactions.	Dimensionner split policy.
Compactions ignorées	Latence et I/O se dégradent.	Surveillance continue.
HBCK2 utilisé sans procédure	Risque de corruption logique.	Suivre la documentation/support.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Besoin	Operational DB ?
Lookups/updates milliseconde à grande échelle	Oui, HBase est un bon candidat.
BI ad hoc multi-table	Non, préférer Data Warehouse.
Recherche textuelle	HBase + Solr selon architecture.
SQL simple sur HBase	Phoenix.
Transactions relationnelles complexes	Évaluer une base relationnelle dédiée.

Ressources officielles

Ressource	Lien	Utilité
Operational Database	Cloudera Operational Database	HBase, Phoenix, Solr.
Runtime docs	Operational DB docs	Configuration et exploitation.

4.1 Data in Motion : NiFi, Kafka, Flink & Edge

Data in Motion : NiFi, Kafka, Flink & Edge — vision pratique

Data in Motion couvre le trajet des données avant qu’elles ne deviennent un dataset stable : collecte, routage, transformation, buffering, transport résilient, stream processing et edge. Cloudera met explicitement en avant NiFi/MiNiFi, Kafka et Flink comme briques complémentaires.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Edge / Apps / DB CDC / Logs / SaaS
          │
          ├── MiNiFi / agents edge
          ▼
         NiFi / Data Flow
          │  routing • enrichment • backpressure
          ▼
        Kafka clusters
          │  durable event backbone
          ├──────────────┐
          ▼              ▼
        Flink          Consumers
  stateful stream       apps/APIs
    processing
          │
          ▼
       Iceberg / HBase / AI / alerts

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Edge / Apps / DB CDC / Logs / SaaS
          │
          ├── MiNiFi / agents edge
          ▼
         NiFi / Data Flow
          │  routing • enrichment • backpressure
          ▼
        Kafka clusters
          │  durable event backbone
          ├──────────────┐
          ▼              ▼
        Flink          Consumers
  stateful stream       apps/APIs
    processing
          │
          ▼
       Iceberg / HBase / AI / alerts

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
NiFi	Flow-based data integration.	Connecteurs, routing, provenance, backpressure.
MiNiFi	Agent léger edge.	Collecte près des devices/sources.
Kafka	Journal d’événements distribué.	Découplage producteurs/consommateurs et rétention.
Flink	Stream processing stateful.	Fenêtres, joins, event time, faible latence.
Schema Registry	Référentiel versionné de schémas.	Contrats de messages.
Streams Messaging Manager / Surveyor	Observabilité Kafka selon déploiement/version.	Topics, partitions, consumers, infrastructure.
Edge Management	Gestion de collecte à la périphérie.	IoT, sites distants, connectivité intermittente.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

NiFi : définir backpressure, queues, retry, dead-letter et data provenance.
Kafka : mesurer consumer lag, ISR, under-replicated partitions, request latency, disk usage.
Flink : checkpoints, savepoints, state backend, watermarking et restart strategy.
Schema Registry : stratégie de compatibilité et ownership des schémas.
Séparer topics par domaine et politiques de rétention, pas uniquement par application.
Tester les pannes de broker et la reconnexion des producers/consumers.
Limiter les transformations CPU lourdes dans NiFi si un moteur stream est mieux adapté.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Pipeline temps réel

MiNiFi(edge) -> NiFi gateway -> Kafka raw.events
                                 │
                                 ├-> Flink fraud_detection -> Kafka alerts
                                 │
                                 └-> Flink normalize -> Iceberg realtime.events

AI/BI consomment la même donnée gouvernée.

Checklist Kafka

[ ] replication factor adapté
[ ] min.insync.replicas cohérent
[ ] acks producers définis
[ ] idempotence si nécessaire
[ ] retention.ms / retention.bytes
[ ] partition count justifié
[ ] consumer groups observés
[ ] schema compatibility
[ ] TLS/auth/Ranger policies
[ ] capacité disque et réseau

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Kafka comme base de données éternelle	Rétention et coût explosent.	Définir hot stream vs lakehouse durable.
Trop de partitions	Overhead brokers/controller/clients.	Dimensionner par throughput et parallelism.
NiFi sans backpressure	Memory/disk runaway.	Configurer queues et seuils.
Flink sans checkpoints testés	Recovery non garanti.	Tester restauration savepoint/checkpoint.
Schémas non gouvernés	Consumers cassés.	Schema Registry + compatibilité.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Besoin	Brique
Connecter/routage visuel	NiFi / Data Flow.
Collecte edge	MiNiFi / Edge Management.
Event backbone durable	Kafka.
Calcul stream stateful	Flink.
Historisation analytique	Iceberg.
Serving key/value temps réel	HBase.

Ressources officielles

Ressource	Lien	Utilité
Data in Motion	Data in Motion	NiFi, MiNiFi, Kafka, Flink.
Streaming	Cloudera Streaming	Kafka/Flink et observabilité.

4.2 Cloudera AI, Inference, Studios & Assistants

Cloudera AI, Inference, Studios & Assistants — vision pratique

La couche IA de Cloudera vise à rapprocher les modèles des données gouvernées. Elle couvre le développement collaboratif, les workbenches, le déploiement et l’inférence, ainsi que des accélérateurs et assistants. L’architecture doit préserver la gouvernance des données et des modèles de bout en bout.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Governed enterprise data
Iceberg • HBase • Streaming • external sources
              │
              ▼
          Cloudera AI
    ┌─────────┼─────────┐
    ▼         ▼         ▼
Workbench   Studios    AMPs
notebooks   low/full   accelerators
training    code
    │         │         │
    └─────────┼─────────┘
              ▼
        Model Registry / artifacts
              │
              ▼
       AI Inference Service
       NVIDIA NIM / CPU/GPU
              │
              ▼
Apps • RAG • Agents • Assistants
              │
              ▼
Monitoring • audit • feedback • drift

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Governed enterprise data
Iceberg • HBase • Streaming • external sources
              │
              ▼
          Cloudera AI
    ┌─────────┼─────────┐
    ▼         ▼         ▼
Workbench   Studios    AMPs
notebooks   low/full   accelerators
training    code
    │         │         │
    └─────────┼─────────┘
              ▼
        Model Registry / artifacts
              │
              ▼
       AI Inference Service
       NVIDIA NIM / CPU/GPU
              │
              ▼
Apps • RAG • Agents • Assistants
              │
              ▼
Monitoring • audit • feedback • drift

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Cloudera AI	Plateforme IA/ML d’entreprise.	Recherche → production sur données gouvernées.
AI Workbench	Développement collaboratif.	Notebooks, code, entraînement et déploiement.
AI Inference	Service d’inférence.	Servir modèles/apps sur cloud ou on-prem.
NVIDIA NIM	Microservices intégrés au service d’inférence.	Optimisation du serving de modèles compatibles.
AI Studios	Workflows GenAI/agentic low-code + full-code.	Accélérer cas d’usage privés.
AI Assistants	Assistants sécurisés/traçables.	Accès à des insights gouvernés.
AMPs	Accelerators for ML Projects.	Templates/blueprints de projets ML.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Versionner code, prompts, modèles, datasets et paramètres.
Séparer POC et production : quotas, réseau, secrets, monitoring et SLA distincts.
Pour RAG, tracer source document, chunk, embedding version, retrieval score et réponse finale.
Définir un modèle d’autorisation : qui peut voir quelles données dans le contexte du modèle.
Mesurer latence, throughput, token usage, GPU/CPU, erreurs et saturation.
Mettre canary/blue-green/A-B lorsque supporté et pertinent.
Évaluer drift, qualité métier, safety et feedback utilisateur.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Architecture RAG privée

Documents gouvernés / Iceberg / catalog
        │
        ├── extraction + chunking
        ├── classification / ACL propagation
        └── embeddings
              │
              ▼
         Vector index
              │
question -> auth -> retrieval filtered by ACL
              │
              ▼
        LLM via AI Inference
              │
              ▼
answer + citations + audit + feedback

Checklist production d’un modèle

[ ] modèle et version identifiés
[ ] dataset / lineage identifiés
[ ] endpoint privé/TLS
[ ] authn/authz
[ ] quotas et autoscaling
[ ] latency p95/p99
[ ] throughput cible
[ ] GPU/CPU utilization
[ ] logs sans fuite de données sensibles
[ ] rollback
[ ] monitoring qualité / drift
[ ] coût par requête / token

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
POC notebook = production	Pas de SLA ni reproductibilité.	Pipeline MLOps et serving dédié.
RAG sans ACL	Le modèle peut révéler des documents interdits.	Propager les droits jusqu’au retrieval.
Logs contenant prompts sensibles	Fuite de données.	Redaction et politique de rétention.
GPU sous-utilisés	Coût très élevé.	Batching, autoscaling, modèle adapté.
Pas de rollback	Incident modèle difficile à contenir.	Versioning + stratégie de déploiement.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Question	Approche
Données ne peuvent pas sortir du datacenter	Inference on-prem / souverain.
Pic de trafic imprévisible	Autoscaling cloud si politique autorise.
RAG documentaire	Catalog + ACL + retrieval gouverné.
Agent métier	Outils restreints, audit et contrôle d’actions.
Modèle externe	Évaluer transfert de données, conformité et contrats avant intégration.

Ressources officielles

5.1 SDX, Ranger, Atlas, Catalog & Lineage

SDX, Ranger, Atlas, Catalog & Lineage — vision pratique

Shared Data Experience (SDX) est la couche transversale qui évite que chaque moteur implémente sa propre sécurité et sa propre gouvernance. Ranger applique les politiques d’accès, Atlas fournit classification et lineage dans le socle historique, Data Catalog apporte la découverte, et Cloudera Data Lineage (anciennement Octopai) étend le lineage actif à de nombreux systèmes externes.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Users / groups / roles / attributes
            │
            ▼
      Identity & authentication
            │
            ▼
       Ranger policies
 row/column access • masking • auditing
            │
 ┌──────────┼───────────┬──────────┐
 ▼          ▼           ▼          ▼
Hive/Impala HBase      Kafka      Files/Object
            │
            ▼
Metadata / classification
Atlas • Data Catalog • Data Lineage
            │
            ▼
Discovery • lineage • impact analysis • compliance

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Users / groups / roles / attributes
            │
            ▼
      Identity & authentication
            │
            ▼
       Ranger policies
 row/column access • masking • auditing
            │
 ┌──────────┼───────────┬──────────┐
 ▼          ▼           ▼          ▼
Hive/Impala HBase      Kafka      Files/Object
            │
            ▼
Metadata / classification
Atlas • Data Catalog • Data Lineage
            │
            ▼
Discovery • lineage • impact analysis • compliance

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Apache Ranger	Centralise politiques et audits pour services supportés.	RBAC/ABAC, masking, accès fin.
Apache Atlas	Metadata, classification et lineage.	Traçabilité dans l’écosystème data.
Data Catalog	Découverte et gestion des assets.	Rendre les données compréhensibles et conformes.
Cloudera Data Lineage	Plateforme active metadata, ex-Octopai.	Lineage cross-system, discovery, cataloging.
IAM/LDAP/Kerberos	Authentification et identité selon environnement.	Établir l’identité avant authorization.
KMS / encryption	Gestion des clés et chiffrement selon déploiement.	Protection at rest.
Audit	Traces d’accès, changement de policies et événements.	Compliance et investigation.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Définir taxonomy de classifications : PII, PCI, secret, public, internal.
Créer les policies par groupes/attributs, éviter les permissions utilisateur individuelles.
Tester explicitement les DENY et cas de masking.
Envoyer les audits importants vers une plateforme de sécurité/SIEM.
Réviser les accès périodiquement avec owners de données.
Utiliser lineage pour impact analysis avant changement de schéma.
Versionner les politiques et conserver raison de changement.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Modèle de policy

Dataset : finance.transactions
Classification : PCI + Confidential

Readers:
  group=finance_analysts -> SELECT allowed
  card_number -> MASK except group=pci_privileged

Writers:
  service_account=finance_etl -> INSERT/UPDATE

Admins:
  group=data_platform_admin -> metadata/admin

Audit:
  all denied + privileged reads -> SIEM

Flux lineage

source DB column
   │
   ▼
NiFi processor
   │
   ▼
Kafka topic
   │
   ▼
Spark transformation
   │
   ▼
Iceberg table.column
   │
   ▼
BI dashboard metric

Impact analysis = "si cette colonne change, qui casse ?"

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Policies trop larges	Risque de fuite.	Least privilege + groupes/attributs.
Authentification ≠ autorisation	Un utilisateur connecté n’est pas autorisé partout.	Ranger/IAM policies explicites.
Lineage incomplet	Impossible de faire impact analysis.	Connecter ETL/BI/sources externes à Data Lineage.
Classification manuelle uniquement	Ne tient pas à l’échelle.	Automatiser et valider.
Audit non centralisé	Investigation lente.	Forwarding SIEM + rétention.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Objectif	Brique/approche
Contrôle accès dataset	Ranger/SDX.
Découverte datasets	Data Catalog.
Lineage Cloudera natif	Atlas/SDX.
Lineage cross-system étendu	Cloudera Data Lineage.
Secrets et clés	KMS/secret stores + séparation de responsabilités.

Ressources officielles

5.2 Stockage : Ozone, HDFS & Object Stores

Stockage : Ozone, HDFS & Object Stores — vision pratique

HDFS reste important dans de nombreux clusters historiques, mais Cloudera pousse désormais son Object Store basé sur Apache Ozone pour les environnements on-prem. Ozone fournit une API S3 native et une interface compatible Hadoop, cible des milliards d’objets et réduit l’overhead de stockage via erasure coding.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Legacy analytics
Spark/Hive/Impala -> Hadoop FS API
                         │
                         ▼
                       Ozone
                  ┌──────┴──────┐
                  ▼             ▼
             OFS/Hadoop       S3 Gateway
                  │             │
                  └──────┬──────┘
                         ▼
                 Ozone metadata + data

Cloud-native AI/apps -> S3 API -> same object store

HDFS remains possible for legacy workloads.

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Legacy analytics
Spark/Hive/Impala -> Hadoop FS API
                         │
                         ▼
                       Ozone
                  ┌──────┴──────┐
                  ▼             ▼
             OFS/Hadoop       S3 Gateway
                  │             │
                  └──────┬──────┘
                         ▼
                 Ozone metadata + data

Cloud-native AI/apps -> S3 API -> same object store

HDFS remains possible for legacy workloads.

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
HDFS	Distributed filesystem historique.	Très mature pour Hadoop, contraintes de small files et NameNode metadata.
Apache Ozone	Object store distribué.	S3 + Hadoop APIs, forte scalabilité objets.
S3 Gateway	Expose Ozone via API S3.	Compatibilité apps/AI cloud-native.
OFS	Filesystem interface Ozone.	Compatibilité Hadoop.
Erasure Coding	Réduit overhead vs réplication triple.	Capacité utile supérieure.
Snapshots	Point-in-time au niveau bucket/volume selon fonctions.	Backup/DR/compliance.
Cloud object stores	S3/ADLS/GCS selon cloud.	Stockage durable séparé du compute.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Sur HDFS, surveiller NameNode heap, file count, small files, block reports et capacité DataNodes.
Sur Ozone, surveiller metadata services, pipelines, containers, disks, S3 Gateway et capacity.
Définir classes de buckets et politiques de chiffrement.
Tester l’accès S3 et Hadoop aux mêmes données si le cas d’usage le nécessite.
Éviter de migrer des centaines de millions de petits fichiers sans stratégie de compactage.
Conserver checksum/validation du volume de données lors des migrations.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Ozone shell officiel - exemples

# Créer un volume
ozone sh volume create /vol1

# Créer un bucket
ozone sh bucket create /vol1/bucket1

# Exemple de bucket chiffré (adapter URI/service/key)
ozone sh bucket create -k <ENCRYPTION_KEY> o3://<service>/<volume>/<bucket>

# Lister les buckets
ozone sh bucket list o3://<service>/<volume>

HDFS diagnostics

hdfs dfs -ls /data
hdfs dfs -du -h /data
hdfs dfs -count -q -h /data

# Les commandes et droits exacts dépendent du cluster,
# de Kerberos et des policies Ranger.

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
HDFS small files	Pression NameNode et listing lent.	Compacter en formats colonnes/tables Iceberg.
Migration sans checksum	Impossible de prouver l’intégrité.	Comptages, tailles, checksums et sampling.
S3 API sans gouvernance	Accès direct contourne parfois les habitudes Hadoop.	Aligner IAM/Ranger/KMS et policies.
Erasure coding partout	Peut être moins adapté à certains workloads chauds.	Définir politiques par type de données.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Situation	Orientation
HDFS stable, SLA OK	Pas d’urgence ; moderniser selon bénéfice.
Très grand nombre d’objets / besoin S3	Ozone est un candidat naturel on-prem.
Workloads AI S3-native + analytics Hadoop	Ozone permet double API.
Cloud public	Utiliser le stockage objet natif et table formats ouverts.
Archive froide	Optimiser coût/rétention plutôt que latence.

Ressources officielles

6.1 Cloudera Manager & Management Console

Cloudera Manager & Management Console — vision pratique

Cloudera Manager reste le centre de gravité de l’exploitation de Cloudera Base on premises. Le serveur gère les clusters via des agents installés sur chaque hôte. Les services sont composés de rôles, regroupés dans des role groups. La Management Console prend le relais pour la gestion des Data Services et des environments.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Admin / API / Automation
        │
        ▼
Cloudera Manager Server
        │
        ├── database metadata/config
        ├── management services
        └── Cloudera Manager Agents
              │
      ┌───────┼────────┐
      ▼       ▼        ▼
    Host1   Host2    HostN
    roles   roles    roles

Examples roles:
NameNode • DataNode • Impala Daemon • HBase RegionServer • Kafka Broker ...

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Admin / API / Automation
        │
        ▼
Cloudera Manager Server
        │
        ├── database metadata/config
        ├── management services
        └── Cloudera Manager Agents
              │
      ┌───────┼────────┐
      ▼       ▼        ▼
    Host1   Host2    HostN
    roles   roles    roles

Examples roles:
NameNode • DataNode • Impala Daemon • HBase RegionServer • Kafka Broker ...

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Cloudera Manager Server	Orchestrateur d’administration.	Configuration, start/stop, upgrades, sécurité, API.
Agent	Daemon sur chaque hôte.	Exécute actions et remonte état/métriques.
Service	HDFS, Hive, HBase, Impala, Kafka, etc.	Regroupe un ensemble de rôles.
Role	Fonction d’un daemon sur un hôte.	Ex : NameNode, DataNode, RegionServer.
Role Group	Configuration commune à plusieurs rôles.	Tuning par classe de nœuds.
Management Service	Service Monitor, Host Monitor, Event Server, etc.	Monitoring et historique.
Management Console	Provisioning Data Services/environments.	Administration cloud-native.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Toujours entrer une raison de changement de configuration significative.
Avant restart, vérifier les “stale configurations” et l’impact du rolling restart.
Surveiller les services de monitoring eux-mêmes : heap, disque, rétention.
Créer des role groups pour différencier classes hardware/roles plutôt que des overrides individuels.
Exporter régulièrement configurations et inventaires utiles au DR.
Automatiser via API uniquement après validation manuelle et gestion des erreurs/retries.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

API Cloudera Manager - squelette

# L’API est versionnée. Récupérer la version compatible avec le Manager.
CM=https://cm.example.net:7183
API=vXX

curl -u "$CM_USER:$CM_PASS" \
  "$CM/api/$API/clusters"

# Ne pas coder en dur les secrets dans les scripts.

Diagnostic service

1. Health summary
2. Service instances / roles
3. Recent commands
4. Configuration changes
5. Events / alerts
6. Metrics charts
7. Role logs
8. Host health
9. Dependency services
10. Network / disk / JVM verification

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Overrides individuels partout	Configuration impossible à maintenir.	Role groups cohérents.
Restart global par réflexe	Impact inutile.	Rolling restart quand supporté.
Monitoring Service sous-dimensionné	Historique perdu ou CM lent.	Tuning et rétention.
API sans idempotence	Actions doublées.	Vérifier state avant action.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Tâche	Outil
Configurer Base cluster	Cloudera Manager.
Surveiller hosts/roles	Cloudera Manager + Management Service.
Provisionner Data Services	Management Console.
Automatiser actions CM	Cloudera Manager API.
Audit changement	Historique config + audit + SIEM.

Ressources officielles

6.2 Observabilité, performance & capacité

Observabilité, performance & capacité — vision pratique

Une plateforme Cloudera ne se supervise pas avec un unique indicateur “cluster green”. Il faut relier ressources physiques, santé des services, métriques des workloads et indicateurs métier. Les dashboards doivent aider à répondre à trois questions : que se passe-t-il, qui est impacté, quelle ressource limite le système ?

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

BUSINESS SLO
freshness • query latency • event lag • API latency • model latency
             │
             ▼
WORKLOAD METRICS
Spark jobs • SQL queries • Kafka consumers • Flink jobs • AI endpoints
             │
             ▼
SERVICE HEALTH
HDFS/Ozone • HMS • Ranger • HBase • Impala/Hive • NiFi/Kafka
             │
             ▼
HOST / K8S
CPU • RAM • JVM • disk • network • containers • pods
             │
             ▼
INFRA
cloud quotas • IOPS • object store • DNS • TLS • network

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

BUSINESS SLO
freshness • query latency • event lag • API latency • model latency
             │
             ▼
WORKLOAD METRICS
Spark jobs • SQL queries • Kafka consumers • Flink jobs • AI endpoints
             │
             ▼
SERVICE HEALTH
HDFS/Ozone • HMS • Ranger • HBase • Impala/Hive • NiFi/Kafka
             │
             ▼
HOST / K8S
CPU • RAM • JVM • disk • network • containers • pods
             │
             ▼
INFRA
cloud quotas • IOPS • object store • DNS • TLS • network

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Health tests	Tests intégrés Cloudera Manager.	Détecter conditions warning/bad.
Host Monitor	CPU, mémoire, disques, rôles.	Santé des nœuds.
Service Monitor	Métriques et activités services.	Queries/apps selon service.
Alerts/Event Server	Événements et alertes.	Notification et investigation.
Grafana	Monitoring de Data Services on premises selon architecture.	Visualisation K8s/services.
Workload observability	Mesures par workload.	Performance et chargeback.
FinOps	Coût compute/storage/GPU.	Optimiser placement et autoscaling.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Définir SLO p95/p99 et freshness par produit de données.
Établir baseline en période normale avant de régler des alertes.
Corréler CPU/mémoire avec queues, latence et erreurs.
Surveiller capacité avec projection 30/60/90 jours.
Retenir les métriques assez longtemps pour comparer incidents et tendances.
Éviter les alertes sur chaque métrique : alertes actionnables uniquement.
Ajouter tags owner/environment/workload/cost-center.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Golden signals data platform

LATENCY
  SQL p95/p99, Kafka end-to-end lag, model inference p95

TRAFFIC
  queries/s, rows/s, MB/s, messages/s, tokens/s

ERRORS
  failed jobs, failed queries, producer errors, checkpoint failures

SATURATION
  CPU, memory, disk, IOPS, network, queue, GPU, executor slots

DATA QUALITY
  freshness, completeness, duplicates, schema drift

Capacity review hebdomadaire

- storage used / growth rate
- file/object count growth
- compute peak / average
- queue time by workload
- top 20 expensive queries/jobs
- Kafka partitions and disk trend
- Ozone/HDFS imbalance
- failed/retried Airflow tasks
- GPU utilization and inference throughput
- incidents + recurring warnings

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Green dashboard = no problem	SLO métier peut être rouge.	Ajouter indicateurs workload et métier.
Alert storm	Équipe ignore les alertes.	Prioriser actionnables, corréler.
Pas de baseline	Impossible de savoir ce qui est anormal.	Conserver tendances et percentiles.
Monitoring sans ownership	Personne n’agit.	Owner et runbook par alerte.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Signal	Action
CPU élevé mais latence stable	Peut être acceptable ; surveiller saturation.
Queue time augmente	Capacité/concurrence/workload management.
Disk usage monte vite	Rétention, compaction, capacity expansion.
Kafka lag monte sans CPU	Consumer failure/network/downstream.
AI latency monte avec GPU 100%	Scale/batching/model optimization.

Ressources officielles

7.1 Runbook d’exploitation production

Runbook d’exploitation production — vision pratique

L’exploitation d’une plateforme Cloudera doit être ritualisée. Les opérations les plus risquées — changement de configuration, upgrade, rotation certificats, scaling, DR — doivent être préparées avec critères GO/NO-GO, rollback et preuves de validation.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

DAILY
health • failed jobs • storage • queues • security alerts
  │
WEEKLY
capacity • top workloads • policy changes • backups • cert expiry
  │
MONTHLY
restore test • DR readiness • patch review • cost review
  │
CHANGE WINDOW
prechecks -> backup -> change -> validation -> rollback decision
  │
INCIDENT
triage -> contain -> restore -> RCA -> preventive action

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

DAILY
health • failed jobs • storage • queues • security alerts
  │
WEEKLY
capacity • top workloads • policy changes • backups • cert expiry
  │
MONTHLY
restore test • DR readiness • patch review • cost review
  │
CHANGE WINDOW
prechecks -> backup -> change -> validation -> rollback decision
  │
INCIDENT
triage -> contain -> restore -> RCA -> preventive action

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Daily checks	Santé, échecs, saturation.	Détecter dérive tôt.
Backup	Metadata, configs, data selon service.	Récupération après erreur.
Restore tests	Preuve que la sauvegarde est utilisable.	Éviter “backup vert mais inutilisable”.
DR	RTO/RPO, réplication, procédures.	Continuité après sinistre.
Upgrade	Compatibilité, prechecks, rolling/non-rolling.	Maintien support et sécurité.
PKI	Certificats, truststores, expirations.	Éviter outages TLS.
Change management	Reason, peer review, rollback.	Réduire erreurs humaines.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Chaque changement doit avoir owner, fenêtre, impact, prechecks, rollback et validation.
Tester les backups/restores dans un environnement isolé.
Surveiller expirations certificats à J-90/J-60/J-30.
Avant upgrade : matrice support, release notes, dépendances, clients, custom configs.
Garder snapshots de configuration et inventaire des services.
Après incident : RCA factuel et action préventive mesurable.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

GO/NO-GO upgrade

GO si :
[ ] versions supportées
[ ] backups validés
[ ] espace disque suffisant
[ ] cluster health stable
[ ] dépendances tierces validées
[ ] drivers clients compatibles
[ ] rollback documenté
[ ] fenêtre approuvée

NO-GO si :
[ ] corruption/health critique existante
[ ] backup non vérifié
[ ] capacité insuffisante
[ ] dépendance majeure non certifiée

Incident template

INCIDENT ID:
Start time:
Detection:
Impacted services:
User impact:
Current hypothesis:
Containment:
Evidence collected:
Changes in last 24h:
Recovery action:
Validation:
RCA:
Preventive actions + owner + due date:

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Backup jamais restauré	Fausse sécurité.	Restore test périodique.
Upgrade en cluster déjà dégradé	Risque d’aggravation.	Stabiliser avant changement.
Certificats sans inventaire	Expiration surprise.	PKI inventory + alerting.
RCA = “erreur humaine”	N’apprend rien.	Identifier contrôles/process manquants.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Événement	Réponse
Warning isolé sans impact	Observer + tendance + runbook.
SLO violé	Incident, même si health global vert.
Metadata service critique dégradé	Priorité élevée car blast radius large.
Backup en échec	Traiter comme risque production.
Certificat <30 jours	Change planifié immédiatement.

Ressources officielles

7.2 Dépannage multi-couches

Dépannage multi-couches — vision pratique

Le meilleur diagnostic Cloudera commence par classer la panne : infrastructure, réseau, identité, stockage, metadata, moteur de calcul ou application. Ajouter des réglages au hasard augmente le temps de résolution. Il faut revenir au dernier niveau connu sain et collecter les preuves avant modification.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Symptôme utilisateur
      │
      ▼
1. Scope / blast radius
      │
      ▼
2. Recent changes
      │
      ▼
3. Infrastructure / DNS / TLS / time
      │
      ▼
4. Identity / auth / Ranger
      │
      ▼
5. Storage / catalog / metadata
      │
      ▼
6. Engine / workload
      │
      ▼
7. App/client
      │
      ▼
Evidence -> hypothesis -> reversible test -> fix -> validate

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Symptôme utilisateur
      │
      ▼
1. Scope / blast radius
      │
      ▼
2. Recent changes
      │
      ▼
3. Infrastructure / DNS / TLS / time
      │
      ▼
4. Identity / auth / Ranger
      │
      ▼
5. Storage / catalog / metadata
      │
      ▼
6. Engine / workload
      │
      ▼
7. App/client
      │
      ▼
Evidence -> hypothesis -> reversible test -> fix -> validate

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Scope	Un user, un service, un host, tout cluster ?	Réduit espace de recherche.
Recent changes	Config, deploy, policy, cert, DNS, data volume.	Cause fréquente.
Logs	Service/role/application.	Timeline et erreurs précises.
Metrics	Avant/pendant incident.	Saturation et corrélation.
Configuration	Stale config, overrides, versions.	Drift et incompatibilité.
Network	DNS, route, port, TLS, proxy, NTP.	Pannes transverses.
Data state	Files, metadata, snapshots, offsets.	Comprendre cohérence.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Toujours noter l’heure exacte et timezone de l’incident.
Capturer logs/config/metrics avant restart si possible.
Comparer un nœud sain et un nœud défaillant.
Tester résolution DNS et connectivité depuis le composant réellement concerné.
Vérifier time sync pour Kerberos/TLS.
Ne pas utiliser outils de réparation destructifs sans backup et procédure officielle.
Valider après fix avec le workload réel, pas uniquement service “green”.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Matrice symptômes

403 / access denied -> identity / Ranger / warehouse access
GSS/Kerberos error -> principal / keytab / clock / DNS
SSL handshake -> truststore / cert / hostname / protocol
FileNotFound -> path / object store / catalog / permissions
Query slow -> queue / scan / files / skew / spill / storage
Kafka lag -> consumer / broker / downstream / partitioning
Flink restart loop -> checkpoint/state/schema/connector
HBase latency -> hotspot/compaction/GC/disk
Spark OOM -> driver/executor/partition/skew
AI 5xx -> model endpoint/resources/dependency

Commandes Linux génériques

date -u
host <fqdn>
getent hosts <fqdn>
curl -vk https://<endpoint>/
ss -lntp
df -h
df -i
free -h
vmstat 1 5
iostat -xz 1 5

# Adapter selon droits et politiques de l’entreprise.

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Restart avant collecte	Efface symptômes.	Collecter evidence d’abord.
Changer 5 paramètres ensemble	Impossible d’identifier la cause.	Une hypothèse, un test réversible.
Diagnostiquer uniquement depuis laptop	Le réseau du service peut être différent.	Tester depuis host/pod concerné.
Ignorer NTP	Kerberos et certificats peuvent échouer.	Vérifier time sync.
Fix manuel non documenté	Dette et récidive.	RCA + config as code si possible.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Symptôme	Premier endroit à regarder
Tous les services d’un host down	Host/network/agent.
Plusieurs moteurs ne voient plus tables	Catalog/HMS/storage/SDX.
Un groupe perd accès	Identity/Ranger/group mapping.
Un seul job Spark échoue	Code/data/resources job.
Tous les consumers lag	Kafka brokers/network/downstream.

Ressources officielles

8.1 Migration & modernisation progressive

Migration & modernisation progressive — vision pratique

Une modernisation Cloudera réussie est une suite de migrations vérifiables. Il faut séparer la migration de la plateforme, des données, des métadonnées, des politiques, des pipelines et des consommateurs. Les workloads peuvent être déplacés à des rythmes différents.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

DISCOVER
inventory • dependencies • SLAs • owners
   │
ASSESS
compatibility • target architecture • security
   │
PILOT
one domain / representative workloads
   │
MIGRATE DATA
HDFS -> Ozone/object store ; tables -> Iceberg
   │
MIGRATE COMPUTE
Spark/SQL/streaming/data services
   │
VALIDATE
counts • checksums • query results • performance • policies
   │
CUTOVER
read-only source -> switch -> monitor -> rollback window
   │
DECOMMISSION
only after evidence and retention period

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

DISCOVER
inventory • dependencies • SLAs • owners
   │
ASSESS
compatibility • target architecture • security
   │
PILOT
one domain / representative workloads
   │
MIGRATE DATA
HDFS -> Ozone/object store ; tables -> Iceberg
   │
MIGRATE COMPUTE
Spark/SQL/streaming/data services
   │
VALIDATE
counts • checksums • query results • performance • policies
   │
CUTOVER
read-only source -> switch -> monitor -> rollback window
   │
DECOMMISSION
only after evidence and retention period

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Inventory	Clusters, versions, services, datasets, jobs, clients.	Base factuelle de migration.
Dependency graph	Qui lit/écrit quoi.	Évite les consommateurs oubliés.
Data migration	HDFS/Ozone/cloud object stores.	Déplacement avec validation.
Table modernization	Hive/Parquet → Iceberg selon use case.	Ouverture et transactions.
Policy migration	Ranger/IAM/KMS.	Conserver sécurité.
Workload migration	Spark, Hive/Impala, Kafka, NiFi, HBase.	Rebuild/tuning sur cible.
Validation	Fonctionnelle, performance, data quality.	Critère de cutover.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Créer une fiche par workload : owner, source, target, RTO/RPO, dépendances, tests.
Établir un jeu de requêtes de référence avant migration.
Comparer row counts, partitions, checksums et business aggregates.
Migrer policies et identities avant l’ouverture aux utilisateurs.
Prévoir dual-run ou shadow queries pour workloads critiques.
Définir rollback tant que la source est conservée.
Décommissionner seulement après une période d’observation et validation métier.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Fiche workload

Name: finance_daily_pnl
Owner: Finance Data
Source engine: Hive/Impala
Source tables: 12
Target: Iceberg + Data Warehouse
Schedule: 05:00 daily
SLA: ready 06:00
RPO: 24h
Security classes: Confidential/PCI
Consumers: Tableau, API pnl-service
Validation: row counts + 8 business totals + 20 SQL queries
Rollback: old warehouse read-only for 14 days

Stratégie HDFS -> Ozone

1. Identify datasets and small-file hotspots
2. Create target volumes/buckets and policies
3. Copy representative partition
4. Validate bytes/counts/checksums
5. Test Spark/Hive/Impala access
6. Performance benchmark
7. Incremental copy
8. Freeze writes
9. Final delta
10. Cutover + monitor

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Migrer sans dependency graph	Consommateurs cachés cassés.	Lineage + logs + interviews owners.
Comparer seulement row count	Peut masquer corruption.	Checksums + agrégats métier.
Reprendre tuning ancien à l’identique	Nouvelle architecture différente.	Rebaseline sur cible.
Décommission rapide	Rollback impossible.	Fenêtre d’observation.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Élément	Ordre conseillé
Identity/policies	Avant exposition des données.
Pilot	Avant migration massive.
Metadata/catalog	Avant consommateurs.
Data copy	Incrémental si volume élevé.
Compute workloads	Par domaine/workload.
Decommission	Dernier, après preuves.

Ressources officielles

8.2 Security Hardening & Zero Trust

Security Hardening & Zero Trust — vision pratique

La sécurité Cloudera doit être pensée en profondeur : identité forte, chiffrement en transit et au repos, segmentation réseau, politiques de données, secrets gérés, audits et processus de changement. Les environnements on-prem historiques utilisent fréquemment Kerberos ; les services cloud ajoutent IAM et identités cloud.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

USER / SERVICE IDENTITY
LDAP / SSO / IAM / Kerberos principals
          │
          ▼
NETWORK TRUST BOUNDARIES
private subnets • firewall • ingress • egress
          │
          ▼
TLS EVERYWHERE
certificates • truststores • rotation
          │
          ▼
AUTHORIZATION
Ranger / IAM / warehouse access / K8s RBAC
          │
          ▼
DATA PROTECTION
KMS • encryption at rest • masking
          │
          ▼
AUDIT / SIEM / DETECTION
access logs • policy changes • admin actions

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

USER / SERVICE IDENTITY
LDAP / SSO / IAM / Kerberos principals
          │
          ▼
NETWORK TRUST BOUNDARIES
private subnets • firewall • ingress • egress
          │
          ▼
TLS EVERYWHERE
certificates • truststores • rotation
          │
          ▼
AUTHORIZATION
Ranger / IAM / warehouse access / K8s RBAC
          │
          ▼
DATA PROTECTION
KMS • encryption at rest • masking
          │
          ▼
AUDIT / SIEM / DETECTION
access logs • policy changes • admin actions

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Kerberos	Authentification forte historique Hadoop/on-prem.	Principals, keytabs, ticket lifecycle.
LDAP/SSO	Groupes et authentification utilisateurs.	Centraliser identité.
Cloud IAM	Roles/service principals/policies.	Accès infra et object storage.
TLS/PKI	Chiffrement en transit.	Certificats et trust chain.
Ranger	Autorisation data.	Policies centralisées.
KMS	Clés de chiffrement.	Encryption zones/buckets selon stockage.
SIEM	Corrélation sécurité.	Audit, alerting et investigation.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Service accounts distincts par application et environnement.
Rotation keytabs/secrets/certificats planifiée et testée.
Interdire secrets dans scripts, DAGs, notebooks et Git.
Limiter egress cloud et accès admin aux endpoints de management.
Appliquer MFA/SSO pour interfaces administratives lorsque disponible.
Tester policies avec utilisateurs positifs et négatifs.
Conserver logs d’administration et changements de politiques.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Checklist hardening

[ ] DNS/NTP fiables
[ ] TLS pour UI/API/services
[ ] certificats inventoriés + alertes expiration
[ ] Kerberos/SSO/IAM selon contexte
[ ] groupes LDAP maîtrisés
[ ] Ranger least privilege
[ ] masking données sensibles
[ ] KMS / encryption at rest
[ ] secrets manager
[ ] admin interfaces réseau privé
[ ] audit vers SIEM
[ ] break-glass account contrôlé
[ ] revue trimestrielle des accès

Modèle service account

service: finance_etl_prod
purpose: write curated finance datasets
identity owner: finance-platform
allowed:
  READ raw.finance.*
  WRITE curated.finance.*
denied:
  admin operations
  unrelated domains
secret/keytab rotation: 60 days
audit: all writes + denials
network: only approved execution subnet

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Compte partagé “hadoop”	Aucune accountability.	Identités nominatives/services distinctes.
TLS partiel	Credentials/metadata exposés.	Chiffrement end-to-end.
Admin UI Internet	Surface d’attaque inutile.	Private access/VPN/bastion.
Secrets dans notebooks	Fuite via Git/logs.	Secret manager + injection runtime.
Policies jamais revues	Privilege creep.	Access reviews périodiques.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Contrôle	Principe
Identity	Centralisée et attribuable.
Network	Deny by default, least connectivity.
Data access	Ranger/IAM par groupes/attributes.
Encryption	At rest + in transit.
Audit	Centralisé et immuable selon politique.
Sovereignty	Placement workload/data conforme avant optimisation coût.

Ressources officielles

9.1 Architectures de référence par cas d’usage

Architectures de référence par cas d’usage — vision pratique

La meilleure façon de comprendre Cloudera est de l’appliquer à des architectures de bout en bout. Les patterns ci-dessous montrent comment combiner ingestion, streaming, lakehouse, serving, gouvernance et IA sans chercher à utiliser tous les composants dans chaque projet.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

PATTERN SELECTION
│
├── Batch lakehouse analytics
│   NiFi/Spark -> Iceberg -> DW -> BI
│
├── Real-time fraud
│   Kafka -> Flink -> alerts + Iceberg -> AI
│
├── Edge / manufacturing
│   MiNiFi -> NiFi -> Kafka -> Flink -> Ozone/Iceberg
│
├── Operational serving
│   stream/batch -> HBase -> API
│
└── Private RAG
    governed docs -> embeddings -> vector index -> AI Inference

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

PATTERN SELECTION
│
├── Batch lakehouse analytics
│   NiFi/Spark -> Iceberg -> DW -> BI
│
├── Real-time fraud
│   Kafka -> Flink -> alerts + Iceberg -> AI
│
├── Edge / manufacturing
│   MiNiFi -> NiFi -> Kafka -> Flink -> Ozone/Iceberg
│
├── Operational serving
│   stream/batch -> HBase -> API
│
└── Private RAG
    governed docs -> embeddings -> vector index -> AI Inference

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Banque hybride	Données sensibles on-prem, BI/AI gouvernés.	SDX, Iceberg, DW, AI selon souveraineté.
Fraude	Décision sous-secondes à secondes.	Kafka/Flink + online features + alerts.
Industrie edge	Sites distants, réseau variable.	MiNiFi/NiFi + Kafka + lakehouse.
Lakehouse BI	Données partagées par plusieurs engines.	Iceberg + Data Warehouse.
Operational API	Lookups rapides.	HBase/Phoenix.
Private RAG	Documents confidentiels et LLM.	Catalog/ACL + AI + Inference.
DR multi-site	Copies contrôlées et metadata/policies.	Replication + restore tests.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Commencer par SLO et contraintes, pas par liste de produits.
Dessiner data flow et trust boundaries.
Définir la source de vérité : event log, table Iceberg, operational DB, etc.
Mettre observabilité et lineage dans le pattern.
Documenter modes dégradés et recovery.
Valider coût et capacité sur un workload représentatif.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Pattern fraude

Card/payment events
      │
      ▼
Kafka secured topics
      │
      ▼
Flink stateful rules + feature computation
      │
      ├── high risk -> alert API
      ├── features -> HBase online store
      └── all events -> Iceberg
                         │
                         ├-> BI/investigation
                         └-> model training in Cloudera AI

Pattern RAG réglementé

Document sources -> NiFi ingestion
       │
       ├-> classification + lineage + Ranger tags
       ▼
Iceberg/Object Store governed zone
       │
       ├-> chunk/embedding pipeline
       ▼
vector index with ACL metadata
       │
user -> SSO -> retrieval filtered by ACL -> AI Inference -> answer + citations
       │
       └-> audit / feedback / monitoring

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Mettre HBase pour tout	Complexité inutile.	Utiliser seulement pour serving temps réel.
Kafka sans lakehouse	Historique analytique devient difficile.	Sink vers Iceberg/Ozone.
RAG sans lineage	Réponses non explicables.	Tracer sources et versions.
Edge sans buffering	Perte en cas de coupure réseau.	Store-and-forward / backpressure.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

SLO	Pattern
<100 ms key/value	HBase serving.
Secondes avec état stream	Kafka + Flink.
Minutes/heures ETL	Spark + Airflow.
SQL BI interactif	Data Warehouse.
IA sur données privées	Cloudera AI/Inference proche des données.

Ressources officielles

9.2 Automation, CI/CD & Infrastructure as Code

Automation, CI/CD & Infrastructure as Code — vision pratique

L’automatisation Cloudera doit rendre les changements reproductibles, audités et réversibles. Le but n’est pas d’automatiser une procédure instable, mais de codifier une procédure déjà validée avec prechecks, contrôles d’état, timeouts, retry et rollback.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

Git repository
├── platform configs
├── Ranger policy definitions
├── Airflow DAGs
├── Spark jobs
├── NiFi flow definitions / parameters
├── deployment manifests
└── tests
      │
      ▼
CI
lint -> unit -> security -> plan -> approval
      │
      ▼
CD / Automation
API / CLI / IaC / Management Console
      │
      ▼
Validation
health -> smoke tests -> SLO -> audit evidence

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

Git repository
├── platform configs
├── Ranger policy definitions
├── Airflow DAGs
├── Spark jobs
├── NiFi flow definitions / parameters
├── deployment manifests
└── tests
      │
      ▼
CI
lint -> unit -> security -> plan -> approval
      │
      ▼
CD / Automation
API / CLI / IaC / Management Console
      │
      ▼
Validation
health -> smoke tests -> SLO -> audit evidence

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Cloudera Manager API	Automatisation Base.	Clusters, services, configs, commands.
CDP/Cloudera CLI	Automatisation de services selon produit.	Provisioning et opérations supportées.
Git	Source de vérité des artefacts automatisables.	Review et historique.
CI	Tests et policy checks.	Prévenir changements invalides.
CD	Déploiement contrôlé.	Promotions dev→test→prod.
Secrets manager	Injection de secrets.	Éviter secrets dans repo.
Drift detection	Comparer desired vs actual.	Détecter changements manuels.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Chaque script doit être idempotent ou vérifier l’état avant action.
Timeout/retry avec backoff sur APIs, jamais boucle infinie.
Enregistrer command IDs et résultats des actions asynchrones.
Séparer variables environnementales du code.
Garder credentials hors Git et logs.
Créer smoke tests post-déploiement.
Exiger approbation pour production et changements de sécurité.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Pseudo-workflow API

desired = load_config_from_git()
actual = query_cloudera_api()
plan = diff(desired, actual)

assert prechecks_ok()
require_approval(plan)

for change in plan:
    apply(change)
    wait_until_terminal_state(timeout=...)

run_smoke_tests()
assert_slo_not_regressed()
store_evidence()

Pipeline de release data job

commit
  -> lint Python/SQL
  -> unit tests
  -> build artifact
  -> scan dependencies
  -> deploy dev
  -> integration tests on sample data
  -> promote staging
  -> data quality + performance baseline
  -> approval
  -> deploy prod
  -> canary / smoke test
  -> monitor

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Automatiser sans prechecks	Panne plus rapide.	Valider conditions avant action.
Secrets dans variables CI visibles	Fuite.	Vault/secret store + masked logs.
Scripts non idempotents	Doubles créations/actions.	State check + unique IDs.
Pas de drift detection	Prod diverge de Git.	Audit régulier.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Type de changement	Automatisation
Répétitif et déterministe	Très bon candidat.
Destructif rare	Automatiser prechecks, garder approval forte.
Diagnostic exploratoire	Conserver humain dans la boucle.
Policy security	Policy-as-code + review + tests.
Provisioning workload	API/CLI/IaC avec quotas et tags.

Ressources officielles

10.1 Compétences, entretien & questions techniques

Compétences, entretien & questions techniques — vision pratique

Maîtriser Cloudera ne consiste pas à réciter une liste de produits. En entretien ou en revue d’architecture, il faut expliquer le parcours d’une donnée, le choix d’un moteur, la gouvernance, la séparation stockage/compute, et la manière d’exploiter la plateforme en production.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

NIVEAU 1 — vocabulaire
HDFS/Ozone • Iceberg • Spark • Hive/Impala/Trino • Kafka/Flink/NiFi
      │
NIVEAU 2 — architecture
Data Lake • Data Services • SDX • control/data plane • hybrid
      │
NIVEAU 3 — operations
Cloudera Manager • capacity • security • upgrades • DR
      │
NIVEAU 4 — design
engine selection • SLO • governance • cost • sovereignty
      │
NIVEAU 5 — modernization
HDFS->Ozone • Hive->Iceberg • batch->streaming • AI/RAG

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

NIVEAU 1 — vocabulaire
HDFS/Ozone • Iceberg • Spark • Hive/Impala/Trino • Kafka/Flink/NiFi
      │
NIVEAU 2 — architecture
Data Lake • Data Services • SDX • control/data plane • hybrid
      │
NIVEAU 3 — operations
Cloudera Manager • capacity • security • upgrades • DR
      │
NIVEAU 4 — design
engine selection • SLO • governance • cost • sovereignty
      │
NIVEAU 5 — modernization
HDFS->Ozone • Hive->Iceberg • batch->streaming • AI/RAG

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
Architecture	Savoir dessiner un flux de bout en bout.	Explique mieux que des slogans.
Storage	HDFS vs Ozone/object store.	Comprendre persistence et small files.
Compute	Spark, SQL, Flink, HBase.	Choisir selon workload.
Governance	Ranger, Atlas, Catalog, Lineage.	Sécurité et conformité.
Operations	Manager, metrics, runbooks, upgrades.	Montrer expérience production.
Hybrid	Cloud/on-prem/souverain.	Placement des workloads.
AI	RAG, Inference, Workbench.	Relier IA et données gouvernées.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Répondre en partant du besoin métier et des SLA.
Donner un exemple de panne et une méthode de diagnostic structurée.
Expliquer les trade-offs, pas seulement les avantages.
Distinguer concepts historiques et produits actuels.
Mentionner que la nomenclature et les fonctionnalités exactes dépendent des versions.
Ne pas prétendre avoir exploité un composant précis si ce n’est pas le cas : parler de transferts de compétences et d’architectures similaires.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

10 questions classiques

1. Quelle différence HDFS / Ozone ?
2. Pourquoi Iceberg dans un lakehouse ?
3. Spark vs Flink ?
4. Kafka vs NiFi ?
5. Impala vs Hive vs Trino ?
6. À quoi sert Ranger ?
7. À quoi sert Atlas / Data Lineage ?
8. Que fait Cloudera Manager ?
9. Comment diagnostiquer une query lente ?
10. Comment migrer un cluster sans big-bang ?

Réponse courte “C’est quoi Cloudera ?”

Cloudera est une plateforme d’entreprise pour gérer le cycle de vie des données et de l’IA sur des environnements hybrides. Elle combine ingestion et streaming, stockage lakehouse ouvert avec Iceberg, data engineering Spark/Airflow, SQL analytics, NoSQL HBase, gouvernance SDX/Ranger/Atlas et une couche AI/MLOps. Son intérêt principal est d’apporter une expérience cohérente et gouvernée sans imposer de déplacer toutes les données dans un cloud unique.

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
“Cloudera = Hadoop”	Réponse datée.	Dire “héritage Hadoop, plateforme moderne data+AI”.
Réciter des acronymes	Ne prouve pas compréhension.	Relier composants à des workloads.
Ignorer exploitation	Architecture non crédible.	Monitoring, security, DR, upgrades.
Survendre expérience	Risque en entretien.	Être précis sur ce qui a été pratiqué vs connu.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Question	Angle de réponse
Pourquoi Cloudera ?	Hybrid + governance + open lakehouse + enterprise operations.
Pourquoi Iceberg ?	Open format, snapshots, evolution, multi-engine.
Pourquoi Ozone ?	S3 + Hadoop APIs, objets à grande échelle, modernisation HDFS.
Pourquoi SDX ?	Policies/metadata partagées.
Pourquoi AI Inference ?	Serving privé/gouverné proche des données.

Ressources officielles

10.2 Cheat-sheet & glossaire

Cheat-sheet & glossaire — vision pratique

Cette dernière section rassemble les repères opérationnels essentiels. Les commandes sont volontairement génériques : les endpoints, options de sécurité et versions doivent toujours être récupérés depuis l’environnement réel et la documentation correspondant à la release.

Point clé : raisonner en cycle de vie de la donnée : ingestion → stockage → traitement → exposition → IA, avec sécurité et gouvernance communes.

Commencer par les workloads et les SLA.
Séparer données persistantes et compute autant que possible.
Éviter le verrouillage technique avec formats/protocoles ouverts lorsque possible.
Traiter sécurité, lineage et observabilité comme des exigences de plateforme.

CHEAT-SHEET
│
├── Storage : hdfs dfs / ozone sh
├── SQL : beeline / impala-shell / JDBC/ODBC
├── HBase : hbase shell
├── Security : kinit / Ranger UI / policy tests
├── Platform : Cloudera Manager / APIs
├── Streaming : Kafka/NiFi/Flink consoles & metrics
└── Troubleshooting : logs + metrics + network + state

Architecture et flux

La carte ci-dessous doit être adaptée au déploiement réel. Les noms de services et fonctions peuvent évoluer selon la version de Cloudera et le mode cloud/on-premises.

CHEAT-SHEET
│
├── Storage : hdfs dfs / ozone sh
├── SQL : beeline / impala-shell / JDBC/ODBC
├── HBase : hbase shell
├── Security : kinit / Ranger UI / policy tests
├── Platform : Cloudera Manager / APIs
├── Streaming : Kafka/NiFi/Flink consoles & metrics
└── Troubleshooting : logs + metrics + network + state

Méthode : pour chaque flèche, documenter protocole, endpoint, identité utilisée, chiffrement, volume, latence attendue et comportement en cas de panne.

Composants et responsabilités

Composant	Rôle	À retenir
SDX	Shared Data Experience.	Sécurité/gouvernance/metadata partagées.
HMS	Hive Metastore.	Métadonnées de tables.
Iceberg	Open table format.	Snapshots et multi-engine.
Ozone	Distributed object store.	S3 + Hadoop APIs.
CDE	Cloudera Data Engineering.	Spark/Airflow.
CDW	Cloudera Data Warehouse.	SQL analytics/virtual warehouses.
CML / Cloudera AI	Ancien/nouveau vocabulaire selon version.	ML/AI development and serving.
CDF / Data Flow	Data flow/streaming.	NiFi et data in motion.
CM	Cloudera Manager.	Administration Base on premises.

Conseil : dans une documentation de production, ajouter pour chaque composant la version, l’owner, le SLA, le mode de backup et le chemin d’escalade.

Exploitation et bonnes pratiques

Toujours vérifier la version de Cloudera Manager et Runtime avant d’utiliser un exemple de commande.
Récupérer les endpoints exacts depuis l’interface du service.
Utiliser kinit/credentials de service correctement, sans secrets en clair.
Tester sur non-production avant commande destructive.
Conserver la sortie des commandes de diagnostic dans le ticket d’incident.

Cadence	Contrôles
À chaque changement	Prechecks, sauvegarde/état, change reason, validation, rollback.
Quotidien	Health, erreurs, queues/lag, capacité, alertes sécurité.
Hebdomadaire	Tendances, top workloads, croissance, changements de policies.
Mensuel	Restore/DR, patch/release review, coûts, revue accès.

Exemples et commandes de référence

Commandes de repère

# HDFS
hdfs dfs -ls /data
hdfs dfs -du -h /data

# Ozone
ozone sh volume list /
ozone sh bucket list /vol1

# Kerberos on-prem lorsque activé
kinit -kt /path/user.keytab user@REALM
klist

# HBase
hbase shell
status 'detailed'

# SQL clients
beeline
impala-shell [options publiées par le Virtual Warehouse]

# Cloudera Manager API
curl -u "$USER:$PASS" "https://<cm>:<port>/api/<version>/clusters"

Arbre de décision moteur

Need visual/routing ingestion? -> NiFi
Need durable event backbone? -> Kafka
Need stateful stream computation? -> Flink
Need large-scale batch ETL? -> Spark
Need interactive SQL/BI? -> Data Warehouse (Impala/Hive/Trino)
Need millisecond wide-column serving? -> HBase
Need open multi-engine tables? -> Iceberg
Need on-prem S3 object storage? -> Ozone
Need governed AI/model serving? -> Cloudera AI / Inference

Pièges fréquents et diagnostic

Piège / symptôme	Pourquoi	Correction
Copier commande d’un blog ancien	Version incompatible.	Utiliser docs de la release.
Commande destructive sans dry-run/backup	Perte de données.	Prechecks + validation + approbation.
Secrets en shell history	Exposition.	Prompt, env sécurisé ou secret store.
Confondre service cloud et Base	Interfaces différentes.	Identifier deployment model d’abord.

Réflexe de diagnostic : scope → changements récents → logs/métriques → infrastructure/réseau → identité/sécurité → stockage/metadata → moteur → application.

Décisions d’architecture & ressources

Règle mémo	Phrase
Architecture	Stockage persistant, compute élastique, gouvernance transversale.
Performance	Mesurer le workload, pas seulement le cluster.
Sécurité	Identity → authorization → encryption → audit.
Migration	Inventorier → piloter → valider → cutover → observer.
Incident	Scope → evidence → hypothesis → reversible test → fix → validate.

Ressources officielles

Ressource	Lien	Utilité
Documentation	docs.cloudera.com	Référence principale.
Product map	Platform & Products	Nomenclature actuelle.
Open Lakehouse	Open Data Lakehouse	Iceberg et interopérabilité.
Data Engineering	Data Engineering	Spark/Airflow.
Data Warehouse	Data Warehouse	SQL engines et BI.
Data in Motion	Data in Motion	NiFi/Kafka/Flink.
Cloudera AI	Cloudera AI	AI/ML.
SDX	SDX	Security/governance.
Object Store	Object Store	Ozone.
Data Lineage	Data Lineage	Cross-system lineage.

Copié dans le presse-papiers

Ressource	Lien	Utilité
Cloudera AI	Cloudera AI	Plateforme IA.
AI Inference	AI Inference Service	Serving modèles et NVIDIA NIM.
Products	AI product map	Studios, Assistants, Workbench, AMPs.

Ressource	Lien	Utilité
SDX	Shared Data Experience	Ranger, Atlas, Catalog.
Data Lineage	Cloudera Data Lineage	Anciennement Octopai.

Ressource	Lien	Utilité
Object Store	Cloudera Object Store	Ozone, S3, HDFS modernization.
Ozone docs	Ozone documentation	Stockage, S3 Gateway, sécurité.

Ressource	Lien	Utilité
Cloudera Manager	Cloudera Manager docs	Concepts et administration.
Monitoring	Monitoring clusters	Health et performance.

Ressource	Lien	Utilité
Monitoring settings	Monitoring settings	Health, alerts, logs et rétention.
Cloudera Observability	Observability	Workload observability.

Ressource	Lien	Utilité
Release notes	Cloudera docs	Release notes par produit/version.
Support	Cloudera Support	Escalade et support.

Ressource	Lien	Utilité
Cloudera docs	Troubleshooting docs	Guides par service/version.
Community	Cloudera Community	Retours d’expérience ; vérifier avec docs/support.

Ressource	Lien	Utilité
Migration docs	Migration documentation	Guides Hive/Impala/HDFS/Ozone selon version.
Object Store	HDFS modernization	Ozone et migration.

Ressource	Lien	Utilité
SDX	SDX security	Ranger/Atlas et politiques.
Trust Center	Trust Center	Informations sécurité et conformité.

Ressource	Lien	Utilité
Solutions	Cloudera Solutions	Cas d’usage sectoriels.
Data in Motion	Streaming patterns	Temps réel et edge.

Ressource	Lien	Utilité
Cloudera Manager API	CM API Explorer	Référence API selon version.
Developer	Cloudera for Developers	Ressources SDK/API.

Ressource	Lien	Utilité
Training	Cloudera Education	Formation et certification.
Docs	Documentation	Préparer questions par produit/version.