DELISH KITCHENの分析基盤について

こんにちは。データ分析担当エンジニアの島田（@smdmts）です。

今回は弊社の事業である「DELISH KITCHEN」で行われている分析基盤について紹介したいと思います。

分析基盤が目指す方向性

みなさんは「信頼できるの単一の情報源（Single source of truth(SSOT))」という言葉をご存じでしょうか？「信頼できる単一の情報源」とはアプリで発生したデータを一元管理することで、迅速にデータ分析を可能として意思決定に活かすための条件を指します。　　
弊社では「信頼できる単一の情報源」を前提として、エンジニア以外の職責でも意思決定の材料となるデータを自由に参照できるよう、以下の方針を満たす分析基盤の構築を目指すこととしました。

職責を問わず可視化されたデータを意思決定の材料とできること
全てデータを結合可能で様々な軸から洞察可能であること
非エンジニアでもSQLを発行して分析出来る基盤であること（簡単なSQLで分析可能であること）

Treasure Data の導入

当初の「DELISH KITCHEN」のアプリ分析は、Athena/BigQueryを利用していたのですが、以下のような課題がありました。

日々増えていくレコード量に伴う実行時間の長時間化、およびクエリ課金の増大していた
- Athena／BigQueryで生ログをフルスキャンしておりジョブスケジューラが存在しませんでした
BigQueryはSQL方言が煩雑であることから、エンジニア以外は分析用SQLが事実上書けなかった
- StandardSQLを利用してもネスト構造を含むRECORD型の分解が難しいと判断しました

そこで上記の課題を解決するべく、以下のPoC（概念実証）を元にTreasure Dataの採用に至りました。

SQL発行回数に上限のないリソース課金であること
ジョブスケジューラやデータ取り込みなどがフルマネージドで完結する仕組みが整備されていること
外部（AWSやGCS、SaaSなど）へのデータ連係を行える仕組みが整備されていること
[再掲] 非エンジニアでもSQLを発行して分析出来る基盤であること（簡単なSQLで分析可能であること）

なおTreasure Dataを最大限活用する一方で、それだけでは満たせない速報値取得や開発者向けアドホッククエリ実行環境などの用途で、BigQueryとRedshiftを併用しています。

データ連係(ETL) と可視化について

分析基盤を構築するに当たり、データ連係（ETL）ツールとしてfluentd（ログ転送）・embulk（バルクローダ）・digdag（ジョブスケジューラ）、可視化ツールとしてre:dash を利用しています。
ここでは「DELISH KITCHEN」の中でも重要なKPIである、動画視聴数をどのように集計しているか紹介させていただきます。

アプリ（iOS/Android)が、イベントログである動画視聴結果をFirebase Analytics（BigQuery）に書き出す
digdagが朝バッチにて、EMRにてembulkを利用してBigQueryからTreasure Dataに転送する (Firebase取り込み用のembulkプラグインは、OSSで公開しています)
digdagがTreasure Data上でSQLを発行して前日分のレシピ毎の視聴数を中間テーブルに書き出す
re:dashにてレシピ毎の動画視聴数の確定値として図で参照する

上記を実現する上で大切だと考えているものはドメイン駆動設計における「蒸留」の概念であり、生ログから必要なデータを中間テーブルに書き出す際のデータ設計となります。蒸留されたデータは効率よく検索可能となるため、短時間でSQLの結果が応答するようになり、よりユーザストレスのない分析基盤の提供が可能となります。