データ収集の基本と「JapanTaxi」アプリにおける実践例

Mobility Technologies Co., Ltd.
Data Engineering Study #2
データ収集の基本と
「JapanTaxi」アプリにおける実践例
株式会社 Mobility Technologies
渡部徹太郎
2020/8/19

自己紹介
2
ID ：fetaro
名前：渡部徹太郎
学生：東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)
職歴：
* 野村総合研究所(NRI)
- オンライントレードシステム基盤
- オープンソース技術部隊
* リクルートテクノロジーズ
- ビッグデータ分析基盤
* MobilityTechnologies
- データエンジニア
エディタ：emacs派→ InteliJ派
日本AWSユーザ会(JAWS)
ビッグデータ支部長
やってました
著書

confidential
3
データソースの種類と取得方法
Agenda
「JapanTaxi」アプリにおける実践例
データ収集における注意点
データ分析システムの全体とデータ収集の役割
70%
10%
15%
5%

データ分析システムの全体と
データ収集の役割01
4

分析システム全体像
5
分析システム事業システム
データ
レイクデータ
ウェア
ハウス
アドホック
分析
データ
マート
データ
可視化
一次
加工マート
生成
データ
収集
データ
生成
メタデータ管理
データ
アプリ
ケーション
利
益
向
上
意
思
決
定
収集生成蓄積活用
データ
ソース
構造化
データ
非構造化
データ
構造化
データ

分析システムにおけるデータ収集
6
データ
レイクデータ
ウェア
ハウス
アドホック
分析
データ
マート
データ
可視化
一次
加工マート
生成
データ
収集
データ
生成
データ
アプリ
ケーション
利
益
向
上
意
思
決
定
収集生成蓄積活用
データ
ソース
構造化
データ
非構造化
データ
構造化
データ
データ収集で考える範囲

データソースの種類と
取得方法02
7

データソースの種類と収集方法
8
頻度データソース Webサイトのデータ例収集方式
1/week 〜
1/month
スプレッドシートコードマスタ手動アップロード
10/min〜
1/day
オブジェクトスト
レージ
社内の他システムのデータファイル収集
Web画面 APIを公開していないWebサイ
ト
スクレイピング
1/min〜
1/h
API クラウドCRMのAPI
気象オープンデータ
API呼び出し
10/sec 〜
1/day
DB ユーザマスタ
商品マスタ
購入トランザクション
DBから
の収集
SQL方式
エクスポート方式
DBダンプ方式
更新ログ方式
更新ログ方式 CDC
100/sec 〜
10000/sec
ログファイル Web画面遷移、検索、購入エージェントを利用した収集
端末イベント Web画面遷移、クリック、ス
クロール、マウス軌跡。
分散キューを利用した収集
→割愛
→割愛

ファイル収集 (1/2)
9
データ
配置処理
データ
キュー
2.配置完了通
知
1.配置
3.通知受領
4.データ収集
オブジェクトストレージ
収集処理収集処理収集処理
5.蓄積
データレイク
or
データ
ウェエアハウス

ファイルフォーマットの種類
ファイル収集 (2/2)
10
フォーマット
名
説明利用ケース
CSV, TSV ・構造化データを表現できる
・テキストフォーマット
構造化データで可読性重視の場合
JSON ・半構造化データを表現できる
・テキストフォーマット
・キー名もデータに含まれるため、データ量が多くなりが
ち
半構造化データで可読性重視の場合
AVRO ・型に厳格なJSONみたいなもの
・バイナリデータ
・事前に型定義を受取システム間で共有し、バイナリデー
タを型定義によってシリアライズ・デシリアライズする
半構造化データで型に厳格にしたい場合。
JSONよりもデータ量を小さくしたい場合。
Parquet, OCR ・カラムナフォーマット(※)
・バイナリデータ
・列指向圧縮によりデータ量の削減ができる
・対応するデータウェアハウスで扱えば、データの読み飛
ばしによるIOの削減の恩恵を受けられる
データ容量の削減優先や、データウェア
ハウスにロードさせる事が前提の場合
カラムナフォーマットについては https://engineer.retty.me/entry/columnar-storage-format

API呼び出し
11
収集処理 3. 格納
API
分析システム
1. HTTP GET
(トークン付き)
2. JSON
データレイク
or
データ
 注意点
 多くの場合APIコール回数制限がある

 メリット
 実装が簡単
 取得対象のデータを SQLで絞り込みや加工ができる
 デメリット
 事業システムDBに高い負荷を与える
 事業システムのデータベースキャッシュは、オンラインのワークロードに最適化されているが、データ収集のSELECT文が
キャッシュを流してしまう。
 長時間トランザクションになりがち
 リードレプリカから収集すれば軽減できる
DBからの収集 SQL方式（1/2）
12
1.SELECT文
収集処理
2.カーソル返却
4.データ
3.フェッチ
5.一時格納
一時
ファイル
6. 格納
３〜６を繰り返す
事業システムDB
テーブル
データ

 巨大なテーブルからの収集を並列化する場合
DBからの収集 SQL方式（2/2）
13
分析システム
収集ワーカー
事業システム
収集ワーカー
収集ワーカー
テーブル
WHERE id <= 10000
WHERE 10001 <= id AND id < 20000
WHERE 20001 <= id
データ
~ 10000
データ
10001~20000
データ
20001~
 ポイント
 テーブルを分割するキーの設計が必要
 分割キーのインデックスの状態によっては、where句で絞り込むオーバーヘッドが大きすぎ、並列化
するとかえって遅くなるケースが有る
 製品
 Apache sqoop

DBからの収集エクスポート方式
テーブル
CSV 収集
 メリット
 SQLよりも事業システムDBに対する負荷は小さい。
 エクスポート時に絞り込みや加工ができる物が多い。
 デメリット
 次に説明する「DBダンプファイル」よりもデータ量が多く、DBに対する負荷も大きい
エクスポート
データ
14

DBからの収集 DBダンプ方式
15
SELECT
復元
テーブル
ダンプ
復元用DB
テーブル収集
 メリット
 事業システムDBへの負荷が少ない
 多くのシステムでは、事業システムDBの日次バックアップをとっているため、それをもらうだけでよ
く、新たに開発しなくてよいケースが有る
 デメリット
 復元用DBは、事業システムDBと同種のDBを用意する必要がある。
 収集時に絞り込みや加工ができない
データ
15

DBからの収集更新ログ方式
16
 概要
 事業システムのDBの更新ログ(MySQLのbinlog等)を随時収集し、復元用DBに適用し復元する。
 メリット
 事業システムDBに対する負荷が小さい
 DBダンプはデータ全量だが、更新ログは差分のみとなるため、データ量が少なく高速。
 DBダンプよりもデータの鮮度を高めることが可能
 デメリット
 構築が難しい
ログ
収集
・
適用
テーブル
更新
ログ
復元用DB
＝リードレプリカ
テーブル収集
準同期レプリケーショ
ンと同じ仕組み
データ

分析システム
収集ワーカ
DBからの収集更新ログ方式 CDC
17
 概要
 更新ログを収集ワーカで解釈し、データウェアハウスに直接反映する。CDC（ Change Data Capture）とも呼ばれる
 メリット
 復元用DBが必要ない
 データレイクorデータウェアハウスにほぼリアルタイムにデータが届くため、データ鮮度が高い
 デメリット
 自前で作るのは難しく、製品利用が前提
 trocco, AWS DMS(Database Migration Service), Attunity, Oracle GoldenGate,
 一般的にデータウェエアハウス製品はUPDATEやDELETEが遅いため、
事業システムDBの更新に頻繁に更新が入ると、収集が間に合わない可能性がある。
 そのため、直接ターゲットテーブルをUPDATE/DELETEするのではなく、一時テーブルに既存データと変更データを入れて処
理する方法が取られる場合がある。
参考：https://trocco.zendesk.com/hc/ja/articles/360046472233-MySQL-to-BigQuery-転送-CDC-
事業システム
ログ
収集
テーブル
更新
ログ解釈格納
データ

事業システム
アプリサーバ or コンテナ
 ポイント
 収集エージェントで取れる形（例えばJSON形式)に変換して貰う必要がある
 事業システムへの働きかけが必要
 急に流量が増えた場合に収集エージェント・収集マネージャのキャパシティを超えることがある
 製品
 fluentd, Logstash, AWS CloudWatch Logs
エージェントを利用した収集
18
18
分析システム
データレイク
データ
アプリ
ログ
収集
マネージャ
収集
エージェント
アプリケーション
tail -f バッファ

ブラウザ
スマホアプリ
IoTデバイス
事業システム
 ポイント
 端末で発生したイベントを分散キューに溜め込み、非同期でデータレイクに取り込む
 メリット
 分散キューに十分な容量を割り当てておけば、急に流量が増えてもイベントを消失しない
 デメリット
 分散キューそのものが難しい
分散キューを利用した収集 (1/3)
19
分析システム
ワーカー
データレイク分散キュー
受信API
javascript
SDK
送信
プログラム
プロデューサーコンシューマー
受信API
ワーカー

 難しい分散キューの特性
 順序性保証レベル
 レベルが低いと、キューに投入された順序でコンシューマーが取り出せるとは限
らない
 信頼性レベル
 レベルが低いと、データは１回以上コンシューマーが受信することがある
 可視性タイムアウト
 コンシューマーが処理している間、他のコンシューマーには見せないようにする
時間
 タイムアウトが処理時間に対して短いと、同じデータを２度処理することになる
 デッドレター
 どのコンシューマーが処理しても必ず失敗するデータ
 データの生成速度
 メッセージの生成速度がコンシューマーの消費速度よりも早い場合、キューが溢
れてしまう
分散キューを利用した収集(2/3)
20
コンシューマー
を冪等に作る
退避するキューを作る
「デッドレターキュー」
BackPressureにより
生成速度を抑止する
対策å
分散キューは難しいので、利用しないで済むならそれがよい

分散キューを利用した収集(3/3)
21
オープンソース AWS
マネージドサービス
GCP
マネージドサービス
プロデューサー自前プログラム
分散キュー Kafka Kinesis Data Streams Cloud Pub/Sub
コンシュー
マー
そのまま格納自前プログラム Lambda、
Kinesis Data Firehose
Cloud Function
加工して格納
（ウインドウ集計
等）
Spark Streamings、
Flink
Kinesis Data Analytics Cloud Dataflow
実現する製品

「JapanTaxi」アプリにおける
実践例03
22

Mobility Technologiesとは
23
配車関連事業
広告決済事業乗務員向けソリューション事業
DRIVE CHART・ドラレコ事業次世代向けR&D事業

「JapanTaxi」アプリのデータ収集
24
BigQuery
生
データ
アプリ
DB
アプリ
SQLによる収集
コンシューマー
Lambda
GPSや
センサー
整形済み
データ
SQL
分散キュー
Kinesis
DataStream
事業システム
アプリログ
分析システム
Open Street Map
外部システム
広告媒体
fluentd
App Store
Google Play
データレイク層
データウェア
ハウス層
ログ
Google Ads
APIによる収集
APIによる収集
自前python
API
アプリ
データ
地図
広告
効果等
ダウンロード数
等
ダウンロード数等広告効果等
Firebase アプリイベント
・重複削除
・名寄せ
・個人情報除去
etc
タクシー
ユーザ

「JapanTaxi」アプリのデータ活用
25
BigQuery
整形済み
データ
KPI
集計SQL
分析システム
BIツール
(Looker)
データアプリケーション
(お迎え時間予想)機械学習用
データ
アドホック分析
(BigQuery UI)
(BigQuery description + 自前ツール(※))
SQL
データウェア
ハウス層
データマート層
意思決定
利益向上￥
https://github.com/JapanTaxi/bqdesc_backupper(※)

データ収集における注意点04
26

 どんな問題？
 ETL製品が多すぎる
 クラウド：AWS Glue, GCP Dataflow, GCP Datafusion
 マネージドサービス：trocco, Alooma
 OSS：embulk, fluentd, logstash, Apache Nifi, sqoop, Pentaho,
 商用製品： Talend, Infomatica, Data Spider, Oracle GoldenGate
 解決策
 ETL製品を選ぶときの選定基準
 入出力プラグインの数は関係ない。プラグインの機能を重視する。
 並列SQLによる収集はできるのか？CDCできるのか？等
 プログラマ向けでカスタマイズ可能な物を選ぶ
 非プログラマ向けのGUIで操作できるものがあるが、多くの場合典型的なデータ収集にしか対応できない。
 デバッグできること（できればソースコードレベルで）
 データ収集の障害は、データの中身がどう処理されているかわからないと解決できないものが多い
 例: nullの扱い null or ”null” or ””
 合うものがなければ自作
 データ収集は業務そのものなので会社によって多種多様。製品でカバーできないケースも多い
ETL製品との付き合い方
27
ETL実行環境
E
T
L
S3
MySQL
S3
コネクタ
MySQL
コネクタ
BigQuery
コネクタ BigQuery

 どんな問題？
 長期間運用するとデータソースである事業システム側の変更により収集が失敗する事が起こる
 仕様変更（列の追加、変更、削除）、障害、計画停止
 解決策
 事業システムの変更を事前に得られる状態にする
 →しかし事業システムのほうが優先されることが多く、分析システムは後回しにされるケースが
多い
 どうする？
 案1：上から落とす
 トップダウンで、事業システムの変更連絡を徹底させる
• 分析システムが会社に貢献（利益向上、意思決定支援）し、民意を得ていることが必須
 →うまく出来ている企業は少ない
 案2 ：事業システムの変更を機械的に知る
 事業システム変更のトリガを機械的にフックする（gitのpull requestなど）
データソースの変更対応
28

どんな問題？
 データ収集チームが、新規要望や障害対応に日々追われて疲弊している。
対応策
 事業へのインパクトを理解し、データ収集に優先順位をつけ対応する
 ECサイトの例
 高：止まると利益が低下するデータ・アプリケーション
 商品レコメンド精度に大きく関わるデータ
 中：止まると意思決定が大きく遅くなるレポート
 KPIモニタリングのための購入データ収集
 低：止まっても影響が小さいもの
 アドホック分析のみで用いるデータ
 目的のわからないデータ収集はやめる
 「企業内のデータを一箇所に」や「データレイクにとりあえず貯める」という曖昧な理由でデー
タを収集してはならない
データ収集の優先度を常に考える
29
「データ収集チーム」が出来てきた時点で要注意。縦割りが始まっている

文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。
30
仲間募集中！

データ収集の基本と「JapanTaxi」アプリにおける実践例

More Related Content

データ収集の基本と「JapanTaxi」アプリにおける実践例

Editor's Notes