AWS ETL祭り - AWS Glue活用事例@primeNumber

AWS ETL祭り - AWS Glue活用事例@primeNumber

データ基盤「systemN」の本番環境で100億レコード/月のETLをGlueで実装した話

42356380866f616c0cea68779b430eaf?s=128

Hirokazu Kobayashi

February 15, 2018
Tweet

Transcript

  1. 2.

    自己紹介 1 CONFIDENTIAL • 小林寛和 ◦ @hiro-koba (Github) ◦ @hiro_koba_jp

    (Twitter / Qiita) • 株式会社primeNumber ◦ 執行役員 エンジニア • 好きなAWSサービス ◦ Elastic Beanstalk / AWS Lambda ◦ Redshift / AWS Glue © 2018 primeNumber Inc.
  2. 5.

    導入事例: 総合マーケティング企業のDMP 4 © 2018 primeNumber Inc. CONFIDENTIAL • 用途

    ◦ Webブラウザ・スマホアプリ上の行動ログ収集 ◦ 生ログを使用した分析 ◦ セグメンテーション・広告利用 • 規模感 ◦ 収集ログ量: 100億レコード/月超 ◦ ETLジョブ実行回数: 250回/日 ◦ Redshiftノード数: 20 nodes (dc2.large)
  3. 10.

    課題1. コスト改善 9 • 人的コスト ◦ Hadoop専属エンジニアが必要 ◦ 運用上のボトルネック •

    料金 ◦ 最小構成: 20万円/月 ◦ 仮に現在と同じレコード処理した場合 ▪ 100億レコード/月を処理するにはEC2 60台構成 ▪ 月間数百万円、全然ペイしない・・・ CONFIDENTIAL © 2018 primeNumber Inc.
  4. 12.

    課題3. ETL・DWHの可用性を上げたい 11 • DWH側が高負荷になるとETLが止まる ◦ prestoで重いクエリが実行されるとクラスタ毎落ちる ◦ 逆もまた然り •

    DWHがボトルネックに ◦ ETL後のログは別システムなどで利活用したい ◦ prestoを経由する必要があり、ボトルネック ◦ HDFSだと取り回しにくい CONFIDENTIAL © 2018 primeNumber Inc.
  5. 15.

    Batch Layer & Serving Layer for systemN 1. 生ログを汎用的なバッチビューに変換 ◦

    ダッシュボードからのクエリなど 2. ビジネス活用のためのバッチビュー構築 ◦ 1の汎用ログバッチビューから生成 ◦ 広告配信用のユーザー単位のサマリービューなど 14 CONFIDENTIAL © 2018 primeNumber Inc.
  6. 19.

    • 解決したい課題 ◦ 料金・人的コスト最小化 ◦ スケーラビリティの確保 • 解決方法 ◦ マネージド・サービスAWS

    Glueの採用 ▪ インフラ面の運用コストほぼ0 ▪ 学習コストはコードを書くことのみ ▪ 料金は1/4以下に • 最小構成は月間20万円→5万円に ◦ スケーラビリティもLambdaとの統合で解決 Batch Layer実装 18 CONFIDENTIAL © 2018 primeNumber Inc.
  7. 20.

    Batch Layer - スケーラビリティを上げる工夫 19 CONFIDENTIAL © 2018 primeNumber Inc.

    • LambdaでGlueのDPUを自動設定 • 突発的なスパイクが来ても一定時間内に処理が終わるように ① 処理対象のログサイズ取得 ② 1時間以内に処理が終わる DPUの算出 ③ 算出したDPUを設定してJob Run
  8. 21.

    • 解決したい課題 ◦ DWH側の障害・メンテの影響がETLに波及しない ◦ DWHの処理性能がボトルネックにならない • 解決方法 ◦ ETLの出力先をS3に統一

    ▪ DWH側の影響はETLに波及しない ◦ RedshiftとRedshift Spectrumの併用 ▪ 性能面のボトルネックは大きく改善 Serving Layer実装 20 CONFIDENTIAL © 2018 primeNumber Inc.
  9. 22.

    Serving Layer - ETLとDWHの分離 21 CONFIDENTIAL © 2018 primeNumber Inc.

    • ETLとDWHを分離するメリット ◦ 外的要因による障害が減る ▪ DWHの障害・メンテの度に止める必要なくなった ▪ 出力先をS3にしたことで、S3が落ちない限りETLは外的要 因で落ちない ◦ コストメリット ▪ 負荷が少ないロードのために、高価なDPUを使わない
  10. 23.

    Serving Layer - ETLとDWHの分離 22 CONFIDENTIAL © 2018 primeNumber Inc.

    • S3→RedshiftへのロードにはRinを採用 ◦ RinはS3→Redshiftのロードを行うためのOSS • ただしジョブ再実行時の冪等性に注意しないと重複発生 ◦ 現状手動でS3オブジェクト削除・DELETE文発行してる ① ETL後のログがS3に置かれたら SQSに通知 ② SQSをポーリングし、メッセージがあ ればRedshiftにCOPY ③ COPYが完了したらメッセージ削除
  11. 24.

    Serving Layer - 2つのクエリ実行方法 23 CONFIDENTIAL © 2018 primeNumber Inc.

    • 応答速度に応じてRedshift or Redshift Spectrumを選択 • どちらもRedshiftのI/Fでアクセスできる点がポイント ある程度時間がかかっても良いアクセス 応答速度が求められる場合は、 Redshiftにデータをロードしておく
  12. 25.

    Serving Layer - Glue Data Catalog 24 CONFIDENTIAL © 2018

    primeNumber Inc. • ETL後のデータはGlueのData Catalogに登録して再利用性向上 ◦ Glue Data CatalogはCrawlerから作成できるメタデータ ◦ Redshift Spectrum、Athena、EMRからテーブルとして扱える ◦ AWS GlueのCrawlerを実行すればすぐ作れる • データのアーカイブ用途でも利用可能 ◦ 過去データ等、利用頻度は少ないが削除するかは悩ましい場合 ◦ S3に退避してData Catalog化しておけば解決 ① Glue CrawlerでS3上のログを クローリングし、Data Catalog作成 ② Redshift上でテーブルとして扱えるように
  13. 26.

    • ETL後のデータの内、一部のフィールドだけRedshiftに取り込 みたい • Redshift Spectrumからは全フィールドが見たい • AVRO+COPYコマンドで解決 一部の列だけRedshiftにLoad 25

    CONFIDENTIAL © 2018 primeNumber Inc. AVRO形式で出力 テーブル定義に存在するフィー ルドだけ取り込まれる Spectrumからは 全フィールドが見える Redshift上には 必要列だけロードし、 容量圧縮
  14. 27.

    2017年9月末リリース 26 CONFIDENTIAL © 2018 primeNumber Inc. • 2017年9月1日、リプレイスPJT始動 •

    2017年9月前半、アーキテクチャ設計 • 2017年9月後半、実装 • 2017年9月末日、本番リリース・完全切替
  15. 28.

    • ETL後のデータの再利用性もっと上げたい ◦ ETLのバージョン違いでデータ形式などもバラバラ ◦ 全期間のデータが同じスキーマで揃っていると再利用性が 更に高くなる • Spectrumのパフォーマンス上げたい ◦

    Parquet形式にしたい(RedshiftのCOPY非対応) ◦ S3のパーティションも最適化したい ▪ Ex. s3://BUCKET/site_id=123/year=2018/… • ETL後のデータに対するETLを作成中 今後の課題1. データマート化 27 CONFIDENTIAL © 2018 primeNumber Inc.
  16. 29.

    • スモールスタートと実装スピードはGlueの得意とするところだ が、もう少しコスト抑えたい • コードで出来る最適化 ◦ RDDを極力使わないなどPySparkのチューニング ◦ Scala化の検証 •

    Glue以外の選択肢も ◦ ログ量が増えたらEMRの方が安かったりするかも? ◦ 便利なDynamicFrameやEC2運用が発生するデメリットを 許容できるか、検証中 今後の課題2. Jobの高速化 28 CONFIDENTIAL © 2018 primeNumber Inc.
  17. 31.

    • データアクセス層とETL処理層に分けています プログラミングモデル 30 CONFIDENTIAL © 2018 primeNumber Inc. 入力はDynamicFrameで

    のロードが便利 ETL処理層のI/FはDataFrame 任意の列でディレクトリを切るなど は、DynamicFrame使えない
  18. 32.

    • ETL処理層はローカル開発 ◦ 少量データからDataFrameを作り、それをETLする ◦ Jupyter Notebookから実行 • データアクセス層の開発やE2Eで動かしたい時はDevEndpoint ◦

    DynamicFrameでデータロードする箇所とか ◦ DevEndpointハマりどころ ▪ SparkContextを再生成しないとtoDF()が動かない ▪ spark.stop() glueContext = GlueContext(SparkContext.getOrCreate()) 開発環境 31 CONFIDENTIAL © 2018 primeNumber Inc.
  19. 33.

    • Glue Job Script ◦ データアクセス層の処理とロギングがメイン ◦ ETL処理はライブラリの呼び出す • Job

    Library ◦ Githubのprivateリポジトリからpip installし、Zipで固めて S3に配置 ◦ このバージョンが変わるとETLの出力も変わるため、バー ジョンごとにS3のディレクトリを変えている • External File ◦ 設定ファイルや変換に必要なインメモリDB等 • Glue Job ◦ 上記のScript、Lib、Fileの参照を持たせるだけ コンポーネントとリリース 32 CONFIDENTIAL © 2018 primeNumber Inc.
  20. 34.

    • Jobの実行結果 ◦ CloudWatch Eventを使用し、基本全てSNS通知 ◦ SNSはIFTTTに通知し、失敗時のみ通知するよう分岐 ◦ ただしJobのステータスがSUCCEEDEDなのにエラー終了 しているのを見たことがあるので、ちゃんとやるなら

    CloudWatch Logsのログでアラート設定すべきかも • Job実行時間 ◦ うまい方法見つけられてない ◦ 毎時GlueのAPI叩いてRunningのジョブの実行時間取る とか・・・? ◦ 現状シビアに監視する必要が無いのでやってない 監視・障害検知 33 CONFIDENTIAL © 2018 primeNumber Inc.
  21. 36.

    • 改行コードを含むデータは正しく認識できない ◦ 複数行に分割されてテーブルが作られるので件数合わない ◦ Custom Classifierでも対応できないらしい ◦ 現状クロール対象のデータを修正するしか無い •

    差分更新的めちゃ遅い ◦ 作成済みData Catalogの再クローリング遅い ◦ ファイル1つしか増えていなくても、全件クロールと同じくらい時間かかる ◦ パーティション追加は手動でやるしか・・・? Glue Crawlerの注意点 35 CONFIDENTIAL © 2018 primeNumber Inc.
  22. 37.

    • コストが大幅に改善した ◦ Hadoopエンジニアに頼らない開発が出来るように ◦ 料金も約75%カット • スケーラビリティ向上 ◦ DPUを動的に算出すれば自動でスケール

    • S3を出力先にすることで可用性向上 ◦ ジョブがコケる外的要因を出来るだけ減らす ◦ Data Catalog + Redshift Spectrumで再利用性向上 まとめ 36 CONFIDENTIAL © 2018 primeNumber Inc.