仮想ビューよりも高速な応答時間を実現するために、スケジュールまたはオンデマンドで更新される物理テーブルとして、事前計算されたクエリー結果を格納するデータベースオブジェクト
によって Databricks Staff による投稿
マテリアライズドビューは、クエリーの結果を物理テーブルとして格納するデータベースオブジェクトです。仮想的であり、基になるテーブルからデータを導出する通常のデータベースビューとは異なり、マテリアライズドビューには、スケジュールに従って、またはオンデマンドで増分更新される事前計算されたデータが含まれています。このデータの事前計算により、特定のシナリオでクエリー応答時間が短縮され、パフォーマンスが向上します。
マテリアライズドビューは、複雑なクエリや集計が頻繁に実行され、かつ基になるデータの変更が少ない状況で特に役立ちます。事前計算された結果を保存することで、データベースは複雑なクエリーを繰り返し実行する必要がなくなり、応答時間が短縮されます。
「データマテリアライゼーション」と「マテリアライズドビュー」という用語は関連していますが、これらは異なる概念を指します。では、この文脈において「マテリアライズド」とは何を意味するのでしょうか。
データマテリアライゼーションとは、コンピュートされたデータをハードディスクなどの物理的な媒体に保存するという概念です。これは通常、パフォーマンスの向上という 1 つの主要な目的のために、仮想ビューまたは論理ビューから作成され ます。
いくつかの点で、データマテリアライゼーションはキャッシングに似ています。どちらのプロセスも、より効率的に取得できる方法でデータを格納することを含みます。両者の主な違いは、キャッシングは使用場所の近くにデータを一時的に格納するために使用されるのに対し、マテリアライズドデータはより長いライフサイクルと、より明確に定義された更新スケジュールを持つ傾向があることです。
このデータ実体化の定義を用いて、それが マテリアライズドビュー の概念とどのように関連しているかを探っていきましょう。
マテリアライズドビューは、リレーショナルデータベースでクエリーの結果を格納して高速に取得するために使用される、データマテリアライゼーションの一種です。
データウェアハウスの環境でマテリアライゼーションを使用するのは、主に利便性のためです。データが格納される際、その格納方法の選択は、一般的にデータが最初にどのようにフォーマットされているかに従います。しかし、データを読み取りたい場合、その選択は簡単な取得に適していない可能性があります。
たとえば、大規模なデータセットがあり、そこからデータのサブセットを定期的に読み取る必要があるとします。ほんの一部にアクセスしたいだけなのに、毎回データセット全体に対してクエリーを実行しなければならないため、その都度新たに取得するのは比較的時間のかかる作業になる可能性があります。
この状況では、マテリアライズドビューを作成する とメリットがあります。読み取る必要のあるデータが事前に投入されるようにセットアップし、自動的に、またはシステムが基になるソースデータの変更を検出したときに更新が行われるように更新スケジュールを定義します。
この時点で「ビュー」を定義し、マテリアライズドビューとの違いを説明することが有益です。ビューとマテリアライズドビューはどちらも、特定の形式で、または特定のクエリの結果としてデータを提示するデータベースオブジェクトです。しかし、ストレージ、パフォーマンス、ユースケースの点で大きく異なります (これについては後ほど詳しく説明します)。
ビューとマテリアライズドビューを比較する際の重要な考慮事項は、ビューが SQL クエリーの結果セットに基づく仮想テーブルであるということです。重要なのは、ビュー自体はデータを保存せず、クエリーが実行されるたびに、基になるテーブルから動的にデータを取得することです。
これは、マテリアライズド ビューとは根本的に異なります。「マテリアライズド」をどのように定義するかの重要な要素は、データ ストレージの観点にあります。具体的には、マテリアライズドビューは、クエリーから得られたデータ結果を物理的に保存するデータベース オブジェクトです。
つまり、マテリアライズドビューは通常のビューとは異なり、動的にデータを取得しません。クエリ結果セットを保存し、基になるテーブルの変更を反映するために定期的に更新さ れるため、クエリのパフォーマンスが向上し、処理リソースをより効率的に使用できます。
ストレージがビューとマテリアライズドビューの主な違いと見なせますが、以下の表では、この違いが2つのデータベースオブジェクトの各機能にどのように影響するかを比較しています。
| 特徴量 | 表示する | マテリアライズドビュー |
|---|---|---|
| データストレージ | データを保存しない (仮想テーブル) | データを物理的に格納します(事前計算された結果) |
| データ取得 | ベーステーブルからデータを動的に取得します | 保存された結果からデータを取得します |
| 性能 | 複雑なクエリーでは低速 | 複雑なクエリーでは高速 |
| データの鮮度 | 常に最新 | 古くなる可能性があり、更新が必要 |
| ストレージ容量 | 追加のストレージは不要 | 追加のストレージ領域が必要 |
| ユースケース | 複雑なクエリーの簡素化、セキュリティ | パフォーマンスの向上、スナップショットデータ |
マテリアライズドビューにはいくつかの利点がありますが、Databricks Platform を含むデータベースでは多くの制限もあります。メリットとデメリットを十分に理解することで、ユーザーはいつ、どのように効果的に使用するかを判断できます。
マテリアライズドビューを作成する主な理由の1つは、クエリーのパフォーマンスを向上させることです。これは、データ取得の高速化とベース テーブルの負荷軽減という 2 つの重要な方法で実現されます。
事前計算された結果を保存するため、毎回データを再コンピュートしてクエリ (またはクエリ内の結合) を解決する必要がなくなります。その結果、特に複雑でリソースを大量に消費するクエリや、アクセス頻度の高いクエリの実行が大幅に高速化されます。
この方法でデータを保存すると、ベース テーブルへの直接クエリーの数も削減されます。これにより、これらのテーブルへの負荷が最小限に抑えられ、データベースのパフォーマンスが全体的に向上します。
特定のデー タセットにアクセスする必要があるたびに、常に完全なクエリを実行したいわけではありません。そうすることは特に遅く、非効率的になる可能性があります。結果を事前計算して保存することで、マテリアライズドビューはリソース使用量を最適化し、反復的な計算とデータ処理の必要性を最小限に抑え、時間とコストを節約します。
マテリアライズドビューは、特定の時点におけるデータのスナップショットを提供します。これは、レポート作成やアナリティクス、またヒストリカルデータ分析の目的で、データセットの変化を追跡する必要がある場合に役立ちます。
ETL プロセス中など、さまざまなソースからデータをまとめる必要がある場合、マテリアライズドビューは優れた選択肢です。これらを使用して、複数のテーブルやデータベースからデータを集計および統合し、統合データにアクセスするための簡単で統一された効率的な方法を提供できます。
複雑な集計、結合、計算はすべて、マテリアライズドビューで事前に計算して保存できます。これも、マテリアライズドビューが高い計算コストを削減し、データのクエリーと分析をより迅速かつ容易にする方法の1つです。
マテリアライズドビューの欠点の1つは、事前計算され たデータを維持するために追加のストレージ容量が必要になることです。データストレージソリューション、ビューのサイズ、更新の頻度によっては、この追加のストレージ要件が無視できない費用を生む可能性があります。
マテリアライズドビューは静的なスナップショットを提供するため、基になるデータの変更に合わせて最新のビューが表示されるように、増分更新を行う必要があります。これは定期的に実行することも、マテリアライズドビューの更新頻度をトリガーする特定のイベントを割り当てることもできます。いずれにせよ、更新の実行頻度を定めた戦略を採用し、データの鮮度を保証するためにデータを計算するロジックとリソースを割り当てる必要があります。
残念ながら、マテリアライズドビューを更新するプロセスは、データベースの全体的なパフォーマンスに影響を与える可能性があります。これは、更新がリソースを大量に消費する場合や、他のデータベース操作と競合する場合に特に顕著になります。
マテリアライズド ビューは、ビューが頻繁にアクセスされる場合や、データ ウェアハウジングのように読み取りパフォーマンスが重要な場合に非常に役立ちます。しかし、すべてのタイプのクエリーやユースケースに適しているわけではありません。たとえば、リアルタイムデータ更新を必要とするタスクや、基になるデータの変更頻度が高いシステムは、マテリアライズドビューでは最適に機能しない場合があります。
では、ビューとマテリアライズドビューというデータベースオブジェクトの違いや、ビューを使用するメリットを理解した上で、代わりにマテリアライズドビューを作成すべき適切なタイミングはいつでしょうか?ここでは、マテリアライズドビューを使用することでデータへのアクセスプロセスをより効率的にできる状況をいくつか紹介します。
バッチ処理を定期的に実行する必要がある場合、マテリアライズドビューを使用すると、独立して処理されるクエリーの一部を事前計算して格納することで、これを実現できます。たとえば、週次の給与計算を管理している場合、マテリアライズドビューを使用して、さまざまな従業員の給与、税金、手数料などの給与明細の詳細を格納できます。マテリアライズドビューに格納されたデータは、各週末に更新されます。
マテリアライズドビューを使用すると、リモート ソースからデータを複製およびキャッシュできるため、特定のデータセットを複数の場所で利用できるようにする問題を解決するのに役立ちます。これにより、データを多数の異なるストレージ サイトにコピーして配布し、ソース データベースの全体的な負荷を軽減できるため、読み取り専用データベースに特に役立ちます。データへのアクセスが必要なユーザーは、最も近いサイトを使用できるため、応答時間も短縮されます。
AI/BIダッシュボードは、Databricks Data Intelligence Platform上でデータの可視化とレポート作成を強化するための効果的なツールです。シンプルなデザインは可視化の共有と配布に最適ですが、パブリックダッシュボード内のデータが鮮度の要件を満たしていることが重要です。
マテリアライズドビューを使用すると、定期的な更新をスケジュールして最新のビューを確保し、ダッシュボードを動かすクエリー結果を事前計算して格納することで、エンドユーザーの応答時間を大幅に改善できます。
マテリアライズドビューの主な利点の1つは、データのスナップショットを提供することです。これにより、基になるデータセットが時間の経過とともにどのように変化したかを調査することがはるかに簡単になり、レポート作成に役立つヒストリカルデータのスナップショットが提供されます。
したがって、マテリアライズドビューは、幅広いビジネスインテリジェンスアプリケーションに適したソリューションです。スタースキーマクエリーを完了したり、生データから集計をコンピュートしたりする必要がある場合、マテリアライズドビューは、月次平均、週次合計、日次カウントなどの事前に集計されたサマリーを格納します。これらの数値を時系列で視覚化することは、履歴分析やレポート作成の目的にとって有益です。
基になるデータベースから切断されるリスクがあることを認識している場合は、マテリアライズド ビューを使用して、作業に利用できる最も重要なデータを保持できます。もちろん、その状況では、更新スケジュールが堅牢であることを確認するために、特に注意する必要があります。この場合、マテリアライズド ビューをローカルにキャッシュできます。
マテリアライズドビューの使用が最適な選択肢ではないシナリオがいくつかあることに注意してください。1つには、データに対するクエリーが迅速かつ簡単である場合、その手間をかける価値はあまりありません。さらに、ソースデータが非常に速く変更される場合、マテリアライズドビューを使用する意味はほとんどありません。むしろ、継続的なデータ更新による処理オーバーヘッドの増大が、データ検索の高速化によって得られるあらゆる利点を上回る可能性が高いでしょう。
Databricks SQL のマテリアライズドビューは、Unity Catalog を介して管理されます。これらは、ソーステーブルの最新データに基づいて事前計算された結果を保存します。従来の実装とは異なり、Databricks のマテリアライズドビューは、クエリーが実行されるたびに更新されるのではなく、最終更新時のデータ状態を保持します。マテリアライズドビューを手動で更新したり、スケジュールされた自動更新を設定したりする柔軟性があります。
Databricks SQLのマテリアライズドビューは、ETL (抽出, 変換, ロード) 処理に特に役立 ちます。これらは、コンプライアンス、修正、集計、チェンジデータキャプチャ (CDC) を処理するための、シンプルで宣言的なアプローチを提供します。マテリアライズドビューは、低速なクエリーや頻繁に使用される計算を事前計算することで、クエリーのレイテンシを大幅に改善し、コストを削減します。さらに、ベーステーブルをクレンジング、エンリッチ、非正規化することで、シームレスな変換を可能にします。場合によっては、マテリアライズドビューはベーステーブルからの変更を増分コンピュートできるため、コストが削減され、ユーザーエクスペリエンスが合理化されます。
Databricks は、Spark宣言型パイプライン のリリースに伴い、lakehouseアーキテクチャの一部として初めてマテリアライズドビューを導入しました。DB SQL SQL warehouseでマテリアライズドビューを作成すると、ビューの更新を管理するためのLakeFlow Pipelinesが自動的に作成されます。Lakeflow UI、API、または CLI を使用して、更新操作のステータスを簡単に監視できます。
次の例では、マテリアライズドビュー customer_orders を、ベーステーブル orders と 顧客: から作成します
Databricks SQL では、事前に定義されたスケジュールに基づいてマテリアライズドビューの自動更新を設定するオプションがあります。このスケジュールは、マテリアライズドビューの作成時に SCHEDULE 句を使用して構成するか、後で ALTER VIEW ステートメントを使用して追加できます。スケジュールが確立されると、更新を処理するための Databricks ジョブが自動的に作成されます。
スケジュールの詳細をいつでも確認するには、DESCRIBE EXTENDED ステートメントを使用します。これにより、マテリアライズドビューに設定されたスケジュールが可視化されます。これにより、Databricks SQL でマテリアライズドビューの自動更新スケジュールを簡単に監視および管理できます。
マテリアライズドビューの詳細については、Databricks 製品ドキュメントを参照するか、紹介ブログをお読みください。
ブログを購読して、最新の投稿を受信トレイにお届けします。