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.

既存Redshift/ETLからSpectrum/Glueへの移行を徹底解明!

633 views

Published on

弊社ではRedshiftの負荷増大に伴いRedshiftSpectrumの導入を行っております。また既存のETL処理の置き換えも実施しており、Glue/Lambda/APIGatewayなど種々のAWSサービスを使用しています。本発表では、弊社の分析基盤の構成とその移行案、さらに移行に関して直面した課題などをより技術的な視点からご紹介いたします。

リクルートライフスタイル 秋本 大樹

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

既存Redshift/ETLからSpectrum/Glueへの移行を徹底解明!

  1. 1. 既存Redshift/ETLから Spectrum/Glueへの移⾏を 徹底解明! 秋本 ⼤樹 ネットビジネス本部 データマネジメントグループ データプラットフォームチーム 1
  2. 2. 秋本 ⼤樹 株式会社 リクルートライフスタイル ネットビジネス本部 データマネジメントグループ データプラットフォームT Facebook: daiki.akimoto.50 2011年 ユーザ系SIerに⼊社 • 客先常駐でインフラ構築のPM • 購買データを⽤いたデータ分析 2014年 ゲーム会社に転職 • ゲームデータ分析基盤の構築 • 社内KPI算出の⾃動化 2017年12⽉より現職 2/38
  3. 3. 3/38 会社紹介
  4. 4. 4/38 保持するデータ
  5. 5. 5/38 HPB HPG JLN 事業データ CSV 外部データ S3 Redshift Redshift (mirror) BigQuery Cloud Storage アクセスログ アプリログ Treasure Data ORACLE Exadata データ分析基盤
  6. 6. 6/38 BigQuery Cloud Storage アプリログ Treasure Data ORACLE Exadata CSV 外部データ S3 Redshift Redshift (mirror) アクセスログ 事業データ HPB HPG JLN 今回はRedshiftにフォーカス
  7. 7. 7/38 実データ容量 約120TB (クラスタは ds2.8xlarge(16TB)*11node=176TB で構成) ユーザアカウント数 1,200 クエリ数 20,000/day テーブル数(データマートも含む) 約4,000 Redshift利⽤状況
  8. 8. ETL処理 JP1によりETL処理を制御しており オンプレDBデータをS3を経由して RedshiftにCOPYしている HPB HPG JLN S3 Redshift JP1により スケジュール実行 データ抽出 COPY .end オンプレサーバ .endファイルを ポーリングし 完了次第COPY EC2 オンプレDB アップロード TSV 8/38
  9. 9. ETL処理の単位 複数テーブルを 事業領域と優先度でグループ化して 毎⽇のロードを⾏なっている。 後続のマート作成で使⽤するものの 優先度を⾼くしている。 HPG 優先度⾼ ロード HPB 優先度⾼ ロード HPG 優先度低 ロード JP1 ロード開始 早朝 夜 ロード開始 HPG マートA 作成 HPG マートC 作成 HPG マートB 作成 HPB 優先度低 ロード HPB マートAʼ 作成 HPB マートCʼ 作成 HPB マートBʼ 作成 … 9/38
  10. 10. マート作成処理 各優先ロードが完了次第 外部DWHからのデータマート抽出、 CTAS等を⽤いたマート作成処理が動く 優先ロードの完了を トリガーにしてJP1から マート作成処理を実行 Redshift オンプレサーバ ORACLE Exadata BigQuery マートデータ 抽出 外部DWHから 抽出したマートデータを 書き込み CTAS等を用いて Redshift内部で マートを作成 マートデータ 抽出 10/38
  11. 11. Redshiftに対する⼀⽇の処理 事業毎に並列して 複数の処理が動き 終⽇Redshiftに対する負荷を 引き上げている HPG 優先度⾼ ロード HPB 優先度⾼ ロード HPG 優先度低 ロード JP1 ロード開始 早朝 夜 ロード開始 HPG マートA 作成 HPG マートC 作成 HPG マートB 作成 HPB 優先度低 ロード HPB マートAʼ 作成 HPB マートCʼ 作成 HPB マートBʼ 作成 … 11/38
  12. 12. Redshiftへの負荷は過⼤ Redshiftへの負荷が⾼く 例えばETL処理は夜23時過ぎまでかかる ETL処理 マート作成処理 ユーザからの アドホック クエリ Redshift 12/38
  13. 13. ⼀時間あたりのコミット数 ⽇中帯のコミット数は⼀時間あたり300を超え また待ち時間も30秒を超えることがある 0 10 20 30 40 50 60 70 80 90 100 0 100 200 300 400 500 600 700 800 6/50 6/56 6/512 6/518 6/60 6/66 6/612 6/618 6/70 6/76 コミット数 コミット平均待ち秒数 秒 13/38
  14. 14. ユーザレスポンス 軽い分析クエリでも 10秒以上かかることがあり 体感的にもかなり遅い 14/38
  15. 15. 退避Redshiftの導⼊ 2013年にRedshift導入 2016年にユーザレスポンス悪化 業務に影響が出始める ユーザクエリとバッチ処理を 一時的に分離する措置が取られる ユーザクエリ実行を一時的に退避する 退避クラスタを構築 (現在はds2.8xlarge(16TB)*6node=96TBで構築) 15/38
  16. 16. 退避Redshiftの仕組み S3 本番 Redshift ⼀⽇⼀回 ロード 退避 Redshift 毎週⼟曜 同期 毎週⼟曜に本番Redshiftの スナップショットを⽤いて 退避Redshiftを作成する 16/38
  17. 17. 退避Redshift S3 本番 Redshift ⼀⽇⼀回 ロード 鮮度を求めないデータに関しては 退避を使うことで ユーザはレスポンスを早くできる 退避 Redshift 毎週⼟曜 同期 本番Redshift (⼀⽇⼀回) 退避Redshift (毎週⼟曜) データの 鮮度 新鮮なデータ 古いデータ 負荷 ⾼い 低い レスポンス 遅い 速い 17/38
  18. 18. Slackによるデータロード 本番Redshift (⼀⽇⼀回) 退避Redshift (毎週⼟曜) データの 鮮度 新鮮なデータ 負荷 ⾼い 低い レスポンス 遅い 速い ユーザがSlackで呟くことで S3を介して新鮮なデータが 退避Redshiftにも⼊る 呟く Slack S3 新鮮なデータ 18/38
  19. 19. 退避Redshiftの課題 • 約100TBのRedshiftを⼀時的な環境として 持ち続けている コスト増 • データが⼀元化されてないことの管理の負担 • 週に⼀度の作り変え作業の負担 運⽤の負担増 • アドホックなクエリはBigQueryで実⾏する ようになっており役割が失われつつある BigQueryとの競合 19/38
  20. 20. よし、 Spectrumを使おう 20/38
  21. 21. 昨年発表されたSpectrum • Redshift上で外部スキーマと外部テーブルを 定義することで使える • 結合処理についてはRedshift本体を⽤いるため 遅くなる傾向がある RedshiftからS3に直接クエリ • 他のRedshiftクラスタからも参照可能 GlueCatalogによる⼀元管理 • 1TBのS3読み出しあたり5ドルかかる クエリ課⾦ 21/38
  22. 22. マート作成に⽤いるテーブルは 結合処理に多く⽤いるために Spectrumを使⽤せずに本体に持つ Spectrumの導⼊(本番) HPB HPG JLN S3 本番Redshift JP1により スケジュール実行 データ抽出 優先度高のみ COPY オンプレサーバオンプレDB アップロード TSV or Parquet マートは作成後 UNLOAD 優先度低テーブルは Spectrum参照 22/38
  23. 23. 全てのテーブルがS3に配置されるので 検証クラスタからは 全テーブルをSpectrum参照する Spectrumの導⼊(検証) HPB HPG JLN S3 検証Redshift JP1により スケジュール実行 データ抽出 全テーブルを Spectrum参照 オンプレサーバオンプレDB アップロード TSV or Parquet 23/38
  24. 24. ETL負荷の変化推測 Spectrum参照により COPYに関するコミットが減るので ETL処理による負荷は半分になるはず 事業側DBより テーブルデータ抽出 S3にアップロード RedshiftにCOPY Spectrumテーブルの S3Pathを付け替えるのみ 約2000テーブル 優先度低 約1000テーブル 優先度⾼ 約1000テーブル 24/38
  25. 25. Spectrum化に伴う⽅針 • コミット数を減らし負荷を下げる 負荷を下げる • 数年前に書かれたものであり変更が困難 • ETLの失敗による業務影響が⼤きい 既存のETL処理への影響を 最⼩限にする • ETL処理が23時まで及んでおりスケジュール での実⾏が困難 イベントドリブンな データパイプラインの構築 25/38
  26. 26. Spectrum実践上の課題1 Aginityで外部スキーマが認識されないので Late Binding Viewを⽤いて 通常スキーマから参照可能にしている 26/38
  27. 27. Spectrum実践上の課題2 schema.table コミットを減らすつもりだったのに Redshift上でS3Pathを付け替えようとすると なぜかコミットも⾛る schema.table 27/38
  28. 28. Spectrum実践上の課題2 直接GlueCatalogを修正する APIを書くことでRedshiftを経由せずに S3Pathを変更しコミット数を削減 変更後のPathを Spectrum参照 オンプレサーバ アップロード TSV or Parquet Redshift S3 Glue Catalog Lambda API Gateway S3Pathとテーブル名で CURL GlueAPIを⽤いて Catalogを変更 28/38
  29. 29. Spectrum実践上の課題3 COPYコマンドでは NULL AS句でNULL⽂字の指定ができたが SpectrumではNULL⽂字の指定ができない Redshift本体ではNULL AS ʻ<NL>ʼ とすることでNULLと認識される Spectrumでは単なる⽂字列として 解釈されてしまう NULLにするためにはʼ¥Nʼを ⽤いる必要がある 29/38
  30. 30. Spectrum実践上の課題3 抽出されたtsvがS3に置かれた時点で Lambdaを発⽕し ⽂字列を置き換える変換を加えて 再配置する S3 Redshift .end オンプレサーバ アップロード TSV Lambda TSV LambdaでTSVの⽂字列を置き換え .end StepFunction 全てのTSVに対する変換が完了したら endファイルを配置する Spectrum参照 30/38
  31. 31. Spectrum実践上の課題4 SpectrumのBestPracticeとして S3上のデータをParquetにするのが良いと ⾔われているが 気軽にParquetに変換できるツールが無い Batch Lambda EMR Glue いずれかにてParquet変換を⾏いたい TSV S3 Parquet S3 31/38
  32. 32. 仮にGlueで変換すると GlueCatalogからDynamicFrameを 作成することで わずか2⾏でシンプルに変換することができる Glue 32/38
  33. 33. 仮にGlueで変換すると 最低課⾦が10分からとなっており 仮に2000テーブルを1ヶ⽉間変換すると $0.44(DPU*h) * 2DPU * 1/6h * 2000tbl * 30days = $8,800(約100万) 最低でも約100万かかる ※DPU(DataProcessingUnit) Glueのコンピュータリソースの単位 ・ ・ ・ ・ ・ ・ イベントドリブンで設計すると 1テーブルにつき1ジョブが⾛る Glue S3 33/38
  34. 34. Spectrum実践上の課題4 良い点 悪い点 実装が簡単(4⾏で書ける) 最低10分課⾦になっておりコスト がとても⾼い(サイズの⼩さいも のでも10分間のコスト) コストが安い 使い慣れている Parquet変換を⾃前で実装 サイズが⼤きいとLambdaのリソー スに収まらない 使い慣れていない ロードが23時まで及ぶので常時起 動させなければならずコストが⾼ い 使い慣れている Parquet変換を⾃前で実装 ジョブ間のオーバーヘッドが⼤き いBatch Lambda EMR Glue 34/38
  35. 35. Spectrum実践上の課題4 ファイルサイズが⼤きいテーブルは Glueを⽤いてSpectrum化させ それ以外のテーブルは 直接TSVで⾒せるようにする オンプレサーバ アップロード TSV Redshift S3 GlueJob Lambda Parquet 小さいサイズのものは TSVで参照 大きいサイズのものは Parquetで参照 ファイルサイズを判定し GlueにてParquetに変換 35/38
  36. 36. Spectrum/Glueを⽤いた 最終的な構成案 36/38 オンプレサーバ アップロード TSV 本番Redshift S3 GlueJob Lambda Parquet TSV 検証RedshiftNULL文字変換 Parquet変換 優先度高テーブルのみ COPY 小さいテーブルは TSVでSpectrum参照 大きいテーブルは ParquetでSpectrum参照 Spectrum参照
  37. 37. まとめ • NULL⽂字の変換をS3上でかける必要あり • ⼿軽にParquetに変換できるツールがない Spectrumの導⼊には課題も多い • 直接S3Pathを書き換えることでRedshiftへの 負荷を下げられる • GlueCatalogで⼀元管理されるため他クラスタ でも容易に参照可能 負荷の低減とデータの可搬性には ⼤きな効果あり 37/38
  38. 38. 38/38 http://engineer.recruit-lifestyle.co.jp/recruiting/ ⼤募集!! ⼀緒に分析基盤を作ろう!

×