Upload
takahiro-ikeuchi
View
3.845
Download
0
Embed Size (px)
DESCRIPTION
AWS Redshiftのデータロードを中心とした デザインパターンを紹介します。 ちなみにデザインパターンというほどではなくツールの 解説みたいなものです。。 - awscli syncパターン - fluentdリレーパターン - fluentdダイレクトパターン - Glacierアーカイブパターン - アンチパターン
Citation preview
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処理周りのパターンを予定
おわり