AWS Redshift デザインパターンデータロード編

@iktakahiro2013-10-05

AmazonRedshift

自己紹介

•株式会社ALBERT•分析力をコアとする　マーケティングソリューションカンパニー

•池内 孝啓 / システム開発部 部長•@iktakahiro

Agenda

•Redshiftへのデータロード周りのデザインパターンを紹介します

Agenda

•awscli syncパターン•fluentdリレーパターン•fluentdダイレクトパターン•Glacierアーカイブパターン•アンチパターン

AWS CLI編

AWS Command Line Interface

•公式コマンドラインツール•pip install awscli•EC2, S3, Redshift... など各サービスの操作、管理ができる

http://aws.amazon.com/jp/cli/

awscli syncパターン

Redshift

ログデータ

S3EC2

sync

[ec2-user@hoge ]# awscli s3 sync ./ s3://hoge-bucket/log

•日次、週次処理でまとまってデータを処理する

•ログデータの定期的な取り込みなど•対象のファイルが多数ある場合

awscli syncパターン Use Case

• rsyncの要領でローカルディレクトリとS3を同期できる

• awscliが実行できればプラットフォームを問わない（オンプレミスでもOK）

•後続の処理の実行タイミングを制御し易い

awscli syncパターン メリット

•ローカルサーバーが複数ある場合、設計・管理が煩雑になる

•障害時のリトライなどは自力で実装•Redshiftへのロードは別で用意

awscli syncパターン デメリット

補足 : Redshift COPY

COPY hoge_table FROM 'S3://hoge-bucket/2013/10/15/' CREDENTIALS 'aws_access_key_id=hogehoge;aws_secret_access_key=hogehoge'DELIMITER '\t' TIMEFORMAT 'YYYY-MM-DD HH:MM:SS' GZIP;

COPYを実行してS3のデータをロードする

PostgreSQLのドライバで接続(Java, Python, Ruby...)psqlコマンドで接続するのも宜し

fluentd編

fluentd

•言わずとしれたログ収集ツール•プラグインの開発が活発

http://fluentd.org

fluentdリレーパターン

RedshiftS3

EC2

plugin : s3_alternative (https://github.com/studio3104/fluent-plugin-s3-alternative)

tail-ex

EC2

fluentdリレーパターン<source> type tail_ex format /^(?<url>.*)\t(?<userid>.*)\t(?<sessionid>.*)\t(?<date>.*)$/ path /var/log/nginx/accesslog_%Y-%m-%d_%H.log tag acceslog.${hostname} pos_file /var/log/td-agent/accesslog.pos refresh_interval 60</source><match accesslog.**> type foresta subtype s3 <template> aws_key_id hogekey aws_sec_key hogehogekey s3_bucket hoeg s3_endpoint s3-ap-northeast-1.amazonaws.com path log/ buffer_path /var/log/td-agent/buffer/${tag} time_slice_format accesslog/%Y/%Y-%m/%Y-%m-%d/${hostname}_ accesslog_%Y-%m-%d_%H.log retry_wait 30s retry_limit 5 flush_interval 600s flush_at_shutdown true </template></match>

•既にfluendを利用してデータをRDBへ取り込んでいる

•Webサーバーから出力されるログをバッチ処理で利用している

•処理対象のサーバーが複数台ある

fluentdリレーパターン Use Case

•プラグインを導入するだけで簡単に使える•サーバー台数が複数あっても比較的容易•日付でディレクトリを分割するなど、S3上のディレクトリ整理もできる

•リトライ機構がfluentd側にある

fluentdリレーパターン メリット

• fluentd未導入の場合は導入・学習コストが発生する

• S3側のディレクトリ構造の設計を入念に行う必要がある

• (注意点として)fluentdが長時間死なないように監視しておく

•Redshiftへのロードは別で用意

fluentdリレーパターン デメリット

fluentdダイレクト パターン

Redshift

S3EC2

plugin : redshift (https://github.com/hapyrus/fluent-plugin-redshift)

EC2 ※ 内部的にはS3を経由している

• fluentd S3中継パターンとほぼ同じ•とにかく手間をかけず、ストリーム出力されるテキストデータをRedshiftに投入したい

fluentdダイレクトパターン Use Case

• fluentd S3中継パターンとほぼ同じ•Redshiftへのロードまで一括で行ってくれる

fluentdダイレクトパターン メリット

• (デメリットではないが) S3にアップしてRedshiftのCOPY文を発行している実装ということは覚えておく

•設定次第で頻繁にロードが走ることになるのでタイミングや参照性能の低下などに注意

fluentdダイレクトパターン デメリット

番外編

Glacierアーカイブパターン

RedshiftS3

EC2

EC2

Glacier

Glacierアーカイブパターン

• S3の費用を安く済ませたい•利用済みのデータの処遇が決まっていないのでとりあえず保持しておきたい

Glacierアーカイブパターン Use Case

•Glacierへの以降はS3の設定で完結•低コストでデータを運用できる• S3 <-> Glacierの関係性なので他のどのデザインパターンにも適応可

Glacierアーカイブパターン メリット

•再利用したくなったときにはGlacierからS3へ差し戻さないとロードできない

Glacierアーカイブパターン デメリット

アンチパターン編

アンチパターン : INSERT LOOP

RedshiftEC2

INSERT INTOINSERT INTOINSERT INTO

アンチパターン : INSERT LOOP

•よほど少量でない限り行うべきではない•Redshiftへの連続アクセスはコストが高い•複数レコードをINSERTしたい場合はBULK INSERTを選択

•データ量が多い場合は、テキスト出力してからawscli syncパターンの適応も検討

補足 : Redshift BULK INSERT

INSERT INTO access_log (user_id, date_time)VALUES ('hoge1', '2013-08-10 00:00:00'), ('hoge2', '2013-08-10 00:00:00'), ('hoge3', '2013-08-10 00:00:00');

BULK INSERTが利用できる

※ COPY文と違い初回ロード時のCompression Encodingsのオプティマイザが働かない点に注意

今回はここまで

次回はETL処理周りのパターンを予定

おわり