マテリアライズドビューの再計算処理の最適化

マテリアライズドビューのインクリメンタル計算の最適化

デジタルネイティブ企業はAIがイノベーション推進において重要な役割を果たすことを認識していますが、多くの企業がETLパイプラインの運用効率化において課題を抱えています。

マテリアライズドビュー（MV）は、管理されたテーブルとして事前に計算されたクエリ結果を保存するために存在し、ユーザーが同じクエリの繰り返し計算を避けることで、複雑または頻繁に使用されるデータに、はるかに高速にアクセスできます。MVはクエリのパフォーマンスを向上させ、計算コストを削減し、変換プロセスを簡素化します。

Lakeflow Declarative Pipelines（LDP）は、データパイプラインの構築に直感的で宣言的なアプローチを提供し、MVのフルリフレッシュとインクリメンタルリフレッシュの両方をサポートします。Databricksのパイプラインは、Enzymeエンジンによって動作しており、新しいデータがクエリ結果にどのように影響するかを追跡し、必要な部分だけを更新することで効率的にMVを最新の状態に保ちます。内部コストモデルを利用して、マテリアライズドビューや一般的に使用される手動ETLパターンで採用されている技術など、さまざまな手法の中から最適なものを選択します。

このブログでは、予期しない全再計算の検出と、適切なインクリメンタルMVリフレッシュのためのパイプラインの最適化について議論します。

主要なアーキテクチャ上の考慮事項

インクリメンタル＆フルリフレッシュのシナリオ

フルリフレッシュは、ソースから利用可能なすべてのデータを再処理することでMVの結果を上書きします。これは、全体のデータセットを再処理する必要があるため、コストがかかり時間がかかることがあります。わずかな変更であっても、データセット全体を再処理する必要があるためです。

一般的には効率のためにインクリメンタルリフレッシュが好まれますが、フルリフレッシュが適切な状況もあります。私たちのコストモデルは、以下の高レベルのガイドラインに従います：

• 基盤となるデータに大きな変更がある場合、特にレコードが削除または変更され、コストモデルがインクリメンタル変更を効率的に計算・適用できない場合は、フルリフレッシュを使用します。
• 変更が比較的小さく、ソーステーブルが頻繁に更新される場合は、インクリメンタルリフレッシュを使用することでコンピューティングコストを削減できます。

Enzymeコンピュートエンジン

Enzymeは、新しいデータが到着したり変更が発生したりするたびに、全体のテーブルやビューをゼロから再計算するのではなく、新しいデータや変更されたデータだけをインテリジェントに判断し、処理します。このアプローチは、伝統的なバッチETL方法と比較して、リソース消費と遅延を大幅に削減します。

下の図は、Enzymeエンジンがマテリアライズドビューを更新する最適な方法をどのように決定するかを概説しています。

Enzymeエンジンは、更新戦略を選択し、パフォーマンスと計算効率を最適化するために、内部コストモデルに基づいて増分リフレッシュまたはフルリフレッシュを実行するかどうかを決定します。

Deltaテーブルでの機能の有効化

MVの再計算を増分化するためには、ソーステーブルで行追跡を有効にする必要があります。

行追跡は、最後のMVリフレッシュ以降にどの行が変更されたかを検出するのに役立ちます。これにより、DatabricksはDeltaテーブルの行レベルのリネージを追跡し、マテリアライズドビューへの特定のインクリメンタル更新に必要となります。

削除ベクトルの有効化はオプション機能です。削除ベクトルにより、Databricksはソーステーブルからどの行が削除されたかを追跡できます。これにより、少数の行のみが削除された場合でもファイル全体を書き換える必要がなくなります。

これらのテーブル機能をソーステーブルで有効にするために、以下のSQLコードを活用します：

技術的な解決策の分解

次のセクションでは、パイプラインがフルリフレッシュをトリガーするのか、MVでのインクリメンタルリフレッシュをトリガーするのかを検出する方法と、インクリメンタルリフレッシュを促進する方法について、例を交えて説明します。

この技術的なウォークスルーは、以下の高レベルのステップに従います：

1. ランダムに生成されたデータでDeltaテーブルを生成する
2. LDPを作成し、マテリアライズドビューを作成するために使用する
3. マテリアライズドビューに非決定的関数を追加する
4. パイプラインを再実行し、リフレッシュ動作に与える影響を観察する
5. パイプラインを更新してインクリメンタルリフレッシュを復元する
6. リフレッシュ手法を調査するためにパイプラインイベントログをクエリする

この例に沿って進めるには、このスクリプトをクローンしてください: MV_Incremental_Technical_Breakdown.ipynb

run_mv_refresh_demo()関数内の最初のステップでは、ランダムに生成されたデータでDeltaテーブルを生成します：

次に、ランダムに生成されたデータを挿入するための次の関数が実行されます。これは、新しいレコードが集計可能な状態であることを確認するために、新しいパイプライン実行の前に実行されます。

次に、Databricks SDKを用いてLDPを作成し、デプロイします。

MVは、サーバーレスLDPまたはDatabricks SQL（DBSQL）を通じて作成でき、同じように動作します。DBSQL MVは、MVと連動したマネージドなサーバーレスLDPを起動します。この例では、イベントログの出力など、さまざまな機能を利用するためにサーバーレスLDPを活用していますが、DBSQL MVを使用した場合でも同じように動作します。
 

パイプラインが正常に作成されると、関数は次にパイプラインの更新を実行します：

パイプラインが正常に実行され、初期のマテリアライズドビューが作成された後、次のステップは、データを追加し、ビューを更新することです。パイプラインを実行した後、リフレッシュの挙動を確認するためにイベントログをチェックします。

結果は、GROUP_AGGREGATEメッセージによってマテリアライズドビューがインクリメンタルにリフレッシュされたことを示しています：

次に、非決定的関数（RANDOM()）の追加がマテリアライズドビューのインクリメンタルリフレッシュを防ぐ方法を示すために、MVは次のように更新されます：

MVの変更を考慮し、非決定的関数を示すために、パイプラインは2回実行され、データが追加されます。イベントログは再度クエリされ、結果は完全な再計算を示します。

RANDOM()やCURRENT_DATE()などの非決定的な関数を追加すると、MVはソースデータの変更だけに基づいて出力を予測することができないため、インクリメンタルリフレッシュができません。

パイプラインイベントログの詳細内で、planning_information,の下にあるJSONイベント詳細は、インクリメンタル化を防ぐ理由を次のように提供します：

非決定的な関数が分析に必要な場合、マテリアライズドビューで動的に計算するのではなく、その値をソーステーブル自体に押し込む方がよいアプローチです。これを実現するために、random_number列をMVレベルで追加するのではなく、ソーステーブルから取得するように変更します。

以下は、MV内の静的なrandom_number列を参照するための更新されたマテリアライズドビュークエリです：

新しいデータが追加され、パイプラインが再度実行されると、イベントログをクエリします。出力結果から、MVがCOMPLETE_RECOMPUTEではなくGROUP_AGGREGATEを実行したことがわかります！

パイプラインによってフルリフレッシュが自動的にトリガーされる条件は次のとおりです：

• UUID()やRANDOM()のような非決定的関数の使用
• クロス、フルアウター、セミ、アンチ、大量の結合など、複雑な結合を含むマテリアライズドビューの作成。
• Enzymeが、フルリフレッシュを実行する方が計算コストが低いと判断した場合

インクリメンタルリフレッシュに対応する関数についてはこちらをご覧ください。

現実世界のデータボリューム

ほとんどの場合、データの取り込みは5行を挿入するよりも大きいです。これを示すために、初期ロードに10億行を挿入し、各パイプライン実行に1000万行を挿入しましょう。

dbldatagenを使用してデータをランダムに生成し、Databricks SDKを使用してLDPを作成し実行することで、ソーステーブルに10億行が挿入され、パイプラインが実行されてMVが生成されました。次に、ソースデータに1000万行が追加され、MVがインクリメンタルにリフレッシュされました。その後、パイプラインは強制的にリフレッシュされ、フルリフレッシュが行われました。

パイプラインが完了したら、list_pipeline_eventsと課金システムテーブルをdlt_update_idでマージし、更新ごとのコストを決定します。

下のグラフに示すように、インクリメンタルリフレッシュはフルリフレッシュよりも2倍速く、コストも安くなりました！

運用上の考慮事項

LDPにおけるインクリメンタルリフレッシュの利点を完全に実現するためには、強力なモニタリング、観測性、自動化の実践が不可欠です。次のセクションでは、Databricksの監視機能を活用してパイプラインのリフレッシュとコストを追跡する方法を概説します。

パイプラインリフレッシュの監視

イベントログやLDP UIインターフェースなどのツールは、パイプラインの実行パターンを可視化し、さまざまなリフレッシュが発生するタイミングを検出するのに役立ちます。

チームがマテリアライズドビューのリフレッシュ動作を追跡し分析するのを助けるアクセラレータツールを含めています。このソリューションはAI/BIダッシュボードを活用してリフレッシュパターンの可視化を提供します。Databricks SDKを使用して、設定されたワークスペース内のすべてのパイプラインを取得し、パイプラインのイベント詳細を収集し、以下のようなダッシュボードを作成します。

Githubリンク: monitoring-declarative-pipeline-refresh-behavior

主要なポイント

マテリアライズドビューのリフレッシュをインクリメンタル化することで、Databricksはソーステーブルの新規または変更されたデータのみを処理し、パフォーマンスを向上させ、コストを削減します。

MVを使用する場合、非決定的な関数の使用を避ける（つまり、CURRENT_DATE()やRANDOM()）とクエリの複雑さを制限する（つまり、過度の結合）ことで、効率的なインクリメンタルリフレッシュを可能にします。インクリメンタルリフレッシュにリファクタリング可能であるにも関わらず、MVで予期しないフルリフレッシュが発生することを放置すると、以下のような問題が生じる可能性があります：

• コンピューティングコストの増加
• 下流のアプリケーションのデータ新鮮度の遅延
• データ量が増加するにつれてのパイプラインのボトルネック

サーバーレスコンピューティングでは、LDPは組み込みの実行モデルを活用し、Enzymeが全体のパイプライン計算コストに基づいて増分または全体のリフレッシュを行うことができます。

アクセラレータツールを活用して、AI/BIダッシュボード内のすべてのパイプラインの挙動を監視し、予期しない全再計算を検出します。

結論として、効率的なマテリアライズドビューのリフレッシュを作成するためには、以下のベストプラクティスに従ってください：

• 必要に応じて決定的なロジックを使用する
• 非決定的関数を避けるためにクエリをリファクタリングする
• 結合ロジックを簡素化する
• ソーステーブルで行追跡を有効にする

次のステップと追加のリソース

今日、あなたのMVリフレッシュタイプを見直しましょう！

Databricksのデリバリーソリューションアーキテクト（DSA）は、組織全体のデータとAIのイニシアチブを加速します。彼らは、アーキテクチャリーダーシップを提供し、プラットフォームをコストとパフォーマンスの観点から最適化し、開発者体験を向上させ、プロジェクトの成功を推進します。DSAは、初期のデプロイメントと本番環境のソリューションの間のギャップを埋める役割を果たし、データエンジニアリング、技術リーダー、エグゼクティブ、その他のステークホルダーを含むさまざまなチームと密接に連携して、カスタム化されたソリューションとより早い価値提供を確実にします。DSAからカスタム実行プラン、戦略的ガイダンス、データとAIの旅を通じてのサポートを受けるためには、Databricksアカウントチームにお問い合わせください。

関連リソース

• Lakeflow Declarative Pipelinesフローを使用してデータをインクリメンタルにロードおよび処理する | Databricks Documentation
• マテリアライズドビューのインクリメンタルリフレッシュ | Databricksドキュメンテーション

LDPを作成し、MVのインクリメンタルリフレッシュタイプを今すぐ確認してください！