【ITニュース解説】(I) Principles of Data Model Architecture: Four Layers and Seven Stages

現代のビジネスにおいて、データは非常に重要な資産であり、これを効果的に活用するためには、データの適切な管理と設計が不可欠だ。システムエンジニアにとって、この膨大なデータをどのように整理し、利用しやすい形にするかは重要な課題であり、そのための設計思想が「データモデルアーキテクチャ」と呼ばれるものだ。この記事では、データレイクとデータウェアハウスという二つの主要なデータ管理システムを統合的に設計するための原則と、具体的なデータの階層構造について解説する。

データレイクは、構造化されていない生データを含むあらゆるデータをそのままの形で蓄積する場所だ。一方、データウェアハウスは、特定の分析目的のために構造化され、整形されたデータを格納する場所である。これらを組み合わせることで、生データの柔軟性と分析データの秩序を両立させ、ビジネスの意思決定を強力に支援できるデータ基盤を構築することを目指す。

なぜデータを階層化する必要があるのかというと、それはデータの構造を明確にし、データの流れを追いやすくするため、重複した設計を防ぎ、生のデータが変更された際の影響を最小限に抑えるためである。適切に階層化されたデータシステムは、ビジネスの現状を迅速にデータでサポートし、将来のビジネス展開にも対応できる柔軟な基盤を提供する。また、安定性と正確性を持ったデータは、新しいビジネスの方向性を示し、データに基づいた意思決定を可能にする。

ここで提唱されるデータモデルアーキテクチャは、「ODS」「DW（DWD/DWM/DWS）」「APP」という主要な4層に加えて、「寸法テーブル層」を設けるものだ。それぞれの層には明確な役割がある。

まず「ODS層（Operational Data Store）」は、データソースに最も近い場所だ。ここでは、データソースから取得した生のデータを、ほぼそのままの形で保持する。後でデータの問題を追跡する可能性を考慮し、この層ではあまり多くのデータクリーニングは行わない。データのノイズ除去や重複排除、異常値の処理といった本格的な加工は、次の層で行う。

次に「DW層（Data Warehouse）」は、データウェアハウス構築の中核となる層である。ODS層から得られたデータを基に、ビジネスのテーマに沿ったさまざまなデータモデルを構築する。このDW層はさらに三つのサブ層に分かれる。

一つ目の「DWD層（Data Warehouse Detail）」は、詳細データ層だ。ここでは、ODS層と同じ粒度のデータを維持しながら、データの品質を保証する役割を担う。具体的には、生のデータをクリーンアップし、統合・標準化する。汚れたデータ、意味のないデータ、形式が不揃いなデータ、状態定義が一貫しないデータ、非標準的な命名のデータなどがここで処理される。さらに、データの使いやすさを向上させるため、ディメンション・デジェネレート（次元縮退）という技術を使って、次元をファクトテーブルに組み込むことで、ファクトテーブルと次元テーブル間の結合を減らす工夫もされる。また、同じテーマのデータを一つのテーブルに集約する部分的なデータ集約も行われる。

二つ目の「DWM層（Data Warehouse Middle）」は、中間データ層だ。この層では、DWD層のデータに対して軽い集約操作を行い、共通して使われる指標の再利用性を高めるための一連の中間テーブルを生成する。これは、特定の統計指標を計算する際に、DWD層やODS層から直接計算すると処理量が多くなりすぎる問題を解決するために役立つ。例えば、よく使われるコアな次元に沿って集計を行い、統計指標を算出する。場合によっては、このDWM層を省略し、すべてのデータをDWS層に含めることもある。

三つ目の「DWS層（Data Warehouse Service）」は、サービスデータ層であり、共通の要約層でもある。ここでは、詳細データよりもやや粗い粒度で軽い集計が行われる。DWD層の基本データに基づき、特定のテーマ領域（例えば、トラフィック、注文、ユーザーなど）のサービスデータを統合・要約し、分析に利用しやすい「ワイドテーブル」を生成する。このDWS層は、一般的なアプリケーションシナリオの約80%をカバーすることを想定しており、「データマート」とも呼ばれる。この層のテーブルはフィールド数が多く、一つのテーブルでより多くのビジネスコンテンツをカバーするため、ワイドテーブルと呼ばれることが多い。

「APP層（Application）」は、データアプリケーション層だ。ここでは、データ製品やデータ分析のためのデータが提供される。オンラインシステムではES、PostgreSql、Redisなどのデータベースに格納され、データ分析やデータマイニングのためにはHiveやDruidなどに格納されることもある。例えば、私たちがよく目にする各種レポートのデータは、このAPP層に配置されるのが一般的だ。

最後に、「寸法テーブル層（Dimension Table Layer）」がある。寸法テーブルの数が非常に多い場合、独立した層として設計される。この層は、ユーザープロファイルや製品プロファイルのようにデータ量が数千万から数億に及ぶ「高カーディナリティ寸法データ」と、設定テーブルや日付寸法テーブルのようにデータ量が数桁から数万程度の「低カーディナリティ寸法データ」の二つのタイプを含む。

このような階層構造に加えて、データモデルを設計する上での重要な原則がいくつかある。

まず、「テーマ領域の分割」だ。これは、ビジネスやビジネスプロセス、またはデータドメインに基づいてデータを分類することである。ビジネスプロセスは、注文、支払い、返金といった企業活動の分割できないイベントを指す。データドメインは、ビジネス分析のためのビジネスプロセスや次元の抽象的な集合であり、現在のすべてのビジネスニーズをカバーしつつ、新しいビジネスが加わった際にも対応できる柔軟性を持つ必要がある。

次に、「高凝集・低結合」という原則がある。これは、一つのテーマ内ではデータやロジックが密接に関連し（高凝集）、異なるテーマ間では互いへの依存度を低くする（低結合）ことを意味する。例えば、詳細層ではビジネスプロセスごとにテーマを分け、要約層では「エンティティ＋活動」に基づいて分析テーマを分け、アプリケーション層ではアプリケーションのニーズに応じてテーマを分ける。

「コアモデルと拡張モデルの分離」も重要だ。共通の核となるビジネスを支える「コアモデル」と、特定のニーズや少数のアプリケーションをサポートする「拡張モデル」を分けて構築する。拡張モデルのフィールドがコアモデルを過度に複雑にしないように注意し、コアモデルのシンプルさと保守性を維持する。

「共通処理ロジックの沈下と単一性」の原則は、共通的に使われる処理ロジックほど、データスケジューリングの依存関係の最下層にカプセル化し、一元的に実装すべきだという考え方だ。共通ロジックが複数の場所に分散して存在することを避け、アプリケーション側で再実装することもないようにする。

「コストとパフォーマンスのバランス」も考慮する必要がある。適切なデータ冗長性は、クエリやデータ更新のパフォーマンス向上に繋がるが、過度な冗長性やデータの複製は避けるべきだ。効率性とコストの間で最適なバランスを見つけることが求められる。

最後に、「データロールバック可能性」だ。これは、同じ処理ロジックであれば、異なるタイミングで複数回実行しても、常に同じデータ結果が得られることを保証するという原則である。これにより、データの信頼性と一貫性が保たれる。

これらの原則と階層構造を理解し、適切に適用することで、システムエンジニアは変化の激しいビジネス環境にも対応できる、堅牢で柔軟、そして価値の高いデータ基盤を構築することができる。データモデルアーキテクチャの深い理解は、現代のITシステム開発において不可欠なスキルの一つと言えるだろう。