読者です 読者をやめる 読者になる 読者になる

試纏

ためしてまとめる〜色々なトピックやテーマについて試してみたり、まとめてみたりするブログです。

『 データ分析基盤Night #2 』に参加してきた #データ分析基盤Night

f:id:shinyaa31:20170427094634p:plain:w600

前回第1回に引き続き抽選に当たったのでこの日参加してきました。

会場は株式会社FiNC様@有楽町。有楽町駅ビックカメラのすぐ隣、交通の便は超良い場所です。 f:id:shinyaa31:20170426231828j:plain:w600

会場内もとてもオシャレで綺麗なオフィスでした。 f:id:shinyaa31:20170426232025p:plain:w600

挨拶

イベント主催の taise(@_eurk)さんによる挨拶及び今回の開催に際してのアンケート発表がありました。発表内容詳細は以下スライド資料を御覧ください。

基盤として使っているものはAWSが多く、オンプレ環境も意外と多い形に。気になるトピックとしてはアドホック分析や定常分析・レポート業務等に対する処理の使い分け、運用サービスと分析基盤との繋ぎ込みの部分、また発生する『基盤刷新』に対してどう対処していくか、複数プラットフォーム連携(例:AWSGCP等)についても言及がありました。

ウェルネスタイム(軽いストレッチ) by FiNC

そして本編開始前に体操のおにーさん(?)が登場、仕事で凝った体をほぐすべく、参加者皆で柔軟体操を少々。良い感じで体がほぐれました。

f:id:shinyaa31:20170426232937p:plain:w500

FiNCの分析基盤の概要

  • 発表者:yoshimi(@yoshimikeisui)氏 検査技術や専門家・他業界ネットワークを活用し、個人や法人の健康を支援する各種サービスを展開しているFiNC。FiNC社における分析チームのミッション・領域としては『最適な意思決定を最速で導けるための分析基盤をつくる』というところにポイントを置いています。

良い分析基盤とは:以下の様なサイクルを回せるようになっていること。青枠の部分はあくまでも"結果論"となる部分であり、基盤選定やログ設計はまず緑枠の部分を見つめて行くことから始めていく必要がある。

f:id:shinyaa31:20170426234722p:plain:w600

  • FiNCの分析ニーズ:
    • ユーザーの個々のパーソナルデータに合わせたユーザー体験の提供
    • SNS系タイムライン・フィードなどの最適化検証
    • 動画等のメディア利用状況
  • 個々のユーザーデータ x ユーザー体験ログ
  • 既存のアプリ分析ツールでは対応しきれず、自分達で設計したログ収集基盤を作ることにした

ログ収集基盤/俯瞰図:

f:id:shinyaa31:20170426233651p:plain:w600

ログ収集基盤/詳細:

f:id:shinyaa31:20170426233658p:plain:w600

  • ログの"集計"基盤について:
    • データをどういう風に集計しているか?→生ログ系と分析系にスキーマを分けて管理している。

f:id:shinyaa31:20170426233703p:plain:w650

  • 生ログ系スキーマ

    • 分析用スキーマの元データ。
    • データを深追いしたい時に、データアナリストやクエリを叩きたいエンジニアが生ログ系のスキーマを使うために用意。
    • 難易度:ある程度のアプリロジックやSQLの知識がそれなりに必要。
    • 主なデータ種別
      • 生ログをそのまま突っ込んだテーブルがひしめくスキーマ
      • 各サーバーアプリケーションから引っ張ってきたスキーマ
      • 広告ツールなど外部サービスから引っ張ってきたスキーマ
        • 流入経路とか
        • 広告クリテエイティブとか
  • 分析用スキーマ

    • KPIの把握や基本的なデータ分析を賄う。
    • 難易度:EXCELを使える人であればデータをエクスポートして凡その分析が可能。
    • 主なデータ種別
      • ユーザーごと/機能ごとにサマったビュー(テーブル)のスキーマ
        • デモグラ情報xアクティビティ
        • 広告情報xアクティビティ
        • Dailyのユーザー更新データ
      • 集計関数でKPIに近い形でまとめたテーブルたちのスキーマ
        • DAU/RR/ActivationRate
        • 各機能利用率集計
        • 人気コンテンツ
  • ビジュアライゼーション(可視化)

    • 綺麗なUIのダッシュボードも大事だが、まずは見るべき数字が見れている事が重要。
    • redash:Make Your Company Data Driven | Redash
      • シンプルで便利。
      • アドホックなクエリ/単一のKPIウォッチ/簡易なダッシュボード
    • EXCEL
      • redashとの同期機能を活用。
      • レポートとしてまとめたい時/複数のKPIを一気に並べてみたい時に使う
  • 最近気になっていること

freee のデータ分析基盤の全容

f:id:shinyaa31:20170426233728p:plain:w600

発表資料

特徴:他のサービスとどこが違うのか

  • データ基盤のありかたは事業・組織のあり方と相似する(コンウェイの法則より引用)
  • データ基盤を扱う組織やロールが多岐に渡っている
    • Engineer
    • Business
      • Analytics/Finance
      • Marketing
      • Sales
      • Customer Support
  • エンジニア(Engineers)
    • 会計/人事労務など、サービス毎のアプリケーション
      • Service DB/Redshift
      • ElasticSearch/Kibana(開発やデバッグ用途)
      • EMR/Spark(取引関係ネットワーク・プラットフォーム)
      • FireBase(モバイル)
      • Kissmetricsなど(グロースハック)
      • JIRA
    • スモールビジネスラボ
      • 初期仮説検証・モデル開発・プロダクト開発
    • 金融機関との連携
    • 課金基盤・セキュリティなど
    • SRE・ビジネス基盤
  • Bizの組織とデータ

    • 分析・財務(Analytics/Finance)
      • Service DB/Redshift:事業計画立案に必要なKPI・ユーザー定着のための仮設検証
    • カスタマーサポート(Customer Support)
      • Zendeskチケット:サポートの生産性向上、顧客満足度向上のための仮説検証
    • オンラインマーケティング(Online Marketing)
    • 販売(Sales)
      • Salesforce:セールス生産性向上・セールスKPIの検証
  • freeeの分析基盤の特徴 f:id:shinyaa31:20170427030007p:plain:w600

  • freeeが利用しているクラウドサービス(の一部)

f:id:shinyaa31:20170427030134p:plain:w600

構成:アーキテクチャ

業務分野によって構成はそれぞれ異なる。業務別のサービス構成図は以下。

マーケティング

f:id:shinyaa31:20170426233737p:plain:w600

販売・サポート

f:id:shinyaa31:20170426233745p:plain:w600

エンジニア

f:id:shinyaa31:20170426233753p:plain:w600

ダッシュボード

  • redashを全社で使っている。
  • 元々内製ダッシュボードを利用していたが、redashにしてデータ利用が加速。
  • 一方で問題も。
    • ダッシュボード多すぎ問題
    • “糞クエリ"をフォークして使う問題→"redash警察"による取締状況に

バッチ処理

辛み

  • 事業展開のスピード感
  • Salesforce/marketoとの連携
    • Rate Limit等のAPI制限、bulk api取得時のIOPS
  • Redshiftのパフォーマンスチューニング
    • Redshift Spectrum、早く東京に来て欲しい

展望・チャレンジ

  • スモールビジネスのバックオフィス業務を効率化
  • ビジネスプラットフォームの構築

まとめ

f:id:shinyaa31:20170427031212p:plain:w600

mercariのデータ分析基盤

f:id:shinyaa31:20170426233812p:plain:w600

メルカリデータ基盤の紹介

  • データ分析に関する役割分担
    • BIアナリスト(データサイエンティスト)
      • 分析ログデータ構造設計
      • データ分析に基づいた企画・提案、KPI設計とレポーティング・可視化
    • ソフトウェアエンジニア(バックエンドシステム)
      • データ分析基盤の開発・運用・サポート
    • ソフトウェアエンジニア(機械学習/NLP/AI)
      • (主に)機械学習をはじめとする専門技術とサービスの橋渡し。研究開発も兼ねる

サーバーログ分析インフラ

f:id:shinyaa31:20170426233821p:plain:w500

  • 各サーバのログをfluentdで収集・転送
  • 用途に応じて各サービスやミドルウェアに投入
    • BigQuery:分析用ログ格納
    • Norikra:SQLによるストリーミング処理
    • その他Kibana, KPI Reporting等
  • Google BigQuery
    • バッチでログファイルをインポート
      • over 1TB/Day
    • ログファイル自体はGCS, S3にバックアップ
    • データ分析の起点
    • 定額プランを利用
  • ダッシュボード
  • Gogole Spread Sheet/Google App Script
  • Norikra

    • 数分のウインドウでSQLによる集計処理
  • ログ分析による可視化とアラート

f:id:shinyaa31:20170426233829p:plain:w500

  • SQLによるストリーム処理

f:id:shinyaa31:20170427032700p:plain:w500

イベントベースログ分析インフラ

f:id:shinyaa31:20170427033201p:plain:w500

  • 特徴

f:id:shinyaa31:20170427033221p:plain:w500

機械学習分析インフラ

  • 技術スタック:Python, Django, scikit-learn, TensorFlow
  • BigQuery上のデータを元にデモグラフィック推定、カテゴリ推定、ラベリング
  • 色々な箇所から利用出来るようにAPIとして提供
  • 去年暮れ位にチームが出来、本格的に稼働中

まとめ

f:id:shinyaa31:20170427033555p:plain:w600

さいごに

以上、データ分析基盤Night #2に関するレポートでした。この後今回の登壇者が一同に集まり、前もって募集していた質問を使ったQ&Aの時間も設けられていました。こうしてみると業務要件に対して実に様々なサービスや環境を連携させて処理を実現しているのだなぁという思いを強く感じます。そしてそれらのサービスをいかに効率良くスムーズに連携出来るのか…という部分もとても重要なポイントとなる事が分かりますね。1セッションあたり20分と時間としては比較的短く、もう少し踏み込んだ内容について聞いてみたい…!と思ったところで時間切れとなってしまうので、次回以降可能であればより長く、深掘りした形でお話が聞けると嬉しいかな、と思いました。

登壇者の皆様、イベント関係者の皆様、ありがとうございました!