More than 1 year has passed since last update.

Snowflakeのデータモデリングに関するメモ (Architect)

Snowflake

Posted at 2024-04-30

これは何？

SnowPro Advanced Architect の文脈で出てくるであろうデータモデリングについて調べてみたもの。
Snowflakeに限らず一般的なDWHにも通じる話である。

公式情報

Snowflake で使用できるデータモデリングの概念

Snowflakeは、次の制約の機能を提供する
- 一意キー、主キー、外部キー、列の NOT NULL制約
- 名前付き制約
- 単一列および複数列の制約
- インラインおよびアウトラインの制約の作成
- 制約の作成、変更、削除のサポート
サポートされている制約のタイプ (ANSI SQL標準)
- UNIQUE
- PRIMARY KEY
- FOREIGN KEY
- NOT NULL
注意点としては、Snowflakeでは常に強制される NOT NULL制約以外については強制しない

Data Vault (データボルト / DV)

アジャイルで柔軟性と拡張性に優れたエンタープライズデータウェアハウス（EDW）をモデリングするためのメソッドおよびアプローチを提供するもの
詳細指向の履歴追跡であり、ビジネスの1つ以上の機能領域をサポートする正規化されたテーブルセットと一意にリンクされているもの
第3正規形（3NF）とスタースキーマの間にある最良の組み合わせを網羅するハイブリッドアプローチである
次の3つの主要タイプのテーブルのみで構成される反復可能なモデリング手法である
- ハブ
- リンク
- サテライト
例えば、以下のようなチームに別れて用途別にデータを参照するようなユースケースに適している
- レポーティング・可視化を行う
- MLで利用する
- データの収益化を行う

ハブ(H)

ビジネスオブジェクトを表すビジネスキーの一意のリスト
ビジネスオブジェクト識別子（ビジネスキー）のレポジトリであり、ビジネスオブジェクト自体がビジネス能力の中心であるため、ハブはビジネス主導型となる

リンク(L)

ビジネスプロセスの作業ユニットを表す関連性/トランザクションの一意のリスト
多対多の構造になるように設計されており、リエンジニアリングせずに（つまり、データをリロードすることなく）、カーディナリティやビジネスルールの変更を柔軟に吸収できる

サテライト(S)

ハブとリンクの記述データ（履歴付きのタイプ2）
- タイプはSCD（Slowly Changing Dimensionsの文脈で出てくる用語
- タイプ2 (Type2)
  - データウェアハウスにおける次元データの管理手法で、データの変更履歴を全て保持する方法を指す
  - 一方で「タイプ1」は履歴を保持しない手法のこと
必要な間隔で履歴を記録するための適応性に加えて、ソースシステムに対する疑う余地のない監査可能性とトレーサビリティを得ることができる

Data Vaultで使用するSnowflake機能

以下の機能を活用して、Data Vaultモデリングアプローチをサポートできるとのこと。

マルチテーブルインサート（MTI）
- INSERT （マルチテーブル）
  - （クエリからの）列値を持つ1つ以上の行をテーブルに挿入することにより、複数のテーブルを更新する
  - 無条件挿入と条件付き挿入の両方をサポートする
    - 無条件のマルチテーブル挿入
      - INSERT ALL
    - 条件付きマルチテーブル挿入
      - INSERT ALL WHEN, INSERT FIRST WHEN ...
MD5ハッシュ関数
- MD5ハッシュは、Data Vault2.0でHASH_DIFF概念を使用して変更データをキャプチャするために利用される
- MD5 , MD5_HEX
  - 128ビットの MD5 メッセージダイジェストを含む32文字の16進数でエンコードされた文字列を返す
Snowflakeの動的なクエリ最適化機能
- 複数のPIT（特定時点）テーブルをデータボルトの1つの結合クエリから並行して読み込むことが可能
- Snowflakeのパフォーマンスチューニングの話とニアゼロメンテナンスの側面を表していると思われる

スタースキーマ

主に2種類のテーブル「ディメンションテーブル」「ファクトテーブル」で構成される、ベーシックなDWHのモデリング
シンプルな構造で、クエリ実行のパフォーマンスにも優れる
26 Quick Tips To Save You Money On Your Snowflake Deployment
- 以下のような言及がある
  
  Data Modeling
  8. Do a data model for analytics
  Star Schema, 3NF, Data vault are optimal for SF
- 「スタースキーマを用いることは最適(な案の1つ)」と書かれている
例えばBIクエリ用に設計されたモデリングアプローチとして使用される
- スタースキーマにより、キューブの処理が高速化される

ファクトテーブル

スタースキーマの中心に位置するテーブル
DWHでの解析で利用される
数値、ビジネスプロセス、トランザクションデータ等を扱う

ディメンションテーブル

ファクトテーブルを中心としてその周辺に位置するテーブル
キー情報(主キー、外部キー)や属性情報(製品名、価格、単価、顧客情報等)を持つ

テナントモデル / マルチテナンシーモデル (DESIGN PATTERNS FOR BUILDING MULTI-TENANT APPLICATIONS ON SNOWFLAKE)

MTT、OPT、APTの3種類が紹介されている

テナントモデルには、セキュリティ、ストレージ、コンピュート、接続性に関して異なる利点があり、これらの考慮事項に適切に対処するにはハイブリッドアプローチが必要になる場合がある。

たとえば、マルチテナントテーブルを使用してストレージを統合しつつ、各テナントに専用のコンピューティングリソースを割り当てることで、MTT/OPTハイブリッド設計を形成するような設計が考えられる。

マルチテナントテーブル(Multi-tenant table, MTT)

概要
- 共有テーブルまたはウェアハウス内にテナントを統合する
- テナントを単一の共有オブジェクトに集約することで、テナントはコンピュートやその他のリソースを効率的に共有できる
特徴
- スケーラビリティとアーキテクチャのシンプルさ
- アプリケーションがサポートできるテナントの数という点で、最もスケーラブルな設計パターンといえる(数百万テナントのアプリケーションをサポートする)
- Snowflakeの中では、よりシンプルなアーキテクチャ
- オブジェクトが増加すると、時間の経過とともに無数のオブジェクトを管理することがますます困難になるため、シンプルであることが重要
- MTTの場合、テナントを追加してもオブジェクトの数は増えないが、OPTとAPTにテナントを追加すると、Snowflake内で数百または数千のオブジェクトが作成される可能性がある
- コスト面では、複数の顧客が共有コンピュートやその他のリソースをより効率的に利用するため、通常はMTTの方がコスト効率が高い
- しかし、MTTにはやや厳格な要件がある
  - MTTを使用するには、アプリのデータモデルがすべてのテナントで同じ一般的な形状である必要がある
  - アプリケーションビルダーは、特定のタイプのテナントにのみ適用されるカスタム列を使用して、わずかな差異を実現することができるが、このアプローチではデータにスパース性が生じる

テナントごとのオブジェクト(Object per tenant, OPT)

概要
- テナントを個別のテーブル、スキーマ、データベース、ウェアハウスに分離する
- このアプローチでは、個々のオブジェクトがテナントに割り当てられるが、アプリケーションは単一のSnowflakeアカウント内で動作する
特徴
- OPTは、各テナントのデータモデルが異なる場合に最適
- MTTとは異なり、テナントのデータ形状はテナントごとに一意にすることができる
- しかし、OPTはMTTほど簡単にはスケールしない
- OPTは通常、数十から数百のテナントに対してはうまくスケールするが、数千のテナントデータベースを含むと扱いにくくなる
- セキュリティは、OPTデザインパターンを使用するかどうかの判断に影響することがある
- エンタイトルメントテーブル、セキュアビュー、行レベルのセキュリティを強力なプロセスで管理したくないため、OPTモデルを好む顧客もいるが、ロールベースのアクセス制御（RBAC）を使用して、データベースへの特定のアクセス権を持つユーザーを制御することには抵抗がない
- OPTモデルを使用するアプリケーションの中には、契約上、セキュリティ上、または規制上の要件を満たすために、顧客に専用のコンピューティングリソースを提供するものもある

テナントごとのアカウント(Account per tenant, APT)

概要
- テナントを個別のSnowflakeアカウントに分離する
- OPTとは異なり、アプリケーション内の各テナントは専用のSnowflakeアカウントを持る
特徴
- APTは、アカウントレベルでテナントを分離する
- 通常、顧客にセキュリティ上の強い理由がある場合にこのアプローチを選択する
- たとえば、厳格な規制上の義務に縛られている組織は、次のような場合にこのオプションを選択する
  - テナントごとに専用の接続文字列を実装する必要がある
  - BYOT（Bring Your Own Tool）などのセキュリティ対策が必要な場合
  - アカウント・レベルでテナントごとのIP制限を使用したい
- APTでは、OPTも実装する必要があるため、テナントのデータ形状は多種多様になる
- テナント数は数十から数百が一般的であるが、それ以上のテナント数を持つ顧客も存在する
- 数千のテナントアカウントを管理する場合、APTは扱いにくくなる可能性がある

データモデリングアプローチの種類

主に4つ。

階層型

階層型データベースモデルでは、データはツリーのような構造に整理され、1対多の配置で相互接続されたレコードとして保存される
階層型データベースモデルはXMLおよびGISにおける標準である

リレーショナル

リレーショナルデータ（別名：リレーショナルモデル）では、データとクエリを指定するための手法を提供することでデータを管理する
ほとんどのリレーショナルデータモデルでは、データ定義とクエリ言語にSQLが使用される

エンティティ-リレーションシップ

エンティティ-リレーションシップモデルでは、図を使ってデータとそのリレーションシップを表現する
リレーショナルデータモデルと統合されたエンティティ-リレーションシップモデルでは、基礎となるモデルを理解するためにデータ要素を視覚的に表現する

グラフ

グラフデータモデルでは、選択したドメインによって制限される、データセット内の複雑なリレーションシップを可視化する

その他

「スノーフレークスキーマ(Snowflake schema)」と呼ばれるDWHでのスキーマの概念が元々存在し、これが言葉としてややこしくなる...
この話は、DWH SaaS としての「Snowflake」とは別の話である
例えば「Snowflake」でのスタースキーマについて調べようとすると、「スタースキーマとスノーフレークスキーマ」関連のページがいろいろ引っかかってくる
「SnowflakeのSchema」とか言い出すともっとややこしいことになる
Snowflake公式の記事でもネタになっている

顧客「データVaultはSnowflakeで使えますか？」
私「使えますよ。お客様はどういった点に不安を感じたのですか？」
顧客「いや、Snowflakeという社名ですから、Snowflakeタイプのスキーマにしか対応していないかもしれないと思ったのです。」

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up