「北欧、暮らしの道具店」のデータ基盤の変遷

https://kurashi.com/news/13050

11/15（火) 19:00 ~
「北欧、暮らしの道具店」データ分析チームのトークセッション vol.2
登壇資料。

Transcript

1. 「北欧、暮らしの道具店」のデータ
   基盤の変遷
   〜データ基盤の変遷は
   意思決定のボトルネックとともに〜
   

   View Slide

2. 自己紹介/会社紹介
   池田 将士 (@mashiike)
   面白法人カヤック
   その他事業部 SREチーム所属
   データエンジニア/サーバーサイドエンジニア
   出身: 千葉県
   趣味: オンラインゲームと食べ比べ、飲み比べ
   　　鎌倉が本拠地
   　Web技術が得意な会社
   　　　　　　　　 面白そうな事をやる
   エンジニアが多い
   

   View Slide

3. 「北欧、暮らしの道具店」とカヤックの関係
   伴走型支援
   エンジニアリングリソース
   採用ノウハウ etc…
   カヤックは技術が強みの会社
   エンジニアの数がとても多い
   「北欧、暮らしの道具店」に技術的に関わっていくパート
   ナーの立ち位置にいます。
   +成功事例
   

   View Slide

4. アジェンダ
   ● データ基盤の変遷は???
   ● 「北欧、暮らしの道具店」のデータ基盤の変遷
   ○ 創世記:
   ○ 出MySQL記:
   ○ Looker記:
   ○ そして未来へ:
   …
   

   View Slide

5. データ基盤の変遷は???
   ズバリ。「意思決定のパフォーマンスチューニング」
   

   View Slide

6. データ基盤の変遷は???
   何かしらの意思決定で必要な分析に関して
   ● レスポンスタイム (分析が必要になったときに素早く結果を返せる能力
   )
   ● スループット（一定期間に分析できる能力
   )
   ● 安定性（必要なときに分析できる能力
   )
   ● etc…
   これらに困ったことが起きるとき、データ基盤の変遷は起こる。
   ズバリ。「意思決定のパフォーマンスチューニング」
   

   View Slide

7. データ基盤の変遷は???
   何かしらの意思決定で必要な分析に関して
   ● レスポンスタイム (分析が必要になったときに素早く結果を返せる能力
   )
   ● スループット（一定期間に分析できる能力
   )
   ● 安定性（必要なときに分析できる能力
   )
   ● etc…
   これらに困ったことが起きるとき、データ基盤の変遷は起こる。
   ズバリ。「意思決定のパフォーマンスチューニング」
   つまり、データ基盤の変遷は「分析に関するボトルネックの特定」とともにある
   そして、ボトルネックは移動する データ基盤の変遷は段階的に起きる
   

   View Slide

8. 「北欧、暮らしの道具店」のデータ基盤の変遷
   創世記:
   出MySQL記:
   ボトルネック: 高度な集計クエリ & アプリデータと統合した分析
   

   View Slide

9. 「北欧、暮らしの道具店」のデータ基盤: 創世記
   Webのアクセスデータは
   Google Analytics
   注文・会員情報 etc…は
   MySQL (Redash)
   

   View Slide

10. 「北欧、暮らしの道具店」のデータ基盤: 創世記
    Webのアクセスデータは
    Google Analytics
    注文・会員情報 etc…は
    MySQL (Redash)
    「北欧、暮らしの道具店」
    　アプリリリースにより状況が変わる
    登場
    

    View Slide

11. 「北欧、暮らしの道具店」のデータ基盤: 創世記
    課題:
    ● 基幹DBとFirebase&GA4のデータをか
    け合わせたアプリの分析が困難
    ● MySQLでの集計クエリの実行時間が長
    い
    ボトルネックは分析用DB(MySQL)
    

    View Slide

12. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    

    View Slide

13. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    [余談] 後日、同じことをする OSSツールも開発
    https://github.com/kayac/mascaras
    Viewを使ってExportする方法もあるが、
    開発目的でMaskされたSnapshotがほしいケースも
    あったのでこの方式にした。
    

    View Slide

14. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    

    View Slide

15. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    本番で現在も稼働中
    https://github.com/kayac/bqin
    

    View Slide

16. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    

    View Slide

17. そして、出MySQL記へ すべてのデータをBigQueryへ集約
    BigQueryで分析が完結するようになった結果
    　「SQLが書ける人」に分析のオーダーが集まった！
    クラシコムさんでは
    「SQLを書ける人」が実は少ない。
    ボトルネックが に移動した。
    

    View Slide

18. そして、出MySQL記へ
    ボトルネック
    

    View Slide

19. そして、出MySQL記へ
    ボトルネック
    FirebaseとGoogle Analyticsのデータを生で見るのは大変
    Scheduled Queryで加工処理して分析しやすくしていた
    FirebaseとGoogle AnalyticsのExport
    実は出力される時刻が不安定
    ※最大で72時間遅れることがある
    Scheduled Queryによるデータマート生成も
    　　　　　　　　　　　　実は地味にボトルネック
    

    View Slide

20. そして、出MySQL記へ
    ボトルネック
    

    View Slide

21. 「北欧、暮らしの道具店」のデータ基盤の変遷
    出MySQL記:
    ボトルネック: 「SQLをかける人」およびRedash
    Scheduled Queryによるデータマート生成
    Looker記:
    

    View Slide

22. Looker導入
    出MySQL記のあるとき、海外で密かに噂になっていた
    がやってきた。
    導入の決め手になったのは
    ● LookMLによるSQL自動生成と使用感の良いUI
    ● PDT(Persistent Derived Table)とDatagroup Triggerを使ったデータマート生成
    

    View Slide

23. Looker導入
    LookMLによるSQL自動生成と使用感の良いUI
    Business User自身はSQLを書く必要がない！
    「SQLを書ける人」に依存するという
    使用時のボトルネックを解決
    データチームはLookMLを書きまくる。
    

    View Slide

24. Looker導入
    PDT(Persistent Derived Table)とDatagroup Triggerを使ったデータマート生成
    がLooker Forumで見つけてきたLookerのハック（裏技）
    Lookerによるデータマート生成：データ遅延にも対応可能
    

    View Slide

25. こうして、Looker記（現代）へ
    

    View Slide

26. こうして、Looker記（現代）へ
    創世記から約2年、様々な分析の役に立ってきた？
    Looker記のデータ基盤
    思えば、きっかけはアプリリリースだった。
    https://prtimes.jp/main/html/rd/p/000000068.000024748.html
    

    View Slide

27. こうして、Looker記（現代）へ
    Looker記（現代）のボトルネックの生みの親は
    LookML複雑すぎ問題！
    PDT, Liquid, 多段Explore, 隠しExplore etc…
    LookMLの改変・メンテナンスコストが爆増
    あのときは、イケてるツールに触れてテンション上がってたんですよね・・・
    

    View Slide

28. 「北欧、暮らしの道具店」のデータ基盤の変遷（現在進行系）
    ボトルネック: 　　　 が生み出した複雑過ぎるLookMLたち
    Looker記(現代):
    そして未来へ:
    

    View Slide

29. そして未来へ
    そもそも、LookerはBIツールなのでデータマート生成はある意味目的外利用
    create_processのデータマート生成
    ワークフローアプリケーション
    　　　　　　　or
    ETL SaaS
    餅は餅屋に！！！
    

    View Slide

30. そして未来へ
    データマートを作るコストが高いため、
    LiquidやDerived Tableを多用して複雑化
    データマートを2次加工してExploreを作る
    1 Explore 1データマート が理想
    

    View Slide

31. そこで、出てくるのがETL SaaS
    

    View Slide

32. そこで、出てくるのがETL SaaS
    の複雑さ
    餅は餅屋に移行して、管理しやすくする
    

    View Slide

33. そこで、出てくるのがETL SaaS
    の複雑さ
    餅は餅屋に移行して、管理しやすくする
    それが「北欧、暮らしの道具店」のデータ基盤の
    Next Generation
    今ならLookerと相性の良いと言われる
    dbtがtroccoで使える
    

    View Slide

34. まとめ
    ● データ基盤の変遷は「意思決定のボトルネック」と共にある。
    意思決定に必要な分析のパフォーマンスチューニング！
    ● ボトルネックは常に移動する。
    その時、その時の状況に合わせたデータ基盤の変遷は大事
    ● 最終的に、その時の分析の役に立っていればそれでよし！
    常に、未来のことを考えよう。
    

    View Slide