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

Transcript

1. © 2022 NTT DATA Corporation DWHにおけるデータモデリング ー 定番から最新トレンドまで 2022年8月 株式会社NTTデータ Data & Intelligence事業部 Snowflakeビジネス推進室 渋谷 亮太
2. © 2022 NTT DATA Corporation 2 自己紹介 渋谷 亮太 株式会社NTTデータ Data & Intelligence事業部 Snowflakeビジネス推進室 最近できました！
3. © 2022 NTT DATA Corporation 3 目次 • なぜいまデータモデルなのか • DWHとデータモデル オールドスクール • 例①正規化モデルをスタースキーマ化 • 現代において、どんなデータモデルが最適か • 例②正規化モデルをData Vault化 • おわりに
4. © 2022 NTT DATA Corporation 4 なぜいまデータモデルなのか
5. © 2022 NTT DATA Corporation 5 なぜいまデータモデルなのか • データ活用の重要性は増す一方 • データ活用の技術は進歩を続けている ⇒ 一方、データの根本を支える技術は変わらず、むしろ回帰している リレーショナルモデル （関係モデル） SQL
6. © 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の原型も全部私が作りました
7. © 2022 NTT DATA Corporation 7 （ご参考） リレーショナルモデルとSQLの詳しい歴史は、SnowflakeユーザコミュニティSnowVillageの YouTubeチャンネルにて「みんなのSQL講座」シリーズをぜひご視聴ください！！ https://www.youtube.com/c/DATACLOUD/videos
8. © 2022 NTT DATA Corporation 8 様々なデータベースの歴史とリレーショナルモデルの凋落 2000年代後半の「ビッグデータ」時代以降、一時的に落ちていたリレーショナルモデル・・・ 業務用データベース DWH/OLAP/分析用データベース Web系データベース NoSQL クラウド ネイティブDB 1980年代 1990年代 2000年代 2010年代 2020年代 並列分散システム/Hadoop/データレイク クラウドネイティブに作られたデータベース 様々な指向があるが、総じてSQL回帰の傾向
9. © 2022 NTT DATA Corporation 9 • 時系列データや半構造化データへの対応 • クラウドによるコスト低減 • 分散トランザクションの進歩 1. SQLやRDBの論理的・技術的進化 なぜ今リレーショナルモデルが復権しようとしているのか
10. © 2022 NTT DATA Corporation 10 なぜ今リレーショナルモデルが復権しようとしているのか 1. SQLやRDBの論理的・技術的進化 2. データのコンプライアンスの高まり • GDPR • 個人情報保護法
11. © 2022 NTT DATA Corporation 11 なぜ今リレーショナルモデルが復権しようとしているのか 1. SQLやRDBの論理的・技術的進化 2. データのコンプライアンスの高まり 3. データの民主化 システムのことは詳しくないけど、自分で データベースからデータを取り出したい シチズンデータサイエンティスト
12. © 2022 NTT DATA Corporation 12 データモデルの出番！ どんな最新のDWH製品やBI製品を導入したとしても • ユーザがデータモデルを理解できなければ、データは活用できない • データモデルの良し悪しで、同じクエリの性能が大きく異なってくる ＝コストが大きく異なってくる • データモデルがデータ基盤の拡張性を左右する ⇒ データモデルがデータ民主化の成否を決めると言っても過言ではない！
13. © 2022 NTT DATA Corporation 13 DWHとデータモデル オールドスクール
14. © 2022 NTT DATA Corporation 14 二人の偉大なアーキテクト Bill Inmon Ralph Kimball 「データウェアハウスについて解説する場合、どうしても避けて通れないふたりの名前がある。それが、 Bill InmonとRalph Kimballである。このふたりの著しい貢献により、データウェアハウスの実践的な 技術が発達し、形成された。」 DAMA International『データマネジメント知識体系ガイド』（2010）p.200
15. © 2022 NTT DATA Corporation 15 「DWHの父」インモンによるDWHの定義 「経営陣の意思決定プロセスを支え、サブジェクト（主題）別に統合化された、時系列な不変 データの集合」 • サブジェクト指向 • 統合化された • 時系列 • 不変的 • 集計データと詳細データ • 履歴 DAMA International 『データマネジメント知識体系ガイド（第二版）』2018 p.416 オペレーショナルなデータベースとの違い
16. © 2022 NTT DATA Corporation 16 コーポレートインフォメーションファクトリー（CIF） 生 デ ー タ ・ 詳 細 デ ー タ リファレンス データ ヒストリカル リファレンスデータ アプリ アプリ アプリ アプリ 統 合 ・ 変 換 DM DM DM EDW ODS オペレーショ ナルDM オペレーショナルレポート （アプリ毎） オペレーショナルレポート （統合） 分析 探索的分析 オペレーショ ナル分析 ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017） インモンはデータを取得・蓄積・統合・提供する一連のアーキテクチャをCIFと呼んだ。
17. © 2022 NTT DATA Corporation 17 コーポレートインフォメーションファクトリー（CIF） 生 デ ー タ ・ 詳 細 デ ー タ リファレンス データ ヒストリカル リファレンスデータ アプリ アプリ アプリ アプリ 統 合 ・ 変 換 DM DM DM EDW ODS オペレーショ ナルDM オペレーショナルレポート （アプリ毎） オペレーショナルレポート （統合） 分析 探索的分析 オペレーショ ナル分析 ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017） インモンはデータを取得・蓄積・統合・提供する一連のアーキテクチャをCIFと呼んだ。 ポイント① EDWに正規化モデルで「統合する」 ポイント② 分析のためのDMがEDW から作成される
18. © 2022 NTT DATA Corporation 18 EDW インモンのEDWのデータモデルは「トップダウン」と「正規化」 概念データモデルからその企業の業務プロセスを可視化していき、正規化モデルで蓄積する。 そのEDWから、分析に適したDMを作成する。 全社ハイレベルデータモデル サブジェクトエリア別 データモデル ソースシステム DM
19. © 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
20. © 2022 NTT DATA Corporation 20 キンボールのディメンショナルモデリング ビジネスプロセスイベントを蓄積する「ファクトテーブル」と分析軸である「ディメンションテーブル」を 組み合わせた「スタースキーマ」が基本。 売上ファクト 日付ディメンション 住所ディメンション 顧客ディメンション 商品ディメンション ファクトテーブル • ビジネスプロセスにおけるイベントの最小粒度でデータが 生成され、時系列で蓄積される • 多数の外部キーといくつかの測定項目（基本的には数 値）で構成される • 大量のレコード数、少ない項目数 ディメンションテーブル • 一つのキーについて、ビジネスにおける属性が記録される • システム的なコードではなくビジネス用語を用いる • これ以上正規化しない（正規化してしまったものを「ス ノーフレイクスキーマと呼ぶ） • 少ないレコード数、多数の項目数
21. © 2022 NTT DATA Corporation 21 キンボールのDW/BIアーキテクチャ エンタープライズDWバスアーキテクチャにより、物理的にデータモデルを統合するのではなく、複数 のスタースキーマの関係を論理的に統合することでEDWを構築する。 サービス データストア 処理 アドホッククエリ レポート 分析アプリ データ分析 抽出 ロード アクセス オペレーショナル ソースシステム ステージング 領域 プレゼンテーション 領域 データアクセス ツール DM DM DM EDWバス 適合ディメンション ※DAMA International 『DAMA-DMBOK 2nd Edition』（2017）
22. © 2022 NTT DATA Corporation 22 エンタープライズDWバス DWバスとは、ビジネスプロセスとディメンションのマトリックスのこと。複数のビジネスプロセスにまたが るディメンションを「コンファームド（適合）ディメンション」と呼ぶ。 日付 製品 倉庫 店舗 プロモ 顧客 従業員 発注 ◦ ◦ ◦ 倉庫荷受 ◦ ◦ ◦ ◦ 倉庫在庫 ◦ ◦ ◦ 店舗荷受 ◦ ◦ ◦ ◦ ◦ 店舗在庫 ◦ ◦ ◦ 売上 ◦ ◦ ◦ ◦ ◦ ◦ 予約売上 ◦ ◦ ◦ プロモーション ◦ ◦ ◦ ◦ 顧客返品 ◦ ◦ ◦ ◦ ◦ ◦ 製造元返品 ◦ ◦ ◦ ◦ 得意先登録 ◦ ◦ ◦ ◦
23. © 2022 NTT DATA Corporation 23 キンボールが考えるEDWとDMの関係 • 部署ごとなどに独立したDMが作られるとき、ディメンショナルモデリングが用いられることが多いが、 これは「アーキテクチャ」ではない。強く反対する。 • インモンのCIFアーキテクチャは、正規化が前提となっているが、正規化することとデータを統合 することは本来無関係であるはず。 • ユーザが欲しいのは分析のために使えるデータモデルであり、そのために組織のデータを全て物 理的に統合することはコスト的に最適ではない。 • エンタープライズDWバスと適合ディメンションを用いてDMを作ることでEDWを作ることができる。 Kimball, Ross 『The Data Warehouse Toolkit Third Edition』 2013 pp.26-30
24. © 2022 NTT DATA Corporation 24 例①正規化モデルをスタースキーマ化
25. © 2022 NTT DATA Corporation 25 ディメンショナルモデリングの手順 1. ビジネスプロセスを選択する • ビジネスプロセスを理解し、DWバスを作り、DWバスから優先度の高いものを選ぶことは、 ビジネス側の一部署の人ではできない。経営目線をもって取り組む必要がある。 2. ファクトの粒度を明確にする • ファクトテーブルの粒度は、できる限り小さく、アトミックにすることが重要。それによってさまざ まな軸での集計が可能になる。 3. ディメンションを定義する • ビジネスユーザの「問い」をディメンションとする。ファクトに関する5W1Hが定義される。ディ メンションテーブルはフィルタリング、グルーピングの軸となる。 4. ファクトの測定値を定義する • ファクトテーブルの属性値は、集計できるよう、加算できる数値が望ましい。
26. © 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
27. © 2022 NTT DATA Corporation 27 TPC-Hデータモデルの特徴 ヘッダ行と明細行が 正規化されている サプライヤと顧客の両方が 持つ「国」の項目は正規 化され、NATIONKEYと いうキー項目以外は別 テーブル化 パーツはサプライヤ の多対多の関係を 示す中間テーブル
28. © 2022 NTT DATA Corporation 28 TPC-Hをスタースキーマにしてみよう 1. ビジネスプロセスを選択する • この場合は既に決定されてしまっている「オーダー（受注）」 2. ファクトの粒度を明確にする • 受注単位ではなく、よりアトミックな単位をファクトの粒度とする。この場合は受注明細。 3. ディメンションを定義する • 受注を分析するとしたらどんな軸が必要か。「誰が」「何を」「いつ」「どこで」「どうやって」。 4. ファクトの測定値を定義する • 同じ粒度で加算できる数値がファクトテーブルの外部キー以外の項目となる。
29. © 2022 NTT DATA Corporation 29 STAR SCHEMA BENCHMARKデータモデル • マサチューセッツボストン大学の研究 チームが開発（？） • TPC-Hをもとに、スタースキーマに再編 されたベンチマーク • Oracle Autonomous DBに最初か ら同梱されている • Redshiftの公式チュートリアルで利用 されている https://www.cs.umb.edu/~poneil/StarSchemaB.PDF
30. © 2022 NTT DATA Corporation 30 STAR SCHEMA BENCHMARKデータモデルの特徴 無用な正規化はせず、 PARTSUPP、NATION、 REGIONは削除。 NATIONKEYではなく、 NATION（コードではな く属性値）を直接ディメ ンションテーブルに格納す る。 ヘッダ行と明細行を統合 して明細側に粒度を合わ せる。 ORDERKEYでサマリす ればヘッダ単位でのロール アップも可能。（縮退ディ メンション）（※1） 日付の分析軸はDWHに とって非常に重要なので、 日付ディメンションを追加。 （※1) ORDTOTALPRICE は粒度が異なるため通常削除 する。ORDERKEYで集計す れば導出できる。
31. © 2022 NTT DATA Corporation 31 スタースキーマは変化に強い？ • 新しい測定値を増やしたいときは？（例：受注明細における「利益額」） • 分析する属性を増やしたいときは？（例：顧客の「年代ごと」の受注額） • 分析軸を増やしたいときには？（例：「従業員ごと」の受注額） ⇒ アトミックな粒度でファクトが作られている限り、既存のクエリに影響を与えることなく、 ALTER TABLEで変更が可能
32. © 2022 NTT DATA Corporation 32 現代において、どんなデータモデルが最適か
33. © 2022 NTT DATA Corporation 33 現代のDWH：データもユーザも、どんどん増える！ データソースは社内外から様々。ユーザはスキルセットも利用ユースケースも様々。 いずれも小さく始めて大きく伸ばす、という進め方が一般的に ⇒ アジリティが重要 データソース ユーザ
34. © 2022 NTT DATA Corporation 34 キンボール流アジャイルアプローチ エンタープライズDWバスをもとに、ビジネスプロセスを順次モデリングしていく。適合ディメンション が徐々に増えて来て、最終的にはファクトテーブルを追加するだけでモデリングできるようになる。
35. © 2022 NTT DATA Corporation 35 大福帳モデルとは ワイドテーブル、ワンビッグテーブルなどとも呼ばれる、横長に全部が詰め込まれたテーブル。 スタースキーマと異なり、参照には結合が不要。大量の繰り返し項目が存在する。 測定値 日付 住所 商品 顧客 売上テーブル 売上ファクト 日付ディメンション 住所ディメンション 顧客ディメンション 商品ディメンション ディメンショナルモデル 大福帳
36. © 2022 NTT DATA Corporation 36 クラウドDWHに最適な大福帳モデル 大福帳はクラウドDWHによるデータ民主化時代に適していると言われる。 1. コスト カラムナ型のDWH製品では、繰り返しの値はストレージを圧迫しない。そもそも現代にお いてストレージは非常に安い 2. パフォーマンス 結合に払うコンピューティングコストが不要で、ストレージIOは増えないので、むしろパフォー マンスは良い。 3. 理解性 何より、ユーザからの理解度が高い。結合しなくても済むので、Excel感覚でデータを扱う ことができる。
37. © 2022 NTT DATA Corporation 37 大福帳にアジリティはあるのか 大福帳はユーザからは非常に見やすいが、変化に強いか？拡張性が高いか？はその前段階 にかかっている。このテーブルをどのように作っていくかが重要。 測定値 日付 住所 商品 顧客 売上テーブル データソース
38. © 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
39. © 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 ステージング 領域
40. © 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を持つことができる。
41. © 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にまたがる結合を行っておくテーブル
42. © 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)
43. © 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 実テーブル
44. © 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/
45. © 2022 NTT DATA Corporation 45 例②正規化モデルをData Vault化
46. © 2022 NTT DATA Corporation 46 Data Vault 2.0によるRaw Data Vaultのモデリング手順 1. Hubをモデリングする • 元テーブルからビジネスキー（自然キー）を抽出する • ビジネスキーをもとにしたハッシュ値を主キーとする • DWHにそのビジネスキーを初めてロードした日時 • 各行が初めてロードされたソースシステム 2. Linkをモデリングする • 外部キーを複数持ち、Hub同士の多対多を解決 • それ以外はHubと同じで、全てのビジネスキーとそれをもとにしたハッシュキー、ロード日時、ソースシステム の列を持つ 3. Satelliteをモデリングする • HubやLinkのハッシュキーに加え、ロード日時を主キーとして持つ • ビジネスキー以外の全ての項目を持ち、データがロードされるごとにレコードが積み上げられていく • レコードごとのソースシステム列を持つ • 全ての属性値を連結してハッシュ化した項目を持ち、新しいデータが追加されたときに突合して変更有無 を確認する
47. © 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：レコードソース
48. © 2022 NTT DATA Corporation 48 Raw Data Vaultの特徴 パーツ名とサプライヤ名 がそれぞれのHubのビジ ネスキー ⇒同じビジネスキーを 持っていれば、別ソース からもSatを統合可能 パーツとサプライヤは多対多 の関係だが、一見1対多の 関係でも、同様のリンクの貼 り方をする（拡張性） Hubの主キー（ハッシュ キー）＋ロード日時の 複合キーでデータの変 化を蓄積し続ける
49. © 2022 NTT DATA Corporation 49 おわりに
50. © 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
51. © 2022 NTT DATA Corporation 51 一緒に勉強しましょう！
52. © 2022 NTT DATA Corporation