Résumé

  • L'argument stratégique de Cloudera n'est pas que les anciens parcs Hadoop doivent rester figés. Il est que les grandes organisations réglementées peuvent moderniser l'analytique et l'IA tout en préservant la politique, les métadonnées, le lignage, l'isolation des charges de travail et la visibilité opérationnelle sur les environnements sur site, cloud privé et cloud public.
  • La preuve la plus solide de cette affirmation est architecturale plutôt qu'anecdotique: Cloudera documente une conception de sécurité et de gouvernance partagée, des clusters Data Hub attachés à des lacs de données gouvernés, des services de données fonctionnant sur site, des chemins Replication Manager pour HDFS, Hive, Ranger, Iceberg et Ozone, et une télémétrie d'observabilité pour les travaux, les requêtes, les clusters et les coûts.
  • Les risques sont tout aussi concrets. Le support Iceberg n'élimine pas le travail de maintenance des tables, certaines fonctionnalités de réplication et de métadonnées restent limitées en version ou en aperçu technique, la tarification de Cloudera exclut les coûts d'infrastructure et de réseau sous-jacents, et les études de cas clients sont organisées par le fournisseur plutôt que basées sur des comparaisons contrôlées.
  • La question d'achat est donc étroite: Cloudera est le plus défendable lorsque la localité des données hybrides, la continuité de la gouvernance et la main-d'œuvre de migration des charges de travail sont plus coûteuses que les coûts de licence, de services, d'infrastructure, de cloud, de mise à niveau et de verrouillage associés au maintien dans sa plateforme.

La vraie question est de savoir si le contrôle hybride réduit la main-d'œuvre

L'activité actuelle de Cloudera doit être jugée par rapport à une question différente de celle qui l'entourait il y a dix ans. La question n'est pas de savoir si Hadoop en tant que marque a survécu à l'entrepôt de données cloud. Il s'agit de savoir si une entreprise aux racines profondes dans l'infrastructure de données distribuées peut rendre l'analytique hybride moins exigeante en main-d'œuvre que les alternatives. Cette distinction est importante car de nombreuses entreprises ne sont pas passées d'une architecture propre à une autre. Elles ont accumulé des clusters HDFS, des conventions de métastore Hive, des travaux Spark, des charges de travail Impala, une ingestion de type Kafka, des exceptions de sécurité, des files d'attente réglées manuellement, des tableaux de bord critiques pour l'activité et des projets d'apprentissage automatique qui dépendent de la localité des données. Le fardeau n'est pas seulement le calcul. C'est la mémoire de qui peut lire une table, quelle transformation a créé un champ, quel compte de service peut écrire une caractéristique de modèle, quel travail est autorisé à éclater et quel cluster doit rester dans la région.

La page de la plateforme de Cloudera elle-même présente le produit autour d'une « expérience cohérente, gouvernance unifiée et contrôle élastique » sur les environnements sur site, cloud public et périphérie, avec l'affirmation supplémentaire que les équipes peuvent utiliser des services, API et interfaces similaires à travers les emplacements (Plateforme de données et d'IA Cloudera). C'est un langage marketing, mais il pointe vers la prémisse technique pertinente. Une plateforme de données hybride n'a de valeur que si elle réduit le nombre de traductions de politique, de métadonnées et de procédures qui se produisent lorsqu'une charge de travail se déplace. Si déplacer un travail Spark vers un cluster cloud signifie réécrire la politique d'accès, reconstruire le lignage, reclassifier les ensembles de données, réajuster chaque requête et découvrir de nouvelles factures de stockage cloud après coup, la plateforme n'a pas résolu le problème de l'acheteur. Elle a vendu une manière gérée de continuer à faire du travail d'intégration.

La gamme de produits actuelle de Cloudera est conçue pour répondre à cette objection. La société se décrit comme un fournisseur de plateforme de données et d'IA qui apporte l'IA aux données « là où elles se trouvent » et revendique une grande échelle sous gestion, y compris plus de 25 exaoctets de données et plus d'un milliard de dollars de revenus récurrents annuels sur sa page à propos (À propos de Cloudera). Ces revendications d'échelle sont fournies par le fournisseur et doivent être traitées comme telles. Les preuves plus importantes se trouvent dans la documentation produit et technique: Shared Data Experience, Data Catalog, Data Hub, Data Engineering, Data Warehouse, Cloudera AI, Replication Manager, Observability et Data Services on premises. Ensemble, elles révèlent une entreprise qui essaie de vendre la continuité entre les environnements comme son unité économique.

Cette continuité est commercialement plausible parce que l'inverse est coûteux. Les alternatives ne sont pas simplement « passer à Snowflake », « passer à Databricks », « utiliser l'open source » ou « rester sur site ». Chaque substitut change le lieu de la main-d'œuvre. Un entrepôt cloud natif réduit la gestion de l'infrastructure mais peut augmenter le travail de sortie, de copie de données, de réimplémentation des politiques et de dépendance à la plateforme. Un lac de données assemblé à partir de projets Apache peut réduire l'exposition aux licences mais transfère les risques de support et d'intégration à l'acheteur. Garder les clusters existants inchangés préserve le comportement connu mais augmente les coûts de cycle de vie, de sécurité, de recrutement et de mise à niveau. Cloudera ne l'emporte que si elle peut conserver une grande partie du parc de données distribué familier tout en rendant la politique, le mouvement, l'observabilité et la modernisation moins artisanaux.

Ce que Cloudera vend maintenant

Cloudera est devenue une société privée en octobre 2021 après une transaction avec Clayton, Dubilier & Rice et KKR valorisée à environ 5,3 milliards de dollars, et ses actions ordinaires ont cessé d'être négociées à la Bourse de New York (Annonce de finalisation de Cloudera). Le dernier instantané financier de l'entreprise publique est donc daté. Au cours de l'exercice 2021, avant la transaction de retrait de la cote, Cloudera a déclaré 869,3 millions de dollars de revenus totaux, 782,8 millions de dollars de revenus d'abonnement et 778 millions de dollars de revenus récurrents annualisés (Résultats de l'exercice 2021). Depuis lors, les lecteurs extérieurs ne peuvent pas utiliser les dépôts publics pour tester la composition des revenus, la rétention, la marge ou les progrès de la transition vers le cloud avec la même précision.

Le produit a également évolué par rapport à l'ancien modèle mental d'une distribution Hadoop avec support. Cloudera Data Hub est documenté comme un service pour lancer et gérer des clusters de charge de travail alimentés par Cloudera Runtime, sa distribution qui combine les lignées CDH et HDP, sur AWS, Microsoft Azure et Google Cloud Platform (Aperçu de Data Hub). Il offre l'isolation des charges de travail, l'automatisation du cycle de vie des clusters, des modèles, la mise à l'échelle et un accès sécurisé via Apache Knox. L'architecture documentée attache ces clusters à un lac de données au sein d'un environnement, de sorte que la sécurité et la gouvernance ne sont pas de simples réflexions après coup par cluster.

Du côté privé, Cloudera Base on premises est décrite comme une base pour des solutions hybrides où le calcul peut être séparé du stockage et les données accessibles à partir de clusters distants, y compris les charges de travail créées à l'aide de Cloudera Data Services on premises (Cloudera Base sur site). Data Services on premises inclut la console de gestion, Data Warehouse, Cloudera AI, Data Catalog, Replication Manager et Data Engineering (Notes de version des Data Services). Le modèle d'installation n'est pas léger. Cloudera documente les exigences en matière de nœuds de travail OpenShift et indique que le nombre de nœuds dépend du nombre d'entrepôts virtuels ou d'espaces de travail d'apprentissage automatique, le dimensionnement de la production étant géré par le support Cloudera ou une équipe de compte (considérations de déploiement).

Cette empreinte de déploiement est au cœur de l'analyse des coûts pour l'acheteur. Cloudera n'est pas un simple point de terminaison SQL hébergé. C'est une plateforme pour les organisations qui doivent encore exploiter une infrastructure de données substantielle, que ce soit dans leurs propres centres de données, un cloud privé ou des comptes cloud publics. La page de tarification publique de Cloudera répertorie les tarifs par unité de calcul Cloudera pour les services cloud, y compris Data Hub, Data Engineering, Data Warehouse, Operational Database, Observability Premium, AI Workbench et AI Inference, mais elle indique également que les prix affichés sont des estimations et n'incluent pas les coûts d'infrastructure, de réseau et autres coûts du fournisseur cloud (Tarification Cloudera). Cette réserve n'est pas mineure. Le plan de contrôle peut être acheté auprès de Cloudera, mais le résultat économique dépend de la localité du stockage, de la combinaison d'instances, de l'utilisation des GPU, des chemins réseau, du plan de support, des services professionnels et de la discipline d'arrêt ou de redimensionnement des charges de travail.

La forme pratique du produit est donc une couche d'exploitation hybride, et non un simple moteur de données. Elle regroupe l'ingestion, l'ingénierie de données orientée Spark et Airflow, l'entreposage SQL, la capacité de base de données opérationnelle, les espaces de travail et l'inférence d'IA, le catalogage, la réplication et l'observabilité. La société appelle le portefeuille « services cloud natifs » pour les étapes allant du streaming à l'IA de production et indique que les charges de travail peuvent passer du cloud public au cloud privé sans réécriture de code (Cloudera Data Services). Cette affirmation doit être lue comme une ambition limitée par les contraintes de version, de connecteur, de sécurité et de performance, mais elle capture pourquoi Cloudera compte toujours. La société vend la continuité de la migration plus qu'elle ne vend un moteur particulier.

La couche de politique est le produit

L'argument technique le plus fort pour Cloudera réside dans Shared Data Experience, ou SDX. La documentation de sécurité de Cloudera décrit SDX comme une architecture de conception incorporée dans ses produits, construite à partir de métadonnées utilisées pour mettre en œuvre des politiques de sécurité. Elle répertorie Ranger, Atlas, Knox, Hive Metastore, Cloudera Data Catalog, Replication Manager et Workload Manager comme faisant partie de la combinaison SDX (Documentation SDX). La phrase clé n'est pas le nom du produit. C'est la promesse d'une politique, d'un schéma et de métadonnées cohérents dans un environnement numérique.

Cette promesse est importante parce que les équipes de données d'entreprise échouent généralement aux coutures. Une équipe peut déplacer des fichiers, mais perdre l'intention de politique qui leur est attachée. Elle peut copier des tables, mais perdre le lignage nécessaire pour savoir si une caractéristique dérivée peut être utilisée dans un modèle réglementé. Elle peut migrer une requête, mais découvrir que les mappages de rôles, la configuration Kerberos, les groupes SAML, les comptes de service ou les contrôles au niveau des colonnes ne sont pas équivalents. Elle peut ajouter un nouveau format de table de lac de données, mais rompre la piste d'audit lorsqu'un moteur tiers lit la table en dehors du chemin attendu. Une plateforme qui préserve la continuité des politiques peut éliminer une véritable main-d'œuvre opérationnelle, mais seulement si les administrateurs lui font suffisamment confiance pour en faire le point de référence pour l'accès.

La page du produit Data Catalog de Cloudera est construite autour de ce même point. Elle indique que le service est destiné à découvrir les données, contrôler les informations sensibles, suivre le lignage, auditer l'accès, classer et profiler les données, et appliquer des contrôles basés sur des politiques dans les environnements cloud et sur site (Cloudera Data Catalog). C'est le bon ensemble de problèmes. Les catalogues qui aident uniquement les utilisateurs à trouver des tables sont utiles, mais ils ne résolvent pas la question commerciale centrale. La prime est justifiée lorsque les métadonnées deviennent une surface de contrôle: qui peut découvrir les données, qui peut les interroger, où elles ont été déplacées, quel moteur les a touchées, quelle étiquette elles portent et quelles obligations les suivent.

La lignée open source sous-jacente est importante. Apache Ranger se décrit comme un cadre pour activer, surveiller et gérer la sécurité des données dans l'écosystème Hadoop, avec une administration centralisée des politiques et une surveillance de l'accès des utilisateurs (Apache Ranger). Apache Atlas se décrit comme un cadre de gestion et de gouvernance des métadonnées pour cataloguer, classer et gouverner les actifs de données (Apache Atlas). Cloudera n'a pas inventé le besoin de politique et de lignage, et ne possède pas les concepts open source en soi. Sa proposition est qu'elle peut assembler, durcir, supporter et étendre ces composants dans un parc d'entreprise désordonné mieux qu'un acheteur ne peut le faire seul.

C'est aussi là que le verrouillage devient plus subtil. Un acheteur peut aimer Apache Ranger, Apache Atlas, Apache Iceberg, Apache Spark et Apache Hive parce que chacun semble ouvert. Mais la dépendance réelle d'une entreprise repose rarement uniquement sur le projet amont. Elle repose sur les versions supportées de Cloudera, les intégrations, les surfaces de gestion, les diagnostics, les mappages de rôles, les paramètres de sécurité par défaut, le chemin de mise à niveau, l'équipe de compte et le processus de support. Les composants ouverts réduisent le risque de verrouillage conceptuel total, mais ils n'éliminent pas le verrouillage opérationnel. Si Cloudera devient l'endroit où vivent toutes les pratiques de politique, de lignage, de catalogue et de réplication, quitter Cloudera signifie recréer plus que des travaux de calcul.

Ce n'est pas nécessairement une raison d'éviter la plateforme. C'est une raison de la tarifer honnêtement. Si SDX réduit le travail répétitif de politique, améliore la confiance dans l'audit et permet aux équipes réglementées de réutiliser les contrôles entre les emplacements, alors la plateforme peut s'autofinancer même lorsque des moteurs moins chers existent. Si SDX devient une autre couche de politique qui doit être réconciliée avec les IAM cloud, les autorisations d'entrepôt, les permissions BI, les rôles Kubernetes et les catalogues tiers, alors elle devient une complexité additive. Les acheteurs doivent tester la couche de politique avec des cas d'exception réels: colonnes masquées, utilisateurs révoqués, comptes de service partagés, tables déplacées, travaux échoués, métadonnées copiées et lectures inter-moteurs.

La migration est le point de preuve

L'angle de l'article de Cloudera réside dans la migration. Une plateforme peut sembler cohérente sur une page produit et échouer lorsqu'une organisation réelle déplace des travaux entre des clusters privés, des services Kubernetes, du stockage cloud public et différents domaines de sécurité. La question pertinente n'est pas « Les données peuvent-elles être copiées? » La question pertinente est de savoir si le déplacement préserve suffisamment de politique, de lignage, de comportement de performance et de procédure de récupération pour que la migration ne devienne pas un projet de conseil ponctuel pour chaque famille de charges de travail.

Replication Manager est la preuve publique la plus claire de la manière dont Cloudera aborde ce problème. Sa documentation couvre HDFS, les tables externes Hive, les tables ACID Hive, Iceberg, Ozone, Ranger, les politiques liées à Atlas, les snapshots, la migration DistCp et la surveillance des politiques de réplication (Index de Replication Manager). Les politiques de réplication HDFS copient les données HDFS entre les services HDFS et peuvent synchroniser les données de destination avec la source, mais elles nécessitent une licence valide et une configuration de cluster prise en charge (Politiques de réplication HDFS). Les politiques de réplication de tables externes Hive peuvent répliquer le métastore Hive et les données vers un autre cluster ou de sur site vers le cloud, mais la documentation indique des limites, notamment que la réplication de cloud à cloud n'est pas prise en charge par ce chemin et que le comportement des tables gérées change lors des transitions CDH vers CDP (Politiques de réplication de tables externes Hive).

Ces limitations ne sont pas disqualifiantes. Elles sont utiles parce qu'elles montrent à quoi ressemble une véritable migration hybride. Le mouvement des politiques et des métadonnées n'est pas magique. La même page Hive met en garde contre les différences de répertoire d'entrepôt, la conversion de tables gérées en tables externes dans certains cas, la réplication de géré à géré non prise en charge et le statut d'aperçu technique pour certains chemins de réplication de métadonnées Atlas. C'est exactement le type de détail que les acheteurs devraient vouloir avant d'acheter. Cela force la conversation sur la migration à sortir de la portabilité vague pour entrer dans l'inventaire des charges de travail: Quelles tables sont externes? Lesquelles sont ACID? Lesquelles dépendent des UDF Impala? Lesquelles utilisent Kudu? Lesquelles stockent des données dans Ozone? Quel système de politique fait autorité? Quel chemin de réplication préserve les métadonnées, et lequel nécessite une procédure distincte?

La réplication des politiques Ranger fait le même constat. Cloudera documente les politiques de réplication Ranger pour les clusters CDP Private Cloud Base compatibles Kerberos, y compris la migration des politiques et des rôles pour HDFS, Hive et HBase, ainsi que la réplication possible des journaux d'audit Ranger dans HDFS (Politiques de réplication Ranger). La documentation indique également que les politiques Ranger peuvent être définies aux niveaux de la base de données, de la table, de la colonne et du fichier. Cela correspond bien à l'argument de gouvernance de Cloudera. Mais ce n'est pas une portabilité universelle. Les versions supportées, la configuration Kerberos, les services source et destination et les procédures de réplication déterminent si un mouvement de politique est routinier ou fragile.

La documentation sur la connectivité Kerberos est particulièrement révélatrice. Cloudera Manager teste si les clusters sont compatibles Kerberos, si les clusters source et cible sont dans le même domaine ou des domaines différents, si les ports KDC sont accessibles et si les mappages de domaine sont corrects (Test de connectivité Kerberos). C'est un travail d'infrastructure banal, pas une fonctionnalité d'IA glamour. C'est aussi là que les plateformes hybrides économisent ou consomment le temps de l'administrateur. Un mappage de domaine défaillant peut arrêter une migration, quel que soit le degré de modernité du format de table.

La conclusion fixe est que la continuité de la migration est le test le plus important pour Cloudera. La société a documenté des outils qui traitent de véritables surfaces de migration. La documentation montre également suffisamment de cas limites pour rejeter toute affirmation simple selon laquelle une charge de travail peut toujours se déplacer sans travail pratique. Cloudera est la plus forte lorsque les acheteurs ont de nombreuses charges de travail similaires, un modèle de sécurité connu, suffisamment de discipline de plateforme pour normaliser les modèles et une feuille de route de migration qui peut réutiliser les procédures. Elle est la plus faible lorsque chaque charge de travail est exceptionnelle, que chaque équipe possède son propre style de politique et que l'acheteur s'attend à ce qu'une licence de plateforme remplace le jugement en ingénierie des données et en architecture de sécurité.

Iceberg rend la stratégie de lac de données crédible, pas automatique

Apache Iceberg donne à Cloudera une histoire de modernisation plus crédible que « garder Hadoop en marche ». Iceberg est un format de table ouvert pour les grands ensembles de données analytiques sur les systèmes de fichiers ou les magasins d'objets. La spécification Apache Iceberg indique que la version 2 ajoute des suppressions au niveau des lignes pour les tables analytiques avec des fichiers immuables via des fichiers de suppression (Spécification Apache Iceberg). La propre matrice de support des fonctionnalités de Cloudera indique que son support Iceberg couvre les moteurs Hive, Impala et Spark et prend en charge les versions v1 et v2 de la spécification Iceberg (Matrice des fonctionnalités Iceberg de Cloudera).

Cela compte pour les données hybrides car le format de table est une frontière de portabilité. Si les données sont enfermées dans le modèle de stockage d'un entrepôt, un acheteur a moins de moyens de combiner les moteurs sans copier les données. Si les données sont stockées dans un format de table ouvert sur un stockage d'objets ou un stockage distribué, plusieurs moteurs peuvent en principe lire et écrire sur la même abstraction de table. La documentation de migration de Cloudera indique qu'Iceberg peut faciliter les implémentations de lac de données ouvert multi-cloud et que les charges de travail basées sur Iceberg peuvent se déplacer entre les environnements de déploiement sur AWS et Azure; elle documente également la migration des tables Hive externes vers Iceberg dans Data Warehouse ou de Spark vers Iceberg dans Data Engineering (Migration de Hive à Iceberg).

Mais Iceberg n'est pas une échappatoire universelle. La même source note des services et des chemins de migration spécifiques pris en charge. La documentation de réplication Iceberg de Cloudera indique que les politiques de réplication Iceberg répliquent les tables Iceberg V2 créées avec Spark, en lecture seule avec Impala, entre les clusters CDP Private Cloud Base, avec des indications de version et un avertissement selon lequel les fonctionnalités de réplication des métadonnées et du lignage Atlas sont en aperçu technique et ne sont pas recommandées pour les déploiements en production (Politiques de réplication Iceberg). C'est une limite de preuve réelle. Un acheteur ne devrait pas entendre « Iceberg » et supposer que chaque moteur, chaque catalogue, chaque modèle de compactage et chaque mouvement de métadonnées est stable en production dans tous les environnements.

Il y a aussi la maintenance ordinaire des tables. Cloudera a introduit la documentation de Lakehouse Optimizer pour la maintenance des tables Iceberg, y compris les politiques, les essais à blanc, les API REST, les associations table-politique et les journaux de tâches (Documentation de Lakehouse Optimizer). L'existence d'un optimiseur est utile, mais elle confirme également que le lac de données n'est pas auto-entretenu. Les petits fichiers, les snapshots, les manifestes, les fichiers de suppression, le compactage et la planification des requêtes deviennent tous des préoccupations opérationnelles. Un entrepôt cloud peut cacher une plus grande partie de ce travail; un lac de données ouvert expose plus de contrôle et plus de responsabilité.

Les problèmes connus renforcent ce point. La page des problèmes connus de Data Warehouse de Cloudera indique que les opérations DELETE, UPDATE ou MERGE Hive ou Impala sur les tables Iceberg V2 peuvent corrompre les tables si un compactage Spark concurrent est validé avant l'instruction de modification, laissant des fichiers de suppression de position pointant vers d'anciens fichiers (Problèmes connus de Data Warehouse). Cela ne signifie pas qu'Iceberg est dangereux en tant que stratégie. Cela signifie que la concurrence, la planification du compactage et la coordination des moteurs font partie de la véritable frontière technique de la plateforme.

Cloudera a également poussé Iceberg comme couche d'interopérabilité avec des tiers. En août 2024, elle a annoncé la modernisation du Data Catalog et l'intégration du Iceberg REST Catalog, indiquant que des moteurs tiers pouvaient accéder aux tables Iceberg tout en maintenant une sécurité, des autorisations et un lignage unifiés (annonce sur les métadonnées et Iceberg REST). En octobre 2024, elle a annoncé une intégration Snowflake alimentée par Apache Iceberg, y compris un accès aux requêtes Snowflake pour les données stockées sur Cloudera Ozone sans duplication ni transfert de données, selon l'annonce (intégration Snowflake). Ces annonces sont importantes sur le plan directionnel car elles reconnaissent la réalité des acheteurs: de nombreuses entreprises ne normaliseront pas sur un seul moteur. Le test commercial est de savoir si Cloudera peut gouverner un lac de données ouvert tout en permettant à d'autres moteurs de participer sans créer de systèmes de sécurité parallèles.

Le mouvement des charges de travail a un coût plancher

L'argumentaire de Cloudera est attrayant parce que le mouvement des charges de travail est coûteux. Il est également attrayant parce que la migration vers le cloud uniquement a déçu certaines organisations qui s'attendaient à un effort d'exploitation moindre et ont plutôt trouvé des données dupliquées, des politiques dupliquées et des coûts moins prévisibles. Mais une plateforme hybride ne peut pas supprimer le coût plancher. Elle ne peut que le déplacer et parfois le réduire.

Le premier plancher est l'infrastructure. Les services de données sur site s'exécutent sur OpenShift ou Cloudera Embedded Container Service selon le choix de déploiement, avec des attentes documentées en matière de nœuds de travail, de CPU, de mémoire, de stockage et de réseau, même pour une installation de base (considérations de déploiement). Cela implique des compétences en Kubernetes ou en plateforme de conteneurs, la planification du stockage, la surveillance, la gestion des certificats et la coordination des mises à niveau. Un acheteur qui a quitté Hadoop en partie parce qu'il manquait de personnel pour maintenir les systèmes distribués ne devrait pas supposer qu'une couche de services de données en cloud privé fait disparaître cette main-d'œuvre.

Le deuxième plancher est l'économie du cloud. La tarification publique sur la page de Cloudera est utile car elle donne une unité visible, l'unité de calcul Cloudera, mais la page exclut explicitement l'infrastructure, le réseau et les coûts associés du fournisseur cloud (tarification). Pour les charges de travail hybrides, ces coûts exclus peuvent être décisifs. La gravité des données, les frais de sortie, les taux de requêtes de stockage d'objets cloud, les déplacements inter-régions, les prix des instances GPU, la connectivité privée et les clusters inactifs peuvent dépasser le tarif logiciel visible. Cloudera Observability peut aider à suivre les coûts, mais la visibilité des coûts n'est pas la même chose que la réduction des coûts.

Le troisième plancher est la gestion des versions et du cycle de vie. Les notes de version des Data Services sur site répertorient des certifications précises pour Cloudera Base, Cloudera Manager, Iceberg v2, les systèmes d'exploitation, Kubernetes, OpenShift et Longhorn (Notes de version des Data Services). Ces certifications sont précieuses car les entreprises réglementées ont besoin de limites de support. Elles sont aussi des contraintes. Une charge de travail peut être techniquement possible sur les versions amont de Spark, Hive ou Iceberg, mais non prise en charge dans la version exacte de Cloudera de l'acheteur. Le coût du maintien du support inclut la planification, les tests et parfois l'attente d'une version certifiée plutôt que l'utilisation immédiate d'une fonctionnalité communautaire.

Le quatrième plancher est la dépendance aux services. Les preuves client de Cloudera mettent parfois en avant les services professionnels. L'étude de cas de Krungsri Bank indique que la banque a utilisé les technologies et les services professionnels de Cloudera pour créer un lac de données unifié, prendre en charge la BI en libre-service et la détection des fraudes, et obtenir une amélioration des performances de 5x dans les domaines optimisés avec les services professionnels de Cloudera (Étude de cas Krungsri Bank). C'est un signal client positif, mais aussi une mise en garde. Si la valeur dépend fortement de l'optimisation menée par les services, l'affirmation d'une plateforme reproductible est plus faible qu'il n'y paraît. La question pertinente pour l'acheteur est de savoir quelles améliorations sont intégrées au produit et lesquelles sont le résultat d'une intervention d'experts.

Le cinquième plancher est la normalisation organisationnelle. Cloudera peut fournir un plan de contrôle commun, mais elle ne peut pas forcer les propriétaires de données à classer les données de manière cohérente, à supprimer les travaux morts, à rationaliser les tables redondantes ou à écrire du code prêt pour la migration. Les plateformes hybrides échouent souvent parce qu'elles préservent trop de variations locales. Chaque exception devient un fardeau de support. La plateforme est plus susceptible d'être rentable si l'acheteur utilise la migration pour simplifier la politique, la disposition des tables, la propriété des travaux et la responsabilité des coûts. Sans cette discipline, Cloudera peut devenir un endroit plus moderne pour héberger de vieilles habitudes.

L'observabilité est nécessaire, mais pas une preuve de résultat

Cloudera Observability répond à un vrai problème. Les plateformes de données hybrides sont difficiles à exploiter car les défaillances sont réparties entre les moteurs, les clusters, les travaux, les systèmes de stockage, les planificateurs, les chemins réseau et les utilisateurs. La documentation d'Observability de Cloudera indique que le service aide les utilisateurs à comprendre les environnements, les services de données, les charges de travail, les clusters et les ressources, en utilisant des métriques, des tests de santé, des conseils prescriptifs, des bases de performance, des analyses historiques, des vues des coûts, des actions en temps réel et des décompositions de charges de travail (Aperçu de Cloudera Observability). C'est exactement la surface dont une entreprise a besoin si elle veut déplacer le travail sans perdre la responsabilité opérationnelle.

La documentation sur les sources de métriques est plus concrète. Telemetry Publisher et Databus WXM Client collectent des métriques, des configurations et des fichiers journaux à partir des services Impala, Oozie, Hive, YARN et Spark pour les travaux de cluster et transmettent les informations à Observability; dans un exemple de Data Hub, certains diagnostics sont extraits périodiquement et d'autres sont envoyés après la fin des travaux (Sources de métriques Observability). Pour les environnements sur site, Cloudera indique que Telemetry Publisher peut collecter et transmettre des métriques, des configurations et des fichiers journaux à partir de ces services, avec des données stockées dans S3 et DynamoDB, une conservation typique de 180 jours et un chiffrement par défaut (collecte de diagnostics sur site).

Cela crée deux implications pour l'acheteur. Premièrement, Observability peut être un élément significatif de l'argument économique hybride car les régressions de performance des requêtes, les travaux incontrôlés, les clusters inactifs et les non-respects des SLA sont coûteux. Un outil qui aide les administrateurs à voir les performances historiques, les coûts et le comportement des charges de travail peut réduire le réglage à l'aveugle. Deuxièmement, la télémétrie elle-même est un sujet de gouvernance et de risque. Les acheteurs doivent comprendre quelles données de diagnostic sont collectées, comment elles sont expurgées, où elles sont stockées, qui peut y accéder et si leurs règles de conformité autorisent ce flux. Cloudera documente des sujets liés à l'expurgation, mais l'acheteur doit encore les valider par rapport à la politique.

Les preuves d'état ajoutent un petit contrôle public utile. La page d'état de Cloudera montrait tous les systèmes opérationnels et aucun incident signalé pour le 11 juillet 2026, avec les services Cloudera répertoriés tels que Data Flow, Data Engineering, Data Warehouse, Operational Database, Cloudera AI, Data Hub, Data Catalog, Replication Manager et Observability marqués comme opérationnels dans toutes les régions sur la page consultée (Statut Cloudera). Ce n'est qu'un indicateur public à un instant donné. Il ne prouve pas les performances au niveau de service pour le déploiement d'un client et ne dit rien sur les clusters privés sur site. Mais c'est un signal public transparent que Cloudera expose la santé des services cloud, ce qui est pertinent lorsqu'une partie de la plateforme dépend de plans de contrôle gérés.

Observability ne prouve pas non plus le résultat client. Un tableau de bord peut révéler qu'une requête est devenue plus lente après la migration; il ne peut pas décider automatiquement si la requête doit être réécrite, ramenée, mise en cache, partitionnée différemment, exécutée sur un autre moteur ou supprimée en tant que dépendance obsolète. Un panneau de coûts peut montrer qu'un cluster est coûteux; il ne peut pas déterminer à qui incombe la réfacturation ni si la latence vaut la dépense. La valeur de Cloudera est la plus forte lorsque Observability est liée à l'autorité opérationnelle: des équipes capables d'agir sur les recommandations, de modifier les modèles de ressources, d'ajuster les files d'attente, d'arrêter les clusters, de régler les travaux et de tenir les propriétaires d'applications responsables.

L'IA augmente les enjeux sans simplifier la plateforme

Cloudera a repositionné son discours sur la plateforme de données autour de l'IA. C'est commercialement nécessaire. Les entreprises se demandent maintenant si leurs parcs de données peuvent prendre en charge la recherche, le réglage fin, la gouvernance des modèles, l'inférence et les applications agentiques sans exposer les données sensibles à des services non gérés. La page Data Services de Cloudera indique que Cloudera AI peut aider à créer et déployer des applications d'IA et de grands modèles de langage personnalisés de manière sécurisée, et sa documentation AI Workbench montre que les workbenches peuvent permettre la gouvernance, les métriques de modèle, TLS, la surveillance et le provisionnement contrôlé par l'administrateur dans les environnements sur site (Provisionnement d'AI Workbench).

La société a également utilisé des acquisitions et des partenariats pour renforcer le discours sur l'IA. En juin 2024, Cloudera a annoncé l'acquisition de la plateforme d'IA opérationnelle de Verta, décrivant Verta comme un pionnier de la gestion, du service et de la gouvernance des modèles pour l'IA prédictive et générative, et indiquant que la technologie prendrait en charge les applications de génération augmentée de recherche, un workbench GenAI, un catalogue de modèles et des outils de gouvernance de l'IA (Acquisition de Verta). En octobre 2024, Cloudera a annoncé AI Inference avec des microservices NVIDIA NIM intégrés, décrivant le déploiement privé, le contrôle d'accès aux modèles, le lignage, l'audit, les tests A/B, les déploiements canaries et les options de déploiement hybride (AI Inference avec NVIDIA NIM).

Ces mouvements correspondent à la thèse centrale de la plateforme: amener le calcul aux données gouvernées plutôt que de déplacer les données sensibles dans chaque service de modèle. Ils élargissent également le fardeau. Les charges de travail d'IA ajoutent des GPU, des registres de modèles, une gouvernance des instructions et de la recherche, la qualité des caractéristiques, l'accès aux points de terminaison des modèles, la surveillance de l'inférence et une nouvelle volatilité des coûts. Une plateforme de données hybride qui peine déjà à maintenir la cohérence des politiques et du lignage des tables ne deviendra pas plus simple parce que l'IA est ajoutée. Elle deviendra plus conséquente.

Le cas d'utilisation de l'IA le plus fort pour Cloudera n'est pas le développement générique de chatbots. C'est l'analytique et les opérations de modèles privées et gouvernées où la localité des données, l'audit et la continuité des politiques comptent. Une banque, un organisme du secteur public, un assureur, une organisation de données de santé ou un opérateur télécom peut valoriser une plateforme qui permet aux équipes de science des données de travailler à proximité des données réglementées tout en préservant le contrôle d'accès. Cela correspond aux exemples de clients de Cloudera. L'étude de cas d'OCBC Bank indique que sa plateforme Next Best Conversation a utilisé l'apprentissage automatique pour analyser les données contextuelles des conversations clients et diffuser des informations personnalisées via les canaux mobiles, avec des chiffres rapportés par le fournisseur tels que 250 millions d'informations par an et la prise en charge par le chatbot de 10 % des interactions sur le site web (Étude de cas OCBC). CIASC, une organisation technologique du secteur public au Brésil, est citée par Cloudera comme disant que son passage à Cloudera a créé un dépôt de données d'État plus organisé qui pourrait soutenir les cas d'utilisation de l'apprentissage automatique et de l'IA (Étude de cas CIASC).

Ce sont des signaux clients, pas des références indépendantes. Ils montrent les types d'organisations que Cloudera souhaite servir et les types de résultats que les acheteurs revendiquent. Ils n'isolent pas la contribution de Cloudera du talent du client, des services professionnels, de l'architecture héritée, du budget, de la qualité des données ou d'autres fournisseurs. La lecture honnête est que Cloudera a une adéquation de domaine crédible là où l'IA dépend de données d'entreprise gouvernées, mais les preuves publiques ne prouvent pas un avantage généralisé en termes de performance ou de retour sur investissement par rapport aux piles d'IA cloud natives, à l'apprentissage automatique natif d'entrepôt, à l'assemblage MLOps open source ou aux plateformes de modèles spécialisées.

Les preuves clients pointent vers une complexité réglementée

Les preuves clients publiques de Cloudera se regroupent autour d'organisations ayant des données réglementées ou opérationnellement complexes. C'est significatif car la proposition de valeur de la plateforme n'est pas particulièrement convaincante pour les petites équipes avec des charges de travail simples et aucun parc hérité. Les acheteurs les plus intéressants sont les banques, les opérations technologiques gouvernementales, les télécoms, les organisations de données de santé, les fabricants et les grandes entreprises avec une gravité des données.

OCBC est un exemple utile car le cas d'utilisation combine l'interaction client, l'apprentissage automatique, la personnalisation et probablement des contrôles bancaires stricts. L'étude de cas de Cloudera indique que la plateforme Next Best Conversation de la banque analyse les données contextuelles en temps réel des conversations clients et diffuse des recommandations et des informations personnalisées via l'application mobile, avec 250 millions d'informations envoyées par an et plus de 100 incitations personnalisées (Étude de cas OCBC). Les preuves sont organisées par le fournisseur, mais elles montrent pourquoi une plateforme de données hybride gouvernée peut avoir de l'importance. La valeur n'est pas seulement un modèle. C'est le chemin opérationnel depuis les données client jusqu'à la sortie du modèle gouverné, puis vers une application orientée client.

CIASC pointe vers un autre marché: les opérations de données du secteur public. L'étude de cas de Cloudera indique que le Centre d'informatique et d'automatisation de Santa Catarina souhaitait un dépôt de données bien organisé dans tout l'État et considérait le support de Cloudera comme important pour maintenir une plateforme complexe (Étude de cas CIASC). L'expression « plateforme complexe » ne doit pas être survolée. C'est à la fois la raison de Cloudera et le risque. Les données du secteur public ont souvent des contraintes de localité, de confidentialité, d'approvisionnement et de personnel. Une plateforme supportée peut réduire le risque d'intégration. Mais si le support est essentiel à la progression courante, les acheteurs doivent budgéter cette dépendance plutôt que de la considérer comme accessoire.

Le cas de Krungsri Bank est commercialement plus fort et plus prudent à la fois. Cloudera indique que la banque a mis en œuvre sa technologie et ses services professionnels pour créer un lac de données unifié pour la BI en libre-service et la détection des fraudes, et que les domaines optimisés avec les services professionnels ont obtenu une amélioration des performances de 5x (Étude de cas Krungsri Bank). L'affirmation de performance est notable, mais la formulation compte. L'amélioration est associée à des domaines optimisés par les services professionnels, et non à un benchmark publié avec une configuration reproductible, une combinaison de charges de travail, une base de référence ou une vérification indépendante. Les acheteurs doivent la lire comme la preuve que le réglage expert peut produire des gains matériels, et non comme la preuve que tous les déploiements Cloudera verront ce résultat.

Ces études de cas soutiennent une conclusion étroite. Cloudera vise les organisations où les données sont trop importantes, distribuées, réglementées ou historiquement enchevêtrées pour être déplacées à la légère dans un nouveau service. Cela ne rend pas la plateforme automatiquement supérieure. Cela signifie que la conversation commerciale doit commencer par le coût de la main-d'œuvre de gouvernance, de la main-d'œuvre de migration et du risque d'audit. Si ceux-ci sont élevés, Cloudera a un argument valable. Si le parc de données de l'acheteur est déjà principalement dans un entrepôt cloud, que la politique est plus simple et que l'équipe a peu besoin de continuité sur site, l'étendue de Cloudera peut sembler être un surcoût.

Les alternatives ne sont pas seulement moins chères ou plus modernes

Cloudera est en concurrence avec plusieurs modèles de substitution. L'un est l'entrepôt de données cloud, où Snowflake, BigQuery, Redshift, Synapse et des services similaires absorbent le travail d'infrastructure et offrent aux utilisateurs métier une couche SQL familière. Un autre est le lac de données cloud ou la plateforme d'analytique unifiée, où Databricks et d'autres combinent Spark, formats de table, notebooks, ingénierie des données, apprentissage automatique et gouvernance. Un autre est un assemblage open source utilisant Apache Iceberg, Spark, Trino, Flink, Airflow, Ranger, Atlas, Kubernetes et un catalogue choisi par l'acheteur. Un autre consiste simplement à étendre les parcs Cloudera existants tout en déplaçant sélectivement les charges de travail vers le cloud.

L'argument le plus fort pour un entrepôt cloud natif est la focalisation. Il peut réduire le nombre de systèmes qu'un analyste métier doit comprendre et transférer la fiabilité de l'infrastructure au fournisseur. Pour de nombreuses charges de travail, c'est la bonne réponse. La faiblesse est la gravité des données et la traduction de la gouvernance. Si les données sensibles doivent rester sur site ou dans une juridiction particulière, si de nombreux travaux s'exécutent déjà sur HDFS ou Ozone, ou si l'acheteur souhaite plusieurs moteurs sur des tables ouvertes, un entrepôt unique peut devenir une autre couche de copie.

L'argument le plus fort pour une plateforme de lac de données cloud est la vélocité des développeurs. Spark, les notebooks, l'outillage ML et la gestion des tables de lac de données peuvent rendre les équipes d'ingénierie des données et d'IA productives. La faiblesse est similaire: dépendance au cloud, traduction de la gouvernance et migration des parcs plus anciens. Le différenciateur de Cloudera n'est pas qu'elle a Spark ou des notebooks. C'est qu'elle peut plausiblement répondre aux besoins des entreprises là où existent encore d'anciens parcs dérivés de Hadoop, des exigences de cloud privé et une gouvernance réglementée.

L'argument le plus fort pour l'assemblage open source est le contrôle. Une équipe de plateforme sophistiquée peut construire une pile autour d'Apache Iceberg, Spark, Trino, Ranger, Atlas ou un autre système de catalogue et de gouvernance, Airflow, Kubernetes et le stockage d'objets cloud. La faiblesse est la main-d'œuvre de support et d'intégration. La valeur de Cloudera est la distribution supportée et la couche de gestion, surtout lorsque les dirigeants veulent un fournisseur responsable de la plateforme. Mais cette responsabilité du fournisseur s'accompagne de coûts de licence, de contraintes de version supportée et d'une dépendance à la feuille de route de Cloudera.

L'argument le plus fort pour rester principalement en l'état est la réduction des risques. Si les charges de travail héritées sont stables et que l'entreprise n'exige pas de modernisation immédiate, une migration massive peut être plus dangereuse qu'une amélioration incrémentale. La faiblesse est la lente dégradation: correctifs de sécurité, compétences vieillissantes, versions non supportées, mauvaise élasticité et incapacité à prendre en charge les nouvelles exigences d'IA ou de partage de données. Le portefeuille actuel de Cloudera tente de rendre la modernisation incrémentale respectable en fournissant des services de données en cloud privé, des chemins de migration Iceberg et des clusters de charge de travail cloud. C'est sensé, mais cela exige toujours un inventaire rigoureux des charges de travail qui méritent une modernisation et de celles qui doivent être retirées.

L'analyse du verrouillage par l'acheteur doit donc être plus précise que « ouvert contre propriétaire ». Cloudera réduit certains verrouillages en s'appuyant sur des moteurs open source et Iceberg. Il augmente d'autres verrouillages en centralisant la gouvernance, la gestion, le support et les procédures de migration au sein de sa plateforme. Un entrepôt cloud peut augmenter le verrouillage du stockage et du moteur de requête tout en réduisant la main-d'œuvre opérationnelle. Une pile open source peut réduire le verrouillage fournisseur tout en augmentant le verrouillage du personnel, car l'architecture réside dans la tête de quelques ingénieurs. Le meilleur choix dépend de la dépendance la moins dangereuse pour l'organisation.

Modes de défaillance à tester avant engagement

Les risques opérationnels pour Cloudera ne sont pas théoriques. La dérive des métadonnées est le premier. Si une table se déplace mais que le catalogue, les classifications, le propriétaire, le lignage ou les étiquettes de politique sont à la traîne, les utilisateurs peuvent faire confiance aux mauvaises données ou les administrateurs peuvent autoriser le mauvais accès. La documentation du Data Catalog et de SDX de Cloudera montre des outils pour les métadonnées et la gouvernance, mais les outils ne garantissent pas la discipline opérationnelle.

La non-concordance des autorisations est le deuxième. Les politiques Ranger, les groupes LDAP, les domaines Kerberos, les comptes de service, les rôles IAM cloud, les espaces de noms Kubernetes et les autorisations d'entrepôt peuvent diverger. La documentation de réplication Ranger et Kerberos de Cloudera montre que la société comprend cette surface, mais les acheteurs doivent tester leurs propres politiques les plus bizarres, pas une démo propre. Les utilisateurs révoqués, les accès d'urgence, les appartenances de groupe héritées et les exceptions au niveau des colonnes sont de meilleurs tests que l'accès en lecture du chemin heureux.

L'échec de la migration des travaux est le troisième. Les travaux Spark peuvent supposer des chemins de fichiers, des versions de bibliothèque, des noms de file d'attente, des emplacements de secrets, un comportement de planificateur ou une localité des données. Cloudera Data Engineering documente la création, les mises à jour, les ressources, les travaux Airflow, les sessions, les secrets et la soumission Spark basés sur CLI (Documentation CLI de CDE). Cette surface opérationnelle est utile, mais la migration nécessite toujours un examen du code et des dépendances.

La régression des performances des requêtes est la quatrième. Passer d'un environnement Impala ou Hive réglé à un autre moteur, format de table ou couche de stockage peut améliorer certaines charges de travail et en dégrader d'autres. Observability peut identifier les régressions, et Iceberg peut améliorer certains modèles de lac de données, mais ni l'un ni l'autre n'élimine le travail de benchmark. Les acheteurs doivent tester des tableaux de bord BI représentatifs, des jointures lourdes, des tables à forte compaction, l'ingestion incrémentale et la concurrence sous des règles d'autorisation réalistes.

La surprise des coûts de stockage est la cinquième. Le stockage d'objets est bon marché par unité jusqu'à ce que la duplication, la conservation, les petits fichiers, les snapshots, les manifestes, les artefacts de compactage et le trafic inter-régions s'accumulent. La tarification de Cloudera exclut les coûts d'infrastructure et de réseau, et sa documentation Lakehouse Optimizer implique un besoin continu de maintenance des tables. L'acheteur doit modéliser le coût total, pas les postes logiciels.

Les connecteurs non pris en charge et les ruptures de mise à niveau sont le sixième et le septième. Les plateformes hybrides vivent de connecteurs: magasins d'objets, fournisseurs d'identité, outils BI, registres de modèles, environnements de science des données, systèmes de streaming et moteurs tiers. Un seul connecteur non pris en charge peut transformer une migration standard en un projet sur mesure. Les notes de version et les matrices de support doivent être traitées comme des documents d'approvisionnement, pas comme une lecture après-vente.

Le contournement de la gouvernance est le huitième. Si les utilisateurs peuvent interroger des données copiées via un autre moteur en dehors de SDX, ou si les équipes de développement créent des ensembles de données non gérés pour aller plus vite, l'affirmation de continuité des politiques de la plateforme s'affaiblit. Les annonces d'Iceberg REST et de l'intégration Snowflake de Cloudera montrent un effort pour prendre en charge l'accès tiers tout en préservant la sécurité et le lignage. L'acheteur doit encore vérifier comment l'application fonctionne dans son environnement.

La dépendance aux services est la neuvième. Les services professionnels peuvent accélérer la migration et le réglage, mais ils peuvent aussi cacher une complexité non répétée. Un acheteur doit demander quelles procédures deviennent des procédures internes, lesquelles sont automatisées par le produit, lesquelles nécessitent le support de Cloudera et lesquelles nécessiteront à nouveau une aide extérieure lors de la prochaine mise à niveau.

Verdict: Cloudera est un pari sur la gouvernance et la migration

Le meilleur argument de Cloudera n'est pas la nostalgie. C'est que les entreprises avec des parcs de données distribués, réglementés ou lourds d'héritage ont besoin d'un chemin de modernisation gouverné qui ne force pas chaque charge de travail dans un seul service de cloud public ou chaque équipe de plateforme à auto-supporter une pile open source complète. Les preuves publiques soutiennent cet argument au niveau de l'architecture. SDX lie la politique et les métadonnées à la plateforme. Data Hub connecte les clusters de charge de travail cloud aux lacs de données gouvernés. Les services de données privés apportent les surfaces d'entrepôt, d'IA, de catalogue, de réplication et d'ingénierie des données sur site. Replication Manager répond aux préoccupations réelles de migration HDFS, Hive, Ranger, Iceberg, Ozone et Kerberos. Observability expose les signaux de charge de travail, de cluster, de performance et de coût. Iceberg donne à l'histoire du lac de données une base de format de table ouvert.

Les mêmes preuves fixent également la limite. Cloudera ne supprime pas la nécessité de comprendre les versions, les domaines de sécurité, les types de tables, le compactage, l'état de réplication des métadonnées, les matrices de support, le dimensionnement de l'infrastructure et les coûts cloud. Certains chemins importants sont limités, en aperçu technique ou explicitement restreints. Les études de cas clients montrent une adéquation dans les organisations réglementées et complexes, mais elles ne fournissent pas de comparaisons contrôlées. Les preuves financières publiques sont périmées car l'entreprise est privée. Les affirmations du fournisseur sur l'échelle et le retour sur investissement peuvent être directionnellement utiles, mais elles ne remplacent pas les tests de l'acheteur.

Cela produit une règle d'achat claire. Cloudera mérite une évaluation sérieuse lorsque l'acheteur a de réelles contraintes hybrides: des données qui doivent rester dans les centres de données ou des juridictions spécifiques, des charges de travail substantielles dérivées de Hadoop, plusieurs moteurs d'analytique et d'IA, un besoin de politique d'accès et de lignage communs, et un programme de migration où les modèles répétés peuvent être normalisés. Elle est moins convaincante lorsque l'acheteur peut passer proprement à un entrepôt ou un lac de données cloud natif, accepter le plan de contrôle de ce fournisseur et éviter de maintenir une infrastructure de données distribuée privée.

Le test final est la main-d'œuvre. Si Cloudera réduit le travail humain de préservation de la politique, du lignage, de la récupération et de la visibilité des coûts lorsque les charges de travail se déplacent, elle peut justifier une prime. Si elle ne fait que regrouper le même fardeau d'intégration derrière un nom de produit plus large, des substituts moins chers ou plus ciblés l'emporteront. L'entreprise doit être jugée non pas sur la survie de Hadoop, mais sur la question de savoir si le travail de données hybride gouverné devient suffisamment reproductible pour que la modernisation cesse de ressembler à un projet de services personnalisé chaque fois qu'une table, un travail ou un modèle franchit une frontière d'environnement.