サマリー

  • Cloudera の戦略的主張は、古い Hadoop 環境を凍結したままにすべきだということではない。それは、大規模規制対象組織が、オンプレミス、プライベートクラウド、パブリッククラウドの各環境にわたって、ポリシー、メタデータ、リネージ、ワークロード分離、運用可観測性を維持しながら、分析と AI をモダナイズできるという点にある。
  • その主張を裏付ける最も強力な証拠は、事例証拠ではなくアーキテクチャ上のものである。Cloudera は、共有セキュリティ・ガバナンス設計、統制データレイクに接続された Data Hub クラスター、オンプレミスで稼働するデータサービス、HDFS、Hive、Ranger、Iceberg、Ozone 向けの Replication Manager パス、ジョブ、クエリ、クラスター、コストに関する可観測性テレメトリを文書化している。
  • リスクも同様に具体的だ。Iceberg のサポートはテーブルメンテナンス作業をなくすわけではない。一部のレプリケーション機能やメタデータ機能はバージョン制限付きまたはテクニカルプレビューのままだ。Cloudera の価格設定には基盤となるインフラストラクチャとネットワーキングコストが含まれていない。顧客事例は、管理された比較ではなく、ベンダーが厳選したものだ。
  • したがって、購入の判断基準は狭まる。Cloudera が最も防御力を発揮するのは、ハイブリッドデータのローカリティ、ガバナンスの継続性、ワークロード移行の手間が、同社プラットフォーム内にとどまるためのライセンス、サービス、インフラ、クラウド、アップグレード、ロックインのコストよりも高くつく場合である。

本当の問題は、ハイブリッド管理が手間を削減するかどうかだ

Cloudera の現在のビジネスは、10 年前に取り沙汰されたものとは異なる問いに照らして評価されなければならない。問われているのは、ブランドとしての Hadoop がクラウドデータウェアハウスを生き延びたかどうかではない。分散データ基盤に長い伝統を持つ企業が、ハイブリッド分析を代替手段よりも低負荷にできるかどうかである。多くの企業は、あるクリーンなアーキテクチャから別のクリーンなアーキテクチャへ移行したわけではないため、この区別は重要だ。彼らは、HDFS クラスター、Hive メタストアの慣例、Spark ジョブ、Impala ワークロード、Kafka スタイルのインジェスト、セキュリティ例外、手動調整されたキュー、ビジネスクリティカルなダッシュボード、データローカリティに依存する機械学習プロジェクトを蓄積してきた。負担はコンピュートだけではない。どのテーブルを誰が読み取れるか、どの変換がフィールドを作成したか、どのサービスアカウントがモデル特徴を書き込めるか、どのジョブがバーストを許可されるか、どのクラスターがリージョン内にとどまらなければならないか、といった記憶の負担も大きい。

Cloudera 自身のプラットフォームページでは、オンプレミス、パブリッククラウド、エッジ環境にわたる「一貫したエクスペリエンス、統合ガバナンス、柔軟な管理」を核に据え、チームが場所を問わず同様のサービス、API、インターフェースを利用できると主張している（Cloudera Platform for Data and AI）。これはマーケティング文言だが、関連する技術的前提を示している。ハイブリッドデータプラットフォームは、ワークロードが移動するたびに発生するポリシー、メタデータ、ランブックの変換回数を減らす場合にのみ価値を持つ。Spark ジョブをクラウドクラスターに移動させるたびに、アクセスポリシーの書き直し、リネージの再構築、データセットの再分類、すべてのクエリの再調整、後になってからのクラウドストレージ料金の発見という手順が必要になるなら、そのプラットフォームはバイヤーの問題を解決していない。それは、統合作業を続けるための管理された手段を売り込んだに過ぎない。

Cloudera の現在の製品ラインは、その反論に答えるために構築されている。同社は自らを、データと AI のプラットフォームプロバイダーと称し、AI をデータが「存在するあらゆる場所」にもたらし、2 万 5000 エクサバイト以上のデータを管理し、年間経常収益 10 億ドル超などの大規模な管理実績があると、概要ページで主張している（About Cloudera）。これらの規模に関する主張はベンダー提供のものであり、そのように扱うべきである。より重要な証拠は製品および技術ドキュメントにある。Shared Data Experience、Data Catalog、Data Hub、Data Engineering、Data Warehouse、Cloudera AI、Replication Manager、Observability、オンプレミスの Data Services である。これらを総合すると、環境間の継続性を経済単位として販売しようとする企業の姿が浮かび上がる。

その継続性は商業的に妥当である。なぜなら、逆のケースは高くつくからだ。代替手段は単に「Snowflake に移行する」「Databricks に移行する」「オープンソースを使う」「オンプレミスにとどまる」ではない。それぞれの代替策は、作業の所在を変える。クラウドネイティブなウェアハウスはインフラ管理を削減するが、エグレス、データコピー、ポリシー再実装、プラットフォーム依存の作業を増やす可能性がある。Apache プロジェクトから組み立てたレイクハウスはライセンスエクスポージャーを下げられるが、サポートとインテグレーションのリスクをバイヤーに転嫁する。レガシークラスターを変更しないままだと、既知の動作は保たれるが、ライフサイクル、セキュリティ、雇用、アップグレードのコストが上昇する。Cloudera が勝つのは、使い慣れた分散データ資産を十分に維持しながら、ポリシー、移動、可観測性、モダナイゼーションをよりビスポークなものから解放できる場合だけである。

Cloudera が今売っているもの

Cloudera は、Clayton, Dubilier & Rice および KKR による約 53 億ドルの取引の後、2021 年 10 月に非公開企業となり、その普通株式はニューヨーク証券取引所での取引を停止した（買収完了アナウンス）。そのため、直近の公開企業としての財務スナップショットは古い。非公開化取引前の 2021 会計年度では、Cloudera は総収入 8 億 6930 万ドル、サブスクリプション収入 7 億 8280 万ドル、年間経常収益 7 億 7800 万ドルを報告した（FY2021 決算）。それ以降、外部の読者は公開提出書類を使って、収入内訳、継続率、利益率、クラウド移行の進捗を同じ精度で検証することはできない。

製品も、Hadoop ディストリビューション＋サポートという古いメンタルモデルから変化している。Cloudera Data Hub は、CDH と HDP の系譜を組み合わせた同社のディストリビューションである Cloudera Runtime を搭載したワークロードクラスターを起動・管理するためのサービスとして文書化されており、AWS、Microsoft Azure、Google Cloud Platform で利用できる（Data Hub 概要）。ワークロード分離、クラスターライフサイクルの自動化、テンプレート、スケーリング、Apache Knox による安全なアクセスを提供する。文書化されたアーキテクチャは、これらのクラスターを環境内の Data Lake に接続するため、セキュリティとガバナンスは単にクラスターごとの後付けではない。

プライベート側では、オンプレミスの Cloudera Base は、コンピュートをストレージから分離し、リモートクラスターからデータにアクセスできるハイブリッドソリューションの基盤と位置づけられている。これには、Cloudera Data Services on premises で作成されたワークロードも含まれる（オンプレミス Cloudera Base）。Data Services on premises には、Management Console、Data Warehouse、Cloudera AI、Data Catalog、Replication Manager、Data Engineering が含まれる（Data Services リリースノート）。インストールモデルは軽量ではない。Cloudera は OpenShift のワーカーノード要件を文書化しており、ノード数は仮想ウェアハウスや機械学習ワークスペースの数に依存し、本番環境のサイジングは Cloudera サポートまたはアカウントチームを通じて行うとしている（導入に関する考慮事項）。

この導入フットプリントは、バイヤーのコスト分析の中心である。Cloudera は単純なホスティング SQL エンドポイントではない。それは、自社データセンター、プライベートクラウド、またはパブリッククラウドアカウントのいずれであれ、依然として相当なデータ基盤を運用する必要がある組織のためのプラットフォームなのだ。Cloudera の公開価格ページには、Data Hub、Data Engineering、Data Warehouse、Operational Database、Observability Premium、AI Workbench、AI Inference などのクラウドサービスについて、Cloudera Compute Unit あたりの料金が記載されているが、表示価格は見積りであり、インフラストラクチャ、ネットワーキング、その他のクラウドプロバイダーコストは含まれないと明記されている（Cloudera 価格）。この但し書きは軽微ではない。コントロールプレーンは Cloudera から購入するかもしれないが、経済的な成果は、ストレージの所在地、インスタンスの組み合わせ、GPU の使用、ネットワークパス、サポートプラン、プロフェッショナルサービス、そしてワークロードをシャットダウンしたり適正化したりする規律にかかっている。

したがって、製品の実際の形状は、単なるデータエンジンではなく、ハイブリッドな運用レイヤーである。インジェスト、Spark や Airflow 指向のデータエンジニアリング、SQL ウェアハウジング、運用データベース機能、AI ワークスペースと推論、カタログ作成、レプリケーション、可観測性をバンドルしている。同社はこのポートフォリオを、ストリーミングから本番 AI までの段階向け「クラウドネイティブサービス」と呼び、ワークロードはコードの書き換えなしにパブリッククラウドとプライベートクラウド間で移行できると述べている（Cloudera Data Services）。この主張は、バージョン、コネクター、セキュリティ、パフォーマンスの制約に縛られた野心として読むべきだが、Cloudera が依然として重要な理由を捉えている。同社は、特定のエンジンよりも、移行の継続性を販売しているのだ。

ポリシープレーンこそが製品である

Cloudera にとって最も強力な技術的論拠は、Shared Data Experience（SDX）にある。Cloudera のセキュリティドキュメントでは、SDX を、セキュリティポリシーの実装に使用されるメタデータから構築され、製品に組み込まれた設計アーキテクチャと説明している。Ranger、Atlas、Knox、Hive Metastore、Cloudera Data Catalog、Replication Manager、Workload Manager を SDX の組み合わせの一部として挙げている（SDX ドキュメント）。キーフレーズは製品名ではない。デジタル環境全体でポリシー、スキーマ、メタデータの一貫性を約束することにある。

この約束が重要なのは、企業のデータチームは通常、継ぎ目で失敗するからだ。チームはファイルを移動できるが、それに付随するポリシーの意図を失う。テーブルをコピーできるが、導出された特徴が規制対象モデルで使用可能かを判断するために必要なリネージを失う。クエリを移行できるが、ロールマッピング、Kerberos 設定、SAML グループ、サービスアカウント、列レベルの制御が同等でないことに気づく。新しいレイクハウスのテーブルフォーマットを追加できるが、サードパーティのエンジンが期待されるパス外でテーブルを読み取ると、監査証跡が破損する。ポリシー継続性を保持するプラットフォームは、真の運用負荷を削減できるが、それは管理者がそれをアクセスの基準点とするのに十分な信頼を寄せた場合に限られる。

Cloudera の Data Catalog 製品ページも同じ点を中心に構築されている。このサービスは、データの発見、機密情報の管理、リネージの追跡、アクセスの監査、データの分類とプロファイリング、そしてクラウドとオンプレミス環境全体でのポリシーベースの制御施行を目的としていると述べている（Cloudera Data Catalog）。これは正しい問題設定だ。単にユーザーがテーブルを見つけるのを助けるカタログは有用だが、核心的な商業的問いに決着をつけるものではない。プレミアムが正当化されるのは、メタデータが誰がデータを発見できるか、誰がクエリできるか、どこに移動したか、どのエンジンが触れたか、どのラベルが付いているか、どの義務が伴うかといった制御面になったときだ。

基盤となるオープンソースの系譜も重要である。Apache Ranger は、Hadoop エコシステム全体にわたるデータセキュリティの有効化、監視、管理のためのフレームワークであり、集中ポリシー管理とユーザーアクセスの監視を提供すると説明している（Apache Ranger）。Apache Atlas は、データ資産をカタログ化、分類、統制するためのメタデータ管理・ガバナンスフレームワークだと自らを説明している（Apache Atlas）。Cloudera がポリシーやリネージの必要性を発明したわけではなく、オープンソースの概念を完全に所有しているわけでもない。同社の提案は、これらのコンポーネントを、複雑な企業の資産全体にわたって、バイヤーが単独で行うよりも優れた方法で、組み立て、強化し、サポートし、拡張できるという点にある。

それは、ロックインがより微妙になる場所でもある。バイヤーは、Apache Ranger、Apache Atlas、Apache Iceberg、Apache Spark、Apache Hive のそれぞれがオープンに思えるため好むかもしれない。しかし、企業の実際の依存先は、単に上流プロジェクトだけなことは稀だ。それは、Cloudera のサポート対象バージョン、統合、管理画面、診断、ロールマッピング、セキュリティデフォルト、アップグレードパス、アカウントチーム、サポートプロセスにかかっている。オープンなコンポーネントは、完全な概念的ロックインのリスクを下げるが、運用上のロックインを排除するわけではない。Cloudera がすべてのポリシー、リネージ、カタログ、レプリケーションの実践が存在する場所になれば、Cloudera から離れることは、単にコンピュートジョブ以上のものを再作成することを意味する。

これは必ずしもプラットフォームを避ける理由ではない。正直に価格付けする理由である。SDX が反復的なポリシー作業を減らし、監査の信頼性を高め、規制対象チームが場所をまたいで制御を再利用できるようにするなら、より安価なエンジンが存在しても、プラットフォームは元が取れるかもしれない。SDX が、クラウド IAM、ウェアハウス許可、BI 許可、Kubernetes ロール、サードパーティカタログと調整しなければならない別のポリシーレイヤーになるなら、それは付加的な複雑性になる。バイヤーは、マスクされた列、取り消されたユーザー、共有サービスアカウント、移動されたテーブル、失敗したジョブ、コピーされたメタデータ、クロスエンジン読み取りといった実際の例外ケースでポリシープレーンをテストする必要がある。

移行が証明の場である

Cloudera の記事の視点は移行にある。プラットフォームは製品ページでは首尾一貫して見えても、実際の組織がジョブをプライベートクラスター、Kubernetes サービス、パブリッククラウドストレージ、異なるセキュリティレルム間で移動させるときに失敗する可能性がある。関連する問いは「データをコピーできるか？」ではない。移動によって、ポリシー、リネージ、パフォーマンス動作、リカバリ手順が十分に保持され、移行がワークロードファミリーごとの一回限りのコンサルティングプロジェクトにならずに済むかどうかである。

Replication Manager は、Cloudera がその問題にどう取り組むかに関する最も明確な公的証拠である。そのドキュメントは、HDFS、Hive 外部テーブル、Hive ACID テーブル、Iceberg、Ozone、Ranger、Atlas 関連ポリシー、スナップショット、DistCp 移行、レプリケーションポリシーの監視をカバーしている（Replication Manager インデックス）。HDFS レプリケーションポリシーは HDFS サービス間で HDFS データをコピーし、宛先データをソースと同期させることができるが、有効なライセンスとサポート対象のクラスター設定が必要である（HDFS レプリケーションポリシー）。Hive 外部テーブルレプリケーションポリシーは、Hive メタストアとデータを別のクラスターに、またはオンプレミスからクラウドに複製できるが、ドキュメントには、そのパスではクラウド間レプリケーションがサポートされないことや、CDH から CDP への移行中に管理テーブルの動作が変わることなどの制限が記載されている（Hive 外部テーブルレプリケーションポリシー）。

これらの制限は失格理由にはならない。それらは、真のハイブリッド移行がどのようなものかを示すため有用である。ポリシーとメタデータの移動は魔法ではない。先の Hive ページは、ウェアハウスディレクトリの違い、場合によっては管理テーブルから外部テーブルへの変換、サポートされていない管理テーブル間レプリケーション、一部の Atlas メタデータレプリケーションパスのテクニカルプレビュー状況について警告している。それはまさに、バイヤーが購入前に知っておくべき種類の詳細である。これにより、移行の会話は漠然とした移植性から、ワークロードの棚卸しへと移る。どのテーブルが外部か？ ACID か？ Impala UDF に依存しているか？ Kudu を使っているか？ Ozone にデータを保存しているか？ どのポリシーシステムが権威か？ どのレプリケーションパスがメタデータを保持し、どれが別の手順を必要とするか？

Ranger ポリシーのレプリケーションも同じ点を示している。Cloudera は、Kerberos 対応の CDP Private Cloud Base クラスター向けの Ranger レプリケーションポリシーを文書化しており、HDFS、Hive、HBase 用のポリシーとロールの移行に加えて、HDFS での Ranger 監査ログレプリケーションの可能性も示している（Ranger レプリケーションポリシー）。また、Ranger ポリシーはデータベース、テーブル、列、ファイルレベルで定義可能だとも述べている。これは Cloudera のガバナンス訴求に強く合致するが、普遍的な移植性ではない。サポートされるバージョン、Kerberos のセットアップ、ソースとデスティネーションのサービス、レプリケーション手順が、ポリシーの移動が日常的か脆弱かを決定する。

Kerberos 接続のドキュメントは特に示唆的である。Cloudera Manager は、クラスターが Kerberos 対応かどうか、ソースとターゲットのクラスターが同じレルムか異なるか、KDC ポートに到達可能か、レルムマッピングが正しいかをテストする（Kerberos 接続テスト）。これは華やかな AI 機能ではなく、地味なインフラ作業である。これは、ハイブリッドプラットフォームが管理者の時間を節約するか消費するかの分かれ目でもある。失敗したレルムマッピングは、テーブルフォーマットがいかに現代的であっても、移行を止めてしまう。

定まった結論は、移行の継続性が Cloudera の最も重要なテストだということだ。同社は実際の移行領域に対処するツールを文書化している。また、そのドキュメントは、ワークロードが常に実務作業なしに移動できるという単純な主張を退けるのに十分なエッジケースを示している。Cloudera が最も強いのは、バイヤーが多くの類似ワークロード、既知のセキュリティモデル、パターンを標準化するための十分なプラットフォーム規律、そして手順を再利用できる移行ロードマップを持っている場合である。それぞれのワークロードが例外的で、各チームが独自のポリシースタイルを所有し、バイヤーがプラットフォームライセンスがデータエンジニアリングとセキュリティアーキテクチャの判断を代替することを期待する場合には、最も弱い。

Iceberg がレイクハウス戦略を信頼できるものにするが、自動的ではない

Apache Iceberg は、「Hadoop を動かし続ける」よりも信頼性の高いモダナイゼーションストーリーを Cloudera にもたらす。Iceberg は、ファイルシステムやオブジェクトストア上の大規模分析データセット向けのオープンテーブルフォーマットである。Apache Iceberg 仕様では、バージョン 2 で、イミュータブルファイルを持つ分析テーブルに対する行レベルの削除が、削除ファイルを通じて追加されるとしている（Apache Iceberg 仕様）。Cloudera 自身の機能サポートマトリクスでは、Hive、Impala、Spark エンジンで Iceberg をサポートし、v1 および v2 バージョンの Iceberg 仕様をサポートするとしている（Cloudera Iceberg 機能マトリクス）。

これは、テーブルフォーマットが移植性の境界であるため、ハイブリッドデータにとって重要である。データが単一のウェアハウスのストレージモデル内にロックされている場合、バイヤーはデータをコピーせずにエンジンを組み合わせる手段が少なくなる。データがオブジェクトストレージや分散ストレージ上のオープンテーブルフォーマットで保存されている場合、複数のエンジンが原理的には同じテーブル抽象化に対して読み書きできる。Cloudera の移行ドキュメントでは、Iceberg がマルチクラウドのオープンレイクハウス実装を促進し、AWS や Azure 上のデプロイメント環境間で Iceberg ベースのワークロードを移動できるとし、Data Warehouse での Hive 外部テーブルから Iceberg への移行や、Data Engineering での Spark から Iceberg への移行についても文書化している（Hive から Iceberg への移行）。

しかし、Iceberg は万能の脱出口ではない。同じソースは特定のサポート対象サービスと移行パスを指摘している。Cloudera の Iceberg レプリケーションドキュメントでは、Iceberg レプリケーションポリシーは、Spark を使用して作成され、Impala で読み取り専用の Iceberg V2 テーブルを CDP Private Cloud Base クラスター間で複製するものであり、バージョンガイダンスとともに、Atlas メタデータおよびリネージレプリケーション機能はテクニカルプレビューであり、本番展開には推奨されないとの警告が付されている（Iceberg レプリケーションポリシー）。これは真の証拠制限である。バイヤーが「Iceberg」と聞いて、あらゆるエンジン、あらゆるカタログ、あらゆるコンパクションパターン、あらゆるメタデータ移動がすべての環境で本番安定していると思い込んではいけない。

通常のテーブルメンテナンスもある。Cloudera は、ポリシー、ドライラン、REST API、テーブル-ポリシーアソシエーション、タスクログを含む、Iceberg テーブルメンテナンス用の Lakehouse Optimizer のドキュメントを導入している（Lakehouse Optimizer ドキュメント）。オプティマイザの存在は有用だが、それはレイクハウスが自己維持型ではないことも確認させる。小さなファイル、スナップショット、マニフェスト、削除ファイル、コンパクション、クエリプランニングはすべて運用上の関心事となる。クラウドウェアハウスはその作業の多くを隠蔽するかもしれないが、オープンレイクハウスはより多くの管理とより多くの責任をさらけ出す。

既知の問題がその点を際立たせる。Cloudera の Data Warehouse 既知の問題ページでは、Iceberg V2 テーブルに対する Hive または Impala の DELETE、UPDATE、または MERGE 操作が、同時実行の Spark コンパクションが変更ステートメントの前にコミットされた場合にテーブルを破損させる可能性があり、位置削除ファイルが古いファイルを指したままになるとしている（Data Warehouse 既知の問題）。これは、戦略として Iceberg が安全ではないという意味ではない。同時実行性、コンパクションスケジューリング、エンジン調整が、プラットフォームの実際の技術的境界の一部であることを意味している。

Cloudera はまた、サードパーティとの相互運用レイヤーとして Iceberg を推進してきた。2024 年 8 月には、Data Catalog のモダナイゼーションと Iceberg REST Catalog 統合を発表し、サードパーティのエンジンが Iceberg テーブルにアクセスしながら、統一されたセキュリティ、権限、リネージを維持できると述べた（メタデータおよび Iceberg REST 発表）。2024 年 10 月には、Apache Iceberg を活用した Snowflake 統合を発表し、発表によれば、データの複製や転送なしに、Cloudera Ozone に保存されたデータへの Snowflake クエリアクセスを含むとした（Snowflake 統合）。これらは、多くの企業が単一のエンジンには標準化しないというバイヤーの現実を認めているため、方向性として重要である。商業的なテストは、Cloudera がオープンレイクハウスを統制しながら、他のエンジンが並行するセキュリティシステムを作成することなく参加できるようにできるかどうかである。

ワークロード移動にはコストの下限がある

Cloudera の売り込みが魅力的なのは、ワークロードの移動が高額であるからだ。また、クラウドのみの移行が、運用負荷の低下を期待していた一部の組織を失望させ、代わりにデータの重複、ポリシーの重複、予測不能なコストを発見したからでもある。しかし、ハイブリッドプラットフォームはコストの下限を取り除くことはできない。それを移動させ、時には引き下げるだけである。

第一の下限はインフラである。オンプレミスの Data Services は、デプロイメントの選択に応じて OpenShift または Cloudera Embedded Container Service 上で稼働し、基本的なインストールであっても、文書化されたワーカーノード、CPU、メモリ、ストレージ、ネットワークの要件を伴う（導入に関する考慮事項）。これは、Kubernetes またはコンテナプラットフォームの能力、ストレージ計画、監視、証明書管理、アップグレード調整が必要であることを意味する。分散システムを維持するスタッフが不足しているために Hadoop を離れたバイヤーは、プライベートクラウドデータサービスレイヤーがその労働を消し去ると想定すべきではない。

第二の下限はクラウド経済である。Cloudera のページの公開価格は、可視化された単位である Cloudera Compute Unit を提供するため有用だが、そのページはインフラストラクチャ、ネットワーキング、関連するクラウドプロバイダーコストを明示的に除外している（価格）。ハイブリッドワークロードにとって、これらの除外コストは決定的になりうる。データ重力、エグレス、クラウドオブジェクトストレージのリクエストレート、リージョン間移動、GPU インスタンス価格、プライベート接続、アイドルクラスターは、可視化されたソフトウェア料金を上回る可能性がある。Cloudera Observability はコスト追跡に役立つかもしれないが、コスト可視化はコスト削減と同じではない。

第三の下限はバージョンとライフサイクル管理である。Data Services on premises のリリースノートには、Cloudera Base、Cloudera Manager、Iceberg v2、オペレーティングシステム、Kubernetes、OpenShift、Longhorn の正確な認定条件がリストされている（Data Services リリースノート）。規制対象企業がサポート境界を必要とするため、これらの認定は貴重である。それらは制約でもある。ワークロードは、上流の Spark、Hive、Iceberg では技術的に可能かもしれないが、バイヤーの正確な Cloudera リリースではサポートされていない可能性がある。サポートされ続けることのコストには、計画、テスト、そして時にはコミュニティ機能をすぐに使う代わりに認定バージョンを待つことが含まれる。

第四の下限はサービス依存である。Cloudera の顧客証拠は、時にプロフェッショナルサービスを強調する。クルンシー銀行の事例研究では、同行が Cloudera のテクノロジーとプロフェッショナルサービスを使用して、統合データレイクハウスを作成し、セルフサービス BI と不正検出をサポートし、Cloudera のプロフェッショナルサービスによって最適化された領域で 5 倍のパフォーマンス改善を達成したとされている（クルンシー銀行の事例研究）。これは肯定的な顧客シグナルだが、注意喚起でもある。価値がサービス主導のチューニングに大きく依存するなら、再現可能なプラットフォームの主張は見かけほど強くない。関連するバイヤーの問いは、どの改善が製品化され、どれが専門家の介入の結果であるかだ。

第五の下限は組織の標準化である。Cloudera は共通のコントロールプレーンを提供できるが、データ所有者に一貫したデータ分類、デッドジョブの廃止、冗長テーブルの合理化、移行対応コードの作成を強制することはできない。ハイブリッドプラットフォームは、あまりにも多くのローカルなバリエーションを保持するためにしばしば失敗する。あらゆる例外がサポートの負担になる。プラットフォームは、バイヤーが移行を利用してポリシー、テーブルレイアウト、ジョブ所有権、コスト説明責任を簡素化するなら、より利益を生む可能性が高い。その規律がなければ、Cloudera は古い習慣をホストするためのより現代的な場所になるかもしれない。

可観測性は必要だが、結果の証明ではない

Cloudera Observability は現実の問題に対処する。ハイブリッドデータプラットフォームは、障害がエンジン、クラスター、ジョブ、ストレージシステム、スケジューラー、ネットワークパス、ユーザーに分散しているため、運用が難しい。Cloudera の Observability ドキュメントでは、このサービスが、メトリクス、ヘルステスト、規範的ガイダンス、パフォーマンスベースライン、履歴分析、コストビュー、リアルタイムアクション、ワークロード内訳を使用して、ユーザーが環境、データサービス、ワークロード、クラスター、リソースを理解するのを助けるとしている（Cloudera Observability 概要）。それはまさに、運用の説明責任を失うことなく作業を移動したい場合に企業が必要とする領域である。

メトリクスソースのドキュメントはより具体的だ。Telemetry Publisher と Databus WXM Client は、クラスタージョブの Impala、Oozie、Hive、YARN、Spark の各サービスからメトリクス、構成、ログファイルを収集し、Observability に送信する。ある Data Hub の例では、一部の診断情報は定期的にプルされ、他のものはジョブ完了後にプッシュされる（Observability メトリクスソース）。オンプレミス環境については、Cloudera は、Telemetry Publisher がこれらのサービスからメトリクス、構成、ログファイルを収集して送信でき、データは S3 と DynamoDB に保存され、通常の保存期間は 180 日で、デフォルトで暗号化されると述べている（オンプレミス診断収集）。

これにより、2 つのバイヤーへの含意が生じる。第一に、Observability はハイブリッド経済のケースの有意義な部分になり得る。なぜなら、クエリパフォーマンスの劣化、暴走するジョブ、アイドルクラスター、SLA 違反は高くつくからだ。管理者が過去のパフォーマンス、コスト、ワークロードの挙動を確認できるツールは、盲目的なチューニングを減らすことができる。第二に、テレメトリ自体がガバナンスとリスクのトピックである。バイヤーは、どの診断データが収集されるか、どのように編集されるか、どこに保存されるか、誰がアクセスできるか、そしてコンプライアンスルールがそのフローを許可するかを理解する必要がある。Cloudera は編集関連のトピックを文書化しているが、バイヤーはそれをポリシーに照らして検証しなければならない。

ステータス証拠は、小さいながら有用な公開チェックを追加する。Cloudera のステータスページは、2026 年 7 月 11 日時点で全システムが稼働中でインシデントは報告されておらず、Data Flow、Data Engineering、Data Warehouse、Operational Database、Cloudera AI、Data Hub、Data Catalog、Replication Manager、Observability といったリストされた Cloudera サービスが、チェックされたページでリージョン全体で稼働中と表示されていた（Cloudera ステータス）。これは一時点の公的指標に過ぎない。顧客のデプロイメントに対するサービスレベルパフォーマンスを証明するものではなく、プライベートなオンプレミスクラスターについては何も語らない。しかしこれは、Cloudera がクラウドサービスの健全性を公開しているという透明な公的シグナルであり、プラットフォームの一部が管理されたコントロールプレーンに依存する場合に関連する。

Observability は顧客の成果も証明しない。ダッシュボードは、移行後にクエリが遅くなったことを明らかにできるが、クエリを書き換えるべきか、戻すべきか、キャッシュすべきか、別の方法でパーティションすべきか、別のエンジンで実行すべきか、あるいは時代遅れの依存関係として停止すべきかを自動的に決定することはできない。コストパネルはクラスターが高価であることを示せるが、誰がチャージバックを所有するか、ないし遅延が支出に見合うかどうかを解決できない。Cloudera の価値が最も高まるのは、Observability が運用権限と結びついている場合、つまり推奨事項に基づいて行動し、リソーステンプレートを変更し、キューを調整し、クラスターを停止し、ジョブをチューニングし、アプリケーション所有者に説明責任を負わせることができるチームがいる場合である。

AI は利害を高めるが、プラットフォームを単純化しない

Cloudera はデータプラットフォームのストーリーを AI 中心に再配置してきた。これは商業的に必要である。企業は今、自らのデータ資産が、未管理のサービスに機密データをさらすことなく、検索、ファインチューニング、モデルガバナンス、推論、エージェンティックアプリケーションをサポートできるかどうかを問うている。Cloudera の Data Services ページでは、Cloudera AI がカスタム AI アプリケーションや大規模言語モデルを安全に構築・展開するのを支援でき、その AI Workbench のドキュメントは、ワークベンチがオンプレミス環境でガバナンス、モデルメトリクス、TLS、監視、管理者制御のプロビジョニングを可能にすることを示している（AI Workbench プロビジョニング）。

同社はまた、買収とパートナーシップを利用して AI ストーリーを強化してきた。2024 年 6 月、Cloudera は Verta の Operational AI プラットフォームの買収を発表し、Verta を予測 AI と生成 AI のためのモデル管理、サービング、ガバナンスの先駆者と評し、この技術が検索拡張生成アプリケーション、GenAI ワークベンチ、モデルカタログ、AI ガバナンスツールをサポートすると述べた（Verta 買収）。2024 年 10 月、Cloudera は組み込み NVIDIA NIM マイクロサービスを備えた AI Inference を発表し、プライベート展開、モデルアクセス制御、リネージ、監査、A/B テスト、カナリー展開、ハイブリッド展開オプションについて説明した（NVIDIA NIM 搭載 AI Inference）。

これらの動きは、プラットフォームの中核的テーゼ、すなわち機密データをあらゆるモデルサービスに移動させるのではなく、統制されたデータにコンピュートをもたらす、というものに合致する。また、負荷も拡大する。AI ワークロードは、GPU、モデルレジストリ、命令と検索のガバナンス、特徴品質、モデルエンドポイントアクセス、推論監視、新たなコスト変動性を追加する。テーブルポリシーとリネージの一貫性を維持することにすでに苦労しているハイブリッドデータプラットフォームは、AI が追加されたからといって単純化しない。より重大なものになるだろう。

Cloudera にとって最も強力な AI ユースケースは、一般的なチャットボット開発ではない。データローカリティ、監査、ポリシー継続性が重要となるプライベートで統制された分析とモデル運用である。銀行、公共セクター機関、保険会社、医療データ組織、通信事業者は、データサイエンスチームが統制されたデータの近くで作業しながらアクセス制御を維持できるプラットフォームを評価するかもしれない。これは Cloudera の顧客事例と一致する。OCBC 銀行の事例研究では、同行の次善の会話（Next Best Conversation）プラットフォームが機械学習を使用して顧客の会話からコンテキストデータを分析し、パーソナライズされたインサイトをモバイルチャネルを通じてプッシュしたとされ、ベンダー報告の数字として年間 2 億 5000 万件のインサイト、チャットボットがウェブサイトインタラクションの 10%を処理したとしている（OCBC 事例）。ブラジルの公共セクター技術組織である CIASC は、Cloudera に移行したことで、より整理された州のデータリポジトリが構築され、機械学習や AI のユースケースをサポートできるようになったと同社から引用されている（CIASC 事例）。

これらは独立したベンチマークではなく、顧客シグナルである。Cloudera がサービス提供を望む組織の種類と、バイヤーが主張する成果の種類を示している。Cloudera の貢献を、顧客の才能、プロフェッショナルサービス、レガシーアーキテクチャ、予算、データ品質、他のベンダーと切り離してはいない。誠実な読み方は、Cloudera が AI が統制されたエンタープライズデータに依存する場に信頼できる領域適合性を持つが、公的証拠は、クラウドネイティブ AI スタック、ウェアハウスネイティブ機械学習、オープンソース MLOps アセンブリ、または専門モデルプラットフォームに対する一般化されたパフォーマンスや ROI の優位性を証明していないということだ。

顧客証拠は規制された複雑性を指す

Cloudera の公開された顧客証拠は、規制された、または運用上複雑なデータを持つ組織に集中している。これは意味がある。なぜなら、プラットフォームの価値提案は、単純なワークロードとレガシー資産のない小規模チームにとっては特に説得力がないからだ。より興味深いバイヤーは、銀行、政府の技術運用、通信、医療データ組織、製造業、データ重力を持つ大企業である。

OCBC は、ユースケースが顧客インタラクション、機械学習、パーソナライゼーション、そしておそらく厳格な銀行の統制を組み合わせているため、有用な例である。Cloudera の事例研究では、銀行の次善の会話プラットフォームが、顧客の会話からのリアルタイムのコンテキストデータを分析し、パーソナライズされたレコメンデーションとインサイトをモバイルアプリを通じてプッシュし、年間 2 億 5000 万件のインサイトが送信され、100 件以上のパーソナライズされたナッジがあるとしている（OCBC 事例）。証拠はベンダーが厳選したものだが、統制されたハイブリッドデータプラットフォームがなぜ重要になり得るかを示している。価値は単にモデルだけではない。それは、顧客データから統制されたモデル出力、そして顧客向けアプリケーションに至る運用パスである。

CIASC は別の市場、つまり公共セクターのデータ運用を示している。Cloudera の事例研究では、サンタカタリナ情報自動化センター（Santa Catarina Informatics and Automation Center）が州全体にわたってよく組織されたデータリポジトリを望み、複雑なプラットフォームを維持するために Cloudera のサポートを重要視したとされている（CIASC 事例）。「複雑なプラットフォーム」という言葉を見逃してはならない。それは Cloudera の理由であると同時にリスクでもある。公共セクターのデータは、しばしば所在地、プライバシー、調達、スタッフの制約を伴う。サポートされたプラットフォームは統合リスクを減らすかもしれない。しかし、サポートが日常的な進展に不可欠であるならば、バイヤーはその依存を偶発的なものとして扱うのではなく、予算化すべきだ。

クルンシー銀行のケースは、商業的により強力であると同時により注意を要する。Cloudera は、同行がそのテクノロジーとプロフェッショナルサービスを導入して、セルフサービス BI と不正検出のための統一データレイクハウスを作成し、プロフェッショナルサービスによって最適化された領域で 5 倍のパフォーマンス改善を達成したと述べている（クルンシー銀行事例）。パフォーマンスに関する主張は注目に値するが、文言が重要である。改善は、プロフェッショナルサービスによって最適化された領域に関連付けられており、再現可能なセットアップ、ワークロードの組み合わせ、ベースライン、または独立した検証を伴う公開ベンチマークではない。バイヤーは、専門家によるチューニングが実質的な利益をもたらしうる証拠として読むべきであり、すべての Cloudera デプロイメントがその結果を見るとの証明ではない。

これらの事例研究は狭い結論を支持する。Cloudera は、データがあまりに重要、分散、規制されている、または歴史的に絡み合っているため、カジュアルに単一の新しいサービスに移行できない組織を対象としている。それは、プラットフォームが自動的に優れていることを意味しない。それは、営業会話がガバナンスの労働、移行の労働、監査リスクのコストから始まるべきことを意味する。それらが高いなら、Cloudera には生きた議論がある。バイヤーのデータ資産がすでにほとんど単一のクラウドウェアハウスにあり、ポリシーがより単純で、チームがオンプレミス継続性をほとんど必要としていないなら、Cloudera の広範さはオーバーヘッドに見えるかもしれない。

代替案は単に安いかより現代的というだけではない

Cloudera はいくつかの代替パターンと競合する。一つはクラウドデータウェアハウスであり、Snowflake、BigQuery、Redshift、Synapse などの類似サービスがインフラ作業を吸収し、ビジネスユーザーに馴染みのある SQL レイヤーを提供する。もう一つはクラウドレイクハウスまたは統合分析プラットフォームで、Databricks などが Spark、テーブルフォーマット、ノートブック、データエンジニアリング、機械学習、ガバナンスを組み合わせる。もう一つは、Apache Iceberg、Spark、Trino、Flink、Airflow、Ranger、Atlas、Kubernetes、そしてバイヤーが選んだカタログを使用したオープンソースアセンブリである。もう一つは、既存の Cloudera 資産を単純に拡張しながら、ワークロードを選択的にクラウドに移動させることだ。

クラウドネイティブウェアハウスにとっての最も強力な論拠は、焦点である。ビジネスアナリストが理解しなければならないシステムの数を減らし、インフラの信頼性をプロバイダーに移すことが出来る。多くのワークロードにとって、それが正しい答えである。弱点はデータ重力とガバナンスの変換である。機密データをオンプレミスや特定の法域に置いておく必要がある場合、多くのジョブがすでに HDFS や Ozone に対して実行されている場合、またはバイヤーがオープンテーブルに対して複数のエンジンを望む場合、単一のウェアハウスは別のコピーレイヤーになり得る。

クラウドレイクハウスプラットフォームにとっての最も強力な論拠は、開発者の速度である。Spark、ノートブック、ML ツーリング、レイクハウステーブル管理は、データエンジニアリングと AI チームを生産的にできる。弱点は同様に、クラウド依存性、ガバナンスの変換、より古い資産の移行である。Cloudera の差別化要因は、Spark やノートブックを持っていることではない。それは、より古い Hadoop 由来の資産、プライベートクラウド要件、規制されたガバナンスが依然として存在する企業に、もっともらしく応えることができる点である。

オープンソースアセンブリにとっての最も強力な論拠は、管理である。高度なプラットフォームチームは、Apache Iceberg、Spark、Trino、Ranger、Atlas または別のカタログおよびガバナンスシステム、Airflow、Kubernetes、クラウドオブジェクトストレージを中心にスタックを構築できる。弱点はサポートと統合の労働である。特に、経営陣がプラットフォームに対して責任を負うベンダーを求める場合、Cloudera の価値はサポートされたディストリビューションと管理レイヤーである。しかし、そのベンダーの説明責任には、ライセンスコスト、サポート対象バージョンの制約、Cloudera のロードマップへの依存が伴う。

現状のままにとどまることの最も強力な論拠は、リスク軽減である。レガシーワークロードが安定しており、ビジネスが即時のモダナイゼーションを要求しない場合、全体的な移行は漸進的な改善よりも危険であり得る。弱点はゆっくりとした衰退である。セキュリティパッチ適用、スキルの老朽化、サポートされていないバージョン、低い弾力性、新しい AI やデータ共有の要件をサポートできないこと。Cloudera の現在のポートフォリオは、プライベートクラウドデータサービス、Iceberg 移行パス、クラウドワークロードクラスターを提供することで、漸進的なモダナイゼーションを立派なものにしようと試みている。それは理にかなっているが、それでもなお、どのワークロードがモダナイゼーションに値し、どれを廃止すべきかの厳しい棚卸しを要求する。

したがって、バイヤーのロックイン分析は、「オープン対プロプライエタリ」よりも正確でなければならない。Cloudera はオープンソースエンジンと Iceberg に依存することで一部のロックインを減らすが、ガバナンス、管理、サポート、移行手順を自社プラットフォーム内に集中化することで他のロックインを増やす。クラウドウェアハウスは、運用労働を減らしながら、ストレージとクエリエンジンのロックインを増やすかもしれない。オープンソーススタックは、ベンダーロックインを減らす一方で、アーキテクチャが少数のエンジニアの頭の中に存在するため、スタッフロックインを増やす可能性がある。最良の選択は、どの依存性が組織にとって最も危険でないかに依存する。

コミット前にテストすべき障害モード

Cloudera にとっての運用リスクは理論的ではない。メタデータのドリフトが第一である。テーブルが移動したが、カタログ、分類、所有者、リネージ、またはポリシーラベルが遅れている場合、ユーザーは誤ったデータを信頼したり、管理者が誤ったアクセスを許可したりする可能性がある。Cloudera の Data Catalog と SDX のドキュメントはメタデータとガバナンスのためのツールを示しているが、ツールは運用規律を保証しない。

権限の不一致が第二である。Ranger ポリシー、LDAP グループ、Kerberos レルム、サービスアカウント、クラウド IAM ロール、Kubernetes 名前空間、およびウェアハウス許可は分岐し得る。Cloudera の Ranger および Kerberos レプリケーションのドキュメントは、同社がこの領域を理解していることを示しているが、バイヤーはクリーンなデモではなく、独自の最も奇妙なポリシーをテストする必要がある。取り消されたユーザー、緊急アクセス、継承されたグループメンバーシップ、列レベルの例外は、ハッピーパスの読み取りアクセスよりも優れたテストである。

ジョブ移行の失敗が第三である。Spark ジョブは、ファイルパス、ライブラリバージョン、キュー名、シークレットの場所、スケジューラーの動作、またはデータローカリティを前提としている可能性がある。Cloudera Data Engineering は、CLI ベースのジョブ作成、更新、リソース、Airflow ジョブ、セッション、シークレット、Spark サブミットを文書化している（CDE CLI ドキュメント）。この運用面は有用だが、移行には依然としてコードと依存性のレビューが必要である。

クエリパフォーマンスの退化が第四である。調整済みの Impala または Hive 環境から別のエンジン、テーブルフォーマット、またはストレージレイヤーに移動すると、一部のワークロードが改善し、他のワークロードが劣化する可能性がある。Observability は劣化を特定でき、Iceberg は一部のレイクハウスパターンを改善できるが、いずれもベンチマーク作業を排除しない。バイヤーは、代表的な BI ダッシュボード、重いジョイン、コンパクションの多いテーブル、増分インジェスト、現実的な認可ルール下での同時実行性をテストすべきである。

ストレージコストの驚きが第五である。オブジェクトストレージは単位当たりでは安価だが、複製、保持、小さなファイル、スナップショット、マニフェスト、コンパクションアーティファクト、クロスリージョントラフィックが蓄積するとそうではない。Cloudera の価格設定はインフラとネットワーキングのコストを除外しており、Lakehouse Optimizer のドキュメントはテーブルメンテナンスが継続的に必要であることを示唆している。バイヤーはソフトウェアの項目ではなく、総コストをモデル化すべきである。

サポートされていないコネクターとアップグレードの破損が第六と第七である。ハイブリッドプラットフォームは、オブジェクトストア、ID プロバイダー、BI ツール、モデルレジストリ、データサイエンス環境、ストリーミングシステム、サードパーティエンジンといったコネクターの上に成り立っている。単一のサポートされていないコネクターが、標準的な移行をビスポークなプロジェクトに変え得る。リリースノートとサポートマトリクスは、販売後の資料としてではなく、調達文書として扱われなければならない。

ガバナンスの迂回が第八である。ユーザーが SDX 外の別のエンジンを通じてコピーされたデータをクエリできる場合、または開発チームがより速く動くために未管理のデータセットを作成する場合、プラットフォームのポリシー継続性の主張は弱まる。Cloudera の Iceberg REST および Snowflake 統合の発表は、セキュリティとリネージを維持しながらサードパーティのアクセスをサポートする取り組みを示している。バイヤーは、その環境で施行がどのように機能するかを自分で検証する必要がある。

サービス依存が第九である。プロフェッショナルサービスは移行とチューニングを加速できるが、反復されない複雑性を隠蔽することもある。バイヤーは、どの手順が内部のランブックになり、どれが製品によって自動化され、どれが Cloudera のサポートを必要とし、どれが次のアップグレードで再び外部の助けを必要とするかを問うべきである。

評決: Cloudera はガバナンスと移行への賭けである

Cloudera の最良の論拠はノスタルジーではない。それは、分散、規制、またはレガシーの重いデータ資産を持つ企業が、すべてのワークロードを単一のパブリッククラウドサービスに強制したり、すべてのプラットフォームチームを完全なオープンソーススタックの自己サポートに追い込んだりしない、統制されたモダナイゼーションパスを必要としているということだ。公的証拠は、アーキテクチャレベルでその論拠を支持している。SDX はポリシーとメタデータをプラットフォームに結びつける。Data Hub はクラウドワークロードクラスターを統制データレイクに接続する。プライベートデータサービスは、ウェアハウス、AI、カタログ、レプリケーション、データエンジニアリングの機能をオンプレミスにもたらす。Replication Manager は、実際の HDFS、Hive、Ranger、Iceberg、Ozone、Kerberos の移行に関する懸念に対処する。Observability は、ワークロード、クラスター、パフォーマンス、コストのシグナルを露出させる。Iceberg は、レイクハウスのストーリーにオープンテーブルフォーマットの基盤を与える。

同じ証拠が限界も設定する。Cloudera は、バージョン、セキュリティレルム、テーブルタイプ、コンパクション、メタデータレプリケーションの状況、サポートマトリクス、インフラサイジング、クラウドコストを理解する必要性を取り除かない。いくつかの重要なパスは境界付き、テクニカルプレビュー、または明示的に制限されている。顧客事例研究は規制された複雑な組織への適合を示しているが、管理された比較を提供していない。公的財務証拠は、同社が非公開であるため古い。ベンダーの規模と ROI の主張は方向的には有用かもしれないが、バイヤーのテストの代替とはならない。

それにより、明確な購入ルールが生まれる。Cloudera は、バイヤーが真のハイブリッド制約を持つ場合に、真剣な評価に値する。つまり、データをデータセンターや特定の法域にとどめなければならないこと、相当な Hadoop 由来のワークロード、複数の分析・AI エンジン、共通のアクセスポリシーとリネージの必要性、そして反復パターンが標準化できる移行プログラムがある場合だ。バイヤーがクラウドネイティブなウェアハウスやレイクハウスにクリーンに移行でき、そのプロバイダーのコントロールプレーンを受け入れ、プライベートな分散データ基盤の維持を回避できる場合には、あまり魅力的ではない。

最終的なテストは労働である。Cloudera が、ワークロードが移動する際にポリシー、リネージ、リカバリ、コスト可視性を維持する人的作業を削減するなら、プレミアムを正当化できる。単に同じ統合負担をより広範な製品名の背後にパッケージ化するだけなら、より安価またはより焦点を絞った代替手段が勝利するだろう。同社は、Hadoop が生き残ったかどうかではなく、統制されたハイブリッドデータ作業が、テーブル、ジョブ、モデルが環境境界を越えるたびに、カスタムサービスプロジェクトのように感じられるのをやめるほど、反復可能になるかどうかによって判断されるべきである。