Tonamelのデータ基盤 ~データモデリング編~

Slide 1

Slide 1 text

〜データモデリング編〜  2021/09/22 18:30~   nakanoshima.dev #21   面白法人カヤック池田将士 @mashiike   のデータ基盤 

Slide 2

Slide 2 text

Github,Twitter: @mashiike  所属: 技術部  役割:   ● データエンジニア  ● サーバーサイドエンジニア  ● SRE  好きなAWSサービス:   S3, Kinesis Redshift  日本酒: 八海山  趣味: オンラインゲーム  ※2021/09 時点ではElite: Dangerousをプレイ  自己紹介  ※アイコンは季節によってバリエーションがあります   9月〜  7月〜8月  11月~2月  3月〜6月  default 

Slide 3

Slide 3 text

会社紹介  商号：株式会社カヤック  所在地：鎌倉  事業内容：    日本的面白コンテンツ事業   

Slide 4

Slide 4 text

● 事業紹介と背景  ● データ基盤を運用して起きた課題  ● 解決策【DBT】【Data Vault 2.0】  ● まとめ  アジェンダ 

Slide 5

Slide 5 text

事業紹介と背景 

Slide 6

Slide 6 text

事業紹介  『大会』は選手にとって晴れ舞台  しかし、大会を主催するためには大きな労力が必要  大会主催者の力になる！  このミッションを実現する世界的な大会プラットフォームを目指しています 

Slide 7

Slide 7 text

背景  9/7 BigData-JAWS #18 で発表してきました  https://speakerdeck.com/mashiike/mwaa-redshiftdegou-cheng-saretadetaji-pan-falsegou-zhu   https://jawsug-bigdata.connpass.com/event/215161/  

Slide 8

Slide 8 text

背景  ビジネスの変化でDBが増えたため、Redashのみだときつい  もう無理ー  11月~2月 

Slide 9

Slide 9 text

背景  なので、MWAA+Redshiftでデータ基盤を構築しました。  これで安心  3月〜6月 

Slide 10

Slide 10 text

Tonamelデータ基盤(概要）     司令塔   背景 

Slide 11

Slide 11 text

データ基盤を運用して起きた課題 

Slide 12

Slide 12 text

データ基盤を運用して起きた課題   Production環境  Develop環境  リリース時にビックバン的にサービスや新機能が増える 

Slide 13

Slide 13 text

データ基盤を運用して起きた課題   Production環境  Develop環境  リリース時にビックバン的にサービスや新機能が増える  ○○のリリースをしたら  データをすぐ見れるようにしてほしい！  （いろいろ判断したい。  　出来れば１日目の初速が知りたい！）  Production環境の  テーブルのマイグレーション？  リリース前日くらいにやっとくかなー。  事例１：リリース直後のKPI

Slide 14

Slide 14 text

データ基盤を運用して起きた課題   Production環境  Develop環境  リリース時にビックバン的にサービスや新機能が増える  なんか、Slackの通知おかしくない？  事例2：データ構造変更による再集計変換後のデータ  がおかしいぞ！  DynamoDBのテーブル構造が変わってる！  FFAの対戦カードの人数が多すぎるから  参加者の情報の持ち方変えました！！！  再集計が必要変更が入ると・・・

Slide 15

Slide 15 text

データ基盤を運用して起きた課題  プロダクトはGit Flowで開発データ基盤はProduction環境のみ存在 ● 新機能に対するデータモデリング  の時間確保  ● ロジックやデータ構造が変化した場合の修正対応の大変さ 

Slide 16

Slide 16 text

動けばいい・・・(ﾎﾞｿ   データ基盤を運用して起きた課題   DAGフォルダの中  ETLの実装はSQL  実態は素朴なファイルで管理  ※SQLのモジュール化はしていない。   image_check.pyの一部抜粋   create_staging.sqlの一部抜粋  

Slide 17

Slide 17 text

動けばいい・・・(ﾎﾞｿ   データ基盤を運用して起きた課題   DAGフォルダの中  ETLの実装はSQL  実態は素朴なファイルで管理  ※SQLのモジュール化はしていない。   image_check.pyの一部抜粋   create_staging.sqlの一部抜粋   やりたいこと  ここに  ヤバヤバな画像が  設定されたら  カスタマーサポート(CS)  　　　　　にお知らせ！ 

Slide 18

Slide 18 text

動けばいい・・・(ﾎﾞｿ   データ基盤を運用して起きた課題   DAGフォルダの中  ETLの実装はSQL  実態は素朴なファイルで管理  ※SQLのモジュール化はしていない。   image_check.pyの一部抜粋   create_staging.sqlの一部抜粋   画像が投稿されたら、S3のNotification経由で  Rekognitionを使ってDetectModerationLabelsを実行して、Redshiftに結果を入れる。そして、Slackに通知する

Slide 19

Slide 19 text

動けばいい・・・(ﾎﾞｿ   データ基盤を運用して起きた課題   DAGフォルダの中  ETLの実装はSQL  実態は素朴なファイルで管理  ※SQLのモジュール化はしていない。   image_check.pyの一部抜粋   create_staging.sqlの一部抜粋   その通知をするためのAirflowの  DAGは素朴なSQLファイル群で構成 DAGフォルダの中  image_check.pyの一部抜粋カスタムオペレータからSQLファイルを読んで RedshiftにクエリをMWAAが投げる

Slide 20

Slide 20 text

動けばいい・・・(ﾎﾞｿ   データ基盤を運用して起きた課題   DAGフォルダの中  ETLの実装はSQL  実態は素朴なファイルで管理  ※SQLのモジュール化はしていない。   image_check.pyの一部抜粋   create_staging.sqlの一部抜粋   create_staging.sqlの一部抜粋   素朴な  SQLファイルが  たくさん！ 

Slide 21

Slide 21 text

データ基盤を運用して起きた課題   ほぼ、同じだけど違うのdag_id・・・  保守・管理が大変になる！  素朴な管理だとこういうことになる

Slide 22

Slide 22 text

Slide 23

Slide 23 text

データ基盤を運用して起きた課題  プロダクトはGit Flowで開発データ基盤はProduction環境のみ存在 ● 新機能に対するデータモデリング  の時間確保  ● ロジックやデータ構造が変化した場合の修正対応の大変さ  ETLの実装はSQL、SQLは素朴な管理 ● コピペSQLの増加によって  保守・管理が大変  （SQLの管理はファイルにベタ書き）  ● データ基盤の複数環境化  ● SQLの効率的な開発方法  ● 再モデリング・再集計の回避  解決方法の方向性開発・運用は１人（分業）〜人のスケールはまだできないが、　　データ基盤はスケールさせたい〜 

Slide 24

Slide 24 text

解決策【DBT】【Data Vault 2.0】 

Slide 25

Slide 25 text

https://www.getdbt.com/ データ変換ツール  https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 データモデリング手法  Data Vault 2.0 

Slide 26

Slide 26 text

https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 データモデリング手法  Data Vault 2.0  https://www.getdbt.com/ データ変換ツール  OSSであり、  Python Jinja2テンプレート記法による強力なSQLビルダー/ランナー  【導入目的】  ● データ基盤の複数環境化  ● SQLの効率的な開発方法

Slide 27

Slide 27 text

dbtのフォルダ構造(公式example) 一つ一つのSQLファイルは  Jinja2テンプレート記法で  便利な記述が可能  my_first_dbt_model.sqlの一部抜粋 dbtの実行結果

Slide 28

Slide 28 text

dbtのフォルダ構造(公式example) 一つ一つのSQLファイルは  Jinja2テンプレート記法で  便利な記述が可能  my_first_dbt_model.sqlの一部抜粋 dbtの実行結果データ抽出のSELECT文を書くだけで  いい感じにテーブルのマイグレーション等をしつつ作成可能 

Slide 29

Slide 29 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  https://docs.getdbt.com/docs/guides/managing-environments Develop環境どう作ろう？  曰く。。。 

Slide 30

Slide 30 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  １つのRedshiftに同居させろ！  Schemaを分離しろ！  profiles.ymlで切り替えろ！  それが我々のおすすめだ。  Redshift  prod-mwaa-env  dev-mwaa-env  connect with prod profie  connect with dev profie 

Slide 31

Slide 31 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  オプションで環境を選択  Jinja2テンプレート構文を使ってSQLを切り替えられるぞ！！！ 

Slide 32

Slide 32 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros コピペSQLどうしよう。。。  曰く。。。  Macroという機能があるぞ 

Slide 33

Slide 33 text

Slide 34

Slide 34 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros コピペSQLどうしよう。。。  曰く。。。  Macroという機能があるぞ  SQLをモジュール化が可能 

Slide 35

Slide 35 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)  生LogのSpectrum クレンジング済みLogのSpectrum Redshift内部に保持しているクレンジング済みログ

Slide 36

Slide 36 text

Slide 37

Slide 37 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)  生LogのSpectrum クレンジング済みLogのSpectrum Redshift内部に保持しているクレンジング済みログ S3へのUNLOAD  古い  データの  削除  テーブルの圧縮 

Slide 38

Slide 38 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)  生LogのSpectrum クレンジング済みLogのSpectrum Redshift内部に保持しているクレンジング済みログ名前解決のついでに依存関係を処理   ２回目以降の実行のときだけ描画することも   実行時に実際にクエリして、その結果を描画することも   テーブルがなかったら、prodは全部、devは直近7日を読み込み  テーブルが既にあったら、最後のパーティション以降を読み込み 

Slide 39

Slide 39 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)  生ログのSpectrum クレンジング済みログのSpectrum UNLOAD  古くなったら行を削除  Redshift内部に保持しているクレンジング済みログ今あるものより新しいものだけ処理して差分更新 

Slide 40

Slide 40 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)  生LogのSpectrum クレンジング済みLogのSpectrum UNLOAD  古くなったら行を削除  Redshift内部に保持しているクレンジング済みログ今あるものより新しいものだけ処理  hotのテーブルに残ってる日付より前のPartitionを特定し、  データをクレンジング済みログのSpectrumから読むView 

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜  超便利！  欠点？ググラビリティ・・・・？  

Slide 45

Slide 45 text

https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 データモデリング手法  Data Vault 2.0  https://www.getdbt.com/ データ変換ツール 

Slide 46

Slide 46 text

https://www.getdbt.com/ データ変換ツール  https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 データモデリング手法  Data Vault 2.0  複数のデータソースから入ってくるデータの長期的な履歴ストレージを提供するように設計された   データベースモデリング手法     2000年にDaniel（Dan）Linstedtによって開発     Data Vault 2.0は2013年に登場した新しい仕様。ビッグデータ、NoSQL、非構造化、半構造化のシームレスな統合、および方法論、アーキテクチャ、実装のベストプラクティスを提供  ● 再モデリング・再集計の回避

Slide 47

Slide 47 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜 

Slide 48

Slide 48 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  Hard business rules never change the meaning of the incoming data, only the way the data is stored.  Soft business rules define how the data is aggregated or consolidated. They also define how the data is transformed to meet the requirements of the business.  Hard business rules は  データの意味を変えることのない。例えば …     0, 1 (integer) -> false, true (boolean)     みたいな変換    Soft business rules はプロダクトのシステムの   　　ビジネスロジックに関わる重要なデータ変換  

Slide 49

Slide 49 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜 

Slide 50

Slide 50 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  なるほど？  Hard business rules にはそのビジネス固有のデータ変換は存在しない  あるのは意味を変えない型変換・TZ変換などの『手堅い』変換だけだ    なので、安定している。頻繁に変わることはない  『手堅い』変換だけを済ませた生のデータを  履歴的な形できれいに保存して  Data Vault層とする。  履歴なので、基本的には追記のみ 

Slide 51

Slide 51 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  なるほど？  各種の最終的な変換後のデータを扱うdata mart層は  基本的にDB Viewで構成される    DB ViewなのでSoft business rules が頻繁に変わったとしても影響は少ない  基本的にS3へはフルリプレイスで  UNLOADする。  読み込みはmanifest.json を使えば問題ない 

Slide 52

Slide 52 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  なるほど？  で、肝心のココ  どうやって作るん？  ココ  plz read me...  HubとLinkとSatelliteの３要素で構成    Hubはビジネスキーの存在履歴  Linkがビジネスキー間の関係履歴  Satelliteがビジネスキーや関係を  説明する属性の変更履歴 

Slide 53

Slide 53 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  詳しく語ると  長すぎるので割愛  履歴データって大事だねぇ・・・ 

Slide 54

Slide 54 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  複数のデータソースから入ってくるデータの長期的な履歴ストレージを提供するように設計された   データベースモデリング手法       （再掲）

Slide 55

Slide 55 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  複数のデータソースから入ってくるデータの長期的な履歴ストレージを提供するように設計された   データベースモデリング手法       （再掲） https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models 複数のデータソースからの   依存関係を管理しやすい

Slide 56

Slide 56 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  複数のデータソースから入ってくるデータの長期的な履歴ストレージを提供するように設計された   データベースモデリング手法       （再掲） https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models 履歴データを構築するための   差分更新のメカニズム 

Slide 57

Slide 57 text

問題にどう対応するのか？　〜Data Vault 2.0の実践〜  複数のデータソースから入ってくるデータの長期的な履歴ストレージを提供するように設計された   データベースモデリング手法       （再掲） https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models Data Vault 2.0を実践するにあたり… 超便利！

Slide 58

Slide 58 text

まとめ  ビジネスの変化によってDBが増えたため、データ基盤を新設。  しかし、そのデータ基盤を運用してみると課題が発生し、  以下の対策が必要になった。  1. データ基盤の複数環境化  2. SQLの効率的な開発方法  3. 再モデリング・再集計の回避  4. データエンジニアの増員  1,2はDBTというツールを使うことで、効率よく対応可能  3はData Vault 2.0 というデータモデリング手法を使うと  スケーラブルで履歴的なデータモデルを管理  　　　そして、Data Vault 2.0の実装にDBTがとても便利である。  　　　  　　　これらの導入で格段に保守管理が楽になった。 

Slide 59

Slide 59 text

弊社では、データエンジニアリング周りの  採用活動も継続的に行っています。 

Slide 60

Slide 60 text

ご清聴ありがとうございました 