「eureka Meetup #08 -Pairsのビッグデータ基盤の裏側」 に参加してきました

eureka Meetup #08 -Pairsのビッグデータ基盤の裏側-eure.connpass.com

エウレカさんのイベントに参加してきました。

前職でデータマーケティング・BIのエンジニアさんと関わることもあったので興味もあったのですが、とても業務的に、あるいはビジネス的に、技術的に話を聞ける機会でした。
すごく熱量の高い内容で面白かったです。

発表者の皆様、イベントの運営者の皆様、ありがとうございました。

以下メモした内容をまとめています。
（お酒が入っていたこともあり、誤りなどがあればすみません）

Tableauを導入した話

鈴木宏典さん | eureka,Inc.

Pairs
マッチングアプリ

今日のお話はPairsというプロダクトのデータについて

恋愛相手に求めている条件
理想の相手を探せるようにプロフィールを充実させる

興味関心といった情報を利用し分析が可能
（個人の特定はできないようになっている）

ユーザーの行動は
登録 -> 検索 ->いいね -> マッチング
といった流れになっている

各アクションのログに大量にある
ユーザーの行動ログを分析し常にサービスを改善

BIチームに課せられた、「データ可視化」との戰い

データ

• 行動ログ
• 課金
• デバイス
• プロフィール
• アンケート
• 広告

PMさん
「こんなすばらしいデータがたくさんあるんだ。 プロダクトに生かそう」

BIチーム
SQLを書く -> 見たい数字が見せられるようにダッシュボードを使う

BigQuery 行動ログ
MySQL ユーザー情報などのマスターデータ

Redashの利用

• クエリの保管
• 実行
• ビジュアライズ

デバイス別　いいねの送信数 DAUとか売り上げとか基本

ビジュアライズめんどくさい
ダッシュボードじゃ間に合わない -> 「SQL書いて」

もう少し深掘りできるダッシュボードを作りたい
グルーピング数が大きいローデータを集める

Redash+GAS＋Google Spreadsheet
SAMIF関数

シートの内容

• 施策の効果測定
• CRM施策の過去結果

ビジュアライズも綺麗
再利用しやすい

だが、
データ更新が不安定　Redashでつまる
可視化めんどくさい
データ量に制限 ,１万５千行あたりから辛い

結局SQL書いて欲しいという依頼が減らない

複雑度 x 依頼数　増大
クエリ作るということが業務になっている部隊に

本来はBIはデータを価値に変えてプロダクトに反映させる部隊

Tableau導入

BigQueryのViewTable（BigQueryから多少加工したもの）

イテレーションの考え方
ダッシュボードを増やしていく方向から、データソースを改善・拡充する方向に

Tableau導入後の世界

「これください」みたいなのを待たない
ビジュアライズなどはマーケティング側に任せられる部分は任せる

BIは高度な析に集中

めっちゃ大規模なデータも余裕
認証とかも楽チン

ただ、ライセンス料が高い

オンラインデーティングのデータは超面白い
本当に見たいデータが大量にある

こういったデータの分析についての本も発売されている

changelogと戦う

山口 将央さん | 株式会社トレタ

クエリの依頼はトレタでもあるある
今日午後から出かけるので　こういうデータ用意して

トレタの事業紹介

iPADアプリ

飲食店　予約管理ツール
繁盛店のオーナーさんの意見を反映
飲食店のためになるツールを作っている

予約のフォーム
POSコネクト

グルメ予約サイトとの連携

電話：CTI きたことがある顧客の情報

３方よし
お店　顧客　エンジニア

トレタデータサイエンス研究所

現状のデータインフラについて

Rails, MySQL
GCPにレプリケーションBigQuery embulk Digdag

Digdag serverをGithubで管理
トップのtaskだけがサーバー
プルリクベースでtaskがくる

足りないデータでChangelogの話をしていた
アプリケーション側としてはDBが肥大化するので、捨てているものもあった

本当に重要なものについてはとっていた

Reservationのジョブからsidekiq

データ側の要望で本番を重くしたくない
レプリケーションをかけている

Change log

Binlog
MySQLレプリケーションのログ

parseしてBQに突っ込めばいいじゃん
dockerでmysqlのmaster slaveを作ってコンフィグ周りを確認

binlog_format = ROW
Log-slave-updates

binlog-parserのレポジトリをfalk

「あとは取り込むだけ、、、」ではない

個人情報バンバン入っている
データを綺麗に
パースしたデータ
１日４G, 改行ありのjson

Sparkのコンフィグで何度も苦しめられた経験

CloudDataflow

Apache Beamで書いたデータパイプラインの実行環境(runserver)で
runnerをDirectRunnerにすればローカルでも可能

ApacheBeamのコードをどこで作るのをどこでやるか
Datalabでやろうとしている

ローカルで確認して、DataflowRunnerに変換

あとはDigdagに突っ込む

個人情報の削除、mask

サーバーサイドの工数を使うことなくChangelogが取れるようになった
Dataflow便利　処理速度が遅かったら勝手にautoscalingしている
ApacheBeamのデバッグが結構めんどくさい
BQに取り込んだフォーマットが今のままだと使いづらい

今後のやっていくこととして

Firebase

トレタとして欲しい人はどんな人？

最低ラインとしてSQLかける人 機械学習にゴリゴリよっていたというよりはビジネスによっている人が欲しい データサイエンティストが欲しい

パネルディスカッション

• 鉄本 環さん | eureka,Inc. Head of BI Team. 

• 山口 将央さん | 株式会社トレタ


• 前田周輝さん| 株式会社リクルートライフスタイル

• モデレータ：Eureka CTO 金子さん

• 鉄本さん
  サーバサイド php -> go
  データの移行を全て担当したところからのBIチーム立ち上げ

• 山口さん
  データ活用したサービス開発
  （２回目のセッションの内容）

• 前田さん
  足回り系からデータインサイト
  Tableauユーザ会の代表

業務について

「BIチームとして一番力を入れているプロジェクト」

• 鉄本さん
  早く正しいデータをいかに出せるか
  データの依頼　煩雑　質がともなわない
  窓口が増えてきた
  リードタイムを減らす

• 山口さん
  データを使ったプロダクトを作る部分

• 前田さん
  データを使って利益を出す
  PMO データそのもの
  アナリストも統計より　機械学習よりの人
  データは貴重

扱いに困っているツールとその理由は

「好きでもあり困っているものなど」

• 前田さん

Redshift
スピードが出ない

Adobe analytics
ツールが進化しているが使いこなすことができず、やれる分析の幅が広がっていない

• 鉄本さん

Redash
可愛いけど、負荷に耐えられなくなる　メンテナンスに時間が割かれる

導入した当時より二次関数的に増えてくる　負荷に耐えられない

• 山口さん

Metabase
Clousureで書かれたツール
これがあればTableauなくてもいいじゃん 導入した時点で完成度がまだ低かった
一万行のCSVでエラー

データについて

「 データの闇
データを使ってこんな価値を生み出した」

• 鉄本さん

ゼロイチで管理した管理のカラムが「on, off」のstringで入っていたことが

不正検知
BIと機械学習エンジニアで連携して作っている

課題からブレークダウン
データを使ってボトムアップの提案　比重を強く

• 前田さん

闇だらけ

１０年以上のデータ
カラムが途中でできた
データの欠損　推定で補完
営業も強い　顧客行動　企業名でユニーク　営業担当者名前が入ってユニークになっていない
Distinctにするクエリの発行

中間テーブル　マッピングテーブル
Datamart ある程度集約されて、制約が取れたもの
Datamart2

世代管理　ガバナンスがたいへん

よかったこと
レコメンデーション　ABテストを金額換算
BI事業　武器となる顧客向けのレポートをTableau 渾身のビジュアライズ
６億　顧客の離脱を防止

• 山口さん

電話番号をハッシュ化してBQ
グローバル対応　日本の電話番号
電話番号 生きている / 生きていない
日本語が入っている　なんで?
店舗のオペレーション上仕方なくというところがある

営業とのやりとりが多い
営業と話しているとこういうデータがほしいというのが雑談ベースで出てくる
営業さんと普通にやるとデータ受け渡しが時間がかかる
今のところ山口さんだけがそういう感じで動いている
営業さんが他の店舗のデータを欲しがるなどリスクもある

組織としてはここから事業が作られていく
予約台帳だけじゃなくなる
データを活かしていこう
ここから新しいプロダクト
チームも

今後チームをどのようにしていきたいか

• 山口さん

前の話題の最後の部分
情報リテラシーを担保する
B2Bの部分をせめるのは引き続き行う
B2Cをやっても良い

（金子さん）やっぱりデータに理解がある会社は良い

• 前田さん

データチームの位置付け
組織に存在価値を証明するということを今までのフェーズでやってきた
インサイトの価値をどれだけ出せるか
GPUを使ってみたいんだ　強化学習を使ってみた
知的欲求を満たす
あれやりたい、あれやったほうがいいのではという思いつきが文化として醸成されてきている
前回失敗したことが今は変わっているかもしれない
即ABテストとして実施する
時系列大事

（金子さん）エウレカでも昔と違う　ユーザーも全然違う　今過去の施策をやったらどうなるか常に考え続ける必要あり

• 前田さん

データプロダクト
予測モデルそのもの
直接的な価値を生む
インサイトについては書籍化レベル

エンジニアのデータストーリーテリングのスキルを上げるべき

• 鉄本さん

データに関わることすべて

マーケティング周りで重視している指標を対応したらどんどんプロダクトの成果が出てきた
データドリブンの風土ができてきた

ユーザーインタビューなどにも力を入れている
でもそこにも統計的な知識があるとなお良い

データがあるからデータを分析すれば何かしらできるんじゃないか、と言う感じでユーザのことよりもデータ第一にしていた感があった時期があった
しかし、一週間かかったことが30分インタビューしたら分かった

データを出せるところ
定量・定性をどちらも大事にする
ドメインナレッジを持っていてデータを出せるのが強い
そこから機械学習　または　もっとビジネスよりな提案を出せる
違う分野で力を発揮し始めた
新しいキャリアを考えるのもいいかもしれない
チームの可能性、拡張性を高める
自分が先導してチームを作るくらいのメンバーになって欲しい

（金子さん）Pairsについての印象も ネガティブからポジティブに変わってきている
３ヶ月まえの頭のままだと時代に遅れる　常に自分をアップデートしていく必要がある

おまけ　オフィス見学

オフィスを案内してもらいました。
日中はバリスタさんがコーヒーを淹れてくれるそう。
羨ましすぎます。

透明性を大事にする会社なので、会議室の壁も基本は透明とのこと。
ipadでの会議室の予約システムが便利そうです。

ため息が出るほど素晴らしいオフィスでした。