データレイクハウスとは？
データレイクとは？
データウェアハウスとは？
データレイクハウスとデータウェアハウスの違いは何ですか？
データレイクハウスとデータレイクの違いは何ですか？
データアナリストは容易にデータレイクハウスを利用できますか？
データレイクハウスとデータウェアハウスの価格性能の比較を教えてください。
データレイクハウスはどのようなデータガバナンス機能をサポートしていますか？
データレイクハウスは一元化する必要がありますか？それともデータメッシュに分散できますか？
データメッシュとデータレイクハウスとの関係は？
データレイクハウスとは、データレイクに格納された膨大なデータに対して、効率的かつセキュアに人工知能（AI）やビジネスインテリジェンス（BI）を直接実行できるアーキテクチャです。
現在、企業ではデータの大部分をデータレイクに格納しています。 データレイクは、あらゆる種類のデータ（構造化、非構造化を問わない）を管理し、どんな処理ツールでも実行できるオープンなインターフェースを備えた低コストのストレージシステムです。データレイクでは、組織のデータセットを活用するために、大部分のデータ変換や高度な分析ワークロード（AI など）が実行されます。これとは別に、ビジネスインテリジェンス（BI）のユースケースでは、独自のデータウェアハウスシステムが、構造化されたデータのより小規模のサブセットに対して使用されます。これらのデータウェアハウスは主に BI をサポートしており、SQL を使用して過去の分析的な問いに答えています（例：前四半期の収益はいくらだったか）。一方、データレイクはより膨大なデータを保存し、予測分析や AI を含む、 SQL と非 SQL の両方のインターフェースを使用した分析をサポートしています（例：どの顧客が解約しそうか、顧客にどのタイミングでどのようなクーポンを提供すべきか）。歴史的には、AI と BI の両方を実現するには、データのコピーを複数持ち、データレイクやデータウェアハウス間でデータを移動させる必要がありました。
データレイクハウスは、あらゆるデータをデータレイクに一旦格納し、そのデータに対して直接 AI や BI を実行することを可能にします。例えば、データレイク上で BI を高速に動作させる SQL と パフォーマンス機能（インデックス、キャッシュ、MPP 処理）など、大規模なスケールで、企業のあらゆるデータを使用した AI と BI の両方を効率的に実現するための具体的なケイパビリティを備えています。また、SQL ベースのデータウェアハウスを強制的に経由させることなく、ファイルへの直接アクセスや、Python やデータサイエンス、AI フレームワークを直接ネイティブにサポートしています。データレイクハウスを実現するための主要なテクノロジーは、Delta Lake、Hudi、Iceberg などのオープンソースです。データレイクハウスに注力しているベンダーには、Databricks、AWS、Dremio、Starburst などがあり、データウェアハウスを提供するベンダーには、Teradata、Snowflake、Oracle などがあります。
データウェアハウスの父と呼ばれているビル・インモン（Bill Inmon）氏は、最近、データレイクハウスへの進化に関するブログ記事で、データレイクのデータサイエンスへの焦点とデータウェアハウスのエンドユーザー分析を組み合わせてオープンな環境でデータを管理する、レイクハウスのユニークな機能について説明しています。
データレイクとは、表データ、テキスト、画像、音声、動画、JSON、CSV など、あらゆるデータタイプを格納できる、低コストでオープンかつ耐久性のあるストレージシステムです。クラウドでは、AWS S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage（GCS）など、主要なクラウドプロバイダがデータレイクを活用、推進しており、多くの組織では、データの大半をクラウドのデータレイクに格納しています。そして、Apache Parquet や ORC など、標準化されたオープンなフォーマットでデータを格納するようになりました。その結果、多くのツールやアプリケーションのエコシステムが、これらのオープンデータフォーマットを直接扱うことができるようになっています。データをオープンなフォーマットかつ抵コストで格納できるこのアプローチにより、組織では、ベンダーロックインを回避しながら膨大なデータをデータレイクに蓄積できるようになりました。しかし、このようなメリットがある一方で、データレイクには、セキュリティ、品質、性能という 3 つの主要な問題があります。データレイクは、あらゆるデータをファイルとして格納・管理するため、ファイルの内容に対するきめ細やかなアクセス制御ができません。できるのは、誰がどのファイルやディレクトリにアクセス可能かという粗いアクセス制御のみです。素早くアクセスできるようにフォーマットは最適化されておらず、クエリは低性能で、ファイルのリストアップには高いコンピューティングコストがかかります。要するに、アプリケーションがノイズ（機械学習など）を許容できる場合を除き、組織がデータを活用するには、データを別のシステムに移動する必要があります。データレイクに取り込まれるデータ量が増大化する中、データの破損を防ぎ、スキーマの変更を管理することが困難なため、品質にも問題が生じています。また、ファイル群の書き込み時のアトミック操作を確保するのは難しく、変更をロールバックする仕組みもありません。結果的に、ほとんどのデータレイクはデータスワンプ（沼地）になっていると言われています。そのため、多くの組織では、データのサブセットをこの 3 つの問題がないデータウェアハウスに移動させています。しかし、データウェアハウスには、また別の問題があります。
データウェアハウスとは、構造化および半構造化（主に JSON 形式）データのみを格納・管理し、SQL ベースの分析やビジネスインテリジェンスを実現するために構築された独自のシステムです。最も価値のあるビジネスデータは、キュレートされ、データウェアハウスにアップロードされます。データウェアハウスは、高性能、同時実行性、信頼性に最適化されていますが、データレイクのような安価なアクセス料金ではなく、効果なSQL料金が必要になるため、データ処理のコストは高くなります。歴史的には、データウェアハウスは容量に制約があり、ETL や BI のクエリを同時に行うことはできず、リアルタイムストリーミングは不可能でした。データウェアハウスは、構造化データを主な対象として構築されているため、画像、センサーデータ、文書、動画などの非構造化データには対応していません。また、機械学習のサポートも限られており、一般的な TensorFlow や PyTorch 、その他の Python ベースのオープンソースのライブラリやツールを直接ネイティブにサポートできません。その結果、多くの組織では、データレイクはデータセットの格納に利用し、データウェアハウスにサブセットを移動させて、高速な BI や SQL を並行して利用しているのが実情です。
レイクハウスは、既存のデータレイクの上に構築されます。データレイクには通常、企業内のデータの 90% 以上が格納されています。ほとんどのデータウェアハウスは、そのデータにアクセスするための「外部 テーブル」機能をサポートしていますが、厳しい機能の制限（例：読み取り操作のみサポート）や性能の制限があります。一方、レイクハウスは、 ACID トランザクション、きめ細かなデータセキュリティ、低コストの更新・削除、ファーストクラスの SQL サポート、SQL クエリ性能の最適化、BI スタイルのレポートなど、従来のデータウェアハウス機能を既存のデータレイクに追加します。データレイク上に構築することで、テーブルの構造化データに加えて、テキスト、音声、動画など、あらゆる種類のデータを含む既存データを、レイクハウスがデータレイクに格納・管理します。また、レイクハウスは、データウェアハウスとは異なり、オープン API を使用してデータへの直接アクセスを提供し、さまざまなな機械学習や、PyTorch、Tensorflow、XGBoost などの Python/R ライブラリをサポートすることで、データサイエンスや機械学習のユースケースをネイティブにサポートします。このように、レイクハウスは、BI や AI などのさまざまな分析をサポートしながら、企業のあらゆるデータを管理する単一のシステムを提供します。
一方、データウェアハウスは、構造化データや特定の半構造化データに対する SQL ベースの分析に特化して構築された独自のデータシステムです。データウェアハウスでは、機械学習のサポートが限られており、最初にデータをエクスポート（ODBC/JDBC 経由またはデータレイクへのエクスポート）しなければ、一般的なオープンソースツールをネイティブに実行できません。また、現在、どのデータウェアハウスシステムも、データレイクに格納されている既存の音声、画像、動画データをネイティブにサポートしていません。
データレイクに関してよくある不満は、データスワンプ（データの沼地）になってしまうことです。データレイクには誰もがデータを投じることができ、レイク内のデータには構造もガバナンスは存在しません。性能を考慮してデータが整理されていないため、低性能で、データレイクでの分析には限界があります。その結果、多くの企業は、低コストのオブジェクトストレージを使用するデータレイクをデータの大部分のランディングゾーンとして使用し、そのデータを別のデータウェアハウスなどのダウンストリームシステムに移動させて価値を抽出しています。
レイクハウスは、データレイクがスワンプ化する根本的な要因を解決します。ACID トランザクションによって、データの読み取りや書き込みを複数のユーザーが同時に実行する場合でも一貫性が保たれます。スター／スノーフレークスキーマなどのデータウェアハウススキーマのアーキテクチャをサポートし、データレイク上で直接、堅固なガバナンスと監査のメカニズムを提供します。キャッシュ、多次元クラスタリング、データスキップなどのさまざまな最適化手法を実現し、ファイル統計とデータの圧縮を活用して、ファイルサイズを適切し、高速な分析を可能にします。また、データガバナンスには、きめ細かなセキュリティと監査機能が提供されています。オープンデータレイクにデータ管理やパフォーマンスの最適化を加えることで、レイクハウスによる BI や機械学習アプリケーションのネイティブなサポートが実現します。
データレイクハウスシステムは、従来のデータウェアハウスと同じ SQL インターフェースを実装しています。そのため、アナリストはワークフローを変更することなく、既存の BI ツールや SQL ツールでデータレイクハウスに接続可能です。例えば、Tableau、PowerBI、Qlik、Looker などの主要な BI 製品は、全てデータレイクハウスシステムに接続でき、Fivetran や dbt などのデータエンジニアリングツールを実行できます。アナリストは、Microsoft Excel などのデスクトップツールにデータをエクスポートできます。レイクハウスは、ANSI SQL やきめ細かなアクセス制御、ACID トランザクションをサポートしているため、管理者は、組織内のあらゆるデータを単一のシステムで、データウェアハウスシステムと同様に管理できます。
シンプルさという点でのレイクハウスシステムの重要な利点は、組織内のあらゆるデータを管理するため、データアナリストは、データウェアハウスにロードされたデータのサブセットのみではなく、着信する未加工データや履歴データにアクセス可能になることです。そのためアナリストは、データベース管理者やデータエンジニアに適切なデータのロードを依頼しなくても、複数の過去のデータセットに対して質問をしたり、新たなデータセットを扱うための新しいパイプラインを確立することが容易にできます。また、AI へのサポートが組み込まれていることで、アナリストは、機械学習チームが構築した AI モデ ルをあらゆるデータに容易に使用して実行できます。
データレイクハウスシステムは、運用コストの最小化とパフォーマンスの最大化を実現のために、分離され、柔軟なスケーラビリティのあるコンピューティングとストレージを中心に構築されています。最近のシステムでは、エンジン内部で同じ最適化技術（クエリのコンパイルやストレージレイアウトの最適化など）を使用し、SQL ワークロードに対して従来のデータウェアハウスと同等以上のコスト性能を実現しています。さらに、レイクハウスのシステムでは、スポットインスタンスの価格設定（クエリ中にワーカーノードを失うことをシステムが許容する必要がある）や、アクセス頻度の低いストレージに対する割引価格など、クラウドプロバイダが提供しているコスト削減につながる方法を活用することがよくあります。これは、従来のデータウェアハウスエンジンではサポートされていませんでした。
データレイクのストレージに管理インターフェースを追加することで、レイクハウスシステムは、データウェアハウスと同様の標準的なインターフェースを使用して、組織の全てのデータに対するアクセス制御、データ品質、コンプライアンスを一元管理できます。最新のレイクハウスシステムは、SQL によるきめ細かな（行、列、ビューレベルの）アクセス制御、クエリ監査、属性ベースのアクセス制御、データのバージョニング、データ品質の制約とモニタリングをサポートしています。これらの機能は通常、既存の担当者が組織内のあらゆるデータを一元的に管理できるように、データベース管理者に馴染みのある標準的なインターフェース（例えば、SQL GRANT コマンド）を使って提供されます。また、単一の管理インターフェースを持つレイクハウスシステムにあらゆるデータを一元化することで、複数の別々のシステムを管理する際に生じる管理負担やエラーの可能性を軽減できます。
組織は、単一のレイクハウスに全てのデータを集約する必要はありません。レイクハウスアーキテクチャを採用している多くの組織では、分散型のアプローチをデータの格納、処理に、一元化されたアプローチをセキュリティやガバナンス、探索に採用しています。組織の構造やビジネスニーズに応じた、一般的なアプローチをいくつかご紹介します。
The unified nature of the Lakehouse architecture enables data architects to build simpler data architectures that align with the business needs without complex orchestration of data movement across siloed data stacks for BI and ML. Furthermore, the openness of the Lakehouse architecture enables organizations to leverage the growing ecosystem of open technologies without fear of lock-in to addressing the unique needs of the different business units or functional areas. Because Lakehouse systems are usually built on separated, scalable cloud storage, it is also simple and efficient to let multiple teams access each lakehouse. Recently, ローンチされた Delta Sharing は、多くのベンダーからのサポートを得て、レイクハウス間でデータを共有するオープンで標準的なメカニズムを提案しています。
データメッシュのクリエータである Zhamak Dehghani 氏は、データメッシュを導入する際に必要となる 4 つの基本的な組織原則を示しています。データレイクハウスのアーキテクチャを利用して、これらの組織原則を実現できます。
