Prochain SlideShare
AWS Redshift デザインパターン データロード編
- 1. AWS Redshift デザインパターン データロード編 @iktakahiro 2013-10-05 Amazon Redshift
- 2. 自己紹介 •株式会社ALBERT •分析力をコアとする マーケティングソリューションカンパニー •池内 孝啓 / システム開発部 部長 •@iktakahiro
- 3. Agenda •Redshiftへのデータロード周りの デザインパターンを紹介します
- 4. Agenda •awscli syncパターン •fluentdリレーパターン •fluentdダイレクトパターン •Glacierアーカイブパターン •アンチパターン
- 5. AWS CLI 編
- 6. AWS Command Line Interface •公式コマンドラインツール •pip install awscli •EC2, S3, Redshift... など各サービスの 操作、管理ができる http://aws.amazon.com/jp/cli/
- 7. awscli syncパターン Redshift ログデータ S3EC2 sync [ec2-user@hoge ]# awscli s3 sync ./ s3://hoge-bucket/log
- 8. •日次、週次処理でまとまってデータを 処理する •ログデータの定期的な取り込みなど •対象のファイルが多数ある場合 awscli syncパターン Use Case
- 9. •rsyncの要領でローカルディレクトリと S3を同期できる •awscliが実行できればプラットフォームを 問わない（オンプレミスでもOK） •後続の処理の実行タイミングを制御し易い awscli syncパターン メリット
- 10. •ローカルサーバーが複数ある場合、 設計・管理が煩雑になる •障害時のリトライなどは自力で実装 •Redshiftへのロードは別で用意 awscli syncパターン デメリット
- 11. 補足 : 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コマンドで接続するのも宜し
- 12. fluentd 編
- 13. fluentd •言わずとしれたログ収集ツール •プラグインの開発が活発 http://fluentd.org
- 14. fluentdリレーパターン RedshiftS3 EC2 plugin : s3_alternative (https://github.com/studio3104/fluent-plugin-s3-alternative) tail-ex EC2
- 15. 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>
- 16. •既にfluendを利用してデータを RDBへ取り込んでいる •Webサーバーから出力されるログを バッチ処理で利用している •処理対象のサーバーが複数台ある fluentdリレーパターン Use Case
- 17. •プラグインを導入するだけで簡単に使える •サーバー台数が複数あっても比較的容易 •日付でディレクトリを分割するなど、 S3上のディレクトリ整理もできる •リトライ機構がfluentd側にある fluentdリレーパターン メリット
- 18. •fluentd未導入の場合は導入・学習コストが 発生する •S3側のディレクトリ構造の設計を入念に 行う必要がある •(注意点として)fluentdが長時間死なないよう に監視しておく •Redshiftへのロードは別で用意 fluentdリレーパターン デメリット
- 19. fluentdダイレクト パターン Redshift S3 EC2 plugin : redshift (https://github.com/hapyrus/fluent-plugin-redshift) EC2 ※ 内部的にはS3を経由している
- 20. •fluentd S3中継パターンとほぼ同じ •とにかく手間をかけず、ストリーム出力される テキストデータをRedshiftに投入したい fluentdダイレクトパターン Use Case
- 21. •fluentd S3中継パターンとほぼ同じ •Redshiftへのロードまで一括で行って くれる fluentdダイレクトパターン メリット
- 22. •(デメリットではないが) S3にアップして RedshiftのCOPY文を発行している実装 ということは覚えておく •設定次第で頻繁にロードが走ることになる のでタイミングや参照性能の低下などに注意 fluentdダイレクトパターン デメリット
- 23. 番外 編
- 24. Glacierアーカイブパターン RedshiftS3 EC2 EC2 Glacier
- 25. Glacierアーカイブパターン
- 26. •S3の費用を安く済ませたい •利用済みのデータの処遇が決まっていない のでとりあえず保持しておきたい Glacierアーカイブパターン Use Case
- 27. •Glacierへの以降はS3の設定で完結 •低コストでデータを運用できる •S3 <-> Glacierの関係性なので他のどの デザインパターンにも適応可 Glacierアーカイブパターン メリット
- 28. •再利用したくなったときにはGlacierから S3へ差し戻さないとロードできない Glacierアーカイブパターン デメリット
- 29. アンチパターン 編
- 30. アンチパターン : INSERT LOOP RedshiftEC2 INSERT INTO INSERT INTO INSERT INTO
- 31. アンチパターン : INSERT LOOP •よほど少量でない限り行うべきではない •Redshiftへの連続アクセスはコストが高い •複数レコードをINSERTしたい場合は BULK INSERTを選択 •データ量が多い場合は、テキスト出力してから awscli syncパターンの適応も検討
- 32. 補足 : 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のオプティマイザが働かない点に注意
- 33. 今回はここまで
- 34. 次回はETL処理周りのパターンを 予定
- 35. おわり
Identifiez-vous pour voir les commentaires