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

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

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

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

4. Mobility Technologies Co., Ltd. データ分析システムの全体とデータ収集の役割01 4

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

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

7. Mobility Technologies Co., Ltd. データソースの種類と取得方法02 7

8. Mobility Technologies Co., Ltd. データソースの種類と収集方法 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画面遷移、クリック、スクロール、マウス軌跡。分散キューを利用した収集 →割愛 →割愛

9. Mobility Technologies Co., Ltd. ファイル収集 (1/2) 9 分析システム事業システムデータ配置処理データキュー 2.配置完了通知 1.配置 3.通知受領 4.データ収集オブジェクトストレージ収集処理収集処理収集処理 5.蓄積データレイク or データウェエアハウス

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

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

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

13. Mobility Technologies Co., Ltd.  巨大なテーブルからの収集を並列化する場合 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

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

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

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

17. Mobility Technologies Co., Ltd. 分析システム収集ワーカ 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- 事業システムログ収集事業システムDB テーブル更新ログ解釈格納データウェエアハウス

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

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

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

21. Mobility Technologies Co., Ltd. 分散キューを利用した収集(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 実現する製品

22. Mobility Technologies Co., Ltd. 「JapanTaxi」アプリにおける実践例03 22

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

24. Mobility Technologies Co., Ltd. 「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 タクシーユーザ

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

26. Mobility Technologies Co., Ltd. データ収集における注意点04 26

27. Mobility Technologies Co., Ltd.  どんな問題？  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

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

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

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

Tetsutaro Watanabe

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