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 

   のデータ基盤

   

   View Slide

2. Github,Twitter: @mashiike

   所属: 技術部

   役割: 

   ● データエンジニア

   ● サーバーサイドエンジニア

   ● SRE

   好きなAWSサービス: 

   S3, Kinesis Redshift

   日本酒: 八海山

   趣味: オンラインゲーム

   ※2021/09 時点ではElite: Dangerousをプレイ

   自己紹介

   ※アイコンは季節によってバリ
   エーションがあります 

   9月〜

   7月〜8月

   11月~2月
 3月〜6月
 default

   

   View Slide

3. 会社紹介

   商号：株式会社カヤック

   所在地：鎌倉

   事業内容：

   

   日本的面白コンテンツ事業

   

   

   View Slide

4. ● 事業紹介と背景

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

   ● 解決策 【DBT】【Data Vault 2.0】

   ● まとめ

   アジェンダ

   

   View Slide

5. 事業紹介と背景

   

   View Slide

6. 事業紹介

   『大会』は選手にとって晴れ舞台

   しかし、大会を主催するためには大きな労力が必要

   大会主催者の力になる！

   このミッションを実現する世界的な大会プラットフォームを目指しています

   

   View Slide

7. 背景
 9/7 BigData-JAWS #18 で発表してきました

   https://speakerdeck.com/mashiike/mwaa-redshiftdegou-cheng-saretadetaji-pan-falsegou-zhu
   

   https://jawsug-bigdata.connpass.com/event/215161/
   

   

   View Slide

8. 背景

   ビジネスの変化でDBが増えたため、Redashのみだときつい

   もう無理ー

   11月~2月

   

   View Slide

9. 背景

   なので、MWAA+Redshiftでデータ基盤を構築しました。

   これで安心

   3月〜6月

   

   View Slide

10. Tonamelデータ基盤(概要）
    

    

    司令塔
    

    背景

    

    View Slide

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

    

    View Slide

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

    Production環境

    Develop環境

    リリース時にビックバン的にサービスや新機能が増える

    

    View Slide

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

    Production環境

    Develop環境

    リリース時にビックバン的にサービスや新機能が増える

    ○○のリリースをしたら

    データをすぐ見れるようにしてほしい！

    （いろいろ判断したい。

    　出来れば１日目の初速が知りたい！）

    Production環境の

    テーブルのマイグレーション？

    リリース前日くらいにやっとくかなー。

    事例１：リリース直後のKPI
    

    View Slide

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

    Production環境

    Develop環境

    リリース時にビックバン的にサービスや新機能が増える

    なんか、Slackの通知おかしくない？

    事例2：データ構造変更による再集計
    変換後のデータ

    がおかしいぞ！

    DynamoDBのテーブル構造が変
    わってる！

    FFAの対戦カードの人数が多すぎるから

    参加者の情報の持ち方変えました！！！

    再集計が必要
    変更が入ると・・・
    

    View Slide

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

    プロダクトはGit Flowで開発
    データ基盤はProduction環境のみ存在
    ● 新機能に対するデータモデリング

    の時間確保

    ● ロジックやデータ構造が変化した場
    合の修正対応の大変さ

    

    View Slide

16. 動けばいい・・・(ﾎﾞｿ 

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

    DAGフォルダの中

    ETLの実装はSQL

    実態は素朴なファイルで管理

    ※SQLのモジュール化はしていない。
    

    image_check.pyの一部抜粋 

    create_staging.sqlの一部抜粋 

    

    View Slide

17. 動けばいい・・・(ﾎﾞｿ 

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

    DAGフォルダの中

    ETLの実装はSQL

    実態は素朴なファイルで管理

    ※SQLのモジュール化はしていない。
    

    image_check.pyの一部抜粋 

    create_staging.sqlの一部抜粋 

    やりたいこと

    ここに

    ヤバヤバな画像が

    設定されたら

    カスタマーサポート(CS)

    　　　　　にお知らせ！

    

    View Slide

18. 動けばいい・・・(ﾎﾞｿ 

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

    DAGフォルダの中

    ETLの実装はSQL

    実態は素朴なファイルで管理

    ※SQLのモジュール化はしていない。
    

    image_check.pyの一部抜粋 

    create_staging.sqlの一部抜粋 

    画像が投稿されたら、S3のNotification経由で

    Rekognitionを使ってDetectModerationLabelsを実行して、Redshiftに
    結果を入れる。そして、Slackに通知する
    

    View Slide

19. 動けばいい・・・(ﾎﾞｿ 

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

    DAGフォルダの中

    ETLの実装はSQL

    実態は素朴なファイルで管理

    ※SQLのモジュール化はしていない。
    

    image_check.pyの一部抜粋 

    create_staging.sqlの一部抜粋 

    その通知をするためのAirflowの

    DAGは素朴なSQLファイル群で構成
    DAGフォルダの中

    image_check.pyの一部抜粋
    カスタムオペレータからSQLファイルを読んで
    RedshiftにクエリをMWAAが投げる
    

    View Slide

20. 動けばいい・・・(ﾎﾞｿ 

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

    DAGフォルダの中

    ETLの実装はSQL

    実態は素朴なファイルで管理

    ※SQLのモジュール化はしていない。
    

    image_check.pyの一部抜粋 

    create_staging.sqlの一部抜粋 

    create_staging.sqlの一部抜粋 

    素朴な

    SQLファイルが

    たくさん！

    

    View Slide

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

    ほぼ、同じだけど違うのdag_id・・・

    保守・管理が大変になる！

    素朴な管理だとこういうことになる
    

    View Slide

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

    プロダクトはGit Flowで開発
    データ基盤はProduction環境のみ存在
    ● 新機能に対するデータモデリング

    の時間確保

    ● ロジックやデータ構造が変化した場
    合の修正対応の大変さ

    

    ETLの実装はSQL、SQLは素朴な管理
    ● コピペSQLの増加によって

    保守・管理が大変

    （SQLの管理はファイルにベタ書き）

    

    View Slide

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

    プロダクトはGit Flowで開発
    データ基盤はProduction環境のみ存在
    ● 新機能に対するデータモデリング

    の時間確保

    ● ロジックやデータ構造が変化した場
    合の修正対応の大変さ

    ETLの実装はSQL、SQLは素朴な管理
    ● コピペSQLの増加によって

    保守・管理が大変

    （SQLの管理はファイルにベタ書き）

    ● データ基盤の複数環境化

    ● SQLの効率的な開発方法

    ● 再モデリング・再集計の回避

    解決方法の方向性
    開発・運用は１人（分業）
    〜人のスケールはまだできないが、
    　　データ基盤はスケールさせたい〜

    

    View Slide

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

    

    View Slide

25. https://www.getdbt.com/
    データ変換ツール

    https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107
    データモデリング手法

    Data Vault 2.0

    

    View Slide

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の効率的な開発方法
    

    View Slide

27. dbtのフォルダ構造(公式example)
    一つ一つのSQLファイルは

    Jinja2テンプレート記法で

    便利な記述が可能

    my_first_dbt_model.sqlの一部抜粋
    dbtの実行結果
    

    View Slide

28. dbtのフォルダ構造(公式example)
    一つ一つのSQLファイルは

    Jinja2テンプレート記法で

    便利な記述が可能

    my_first_dbt_model.sqlの一部抜粋
    dbtの実行結果
    データ抽出のSELECT文を書くだけで

    いい感じにテーブルのマイグレーション等をしつつ作成可能

    

    View Slide

29. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    https://docs.getdbt.com/docs/guides/managing-environments
    Develop環境どう作ろう？

    曰く。。。

    

    View Slide

30. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    １つのRedshiftに同居させろ！

    Schemaを分離しろ！

    profiles.ymlで切り替えろ！

    それが我々のおすすめだ。

    Redshift

    prod-mwaa-env

    dev-mwaa-env

    connect with
    prod profie

    connect with dev
    profie

    

    View Slide

31. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    オプションで環境を選択

    Jinja2テンプレート構文を使ってSQLを切り替えられるぞ！！！

    

    View Slide

32. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros
    コピペSQLどうしよう。。。

    曰く。。。

    Macroという機能があるぞ

    

    View Slide

33. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros
    コピペSQLどうしよう。。。

    曰く。。。

    Macroという機能があるぞ

    

    View Slide

34. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros
    コピペSQLどうしよう。。。

    曰く。。。

    Macroという機能があるぞ

    SQLをモジュール化が可能

    

    View Slide

35. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生LogのSpectrum クレンジング済みLogのSpectrum
    Redshift内部に保持しているクレンジング済みログ
    

    View Slide

36. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生LogのSpectrum クレンジング済みLogのSpectrum
    Redshift内部に保持しているクレンジング済みログ
    

    View Slide

37. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生LogのSpectrum クレンジング済みLogのSpectrum
    Redshift内部に保持しているクレンジング済みログ
    S3へのUNLOAD

    古い

    データの

    削除

    テーブルの圧縮

    

    View Slide

38. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生LogのSpectrum クレンジング済みLogのSpectrum
    Redshift内部に保持しているクレンジング済みログ
    名前解決のついでに依存関係を処理 

    ２回目以降の実行のときだけ描画することも 

    実行時に実際にクエリして、その結果を描画することも 

    テーブルがなかったら、prodは全部、devは直近7日を読み込み

    テーブルが既にあったら、最後のパーティション以降を読み込み

    

    View Slide

39. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生ログのSpectrum クレンジング済みログのSpectrum
    UNLOAD

    古くなったら行を削除

    Redshift内部に保持しているクレンジング済みログ
    今あるものより新しいものだ
    け処理して差分更新

    

    View Slide

40. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生LogのSpectrum クレンジング済みLogのSpectrum
    UNLOAD

    古くなったら行を削除

    Redshift内部に保持しているクレンジング済みログ
    今あるものより新しいものだ
    け処理

    hotのテーブルに残ってる日付より前のPartitionを特定し、

    データをクレンジング済みログのSpectrumから読むView

    

    View Slide

41. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生ログのSpectrum
    クレンジング済みログのSpectrum
    UNLOAD

    古くなったら行を削除

    Redshift内部に保持しているクレンジング済みログ
    今あるものより新しいものだ
    け処理

    Redshift内に保持されてないものを

    Spectrumから読むView

    

    View Slide

42. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生ログのSpectrum
    クレンジング済みログのSpectrum
    UNLOAD

    古くなったら行を削除

    Redshift内部に保持しているクレンジング済みログ
    今あるものより新しいものだ
    け処理

    Redshift内に保持されてないものを

    Spectrumから読むView

    

    View Slide

43. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    具体的な例として、いい感じにLogを見るView（Lambda View Patternの実装)

    生ログのSpectrum
    クレンジング済みログのSpectrum
    UNLOAD

    古くなったら行を削除

    Redshift内部に保持しているクレンジング済みログ
    今あるものより新しいものだ
    け処理

    Redshift内に保持されてないものを

    Spectrumから読むView

    最終的に結合して、いい感じに見るためのView

    

    View Slide

44. 問題にどう対応するのか？　〜DBT(Data Build Tool)の利用〜

    超便利！

    欠点？ググラビリティ・・・・？ 

    

    View Slide

45. https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107
    データモデリング手法

    Data Vault 2.0

    https://www.getdbt.com/
    データ変換ツール

    

    View Slide

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、非構造化、半構造化のシームレスな統
    合、および方法論、アーキテクチャ、実装のベストプラク
    ティスを提供

    ● 再モデリング・再集計の回避
    

    View Slide

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

    

    View Slide

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 はプロダクトのシステムの
    

    　　ビジネスロジックに関わる重要なデータ変換
    

    

    View Slide

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

    

    View Slide

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

    なるほど？

    Hard business rules にはそのビジネス固有のデータ変換は存在しない

    あるのは意味を変えない型変換・TZ変換などの『手堅い』変換だけだ

    

    なので、安定している。頻繁に変わることはない

    『手堅い』変換だけを済ませた生のデータを

    履歴的な形できれいに保存して

    Data Vault層とする。

    履歴なので、基本的には追記のみ

    

    View Slide

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

    なるほど？

    各種の最終的な変換後のデータを扱うdata mart層は

    基本的にDB Viewで構成される

    

    DB ViewなのでSoft business rules が頻繁に変わったとしても影響は少ない

    基本的にS3へはフルリプレイスで

    UNLOADする。

    読み込みはmanifest.json を使えば問題ない

    

    View Slide

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

    なるほど？

    で、肝心のココ

    どうやって作るん？

    ココ

    plz read me...

    HubとLinkとSatelliteの３要素で構成

    

    Hubはビジネスキーの存在履歴

    Linkがビジネスキー間の関係履歴

    Satelliteがビジネスキーや関係を

    説明する属性の変更履歴

    

    View Slide

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

    詳しく語ると

    長すぎるので割愛

    履歴データって大事だねぇ・・・

    

    View Slide

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

    複数のデータソースから入ってくるデータの長期的な履
    歴ストレージを提供するように設計された
    

    データベースモデリング手法
    

    

    

    （再掲）
    

    View Slide

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

    複数のデータソースから入ってくるデータの長期的な履
    歴ストレージを提供するように設計された
    

    データベースモデリング手法
    

    

    

    （再掲）
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models
    複数のデータソースからの
    

    依存関係を管理しやすい
    

    View Slide

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

    複数のデータソースから入ってくるデータの長期的な
    履
    歴ストレージを提供するように設計された
    

    データベースモデリング手法
    

    

    

    （再掲）
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models
    履歴データを構築するための
    

    差分更新のメカニズム

    

    View Slide

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

    複数のデータソースから入ってくるデータの長期的な
    履
    歴ストレージを提供するように設計された
    

    データベースモデリング手法
    

    

    

    （再掲）
    https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models
    Data Vault 2.0を実践す
    るにあたり…
    超便利！
    

    View Slide

58. まとめ

    ビジネスの変化によってDBが増えたため、データ基盤を新設。

    しかし、そのデータ基盤を運用してみると課題が発生し、

    以下の対策が必要になった。

    1. データ基盤の複数環境化

    2. SQLの効率的な開発方法

    3. 再モデリング・再集計の回避

    4. データエンジニアの増員

    1,2はDBTというツールを使うことで、効率よく対応可能

    3はData Vault 2.0 というデータモデリング手法を使うと

    スケーラブルで履歴的なデータモデルを管理

    　　　そして、Data Vault 2.0の実装にDBTがとても便利である。

    　　　

    　　　これらの導入で格段に保守管理が楽になった。

    

    View Slide

59. 弊社では、データエンジニアリング周りの

    採用活動も継続的に行っています。

    

    View Slide

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

    

    View Slide