ディメンショナル・モデルの概要とこれからの活用局面（２）

　「ディメンショナル・モデルの概要とこれからの活用局面（１）」では、ディメンショナル・モデルの基本概念を解説しました。本稿では、その応用の歴史を振り返り、現在の技術的な背景を考慮した活用局面について解説します。

ディメンショナル・モデルの活用局面

～2010年前後

ディメンショナル・モデルを利用する理由①モデルの理解容易性

　Ralph Kimballが提唱したディメンショナルモデリングは、2010年前後まで、Bill Inmonの正規化を重視するデータウェアハウス理論との使い分けについて多くの議論がなされながら、実装領域が重複する形で実装されてきました。そもそもこの２つの理論が提唱する「データウェアハウス」という言葉の定義に差異があり、それによる混乱や議論の行き違いもあったように思えます。

　ディメンショナルモデリングで言うところの「データウェアハウス」は、①データを整理蓄積するためのデータストア、②ユーザーの参照に最適化されたデータストア、の２つを総称しており、その役割と使い分けについて明確に基準が定義されていました。

　ディメンショナルモデルリングは、「会計」、「CRM（顧客関係管理）」、「SCM（サプライチェーン管理）」など、全社規模というより分析領域が限られている場合にの実装に長けています。

　例えば、SCM分析で次のような分析要件があるとします。

納期遵守率分析

在庫回転期間分析

販売計画精度分析

製品ライフサイクル分析

粗利推移分析

　このような場合、ディメンショナルモデリングでは次のようなアプローチをとります。

データウェアハウス（整理・蓄積）層として、バリューチェーン（価値連鎖）に沿ったファクトを設計する。

データマート（ユーザー参照）層として、分析用途に適したファクトを設計する。

１、２共用のディメンションを設計する。

　シンプルに表すと次のような構成になります。

　このように、データ分析基盤のライフサイクルを通じて、ディメンショナルモデルを適用することが可能であり、このようなアプローチを採用したデータ分析基盤の開発例も多く存在します。

ディメンショナル・モデルを利用する理由②性能の確保

　ディメンショナルモデルは、前述の多くのメリットがある一方、当時の技術的な制約を解決するための設計手法であったという側面もあります。当時、自由なデータモデルを選択できなかった技術上の理由には次のようなものがあります。

行指向のデータベースソフトウェア

　当時の制約の一例としては、多くの主要なデータベース製品が行指向であったことが挙げられます。行指向のデータベースの性能はおおよそ次のような計算で決まります。

[性能] = [インデックスのI/O] ＋ [テーブルのI/O] ＋ [結合（JOIN）のコスト]

[テーブルのI/O]=[レコード長] × [レコード件数]

　その観点で、データ分析基盤として利用されてきたデータベースのモデルを比較すると下図のようになります。

　上の図のそれぞれの四角形は、縦の長さがレコード数、横の長さがレコード長を表します。（面積の合計=テーブルのI/O量）

①は分析軸をすべて結合した第1正規形のモデル

②は高次に正規化されたモデル

③はマスタとトランザクションをナチュラルキーと有効期間で結合するモデル

④はスタースキーマ

　この４つのパターンを比較すると、ケースによるため一概には言えませんが、おおよそ次のように整理されます。（5点満点）

	テーブルのI/O	インデックスのI/O	結合のコスト	合計
①第1正規形	1	1	5	7
②高次正規形	5	3	1	9
③ナチュラルキー	3	4	2	9
④スタースキーマ	4	5	3	12

④のスタースキーマは

サロゲートキーの使用により、ファクトテーブルおよびファクトに付随するインデックスがコンパクトになる。（テーブルとインデックスのI/O量が少ない）

結合がシンプルになる

ことに起因して、性能上のメリットが出やすいことが見て取れます。

　このように、行指向データベースへのデータウェアハウスの実装に対して、ディメンショナル・モデルは適したモデルであったと考えられます。

クエリープランナーの精度

　クエリープランナー（SQLクエリを効率的に実行するための最適な実行計画を生成するコンポーネント）の精度が低く、正規化された多数のテーブルや複雑な結合、複雑な計算を伴うクエリでは性能上の問題が発生することがありました。このため、ディメンショナルモデリングによって設計されたシンプルなスタースキーマは、性能上のリスクを軽減する重要な役割を果たしていました。

オンプレミス環境でのコンピューティングリソース

　オンプレミスのデータウェアハウスでは、コンピューティングリソース（CPU、メモリ、ストレージ、ネットワーク、GPUなど）が高価であり、事前に厳密なサイジングが必要でした。さらに、バッチ処理とオンライン処理を共通のコンピューティングリソースで実行するケースも多かったため、クエリ実行の総コストを低く抑えるために、ディメンショナルモデルによる実装が選択されることが多くありました。

2010年頃～

ディメンショナルモデルを利用する理由①モデルの理解容易性

　「ディメンショナルモデルの概要とこれからの活用局面（１）」で解説した通り、ディメンショナルモデリングによって設計されたモデルは、ユーザーにとても理解しやすい構造を持っています。さらに、初期バージョンの発表以降、継続的な改良が行われ、より実践的で使いやすい技法へと進化しています。ただし、エンタープライズ向けの用途には元々適していないため、以下のような使い分けを推奨します。

データ分析基盤内の役割	利用する範囲	適用するモデル
データウェアハウス（SSoT）	エンタープライズ向け	・高次正規化モデル・Data Vault 2.0
	特定業務（CRM,SCM,etc.）向け	・高次正規化モデル・Data Vault 2.0 ・ディメンショナルモデル
インフォメーションマート（ユーザーの理解、性能）		・ディメンショナルモデル

ディメンショナルモデルを利用する理由②性能の確保

　「～2010年前後」までにディメンショナル・モデルを採用した理由を解説しましたが、その多くが現在は解決されています。

行指向のデータベースソフトウェア

　現在のデータウェアハウス向けのデータベース製品は、多くが列指向アーキテクチャを採用しています。そのため、前述のように「面積」を意識した性能対策の重要性は薄れてきています。また、Parquetなどのオープンな列指向データ形式の技術も利用されており、実装の選択肢はさらに広がっています。

クエリープランナーの精度

　クエリプランナーの精度が年々向上し、データベースの専門家がパフォーマンスチューニングを行わなくても一定の性能を確保できるようになりました。この背景には、インデックスタイプの増加、パーティショニング技術、およびデータベース製品独自の性能向上技術が性能改善に寄与しています。従って、性能担保のために必ずしもディメンショナル・モデルでなくてはいけない、という状況ではなくなりました。

オンプレミス環境でのコンピューティングリソース

　かつては、限られたコンピューティングリソースでデータウェアハウスを運用する際、クエリコストが低いディメンショナル・モデルの実装が非常に有効でした。しかし、近年はクラウドテクノロジーを活用したデータウェアハウス製品の使用が増えてきたため、必ずしもその限りではなくなっています。

例えば、クラウド技術を使用することで、以下のような対応が容易になります。

バッチ処理とオンライン処理でコンピューティングリソースを分離する。
負荷に応じて自動的にスケーリングする。
必要なリソースが増加した場合、コンソールから簡単にリソースを追加する。

これらの措置により、データモデルの選択肢も広がっています。

おわりに

　前述の通り、「モデルの理解容易性」という観点からは、ディメンショナルモデルは変わらずメリットがあり、有効なモデリング手法であると言えます。一方で、「性能の確保」という観点からは、そのメリットが薄れてきています。

　また、初期段階でのディメンショナルモデルの設計には、手法を正しく理解し標準化することが必要であり、技術者にとっては一つのハードルとなり、コスト高になる傾向があるため、利用部門やコスト負担部門の理解が求められます。

　今後実現したいデータ分析環境の内容や規模、コスト、技術者のスキルなどを考慮し、適切な場面での適用することは極めて有意義であると考えます。