Amazon Redshiftの開発者が
これだけは知っておきたい10のTIPS
第18回 AWS User Group – Japan 東京勉強会
Hapyrus Inc. 藤川幸一 @fujibee
まずは初級
1. Redshift (Data Warehouse) は通常の
RDB (MySQL, Oracleなど)と違う!
»データの持ち方がカラム毎に独立
»1行取ってくるのも数秒かかる
»その代わり大規模データの join / group
by...
2. Table設計はパフォーマンスに大きな
影響がある
»distkeyはjoin時のキー (1個だけしか設定
できない)
»sortkeyはwhere句の条件カラム (400個設
定できる)
• timestampが第一候補
• distk...
3. カラムナーデータの圧縮は大事
»適切な圧縮エンコードによってクエリ
スピードが大きく変わる
• 圧縮エンコーディングを自動的に適用する
にはテーブル作成直後に10万行程度ロード
する
• 以後は“ANALYZE COMPRESSION” ...
4. データロードとクエリ実行はどうする
の?
» データロード
• insert文はとても遅い
• copyコマンドによるバルクロード
• S3かdynamodbにデータをアップロードしてcopyコ
マンドで投入
» クエリ実行は Postg...
中級のちょっとしたネタ
5. RedshiftでのSQL的制約
»primary keyやunique制約は文法的には存
在するが、実際には制約として機能し
ない
• クエリオプティマイズに内部的に使われる
のみ
»not null制約は実際に機能する
6. UTF-8の一部マルチバイト文字コー
ドが利用できない
»以前は4バイト文字がNGだった
• 多国語環境では頻繁にエラーが起きた
» 現在は5バイト以上がNG
»最近(8月末あたり)copyコマンドで
ACCEPTINVCHARSというオ...
上級・実際に使っている人向け
7. リサイズあれこれ
» 操作はAWS consoleから数クリック
• XLの数を増やすことも、8XLクラスタにすること
も可能
» 最初にread onlyになり、数時間後、数分read
も不可になって利用可能に
» 内部的には別クラスタ...
8. Redshiftの主要な制限
» PostgreSQLベースだが関数は半分くらいしか使えな
い
• 主にパフォーマンスに影響する関数がNG
» データタイプもプリミティブなもののみ
• INT系、FLOAT系、Boolean、Char、V...
9. copyコマンドのオプティマイズ
» 一度に処理するデータ量が多ければ多い
ほどスループットは大きい
• 1 copyコマンドで処理されるファイルは分割す
るべし
• 1インスタンスのクラスタ(XLノード)でも効果
あり
– 1インスタン...
10. FlyDataを使おう!
» 今までの内容が全て考慮されたRedshift向
け全自動データインテグレーション(ETL)
サービス
» 大量データ(200GB/day)でもロードパフォーマン
ス最適化
» エラーハンドリングもバッチリ=...
See Also: 技術評論社サイトgihyo.jpにて技術連載
Hapyrusでは「カスタマーサクセス」エンジ
ニアを
募集しています!Wantedlyにて!
ありがとうございました!
Hapyrus は Amazon Redshift のデータインテグレーションパートナーです。
Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan
Upcoming SlideShare
Loading in...5
×

Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan

9,528

Published on

Published in: Technology
0 Comments
33 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,528
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
90
Comments
0
Likes
33
Embeds 0
No embeds

No notes for slide

Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan

  1. 1. Amazon Redshiftの開発者が これだけは知っておきたい10のTIPS 第18回 AWS User Group – Japan 東京勉強会 Hapyrus Inc. 藤川幸一 @fujibee
  2. 2. まずは初級
  3. 3. 1. Redshift (Data Warehouse) は通常の RDB (MySQL, Oracleなど)と違う! »データの持ち方がカラム毎に独立 »1行取ってくるのも数秒かかる »その代わり大規模データの join / group by / sort が異常に早い • Hadoop/Hiveはこの辺りがかなり苦手(つ まり遅い・難しい)
  4. 4. 2. Table設計はパフォーマンスに大きな 影響がある »distkeyはjoin時のキー (1個だけしか設定 できない) »sortkeyはwhere句の条件カラム (400個設 定できる) • timestampが第一候補 • distkey, sortkey, は後から変更できない »変更にはテーブル/カラム作り直しが必 要
  5. 5. 3. カラムナーデータの圧縮は大事 »適切な圧縮エンコードによってクエリ スピードが大きく変わる • 圧縮エンコーディングを自動的に適用する にはテーブル作成直後に10万行程度ロード する • 以後は“ANALYZE COMPRESSION” コマンドで 適切なエンコーディングがわかる »圧縮エンコーディングは後から変更で きない
  6. 6. 4. データロードとクエリ実行はどうする の? » データロード • insert文はとても遅い • copyコマンドによるバルクロード • S3かdynamodbにデータをアップロードしてcopyコ マンドで投入 » クエリ実行は PostgreSQL と同等! • psqlやpg gemなど既存ツールがそのまま使える • JDBC/ODBCアクセスも可能 » unloadというコマンドでデータをS3にexport できる
  7. 7. 中級のちょっとしたネタ
  8. 8. 5. RedshiftでのSQL的制約 »primary keyやunique制約は文法的には存 在するが、実際には制約として機能し ない • クエリオプティマイズに内部的に使われる のみ »not null制約は実際に機能する
  9. 9. 6. UTF-8の一部マルチバイト文字コー ドが利用できない »以前は4バイト文字がNGだった • 多国語環境では頻繁にエラーが起きた » 現在は5バイト以上がNG »最近(8月末あたり)copyコマンドで ACCEPTINVCHARSというオプションを指 定すると利用できない文字を置換でき るようになった
  10. 10. 上級・実際に使っている人向け
  11. 11. 7. リサイズあれこれ » 操作はAWS consoleから数クリック • XLの数を増やすことも、8XLクラスタにすること も可能 » 最初にread onlyになり、数時間後、数分read も不可になって利用可能に » 内部的には別クラスタを立ち上げてデータを マイグレート、DNSを切り替えている » データ量が多い、複雑なテーブル構造等があ るとリサイズは時間がかかる事が多い • snapshotからの復元のほうが早いこともある
  12. 12. 8. Redshiftの主要な制限 » PostgreSQLベースだが関数は半分くらいしか使えな い • 主にパフォーマンスに影響する関数がNG » データタイプもプリミティブなもののみ • INT系、FLOAT系、Boolean、Char、Varchar、Date、Timestamp » 1テーブルにつきバルクロード系操作は同時に1つ しかできない • copyやselect insertクエリはテーブルごとに2個め以降キュー イングされる » 最大コネクション数は95 = 複数サーバからのcopy コマンドがキューイングされるとすぐいっぱいに なる » TimestampはTimezoneをサポートしていない。UTC で格納し、アプリ側でハンドルした方が良い » 8XLインスタンスは最低2インスタンスから
  13. 13. 9. copyコマンドのオプティマイズ » 一度に処理するデータ量が多ければ多い ほどスループットは大きい • 1 copyコマンドで処理されるファイルは分割す るべし • 1インスタンスのクラスタ(XLノード)でも効果 あり – 1インスタンスは複数のスライスで構成されてい るので • 少なくともインスタンス数分は分割したほう が良い » クラスタのインスタンスが多ければ多い ほどパフォーマンスが向上 » クラスタサイズによってデータ量・分割 数をチューニングするとよい
  14. 14. 10. FlyDataを使おう! » 今までの内容が全て考慮されたRedshift向 け全自動データインテグレーション(ETL) サービス » 大量データ(200GB/day)でもロードパフォーマン ス最適化 » エラーハンドリングもバッチリ=開発・ 運用コスト削減 » apache logや JSONフォーマットも対応
  15. 15. See Also: 技術評論社サイトgihyo.jpにて技術連載
  16. 16. Hapyrusでは「カスタマーサクセス」エンジ ニアを 募集しています!Wantedlyにて!
  17. 17. ありがとうございました! Hapyrus は Amazon Redshift のデータインテグレーションパートナーです。
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×