既存Redshift/ETLからSpectrum/Glueへの移行を徹底解明！
0 likes2,138 views
弊社ではRedshiftの負荷増大に伴いRedshiftSpectrumの導入を行っております。また既存のETL処理の置き換えも実施しており、Glue/Lambda/APIGatewayなど種々のAWSサービスを使用しています。本発表では、弊社の分析基盤の構成とその移行案、さらに移行に関して直面した課題などをより技術的な視点からご紹介いたします。 リクルートライフスタイル 秋本 大樹
既存Redshift/ETLからSpectrum/Glueへの移行を徹底解明！
- 2. 秋本 ⼤樹 株式会社 リクルートライフスタイル ネットビジネス本部 データマネジメントグループ データプラットフォームT Facebook: daiki.akimoto.50 2011年 ユーザ系SIerに⼊社 • 客先常駐でインフラ構築のPM • 購買データを⽤いたデータ分析 2014年 ゲーム会社に転職 • ゲームデータ分析基盤の構築 • 社内KPI算出の⾃動化 2017年12⽉より現職 2/38
- 3. 3/38 会社紹介
- 4. 4/38 保持するデータ
- 5. 5/38 HPB HPG JLN 事業データ CSV 外部データ S3 Redshift Redshift (mirror) BigQuery Cloud Storage アクセスログ アプリログ Treasure Data ORACLE Exadata データ分析基盤
- 6. 6/38 BigQuery Cloud Storage アプリログ Treasure Data ORACLE Exadata CSV 外部データ S3 Redshift Redshift (mirror) アクセスログ 事業データ HPB HPG JLN 今回はRedshiftにフォーカス
- 12. Redshiftへの負荷は過⼤ Redshiftへの負荷が⾼く 例えばETL処理は夜23時過ぎまでかかる ETL処理 マート作成処理 ユーザからの アドホック クエリ Redshift 12/38
- 17. 退避Redshift S3 本番 Redshift ⼀⽇⼀回 ロード 鮮度を求めないデータに関しては 退避を使うことで ユーザはレスポンスを早くできる 退避 Redshift 毎週⼟曜 同期 本番Redshift (⼀⽇⼀回) 退避Redshift (毎週⼟曜) データの 鮮度 新鮮なデータ 古いデータ 負荷 ⾼い 低い レスポンス 遅い 速い 17/38
- 18. Slackによるデータロード 本番Redshift (⼀⽇⼀回) 退避Redshift (毎週⼟曜) データの 鮮度 新鮮なデータ 負荷 ⾼い 低い レスポンス 遅い 速い ユーザがSlackで呟くことで S3を介して新鮮なデータが 退避Redshiftにも⼊る 呟く Slack S3 新鮮なデータ 18/38
- 19. 退避Redshiftの課題 • 約100TBのRedshiftを⼀時的な環境として 持ち続けている コスト増 • データが⼀元化されてないことの管理の負担 • 週に⼀度の作り変え作業の負担 運⽤の負担増 • アドホックなクエリはBigQueryで実⾏する ようになっており役割が失われつつある BigQueryとの競合 19/38
- 21. 昨年発表されたSpectrum • Redshift上で外部スキーマと外部テーブルを 定義することで使える • 結合処理についてはRedshift本体を⽤いるため 遅くなる傾向がある RedshiftからS3に直接クエリ • 他のRedshiftクラスタからも参照可能 GlueCatalogによる⼀元管理 • 1TBのS3読み出しあたり5ドルかかる クエリ課⾦ 21/38
- 25. Spectrum化に伴う⽅針 • コミット数を減らし負荷を下げる 負荷を下げる • 数年前に書かれたものであり変更が困難 • ETLの失敗による業務影響が⼤きい 既存のETL処理への影響を 最⼩限にする • ETL処理が23時まで及んでおりスケジュール での実⾏が困難 イベントドリブンな データパイプラインの構築 25/38
- 29. Spectrum実践上の課題3 COPYコマンドでは NULL AS句でNULL⽂字の指定ができたが SpectrumではNULL⽂字の指定ができない Redshift本体ではNULL AS ʻ<NL>ʼ とすることでNULLと認識される Spectrumでは単なる⽂字列として 解釈されてしまう NULLにするためにはʼ¥Nʼを ⽤いる必要がある 29/38
- 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. Spectrum実践上の課題4 良い点 悪い点 実装が簡単(4⾏で書ける) 最低10分課⾦になっておりコスト がとても⾼い(サイズの⼩さいも のでも10分間のコスト) コストが安い 使い慣れている Parquet変換を⾃前で実装 サイズが⼤きいとLambdaのリソー スに収まらない 使い慣れていない ロードが23時まで及ぶので常時起 動させなければならずコストが⾼ い 使い慣れている Parquet変換を⾃前で実装 ジョブ間のオーバーヘッドが⼤き いBatch Lambda EMR Glue 34/38
- 37. まとめ • NULL⽂字の変換をS3上でかける必要あり • ⼿軽にParquetに変換できるツールがない Spectrumの導⼊には課題も多い • 直接S3Pathを書き換えることでRedshiftへの 負荷を下げられる • GlueCatalogで⼀元管理されるため他クラスタ でも容易に参照可能 負荷の低減とデータの可搬性には ⼤きな効果あり 37/38