レイクハウスの具体化された湖の景色に最適なリフレッシュ

具体化されたレイクビューに対してスケジュールされた更新が実行されるたびに、Fabric は、ソースデータの変更に基づいて、「更新なし」、「増分更新」、「完全更新」の中から最適な戦略を決定します。この動作は 最適な更新と呼ばれ、コンピューティングコストと更新時間を最小限に抑えながら、具体化された湖のビューを最新の状態に保つのに役立ちます。

この記事では、最適な更新のしくみ、各戦略の機能、および必要に応じて完全更新モードに切り替える方法について説明します。

注

次のシナリオでは、最適な更新はサポートされていません。

PySpark 定義: 最適な更新は、Spark SQL で定義されている MLV にのみ適用されます。 PySpark で定義された MLV では、常に完全更新が使用されます。
差分以外のソーステーブル: ソースとして非差分テーブルを使用する具体化されたレイクビューでは、常に完全な更新が実行されます。増分戦略およびノーリフレッシュ戦略では、Deltaテーブルソースが必要です。

最適な更新の利点

ソーステーブルの差分コミットを分析することで、最適な更新によって、データの処理方法に関するスマートな決定を行うことができます。可能な場合は、次の結果が発生する可能性があります。

コストの削減: ソースデータが変更されなかったことを Fabric が検出し、更新を完全にスキップするときに使用されるコンピューティングとストレージが少なくなります。最適な更新には追加料金は適用されません。更新操作中のコンピューティング使用量に基づいて課金されます。
効率性の向上: 変更されたデータのみを処理する必要がある場合の更新サイクルを短縮し、より新しい分析情報を提供するのに役立ちます。
時間の節約: 完全なデータセットを再計算するのではなく、増分処理を適用するときの更新期間が短縮されました。

最適な更新戦略

次の表では、最適な更新で選択できる更新戦略について説明します。

ポリシーの更新	Description
更新なし	ソーステーブルで新しい差分コミットが検出されない場合、Fabric は更新を完全にスキップし、不要なコンピューティングを回避します。
増分更新	ソーステーブルで新しい差分コミットが検出されたときに、変更されたデータのみを処理します。
完全更新	完全なソースデータセットから具体化されたレイクビュー全体を再計算します。この方法は、サポートされていない式が検出された場合、変更を増分処理できない場合、またはソースデータセットが小さい場合に、完全な再計算が増分処理よりも高速である場合に使用されます。

Important

インクリメンタルリフレッシュは以下の要素に基づいて適用されます:

出典データのパターン。 追加専用データは挿入のインクリメンタル処理をサポートします。削除や更新などの追記型ではないデータについては、増分リフレッシュがサポートされるのは、マテリアライズドレイクビューで行識別子を特定するリフレッシュヒントが使用されている場合のみです。そうでなければ、エンジンはフルリフレッシュに戻ります。詳細については、インクリメンタルリフレッシュおよびデータ変更パターンをご覧ください。
デルタ変化データフィード(CDF)。 マテリアル化された湖のビュー定義で参照されるすべてのソーステーブルでCDFを有効にする(delta.enableChangeDataFeed=true)必要があります。 CDF を使用しない場合、最適な更新では、更新なしと完全更新のどちらかのみを選択できます。詳細については、「増分更新を有効にする」を参照してください。

最適な更新を設定する

最適な更新の切り替えにより、追加のセットアップなしで、更新なしと完全更新の戦略が提供されます。増分更新戦略のロックを解除するには、ソーステーブルで変更データフィードを有効にする必要もあります。

最適な更新モードを有効にする

既定では、具体化されたレイクビュー系列に対して最適な更新モードが有効になっています。有効になっていない場合は、次の手順に従って有効にします。

レイクハウスに移動し、 具体化された湖の景色を選択します。
[ 管理] を選択し、[ 最適な更新 ] トグルを選択してオンにします。

インクリメンタルリフレッシュとデータ変更パターン

インクリメンタルリフレッシュは、クエリとデータがリフレッシュ戦略で動作する場合、追加のみおよび非追加データパターンの両方をサポートします。

注

インクリメンタルリフレッシュが最も効率的な選択肢でない場合、エンジンは変更の規模やコストに応じてフルリフレッシュに切り替えることができます。このバックアップは効率的な更新を維持しつつ正確さを保つのに役立ちます。

追加のみの更新の場合、Fabricは前回の更新以降に追加された新しい行のみを処理します。削除や更新など付加しないデータに対しては、エンジンは行を確実に識別する方法が必要です。もし物質化された湖のビューが一意キーを宣言するリフレッシュヒントを定義しているなら、Fabricはデルタを段階的に適用できます。互換性のあるキーがない場合、CDFが有効でクエリがサポートされているSQL構造のみを使用していても、エンジンはフルリフレッシュに切り替えます。

削除と更新の処理についての詳細は、「リフレッシュヒント付きマテリアル化された湖のビューにおける削除と更新の処理」をご覧ください。

増分更新を有効にする

増分更新を使用するには、具体化されたレイクビュー定義で参照されるすべてのソーステーブルまたは具体化されたレイクビューで差分変更データフィード (CDF) プロパティを有効にする必要があります。 CDF では、完全なデータセットを再処理するのではなく、前回の更新以降に変更された行のみを読み取ります。

CDF が有効になっていない場合、最適な更新では、更新なしと完全更新のどちらかのみを選択できます。

Tip

更新最適化の機会を特定できるように、Fabric では、増分更新の対象でありながら、1 つ以上のソーステーブルで CDF が有効になっていないためにブロックされているマテリアライズドレイクビューを一覧表示するバナーが表示されます。バナーは、リネージビュー、最近の実行の詳細、および各ノードレベルに表示されるため、どのエントリポイントからでもギャップを特定できます。

バナーから直接 CDF を有効にするには:

バナーで、[ CDF のアクティブ化] を選択します。
[ データフィードの変更を有効にする ] ダイアログで、具体化されたレイクビューの一覧と、CDF が有効になるソーステーブルを確認します。
有効化 を選択します。次の更新では、更新された CDF の状態が反映されます。

注

ソーステーブルでCDFを有効にしても、マテリアル化された湖のビューで使用されるソーステーブルに測定可能なストレージやパフォーマンスへの影響はありません。 CDF は、他の Fabric 機能も利用できる標準の Delta Lake テーブルプロパティです。 CDF のしくみの詳細については、「 Delta Lake の変更データフィードを使用する」を参照してください。

TBLPROPERTIES ステートメントにCREATEを含めることで、作成時に CDF を有効にすることができます。

CREATE OR REPLACE MATERIALIZED LAKE VIEW silver.cleaned_order_data
TBLPROPERTIES (delta.enableChangeDataFeed=true)
AS
SELECT 
    o.order_id,
    o.order_date,
    o.product_id,
    p.product_name,
    o.quantity,
    p.price,
    o.quantity * p.price AS revenue
FROM bronze.orders o
INNER JOIN bronze.products p
ON o.product_id = p.product_id

既存のソーステーブルの場合は、 ALTER TABLE を使用して CDF を有効にします。

ALTER TABLE <table-name> SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

たとえば、使用開始ガイドの両方のソーステーブルで CDF を有効にするには、次のようにします。

ALTER TABLE bronze.products SET TBLPROPERTIES (delta.enableChangeDataFeed = true);
ALTER TABLE bronze.orders SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

増分更新でサポートされる SQL コンストラクト

増分更新は、具体化されたレイクビュー定義でここで説明する SQL コンストラクトのみを使用する場合に機能します。クエリにサポートされていないコンストラクト (ウィンドウ関数や非決定的関数など) が含まれている場合、Fabric は引き続きデータを更新しますが、完全な更新にフォールバックします。

SQL コンストラクト	注釈
SELECT 式	決定論的な組み込み関数と式がサポートされています。 `rand()`、`uuid()`、`current_timestamp()`などの非決定的関数はサポートされていません。 `DISTINCT` およびウィンドウ関数はサポートされていません。
FROM	Delta テーブルと具体化されたレイクビューをサポートします。サブクエリと CTE は、サポートされている句のみを使用する場合に機能します。
WHERE	決定的な組み込み関数のみがサポートされています。
INNER JOIN（内部結合）	Supported.
左外部結合/左半結合	Supported. 増分更新は、更新サイクル中に右側のテーブルが変更されない場合にのみ機能します。右側のテーブルを変更すると、完全な更新がトリガーされます。
GROUP BY / 集計	Supported. アグリゲート(`AVG()`、`STDDEV()`など)の使用では、すべてのソーステーブルが分割され、その分割列がMLVクエリの`GROUP BY`節に含まれる必要があります。これにより、影響を受けたパーティションのみを段階的に再計算Fabric可能です。 `SUM()`、 `MIN()`、 `MAX()`、 `COUNT()` (DISTINCTなし) は特別なケースで、分割要件なしでインクリメンタルリフレッシュをサポートします。同じクエリ内で`SUM()`、`COUNT()`、`MIN()`、`MAX()`と他の集約関数を混同する場合(例えば`SELECT SUM(amount), AVG(price) ...`)、クエリ全体のパーティショニング条件が必要です。そうでなければ、Fabricはフルリフレッシュにフォールバックします。 `GROUP BY` 列は、 `SELECT` リストに表示される必要があります。
UNION ALL	Supported.
WITH	サポートされている句のみを使用する場合の共通テーブル式 (CTE)。
式のサブクエリ	SELECT 式または WHERE 式内のサブクエリ (スカラーサブクエリや `EXISTS`など) は、参照先テーブルに変更がある場合に完全な更新をトリガーします。
データ品質の制約	制約では、決定的な組み込み関数のみがサポートされます。

注

サポートされていないコンストラクトを使用しても、具体化されたレイクビューを作成できません。これは、Fabric が増分更新ではなく完全更新を使用することを意味するだけです。

完全更新

最適な更新は、必要に応じて自動的に完全更新にフォールバックするため、通常は強制的に更新する必要はありません。ただし、たとえば、予期しない結果のトラブルシューティングや修正後のデータの再処理など、完全な更新を手動でトリガーする必要がある場合があります。

SQL を使用して 1 回限り完全更新を実行する

特定の具体化されたレイクビューを強制的に完全に更新するには、次のコマンドを実行します。

REFRESH MATERIALIZED LAKE VIEW [workspace.lakehouse.schema].MLV_Identifier FULL

注

ワークスペース名にスペースが含まれている場合は、バックティックで囲んでください。 `My Workspace`.lakehouse.schema.view_name

最適な更新をオフにする

スケジュールされたすべての実行で完全な更新を実行する場合は、最適な更新トグルをオフにすることができます。これにより、更新なし戦略と増分戦略の両方が無効になります。ソースデータが変更されていなくても、すべての実行で完全なデータセットが再計算されます。

レイクハウスに移動し、 具体化された湖の景色を選択します。
管理を選択し、最適リフレッシュのトグルをオフにしてください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-29