TREASUREDATAのエコシステムで作るロバストなETLデータ処理基盤の作り方
1 like2,291 views
ETL処理のユースケースや、ETL処理のセオリーを解説します。 2018/05/23(水)開催の「PLAZMA Data Engineer Day: TD Tech Talk 2018」にてお話ししたスライドです。 https://techplay.jp/event/669346
![PUBLICATION
•2014
•サーバ/インフラエンジニア養
成読本 ログ収集～可視化編 [現
場主導のデータ分析環境を構
築!] (Software Design plus)
•2017
•データ分析基盤構築入門
[Fluentd、Elasticsearch、
Kibanaによるログ収集と可視化]
Sep, 2017Aug, 2014
400 Pages164 Pages](https://image.slidesharecdn.com/howtobuiltrobustetlplatform-180524131701/85/TREASUREDATA-ETL-4-320.jpg)
![ETL処理で気をつけたいこと
•遅れて届くデータ
•単位時間毎のある条件における平均値を求めている場合
•単位時間のデータを改めて全件走査して計算する方法以外の手もあります
•平均値・母数となった件数を両方保管し、増分レコードへの計算に備えます
•例えば 合計64/20件 = 平均3.2 ならば、3.2(avg)と20(num)を記録します
•遅れて届いた[5,12,6]というデータを取り込む場合、次の計算で補正できます
•式: (avg*num+sum(delayed_record))/(num+count(num))
•(3.2*20+5+12+6)/(20+3) = 3.78
•平均値だけでなく、総件数も更新します
26](https://image.slidesharecdn.com/howtobuiltrobustetlplatform-180524131701/85/TREASUREDATA-ETL-26-320.jpg)
TREASUREDATAのエコシステムで作るロバストなETLデータ処理基盤の作り方
- 1. TREASUREDATAのエコシステムで作る ロバストなETLデータ処理基盤の作り方 PLAZMA Data Engineer Day @ TD TECH TALK 2018 - May 23th, 2018 Kentaro Yoshida twitter:@yoshi_ken Data Engineer at Treasure Data, Inc.
- 2. PROFILE •@yoshi_ken •Data Engineer at TreasureData •When I have started to use… •TreasureData: 2012 •Fluentd: 2012 •Embulk: 2015 •Digdag: 2015 •Hivemall：2015
- 3. PROFILE •Released Fluentd Plugin: 12 •rewrite-tag-filter •geoip •twitter •mysql-replicator •anonymizer •munin etc…
- 4. PUBLICATION •2014 •サーバ/インフラエンジニア養 成読本 ログ収集～可視化編 [現 場主導のデータ分析環境を構 築!] (Software Design plus) •2017 •データ分析基盤構築入門 [Fluentd、Elasticsearch、 Kibanaによるログ収集と可視化] Sep, 2017Aug, 2014 400 Pages164 Pages
- 5. PUBLICATION
- 6. PUBLICATION
- 7. PUBLICATION
- 9. THEN
- 10. Business Trip to TreasureData Mountain View Office
- 12. TREASUREDATAのエコシステムで作る ロバストなETLデータ処理基盤の作り方 Kentaro Yoshida twitter:@yoshi_ken Data Engineer at Treasure Data, Inc.
- 13. 13 ETLの基本
- 14. ETLの基本 Transform •中間処理 •表結合 •中間DBも活用 •フォーマット変換 •表記の名寄せや正規化 Extract •Database •File Dataset •Log •API •Stream Input Load •RDB (DWH) •File (S3) •API •Stream •BI Tool Basics of ETL 14
- 15. 15 さまざまなETL処理
- 21. 直列処理 並列処理 Timeline Step1 Step3 Step2 Step1 Step3 Step2 Timeline Serial Processing Parallel Processing ETL処理で気をつけたいこと •活用できるまでのリードタイムの長さ •データが生まれてから使えるまでの処理時間 •単純な直列処理よりもマルチコアを生かして短時間で処理できると好ましい 21
- 24. # ジョブの結果を書き出すResult Export機能の使い方 +simple_query: td>: queries/simple_query.sql database: sample_datasets +result_output: _parallel: true +to_td: sh>: td export:result ${td.last_job_id} ${result_path} _export: result_path: td://@/test_db/test_output_by_jobid +to_s3: sh>: td export:result ${td.last_job_id} ${result_path} _export: result_path: s3://***:***@/my_bucket/file.csv.gz?compression=gz 24
- 26. ETL処理で気をつけたいこと •遅れて届くデータ •単位時間毎のある条件における平均値を求めている場合 •単位時間のデータを改めて全件走査して計算する方法以外の手もあります •平均値・母数となった件数を両方保管し、増分レコードへの計算に備えます •例えば 合計64/20件 = 平均3.2 ならば、3.2(avg)と20(num)を記録します •遅れて届いた[5,12,6]というデータを取り込む場合、次の計算で補正できます •式: (avg*num+sum(delayed_record))/(num+count(num)) •(3.2*20+5+12+6)/(20+3) = 3.78 •平均値だけでなく、総件数も更新します 26
- 27. 27 ETL設計のセオリー
- 28. ETL設計のセオリー •Functional •それぞれが単純明解な処理 •Reproducibility (Idempotent, Immutability) •データソースが不変的で再現性のある冪等な動作が出来ること •Logging Strategy •ログ戦略 •Security •セキュリティ・サニタイズ 28
- 30. ETL設計のセオリー / Reproducibility •何らかのエラーが起きて失敗しても、再実行すれば同じ結果を生み出せること •もし2度同じプログラムを実行してもレコード重複や2重カウントが発生しない •実行させるタイムレンジ毎にsnapshot_idを設けると良い •日次でDBのデータを取り込んでいる場合、timeキーにその時のタイムスタン プを入れるのでは無く、対象日のunixtimeを固定的に使う •実行時にまずsnapshot idを暗黙的に削除し、新たなレコードを入れる •例) DELETE * FROM foo WHERE time = 1526947200 •実行のたびにDELETE, INSERTを行うことで一貫性を確保する 30
- 32. ETL設計のセオリー / Logging Strategy •新たな値が来るとレコードが上書き(またはレコード削除)されていくワークロードには、 イベントログとしてロガーを使うと時系列分析が可能となります •スナップショットは履歴テーブルの要件を完全にはカバーできません •アプリDB側でUPDATE/DELETEはしない増分記録のみの履歴テーブルを持つと肥大化 するため、そういった所にはTreasureDataを活用してオフロードすると良いでしょう •1日に1度のスナップショット取得が適するケース •顧客リスト、顧客のプラン情報テーブル、レコードのDELETEが発生するテーブル •イベントロガーを整備するケース •Webアプリの動作に作用する設定の変更ログ、増分テーブル 32
- 33. ETL設計のセオリー / Security •分析DBに個人情報が入っていてはならない •idや分類識別子だけにする等のサニタイズ処理を取り出し時に済ませておく •スキーマ変更に気づける仕組みを作ろう •テーブルやカラムの増減に追従するため、それを検知できる仕組みを作る •例: db/schema.rbのversionを監視 •新規テーブル/カラムに秘匿情報が入るようならば、どのようなサニタイズ が最適かを検討して反映する •開発DBで検知すれば本番リリースよりも先に気づける 33
- 38. 38 まとめ
- 40. 40