第３回 データモデリング？どのレベルでやるの？（2023/11/15 SnowflakeJP デタマネ UserGroup）
こんにちは。Snowflakeのデタマネユーザーグループ（デタマネ会）の佐川です！
普段はSIerで通信系のお客様向けにデータ基盤開発をしています。
デタマネ会では毎週第一金曜日に、データマネジメント関連で気になるテーマをディスカッションしてノウハウ共有しています。
詳細はこちら。
今回は第３回11/9（木）のデタマネ会のディスカッション内容をお届けします！
第3回テーマは
『データモデリング？どのレベルでやるの？』
by Snowflake Data Superheroes 2023のこみぃさん(@kommy_jp)
データモデルはデータマネジメントをするうえで、データエンジニアとしては根幹となるといっても過言ではないテーマですね🎉
\データモデルに興味ある方多かったのかいつもより少し参加者多め/
\データモデルに詳しいpei(@pei0804)さんも参戦！/
今のプロジェクトでデータモデルって何から整理すれば？と悩んでいたので、とても勉強になる会でした！
個人的に印象に残ったキーワードはこちら。
DataVaultはdbtが出るまでは人類には早すぎた感があった
つよつよ集計データを、まずは使いやすくなるようにデータモデリングすると、みんなデータモデリングの魅力に憑りつかれる
（モデリング手法を説明するよりも）
データカタログはお高い
それでは内容に入っていきます！
Presentation by こみぃさん
GENDAでデータエンジニアをされているこみぃさんのプレゼンテーションが今回のディスカッションインプットです。
スライド参照いただきつつ、口頭部分を補足させていただきます💡
データモデリングとは？
なぜデータモデリングが必要なのか、プロジェクト内で説得するとしたらこういうロジックがいいのでは？なお話です。
たしかにデータモデリングという話をすると、データベースの好きな人の気にするところ？プラスアルファやるといいかもね？な温度感で捉えられてしまうのが難しいところ。
データモデリングはデータを整理して見やすくするプロセス
データが整理されていないと、こんな問題が起きがち。
- 間違ったデータを出してしまう
- データの閲覧（見つけるのにも）に時間がかかる
- データを共有できない
- セキュリティがつらい
データドリブンの材料のデータがそもそも間違っているとおかしなことになってしまいます🙄
データモデリング？どのレベルでやるの？
データモデリングの重要性を周囲の人が理解できたとして、それでもある程度データドリブンに進められてデータを使っている人には響くのか？という問題ですが、これはデータベースにフォーカスしているからかもしれません。
データモデリングというと、いわゆるDWH・マート集計のデータモデルを考える人が多いかもしれませんが、もっと広い範囲で動くべきなんではというのが今回のポイント。
データを使っている人のデータの使い方をヒアリングしてみて、どんな風に使っているのかまず把握しにいきましょう。
そもそもDWH上のデータではなくて手渡しのExcelデータと組み合わせていることもある😨使い方を深追いしていくと、ログの形式が適切でなく、追加のログ取得が必要になることも😱
そしてそこから修正した後のデータ提供の仕方も大事。使う人が望む形でデータを提供しないとデータは使われない。
データモデリングのステップ
データ生産者へのヒアリングでデータの仕様を正確に把握しつつ、
データ利用者に使いたいデータがどんな形式で提供してほしいかをすり合わせる
つまり、データモデリングは挟み撃ちで進める。
挟み撃ちでなるほど！と思ったものの、この両者との調整を想像するととても大変。。随所でこみぃさんコメントがありますが、データモデリングは根性の要る仕事です。
でも、ここでいいデータが提供できれば、データモデリングの良さにみんなが気づき、より多くの要望（こういう切り口でもデータが見たい、新しいデータも加えたい…）が生まれる！自分達でデータモデリングしだすかもしれない！そしてどんどんデータが整理されていく・・！
そんな世界をめざして頑張りましょう。
データモデリングの手法
ここまでのコミュニケーションと比べれば、どの手法を選ぶかは些細な問題。そして、モデリング手法は実施にデータ利用者が提供データを使いこなせるかや自分達の運用方法を考えて好きなものを選べばOK。
代表的な手法を説明いただきました。
ディメンショナルモデル
大福帳モデル
DataVault
DataVaultは利用者がめちゃめちゃJOINしないといけなくなるんでは？ということでディメンショナルモデルを採用されたとのこと。
ということで、こみぃさんからのPresentationでした！めちゃめちゃ分かりやすかったです👏
Discussion with 参加者
参加者の現場でのデータモデリングの進め方
peiさんの現場でも、まずは一番難しい謎のスプレッドシートを倒して、実例を見せた方がいい。ファクトディメンションとか説明するよりも、モデリングしたいいデータを出すのが早い、とのこと。
（クエリがしんどいんじゃなく、モデルがおかしいんだ）
モデリングして作ったデータを活用するめちゃめちゃいい世界を見せるところから攻めてファンを増やす！というのはとても共感で、たしかにエンジニアも頑張って理解するデータモデリング手法をみんなが理解しようとするのは到底無理かも。
個人的に今、データモデリングって大量にデータがあるなかで、何のデータから整理していけばいいんだ？これ全部分類するのか？と悩んでいましたが、一番難しいやつから倒す！というのは分かりやすい先人の言葉でした。
そして、ディスカッション内で紹介いただいたこんまりメソッドでデータを整理しようなサイトがこちら。（やっぱりdbtを使うのが早いのかなぁ）
とても参考になるので初見の方は是非ご一読ください！
生データの把握やクレンジングってどうやってる？
生データ自体の取込はプロダクトチーム自らがやるようにしているというところも。（Terraformでsnowpipe設定できるようにしてロードしてもらう）
ただ、クレンジングは強制化しているとのこと。理由はクレンジングをすることでログの重複や時間が入っていないとかおかしなことに気づけるから。
後ろの議論にも関連しますが、データを取込んだ人がデータの責任をもつ、というところにもつながるのかと。
なかなか大きな組織の全社統合データ基盤等では、生データの取込とデータ利用者の距離を縮めるのは難しいなぁと悩まされますね。
利用者にはどんな形でデータ提供している？データカタログって必要？
私のプロジェクトでは、結構がっつり海外のデータカタログ製品を使っており、某A製品やA製品等に興味津々でしたが、
参加者は多数派でデータカタログをそこまで使っていないプロジェクトが多し。
Excel（VBAとSQL）を添えて
Confluenceで提供
Excelで渡してる
AWS上にスクラッチで作ってる
そもそもデータカタログは提供していない
dbt docsとelementary reportでやってる
quollio検討中
ソースの基幹システムである程度登録されている
という感じでした。データカタログなくても見たら分かるようなモデリングでデータを提供しようぜというパワープレイヤーも。（そうありたい）
とにかくデータカタログ製品はお高いというコメントが多し。
ただ、リネージュの要望はみなさん高かったのはなるほど～と思いました。データカタログ自体はなくても、エラー発生時の影響調査とかやっぱりリネージュが必要だし、私も今カラムレベルリネージュを切望しております。
ただ、データカタログ製品のリネージュ機能を要望するとオプション●●万とか高すぎるんじゃというお話でした。スクラッチの必要性を理解しました。
そして、そもそもデータカタログってなんで必要なんだっけ？議論に。
データ生産者とデータ利用者が遠すぎると、共通言語にするのが厳しい。このデータって何者？というのをデータ利用者とデータ生産者で共通言語で話せるようにデータカタログがあるんだよ、という話。特に途中で別のプレイヤーに集計されてしまっていたりすると厳しいですよね。
これは組織に寄りそうで、データ生産～利用まで一気通貫でできているところは要らなかったりするよう。ただ、横のドメインの情報は全く分からない。人やチームが複数にまたがると、データカタログがないと厳しくなるのではないかなと思いました。
データカタログにどんなこと書いている？Descriptionをもっときれいにしようという流れは各所あるよう。
文字よりも絵とか動画で表現したいよね、という声も。
データオーナーの情報を載せているというところに対して、データオーナーって何する人？議論へ発展。
データ生産者と利用者が遠いとデータオーナーの設定が難しい
機密情報のコントロールだったり、データに関する質問だったり、責任ばっかりが伴うので、何かメリットがあるといいよね。
データを作った人がオーナーになった方がいいのでは。
でも、データを作った人ってマートを作った人かソースを取込んだ人か？
モデラ―が全部やるのは厳しいし、データを生んでいる人が一番知っている人だからデータ生産者がオーナーになるのがいいんでは？
データ自体をプロダクトという意識をもってもらう（なんでソフトウェア開発だと自分達が作った機能に責任をもつのに、データだとSQLでかちゃかちゃしちゃうんだ）
まさに次のテーマはDataOpsです
ちなみに、ここでのSQLかちゃかちゃしないで議論のなかで、SQLってあんまり共通的なコーディングルールないのかな？という話に。
おすすめいただいたのはsqlfmt
これを使うと変なSQLを書こうとしてもsqlfmtがダメと言ってるから書けないよと歯止めできるそう💡
あとはdbtのSQL fluffを使っているよーという方も。
実際どんなモデリング手法を使っている？？
今回の参加者のなかにDataVaultを使っている人はいませんでした。
ディメンションモデルや大福帳モデルが多い印象。
semantic layerもデータモデルの一種？という話に。
かっこいいけどやっていないという声も。
BIでごりごりやるよりも大福帳提供した方がうまくいったりすることもあるが、BIが単純なVIEWであって、SemanticLayerを理解してればいい。
そして、知識の分散が発生しにくいところがいい。
生データを提供する直前の状態にするのがモデリングなので、SemanticLayerはそこよりもビジネスロジックに寄ったところのモデリングかもね、という意見も。
いずれにせよ革命的でかっこいいねという印象でした。
議論も白熱したので、長くなってしまいましたが、以上が第3回のデタマネ会ディスカッションでした！
次回のデタマネ会についてはSnowVillage slackのdata managementチャネルにてご連絡します。
最後まで読んでくださった方ありがとうございましたー！！