O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

データ収集の基本と「JapanTaxi」アプリにおける実践例

16.038 visualizações

Publicada em

データ収集の基本として、データソース毎に典型的なデータ収集方法を整理して説明しています。またJapanTaxiアプリにおいてどのように実践しているかを説明しています。

Publicada em: Tecnologia
  • Entre para ver os comentários

データ収集の基本と「JapanTaxi」アプリにおける実践例

  1. 1. Mobility Technologies Co., Ltd. Data Engineering Study #2 データ収集の基本と 「JapanTaxi」アプリにおける実践例 株式会社 Mobility Technologies 渡部 徹太郎 2020/8/19
  2. 2. Mobility Technologies Co., Ltd. 自己紹介 2 ID :fetaro 名前:渡部 徹太郎 学生:東京工業大学でデータベースと情報検索の研究 (@日本データベース学会) 職歴: * 野村総合研究所(NRI) - オンライントレードシステム基盤 - オープンソース技術部隊 * リクルートテクノロジーズ - ビッグデータ分析基盤 * MobilityTechnologies - データエンジニア エディタ:emacs派→ InteliJ派 日本AWSユーザ会(JAWS) ビッグデータ支部長 やってました 著書
  3. 3. Mobility Technologies Co., Ltd. confidential 3 データソースの種類と取得方法 Agenda 「JapanTaxi」アプリにおける実践例 データ収集における注意点 データ分析システムの全体とデータ収集の役割 70% 10% 15% 5%
  4. 4. Mobility Technologies Co., Ltd. データ分析システムの全体と データ収集の役割01 4
  5. 5. Mobility Technologies Co., Ltd. 分析システム全体像 5 分析システム事業システム データ レイク データ ウェア ハウス アドホック 分析 データ マート データ 可視化 一次 加工 マート 生成 データ 収集 データ 生成 メタデータ管理 データ アプリ ケーション 利 益 向 上 意 思 決 定 収集生成 蓄積 活用 データ ソース 構造化 データ 非構造化 データ 構造化 データ
  6. 6. Mobility Technologies Co., Ltd. 分析システムにおけるデータ収集 6 分析システム事業システム データ レイク データ ウェア ハウス アドホック 分析 データ マート データ 可視化 一次 加工 マート 生成 データ 収集 データ 生成 メタデータ管理 データ アプリ ケーション 利 益 向 上 意 思 決 定 収集生成 蓄積 活用 データ ソース 構造化 データ 非構造化 データ 構造化 データ データ収集で考える範囲
  7. 7. Mobility Technologies Co., Ltd. データソースの種類と 取得方法02 7
  8. 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. 9. Mobility Technologies Co., Ltd. ファイル収集 (1/2) 9 分析システム事業システム データ 配置処理 データ キュー 2.配置完了通 知 1.配置 3.通知受領 4.データ収集 オブジェクトストレージ 収集処理収集処理収集処理 5.蓄積 データレイク or データ ウェエアハウス
  10. 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. 11. Mobility Technologies Co., Ltd. API呼び出し 11 収集処理 3. 格納 API 分析システム 1. HTTP GET (トークン付き) 2. JSON データレイク or データ ウェエアハウス  注意点  多くの場合APIコール回数制限がある
  12. 12. Mobility Technologies Co., Ltd.  メリット  実装が簡単  取得対象のデータを SQLで絞り込みや加工ができる  デメリット  事業システムDBに高い負荷を与える  事業システムのデータベースキャッシュは、オンラインのワークロードに最適化されているが、データ収集のSELECT文が キャッシュを流してしまう。  長時間トランザクションになりがち  リードレプリカから収集すれば軽減できる DBからの収集 SQL方式(1/2) 12 分析システム事業システム 1.SELECT文 収集処理 2.カーソル返却 4.データ 3.フェッチ 5.一時格納 一時 ファイル 6. 格納 3〜6を繰り返す 事業システムDB テーブル データ ウェエアハウス
  13. 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. 14. Mobility Technologies Co., Ltd. DBからの収集 エクスポート方式 分析システム事業システム テーブル CSV 収集  メリット  SQLよりも事業システムDBに対する負荷は小さい。  エクスポート時に絞り込みや加工ができる物が多い。  デメリット  次に説明する「DBダンプファイル」よりもデータ量が多く、DBに対する負荷も大きい 事業システムDB エクスポート データ ウェエアハウス 14
  15. 15. Mobility Technologies Co., Ltd. DBからの収集 DBダンプ方式 15 分析システム事業システム SELECT 復元 事業システムDB テーブル ダンプ 復元用DB テーブル 収集  メリット  事業システムDBへの負荷が少ない  多くのシステムでは、事業システムDBの日次バックアップをとっているため、それをもらうだけでよ く、新たに開発しなくてよいケースが有る  デメリット  復元用DBは、事業システムDBと同種のDBを用意する必要がある。  収集時に絞り込みや加工ができない データ ウェエアハウス 15
  16. 16. Mobility Technologies Co., Ltd. DBからの収集 更新ログ方式 16  概要  事業システムのDBの更新ログ(MySQLのbinlog等)を随時収集し、復元用DBに適用し復元する。  メリット  事業システムDBに対する負荷が小さい  DBダンプはデータ全量だが、更新ログは差分のみとなるため、データ量が少なく高速。  DBダンプよりもデータの鮮度を高めることが可能  デメリット  構築が難しい 分析システム事業システム ログ 収集 ・ 適用 事業システムDB テーブル 更新 ログ 復元用DB =リードレプリカ テーブル 収集 準同期レプリケーショ ンと同じ仕組み データ ウェエアハウス
  17. 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. 18. Mobility Technologies Co., Ltd. 事業システム アプリサーバ or コンテナ  ポイント  収集エージェントで取れる形(例えばJSON形式)に変換して貰う必要がある  事業システムへの働きかけが必要  急に流量が増えた場合に収集エージェント・収集マネージャのキャパシティを超えることがある  製品  fluentd, Logstash, AWS CloudWatch Logs エージェントを利用した収集 18 18 分析システム データレイク データ アプリ ログ 収集 マネージャ 収集 エージェント アプリケーション tail -f バッファ
  19. 19. Mobility Technologies Co., Ltd. ブラウザ スマホアプリ IoTデバイス 事業システム  ポイント  端末で発生したイベントを分散キューに溜め込み、非同期でデータレイクに取り込む  メリット  分散キューに十分な容量を割り当てておけば、急に流量が増えてもイベントを消失しない  デメリット  分散キューそのものが難しい 分散キューを利用した収集 (1/3) 19 分析システム ワーカー データレイク分散キュー 受信API javascript SDK 送信 プログラム プロデューサー コンシューマー 受信API ワーカー
  20. 20. Mobility Technologies Co., Ltd.  難しい分散キューの特性  順序性保証レベル  レベルが低いと、キューに投入された順序でコンシューマーが取り出せるとは限 らない  信頼性レベル  レベルが低いと、データは1回以上コンシューマーが受信することがある  可視性タイムアウト  コンシューマーが処理している間、他のコンシューマーには見せないようにする 時間  タイムアウトが処理時間に対して短いと、同じデータを2度処理することになる  デッドレター  どのコンシューマーが処理しても必ず失敗するデータ  データの生成速度  メッセージの生成速度がコンシューマーの消費速度よりも早い場合、キューが溢 れてしまう 分散キューを利用した収集(2/3) 20 コンシューマー を冪等に作る 退避するキューを作る 「デッドレターキュー」 BackPressureにより 生成速度を抑止する 対策å 分散キューは難しいので、利用しないで済むならそれがよい
  21. 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. 22. Mobility Technologies Co., Ltd. 「JapanTaxi」アプリにおける 実践例03 22
  23. 23. Mobility Technologies Co., Ltd. Mobility Technologiesとは 23 配車関連事業 広告決済事業 乗務員向けソリューション事業 DRIVE CHART・ドラレコ事業 次世代向けR&D事業
  24. 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. 25. Mobility Technologies Co., Ltd. 「JapanTaxi」アプリのデータ活用 25 BigQuery 整形済み データ KPI 集計SQL 分析システム BIツール (Looker) データアプリケーション (お迎え時間予想)機械学習用 データ アドホック分析 (BigQuery UI) メタデータ管理 (BigQuery description + 自前ツール(※)) SQL データウェア ハウス層 データマート層 意思決定 利益向上¥ https://github.com/JapanTaxi/bqdesc_backupper(※)
  26. 26. Mobility Technologies Co., Ltd. データ収集における注意点04 26
  27. 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. 28. Mobility Technologies Co., Ltd.  どんな問題?  長期間運用するとデータソースである事業システム側の変更により収集が失敗する事が起こる  仕様変更(列の追加、変更、削除)、障害、計画停止  解決策  事業システムの変更を事前に得られる状態にする  →しかし事業システムのほうが優先されることが多く、分析システムは後回しにされるケースが 多い  どうする?  案1: 上から落とす  トップダウンで、事業システムの変更連絡を徹底させる • 分析システムが会社に貢献(利益向上、意思決定支援)し、民意を得ていることが必須  →うまく出来ている企業は少ない  案2 :事業システムの変更を機械的に知る  事業システム変更のトリガを機械的にフックする(gitのpull requestなど) データソースの変更対応 28
  29. 29. Mobility Technologies Co., Ltd. どんな問題?  データ収集チームが、新規要望や障害対応に日々追われて疲弊している。 対応策  事業へのインパクトを理解し、データ収集に優先順位をつけ対応する  ECサイトの例  高:止まると利益が低下するデータ・アプリケーション  商品レコメンド精度に大きく関わるデータ  中:止まると意思決定が大きく遅くなるレポート  KPIモニタリングのための購入データ収集  低:止まっても影響が小さいもの  アドホック分析のみで用いるデータ  目的のわからないデータ収集はやめる  「企業内のデータを一箇所に」や「データレイクにとりあえず貯める」という曖昧な理由でデー タを収集してはならない データ収集の優先度を常に考える 29 「データ収集チーム」が出来てきた時点で要注意。縦割りが始まっている
  30. 30. 文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 30 仲間募集中!

×