Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ikeda-masashi
September 22, 2021

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

#nakanoshima_dev 9/22 18:30~

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

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

ikeda-masashi

September 22, 2021
Tweet

More Decks by ikeda-masashi

Other Decks in Technology

Transcript

  1. Github,Twitter: @mashiike
 所属: 技術部
 役割: 
 • データエンジニア
 • サーバーサイドエンジニア


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

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

    
 create_staging.sqlの一部抜粋 
 やりたいこと
 ここに
 ヤバヤバな画像が
 設定されたら
 カスタマーサポート(CS)
      にお知らせ!

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

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

    
 create_staging.sqlの一部抜粋 
 その通知をするためのAirflowの
 DAGは素朴なSQLファイル群で構成 DAGフォルダの中
 image_check.pyの一部抜粋 カスタムオペレータからSQLファイルを読んで RedshiftにクエリをMWAAが投げる
  5. データ基盤を運用して起きた課題
 プロダクトはGit Flowで開発 データ基盤はProduction環境のみ存在 • 新機能に対するデータモデリング
 の時間確保
 • ロジックやデータ構造が変化した場 合の修正対応の大変さ


    ETLの実装はSQL、SQLは素朴な管理 • コピペSQLの増加によって
 保守・管理が大変
 (SQLの管理はファイルにベタ書き)
 • データ基盤の複数環境化
 • SQLの効率的な開発方法
 • 再モデリング・再集計の回避
 解決方法の方向性 開発・運用は1人(分業) 〜人のスケールはまだできないが、   データ基盤はスケールさせたい〜

  6. 問題にどう対応するのか? 〜DBT(Data Build Tool)の利用〜
 具体的な例として、いい感じにLogを見るView(Lambda View Patternの実装)
 生LogのSpectrum クレンジング済みLogのSpectrum Redshift内部に保持しているクレンジング済みログ 名前解決のついでに依存関係を処理

    
 2回目以降の実行のときだけ描画することも 
 実行時に実際にクエリして、その結果を描画することも 
 テーブルがなかったら、prodは全部、devは直近7日を読み込み
 テーブルが既にあったら、最後のパーティション以降を読み込み

  7. 問題にどう対応するのか? 〜DBT(Data Build Tool)の利用〜
 具体的な例として、いい感じにLogを見るView(Lambda View Patternの実装)
 生LogのSpectrum クレンジング済みLogのSpectrum UNLOAD
 古くなったら行を削除


    Redshift内部に保持しているクレンジング済みログ 今あるものより新しいものだ け処理
 hotのテーブルに残ってる日付より前のPartitionを特定し、
 データをクレンジング済みログのSpectrumから読むView

  8. 問題にどう対応するのか? 〜DBT(Data Build Tool)の利用〜
 具体的な例として、いい感じにLogを見るView(Lambda View Patternの実装)
 生ログのSpectrum クレンジング済みログのSpectrum UNLOAD
 古くなったら行を削除


    Redshift内部に保持しているクレンジング済みログ 今あるものより新しいものだ け処理
 Redshift内に保持されてないものを
 Spectrumから読むView

  9. 問題にどう対応するのか? 〜DBT(Data Build Tool)の利用〜
 具体的な例として、いい感じにLogを見るView(Lambda View Patternの実装)
 生ログのSpectrum クレンジング済みログのSpectrum UNLOAD
 古くなったら行を削除


    Redshift内部に保持しているクレンジング済みログ 今あるものより新しいものだ け処理
 Redshift内に保持されてないものを
 Spectrumから読むView

  10. 問題にどう対応するのか? 〜DBT(Data Build Tool)の利用〜
 具体的な例として、いい感じにLogを見るView(Lambda View Patternの実装)
 生ログのSpectrum クレンジング済みログのSpectrum UNLOAD
 古くなったら行を削除


    Redshift内部に保持しているクレンジング済みログ 今あるものより新しいものだ け処理
 Redshift内に保持されてないものを
 Spectrumから読むView
 最終的に結合して、いい感じに見るためのView

  11. 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、非構造化、半構造化のシームレスな統 合、および方法論、アーキテクチャ、実装のベストプラク ティスを提供
 • 再モデリング・再集計の回避
  12. 問題にどう対応するのか? 〜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 はプロダクトのシステムの 
   ビジネスロジックに関わる重要なデータ変換 

  13. 問題にどう対応するのか? 〜Data Vault 2.0の実践〜
 なるほど?
 Hard business rules にはそのビジネス固有のデータ変換は存在しない
 あるのは意味を変えない型変換・TZ変換などの『手堅い』変換だけだ
 


    なので、安定している。頻繁に変わることはない
 『手堅い』変換だけを済ませた生のデータを
 履歴的な形できれいに保存して
 Data Vault層とする。
 履歴なので、基本的には追記のみ

  14. 問題にどう対応するのか? 〜Data Vault 2.0の実践〜
 なるほど?
 各種の最終的な変換後のデータを扱うdata mart層は
 基本的にDB Viewで構成される
 
 DB

    ViewなのでSoft business rules が頻繁に変わったとしても影響は少ない
 基本的にS3へはフルリプレイスで
 UNLOADする。
 読み込みはmanifest.json を使えば問題ない

  15. 問題にどう対応するのか? 〜Data Vault 2.0の実践〜
 なるほど?
 で、肝心のココ
 どうやって作るん?
 ココ
 plz read me...


    HubとLinkとSatelliteの3要素で構成
 
 Hubはビジネスキーの存在履歴
 Linkがビジネスキー間の関係履歴
 Satelliteがビジネスキーや関係を
 説明する属性の変更履歴

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


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


    
 (再掲) https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models 履歴データを構築するための 
 差分更新のメカニズム

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


    
 (再掲) https://docs.getdbt.com/docs/building-a-dbt-project/building-models/configuring-incremental-models Data Vault 2.0を実践す るにあたり… 超便利!
  19. まとめ
 ビジネスの変化によってDBが増えたため、データ基盤を新設。
 しかし、そのデータ基盤を運用してみると課題が発生し、
 以下の対策が必要になった。
 1. データ基盤の複数環境化
 2. SQLの効率的な開発方法
 3. 再モデリング・再集計の回避


    4. データエンジニアの増員
 1,2はDBTというツールを使うことで、効率よく対応可能
 3はData Vault 2.0 というデータモデリング手法を使うと
 スケーラブルで履歴的なデータモデルを管理
    そして、Data Vault 2.0の実装にDBTがとても便利である。
    
    これらの導入で格段に保守管理が楽になった。