【一休 × JapanTaxi】サービスを支えるデータ分析基盤
- 2017/08/17 19:30
- 株式会社一休(本社オフィス)
一休.com におけるデータ分析基盤とCRM運用(仮)
株式会社一休 宿泊事業本部システム開発部長 エンジニアリングマネージャー 笹島祐介
- もともと一部の人がやっていたものを全社向けに再構築したんです。
- 移行の背景
- 本番環境と社内の分析環境は分断されていたんですよね。
- なので、一旦一日1回しかETLできていないし、ディスク容量が足りなくなってきたんです。
- そうすると日々のマーケティング施策がとまってしまうのでなんとかしようと。なりました。
- 再構築前のデータ分析基盤
- 様々なデータソース(基幹DBとGoogleAnalyticsPremium)
- GAPremiumだと、自動的にGoogleBigQueryに入るんです。
- DHWはSQLServer
- DWHに対してTableauやredashを使っています。
- どうしたかというと
- どうやって移行したか
- それらを使ってなにをやっているの?
- 今後、こんなことができたらいいな。
- なぜかDynamoDBがいるんだよね。性能は優れている。リアルタイムに分析して施策を売ってみたい。
- 例えば、ユーザが旅館を検索して、予約動線までいて今回はやめようとしたユーザに対して、その場で即時再提案する。とか。
- ユーザの行動ログを可能な限り早く収集する。とか。
- GA+Biqqueryの構成では解決できない問題があった。
- データ蓄積のタイムラグ(最短でも8時間)
- なので、自分たちでコントロールできる基盤が必要ということ。なので、DynamonDBを作った。
- まとめ
- うーん。とくになにもない。
- ちゃんと現行業務やデータ量等、データ分析基盤に関わる要素をきちんと分析してから進めるべきだと再認識しました。
- まぁ普通そうだよね。
- 質疑応答
タクシー会社を支えるデータ収集技術 〜AWS Kinesis Stream/IoT の導入事例〜
JapanTaxi株式会社 システムデザイン事業部 部長 長谷川 直
- 動態データの従来までの使われ方
- 動態データとは(もともとは分析用途ではなかった)
- 車の経度緯度ステータス
- でもね、この動態データが需要予測とかに利用できそうだ。ということで。
- Bigquery<-embulk<-動態データ
- いままでは、やりたいひとだけがやっていた。
- 社内のリクエストを収集
- リアルタイムに動態データを取得したい。
- 過去の動態データを取得したい。
- 動態データ取得方法が共通化され、簡単にアクセスできる
- で、二、三日で構築してみた。
- Knestis Stream -> Consumer(Lambda)-> S3 -> Athena -> プロダクトB
- 結果失敗してしまった。
- シャードの見積もりがあまったためにストレームに対する
- なので、ELB -> Collector Svr -> Kinessi Streamにしてみたら、なんとかなった。
- この基盤を利用して、需要予測や奇跡の表示ができている。
- タクシーを利用してどの道をとうったか、とかがわかるようになっている。
- 動態データとは(もともとは分析用途ではなかった)
- AWS Iotの活用事例について
- リモコンでタクシーを呼ぶデバイスを開発してみた。
LT:田中康一さま 「3分で作るストリーム処理基盤 ~Kafka + Flink on Docker編~」
ウェブニウム株式会社CTO
- 今回作るもの
- リアルタイムなストリーム処理基板を作る
- INPUT/OUTPUTを受け取っているもの
LT:motobrewさま 「クラシルを支える分析基盤 を支える話」
- kurashiruというアプリを作っている。
- margaret hamilton/NASAのソフトウエアエンジニア(SREサイトリライアビリティエンジニアリング)
- SRE??
- プログラミングを教えてくれるところはあるけど、SREのスキルをアップさせるにはどうすればいいの?
- 経験者にはより経験があつまるけど、未経験者にはないよね。
- なのでSRE育成プログラムを作った。
- ミッション1
- 本番環境と同等のログ収集基盤を構築してみる。
- ミッション2
- 課題
- ミッションの作成
- 網羅異性
- 実務で通用するか?
LT:Shogo_Suzukiさま 「SpinAppを支えるデータ収集基盤」
- DATAを収集する部分
- Adjust
- AppsFlyer
- Firebase
- もともとEC2とRedshfit中心だったか、しんどくなった。
- ELB->EC2->SQS->Instance->DyamonDB->redshiftだった。
- redshfitがいっぱいデータがたまってきて集計が間に合わなくなってきた。
- スパイクに耐えられない。
- なので、GCPで全部作り直した。
- GAT+GOで高速オートスケール
- 安くてハイパフォーマンスなBigQuery
- 全部GCPの方が都合が良い。
- PUB/SUBも使いたかったな。
- GAE->TaskQueue->GAE->GCS->DataFlow->BigQuery
- 嬉しいこと。
- まえのAWSからコストが1/8となった。比較があるよ。
- BigQueryが早くて安くてうれしい
- たいへんなこと
- フルマネージドサービスが結構エラーを返す。
- AWSに比べて障害が多い気がする。
LT:idobataさま 「b→dashのデータ処理基盤」
株式会社フロムスクラッチ CTO 次世代マーケティングプラットフォームb->dash
- システム刷新の理由
- システムが拡大
- アプリケーションが像が
- データ容量が増加
- ユーザ数(社数)が増加
- 個社ごとの要望に対応する
- システムが拡大
- 構成
- DHWにRedshiftを作っている。
- 課題X
- データクレンジングができない
- ・・
- 課題X
- 全体構成
- redshiftでパワー対応していたものをマイクロサービス化してみた。
- dataflowはdataspiderを使っている。
- DHWにRedshiftを作っている。
- 今後やりたいこと
- まとめ
- データを活用したマーケティングは当たり前の時代になっていくr.
- b->dashはは共通部分と個別部分を切り分けている。
- 共通部分nお保守性が向上した
- 顧客ごとに個別に拡張させることが可能なので、コスト効率を向上させている。