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

by Hirokazu Kobayashi

Slide 1

Slide 1 text

2018年2月15日 AWS Glue活用事例データ基盤「systemN」の本番環境で、 100億レコード/月のETLをGlueで実装した話

Slide 2

Slide 2 text

自己紹介 1 CONFIDENTIAL ● 小林寛和 ○ @hiro-koba (Github) ○ @hiro_koba_jp (Twitter / Qiita) ● 株式会社primeNumber ○ 執行役員エンジニア ● 好きなAWSサービス ○ Elastic Beanstalk / AWS Lambda ○ Redshift / AWS Glue © 2018 primeNumber Inc.

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

導入事例: 総合マーケティング企業のDMP 4 © 2018 primeNumber Inc. CONFIDENTIAL ● 用途 ○ Webブラウザ・スマホアプリ上の行動ログ収集 ○ 生ログを使用した分析 ○ セグメンテーション・広告利用 ● 規模感 ○ 収集ログ量: 100億レコード／月超 ○ ETLジョブ実行回数: 250回／日 ○ Redshiftノード数: 20 nodes (dc2.large)

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

課題3. ETL・DWHの可用性を上げたい 11 ● DWH側が高負荷になるとETLが止まる ○ prestoで重いクエリが実行されるとクラスタ毎落ちる ○ 逆もまた然り ● DWHがボトルネックに ○ ETL後のログは別システムなどで利活用したい ○ prestoを経由する必要があり、ボトルネック ○ HDFSだと取り回しにくい CONFIDENTIAL © 2018 primeNumber Inc.

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● 解決したい課題 ○ 料金・人的コスト最小化 ○ スケーラビリティの確保 ● 解決方法 ○ マネージド・サービスAWS Glueの採用 ■ インフラ面の運用コストほぼ0 ■ 学習コストはコードを書くことのみ ■ 料金は1/4以下に ● 最小構成は月間20万円→5万円に ○ スケーラビリティもLambdaとの統合で解決 Batch Layer実装 18 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 20

Slide 20 text

Slide 21

Slide 21 text

● 解決したい課題 ○ DWH側の障害・メンテの影響がETLに波及しない ○ DWHの処理性能がボトルネックにならない ● 解決方法 ○ ETLの出力先をS3に統一 ■ DWH側の影響はETLに波及しない ○ RedshiftとRedshift Spectrumの併用 ■ 性能面のボトルネックは大きく改善 Serving Layer実装 20 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 22

Slide 22 text

Serving Layer - ETLとDWHの分離 21 CONFIDENTIAL © 2018 primeNumber Inc. ● ETLとDWHを分離するメリット ○ 外的要因による障害が減る ■ DWHの障害・メンテの度に止める必要なくなった ■ 出力先をS3にしたことで、S3が落ちない限りETLは外的要因で落ちない ○ コストメリット ■ 負荷が少ないロードのために、高価なDPUを使わない

Slide 23

Slide 23 text

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が完了したらメッセージ削除

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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上でテーブルとして扱えるように

Slide 26

Slide 26 text

● ETL後のデータの内、一部のフィールドだけRedshiftに取り込みたい ● Redshift Spectrumからは全フィールドが見たい ● AVRO＋COPYコマンドで解決一部の列だけRedshiftにLoad 25 CONFIDENTIAL © 2018 primeNumber Inc. AVRO形式で出力テーブル定義に存在するフィールドだけ取り込まれる Spectrumからは全フィールドが見える Redshift上には必要列だけロードし、容量圧縮

Slide 27

Slide 27 text

Slide 28

Slide 28 text

● ETL後のデータの再利用性もっと上げたい ○ ETLのバージョン違いでデータ形式などもバラバラ ○ 全期間のデータが同じスキーマで揃っていると再利用性が更に高くなる ● Spectrumのパフォーマンス上げたい ○ Parquet形式にしたい（RedshiftのCOPY非対応） ○ S3のパーティションも最適化したい ■ Ex. s3://BUCKET/site_id=123/year=2018/… ● ETL後のデータに対するETLを作成中今後の課題1. データマート化 27 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 29

Slide 29 text

● スモールスタートと実装スピードはGlueの得意とするところだが、もう少しコスト抑えたい ● コードで出来る最適化 ○ RDDを極力使わないなどPySparkのチューニング ○ Scala化の検証 ● Glue以外の選択肢も ○ ログ量が増えたらEMRの方が安かったりするかも？ ○ 便利なDynamicFrameやEC2運用が発生するデメリットを許容できるか、検証中今後の課題2. Jobの高速化 28 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

● ETL処理層はローカル開発 ○ 少量データからDataFrameを作り、それをETLする ○ Jupyter Notebookから実行 ● データアクセス層の開発やE2Eで動かしたい時はDevEndpoint ○ DynamicFrameでデータロードする箇所とか ○ DevEndpointハマりどころ ■ SparkContextを再生成しないとtoDF()が動かない ■ spark.stop() glueContext = GlueContext(SparkContext.getOrCreate()) 開発環境 31 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 33

Slide 33 text

● 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.

Slide 34

Slide 34 text

● Jobの実行結果 ○ CloudWatch Eventを使用し、基本全てSNS通知 ○ SNSはIFTTTに通知し、失敗時のみ通知するよう分岐 ○ ただしJobのステータスがSUCCEEDEDなのにエラー終了しているのを見たことがあるので、ちゃんとやるなら CloudWatch Logsのログでアラート設定すべきかも ● Job実行時間 ○ うまい方法見つけられてない ○ 毎時GlueのAPI叩いてRunningのジョブの実行時間取るとか・・・？ ○ 現状シビアに監視する必要が無いのでやってない監視・障害検知 33 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 35

Slide 35 text

Slide 36

Slide 36 text

● 改行コードを含むデータは正しく認識できない ○ 複数行に分割されてテーブルが作られるので件数合わない ○ Custom Classifierでも対応できないらしい ○ 現状クロール対象のデータを修正するしか無い ● 差分更新的めちゃ遅い ○ 作成済みData Catalogの再クローリング遅い ○ ファイル1つしか増えていなくても、全件クロールと同じくらい時間かかる ○ パーティション追加は手動でやるしか・・・？ Glue Crawlerの注意点 35 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 37

Slide 37 text

● コストが大幅に改善した ○ Hadoopエンジニアに頼らない開発が出来るように ○ 料金も約75%カット ● スケーラビリティ向上 ○ DPUを動的に算出すれば自動でスケール ● S3を出力先にすることで可用性向上 ○ ジョブがコケる外的要因を出来るだけ減らす ○ Data Catalog + Redshift Spectrumで再利用性向上まとめ 36 CONFIDENTIAL © 2018 primeNumber Inc.

Slide 38

Slide 38 text

We are hiring. primeNumberではデータエンジニアリング基盤を一緒に育ててくれる仲間を募集中です