Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TREASUREDATAのエコシステムで作るロバストなETLデータ処理基盤の作り方

359 views

Published on

ETL処理のユースケースや、ETL処理のセオリーを解説します。

2018/05/23(水)開催の「PLAZMA Data Engineer Day: TD Tech Talk 2018」にてお話ししたスライドです。
https://techplay.jp/event/669346

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

TREASUREDATAのエコシステムで作るロバストなETLデータ処理基盤の作り方

  1. 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. 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. 3. PROFILE •Released Fluentd Plugin: 12 •rewrite-tag-filter •geoip •twitter •mysql-replicator •anonymizer •munin etc…
  4. 4. PUBLICATION •2014 •サーバ/インフラエンジニア養 成読本 ログ収集~可視化編 [現 場主導のデータ分析環境を構 築!] (Software Design plus)
 •2017 •データ分析基盤構築入門 
 [Fluentd、Elasticsearch、 Kibanaによるログ収集と可視化] Sep, 2017Aug, 2014 400 Pages164 Pages
  5. 5. PUBLICATION
  6. 6. PUBLICATION
  7. 7. PUBLICATION
  8. 8. PUBLICATION •機能やカテゴリごとに分類し、日本語での解説を再度実施 •一定の条件のもと、現在も利用を推奨できるものに厳選 •ダウンロード数が多い順に並べているため選びやすい特徴 •Fluentdプラグイン事典:厳選した328プラグインの紹介 •Embulkプラグイン事典:厳選した202プラグインの紹介
  9. 9. THEN
  10. 10. Business Trip to TreasureData Mountain View Office
  11. 11. Let’s join us! 11
  12. 12. TREASUREDATAのエコシステムで作る ロバストなETLデータ処理基盤の作り方 Kentaro Yoshida twitter:@yoshi_ken Data Engineer at Treasure Data, Inc.
  13. 13. 13 ETLの基本
  14. 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. 15 さまざまなETL処理
  16. 16. 19 ETL処理で気をつけたいこと
  17. 17. ETL処理で気をつけたいこと •活用できるまでのリードタイム •最小限のラグとすべき •エラーハンドリング •タイムアウト •プロセスダウン •リトライ •ログ出力 •エラー通知と監視設定 •データ検証 •破損レコードの検出 •バックフィル •データの入れ直し •冪等性の担保 •遅れて到着したデータへの考慮 •速報値と確定値のズレ etc… 20
  18. 18. 直列処理 並列処理 Timeline Step1 Step3 Step2 Step1 Step3 Step2 Timeline Serial Processing Parallel Processing ETL処理で気をつけたいこと •活用できるまでのリードタイムの長さ •データが生まれてから使えるまでの処理時間 •単純な直列処理よりもマルチコアを生かして短時間で処理できると好ましい 21
  19. 19. ETL処理で気をつけたいこと •エラーハンドリング •異常終了したバッチのレジューム(Backfill)が出来る仕組み •コマンド1つで再実行できることが理想 •手動でのゴミファイル削除に頼ってはいけない •途中で落ちていても問題が起きない、冪等性のある設計が必要である •レジューム機能 •最初からやり直しをさせることは最終手段 •チェックポイントとし書き出されたファイルの所から再開できる仕組み 22
  20. 20. ETL処理で気をつけたいこと •効率の良いレジュームとは、失敗した処理から再開できること •各ステップの最初からやり直すのではなく、作られたチェックポイントの続き から再開できる •DBからのSnapshotを取得してDWHへ書き出す処理は、取り込みと書き出し の2つに分ける •S3等のストレージへの書き出しをチェックポイントとする •特にSnapshotの取得に数時間かかる場合に有用 •TDでも、クエリの実行と書き出しは別のJOBとして実行可能となった (2018年新機能) 23
  21. 21. # ジョブの結果を書き出す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
  22. 22. ETL処理で気をつけたいこと •遅れて届くデータ •単位時間毎に集計した結果をレポートしたいが、即座には届かない事を考慮 •例えばスマホアプリからのログに数時間の遅れが生じることは良くあること •日次で前日または前々日のデータを処理する運用で対処するケースもある •遅れて届く範囲が予測可能という前提が成り立つユースケースの場合 •速さが価値につながるシステムなら、速報値と確定値の2ストリームとすべき •速報値として5分や10分といった単位での計算をする •日次で確定値の計算を行う 25
  23. 23. 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
  24. 24. 27 ETL設計のセオリー
  25. 25. ETL設計のセオリー •Functional •それぞれが単純明解な処理 •Reproducibility (Idempotent, Immutability) •データソースが不変的で再現性のある冪等な動作が出来ること •Logging Strategy •ログ戦略 •Security •セキュリティ・サニタイズ 28
  26. 26. ETL設計のセオリー / Functional •シンプルかつ単機能だと、テストを行いやすい •1つのPythonスクリプトで、一気通貫処理で実装されていると手をつけにくい •ETL処理こそ、ステップ実行できる単機能な処理がチェーンする仕組みが合う •不具合が起きたときの調査も行いやすくなる •例えばDBからデータを吸い出して別の分析DBへ転送するスクリプトがある •その途中にあるDataFrameの加工部分の調整を行いたい •そのたびにDBからデータを直接取り出すのはナンセンス •S3にあるテストデータを読ませてunit testが作れる仕組みが欲しい 29
  27. 27. ETL設計のセオリー / Reproducibility •何らかのエラーが起きて失敗しても、再実行すれば同じ結果を生み出せること •もし2度同じプログラムを実行してもレコード重複や2重カウントが発生しない •実行させるタイムレンジ毎にsnapshot_idを設けると良い •日次でDBのデータを取り込んでいる場合、timeキーにその時のタイムスタン プを入れるのでは無く、対象日のunixtimeを固定的に使う •実行時にまずsnapshot idを暗黙的に削除し、新たなレコードを入れる •例) DELETE * FROM foo WHERE time = 1526947200 •実行のたびにDELETE, INSERTを行うことで一貫性を確保する 30
  28. 28. ETL設計のセオリー / Immutability •履歴テーブル •DBのデータを抽出して中間DBに納める際に、snapshot_idを付与する •snapshot_idを用いて、どのように変化したか時系列分析が可能となる •snapshot_idを使ってそれぞれのテーブルからレコードを取り出せば、過去の日 の組み合わせを元にした再現性のある再計算も可能となる •同様に、元のテーブルから作られたFactテーブルにもsnapshot_idを付与する 31
  29. 29. ETL設計のセオリー / Logging Strategy •新たな値が来るとレコードが上書き(またはレコード削除)されていくワークロードには、
 イベントログとしてロガーを使うと時系列分析が可能となります •スナップショットは履歴テーブルの要件を完全にはカバーできません 
 •アプリDB側でUPDATE/DELETEはしない増分記録のみの履歴テーブルを持つと肥大化 するため、そういった所にはTreasureDataを活用してオフロードすると良いでしょう •1日に1度のスナップショット取得が適するケース •顧客リスト、顧客のプラン情報テーブル、レコードのDELETEが発生するテーブル •イベントロガーを整備するケース •Webアプリの動作に作用する設定の変更ログ、増分テーブル 32
  30. 30. ETL設計のセオリー / Security •分析DBに個人情報が入っていてはならない •idや分類識別子だけにする等のサニタイズ処理を取り出し時に済ませておく •スキーマ変更に気づける仕組みを作ろう •テーブルやカラムの増減に追従するため、それを検知できる仕組みを作る •例: db/schema.rbのversionを監視 •新規テーブル/カラムに秘匿情報が入るようならば、どのようなサニタイズ が最適かを検討して反映する •開発DBで検知すれば本番リリースよりも先に気づける 33
  31. 31. ETL設計のセオリー / Security •プロダクションDBからの抽出と、それ以降のプログラム群を分けるべき •分けることでの生産性向上が期待できる •前者はセキュリティ監査レビューを入念に行い、後者は素早い開発が期待でき る •後者が設置される分析基盤は、プロダクション外のネットワークに置けた方が 外部連携など自由度が高まる 34
  32. 32. 35 TDを活用することで出来ること
  33. 33. TDのエコシステムを活用することで解決すること •ETL処理・基盤を自前で整備するには、さまざまな苦労が発生する
 •embulkが解消させること •データ取り込みやフィルタ加工が、設定ファイルで容易となる •ETL処理に最適化されたembulkを用いることで、実装工数を圧縮可能 •1ファイルであってもマルチコアを活用して高速に処理が出来る仕組み •digdagが解消させること •スケジューリングやエラーハンドリング、再実行を任せられる 36
  34. 34. TDのエコシステムを活用することで解決すること •TreasureCDPが解決すること •大量のデータに耐えられるスケーラブルなシステムにより、
 利用企業は顧客への価値提供最大化に注力できるようになる •エンジニア観点では、最も負荷が高く難易度の高いデータプラットフォーム部 分の仕組みを利用することで、データ活用の工数的ハードルが劇的に下がる •TDには全量データを入れて、各種連携システム毎に必要な量のデータを転送す るようなハブとしての使い方は効果的 37
  35. 35. 38 まとめ
  36. 36. まとめ •ETL処理のセオリーをおさえて、ロバストな基盤を作るノウハウを紹介しました
 •可能な限り利用者の負担を減らし、シンプルにどう解決するか。 
 それを実現できるのがTreasureDataの強みだと感じています。 
 •TDのエコシステムを活用するとさまざまなノウハウを大いに活用できるため、
 ビジネスの拡大を大いに後押しでき、スピード感のある成功を支援できます
 •TDはAWS上で動いているシステムなので、AWSの他サービスとの連携にも優れ、そ れぞれの良いところ取りが出来る自由さもメリットだと感じています 39
  37. 37. 40

×