DWHにおけるデータモデル　定番から最新トレンドまで

by Ryota Shibuya

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2022 NTT DATA Corporation 6 リレーショナルモデルはコンピュータサイエンス史に残るすごい発明！ 1970年にエドガー・F・コッド氏が発表した、データを「2次元の表」であらわすモデル IBM blog https://www.ibm.com/blogs/resea rch/2020/06/sql-relational- model-50-years-later/ エドガー・F・コッドリレーショナルモデルも正規化も SQLの原型も全部私が作りました

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2022 NTT DATA Corporation 8 様々なデータベースの歴史とリレーショナルモデルの凋落 2000年代後半の「ビッグデータ」時代以降、一時的に落ちていたリレーショナルモデル・・・業務用データベース DWH/OLAP/分析用データベース Web系データベース NoSQL クラウドネイティブDB 1980年代 1990年代 2000年代 2010年代 2020年代並列分散システム/Hadoop/データレイククラウドネイティブに作られたデータベース様々な指向があるが、総じてSQL回帰の傾向

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2022 NTT DATA Corporation 12 データモデルの出番！どんな最新のDWH製品やBI製品を導入したとしても • ユーザがデータモデルを理解できなければ、データは活用できない • データモデルの良し悪しで、同じクエリの性能が大きく異なってくる＝コストが大きく異なってくる • データモデルがデータ基盤の拡張性を左右する ⇒ データモデルがデータ民主化の成否を決めると言っても過言ではない！

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2022 NTT DATA Corporation 14 二人の偉大なアーキテクト Bill Inmon Ralph Kimball 「データウェアハウスについて解説する場合、どうしても避けて通れないふたりの名前がある。それが、 Bill InmonとRalph Kimballである。このふたりの著しい貢献により、データウェアハウスの実践的な技術が発達し、形成された。」 DAMA International『データマネジメント知識体系ガイド』（2010）p.200

Slide 15

Slide 15 text

© 2022 NTT DATA Corporation 15 「DWHの父」インモンによるDWHの定義「経営陣の意思決定プロセスを支え、サブジェクト（主題）別に統合化された、時系列な不変データの集合」 • サブジェクト指向 • 統合化された • 時系列 • 不変的 • 集計データと詳細データ • 履歴 DAMA International 『データマネジメント知識体系ガイド（第二版）』2018 p.416 オペレーショナルなデータベースとの違い

Slide 16

Slide 16 text

© 2022 NTT DATA Corporation 16 コーポレートインフォメーションファクトリー（CIF）生データ・詳細データリファレンスデータヒストリカルリファレンスデータアプリアプリアプリアプリ統合・変換 DM DM DM EDW ODS オペレーショナルDM オペレーショナルレポート（アプリ毎）オペレーショナルレポート（統合）分析探索的分析オペレーショナル分析 ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017）インモンはデータを取得・蓄積・統合・提供する一連のアーキテクチャをCIFと呼んだ。

Slide 17

Slide 17 text

© 2022 NTT DATA Corporation 17 コーポレートインフォメーションファクトリー（CIF）生データ・詳細データリファレンスデータヒストリカルリファレンスデータアプリアプリアプリアプリ統合・変換 DM DM DM EDW ODS オペレーショナルDM オペレーショナルレポート（アプリ毎）オペレーショナルレポート（統合）分析探索的分析オペレーショナル分析 ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017）インモンはデータを取得・蓄積・統合・提供する一連のアーキテクチャをCIFと呼んだ。ポイント① EDWに正規化モデルで「統合する」ポイント② 分析のためのDMがEDW から作成される

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2022 NTT DATA Corporation 19 インモンが考えるEDWとDMの関係 • 正規化モデルは柔軟であり、様々な組織の要請に応えられる • スタースキーマは他のユーザを犠牲にして特定ユーザのニーズに応えるもの • ユーザが直接参照しないEDWは正規化モデルで、ユーザが直接参照するDMはスタースキーマで構築するとそれぞれの長所が生かされるので良い • EDWを作らずに独立したDMを作ることは、データの再利用性・整合性を失わせ、インターフェイスの異なる多数の重複データを生み出す。後にインモンはこんなことも言っているらしい（原典不明）「Data VaultはDW2.0フレームワークでEDWをモデリングするのに最適な選択肢だ」 https://www.dv-community.org/what-is-the-data-vault-and-why-do-we-need-it/ Inmon 『Building the Data Warehouse Fourth Edition』 2005 p.375

Slide 20

Slide 20 text

© 2022 NTT DATA Corporation 20 キンボールのディメンショナルモデリングビジネスプロセスイベントを蓄積する「ファクトテーブル」と分析軸である「ディメンションテーブル」を組み合わせた「スタースキーマ」が基本。売上ファクト日付ディメンション住所ディメンション顧客ディメンション商品ディメンションファクトテーブル • ビジネスプロセスにおけるイベントの最小粒度でデータが生成され、時系列で蓄積される • 多数の外部キーといくつかの測定項目（基本的には数値）で構成される • 大量のレコード数、少ない項目数ディメンションテーブル • 一つのキーについて、ビジネスにおける属性が記録される • システム的なコードではなくビジネス用語を用いる • これ以上正規化しない（正規化してしまったものを「スノーフレイクスキーマと呼ぶ） • 少ないレコード数、多数の項目数

Slide 21

Slide 21 text

© 2022 NTT DATA Corporation 21 キンボールのDW/BIアーキテクチャエンタープライズDWバスアーキテクチャにより、物理的にデータモデルを統合するのではなく、複数のスタースキーマの関係を論理的に統合することでEDWを構築する。サービスデータストア処理アドホッククエリレポート分析アプリデータ分析抽出ロードアクセスオペレーショナルソースシステムステージング領域プレゼンテーション領域データアクセスツール DM DM DM EDWバス適合ディメンション ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017）

Slide 22

Slide 22 text

© 2022 NTT DATA Corporation 22 エンタープライズDWバス DWバスとは、ビジネスプロセスとディメンションのマトリックスのこと。複数のビジネスプロセスにまたがるディメンションを「コンファームド（適合）ディメンション」と呼ぶ。日付製品倉庫店舗プロモ顧客従業員発注 ○ ○ ○ 倉庫荷受 ○ ○ ○ ○ 倉庫在庫 ○ ○ ○ 店舗荷受 ○ ○ ○ ○ ○ 店舗在庫 ○ ○ ○ 売上 ○ ○ ○ ○ ○ ○ 予約売上 ○ ○ ○ プロモーション ○ ○ ○ ○ 顧客返品 ○ ○ ○ ○ ○ ○ 製造元返品 ○ ○ ○ ○ 得意先登録 ○ ○ ○ ○

Slide 23

Slide 23 text

© 2022 NTT DATA Corporation 23 キンボールが考えるEDWとDMの関係 • 部署ごとなどに独立したDMが作られるとき、ディメンショナルモデリングが用いられることが多いが、これは「アーキテクチャ」ではない。強く反対する。 • インモンのCIFアーキテクチャは、正規化が前提となっているが、正規化することとデータを統合することは本来無関係であるはず。 • ユーザが欲しいのは分析のために使えるデータモデルであり、そのために組織のデータを全て物理的に統合することはコスト的に最適ではない。 • エンタープライズDWバスと適合ディメンションを用いてDMを作ることでEDWを作ることができる。 Kimball, Ross 『The Data Warehouse Toolkit Third Edition』 2013 pp.26-30

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2022 NTT DATA Corporation 25 ディメンショナルモデリングの手順 1. ビジネスプロセスを選択する • ビジネスプロセスを理解し、DWバスを作り、DWバスから優先度の高いものを選ぶことは、ビジネス側の一部署の人ではできない。経営目線をもって取り組む必要がある。 2. ファクトの粒度を明確にする • ファクトテーブルの粒度は、できる限り小さく、アトミックにすることが重要。それによってさまざまな軸での集計が可能になる。 3. ディメンションを定義する • ビジネスユーザの「問い」をディメンションとする。ファクトに関する5W1Hが定義される。ディメンションテーブルはフィルタリング、グルーピングの軸となる。 4. ファクトの測定値を定義する • ファクトテーブルの属性値は、集計できるよう、加算できる数値が望ましい。

Slide 26

Slide 26 text

© 2022 NTT DATA Corporation 26 TPC-Hデータモデル • トランザクション処理性能評議会（Transaction Processing Performance Council）が定める、データベース業界標準の性能ベンチマーク • TPC-HはDWH向けのベンチマークながら、正規化モデルであることが特徴 • Snowflakeはデータシェアリングの機能を使って、最初からTPC-HとTPC- DSのデータをサンプルとして使えます（TPC-DSはスノーフレイクスキーマのベンチマーク） https://www.tpc.org/TPC_Documents_Current_Versions/pdf/TPC-H_v3.0.1.pdf

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2022 NTT DATA Corporation 28 TPC-Hをスタースキーマにしてみよう 1. ビジネスプロセスを選択する • この場合は既に決定されてしまっている「オーダー（受注）」 2. ファクトの粒度を明確にする • 受注単位ではなく、よりアトミックな単位をファクトの粒度とする。この場合は受注明細。 3. ディメンションを定義する • 受注を分析するとしたらどんな軸が必要か。「誰が」「何を」「いつ」「どこで」「どうやって」。 4. ファクトの測定値を定義する • 同じ粒度で加算できる数値がファクトテーブルの外部キー以外の項目となる。

Slide 29

Slide 29 text

© 2022 NTT DATA Corporation 29 STAR SCHEMA BENCHMARKデータモデル • マサチューセッツボストン大学の研究チームが開発（？） • TPC-Hをもとに、スタースキーマに再編されたベンチマーク • Oracle Autonomous DBに最初から同梱されている • Redshiftの公式チュートリアルで利用されている https://www.cs.umb.edu/~poneil/StarSchemaB.PDF

Slide 30

Slide 30 text

© 2022 NTT DATA Corporation 30 STAR SCHEMA BENCHMARKデータモデルの特徴無用な正規化はせず、 PARTSUPP、NATION、 REGIONは削除。 NATIONKEYではなく、 NATION（コードではなく属性値）を直接ディメンションテーブルに格納する。ヘッダ行と明細行を統合して明細側に粒度を合わせる。 ORDERKEYでサマリすればヘッダ単位でのロールアップも可能。（縮退ディメンション）（※1）日付の分析軸はDWHにとって非常に重要なので、日付ディメンションを追加。（※1) ORDTOTALPRICE は粒度が異なるため通常削除する。ORDERKEYで集計すれば導出できる。

Slide 31

Slide 31 text

© 2022 NTT DATA Corporation 31 スタースキーマは変化に強い？ • 新しい測定値を増やしたいときは？（例：受注明細における「利益額」） • 分析する属性を増やしたいときは？（例：顧客の「年代ごと」の受注額） • 分析軸を増やしたいときには？（例：「従業員ごと」の受注額） ⇒ アトミックな粒度でファクトが作られている限り、既存のクエリに影響を与えることなく、 ALTER TABLEで変更が可能

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2022 NTT DATA Corporation 36 クラウドDWHに最適な大福帳モデル大福帳はクラウドDWHによるデータ民主化時代に適していると言われる。 1. コストカラムナ型のDWH製品では、繰り返しの値はストレージを圧迫しない。そもそも現代においてストレージは非常に安い 2. パフォーマンス結合に払うコンピューティングコストが不要で、ストレージIOは増えないので、むしろパフォーマンスは良い。 3. 理解性何より、ユーザからの理解度が高い。結合しなくても済むので、Excel感覚でデータを扱うことができる。

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2022 NTT DATA Corporation 38 アジャイルデータモデリング「Data Vault」最も新しく、最も注目されているデータモデリング手法。 • 2000年：Dan Linstedtが発表 • 2014年：ビッグデータ時代に合わせData Vault2.0を発表 • 2021年：米国でSnowflake Data Vaultユーザグループが発足 DanによるとData Vaultは・・・「正規化モデルとディメンショナルモデルのハイブリッドアプローチで、柔軟性・拡張性・一貫性があり、エンタープライズの要求に応えられる。エンタープライズデータウェアハウスのためのデータモデリング。」 https://tdan.com/data-vault-series-1-data-vault-overview/5054

Slide 39

Slide 39 text

© 2022 NTT DATA Corporation 39 Data Vaultの位置づけディメンショナルモデルや大福帳の手前の部分、インモンのEDWにあたる部分がData Vault の適用領域。さらにRaw Data VaultとBusiness Data Vaultに分けられる。データソースプレゼンテーション領域 Data Vault 領域（EDW）ディメンショナルモデル大福帳 Raw Data Vault Business Data Vault ステージング領域

Slide 40

Slide 40 text

© 2022 NTT DATA Corporation 40 Raw Data Vaultの例 CUSTOMER HUB 顧客Hash Load Date Source 顧客番号 CUSTOMER SAT 顧客Hash Load Date Source 顧客番号顧客名前その他情報… Hashdiff BOOKING HUB 予約Hash Load Date Source 予約番号 BOOKING DETAILS SAT 予約Hash Load Date Source 予約番号予約状況予約日金額その他情報… Hashdiff CUSTOMER BOOKING LINK 顧客予約Hash Load Date Source 顧客Hash 予約Hash CUSTOMER BOOKING SAT 顧客予約Hash Load Date Source Hashdiff  Hub • ビジネスキー（自然キー）のセット • ビジネスプロセスが扱う実体（Entity）を一意に識別する  Link • EntityとEntityの関係、つまりHubと Hubの関係を表現する  Satellite • HubやLinkに関する情報を表現する • 1つのSatelliteは1つのHubもしくは Linkに紐付く。HubやLinkは複数の Satelliteを持つことができる。

Slide 41

Slide 41 text

© 2022 NTT DATA Corporation 41 Raw Data VaultとBusiness Data Vault 機械的に作れるRaw Data Vaultに対して、Business Data Vaultはそこにビジネスルールを適用したもの。 • ビジネス観点での集約や計算を行ったLinkやSatellite • PIT（Point In Time）テーブル：時系列の異なる複数のSatelliteを紐づけるテーブル • Bridgeテーブル：複数のHubやLinkにまたがる結合を行っておくテーブル

Slide 42

Slide 42 text

© 2022 NTT DATA Corporation 42 アジャイルなデータ統合の例 Sprint 1：ビジネス側からの要望が多いソースシステムAの「Customerテーブル」の中から顧客データを抜き出してCustomer Hub、Customer Satellite化し、データウェアハウスにロード、データコンシューマに提供する。 Sprint 2：次にビジネス側からの要望が多いソースシステムBの「Clientテーブル」の中から顧客データを抜き出しCustomer Satellite化し、Customer Hubに紐付ける。データコンシューマに提供する。ソースシステムBからのSatelliteはCustomer Hubにただ追加されるだけである。もしソースシステムAの顧客データとソースシステムBの顧客データを完全に統合しようとするなら、この時点でデータ項目の一つ一つの意味を詳らかに理解した上で統合しなければならない。それは難しい作業であることが多い。Data Vaultではそれらの問題をいったん置いて統合し、現時点でビジネス的に必要な部分のみに着目したデータをBusiness Data Vaultとして提供する。 CUSTOMER HUB（ソースシステムA） CUSTOMER SAT（ソースシステムA） CUSTOMER HUB（ソースシステムA） CUSTOMER SAT（ソースシステムA） CUSTOMER SAT（ソースシステムB） CUSTOMER SAT (Business Vault)

Slide 43

Slide 43 text

© 2022 NTT DATA Corporation 43 Data Vaultからプレゼンテーション層へデータマートを構築する際、Raw Data VaultまたはBusiness Data Vaultからビューによって構築することができる。性能を求める場合には実テーブル化する。（ETLではなくELT） Information Delivery Data Vault ビュー Raw Data Vault Business Data Vault 実テーブル

Slide 44

Slide 44 text

© 2022 NTT DATA Corporation 44 クラウドDWHとData Vault クラウドDWH（と現代のデータ基盤）の特徴 • クラウドDWHはストレージコストが圧倒的に安い • クラウドのスケーラビリティを活かしたELTが有利 • アジャイル的なスピード感 Data Vaultの良いところ • 全ての断面を生データのまま保持するので、監査性が高い • 変換はルールベースかつ冪等なのでSQLによる自動化・効率化が容易 • 柔軟でスモールスタートから拡張していける（参考）：基本的な考え方が一致しているため、組み合わせの例が多い dbt Tokyo Meetup #3のアジェンダ 2/3がData Vault https://dbt-tokyo.connpass.com/event/246144/

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© 2022 NTT DATA Corporation 46 Data Vault 2.0によるRaw Data Vaultのモデリング手順 1. Hubをモデリングする • 元テーブルからビジネスキー（自然キー）を抽出する • ビジネスキーをもとにしたハッシュ値を主キーとする • DWHにそのビジネスキーを初めてロードした日時 • 各行が初めてロードされたソースシステム 2. Linkをモデリングする • 外部キーを複数持ち、Hub同士の多対多を解決 • それ以外はHubと同じで、全てのビジネスキーとそれをもとにしたハッシュキー、ロード日時、ソースシステムの列を持つ 3. Satelliteをモデリングする • HubやLinkのハッシュキーに加え、ロード日時を主キーとして持つ • ビジネスキー以外の全ての項目を持ち、データがロードされるごとにレコードが積み上げられていく • レコードごとのソースシステム列を持つ • 全ての属性値を連結してハッシュ化した項目を持ち、新しいデータが追加されたときに突合して変更有無を確認する

Slide 47

Slide 47 text

© 2022 NTT DATA Corporation 47 TPC-H（一部）をRaw Data Vaultにしてみよう https://www.snowflake.com/blog/tips-for-optimizing-the-data-vault-architecture-on-snowflake/ • Data Vaultのエヴァンジェリスト“The Data Warrior” Kent Grazianoが作成した Data Vault 2.0の例 • 主キーはビジネスキーをMD5 ハッシュした値 • LDTS：ロードデイト/タイムスタンプ • RSCR：レコードソース

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© 2022 NTT DATA Corporation 50 データモデリングの波、来てますアジャイルでクラウドなデータ基盤を整えた人から、重要なのはデータモデリングだと気づき始めている。 https://speakerdeck.com/ishikawa_satoru/detafen-xi-wozhi-eruji-shu- detamoderinguzai-ru-men https://speakerdeck.com/cyberagentdevelopers/cd-snowflakexdbt https://speakerdeck.com/pei0804/modeling-over-shiny-tech https://speakerdeck.com/foursue/datavault2-dot-0wogoshao-jie https://speakerdeck.com/kazk1018/dbttobigquerydeshi-merudata- vaultru-men