Microsoft Fabric Lakehouse と Warehouse:どちらのストレージ エンジンを選ぶべきか?
By Mirko Peters ·
Microsoft Fabric の Lakehouse と Warehouse を比較します。エンタープライズ分析アーキテクチャで、Spark を使う Lakehouse と T-SQL を使う Warehouse をいつ選ぶべきかを解説します。
Automatically translated with AI from the original post. Read the English original
![Cover: Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]](https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/bfbd20ad8a411469d5aad58275f070a5.jpg)
Microsoft Fabric の Lakehouse と Microsoft Fabric の Warehouse のどちらを選ぶかは、データ チームにとって最も重要なアーキテクチャ上の決定の一つです。本ガイドでは、構造化データと非構造化データの扱いの違い、T-SQL と PySpark の実行エンジンの違い、タイム トラベル機能、コンピューティングの分離について解説し、最適な分析戦略の設計を支援します。
重要なポイント
- Lakehouse は、構造化データと非構造化データの両方を扱え、Apache Spark によってネイティブに管理されます。
- Warehouse は構造化データに特化しており、使い慣れた高性能な T-SQL のクエリ エクスペリエンスを提供します。
- どちらのストレージ タイプも内部ではオープンな Delta 形式を使用するため、データの不要な物理的コピーを作成する必要がありません。
- Lakehouse は監査向けに優れたタイム トラベルの保持期間を提供しますが、Warehouse は履歴データの保持を定義された日数の範囲内で管理します。
- SQL 開発とデータ サイエンスのどちらに強いかなど、チームの既存のスキル セットが、プラットフォームの選択に大きく影響するはずです。
Fabric ストレージの基盤を理解する
Lakehouse と Warehouse の比較に入る前に、Microsoft Fabric が何を解決しようとしているのかを理解しておくと役立ちます。従来のデータ分析アーキテクチャでは、組織は生データの処理用のデータ レイクと、ビジネス インテリジェンス用のデータ ウェアハウスのどちらかを選ぶ必要がありました。この分離により、データの重複、サイロ化されたガバナンス、ストレージとコンピューティングのコスト増大が必然的に生じていました。Microsoft Fabric は、OneLake と呼ばれる共通の基盤のもとで、これらのパラダイムを統合します。
OneLake の内部では、組織はさまざまな分析ワークロードをプロビジョニングできます。ただし、構造化された表形式データについては、Lakehouse も Warehouse も標準化された Delta Parquet 形式でデータを格納します。つまり、どちらのエンジンを選んでも、基盤となるデータ形式はオープンでアクセス可能なままであり、Fabric エコシステム全体で相互運用できます。
Lakehouse のアーキテクチャとユース ケース
Microsoft Fabric の Lakehouse エクスペリエンスは、データ レイクの長所とデータ ウェアハウスの信頼性を兼ね備えています。画像、PDF、ログ、CSV などの構造化ファイルと非構造化ファイルの両方を扱えるように設計されており、最新のデータ エンジニアリング パイプラインの自然な拠点となります。
主要なエンジンとしての Spark
Lakehouse では、Apache Spark が主要な処理エンジンです。データ担当者は PySpark、Spark SQL、Scala のノートブックを使って、大規模な分散データ変換を実行します。膨大なデータセット、複雑な機械学習ワークロード、ストリーミング データを扱う組織にとって、Lakehouse は比類のない柔軟性を提供します。
高度なタイム トラベルと柔軟性
Lakehouse は Delta テーブル上に構築されているため、タイム トラベルなどの機能をネイティブにサポートします。組織はデータの過去の状態をクエリしたり、誤った更新をロールバックしたり、事実上無制限の履歴期間を保持したりできます。このレベルの細かな制御は、時間の経過に伴うデータの変化を詳細に把握する必要があるデータ エンジニアリング チームにとって非常に価値があります。
Warehouse のアーキテクチャとユース ケース
一方、Microsoft Fabric Warehouseは、構造化データとリレーショナルモデリングのために特別に設計されています。長年にわたり従来のSQL Serverエンタープライズデータウェアハウスを利用してきた組織であれば、Warehouseのエクスペリエンスは、使い慣れた高度に最適化されたT-SQL環境を提供します。
最優先で扱われるT-SQL
Sparkがデータのライフサイクルを管理するLakehouseとは異なり、WarehouseではT-SQLが中心に据えられています。データベース管理者、SQL開発者、従来のBIアナリストは、PySparkを学んだりノートブック環境を管理したりすることなく、標準的なストアドプロシージャ、ビュー、複雑な結合を記述できます。そのため、既存のSQLスキルを持つチームにとって導入の障壁が大幅に下がります。
予測可能なパフォーマンスと管理
Warehouseは基盤となるクラスター管理を抽象化し、分析クエリに最適化されたトランザクションデータベースのエクスペリエンスを提供します。設定可能な上限(120日など)までタイムトラベルがサポートされていますが、主な目的は、セマンティックモデルやPower BIレポートにスムーズにデータを供給する、高性能なリレーショナルクエリ機能の提供です。
アーキテクチャ上の適切な選択
Microsoft Fabric環境を設計する際、必ずしも1つだけを選ぶ必要はありません。成熟したアーキテクチャの多くは、BronzeレイヤーとSilverレイヤーの変換にLakehouseを使用し、Sparkで未加工のファイルを取り込んでデータをクレンジングします。一方で、Goldレイヤーでは、最終的な高度に構造化されたディメンションモデルをビジネスユーザーに提供するためにWarehouseを活用しています。
ソースデータの種類、チームの中核となるエンジニアリングスキル、ワークロードの負荷を評価してください。業界の専門家とともに、これらのエンドツーエンドのアーキテクチャ上の検討事項をさらに掘り下げたい場合は、エピソード全編をお聴きください。MVPがどのように最新のエンタープライズデータプラットフォームを構築しているかが分かります。
よくある質問
T-SQLを使用して Microsoft Fabric Lakehouseのデータにアクセスできますか?
はい。すべての Microsoft Fabric Lakehouseには既定のSQLエンドポイントが自動的にプロビジョニングされるため、Sparkノートブックと並行して、標準のT-SQLを使用してDeltaテーブルにクエリを実行できます。
LakehouseとWarehouseの間でデータを移動する際、物理的なコピーを作成する必要はありますか?
いいえ。どちらのストレージエンジンもOneLake上でDelta テーブル形式を使用しているため、物理ファイルを複製することなく、ショートカットを作成したり、相互にクロスクエリしたりできます。
機械学習ワークロードには、どちらのストレージエンジンが適していますか?
一般的に、機械学習や高度なデータサイエンスには Lakehouseが推奨されます。Apache Spark、Pythonライブラリ、非構造化ファイルストレージとネイティブに統合されているためです。
SQL開発者は Microsoft Fabric Warehouseで PySparkを使用できますか?
はい。ただし制限があります。Sparkを使用してWarehouseに接続することはできますが、基盤となるエンジンは引き続きT-SQLで管理されるため、Sparkネイティブの一部の操作では、特定のSynapseライブラリが必要になる場合があります。