複数データソースにまたがった分析環境の改善計画 / improvement-plan-for-analytical-environment

【09/15 イベント登壇資料】
Nowcast主催の「データ分析環境に関する勉強会」にestieから黒崎（ @kuro_m88 ）が登壇いたします。

redashやAmazon Athena、Amazon RDSなど複数データソースにまたがった分析環境の改善計画についてお話ししました。

▼ 会社について
会社サイト：https://www.estie.jp/corp/
エンジニア採用サイト：https://jobs.estie.jp/

Transcript

1. 複数データソースにまたがった分析環境の 改善計画 黒崎優太 / @kuro_m88
2. 黒崎 優太 • バックエンド系のエンジニア ◦ インフラの改善 ◦ データ基盤の改善 • 8月から副業でお手伝いしはじめました @kuro_m88
3. はなすこと • 株式会社estieについて • スタートアップのデータ基盤 • スタートアップのつらみ • 改善への道のり
4. 株式会社estieについて
5. 5 estie(エスティ)は オフィス不動産を デジタル化する会社です
7. スタートアップのデータ基盤
8. データ基盤、ほしいですか？ • 󰢧 ほしいに決まってる！ • 󰢨 かっこいいデータ基盤がほしい！ ◦ ETLってやつがやりたい！ • 󰢧「データの民主化」がやりたい！ ◦ みんなが平等にデータにアクセスできる世界！
9. データ基盤、ほしいですか？ • 🤔 データ、ありますか？ ◦ ないものは集めようがない • 🤯 意味のあるログですか？ ◦ なんとなく出力したログ、役に立たないことが多い • 🥺 基盤づくりから始めるのは危険かも？ ◦ 分析したいユースケースや追いたいKPIの設計からはじめよう
10. 身も蓋もない話 • まずはGoogle Analytics入れましょう ◦ webやネイティブアプリの場合 • カスタムイベントの計測も充実しています ◦ アクション, カテゴリ, ラベル, 値などを組み合わせてイベントの記録が可能 • 生ログも分析可能 ◦ GA4からBigQueryで分析できちゃいます！ • 無料ではじめられます💸
11. スタートアップ(立ち上げ初期)のデータ基盤 • クライアントサイドで取れないがものある ◦ サーバサイドでしか取れないもの、秘匿性の高いものなど • ログ自体の信頼性を担保したい ◦ アクセス解析用途ではなく証跡用途など • 正確なレポーティングを事業として提供する ◦ 高度な分析を事業価値としていきたい • このあたりの需要が出てきたらデータ基盤の設計に乗り出しましょう • 最初から焦らなくても大丈夫です！要件を整理するのが先！
12. 余談: 法的側面 • 󰢨アクセスログって保存しないといけないって聞きました！ ◦ 必ずしも義務付けられているわけではないかも…？ • 企業における情報システムのログ管理に関する実態調査 - IPA より ◦ https://www.ipa.go.jp/files/000052999.pdf • ログの開示を求められる確率は事業規模が大きくなるにつれて大きくなる 可能性があるので、どこかのタイミングで考慮する必要はあるかも
13. スタートアップのつらみ
14. スタートアップのつらみ • 採用が軌道にのるとエンジニアが増えてくる(嬉しい) • 開発スピードもどんどん上がっていく(嬉しい) • ひとまず作ったものがいつのまにかみんな使っている(嬉しい) ◦ ログも散らかり始める(あれ…) ◦ あとからしくみを変えづらい(うっ…) • 分析をミッションに入社したもののなんもわからん(つらい…) • 正直そんなにお金がかけられない(だいたいそう…)
15. ほしいデータ基盤像 • スモールスタートしたい ◦ コストのことを考えても必須 • シンプルな構成 ◦ あとから入った人でもすぐわかるように • そこそこのパフォーマンス ◦ 爆速である必要もない、安定してくれる方が嬉しい • メンテしたくない ◦ そこに人的リソースを割きたくない
16. • 環境 ◦ 創業期に導入したself hosting redash（EC2） ◦ RDS, Athenaをdatasourceとして利用 estieの現状 RDS Athena S3 Redash (EC2)
17. estieの現状 • 主な分析対象 ◦ RDS内のestieが提供するオフィス不動産データ (ビル/募集/入居テナント等) ◦ RDS内のユーザがDB内に作成したデータ (ウォッチする物件のリスト等) ◦ S3に出力されたサーバのアクセスログ • 体制 ◦ ビジネス/エンジニア問わず全員がSQLを書く ◦ データアナリストが依頼されて分析するような分業はしてない ◦ 不動産デベロッパー出身者も週1回の勉強会でクエリを書けるように
18. つらいポイント1: 複数データソース • RDSにあるユーザの属性とS3のログデータを組み合わせて利用状況分析 ◦ RDSとS3のJOINをしたい… • 現状のJOIN方法 ◦ RDSからselectした結果とS3からselectした結果をredashに保存 ◦ redashのquery results機能を使ってJOIN(内部実装はsqlite🔥) SELECT month, org_id, function, sum(action_count) FROM query_1533 as function_analysis LEFT JOIN query_1489 as active_users ON active_users.user_id=function_analysis.user_id AND active_users.org_id={{ org_id }} GROUP BY month, org_id, function_analysis.function ORDER BY month
19. つらいポイント1: 複数データソース • RDSにあるユーザの属性とS3のログデータを組み合わせて利用状況分析 ◦ RDSとS3のJOINをしたい… • 現状のJOIN方法 ◦ RDSからselectした結果とS3からselectした結果をredashに保存 ◦ redashのquery results機能を使ってJOIN(内部実装はSQLite🔥) SELECT month, org_id, function, sum(action_count) FROM query_1533 as function_analysis LEFT JOIN query_1489 as active_users ON active_users.user_id=function_analysis.user_id AND active_users.org_id={{ org_id }} GROUP BY month, org_id, function_analysis.function ORDER BY month 🤔 🤔
20. つらいポイント2: 重くなる分析クエリ • query resultsはquery parameterが利用できない ◦ 参照する日付やuser_idを絞れず、スキャン量が増加 • ダッシュボードを表示するのに1分程度かかったり🔥 ◦ ログの量が増えるともっと🔥
21. つらいポイント3: クエリの見通しが悪い • query resultsわかりづらい ◦ 定義がわからない • 似たようなクエリが何度も書かれてる ◦ ログがJSONでスキーマがないのでparse処理が散在 • SQL初心者はつらい ◦ JSONのparseから入門🔥
22. 改善への道のり
23. 改善への道のり • 極力シンプルに、癖のない構成をまず作りたい • 改善案として提案中のアイデアを紹介します
24. 全体像 • 使う技術は変わらない ◦ データソースとアクセス方法を改良する RDS Athena S3 Redash (EC2) S3 Athena
25. データソース • S3にある生ログは使いづらい ◦ 分析用途で直接クエリしないようにしたい • 分析用のデータのスキーマを定義する ◦ 毎度JSONのパースをしなくていいようにする ◦ ログの構造変更が即座に分析用データに現れないようにする
26. フォーマット変換 • AWS Glueを使いたいところだが、そこまでお金を掛けずに変換可能 • Athenaでselect insertができます…！ ◦ S3からselectしてS3にinsert可能 ◦ insert時にテーブルの定義をParquet形式にしておけば フォーマット変換が可能 • 参考 ◦ Amazon Athena がついにINSERT INTOをサポートしたので実際に試してみ ました！ ▪ https://dev.classmethod.jp/articles/20190920-amazon-athena-insert-i nto-support/
27. Parquetとは • 列指向データフォーマット ◦ https://parquet.apache.org/documentation/latest/ • 必要なカラムのみスキャンができる • ある程度のデータの塊ごとに統計情報が ◦ さらにスキャン範囲を絞れる
28. 複数データソースのJOIN • AthenaにはFederated Queryという機能が！ ◦ ドキュメントは日本語訳がちょっと変なので英語版を読みましょう ▪ https://docs.aws.amazon.com/athena/latest/ug/connect-to-a-data-so urce.html ◦ AthenaがAuroraなどの外部データソースとのJOINをしてくれる
29. Redashはどうなるのか • SQLiteを使ったJOINは発生しなくなるため、動作は圧倒的に軽くなる予定 • スキーマのあるデータをクエリできるようになる • Parquet化によるスキャン量減少も見込める • これで分析がはかどるはず…！
30. 再掲 • 使う技術は変わらない ◦ データソースとアクセス方法を改良する RDS Athena S3 Redash (EC2) S3 Athena
31. さいごに • 移行までしきって改善の幅をドヤりたかったのですが、 間に合いませんでした󰢛 • まずはベースになるデータ基盤をリニューアルするつもりなので、 今後ともご期待ください