収集ワーカー 事業システム 収集ワーカー 収集ワーカー テーブル 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
復元 事業システムDB テーブル ダンプ 復元⽤DB テーブル 収集 n メリット n 事業システムDBへの負荷が少ない n 多くのシステムでは、事業システムDBの⽇次バックアップをとっているため、それをもらうだけでよ く、新たに開発しなくてよいケースが有る n デメリット n 復元⽤DBは、事業システムDBと同種のDBを⽤意する必要がある。 n 収集時に絞り込みや加⼯ができない データ ウェエアハウス 15
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 テーブル 更新 ログ 解釈 格納 データ ウェエアハウス
らない n 信頼性レベル n レベルが低いと、データは１回以上コンシューマーが受信することがある n 可視性タイムアウト n コンシューマーが処理している間、他のコンシューマーには⾒せないようにする 時間 n タイムアウトが処理時間に対して短いと、同じデータを２度処理することになる n デッドレター n どのコンシューマーが処理しても必ず失敗するデータ n データの⽣成速度 n メッセージの⽣成速度がコンシューマーの消費速度よりも早い場合、キューが溢 れてしまう 分散キューを利⽤した収集(2/3) 20 コンシューマー を冪等に作る 退避するキューを作る 「デッドレターキュー」 BackPressureにより ⽣成速度を抑⽌する 対策å 分散キューは難しいので、利⽤しないで済むならそれがよい
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
n 解決策 n 事業システムの変更を事前に得られる状態にする n →しかし事業システムのほうが優先されることが多く、分析システムは後回しにされるケースが 多い n どうする？ n 案1： 上から落とす n トップダウンで、事業システムの変更連絡を徹底させる • 分析システムが会社に貢献（利益向上、意思決定⽀援）し、⺠意を得ていることが必須 n →うまく出来ている企業は少ない n 案2 ：事業システムの変更を機械的に知る n 事業システム変更のトリガを機械的にフックする（gitのpull requestなど） データソースの変更対応 28
n ECサイトの例 n ⾼：⽌まると利益が低下するデータ・アプリケーション n 商品レコメンド精度に⼤きく関わるデータ n 中：⽌まると意思決定が⼤きく遅くなるレポート n KPIモニタリングのための購⼊データ収集 n 低：⽌まっても影響が⼩さいもの n アドホック分析のみで⽤いるデータ n ⽬的のわからないデータ収集はやめる n 「企業内のデータを⼀箇所に」や「データレイクにとりあえず貯める」という曖昧な理由でデー タを収集してはならない データ収集の優先度を常に考える 29 「データ収集チーム」が出来てきた時点で要注意。縦割りが始まっている
fetaro
tammyeverts
productmarketing
marktimemedia
samlambert
jonrohan
jponch
irinanazarova
carmenintech
jrom
eileencodes
danielanewman
