エンタープライズデータウェアハウス

エンタープライズデータウェアハウスの概要

アーキテクチャの概要

EDWは一連のレイヤーとして捉えられています。5つの連続したレイヤーがあり、データはこのレイヤーを通じて処理されます。また、データが探索・開発される1つの開発レイヤーがあります。各レイヤーはEDWの全体的な運用と有効性における役割を持っています。EDW内のすべてのデータはLandingに格納されます。その後のすべてのレイヤーはオプションですが、Tableauはprodデータベーススキーマにのみ接続する必要があることに注意してください。

レイヤー	目的	スキーマ例
Landing	ソースシステムからの読み込み非冪等データの生成	raw.salesforce_v2_stitch
Staging	カラム名とデータ型の標準化フィルタリングと重複排除（クレンジング）	prep.salesforce
Preparation	処理中のステップと変換汎用ビジネスロジックの適用	prod.common_prep
Model	磨かれた製品エンタープライズ次元モデル機能データモデル信頼性が高く、検証済みでサポートされている	prod.common
Semantic	論理的および物理的な構成レポートと分析のエントリポイント	prod.common_mart
Workspace	開発中探索高速イテレーション	prod.workspace_sales

各レイヤーで実行される活動の詳細については、レイヤーセクションを参照してください。

重要なスキーマ

EDWの本番データベースは、GitLabのデータコンシューマーによるレポートと分析に使用されます。主要な4つのスキーマCOMMON_、SPECIFIC、LEGACY_、WORKSPACE_で構成されています。

COMMON スキーマ: エンタープライズ次元モデル（EDM）を格納し、統合されたアプリケーションデータの中核として機能します。Kimball手法を実装して最高のデータ品質基準を確保します。
SPECIFIC スキーマ: 他のシステムとの統合を必要とせず独立したアプリケーションデータを維持します。
WORKSPACE スキーマ: 実験とプロトタイピングのための柔軟な環境を提供します。
LEGACY スキーマ: 現代のアーキテクチャへの移行に際して、歴史的なモデリングアプローチを維持します。

次元モデリングの基礎

次元モデリングはRalph Kimballによって開発されたビジネス次元ライフサイクル手法の一部です。

レイヤー

Landing

LandingレイヤーはソースシステムからのデータがEDWにコピーされる場所です。従来のSQLテーブルとファイルベースのデータの両方を含むことができます。

Staging

Stagingレイヤーは最初の管理的な変換が行われる場所です。これらの変換により、予測可能な動作をするデータセットが作成され、GitLab標準の規則に準拠したデータになります。

データ型の適合: NULLおよびブランク値の処理は、データのステージング中に行う必要があります。ブランク値はNULLに変換する必要があります。

カラム名の標準化: カラム名を適合させることで、変換がより自己文書化され、将来の変換の可読性が向上します。

データのクレンジング: 誤ったデータレコード（重複など）の削除は、ダウンストリームの変換を効率化します。

非表形式データのフラット化: Landingレイヤーのデータが非表形式で格納されている場合、他のステージングステップを実行できるようにデータをフラット化することが必要です。

Preparation

Preparationレイヤーは一般的なビジネスロジックの変換がデータに初めて適用される場所です。

フィールドの計算: 計算フィールドは、ソースシステムに由来しないが、単一のデータセット内のデータにビジネスロジックを適用することで形成できるフィールドです。

フィールドの導出: 導出フィールドは、ソースシステムに由来しないが、複数のデータセットにわたるデータへのビジネスロジックの適用によって形成できるフィールドです。

レコードの導出: 日付間隔データのファンアウトなどの導出レコードは、ソースシステムに由来しないが、JoinまたはAggregationを通じて形成されるレコードです。

モデリング

モデリングレイヤーは、データが保守と拡張を容易にする正式な構造に変換される場所です。

ファクトとディメンションの作成: Kimball次元モデリングの原則を使用して、データをフィルタリング、グループ化、結合して再利用可能なディメンションモデルとファクトを作成します。

ビッグテーブルの作成: ビッグテーブルモデルは、できるだけ多くの関連する属性を単一の広いテーブルに提供することを目的としています。

エンタイトルメントテーブルの作成: エンタイトルメントモデルは、SnowflakeとTableauなどのツールでデータレコードへの明示的なアクセスを許可するための人物識別子とJoin条件のリストを作成することを目的としています。

セマンティック

セマンティックレイヤーは、ビジネスレポートのニーズに合わせてデータが変換される場所です。

マートテーブルの作成: マートテーブルは、多くの関連するビジネス質問に答えるために必要なレコードと列を提供します。

レポートテーブルの作成: レポートテーブルは、単一のビジネス質問に答えるために必要なレコードと列を提供します。

ワークスペース

ワークスペースは、データウェアハウス内で探索と初期開発が行われるレイヤーです。

ワークスペースを使用する場合:

EDWでこれまでモデル化されたことのない完全に新しいデータソースを探索する
継続的なレポートには使用されない一時的な分析を作成する
EDM標準を満たさない可能性のある実験的な変換を実行する
本番レポートに影響を与える可能性のある既存のEDMモデルへの主要な変更をテストする

エンタープライズ次元モデル（COMMON スキーマ）

有用なリンクとリソース

コアコンセプト

次元モデリングは2つの主要なコンポーネントを使用します:

ファクト（メジャー）: データの数値的な値。これらは分析したい「いくつ」「いくら」の値です。
ディメンション（コンテキスト）: ファクトに意味を与える記述的な属性。ディメンションはデータの「誰が、何を、いつ、どこで、なぜ」に答えます。

このアプローチにより、いくつかのスキーマパターンが作成されます:

スタースキーマ: 中央のファクトテーブルをディメンションテーブルにリンク
スノーフレークスキーマ: 他のディメンションテーブルにリンクするディメンションテーブル
ギャラクシースキーマ: 相互に接続された複数のファクトテーブル

開発プロセス

次元モデルは4つの主要なステップで構築されます:

ビジネスプロセスを選択する（例: 年間収益の追跡）
粒度を宣言する（例: 顧客ごと）
ディメンションを特定する
ファクトを特定する

スキーマ

Common Prep スキーマ

Common Prepスキーマはデータアーキテクチャの重要な中間レイヤーとして機能します。

コア原則

4つの基本原則が開発と保守を導きます:

真実の単一ソース 次元エンティティごとに1つのprepモデルを維持します。
最低粒度の保持 次元エンティティの最低可能粒度でprepモデルを維持します。
包括的なデータ保持 COMMON_PREPスキーマでのレコードのフィルタリングを避けます。
実用的なモデル作成 Commonスキーマへの直接変換がより効率的な場合、prepレイヤーをスキップします。

Common Mapping スキーマ

ディメンションテーブルをサポートするマッピング/ルックアップ（map_）テーブルはcommon_mappingスキーマで作成する必要があります。

Common スキーマ

Commonスキーマはエンタープライズ次元モデルを構成するすべてのファクトとディメンションが格納される場所です。

ディメンションテーブル

ディメンションテーブルはビジネスイベントにコンテキストを与える記述的な属性を提供します。

ゆっくりと変化するディメンションとスナップショット

タイプ1ディメンション

変更時に値を上書き
現在の状態のみを維持
最もシンプルな実装

タイプ2ディメンション（SCD）

変更に対して新しいレコードを追加
valid_fromとvalid_to日付で有効期間を追跡
履歴分析を有効化

タイプ3ディメンション

現在の値と代替の値を維持
現在EDMでは実装されていない

ファクトテーブル

ファクトテーブルは分析したいビジネスイベントを記録します。

アトミックファクト: ビジネスイベントを最も細粒な形で捉えるファクトテーブル。

派生ファクト: アトミックファクトの上に構築された特定の分析ニーズに対応する特殊なビュー。

Common Mart スキーマ

Common Martスキーマはディメンションとファクトをビジネスに即したアナリティクスモデルに組み合わせます。

Specific スキーマ

SPECIFICスキーマは、エンタープライズ次元モデルの次元モデリング構造に準拠しないがレポート機能を実行し、真実のソースとして機能するテーブルに使用されます。

変換なしビュー

変換なしビューは、さらなる変換なしにレポートに必要な生ソースデータの直接ビューである必要があります。常にビューとしてntv_プレフィックスで作成する必要があります。

エンタイトルメント

SnowflakeとTableauの両方での行レベルセキュリティの使用を促進するために、エンタイトルメントテーブル専用のスキーマが使用されます。

命名

エンタイトルメントテーブルの名前は、他のテーブルへの参照と使用するアプリケーションを示す必要があります。例: ent_team_member_directory_tableau

技術的な実装詳細

Tableau統合のベストプラクティス

Tableauは主要な可視化ツールであるため、すべてのEDWモデルはTableauの互換性を念頭に置いて設計する必要があります。

命名標準

PREP テーブル: prep_<subject>
FACT テーブル: fct_<verb>
DIMENSION テーブル: dim_<noun>
MART テーブル: mart_<subject>
REPORT テーブル: rpt_<subject>
PUMP テーブル: pump_<subject>
MAP テーブル: map_<subjects>
BRIDGE テーブル: bdg_<subjects>
SCAFFOLD テーブル: rpt_scaffold_<subject>
単数命名を使用する（例: dim_customer、dim_customersではない）
テーブルと列名にプレフィックスを使用して同様のデータをグループ化する

テストフレームワーク

モデルは信頼できるデータフレームワーク（TDF）に従ってschema.ymlファイルによるテストとドキュメントが必要です。

時間標準

すべてのシステムで月曜日を週の最初の日として標準化します:

CASE WHEN day_name = 'Mon' THEN date_day
    ELSE DATE_TRUNC('week', date_day)
END AS first_day_of_week

エンティティ関係図（ERD）ライブラリ

これらの図は主要なビジネスプロセスフライホイール全体でエンタープライズ次元モデル内のデータオブジェクト間の関係を示します。

Lead to Cash ERDs

ERDライブラリ

Product Release to Adoption ERDs

ERDライブラリ

Team Member ERDs

ERDライブラリ

Lucidchartを使用したエンティティ関係（ER）図の作成

Lucidchartはユーザーが図表を視覚的にコラボレーションして描画・修正・共有できるWebベースの作図アプリケーションです。

ステップ1: 'Lucidchartアプリ'からブランクのlucidドキュメントを作成します。

ステップ2: ページの左下にある「シェイプライブラリ」の下に表示される「データのインポート」をクリックします。

ステップ3: 「すべてのデータソース」から「エンティティ関係（ERD）」を選択します。

ステップ4: データをインポートするDBMSソースとして「MySQL」を選択します。

ステップ5: Snowflakeで以下のスクリプトを実行します。

The below query can be run in Prod database in Snowflake to get all the Models/tables from COMMON and COMMON_PREP Schemas:

SELECT 'mysql' dbms,
        t.TABLE_SCHEMA,
        t.TABLE_NAME,
        c.COLUMN_NAME,
        c.ORDINAL_POSITION,
        c.DATA_TYPE,
        c.CHARACTER_MAXIMUM_LENGTH,
        '' CONSTRAINT_TYPE,
        '' REFERENCED_TABLE_SCHEMA,
        '' REFERENCED_TABLE_NAME,
        '' REFERENCED_COLUMN_NAME
FROM INFORMATION_SCHEMA.TABLES t
LEFT JOIN INFORMATION_SCHEMA.COLUMNS c
ON t.TABLE_SCHEMA=c.TABLE_SCHEMA
AND t.TABLE_NAME=c.TABLE_NAME
WHERE t.TABLE_SCHEMA NOT IN('INFORMATION_SCHEMA')
AND t.TABLE_SCHEMA IN ('COMMON', 'COMMON_PREP')