[レポート][TA-03]Amazon Redshift Integration Deep Dive #AWSSummit

2015.06.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2015TA-03: Tech Deep Dive by Amazon:「Amazon Redshift Integration Deep Dive」のレポートです。

スピーカーはAmazon Data Services Japanの八木橋 徹平氏。

ta-03-1

レポート

このセッションの目的

このセッションはRedshiftの使い方がある程度わかっている人に自社システムやAWSの他サービスとの連携方法のコツを知ってもらうことにある。Redshift固有のクセや設定があるため、端的にいうとRedshiftにいかに効率よくデータを入れるためにETL(Extract + Transform + Load) + Uploadを行うか、というセッションである。

Redshiftおさらい

Redshiftの特徴 →MPP(超並列演算)、論理的なリソースの括り「ノードスライス」 →データの格納:列志向(カラムナ)、圧縮処理 データのロード →スロット数と同じ並列度でロードするため、ファイル数はスロット数の倍数が望ましい。 →Amazon EMR, DynamoDB, リモートホストからのロードも可能。 Redshiftのカスタムドライバ →今まではPostgreSqlのドライバが提供されていたが、JDBC4.1/4.0、ODBC3.8をサポートしたオリジナルのドライバの提供が開始。オリジナルなので今までよりパフォーマンス、信頼性がいい。 Interleaved Sort Key →最大8つまでのSort Keyを指定でき、フルスキャンを回避する。

インテグレーション = データ連携

AWSサービス間のデータ連携、オンプレミスとのデータ連携において考慮すべき点 →シングル vs パラレル処理 →同期 vs 非同期実行 →どこでデータ変換をすべきか

S3がハブとなる

CSVファイルは必ずS3に保存する。オンプレミス環境からRedshiftへの直接insertは推奨されない。 大量の同時クライアントの書き込みがある場合 => DynamoDBやKinesisに退避してS3にファイル化、一定間隔でロードする。 AWSネイティブサービスとしては →バッチ処理:Data Pipeline →ストリーム処理:Kinesis →イベント処理:Lambda を駆使してAWSサービス間連携をする。

サンプルシナリオ

今回は

  • 1. RDBMSからデータを抽出(Extract)
  • 2. S3にアップデート(Upload)
  • 3. EMRによるデータ変換(Transform)
  • 4. Redshiftにロード(Load)

というシナリオで考える。

Talendの使用

これらシナリオの実装にフリーのEclipseベースのオープンソースETLツール「Talend」を使用する。

Extract(抽出)

オンプレにあるmysqlからデータを抽出する。抽出形式はCSVファイル。この時点で複数のファイルに分割しておく。一定のレコード数で分割する。ファイル数はスロット数の倍数で。CSVを分割しておくとパラレルにRedahiftに入れられるので効率的。

CDC(Change Data Capture)

差分データをどうやってキャプチャするか。前回抽出分から増えた分は足すだけだが更新された分をどうするか。 →マスターテーブルのレコード数が少ない場合 => 毎回全件を抽出する。 →ソーステーブルにトリガーを設定して差分データを変更テーブルに吐き出しておく。 →RDBMSのトランザクションログを分析して更新ログを抽出できる商用ツールもある。

Extractのポイント

  • 大量のデータを抽出する時はカーソルを使用してメモリの枯渇を防ぐ
  • 抽出・分割後に圧縮を明示的に指定することでS3のアップロード時のコストを削減。
  • ファイルの分割数はスロット数の倍数

Upload

  • データ量やファイル数に応じて並列でアップロードする。時間短縮につながる。
  • アップロードの並列度はクライアントのスペックも考慮する。
  • S3のキーの先頭4文字はランダム文字にするのが理想だが通常は管理しやすい「日付」や「テーブル名」になる。

Transform(変換)

最大のテーマは「どこでTransformするか?

AWSアップロード前のオンプレミス環境 →メリット:アップロード前のクレンジングで転送時間が削減できる →デメリット:オンプレ側にリソースが必要になる

S3のファイルをバッチ変換 <=これが一押し!! →メリット:RedshiftからTransform処理をオフロード →デメリット:Hadoop関連の技術の習得

SQLで一時テーブルに全てつっこみ、そこから本番テーブルに移行する →メリット:Redshift内にて全て完結 →デメリット:Redshiftの負荷がかかる

AWSではEMRにて「データのIn/Out」「変換処理の並列実行」「クラスタの作成・破棄」を簡単に行えるので便利。 ただしAWS CLIからの呼び出しを同期実行するためにはポーリング等の工夫が必要

Load(ロード)

COPYコマンドにはファイルの一覧や正規表現で指定する。単一ファイルの指定だと並列処理にならないので注意。 新規テーブルではデータをロードする時にどの圧縮アルゴリズムを使うか洗濯するのに時間がかかるので明示的に指定すると時間の削減になる。

ロードに失敗したレコードは「stl_load_errors」に格納される。何時何分何秒にデータが入ったか記録されている。「MAXERRORS」オプションで許容できる最大レコード数を指定できる。 insert, update, deleteはリーダーノードを通るのでシリアルな通信になる。insert - selectだと並列に処理が走る。

まとめ

Redshiftはこれからの分析には欠かせないサービスのためできるだけ処理時間を短く単純な仕組みで実装できることが理想です。そのためのキーワードは「Talendで自動化」「EMRで並列変換」かな、と感じました。「並列」を意識して使っていきましょう。