オープンレイクハウスとは？オープンデータ標準について解説します。

オープンレイクハウスとは、すべてのレイヤー（ストレージ、テーブルフォーマット、エンジン、カタログ、およびその上のMLやAIのツール）がオープンスタンダードに基づいて構築されており、どのレイヤーも特定のベンダーに固定（ロックイン）されないデータレイクハウスのことです。

データレイクハウスは、データレイクの低コストで拡張性の高いストレージと、データウェアハウスの管理機能およびトランザクション保証を組み合わせたものです。オープンレイクハウスはさらに、アーキテクチャのすべてのレイヤーがオープンスタンダードに基づいて構築されているという条件が加わります。データ、それを処理するエンジン、それをガバナンスするカタログ、そしてその上でモデルやアプリケーションを構築するツールはすべてオープンソースであるため、特定のベンダーに依存することはありません。

「オープン」という言葉はよく使われますが、必ずしも実態を伴っているとは限りません。だからこそ、その定義を明確にすることに価値があります。あるフォーマットがオープンと呼ばれていても、実際には1つのエンジンでしか実用的に使えない場合があります。カタログがオープンと呼ばれていても、特定のプラットフォームに依存している場合もあります。ストレージは、データ転送（エグレス）料金によって移動コストが高くなる直前まではポータブルな状態を維持できます。オープンレイクハウスとは、こうした制約がすべてのレベルで取り除かれた状態を指します。最近では、このオープン性が、データ上で構築されるAIやエージェントのワークロードにも広がっています。

オープンレイクハウスは、データレイクやデータウェアハウスとどう違うのですか？

オープンレイクハウスは、データウェアハウスの信頼性とデータレイクの低コストなストレージを1つのアーキテクチャに統合し、さらに他の2つにはない「すべてのレイヤーがオープンで互換性（入れ替え可能性）を持たなければならない」というルールを追加したものです。データウェアハウスは、レポート作成用にクリーンで構造化されたテーブルを保持し、強力なガバナンスを提供しますが、コストが高く、非構造化データを扱う余地はほとんどありません。データレイクは、生ファイル、ログ、画像など、それ以外のすべてのデータを低コストかつ大規模に保持しますが、トランザクションやスキーマの保証、十分なガバナンスはありません。

レイクハウスは突然現れたわけではありません。長年、チームは2つのシステムを並行して運用し、システム間でデータをコピーし、2つの「真実のバージョン」を整合させていました。データレイクハウスはこれらを統合し、低コストなレイクストレージにウェアハウス型の管理とトランザクションを直接適用しました。オープンレイクハウスは、そのアイデアをさらに一歩進めたものです。統合されたアーキテクチャを維持しつつ、上記のルールを追加することで、どのレイヤーも特定のベンダーに縛られることなく、ウェアハウスの信頼性とレイクの経済性を実現します。

オープンレイクハウスとプロプライエタリ（独自の）レイクハウス：何が違うのですか？

オープンレイクハウスとプロプライエタリなレイクハウスの違いは、「誰がデータを読み取ることができ、どのエンジンがその上で動作できるか」という1つの問いに行き着きます。プロプライエタリなレイクハウスは、特定のベンダーしか読み取れないフォーマットでデータを保存するため、ツールの切り替え時にすべてのデータを書き直したり再エクスポートしたりする必要があります。オープンレイクハウスは、互換性のあるエンジンならどれでも読み取れるオープンフォーマットでデータを保存するため、データを書き直すことなく、クエリエンジンを追加、交換、または削除できます。

何がレイクハウスを「オープン」にするのですか？

オープンレイクハウスとプロプライエタリなレイクハウスを分けるのは、オープンフォーマット、オープンエンジン、そして統合されたガバナンスの3つです。

まずはオープンフォーマットです。データは、Apache Parquet®のようなオープンなファイルフォーマット上にある、Delta LakeやApache Iceberg®といったオープンなテーブルフォーマットに保存されます。仕様は公開されているため、特定のベンダーのランタイムだけでなく、それらを実装しているすべてのエンジンがデータを読み書きできます。

次にオープンエンジンです。処理を行うシステムもオープンソースです。Apache Spark®は、バッチ、ストリーミング、SQL、機械学習を1つのランタイムでカバーしており、その下にあるテーブルがオープンであるため、DuckDB、Trino、PyIcebergなどのエンジンが、データを複製することなく同じデータに対して動作できます。

統合されたガバナンスは、多くのチームが見落としがちな部分です。1つのカタログが、すべてのフォーマットとすべてのエンジンに対するアクセス制御、リネージ、監査を処理するため、データに触れるツールごとにガバナンスを再構築するのではなく、データ自体にガバナンスを紐付けることができます。ここではUnity Catalogがその役割を果たします。

これらを組み合わせることで、最下層のオブジェクトストレージから、その上のオープンなテーブルフォーマット、オープンな処理エンジン、ガバナンスのためのオープンなカタログ、そして最上層のアナリティクス、機械学習、AIアプリケーション向けのオープンなツールに至るまで、ストレージレイヤーからサービングレイヤーまでが完全にオープンになります。

「オープン」は「オープンソース」と同じですか？

厳密には異なりますが、その違いは重要です。オープンソースは、プロジェクトのコードに対するライセンスを指します。レイクハウスにおける「オープン」はより広く、オープンなファイルやテーブルのフォーマット、オープンなAPI、ツールが接続するための標準的な方法、そして多くのエンジンが同じデータ上で動作するエコシステムをカバーしています。プラットフォームがオープンソースプロジェクトから構築されていても、例えば独自のエンジンしかうまく読み取れないレイアウトでデータを保存するなどして、データを囲い込む（トラップする）ことは可能です。オープン性に対する真のテストはシンプルです。互換性のある任意のツールでデータを読み取ることができ、データを書き直すことなくツール間を移動できるかどうかです。

オープンテーブルフォーマットとオープンレイクハウス：何が違うのですか？

これら2つの用語は混同して使われがちですが、区別する必要があります。オープンテーブルフォーマットは1つのレイヤーであり、オブジェクトストレージ内のファイルの上に、データベースのような機能（信頼性の高い更新、スキーマ変更、履歴）を追加します。オープンレイクハウスは、そのレイヤーを取り巻くすべて、つまりその下のストレージや、その上のコンピュート、カタログ、ガバナンスを指します。テーブルフォーマットはコンポーネント（構成要素）であり、レイクハウスはスタック全体です。

表の中の2つの用語について説明します。ACIDとは、テーブルを破損することなくデータの変更が確実に完了することを意味し、タイムトラベルとは、過去の時点におけるデータの状態を表示または復元できることを意味します。

オープンレイクハウスを支えるオープンスタンダードは何ですか？

このリファレンスアーキテクチャは、5つのオープンソーススタンダードから構築されており、それぞれが中立的な財団（Apache Software FoundationまたはLinux Foundation）によって管理され、スタックの異なるレイヤーを担っています。オープンレイクハウスの信頼性は、それを構成するプロジェクトの信頼性に依存します。これらはニッチなプロジェクトではなく、業界の多くがすでに採用している標準規格であり、そのほとんどがDatabricksで作成されました。これは自慢話ではなく、事実として確認できます。2026年初頭の時点で、Apache SparkはFortune 500の約80%で使用されており、大規模データ処理用として最も広く採用されているエンジンです。MLflowは月間3,000万回以上のダウンロードを記録しています。Delta LakeとApache Icebergは、本番環境におけるレイクハウステーブルの大部分をカバーしており、Delta Lakeは最大の導入実績（インストールベース）を誇っています。

これらを合わせると、GitHubのスター数は9万を超え、月間ダウンロード数は数千万回に達します。各プロジェクトの現状の概要は以下の通りです（GitHubのスター数は2026年初頭時点）：

Apache Spark

Apache Spark®は処理エンジンです。2009年にカリフォルニア大学バークレー校のAMPLabで、後にDatabricksを共同設立するチームによって開発され、Apache Software Foundationに寄贈されました。その後、大規模データ処理において最も広く使用されるエンジンの1つとなりました。1つのSparkランタイムでバッチジョブ、ストリーミング、SQL、機械学習を処理できるため、ワークロードの種類ごとに異なるシステムを管理する代わりに、単一のエンジンを運用するだけで済みます。レイクハウスにおいて、Sparkは生データを読み込み、段階的に精製し、その結果をオープンテーブルとして書き戻します。

Delta Lake

Delta Lakeは、オブジェクトストレージを単なるファイルの集まりではなく、データベースのように動作させるテーブルフォーマットです。通常のParquetファイル上で、ACIDトランザクション、スキーマ強制、タイムトラベル機能を提供します。これにより、同時実行されるジョブが互いの書き込みを破損することがなくなり、過去の特定の時点におけるテーブルの状態に対してクエリを実行できます。関連ライブラリであるDelta Kernelは、読み書きのロジックをエンジンに依存しないコンポーネントにパッケージ化しており、Spark以外のエンジンでもこのフォーマットを容易にサポートできるようにします。Delta LakeはDatabricksで開発され、現在もDatabricksが主要なコントリビューターであり、Linux Foundationプロジェクトとして管理されています。

Apache Iceberg

Icebergは、非常に大規模な分析テーブル向けに構築され、エンジン間をスムーズに移行できるように設計された、2つ目のテーブルフォーマットです。DatabricksではなくNetflixから誕生し、現在は広く採用されているApacheプロジェクトとなっています。Databricksは主要なコントリビューターであり、Tabularの買収によって加わったIcebergの創設チームも含まれています。そのテーブル仕様とRESTカタログにより、複数のエンジンで同じテーブルを簡単に共有できるため、複数のクエリエンジンが稼働する環境で広く利用されています。Delta LakeとIcebergの両方をサポートすることで、チームは初日からどちらか一方のフォーマットに縛られ、その選択を永遠に維持し続ける必要がなくなります。

Unity Catalog

Unity Catalogはガバナンスレイヤーです。アクセス制御ポリシー、認証情報の払い出し、リネージを1か所で管理し、エンジンはデータを直接バイパスするのではなく、Unity Catalogを介してデータにアクセスします。ルールは特定のエンジン内ではなくカタログ内に存在するため、クエリがSpark、DuckDB、またはその他のクライアントのいずれから送信されても、アクセス制御とリネージの一貫性が保たれます。Unity CatalogはDatabricksで開発され、現在はLF AI & Data Foundation傘下のオープンソースプロジェクトとなっており、Databricks上でマネージドバージョンが提供されています。オープンソース版はマネージド製品よりも新しく、一部のガバナンス機能はまだ発展途上であるため、要件に適合するかどうかオープンプロジェクトを確認することをお勧めします。

Unity Catalogは唯一のオープンカタログではありません。Apache Polaris、Project Nessie、Hive Metastore、AWS Glueも同様の役割を果たしており、Iceberg RESTカタログはこれらを横断する共通インターフェースとして台頭しています。オープンレイクハウスでは、これらいずれも使用可能です。このリファレンスアーキテクチャでは、データ、ML、AI資産を1つのモデルの下で統合管理できるためUnity Catalogを使用していますが、カタログレイヤーは完全に差し替え可能です。

MLflow

MLflowは機械学習とAIのためのレイヤーです。実験の追跡、モデルのパッケージング、モデルレジストリ、評価、サービングを処理し、その同じ仕組みが現在ではAIエージェントにも適用されています。エージェントの行動のトレース、評価器による出力のスコアリング、予算制限やガードレールを備えたゲートウェイの前面配置などが可能です。モデルやエージェントを、別個の独立したスタックではなく、データを管理するのと同じオープンプラットフォーム上で実行することが、このバージョンのレイクハウスの大きな特徴です。MLflowはDatabricksで開発され、現在もDatabricksが主要なコントリビューターであり、Linux Foundationプロジェクトです。

オープンレイクハウスの各レイヤーはどのように連携しますか？

各レイヤーはオープンなインターフェースを介して接続されているため、独自の接着剤（プロプライエタリな仕組み）なしで適合し、他のレイヤーに影響を与えることなく、どのレイヤーでも差し替えることができます。これにより、5つのプロジェクトが1つのアーキテクチャへと統合されます。

まずはデータから始めましょう。Sparkは、Delta LakeまたはIcebergとしてオブジェクトストレージにテーブルを書き込みます。これらのフォーマットはオープンであり、Delta KernelとIceberg RESTカタログが中立的な方法で公開しているため、他のエンジンも同じファイルを直接読み込むことができます。事前にプロプライエタリなストレージにコピーする必要はなく、出力時のエクスポート手順も不要です。

ガバナンスはそのすべてを横断して機能します。すべてのエンジンがUnity Catalogを介してデータにアクセスするため、一度作成したポリシーがすべての場所で適用されます。新しいクエリエンジンを導入する際は、カタログを指定するだけでよく、アクセスルールやリネージをゼロから再作成する必要はありません。

モデルとエージェントは、同じ管理されたデータを利用します。MLflowでトレーニングされたモデルは、Sparkが生成したGoldテーブルを読み込みます。質問に回答するエージェントは、人間のアナリストと同じポリシーの下で、Unity Catalogを介してクエリを実行します。生の入力からデプロイされたモデル、またはエージェントの回答に至るまでのリネージが途中で記録されます。AIレイヤーは最後にとって付けたものではありません。他のすべての要素と同様に、同じ管理されたインターフェースを介して読み書きを行います。

実用上のメリットは、レイヤー間の独立性です。各レイヤーは隣接するレイヤーのオープンインターフェースにのみ依存しているため、チームは上下のレイヤーを再構築することなく、処理エンジンの変更、クエリエンジンの追加、2つ目のテーブルフォーマットの採用、または異なるモデルフレームワークへの差し替えを行うことができます。

オープンレイクハウスのメリットは何ですか？

オープンレイクハウスの主なメリットは、選択肢の広さ（オプショナリティ）です。特定のベンダーにロックインされるレイヤーがないため、データやAIのニーズの成長に合わせて、チームは常に選択肢を確保できます。具体的なメリットは以下の通りです。

• ロックインの排除：オープンフォーマットにより、データの移行や書き換えを行うことなく、ツールを変更できます。
• コストの削減：安価なストレージにデータを1つ保存するだけで済むため、システム間でのデータの重複を回避できます。
• マルチエンジン：BI、SQL、機械学習において、同じデータに対して複数のエンジンを実行できます。
• 統合ガバナンス：単一のカタログにより、一貫したアクセス制御とリネージが適用されます。
• AI対応：信頼性の高い統合データにより、モデルトレーニング、フィーチャストア、AIエージェントをサポートします。
• クラウドの自由度：再構築することなく、複数のクラウド間でワークロードを実行できます。

成長に合わせてオープンレイクハウスはどのようにスケールしますか？

オープンレイクハウスは、プラットフォームを再構築するのではなく、レイヤーを追加することでスケールします。業務の必要性に応じてレイヤーを有効化し、後から追加するレイヤーが導入されても、既存のレイヤーはそのまま維持されます。2人のチームから複数地域に展開する大企業まで、同じ構成が適合します。違いは、有効化されているレイヤーの数だけです。

• 基本的なETL。オブジェクトストレージ、Deltaテーブル、およびSpark。生データはBronzeに格納され、クレンジングされてSilverになり、Goldから提供されます。このメダリオン構成は、それ自体で完全なオープンスタックとなります。
• ストリーミングとバッチの統合。データが到着すると同時に処理する必要がある場合、Spark Structured Streamingとリアルタイムモード（Real-Time Mode）により、同じエンジン上でバッチと並行してストリーミングを実行でき、Spark Declarative Pipelinesが変換処理を記述します。別のストリーミングシステムを用意する必要はありません。
• 共有カタログと最初のエージェント。 アナリスト、アプリケーション、ダッシュボード、機械学習のすべてが同じデータを必要とするようになると、Unity Catalogはそれらが読み取る共通のガバナンスレイヤーになります。通常、最初のエージェントもここに登場し、データの品質監視、パイプラインのドラフト作成、リネージの探索などを行います。これらはすべて、他のコンシューマーと同様にカタログを通じてガバナンスが適用されます。
• エンタープライズスケール。 リージョンやクラウドをまたいで、Unity Catalogは認証情報の自動発行（credential vending）、きめ細かなポリシー、Lakehouse Federation、およびDelta Sharingを追加し、SparkはKubernetes上のマネージドフリートとして実行されます。基盤は同じですが、より強力なガバナンスとより多くのコンピュートリソースが提供されます。

オープンなレイクハウスにAIはどのように適合するのか？

オープンなレイクハウスでは、AIアプリケーションやエージェントは、後から付け足された個別のシステムではなく、他のデータコンシューマーとまったく同じようにガバナンスが適用されるファーストクラスのワークロードです。ほとんどのレイクハウスの説明はビジネスインテリジェンスや機械学習で終わっており、今となってはAIの箱を横に貼り付けた2021年の図のように見えます。エージェントを、同じデータのガバナンス対象コンシューマーとして扱うことこそが、このバージョンを真に現代的なものにしている理由です。

MLflowはデータを管理するプラットフォーム上で実行されるため、エージェントも他のすべてのユーザーと同じルールに従います。Unity Catalogを介して読み取るため、権限で許可されたデータのみを表示できます。エージェントのアクティビティは追跡され、その回答はモデルの品質が追跡されるのと同じ方法でMLflowの評価器によってスコアリングされます。また、その手前にあるゲートウェイによって、支出の制限やガードレールの適用が可能です。これらはいずれも、独自のデータコピーと脆弱なガバナンスを持つ個別のAIスタックを必要としません（通常はそれが代替案となります）。

具体的には以下の通りです。

• 帰属（Attribution）： エージェントは独自のアイデンティティとして実行されるため、すべてのアクションは共有アカウントの背後に隠されることなく、特定のプリンシパルに追跡されます。
• スコープ限定の認証情報： カタログは、有効期限の長いキーの代わりに、有効期限が短く範囲が限定された認証情報を発行するため、エージェントのアクセスを他のユーザーと同様に制限および取り消すことができます。
• リネージ： エージェントの読み取りと書き込みが記録されるため、ソースデータから検索を経て回答に至るまでの経路を監査のために再構築できます。
• 支出とガードレール： 予算制限とコンテンツ管理は、エージェント自身のコードの外部であるゲートウェイに配置されます。
• 障害モード： アクセスはカタログを経由するため、カタログが利用できない場合の動作（ガバナンスのない直接読み取りにフォールバックするのではなく、アクセスを拒否するなど）を明示的に設計できます。

エージェントのアイデンティティは、独自のサービスプリンシパルにすることも、エージェントを呼び出したユーザーの委任（代理実行モデル）にすることもでき、その選択によって監査ログでのアクションの表示方法が決まります。また、後述するスタンドアロンのMLflowパスを使用すると、レイクハウスがなくてもトレースと評価を行えますが、上記のカタログによるアクセス制御は、Unity Catalogが導入されて初めて適用されます。

実際、これは非常に具体的です。エージェントが権限のない列を要求すると、Unity Catalogは読み取りを拒否し、監査ログにエージェントのアイデンティティ、要求されたテーブルと列、時間、および拒否の決定が記録されます。許可されたクエリについては、リネージによって回答が読み取り元の特定のGoldテーブルにリンクされます。

重要なのは、エージェントがアーキテクチャの他の部分を置き換えるということではありません。アーキテクチャに組み込まれるということです。エージェントは、ガバナンスが適用されたデータのもう1つのコンシューマーであり、周囲のパイプラインやモデルと同じオープンツールを使用して構築および監視されます。

本当にオープンなレイクハウスが必要ですか？

常に必要とは限りません。オープンなレイクハウスは、オープン性とスケールが価値を発揮する場合には最適な選択肢ですが、そうでない場合は過剰（オーバースペック）になります。多くのデータ型、同じデータを共有する複数のチームやエンジン、マルチクラウドの要件、またはベンダーロックインを回避するという明確な目標がある場合に非常に適しています。シンプルな構造化データを使用し、ツール間を移動する必要がない、単一ツールによる小規模なワークロードには過剰かもしれません。

実用的なアプローチとしては、完全な移行を決断する前に、既存のソースを1つフェデレーションする、あるいはパイプラインを1つ移行するなど、実際の要件に関連付けられたスコープ限定のパイロットから始めることです。このアーキテクチャは1つのレイヤーずつ導入できるように構築されているため、「すべて導入するか、まったく導入しないか」の二者択一ではありません。

オープンなレイクハウスへ段階的に移行することはできますか？

はい。オープンなレイクハウスは、既存のスタックを最初に解体することを求めるのではなく、すでに実行しているものの隣に1レイヤーずつ適合するように設計されています。何もない状態から始めるチームはほとんどありません。大半はすでにクラウドデータウェアハウス、EMR、データカタログ、または半分完了したIcebergへの移行を実行しています。

• 既存のクラウドデータウェアハウスの場合： Unity Catalogを通じてフェデレーションすることで、ガバナンスとリネージを適用し、データは元の場所に残します。
• EMR Sparkの場合： パイプライン作成レイヤーのみをSpark Declarative Pipelinesに移行し、すでに実行しているクラスターはそのまま維持します。
• 別のカタログの場合： Unity Catalogからオープンなリネージイベントを発行し、既存のカタログにそれを取り込ませることで、両方を並行して動作させます。
• Icebergへの移行が途中の場合： すでにセットアップされているカタログの上にUnity Catalogを配置し、それ以外は何も変更しません。

移行手順は毎回同じです。1つのレイヤーをオープンなバージョンに置き換え、変更する理由が生じるまで残りの部分はそのままにしておきます。

オープンなレイクハウスで本当に難しいことは何ですか？

オープンなレイクハウスには実際に厄介な部分があり、率直に説明する必要があります。オープンなテーブルフォーマットは小さなファイルが蓄積されるため、定期的なコンパクション（最適化）とメンテナンスが必要です。複数のエンジンから同時に同じテーブルに書き込む機能は、読み取り機能ほど成熟していないため、マルチエンジンでの書き込みには注意が必要です。一部のコンポーネントのオープンソース版は、マネージド版に比べていくつかの機能で遅れをとっています。また、スタック全体をセルフホストすることは、実際の運用作業を伴います。フォーマットレイヤーやカタログレイヤーにおけるオープン性も、あらゆる形態のロックインを排除するわけではありません。マネージドランタイム、独自のクエリアクセラレータ、コンピュート料金などは、プラットフォームが依然としてユーザーを囲い込む部分であり、オープンレイヤーとは別に評価する価値があります。これらはどれも、このアーキテクチャを否定するものではありません。すべてのレイヤーを所有することに伴う、率直なコストです。

オープンなレイクハウスを自分で運用するにはどうすればよいですか？

すべてのレイヤーがオープンソースであるため、全体を自分で実行できます。各レイヤーをまとめて立ち上げるオープンなリファレンス実装があります。

これにより、Apache Spark、Apache Kafka®、Apache Airflow®、Apache Iceberg、Delta Lake、Unity Catalog、MLflowがDocker環境下でローカルに起動し、クラウドへのデプロイ構成も含まれています。最初に必要なのがAIレイヤーだけであれば、MLflow単体から始めることができます。pip installと既存のアプリケーション内の数行のコードだけで十分であり、残りは後から追加できます。

たとえば、下層にレイクハウスがない既存のエージェントにMLflowを向けることができます。

LangGraphやOpenAIのエージェントは変更なしで実行され、そのトレース、プロンプト、ツール呼び出しがMLflowに表示されます。Postgres、ベクトルストア、モデルプロバイダーはそのまま維持されます。エージェントがガバナンスの適用されたエンタープライズデータを必要とする場合にのみ、その下層にガバナンスが適用されたレイクハウスを追加します。

リファレンスリポジトリはApache 2.0ライセンスで提供され、Databricksの開発者リレーションズチームによってメンテナンスされています。これは新しい技術ではありません。スタック全体を1か所にまとめたいときのために、上記の5つの実績あるプロジェクトをDockerで連携させたものです。各レイヤーは独立して動作することもできます。このバンドルは利便性を提供するものであり、依存関係ではありません。オープンなレイクハウスを自分で運用することは現実的ですが、実際の作業を伴います。リポジトリもそのように扱っており、高可用性パターン、デプロイ構成、オブザーバビリティ（可観測性）を提供しているため、セルフホストは単なる主張ではなく、サポートされた手段となっています。

オープンなレイクハウスはあなたの役割をどのように変えますか？

• SQLまたはdbtを作成する場合： Spark Declarative Pipelinesは、dbtでおなじみの宣言型かつSQLファーストの作成環境を提供します。さらに、単一のエンジン上でバッチ処理と並行してストリーミング、完全なSQL、Pythonを追加し、これらすべてを、既存のBIツールから引き続きクエリ可能なガバナンス適用済みのオープンテーブルに対して実行できます。
• データパイプラインを構築する場合： たとえばSpark Declarative Pipelinesを使用してパイプラインを一度作成すれば、単一のエンジンでバッチ処理とストリーミングを実行できます。
• モデルやエージェントを構築する場合： 他のすべてのユーザーと同じアクセスルールの下で、同じガバナンス適用済みデータに対して、MLflowで構築、評価、サービングを行います。
• プラットフォームを自社で運用する場合：ビジネスの成長に合わせてレイヤーを追加でき、他の部分を再構築することなく、任意のレイヤーを個別に置き換えることができます。

オープンなレイクハウスをサポートしているプラットフォームは？

現在、いくつかのプラットフォームがオープンなレイクハウスの原則を採用しています。Databricks、Snowflake、Google Cloud、Microsoft Fabric、Cloudera、Dremio、Starburst、Qlikはすべて、この分野で製品を提供しています。これらはオープンなレイクハウスの思想に基づいて構築された製品であり、アーキテクチャそのものではありません。また、各レイヤーが実際にどの程度オープンであるかは製品によって異なります。

Databricksはレイクハウスというカテゴリを創出し、ストレージにDelta LakeとApache Icebergを、ガバナンスにUnity Catalogを使用することで、オープンな基盤上でデータウェアハウス（DWH）クラスのパフォーマンスを提供します。Databricks Platformは、自社でスタックを運用することを望まないチーム向けに、これをマネージドサービスとして提供しています。

よくある質問

オープンレイクハウスはデータレイクハウスと同じですか？

データレイクハウスとは、レイクストレージ上でDWHスタイルの管理を行うアーキテクチャのことです。オープンレイクハウスとは、すべてのレイヤー（ストレージ、テーブルフォーマット、エンジン、カタログ、およびその上のMLやAIツール）がオープンソースであり、相互に交換可能であるデータレイクハウスを指します。そのため、特定のベンダーに依存するレイヤーはありません。

IcebergとDelta Lakeのどちらを使うべきですか？

どちらもACIDトランザクション、スキーマエボリューション、タイムトラベルを備えたオープンなテーブルフォーマットであり、オープンレイクハウスでは一方または両方を使用できます。Delta LakeはSparkと親和性が高く、Delta Kernelを介して他のエンジンからも読み取りやすくなっています。一方、IcebergはRESTカタログを介して幅広いマルチエンジンアクセスができるように設計されています。両方をサポートしているため、最初からどちらか一方に決める必要はありません。

オープンレイクハウスを構築するには、5つのプロジェクトすべてが必要ですか？

いいえ。このアーキテクチャは成長させることを前提としています。基本的なオープンレイクハウスは、オブジェクトストレージ、テーブルフォーマット、そしてSparkだけで構成されます。多くの利用者にわたるガバナンスや、機械学習やAIのワークロードが必要になった段階で、Unity CatalogとMLflowを追加します。

Databricksなしでオープンレイクハウスを運用できますか？

はい。すべてのレイヤーがオープンソースであり、自社のインフラストラクチャ上で動作します。リファレンス実装では、Dockerを使用してローカルでフルスタックを起動できます。また、機械学習レイヤーは、1回のpip installだけで単独で使用することも可能です。Databricksはこれらのオープンコンポーネントのマネージド版を提供していますが、セルフホストもサポートされている方法の1つです。

AIエージェントはオープンレイクハウスのどこに位置づけられますか？

エージェントは、個別のシステムではなく、ガバナンスが適用されたデータのコンシューマー（利用者）として扱われます。エージェントは、人間や他のエンジンと同じポリシーのもとでUnity Catalogを介してデータを読み取ります。また、モデルと並行してMLflow内で構築、トレース、評価されるため、AIレイヤーを後付けにするのではなく、同じオープンで統制されたアーキテクチャ内に維持できます。

オープンレイクハウスのコストはどのくらいですか？

オープンソースコンポーネントは、Apache 2.0およびLinux Foundationライセンスのもとで無料で使用できます。発生するコストは、オブジェクトストレージ、実行するコンピューティング、およびスタックを維持するための運用コストです。自社で運用する場合はライセンスコストをエンジニアリング時間と引き換えることになり、Databricksのようなマネージドプラットフォームを利用する場合は、同じオープンな基盤上で、エンジニアリング時間をサブスクリプション費用と引き換えることになります。

オープンレイクハウスは本番環境に対応していますか？

はい。5つの主要プロジェクトは成熟した標準技術であり、すでに大規模な本番環境で稼働しています。たとえば、Apache SparkはFortune 500の約80%で採用されており、MLflowは月間3,000万回以上ダウンロードされています。本番環境における主な考慮事項は運用面です。テーブルのメンテナンスやコンパクション、マルチエンジンによる書き込みへの配慮、マネージドサービスを使用しない場合のセルフホスト作業などが挙げられます。

Apache、Apache Spark、Apache Iceberg、Apache Kafka、Apache Airflow、Apache Parquet、およびApache featherロゴは、米国およびその他の国におけるApache Software Foundationの登録商標または商標です。Delta Lake、MLflow、およびUnity Catalogは、LF Projects, LLCの商標です。その他すべての商標は、それぞれの所有者に帰属します。

実際に動作を確認するには、リファレンスアーキテクチャをクローンし、github.com/open-lakehouse/open-lakehouse でエンドツーエンドで実行してください。AI側から始める場合は、MLflow単体から始めるのが良いエントリーポイントになります。モデルやエージェントにガバナンスの効いたデータが必要になった段階で、残りのスタックを導入できます。完全なマネージドサービスをお望みですか？同じオープンな基盤が、Databricks lakehouse platformを支えています。

リファレンスアーキテクチャを見る

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事