Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
AWS Redshift デザインパターン データロード編 @iktakahiro 2013-10-05 Amazon Redshift
自己紹介 •株式会社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.co...
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_...
fluentd 編
fluentd •言わずとしれたログ収集ツール •プラグインの開発が活発 http://fluentd.org
fluentdリレーパターン RedshiftS3 EC2 plugin : s3_alternative (https://github.com/studio3104/fluent-plugin-s3-alternative) tail-ex E...
fluentdリレーパターン <source> type tail_ex format /^(?<url>.*)t(?<userid>.*)t(?<sessionid>.*)t(?<date>.*)$/ path /var/log/nginx/a...
•既にfluendを利用してデータを RDBへ取り込んでいる •Webサーバーから出力されるログを バッチ処理で利用している •処理対象のサーバーが複数台ある fluentdリレーパターン Use Case
•プラグインを導入するだけで簡単に使える •サーバー台数が複数あっても比較的容易 •日付でディレクトリを分割するなど、 S3上のディレクトリ整理もできる •リトライ機構がfluentd側にある fluentdリレーパターン メリット
•fluentd未導入の場合は導入・学習コストが 発生する •S3側のディレクトリ構造の設計を入念に 行う必要がある •(注意点として)fluentdが長時間死なないよう に監視しておく •Redshiftへのロードは別で用意 fluentdリレーパ...
fluentdダイレクト パターン Redshift S3 EC2 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 INTO INSERT INTO INSERT INTO
アンチパターン : INSERT LOOP •よほど少量でない限り行うべきではない •Redshiftへの連続アクセスはコストが高い •複数レコードをINSERTしたい場合は BULK INSERTを選択 •データ量が多い場合は、テキスト出力し...
補足 : Redshift BULK INSERT INSERT INTO access_log (user_id, date_time) VALUES ('hoge1', '2013-08-10 00:00:00'), ('hoge2', '...
今回はここまで
次回はETL処理周りのパターンを 予定
おわり
Upcoming SlideShare
Loading in …5
×

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

8,877 views

Published on

AWS Redshiftのデータロードを中心とした
デザインパターンを紹介します。

ちなみにデザインパターンというほどではなくツールの
解説みたいなものです。。

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

Published in: Technology
no profile picture user

  • Login to see the comments

Show More

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

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

×