Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

fetaro
August 19, 2020
27

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

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

fetaro

August 19, 2020
Tweet

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. Mobility Technologies Co., Ltd.
    分析システム全体像
    5
    分析システム
    事業システム
    データ
    レイク データ
    ウェア
    ハウス
    アドホック
    分析
    データ
    マート
    データ
    可視化
    一次
    加工 マート
    生成
    データ
    収集
    データ
    生成
    メタデータ管理
    データ
    アプリ
    ケーション








    収集
    ⽣成 蓄積 活⽤
    データ
    ソース
    構造化
    データ
    非構造化
    データ
    構造化
    データ

    View Slide

  6. Mobility Technologies Co., Ltd.
    分析システムにおけるデータ収集
    6
    分析システム
    事業システム
    データ
    レイク データ
    ウェア
    ハウス
    アドホック
    分析
    データ
    マート
    データ
    可視化
    一次
    加工 マート
    生成
    データ
    収集
    データ
    生成
    メタデータ管理
    データ
    アプリ
    ケーション








    収集
    ⽣成 蓄積 活⽤
    データ
    ソース
    構造化
    データ
    非構造化
    データ
    構造化
    データ
    データ収集で考える範囲

    View Slide

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

    View Slide

  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画⾯遷移、クリック、ス
    クロール、マウス軌跡。
    分散キューを利⽤した収集
    →割愛
    →割愛

    View Slide

  9. Mobility Technologies Co., Ltd.
    ファイル収集 (1/2)
    9
    分析システム
    事業システム
    データ
    配置処理
    データ
    キュー
    2.配置完了通

    1.配置
    3.通知受領
    4.データ収集
    オブジェクトストレージ
    収集処理
    収集処理
    収集処理
    5.蓄積
    データレイク
    or
    データ
    ウェエアハウス

    View Slide

  10. Mobility Technologies Co., Ltd.
    nファイルフォーマットの種類
    ファイル収集 (2/2)
    10
    フォーマット

    説明 利⽤ケース
    CSV, TSV ・構造化データを表現できる
    ・テキストフォーマット
    構造化データで可読性重視の場合
    JSON ・半構造化データを表現できる
    ・テキストフォーマット
    ・キー名もデータに含まれるため、データ量が多くなりが

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. Mobility Technologies Co., Ltd.
    DBからの収集 更新ログ⽅式
    16
    n 概要
    n 事業システムのDBの更新ログ(MySQLのbinlog等)を随時収集し、復元⽤DBに適⽤し復元する。
    n メリット
    n 事業システムDBに対する負荷が⼩さい
    n DBダンプはデータ全量だが、更新ログは差分のみとなるため、データ量が少なく⾼速。
    n DBダンプよりもデータの鮮度を⾼めることが可能
    n デメリット
    n 構築が難しい
    分析システム
    事業システム
    ログ
    収集

    適⽤
    事業システムDB
    テーブル
    更新
    ログ
    復元⽤DB
    =リードレプリカ
    テーブル 収集
    準同期レプリケーショ
    ンと同じ仕組み
    データ
    ウェエアハウス

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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
    n実現する製品

    View Slide

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

    View Slide

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

    View Slide

  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
    タクシー
    ユーザ

    View Slide

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

    https://github.com/JapanTaxi/bqdesc_backupper
    (※)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. ⽂章·画像等の内容の無断転載及び複製等の⾏為はご遠慮ください。
    Mobility Technologies Co., Ltd.
    30
    仲間募集中!

    View Slide