AWS認定Big Data勉強記 - 6: Amazon Redshift

こんにちは、えいりんぐーです。

今回はRedshiftについてまとめます。

####  Q: Amazon Redshift とは何ですか?

Amazon Redshift は高速で完全マネージド型のデータウェアハウスです。標準 SQL および既存のビジネスインテリジェンス (BI) ツールを使用して、すべてのデータをシンプルかつコスト効率よく分析できます。洗練されたクエリ最適化、列指向ストレージ、高パフォーマンスのローカルディスク、および超並列クエリ実行を使用して、ペタバイト単位の構造化データに対して複雑な分析クエリを実行できます。

#### 参考資料
基本的に以下の資料をもとにしています。

 - Black Belt資料
    - [Redshift 2016](https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-redshift)
    - [Redshift Update & Spectrum 2017](https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-amazon-redshift-update)
    - [Redshiftテーブル設計ガイド](https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-amazon-redshift)
    - [Redshift Update 2019](https://www.slideshare.net/AmazonWebServicesJapan/20190122-aws-black-belt-online-seminar-amazon-redshift-update)
 - ドキュメント
    - [Redshiftとは?](https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/welcome.html)
    - [Redshiftのベストプラクティス](https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/best-practices.html)
 - [よくある質問](https://aws.amazon.com/jp/redshift/faqs/)
 - AWSブログ
    - [Amazon Redshiftを使用した高性能ETL処理のベストプラクティス Top 8](https://aws.amazon.com/jp/blogs/news/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/)
    - [Amazon Redshift Spectrum 10 のベストプラクティス](https://aws.amazon.com/jp/blogs/news/10-best-practices-for-amazon-redshift-spectrum/)

#### 仕組み
 - クラスター
    - リーダーノード
        - コンピュートノードの管理
        - クライアントとのやりとり
        - クエリの最適化
    - コンピュートノード
        - データの保存
        - クエリの実行
 - 超並列処理: Massive Parallel Processing
    - 1つのタスクを複数のノードで分散して実行する
    - ノードの追加でスケールアウト
 - シェアードナッシング
    - ディスクをノードで共有しない
    - ノードの増加に対して、ディスクがボトルネックにならない
 - 列指向型のデータ保管
 - データの圧縮
    - 圧縮アルゴリズムは列ごとに指定できる
 - ゾーンマップ
    - ブロック単位でデータを格納
    - ブロック内の最小値と最大値をメモリに保存

###### ノードタイプ

Dense Compute (dc2): 費用対効果が良い
Dense Storage (ds2): ストレージあたりの費用が低い

|タイプ|CPU|メモリ|ストレージ|スライス|ノード数|価格|リサイズ幅|
|---|---|---|---|---|---|---|---|
|dc2.large|2|15|0.16TB SSD|2|1~32|$0.314/h|1/2倍と2倍のみ|
|dc2.8xlarge|32|244|2.56TB SSD|16|2~128|$6.095/h|同上|
|ds2.xlarge|4|31|2TB HDD|2|1~32|$1.190/h|1/2倍から2倍の間で任意の値|
|ds2.8xlarge|36|244|16TB HDD|16|2~128|$9.520/h|同上|

* 価格に関しては2019年1月時点

#### データ保護
 - クライアントとRedshiftの通信をSSLで暗号化可能
 - 保管中もAES-256で暗号化する
    - Redshift管理の鍵だけでなく、顧客管理のHSMや、AWS KMSの利用も可能
 - データウェアハウスの自動バックアップがデフォルトで有効
    - 保存は1日。35日まで変更できる
 - AZが機能停止したら、クラスターも使用不可能になる
    - スナップショットから他のAZに復元は可能
- Redshift自体のマルチAZは現在非対応

#### パフォーマンスの最適化

 - ディスクIOの削減
    - 適切なデータ型
    - データ圧縮
        - LZOが多くのケースで有効
        - `ANALYZE COMPRESSION` コマンドで推奨を確認できる
    - アクセス範囲の制限
        - SORTKEYによってデータが順に格納される
            - 頻繁に範囲・等式検索される列に有効
        - Interleaved Sort Key
            - 複数の列をソートキーに指定できる
            - 複数のキーがAND条件で検索される時などに有効
    - データの平準化
        - ノードのデータサイズを均一にする
 - データ転送の最小化
    - データ分布の選択
        - EVEN: 均一に分散。基本はこれ
        - KEY: 同じキーを同じ場所に。カーディナリティが高いと有効
        - ALL: 全ノードにデータをコピー
    - コロケーション
        - ジョインされやすい列をDISTKEYに設定する
        - ALLでテーブルを作成する

###### 運用
 - S3にデータを置く
 - COPYコマンドでロードする
    - エンコーディングが定義されていなければ自動で圧縮
    - IAMロールの利用が可能
    - gzip, bzip2, lzo, zstdで圧縮すると効率化
    - ファイル分割で効率化
 - Analyze & Vacuumで効率化
    - テーブルの統計情報はクエリプランの決定に使われる
    - `ANALYZE` コマンドで統計情報を最新に保つ
        - PREDICATE COLUMNSオプションを使うことで、WHERE句に使われた列だけを対象とすることができる
    - Redshiftのデータは追記型
        - 削除がマークされるだけでディスク上はデータが残る
    - `VACUUM` コマンドで不要領域を削除（コンパクション）する
    - `ANALYZE`と`VACUUM`はバックグラウンドスケジュール実行できる
 - `ALTER TABLE APPEND`
    - ソース表をターゲット表に移動する
    - `CREATE TABLE AS` や `INSERT INTO` よりも高速
        - `CREATE TEMP TABLE`ではDIST KEYやSORT KEYを指定できるので、ロードを速くできる
 - バックアップ
    - ディスクイメージをS3へバックアップする
    - 他リージョンへの作成可能
    - KMS暗号化済みのスナップショット転送にも対応
 - データの抽出
    - 大量のデータをファイル抽出したい時は `UNLOAD` を使用する
    - `ENCRYPTED` オプションで抽出データを暗号化できる

###### データのロード
S3以外のデータソースからもデータをインポートできる。

 - DynamoDB
 - EMR
 - Glue
 - Data Pipeline

#### ポイント
**Elastic Resize**
クラスターをオンデマンドで迅速に伸縮する。

**Workload Management (WLM)**
実行時間の長いクエリはクラスタ全体のボトルネックになるので、WLM毎にクエリ並列度の上限を設けたキューを定義する。キューで並列度を保証する。リソース競合の可能性は残る。concurrency や memory to use のように Redshift を再起動せずに変更できるパラメータと、 user groups や query groups のように再起動が必要なパラメータがある。

**Data Migration Service**
ターゲットとして Redshift が対応可能。

**Query Monitoring Rules (QMR)**
WLMの拡張で、クエリに関するルールを作成して、違反したクエリに対してアクションを実行する。ルール: CPU使用率・ジョイン対象行数など。アクション: LOG/ABORTなど。

**CTASにおける自動圧縮**
2017年のアップデートで、CTASで作成される表の列は全てLZOで圧縮される（例外あり）。

**UDF User Logging**
RedshiftはPythonでUDFを作成できる。loggerに出力したエラーログを自動的にRedshiftに蓄積できる。

**Enhanced VPC Routing**
VPC-S3間のCOPY/UNLOADの通信ルートを調整するための機能。メリット: S3への通信を特定のVPCエンドポイントまたはゲートウェイ経由に強制できる。

**ショートクエリアクセラレーション (SQA)**
機械学習によってクエリの実行時間を予測。ショートクエリと判断されたクエリは専用のキューにルーティング。リソースを動的に確保。

**リザルトキャッシュ**
リーダーノード内のキャッシュにクエリ結果が含まれている場合、コンピュートノードで処理をせずに返却。

#### その他

###### 向き
 - データウェアハウス
    - 数百GB ~ PB
 - OLAP
    - 複雑だが同時実行数の少ないSQL
    - 頻繁でないデータ更新
 - 構造データ

###### 不向き
 - 同時実行数の多いSQL
    - RDSが良い
 - 低レイテンシー
    - RDSかElastiCache
 - ランダム・パラレルなアクセス
    - RDSかDynamoDB
 - データを格納するが集計はしない
    - RDSやDynamoDB

###### EMRとの使い分け
RedshiftもHadoopもクラスター上に作成されるが、その使い分けとは

 - EMR
    - データが非構造な時
    - Hive, Spark, Prestoなどが使いたい時
    - 機械学習・データ変換・ストリーミング処理をしたい時
 - Redshift
    - 構造的な大規模データを扱う時
    - SQLだけが使えればいい時