AIと連携し、Excel感覚で操作できるクラウドBIサービス、Sigma(Sigma Computing)。
SigmaにはMaterialization(マテリアライゼーション)という機能があります。クエリ結果をデータウェアハウス内のテーブルに書き込み、定期的に(多くの場合、毎日)更新されるキャッシュ形式としてアクセス出来るようにしておくことで、クエリが実行されるたびに結果を再計算するよりも迅速かつ効率的にアクセスできるようになります。
当エントリではSigmaにおけるMaterialization(マテリアライゼーション)の概要について紹介していきます。
はじめに
マテリアライゼーション(Materialization)はレポートの速度とパフォーマンスを向上させます。データモデル、ワークブック、データセットのマテリアライゼーションを設定できます。
マテリアライゼーション(Materialization)について
Sigmaでは、データ要素間の複雑な結合や、カーディナリティ(データベースのテーブルの列[カラム]に含まれる異なる値の種類[バリエーション]の数)が高く、複数のグループ化レベルと計算列を持つデータセットなど、コストの高いクエリや実行時間の長いクエリを使用するデータソースがある場合、マテリアライゼーションを設定することでクエリのパフォーマンスが向上し、コンピューティングコストの削減に繋げることができます。
マテリアライゼーションでは、データセットまたはデータ要素のコピーがテーブル(場合によっては動的テーブル)としてウェアハウスに書き戻されます。
マテリアライズされたデータは、Sigmaのサービスによって管理されるスキーマ内のクラウドデータウェアハウスに保存されます。このスキーマは、すべての書き戻しデータに使用されるデータベースまたはカタログとスキーマと同じです。マテリアライズされたテーブルには、先頭にt_matまたはT_IDが付加されるか、末尾に_MATが付加され、Sigmaの接続エクスプローラーには表示されません。
マテリアライゼーション(Materialization)を利用するケース
マテリアライゼーションを使用する要素を表示または操作する場合、Sigmaのクエリコンパイラは自動的かつ透過的に最新のマテリアライゼーションを使用します。クラウドデータウェアハウスはクエリを再計算しません。
ワークブックのページコントロールがマテリアライズド要素をターゲットとしている場合、コントロールの値を変更するとライブデータがクエリされます。代わりに、ワークブックまたはデータモデルの子要素をコントロールのターゲットとしてください。
マテリアライズド要素に関するベストプラクティスをご覧ください。
ワークブックまたはデータモデル内の具体化されたデータセットまたは具体化された要素を編集する場合、具体化されたデータは使用されず、正確な結果を確保するために基になるデータがクエリされます。
「データモデルとワークブックのマテリアライゼーション」と「データセットのマテリアライゼーション」の比較
ワークブックおよびデータモデル内のマテリアライズされたデータ要素は、マテリアライズされたデータセットとはいくつかの点で異なります。
- データセットをパブリッシュすると、変更がマテリアライズの精度に影響を与えない場合でも、マテリアライズが実行されます。マテリアライズされた要素を含むワークブックまたはデータモデルをパブリッシュする場合、パブリッシュされた変更がマテリアライズに影響を与える場合にのみ、マテリアライズが実行されます。
- データセットに複数のグループ化レベルが含まれている場合、実体化できるのは 1つのグループ化レベルのみです。ワークブックまたはデータモデル内のデータ要素に複数のグループ化レベルが含まれている場合は、各グループ化レベルを実体化できます。
- ワークブックおよびデータモデル内のデータ要素の未使用のマテリアライゼーションは自動的に一時停止できます。未使用のデータセットのマテリアライゼーションは自動的に一時停止できません。自動一時停止されたマテリアライゼーションの詳細については、下記ドキュメントを御覧ください。
- Snowflake接続でマテリアライゼーションを使用する場合、ワークブックおよびデータモデル内のマテリアライズされたデータ要素は一時テーブルを使用します。一時テーブルの詳細については、下記Snowflakeドキュメントを御覧ください。
動的テーブル(dynamic tables)による増分マテリアライゼーション(Incremental materialization)
デフォルトでは、マテリアライゼーションは毎回新しいテーブルを作成します。
Snowflake接続でマテリアライゼーションを使用する場合、接続ではデフォルトで動的テーブルがマテリアライゼーションに使用されます。多くの場合、動的テーブルは増分更新を許可しているため、マテリアライゼーションの実行時には変更されたデータのみが更新されます。
動的テーブルをマテリアライゼーションに使用するには以下手順を行います。
- マテリアライゼーションに動的テーブルを使用するように接続を設定します。詳細は下記情報をご参照ください。
- マテリアライゼーションに使用する動的テーブルを構築するためにクエリされる可能性のあるすべてのデータベーステーブルで変更追跡を有効にします。動的テーブルの作成については、Snowflakeドキュメントの下記情報をご参照ください。
上記手順を完了すると、マテリアライゼーションは動的テーブルを使用し、利用可能な場合は増分リフレッシュを使用します。
増分リフレッシュが利用できない場合は、フルリフレッシュが実行されます。動的テーブルが利用できない、またはサポートされていない場合は、テーブルが使用されます。どの方法が使用されたかを確認するには、要素のマテリアライゼーション履歴を確認してください。
増分更新が使用できない場合、または動的テーブルが使用できない場合の詳細については、下記Snowflakeのドキュメントをご参照ください。
既存のマテリアライズスケジュールは、次回のスケジュール実行時に動的テーブルの使用を試みます。動的テーブルを使用した増分マテリアライズを使用できるのは、ワークブックとデータモデル内のデータ要素のみです。マテリアライズされたデータセットでは動的テーブルは使用されません。
スケジュールされたマテリアライゼーションのバイパス
Snowflake接続でマテリアライゼーションを使用する場合、Sigmaはワークブックおよびデータモデル内のマテリアライゼーションされた要素のデータ更新を検出します。
前回の正常なマテリアライゼーション以降に基となるデータが更新されていない場合、Sigmaはスケジュールされたマテリアライゼーションをバイパスし、不要な計算時間とコストを削減します。
基となるデータに変更がないためマテリアライゼーションがスキップされた場合、Sigmaはマテリアライゼーションの状態が表示されるすべての場所で [✅️Skipped]を表示します。これには以下の要素が含まれます。
- 要素メニューにビューの物質化情報ポップオーバー
- マテリアライゼーションスケジュールモーダル、ワークブックまたはデータモデルリネージ
- および [Admin]>[Materializations] ページ。
マテリアライゼーションに関する制限
- 一部のデータ構造はマテリアライズできません。データにシステム関数を使用する列が1つ以上含まれる場合（例：行レベルセキュリティが設定されたデータセットなど）、マテリアライズが実行できません。
- マテリアライゼーションは、マテリアライゼーションが実行された時点のデータの固定出力を反映するため、一部のデータ構造では予期しない結果が生成される場合があります。
- データセットでパラメータを使用している場合、マテリアライゼーションはパラメータの初期値を使用して実行されます。パラメータへの将来の変更は影響しません。
- ワークブックまたはデータモデル内のデータ要素が1つ以上のコントロールのターゲットになっている場合、コントロールの初期値を使用してマテリアライズが実行されます。マテリアライズ後、コントロールを使用してマテリアライズされたデータ要素を操作すると、マテリアライズされたデータは使用されず、代わりに最新のデータを取得するためのクエリが実行されます。代わりに、コントロールを子要素にターゲット設定してください。
- ソース データ要素のいずれかを具体化できない場合を除き、ルックアップ、結合、リレーションシップなどを使用して他のデータ要素を参照するワークブックまたはデータ モデル内のデータ要素を具体化できます。
- ソース データセットのいずれかを具体化できない場合を除き、ルックアップ、リンク、結合などを使用して他のデータセットを参照するデータセットを具体化できます。
- OAuth 認証を使用してデータ プラットフォームに接続すると、ワークブックおよびデータ モデル内のデータ要素を具体化できますが、データセットを具体化することはできません。
-
sigma_element()構文を使用して別の Sigma 要素を参照するカスタムSQL要素を具体化することはできません。
まとめ
というわけで、Sigmaにおけるマテリアライゼーション(Materialization)の概要に関する紹介でした。次エントリ以降で実践もしてみたいと思います。