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
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 テーブル 更新 ログ 解釈 格納 データ ウェエアハウス
Mobility Technologies Co., Ltd. n 難しい分散キューの特性 n 順序性保証レベル n レベルが低いと、キューに投⼊された順序でコンシューマーが取り出せるとは限 らない n 信頼性レベル n レベルが低いと、データは１回以上コンシューマーが受信することがある n 可視性タイムアウト n コンシューマーが処理している間、他のコンシューマーには⾒せないようにする 時間 n タイムアウトが処理時間に対して短いと、同じデータを２度処理することになる n デッドレター n どのコンシューマーが処理しても必ず失敗するデータ n データの⽣成速度 n メッセージの⽣成速度がコンシューマーの消費速度よりも早い場合、キューが溢 れてしまう 分散キューを利⽤した収集(2/3) 20 コンシューマー を冪等に作る 退避するキューを作る 「デッドレターキュー」 BackPressureにより ⽣成速度を抑⽌する 対策å 分散キューは難しいので、利⽤しないで済むならそれがよい
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
Mobility Technologies Co., Ltd. n どんな問題？ n ⻑期間運⽤するとデータソースである事業システム側の変更により収集が失敗する事が起こる n 仕様変更（列の追加、変更、削除）、障害、計画停⽌ n 解決策 n 事業システムの変更を事前に得られる状態にする n →しかし事業システムのほうが優先されることが多く、分析システムは後回しにされるケースが 多い n どうする？ n 案1： 上から落とす n トップダウンで、事業システムの変更連絡を徹底させる • 分析システムが会社に貢献（利益向上、意思決定⽀援）し、⺠意を得ていることが必須 n →うまく出来ている企業は少ない n 案2 ：事業システムの変更を機械的に知る n 事業システム変更のトリガを機械的にフックする（gitのpull requestなど） データソースの変更対応 28
Mobility Technologies Co., Ltd. nどんな問題？ n データ収集チームが、新規要望や障害対応に⽇々追われて疲弊している。 n対応策 n 事業へのインパクトを理解し、データ収集に優先順位をつけ対応する n ECサイトの例 n ⾼：⽌まると利益が低下するデータ・アプリケーション n 商品レコメンド精度に⼤きく関わるデータ n 中：⽌まると意思決定が⼤きく遅くなるレポート n KPIモニタリングのための購⼊データ収集 n 低：⽌まっても影響が⼩さいもの n アドホック分析のみで⽤いるデータ n ⽬的のわからないデータ収集はやめる n 「企業内のデータを⼀箇所に」や「データレイクにとりあえず貯める」という曖昧な理由でデー タを収集してはならない データ収集の優先度を常に考える 29 「データ収集チーム」が出来てきた時点で要注意。縦割りが始まっている
fetaro
colly
erikaheidi
notwaldorf
andyhume
jasonvnalue
marktimemedia
lauravandoore
palkan
lynnandtonic
3n
paulrobertlloyd