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

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

アーキテクチャの概要

EDW は一連のレイヤーとして捉えます。データが順に進む 5 つの連続したレイヤーと、データを探索・開発する 1 つの開発レイヤーがあります。各レイヤーには EDW の運用と有効性における目的があります。EDW 内のすべてのデータは Landing に到着します。その後のレイヤーはすべて任意ですが、Tableau は prod データベーススキーマにのみ接続してください。

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

重要なスキーマ

EDW の本番データベースは、GitLab のデータコンシューマーがレポートと分析に使用します。COMMON_、SPECIFIC、LEGACY_、WORKSPACE_、SEMANTIC の 5 つの主要なスキーマで構成されます。各スキーマの説明は次のとおりです。

私たちのウェアハウスアーキテクチャは、5 つの異なるスキーマで構成されています。

1. COMMON スキーマ： エンタープライズ次元モデル（EDM）を格納し、統合されたアプリケーションデータの中核として機能します。Kimball 手法を実装して最高のデータ品質基準を確保します。
2. SPECIFIC スキーマ： 他のシステムとの統合を必要としない独立したアプリケーションデータを維持し、不要な複雑さを避けつつ Trusted Data Development プロセスに従います。
3. WORKSPACE スキーマ： 将来の EDM ソリューションのステージング領域として、実験とプロトタイピングのための柔軟な環境を提供します。
4. LEGACY スキーマ： 重要なシステムを現代のアーキテクチャへ段階的に廃止・移行する間、歴史的なモデリング手法を維持します。
5. SEMANTIC スキーマ： エージェント型ツールと AI ツールがセマンティックレイヤーへアクセスする主な入口として機能し、データを正しくクエリ・解釈するために必要な文脈を含む Agent Skills を埋め込んだ、厳選・文書化済みビューを提供します。

次元モデリングの基礎

次元モデリングは Ralph Kimball が開発した Business Dimensional Lifecycle 手法の一部です。ビジネスプロセス志向を保ちながら高性能なアクセスを可能にする、標準的で直感的なフレームワークでデータを提示します。

レイヤー

Landing

Landing レイヤーは、ソースシステムのデータを EDW にコピーする場所です。従来の SQL テーブルとファイルベースのデータの両方を含められます。このデータはソースシステムからエクスポートされた状態のまま意図的に変更せず、データ読み込みの監視と追跡を容易にします。

Staging

Staging レイヤーは、最初の管理的な変換を行う場所です。これらの変換は、既知で予測可能な動作をするデータセットを作り、データを扱いやすくする GitLab の標準規則に適合させます。変換はデータウェアハウス内にとどめつつ、できるだけデータソースに近く、他の変換より前に実行するのが最適です。一般的な変換は次のとおりです。

データ型の適合： データ型を適合させる一部として、NULL と空白の値をステージング中に扱います。実際には、空白値を NULL に変換します。NULL 値を許容できない場合は、空白値と NULL 値を想定される既定値に変換します。この変換により、下流の変換の結合・フィルタリング条件が単純になり、比較演算が期待どおりに動作します。

カラム名の標準化： 列名を適合させると、変換の自己文書化が進み、将来の変換の可読性が高まります。データモデル間で名前が繰り返されないよう注意してください。

データのクレンジング： 誤ったデータレコード（重複など）の削除は、ビジネス上の問いのためのフィルタリングとは異なります。データ形式に問題がある場合の追加エラー処理ロジックを減らせるため、下流の変換を効率化します。

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

Preparation

Preparation レイヤーは、一般的なビジネスロジックの変換をデータに初めて適用する場所です。これらは中間的な変換であり、保守と拡張を可能にする形でデータを整理します。多くの場合は単一のデータモデルで実行できますが、性能、可読性、保守性が上がる場合は、分離し、できれば順番に実行するデータモデルを使えます。原則として、性能を高めるため、できるだけ早く、できるだけ単純なデータに変換を適用します。一般的な変換は次のとおりです。

フィールドの計算： 計算フィールドはソースシステムに由来しませんが、単一データセット内のデータにビジネスロジックを適用して作れるフィールドです。

フィールドの導出： 導出フィールドはソースシステムに由来しませんが、複数のデータセットにまたがるデータにビジネスロジックを適用して作れるフィールドです。

レコードの導出： 日付間隔データのファンアウトなどの導出レコードは、ソースシステムに由来しませんが、結合または集計によって作られるレコードです。これらの変換はデータの分析粒度を設定するために使います。

モデリング

モデリングレイヤーは、形を標準化して保守と拡張を容易にする正式な構造へデータを変換する場所です。変換は一般的なビジネスロジック（ビジネスプロセスを反映）と採用した標準に基づき、生成するモデルの種類に応じて追加の結合、フィルタリング、フィールド生成を必要とする場合があります。原則はモデル数を最小化し、セマンティックレイヤーでできるだけ多くのレポートニーズに対応するよう設計することです。一般的な変換は次のとおりです。

ファクトとディメンションの作成： Kimball 次元モデリングの原則を使い、データをフィルタリング、グループ化、結合して、レコードの属性を説明する再利用可能なディメンションモデルと、ビジネスプロセスのトランザクションを表す低粒度のファクトを作ります。

ビッグテーブルの作成： ビッグテーブルモデルは、できるだけ多くの関連属性を単一の幅広いテーブルに提供することを目的とします。複数のデータソースをまたいで使う必要がない場合や、データが非常に大きく、下流の結合を再設計する必要がある場合に有用です。

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

登録済みクエリ

登録済みクエリは、GitLab チームメンバーが少ない手間で再利用可能な SQL を、ドキュメントとテストを備えたビューとしてデータウェアハウスに保存できる、軽量なワークスペースのサブタイプです。正式な EDM のレイヤー構造とは別の独立したスキーマに配置され、データチームが簡易なレビュープロセスで管理します。ユーザーが管理するクエリとは異なり、登録済みクエリは上流の変更による不具合を監視し、基本的なデータ品質テストを備え、ほかのチームメンバーも見つけられます。そのため、信頼性と共有のしやすさが必要である一方、完全な次元モデリングまでは必要ないクエリに適しています。登録済みクエリは常にビューであり、ほかの dbt モデルから参照できません。より高いパフォーマンスや下流のモデリングが必要な場合は、データチームのほかのサービスを利用してください。

依頼と実装の詳しいプロセスについては、登録済みクエリを参照してください。

セマンティック

セマンティックレイヤーは、ビジネスレポートのニーズに合わせてデータを変換する場所です。この変換で特定のビジネスロジックを適用します。一般的な変換は次のとおりです。

マートテーブルの作成： マートテーブルは、多くの関連するビジネス上の問いに答えるために必要なレコードと列を提供します。ファクトとディメンションテーブルを直接結合して次元モデリングスキーマを具体化するか、モデリングレイヤーの他テーブルから導出できます。通常はセマンティックレイヤーの他テーブルではなく、モデリングレイヤーのテーブルから作成してください。

レポートテーブルの作成： レポートテーブルは、単一のビジネス上の問いに答えるために必要なレコードと列を提供します。通常はセマンティックレイヤーのマートテーブルから、フィルタリング、集計、列選択を通して作りますが、他レイヤーのテーブルから直接作ることもできます。列名は、以前のレイヤーの標準と一致しなくても対象レポートのニーズに合わせて変更できます。

ワークスペース

ワークスペースは、データウェアハウスで探索と初期開発を行うレイヤーです。正式な EDM 構造へコミットする前に、アナリストがデータ変換を試すために設計されています。本番モデルの恒久的な場所ではなく、一時的な開発領域と考えてください。

原則として、可能な限り新しいモデルは適切な EDM スキーマで直接開発します。これにより最初から一貫した命名規則を確保し、将来の移行を避け、Tableau ワークブックのリネージをきれいに保ち、重複開発を減らせます。EDW の最終目的は、構造化され信頼できるデータモデルを通じてレポートを作成し価値を提供することです。開発は柔軟性を提供しますが、価値のあるモデルを適切な本番スキーマで成熟させることを常に目標にしてください。

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

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

ワークスペースを使用しない場合：

1. 最小限の変換で既存の EDM テーブルを結合する
2. ビジネスで定期的に使用される新しいレポートまたはダッシュボードを作成する
3. EDM ソースに標準的なビジネスロジックを適用する
4. 既存の次元モデルを追加のメトリクスまたは属性で拡張する

継続的なレポート作成にとって価値のあるモデルは、ワークスペースから適切な EDM スキーマへ移行する必要があります。定期レビューでは、ビジネスレポートに不可欠になったワークスペースモデルを特定し、強固なデータガバナンスを維持するためにその移行を優先する必要があります。

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

有用なリンクとリソース

• 現代のデータウェアハウスにおける Kimball 次元モデリング
• 次元モデリングマニフェスト
• 次元モデリング技法
• Kimball バスマトリクス
• 次元モデリング開発プロセス

コアコンセプト

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

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

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

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

開発プロセス

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

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

次元モデリングの利点

次元モデリングは、ビジネスチームがデータへ簡単にアクセスできるようにしながら、一貫した定義を保つ、実績ある業界標準の手法です。柔軟なアーキテクチャにより新しいサブジェクト領域をシームレスに統合でき、ディメンションを追加するほど分析能力が高まり、エンタープライズ分析の基盤はさらに堅牢になります。

スキーマ

このスキーマ設計は、初期取り込みから最終利用まで、データがウェアハウス内を自然に進む流れを反映します。生データは専用スキーマに入り、Preparation スキーマで変換され、最終的に人によるレポート・分析の次元モデルを支える利用可能なスキーマ、または同じデータに対する厳選されたエージェントアクセス可能なインターフェースを提供する AI Semantic スキーマに配置されます。このレイヤー方式により、パイプライン全体でデータ品質と一貫性を確保しながら、処理の各段階で明確な引き渡しを維持できます。各スキーマはデータの移動におけるチェックポイントとして機能し、データウェアハウスの完全性を維持する明確な責任とガバナンス規則を持ちます。

Common Prep スキーマ

Common Prep スキーマはデータアーキテクチャの重要な中間レイヤーとして機能し、データ品質、保守性、使いやすさを保証する 4 つの基本原則に従います。

コア原則

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

1. 真実の単一ソース 次元エンティティごとに 1 つの prep モデルを維持します。たとえば、個別のバリエーションではなく単一の prep_charge モデルを使い、特殊なバージョンは FACT、MART、REPORT モデルとして下流へ送ります。この方法は次のことを実現します。

• データリネージを簡素化する
• コードを DRY に保つ
• 保守の負荷を下げる
• 重複実装を防ぐ

1. 最低粒度の保持 次元エンティティで可能な限り低い粒度に prep モデルを保ちます。これにより、次のことを実現します。

• 真実の単一ソース（SSOT）として確立する
• 柔軟な下流モデリングを可能にする
• 多様なモデルタイプ（DIM、FACT、MART、MAPPING、BDG、REPORT）を支える
• 将来の分析能力を制限しない

1. 包括的なデータ保持 COMMON_PREP スキーマでレコードをフィルタリングしません。代わりに次のことを行います。

• COMMON スキーマと下流でフィルタリングを実装する
• さまざまなユースケースのためにデータ可用性を維持する
• 早すぎるデータ除外を防ぐ
• 多様な分析ニーズを支える

1. 実用的なモデル作成 Common スキーマへの直接変換の方が効率的なら prep レイヤーを省略します。

• パターンに基づくだけのモデリングを避ける
• 不必要な複雑さを排除する
• 価値の追加に集中する
• モデルの効率性を維持する

ユースケース

このスキーマには 6 つの重要な機能があります。

1. サロゲートキーの生成 Common Schema 全体で使うキーを作成・管理します。
2. データクレンジング データ型を標準化し、NULL 値を一貫して扱います。
3. ビジネスロジックの適用 データ結合前に必要な変換を実装します。
4. 参照データの統合 適切に結合するため、外部キーと識別子フィールドを組み込みます。
5. ソースの統合 一貫した形式で複数のデータソースを結合します。
6. パフォーマンスの最適化 大きなデータセットを効率的に処理できるよう分割します。

COMMON_PREP スキーマは任意ですが、適切に使うと大きな価値があります。これらの原則は、不必要な複雑さを防ぎながら多様な分析ニーズを支える、クリーンで保守しやすく効率的なデータモデリングの基盤になります。

Common Mapping スキーマ

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

Common スキーマ

Common スキーマは、エンタープライズ次元モデルを構成するすべてのファクトとディメンションを格納する場所です。Common スキーマには、複数のスタースキーマを作成するさまざまな種類のディメンションとファクトが含まれます。このスキーマのモデルは堅牢であり、GitLab のビジネスプロセスを分析する基盤を提供します。

私たちの次元モデルは、ディメンション（コンテキストを提供する）とファクト（イベントを測定する）という 2 つのコアコンポーネントを中心に構成されています。効果的なデータモデリングには、各コンポーネントの役割と特性を理解することが不可欠です。

ディメンションテーブル

ディメンションテーブルは、ビジネスイベントにコンテキストを与える記述的な属性を提供します。これはデータにおける「誰が、何を、どこで、いつ、なぜ、どのように」を表します。ディメンションテーブルは通常、顧客、製品、場所などのビジネスエンティティを表します。

ディメンションの特性

• 記述的な属性（テキストベースまたはカテゴリ型）を含む
• 通常、ファクトテーブルよりも行数が少なく、列数が多い
• 時間の経過に対する変化が比較的遅い
• クエリとフィルタリングの入口を提供する
• 階層関係を含む

一般的なディメンションの種類

適合ディメンション 適合ディメンションにより、複数のファクトテーブルとデータマートにわたって、ファクトとメジャーを一貫して分類および記述できます。これらのディメンションは、複数のファクトテーブルにわたって一貫した意味を維持します。この標準化により、信頼できる分析レポーティングが確保され、データウェアハウス全体での再利用性が促進されます。適切に実装すると、各サブジェクトエリアを独立して分析しながら、関連エリアとインサイトを組み合わせる能力を維持できます。ただし、サブジェクトエリア間でディメンションにわずかな違いでもある場合、このエリア横断分析の能力は機能しなくなります。Kimball は、この標準化された共有ディメンションのセットを「conformance bus」と呼んでおり、共通ディメンションのシームレスな統合を促進し、複数のサブジェクトエリアにわたる包括的なレポーティングを可能にします。例：

• さまざまなビジネスプロセスで使用される日付ディメンション
• セールスとマーケティングで使用される顧客ディメンション

ローカルディメンション 単一のビジネスプロセスまたはファクトテーブルに固有のディメンションで、特定のイベントまたはメトリクスにコンテキストを提供します。例：

• サポートチケットのステータス
• 注文タイプ
• キャンペーン属性

ディメンションテーブルのキー

1. サロゲートキー： dbt_utils.surrogate_key マクロで生成するハッシュ化キーです。主キーとして機能し、ソースアプリケーションデータに由来せず、ディメンションとファクトを結合するために使用します。2022 年 6 月以降、_sk 接尾辞（例：dim_order_type_sk）を使用し、dim_ を前置する必要があります。最終ディメンションテーブルの最初の列として、--Surrogate Key コメントセクションに置く必要があります。
2. 自然キー： ソースシステムから取得します。単一フィールドまたは複合にできます。ディメンションテーブルの 2 番目の列（複数可）として、--Natural Key コメントセクションに置く必要があります。一貫性のため、単一フィールドの自然キーには dim_ プレフィックスを使用します。
3. 欠損メンバー値： すべてのディメンションには、欠損メンバーのレコードが必要です。dbt_utils.surrogate_key（MD5('-1') と同等）を使用して生成します。自動生成には missing member column macro を使用できます。

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

時間的視点の理解

データ分析では通常、現在と履歴という 2 つの視点が必要です。現在のビューでは最新のディメンション値を使用しますが、履歴分析では特定の時点で物事がどのように見えていたかを理解する必要があります。例：

• 以前の製品カタログを使ったセールスの分析
• 時間の経過に伴う顧客所在地の変更の追跡
• 組織構造の理解

ディメンションのタイプ

時間ベースの変更を処理するために、3 つのアプローチを実装しています：

タイプ 1 ディメンション

• 変更時に値を上書き
• 現在の状態のみを維持
• 最もシンプルな実装
• 履歴コンテキストを失う

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

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

タイプ 3 ディメンション

• 現在の値と代替の値を維持
• 複数の分析的視点を可能にする
• 二重の分類ニーズをサポートする
• 現在 EDM では実装されていない

実際の SCD

スナップショットテーブルは履歴追跡システムの中核を成し、ビジネスオブジェクトを作成から現在の状態に至るまで、変更のたびに完全なライフサイクルを取り込みます。これらのテーブルは、効率的な履歴分析を可能にしながら、変更の詳細な監査証跡を維持します。

私たちの実装では、ゆっくりと変化するディメンションは dbt のスナップショット機能を使用して作成します。dbt スナップショットは、データの履歴変更を追跡するシンプルかつ強力な方法を提供します。スナップショットを実行すると、dbt はデータの現在の状態を前回のスナップショットと比較し、valid_from と valid_to の日付を通じて変更を自動的に追跡します。

スナップショットは有効期間を通じて変更を追跡し、各状態にこれらのタイムスタンプを付けます。たとえば、単純な状態変更は次のようになります：

この形式は履歴データを効率的に格納しますが、ビジネスユーザーが分析するには難しい場合があります。使いやすさを改善するために、これらのスナップショットを COMMON スキーマ内の日次粒度レコードに変換します。これらの _daily_snapshot モデルは、次元モデルとの一貫性を維持しながら有効期間を個々の日のレコードへ展開し、時間ベースの分析をより直感的にします。

モデル開発では、まず COMMON_PREP のステージングモデルでビジネスロジックを実装し、次に dbt のスナップショット機能を使用して変更を追跡します。この基盤により、パフォーマンスへの影響を管理しながら、必要に応じて日次スナップショットを作成できます。

スナップショット実装のベストプラクティスには、明確な現在レコードインジケーターの追加、関連モデル間での一貫した粒度の維持、有効期間の徹底的な文書化が含まれます。これらのプラクティスにより、多様な分析ニーズに対応しながら履歴追跡の正確性とパフォーマンスを維持できます。

ファクトテーブル

ファクトテーブルは、分析したいビジネスイベントを記録します。ビジネスプロセスの定量的なメトリクス（メジャー）と、関連するディメンションへの参照を含みます。

主要な特性

ファクトテーブルは数値メジャーを含むビジネスイベントを取り込み、新しいイベントの発生に伴って通常は継続的に増加します。多くの行（それぞれが単一のイベントを表す）を持ちますが、列数は比較的少ないことが特徴です。

これらのテーブルのメジャーの大部分は集計できますが、平均のように部分的にしか集計できないものや、パーセンテージのようにまったく集計すべきでないものもあります。各ファクトテーブルは特定のビジネスプロセスを表し、ディメンションテーブルにリンクする外部キーを含むことで、メジャーにコンテキストを提供します。

ファクトの種類

アトミックファクト ファクトテーブルは、ビジネスイベントを最も細かい粒度で取り込むことで、ファクトベース分析の基盤を形成します。各行は、完全でフィルタリングされていないデータを持つ個々のビジネスイベントを表し、最大レベルの詳細を保持します。この粒度を維持することで、アトミックファクトはさまざまな分析ニーズに柔軟な集計オプションを提供します。

派生ファクト 派生ファクトは、明確なデータリネージを維持しながら特定の分析ニーズに対応するため、アトミックファクトの上に構築される特殊なビューです。大きなアトミックファクトテーブルの対象を絞ったサブセットを作成することで、パフォーマンスを改善します。たとえば、アナリストが通常、大きなイベントテーブルのわずか 10% だけを扱う場合、派生ファクトでその部分だけを抽出してクエリ速度を改善できます。これらのテーブルは、よく使われる集計を事前に計算することでメトリクスも標準化します。

さらに、「drill across facts」を通じて、共有する適合ディメンションを介して複数のファクトテーブルを結合し、統合された分析ビューを作成できます。共通ディメンションで完全外部結合を使用することで、このプロセスは次元的一貫性を維持しながら関連するビジネスプロセスをリンクする派生ファクトテーブルを作成し、複数のビジネスエリアにわたる分析を可能にします。

ファクトテーブルのキー

• 主キー： ファクトテーブルの最初の列でなければなりません。<table_name_without_fct_prefix>_pk として命名します（例：fct_event の event_pk）。--Primary Key コメントセクションに置く必要があります。作成には dbt_utils.surrogate_key マクロまたは連結関数を使用できます。
• 外部キー： --Foreign Keys コメントセクションに置く必要があります。これらはディメンションからのハッシュ化されたサロゲートキーです。さらに Conformed Dimensions と Local Dimensions のサブセクションに分類できます。すべての外部キーでは、欠損メンバーを処理するために get_keyed_nulls マクロを使用する必要があります。

特殊用途テーブル

ブリッジテーブル

ブリッジ（bdg_）テーブルは common スキーマに置かれ、次元モデルで重要な役割を果たします。これらの中間テーブルは、テーブル間の多対多関係を解決し、適切な関係管理を確保しながらデータモデルの柔軟性を維持します。

Common Mart スキーマ

Common Mart スキーマはディメンションとファクトをビジネスにすぐ使える分析モデルへ結合し、ビジネスユーザーと分析ツールの主なアクセスポイントとして機能します。

目的と構造

マートレイヤーは、関連するファクトとディメンションを結合することで、次元モデルをビジネス固有のデータセットへ変換します。共通の属性を事前に結合し、標準的なビジネスルールを適用することで、マートは各ビジネスドメイン内の特定の分析ニーズに合わせてデータを最適化します。

ビジネスドメイン別の編成

マートモデルはビジネス機能別に編成され、データを Finance、Marketing、People、Product、Sales などの焦点を絞った領域に分離します。この機能別の編成により、各部門は適合ディメンションを通じてより広範なデータウェアハウスとの接続を維持しながら、分析ニーズに合わせて特別に調整されたデータを利用できます。

主な特性

マートモデルは Enterprise Data Model のファクトテーブルおよびディメンションテーブルに直接基づいて構築され、一貫したビジネス定義と標準化された関係を確保します。データリネージを維持し複雑さを防ぐため、他のマートモデルをソースとして参照することはありません。

分析を念頭に設計されたこれらのモデルは、一般的なクエリパターンに対して事前結合済みのテーブルを備え、頻繁に使用される計算を含みます。データの粒度は、ユーザーニーズとパフォーマンス要件のバランスをとるよう慎重に検討されます。

この設計では、テーブルとフィールドに技術的な用語ではなく馴染みのあるビジネス用語を使用し、ビジネスユーザーを最優先にします。このビジネス指向の構造とドキュメントは、一般的な分析パターンに合わせることでセルフサービス分析を支援し、データへのアクセスと理解を容易にします。

ベストプラクティス

• モデルの対象を特定のビジネスドメインに絞る
• 前提条件と制限事項を文書化する
• 関連するマート間で命名の一貫性を維持する
• ビジネスロジックを定期的にテストする
• 最適化のため使用パターンを監視する
• ソースモデルへの明確なリネージを維持する

特殊用途テーブル

スキャフォールドテーブル

スキャフォールドテーブルはファクトテーブル間の基盤構造として機能し、可視化や分析におけるすべての可能なディメンションの組み合わせを包括的にカバーします。Tableau のような可視化ツールで作業する場合、これらのテーブルは欠損を補い、実績と目標の一貫した比較を可能にするため、特に価値があります。データポイントが欠けている場合でも連続したビューを維持する必要がある時間ベースの分析で、特に役立ちます。この完全なディメンションフレームワークを提供することで、スキャフォールドテーブルは、データが存在しない期間や組み合わせを含む全体像をアナリストが確認できるようにし、レポートやダッシュボードで誤解を招く空白が生じるのを防ぎます。これらのスキャフォールドテーブルは、common_mart スキーマ内に rpt_scaffold_ プレフィックスで配置され、完全なディメンションの組み合わせを維持しながらファクトテーブルを基に構築されます。

目標と実績のレポートでは、データの完全性と一貫性を確保するためにスキャフォールドテーブルを使用します。このテーブルは、販売活動の有無にかかわらず、すべての期間と属性の組み合わせをカバーする包括的な構造を維持します。

AI Semantic スキーマ

AI Semantic スキーマは、エージェント型ツールと AI ツールのために特別に設計した、データウェアハウスへの厳選され制御されたインターフェースです。ウェアハウスのイントロスペクションやメタデータのクロールに頼るのではなく、エージェントが確実に検出して利用できる、安定して意図的に設計された一連のビューを提供します。

この目的には 2 つのスキーマがあります。

• prod.SEMANTIC — エージェント型ツール用の公開ビュー
• prod.RESTRICTED_SAFE_SEMANTIC — 機密データを公開するビューのアクセス制御版

主要な設計原則

これらのスキーマのすべてのオブジェクトは非マテリアライズドです（ビュー、関数、セマンティックビュー）。これにより、完全なモデル再ビルドなしで変更を直ちにデプロイできます。ビューは既存のレポートテーブルへの入口として機能し、ビジネスロジックの重複を避けます。すべてのオブジェクトは保守性、テスト可能性、スケーラブルな開発のため dbt で管理します。

ビューの種類

ドキュメントのパターン

各ビューは、エージェント利用のために設計したパターンに従って文書化します。

• スキーマの説明 — 個別ビューの説明とともにエージェント検索に参加する、スキーマ自体の説明
• 短い説明 — エージェントのコンテキストウィンドウを圧迫せず、候補ビューを見つける段階的開示検索で使う、ビューの簡潔な概要
• 完全な利用説明 — ビューを選択後に読み込む包括的な説明です。利用ガイダンス、パラメーターの期待値、結果の解釈など、ビューを正しくクエリ・解釈するために必要な文脈をすべて含む Agent Skill として構造化され機能します。
• カテゴリと優先度 — 検索結果の順位付けとフィルタリングに使うメタデータ

エージェントによるスキーマの利用方法

エージェントは段階的開示のパターンでこれらのスキーマを利用します。

1. スキーマの説明とビューの短い説明を使って関連ビューを検索し、各結果の詳細をすべて読み込まずに順位付けした一致を返します。
2. 最も関連するビューを選択して、完全なクエリ文脈を提供する用途固有の Agent Skill として機能する完全な利用説明を読み込みます。
3. 埋め込まれたガイダンスを使ってビューを直接クエリするか、基礎となる SQL を読んで根拠のあるアドホックな変更を行います。

Specific スキーマ

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

変換なしビュー

変換なしビューは、追加の変換をせずにレポートで必要となる生ソースデータの直接ビューにしてください。後続のテーブル構築には使わず、さらなる変換にはより良いリネージドキュメントを提供する上流の RAW または PREP データベース内テーブルを使用します。常に追加の変換やフィルタリングをしないビューとして作成し、ntv_ を前置します。

エンタイトルメント

Snowflake と Tableau の両方で行レベルセキュリティを容易にするため、ユーザーまたはロールと参照可能なデータレコードを対応付けるエンタイトルメントテーブル専用のスキーマを使用します。このスキーマのテーブルは標準形式に従いますが、正確な構造に限定されません。これらのテーブルは他テーブルと結合し、クエリ実行者に対して 2 番目のテーブルを適切なレコードに制限するために使用します。

命名

エンタイトルメントテーブルの名前は、組み合わせて使う他のテーブルと使用するアプリケーションをユーザーに示す必要があります。エンタイトルメントテーブルを使う対象テーブルは、データウェアハウスモデルのドキュメントに記載します。たとえば Tableau で mart_team_member_directory テーブルと使うエンタイトルメントテーブルは ent_team_member_directory_tableau と命名します。

形式

各エンタイトルメントテーブルには少なくとも 2 列が必要です。ほかのテーブルに接続してレコードのサブセットを表す結合キーと、Tableau ユーザーまたは Snowflake ロールを表す列です。ほかのテーブルと結合する列は、正しいテーブルを使いやすくするため、そのテーブルと同じ名前にします。結合キー列の値は対応するテーブルのその列の値を表します。Tableau ユーザーまたは Snowflake ロールを表す列は、それに合う名前にします。

ユーザーと結合キーの組み合わせはすべて、テーブルの 1 行として明示的に含める必要があります。

例

Snowflake で mart_team_member_directory テーブルに直接行レベルセキュリティを実装する場合、次のテーブルを作成します。

ent_team_member_directory_snowflake

次に、mart_team_member_directory テーブルへ行アクセスポリシーを適用します。

Tableau のデータソースで mart_team_member_directory テーブルに行レベルセキュリティを実装する場合、次のテーブルを作成します。

ent_team_member_directory_tableau

次に、Tableau Developers Guideのガイドラインを使って、データソースとフィルターを作成します。

技術的な実装詳細

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

Tableau は主要な可視化ツールであるため、人によるレポートを目的とするすべての EDW モデルは、一貫した命名規則に従い、移行を慎重に計画して Tableau との互換性を念頭に設計してください。このガイダンスは COMMON、COMMON_MART、SPECIFIC、および関連スキーマのモデルに適用します。AI Semantic スキーマ（SEMANTIC と RESTRICTED_SAFE_SEMANTIC）のオブジェクトはエージェント型ツール利用のために設計されており、AI Semantic スキーマセクションで説明する別の設計パターンに従います。

モデルは命名標準に従い、目的と EDW レイヤーを表す正しい接頭辞（mart_、rpt_、fct_、dim_ など）を使います。テーブル名の変更で Tableau ワークブックが壊れるため、最初から安定した名前を選ぶことが重要です。移行はステークホルダーと調整し、月末や四半期末など利用の多い時期を避けて予定し、依存するすべてのレポートをテストして継続的な機能を保証してください。

モデルをスキーマ間で移動または改名する場合、Tableau 接続を維持することが重要です。推奨する方法は、モデルの SQL を適切なスキーマへ移し、以前の場所から既存モデルを削除することです。Snowflake では、ステークホルダーが Tableau ワークブックを再指定するまで、テーブルは更新後の場所に存在すると同時に以前の場所にも存在します（ただし以前の場所では更新されません）。すべての依存関係を更新後、古いテーブルを削除できます。依存関係が少なく、ステークホルダーが迅速に更新を調整でき、元の場所のデータが短期間古くても許容できる場合に最適です。

依存関係が多い場合や、現在のデータに中断なくアクセスする必要がある場合は、古いバージョンと新しいバージョンを並行稼働する段階的ロールアウトでリスクを減らせます。元の名前で新しいテーブルを指すビューを作成するか、dbt の alias 機能で基礎モデルまたは場所を変更しながら公開テーブル名を保つことで実現できます（例：MR）。

命名標準

命名規則から始めて、セルフサービスデータ環境を意図的に整理することが重要です。目標は、初級者、中級者、上級者がデータウェアハウスを簡単に操作できるようにすることです。私たちは、次のベストプラクティスに従ってこれを実現します。

1. PREP テーブル：prep_<subject> = 生データをクリーンアップし、次元分析のために準備します。
2. FACT テーブル：fct_<verb> = 発生するイベントまたは現実世界のプロセスを表します。ファクトはアクションまたは「動詞」であることから識別できます。（例：session、transaction）
3. DIMENSION テーブル：dim_<noun> = ディメンションテーブルです。ディメンションはファクトレコードに記述的な文脈を与え、「人、場所、物」などの「名詞」であることから識別できます。（例：customer、employee）ディメンション属性は「形容詞」として機能します。（例：customer type、employee division）
4. MART テーブル：mart_<subject> = 最小限のフィルターと集計でディメンションおよびファクトテーブルを結合します。そのため幅広いレポート目的に使用できます。
5. REPORT テーブル：rpt_<subject> = dim、fact、mart テーブルの上に構築できます。非常に具体的なフィルターを適用するため、限られたレポート目的に適用できます。
6. PUMP テーブル：pump_<subject> = dim、fact、mart、report テーブルの上に構築できます。サードパーティツールへパイプするモデルに使います。
7. MAP テーブル：map_<subjects> = 異なるソースから得たデータ間の 1 対 1 の関係を維持するために使います。
8. BRIDGE テーブル：bdg_<subjects> = 異なるソースから得たデータ間の多対多の関係を維持するために使います。ブリッジテーブルの構築方法については Kimball Group のドキュメントを参照してください。
9. SCAFFOLD テーブル：rpt_scaffold_<subject> = 目的のファクトテーブル間の共通ディメンションのすべての組み合わせを含むテンプレート／設計図を作り、可視化レイヤーを支えます。
10. 単数形の命名を使います。例：dim_customer。dim_customers は使いません。
11. テーブル名と列名の接頭辞を使い、同種のデータをグループ化します。アルファベット順に並べた場合も論理的にグループ化された状態を保てます。例：dim_geo_location、dim_geo_region、dim_geo_sub_region。
12. 主キーおよび外部キーの命名にディメンションテーブル名を使用します。どのテーブルを結合すれば追加属性を取得できるかをユーザーに明確にします。たとえば dim_crm_account の主キーは dim_crm_account_id です。このフィールドが fct_subscription に現れる場合、追加のアカウント詳細を得るには dim_crm_account を結合する必要があると分かるよう、dim_crm_account_id と命名します。
13. ディメンション、ファクト、マートテーブルに運用システムへの参照を含めません。ソースシステム名を抽象化し、データが生成されるビジネスエンティティまたはセマンティックな重要性を表す名前にします。たとえば Salesforce のデータは、次元モデルでは sfdc や salesforce ではなく crm と記述します。
14. AI SEMANTIC ビュー： SEMANTIC および RESTRICTED_SAFE_SEMANTIC スキーマのオブジェクトは、オブジェクトの種類に基づく接頭辞に、オブジェクトが答えるよう設計されたビジネス上の問いを反映する平易な名前を続けます。

    種類	接頭辞	例
    検証済みクエリ	vq_	vq_monthly_arr_by_sales_segment
    検出済みクエリ	dq_	dq_open_opportunities_by_region
    セマンティックビュー	sv_	sv_customer_health_score
    ユーザー定義テーブル関数	udtf_	udtf_arr_for_account_and_period

ファイルベースのデータソース

CSV 以外のデータソースを扱う場合は、ソースシステムからの直接抽出を優先します。ただし、明確な廃止計画があれば、seed ファイル、Sheetload、Driveload を使う一時的なソリューションも許容できます。CSV 型のソースデータには 3 つの選択肢があります。

1. dbt seed

• GitLab によるバージョン管理
• MR で容易に更新可能
• 1,000 行未満に最適
• 小さなデータセットに推奨

1. GCP Driveload

• 安定し予測可能
• 予期しない変更がない
• 手動でのファイル更新が必要
• 大きなデータセットに推奨

1. Sheetload

• チームによるデータ入力を可能にする
• 実装の安定性が低い
• SOX 準拠が難しい
• Tier 1 アセットでは最後の手段

テストフレームワーク

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

時間標準

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

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

これにより、次のことを保証します。

• 一貫した週次レポート
• ISO 8601 との整合
• 正確なメトリクス計算
• モデル全体での標準実装

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

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

リードからキャッシュまでの ERD

プロダクトリリースから導入までの ERD

チームメンバー ERD

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

Lucidchart は、図表の作成、改訂、共有で視覚的に協働し、プロセス、システム、組織構造を改善できる Web ベースの作図アプリケーションです。

エンティティ関係（ER）図は、システム内で エンティティ または オブジェクト がどのように相互に関連するかを表すフローチャートの一種です。ER 図 は、論理とビジネスルールの観点（論理データモデル）および実装する特定のテクノロジーの観点（物理データモデル）から、リレーショナルデータベースをモデル化・設計するために使います。

以下の手順は、Lucidchart の ERD インポート機能 を使用して ER 図（論理・物理データモデル）を作成する方法を示します。データベースまたはスクリプトからデータモデルを作成するこのプロセスは、リバースエンジニアリング とも呼ばれます。

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')

ビッグデータ

ビッグデータは、データサービスの限界を理解するために使う概念です。一般的に、ビッグデータとは、現在のデータサービスの処理・提供能力を超える、または負荷をかけるものです。ビッグデータを扱うには、データサービスの能力を拡張する新しい、または創造的なソリューションの開発・デプロイが必要なため、効率が下がりコストが高くなる場合があります。

ビッグデータとエンタープライズデータウェアハウス

エンタープライズデータウェアハウスにおけるビッグデータは、次の 3 つの一般的なトピックで分類します。

1. ボリューム - 関連するソース、概念、またはモデルにどれだけのデータがあるか
2. ベロシティ - データがどれだけ速く変化し、取り込まれ、利用されるか
3. バラエティ - データソースの構造と形式が他のソースとどのように異なるか

エンタープライズデータウェアハウスには、これらの概念的な領域ごとに制限があり、これらの制限に近づくデータはビッグデータと見なします。

ボリューム

エンタープライズデータウェアハウスに保存できるデータ量に実質的な制限はありませんが、パフォーマンスとコスト効率を維持して変換できる量には制限があります。現在の制限は、XL Snowflake ウェアハウスを使用して 3 時間以内に単一テーブルを作成できることです。たとえば、6 TB と 300 億レコードを超える収集済み Snowplow データは一度にすべて処理できないため、ビッグデータと見なします。

ベロシティ

エンタープライズデータウェアハウスは、厳選された一連のテーブルを提示するためにデータを処理・変換するよう設計されているため、コスト効率を維持してこれらの変換を処理できる速さには制限があります。エンタープライズデータウェアハウスは 24 時間ごとにデータを処理するよう設計されており、ビジネスニーズに対応するためにそれより速い処理が必要なデータはビッグデータと見なします。たとえば、ほぼリアルタイムで Web サイトの行動を評価することは、ビッグデータと見なします。

バラエティ

エンタープライズデータウェアハウスの現在の設計は Snowflake クラウドデータベース上に構築されています。これにより、処理できるデータの形式と構造は構造化テーブルに適合するものに制限されます。JSON などの半構造化データはエンタープライズデータウェアハウス内で直接処理できる場合もありますが、これは限定的であり、まずテーブルの列として取り込む必要があるため効率が低下します。一般に、構造化テーブルに含まれないエンタープライズデータウェアハウスへのすべてのデータ入力またはそこからの出力は、ビッグデータと見なします。たとえば、Version データベースの Service Ping ペイロードは JSON であり、分析できるようになる前に広範な操作が必要なため、ビッグデータと見なします。

アナリティクスパフォーマンスポリシーフレームワーク

問題の説明

エンタープライズデータウェアハウスにおけるデータ量とビジネスロジックの複雑さの増大により、EDW で構築されたデータモデルの変換は時間とともにパフォーマンスが低下しています。日次の dbt モデル本番実行は完了までに 12 時間以上かかります。最大規模の Snowplow、Service Ping、GitLab.com データセットの一部では、L および XL サイズのウェアハウスでクエリの実行に数分以上かかる場合があります。日次の Snowplow イベントデータ量は、今後 12 ヶ月以上で 2.5 倍に増加すると予想されます。したがって、技術的な考慮事項とビジネスニーズおよび要件のバランスを取り、EDW の変換レイヤーでパフォーマンスの高いデータモデルを設計する方法のガイドラインを提供する Analytics Performance Policy が必要です。

dbt モデルの実行は、パフォーマンス、効率性、コストという 3 つの主要な側面で考えます。

1. パフォーマンス は、モデルのビルドにかかる時間に関連します。
2. 効率性 は、モデルがローカルストレージ、リモートストレージ、パーティションプルーニングをどれだけ効率よく使うかに関連します。
3. コスト は、モデルの実行に必要な Snowflake クレジット数に関連し、モデルのパフォーマンスと効率性の両方の影響を受けます。

現時点で、この Analytics Performance Policy の範囲はモデルのパフォーマンスに特に重点を置いています。将来は、全体的な Analytics Scalability Policy にまとめる、効率性とコストに関する別のポリシーを追加することを検討します。

Analytics Performance Policy はデータ変換のみを対象としており、EDW の RAW データベースに抽出・ロードされたデータの保持は対象外です。当面、このポリシーでは RAW データベースのすべてのデータを保持し、データを削除しないと想定します。将来データ保持ポリシーを実装した後、EDW の Transformation レイヤーに重点を置くこの Analytics Performance Policy を再評価してイテレーションします。この Analytics Performance Policy で Functional Teams と合意した内容は、Snowflake の RAW データベースにおけるデータ保持ポリシーに影響を与えるために使用します。

パフォーマンスターゲット

これらの初期パフォーマンス目標は、日次の dbt モデル本番実行を 8 時間の勤務日内に完了し、勤務日内に実行をトリアージできるように設定しました。Snowflake クエリ時間の目標は、数分だったクエリ時間を 1 分へ段階的に改善し、Snowflake でより生産的で快適なクエリ体験を提供するために設定しました。パフォーマンスの継続的な改善と新しいビジネス要件に応じて、これらの目標は将来変更される可能性があります。

1. 本番 dbt DAG の実行時間を 8 時間未満に維持します。既存モデルではウェアハウスサイズを拡張せず、最大として XL ウェアハウスを使い続けると仮定します。同時に実行するスレッド数を増やすことでスケールアウトできると仮定します。
2. 個々の dbt モデルの実行時間は一貫して 1 時間未満とし、その設計で予測されるデータ量の増加を考慮します。
3. Snowflake の Snowplow、Service Ping、GitLab.com ビッグデータセットに対する単純なクエリは、L または XL ウェアハウスで 1 分未満に完了します。

パフォーマンス向上のためのアーキテクチャアプローチ

1. データモデルで変換・提示するデータ量を減らします。
   1. ビジネスニーズと技術的・パフォーマンス上の制約を比較検討して、アトミックファクトテーブル（ビジネスプロセスのすべてのトランザクションを取得する最小粒度）で提示する行数または列数を制限します。例：パフォーマンスを保ち、ビジネス分析に必要な直近 13 ヶ月のデータにモデル内のデータを制限します。
   2. より高い抽象レベルのビジネスプロセスをモデル化するモノリシックなアトミックファクトテーブル（ビジネスプロセスのすべてのトランザクションを取得する最小粒度）を、サブビジネスプロセスをモデル化する小さなデータモデルに分割します。例：エンドツーエンドの SDLC を 1 つの巨大なモノリシックデータモデルでモデル化するのではなく、SDLC（Software Development Lifecycle）を SCM、CI、CD、Security などの構成要素に分けてモデル化します。
   3. Business Analytics のユースケース用に特別に作られた詳細度で、集計データモデルを作成します。例：ビジネスユースケースに応じて、プロダクト利用データをユーザー、namespace、installation、メトリクスの粒度で週、月、四半期、年の時間枠に集計することを検討します。
2. モデルでよくクエリされるユースケースに沿ったクラスタリングキーをデータモデルへ追加することを検討します。
3. データモデルで simple_cte マクロを使うことを評価し、モデルに必要な列のみが選択されていることを確認します。
4. データモデルをインクリメンタルに設定することを検討します。

履歴アーカイブプロセス

1. パフォーマンスポリシーの考慮によりデータモデルで再作成または提示できない非冪等データでは、データプラットフォームのアーカイブ手法を活用してデータの履歴アーカイブを作成します。

たとえば、アトミックファクトテーブルで直近 13 ヶ月のプロダクト利用データのみを提示し、月、メトリクス、namespace の粒度で直近 13 ヶ月のデータだけを提供する集計データテーブルを作成する場合、ライブデータモデルは直近 13 ヶ月のデータだけを提供する一方で、履歴アーカイブテーブルは集計テーブルについて 2 年または 3 年前からのインサイトを提供できます。

ページのソースコードを見る - ページの編集 - please contribute.