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

#nakanoshima_dev 9/22 18:30~

https://nakanoshima-dev.connpass.com/event/221243/

nakanoshima.dev #21 LED!! (Let's enjoy データ分析!!)の発表資料です。

Transcript

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

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

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

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

5. 事業紹介と背景

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

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

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

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

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

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

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

13. データ基盤を運用して起きた課題 
 Production環境
 Develop環境
 リリース時にビックバン的にサービスや新機能が増える
 ◦◦のリリースをしたら
 データをすぐ見れるようにしてほしい！
 （いろいろ判断したい。
 　出来れば１日目の初速が知りたい！）
 Production環境の
 テーブルのマイグレーション？
 リリース前日くらいにやっとくかなー。
 事例１：リリース直後のKPI
14. データ基盤を運用して起きた課題 
 Production環境
 Develop環境
 リリース時にビックバン的にサービスや新機能が増える
 なんか、Slackの通知おかしくない？
 事例2：データ構造変更による再集計 変換後のデータ
 がおかしいぞ！
 DynamoDBのテーブル構造が変 わってる！
 FFAの対戦カードの人数が多すぎるから
 参加者の情報の持ち方変えました！！！
 再集計が必要 変更が入ると・・・
15. データ基盤を運用して起きた課題
 プロダクトはGit Flowで開発 データ基盤はProduction環境のみ存在 • 新機能に対するデータモデリング
 の時間確保
 • ロジックやデータ構造が変化した場 合の修正対応の大変さ

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

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

18. 動けばいい・・・(ﾎﾞｿ 
 データ基盤を運用して起きた課題 
 DAGフォルダの中
 ETLの実装はSQL
 実態は素朴なファイルで管理
 ※SQLのモジュール化はしていない。 
 image_check.pyの一部抜粋 
 create_staging.sqlの一部抜粋 
 画像が投稿されたら、S3のNotification経由で
 Rekognitionを使ってDetectModerationLabelsを実行して、Redshiftに 結果を入れる。そして、Slackに通知する
19. 動けばいい・・・(ﾎﾞｿ 
 データ基盤を運用して起きた課題 
 DAGフォルダの中
 ETLの実装はSQL
 実態は素朴なファイルで管理
 ※SQLのモジュール化はしていない。 
 image_check.pyの一部抜粋 
 create_staging.sqlの一部抜粋 
 その通知をするためのAirflowの
 DAGは素朴なSQLファイル群で構成 DAGフォルダの中
 image_check.pyの一部抜粋 カスタムオペレータからSQLファイルを読んで RedshiftにクエリをMWAAが投げる
20. 動けばいい・・・(ﾎﾞｿ 
 データ基盤を運用して起きた課題 
 DAGフォルダの中
 ETLの実装はSQL
 実態は素朴なファイルで管理
 ※SQLのモジュール化はしていない。 
 image_check.pyの一部抜粋 
 create_staging.sqlの一部抜粋 
 create_staging.sqlの一部抜粋 
 素朴な
 SQLファイルが
 たくさん！

21. データ基盤を運用して起きた課題 
 ほぼ、同じだけど違うのdag_id・・・
 保守・管理が大変になる！
 素朴な管理だとこういうことになる
22. データ基盤を運用して起きた課題
 プロダクトはGit Flowで開発 データ基盤はProduction環境のみ存在 • 新機能に対するデータモデリング
 の時間確保
 • ロジックやデータ構造が変化した場 合の修正対応の大変さ
 
 ETLの実装はSQL、SQLは素朴な管理 • コピペSQLの増加によって
 保守・管理が大変
 （SQLの管理はファイルにベタ書き）

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

24. 解決策 【DBT】【Data Vault 2.0】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. 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、非構造化、半構造化のシームレスな統 合、および方法論、アーキテクチャ、実装のベストプラク ティスを提供
 • 再モデリング・再集計の回避
47. 問題にどう対応するのか？　〜Data Vault 2.0の実践〜

48. 問題にどう対応するのか？　〜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 はプロダクトのシステムの 
 　　ビジネスロジックに関わる重要なデータ変換 

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

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

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

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

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

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

57. 問題にどう対応するのか？　〜Data Vault 2.0の実践〜
 複数のデータソースから入ってくるデータの長期的な 履 歴ストレージを提供するように設計された 
 データベースモデリング手法 
 
 
 （再掲） https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models Data Vault 2.0を実践す るにあたり… 超便利！
58. まとめ
 ビジネスの変化によってDBが増えたため、データ基盤を新設。
 しかし、そのデータ基盤を運用してみると課題が発生し、
 以下の対策が必要になった。
 1. データ基盤の複数環境化
 2. SQLの効率的な開発方法
 3. 再モデリング・再集計の回避
 4. データエンジニアの増員
 1,2はDBTというツールを使うことで、効率よく対応可能
 3はData Vault 2.0 というデータモデリング手法を使うと
 スケーラブルで履歴的なデータモデルを管理
 　　　そして、Data Vault 2.0の実装にDBTがとても便利である。
 　　　
 　　　これらの導入で格段に保守管理が楽になった。

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

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