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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ikeda-masashi

More Decks by ikeda-masashi

Other Decks in Technology

Featured

Transcript