Snowflakeは、データプラットフォームのメンテナンス作業を排除し、クラウド用のデータモデル手法を自由に選択できるようにすることで、クラウドにおけるデータの標準を設定し続けています。今回をはじめとする一連の投稿を通じて、Snowflakeのスケーリングに合わせてData Vaultを動的にスケーリングするために考慮すべきSnowflakeの機能について説明していきます。

今後数か月かけて、次のようなブログ記事の公開を予定しています。

  1. イミュータブルストア、仮想の終了日
  2. Data Vault用のSnowsightダッシュボード
  3. ポイントインタイム構造とジョインツリー
  4. 非常に大きなサテライトテーブルのクエリ
  5. ビュー上でのストリームとタスク
  6. 条件付きのマルチテーブルINSERTとその使用場面
  7. 行アクセスポリシーとマルチテナント
  8. Snowflakeでのハブのロック
  9. 仮想ウェアハウスとチャージバック

残りのData Vaultのタイプ：

図、テキスト 説明（自動生成）

変更不可能なオブジェクトと変更可能なオブジェクトのことをそれぞれ「イミュータブル」、「ミュータブル」と呼びます。Snowflakeでは、圧縮および暗号化された16MBのイミュータブルなマイクロパーティションが、Snowflakeのミュータブルテーブルを構成しています。Snowflakeのマイクロパーティションはイミュータブルなファイルであり、Snowflakeのユーザーには見えません。ここではテーブルがマイクロパーティションの入れ物として機能し、ユーザーはそれを操作することになります。操作には次のようなものがあります。

  • 新規マイクロパーティションを新規レコードとしてロードするSQL INSERT演算
  • レコードとそのマイクロパーティションをタイムトラベルにコミットするSQL DELETE演算
  • 新規レコードをテーブルにINSERTし、レコードの古い状態をタイムトラベルにコミットするSQL UPDATE演算

タイムトラベルについてもう少し詳しく見てみましょう

カレンダーを含む図 自動生成された説明

簡略化されたデータ表現であるハッシュキーは親キーに対する決定論的なダイジェスト値となります

Data Vaultのサテライトテーブルには、ビジネスオブジェクトの記述状態（ハブテーブルに基づく）または作業単位の記述状態（リンクテーブルに基づく）が含まれています。サテライトテーブルは開始日と終了日で完成されたKimball Slowly Changing（SCD）タイプ2のディメンションとして表示され、親キー（ハッシュキー）によるそれぞれのSQL UPDATEにより、実際には2つのレコードがテーブルにINSERTされることになります。上記で示したように、HASH KEY 3、5、6には既存のレコードに対するアップデートが存在するため、SQL UPDATE が完了した時点で、これらのレコードの新しい状態を反映させる必要があります。この際、マイクロパーティションはイミュータブル（変更不可）であることを覚えておいてください。

1月4日のアップデート前のSQL SELECTクエリが返すもの：

  • HashKey 1, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 2, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 3, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 4, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 5, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 6, StartDate: 03-JAN-2022, EndDate: 31-DEC-9999
テーブルを含む図 自動生成された説明

タイムトラベルとフェイルセーフを備えたSnowflakeベーステーブルとしてのサテライトテーブル

静止状態の場合、SQL UPDATEの前後のレコードがディスク上に同時に存在することになりますが、SQL UPDATE前のレコードを利用するにはタイムトラベル機能を使用する必要があります。タイムトラベルはSCDタイプ2ディメンションと同一ではありません。むしろ、サテライトテーブルのライブバックアップとお考えください。タイムトラベルは0～90日の範囲で設定でき、Snowflakeで拡張されたSQLタイムトラベル構文を使用して取得可能です。レコードがタイムトラベル期間から外れると、7日間のフェイルセーフが設定され、この間はSnowflakeのサポートに連絡した場合のみレコードを取得することができます。この7日間を過ぎると、これらのレコードはSnowflakeから削除され、回復不可能となります。

  • Permanentテーブルではタイムトラベルを0～90日の範囲で設定できますが7日間のフェイルセーフについては変更できません。
  • Transientテーブルでは0～1日のタイムトラベルが可能ですが、フェイルセーフ機能はありません。
グラフィカルユーザーインターフェース 自動生成された説明

タイムトラベルは、Snowflakeの拡張SQLを使用して構成したデータのライブバックアップです。

更新後のテーブルをクエリするとそのテーブル内のレコードの現在の状態が返され、タイムトラベルを使用してクエリを実行すると、そのテーブルの以前の状態が返されます。HASH KEY3、5、6のストレージニーズに注意してください。したがって、1月18日にSQL SELECTクエリを実行すると、次のような結果が得られます。

  • HashKey 1, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 2, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 3, StartDate: 01-JAN-2022, EndDate: 15-JAN-2022
  • HashKey 3, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 4, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 5, StartDate: 02-JAN-2022, EndDate: 16-JAN-2022
  • HashKey 5, StartDate: 17-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 6, StartDate: 03-JAN-2022, EndDate: 16-JAN-2022
  • HashKey 6, StartDate: 17-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 7, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 8, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999

A picture containing graphical user interface Description automatically generated

Data Vault 2.0サテライトテーブルにはEND-DATE列がありません

Data Vault 2.0では、数年前からSQL UPDATE操作の実行にかかる費用を認識しており、SQL言語自体の進化に伴い、Data Vault 2.0の実践事項としてサテライトテーブルのEND-DATE列が非推奨となりました。SQL LEAD Analytical機能を使って、サテライトテーブルを作成した後、そのサテライトテーブルに対してSQL VIEWを定義することにより、親キーの終了日を仮想化できるようになりました。

Graphical user interface, application Description automatically generated

データはSQL INSERT演算であり、SQL UPDATE演算は不要であるため、テーブルの更新は新規レコードの挿入のみとなります。つまり、データがどのような速度で到着しても、Snowflakeではテーブルを最新の状態に保つ目的で新規マイクロパーティションのチャーン速度を変更するということがありません。また、チャーンの大きなテーブルのようにタイムトラベルとフェイルセーフのストレージに多数のマイクロパーティションが作成されることもありません。さらに、Snowflakeのテーブルでは列のクラスタリングを設定する必要がなく、サテライトテーブルが自然にSTART-DATEでクラスタリングされるようになっています。ほとんどのアナリティクスは、親キーによる現在の日付に基づいているため、テーブルの再クラスタリングが一切不要となります。

クローン作成とタイムトラベル

ゼロコピークローン

最後に、サテライトテーブルのクローンは、Snowflakeアカウント内の環境をまたいで作成できます。クローンはその時点でのテーブルのスナップショットであり、PRODに追加された新規データには（クローンが存在する）DEVからはアクセスできず、DEVに追加された新規データにはPRODからアクセスできません。この特許取得済みのSnowflake機能を活用すると、本番品質のデータの瞬時のコピーを利用して開発することができる一方で、ストレージは複製されず、メタデータのみが複製されるため、DevOpsプロセスのスピードアップが実現します。 

クローン作成は、スキーマ全体のクローン作成あるいはデータベース全体にも拡張できるほか、ブルー／グリーンテストのためのスキーマの入れ換えも可能です。

例：

ステップ1：スキーマをDEVスキーマにクローンし、変更を実行する

ステップ2：データロードをDevクローンにキャッチアップする

ステップ3：DevとProdのスキーマを入れ換える

まとめ

コンピューティングとストレージの分離とマイクロパーティションの管理は完全にメタデータをベースとしているためDevOpsプロセスがスピードアップされます。また、Data Vault 2.0はINSERT-ONLYの手法であるため、Snowflakeのスケールに自動的にフィットし、スケーリングされます。タイムトラベルにレコードが保持されない場合、以前の状態を追跡する必要はありません。 

ただし、Snowflakeのタイムトラベル機能を使えば、ある時点のスナップショットでData Vaultのクローンを作成し、DevOpsの開発とテストをスピードアップできます。

Data Vaultの自動化とオーケストレーション

その他の参考資料