[AWS] Amazon Redshiftまとめ

# Amazon Redshiftとは

- 高速、スケーラブルで費用対効果の高いDWHおよびデー誰行く分析マネージドサービス

> 参考：https://d1.awsstatic.com/webinars/jp/pdf/services/20200318_AWS_BlackBelt_Redshift.pdf


# ユースケース

> 主に大容量データを高速に集計・分析する必要があるワークロードに利用

- 経営ダッシュボード
- 定型レポーティング
- アドホック分析
- ELT/バッチ
- 機械学習の前処理

## Amazon Redshiftを中心としたデータ分析パイプライン

![amazon_redshift-データパイプライン.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/1bb17548-4eb3-d2db-2518-a88aeb2853eb.jpeg)

# アーキテクチャ（RA3インスタンス）

- ベースは **PostgreSQL** でDWH用に拡張している
- AWSの他のサービスコンポーネントを活用したマネージドサービスとなっている


![amazon_redshift-アーキテクチャ.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/74890e40-af92-550e-bbad-ead4edfe2bdf.jpeg)

- コンピュートとストレージを分離しスケーリングと支払を独立
- データは永続ストレージとしてS3、キャッシュとしてローカルSSDに格納
- アクセス頻度の高いデータはキャッシュにとどまり、アクセス頻度の低いデータはキャッシュアウト

## クエリ実行

1. リーダーノードがクライアントからのクエリを受け取る
2. リーダーノードがSQLをコンパイルしてコンピュートノードへ配信する
3. コンピュートノード上で処理を並列実行しリーダーノードへ結果を返す<br>該当データがキャッシュ上にない場合はマネージドストレージからブロック単位で読み込む
4. リーダーノードがクライアントへ結果を返す

## データロードとアンロード

- データはユーザ管理のS3を経由してロード&アンロード

# 特徴

- ハイパフォーマンス
    - DWH、分析向けに特化した**RDB**
    - 様々な種類の分析ワークロードについて、より迅速な洞察を取得可能
- スケーラブル
    - ベタバイト級までスケールアウト
    - 分析要求やデータ容量が増加しても、動的にスケールアップ/アウトが可能
- データレイクへの拡張
    - データレイク上のデータへ直接アクセス
    - Amazon S3上のオープンフォーマットデータをそのまま分析可能
- 高いコスト効果
    - 初期費用なし、小規模からはじめて利用に応じた支払が可能

## ハイパフォーマンス

- 列指向ストレージ
- データ圧縮
- ソートキー
- データ分散


### 列指向ストレージ

- データは列ごとに格納
    - 必要な列のみの読み取りが可能に
- 大容量データへのアクセスが必要となる分析クエリのボトルネックとなるディスクIOを削減

#### 列指向、行指向の違い

- `select min(datetime) from users` の検索による違い
    - 列指向の場合は `datetime` 列のみをスキャンしソート、不要なスキャンを削減
    - 行指向の場合は、 全てのデータをスキャンしソート

### データ圧縮

- 列の圧縮を行うことで一度のディスクアクセスで読み込めるデータ量が多くなり速度の向上が見込める
- 圧縮のエンコードが13個用意されている、 `CREATE TABLE` で列毎の設定が可能
- `ANALYZE COMPRESSION` コマンドを利用して既存テーブルの各列に最適な圧縮を確認することが可能
- コンドードタイプを変更したいときにテーブル再作成 & `INSERT-SELECT` で対応
- 列、すなわち類似データなので高い圧縮率となる

#### 圧縮エンコードの自動割当

- エンコードが未指定の列には自動的割当される

| タイプ | エンコード |
| :---: | :---: |
| ソートキー | RAW圧縮
| BOOLEAN、REAL、DOUBLE PRECISION | RAW圧縮 |
| SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIMESTAMP | AZ64圧縮 |
| CHAR、VARCHAR | LZO圧縮 |

### ソートキー

#### 1MBブロックサイズ

- Redshift は通常RDBMSよりも大きい `1MB` でブロックサイズを確保する
    - 通常は `8KB ~ 32KB` ていど
    - こによりディスクIOを効率化

#### ゾーンマップ（ブロックフィルタリング）

- 1MBブロックのメタデータをリーダーノードのメモリ上に格納
- 各ブロックの `最大値` `最大値` を保持
- クエリの内容に応じて処理に不要なブロックを読み飛ばすよう効率的なアクセスを実現

#### ソートキーとは

- ゾーンマップ機能を活用してI/Oを削減
- クエリパフォーマンス向上にはソートキーが非常に重要
- データをどの列順にソートするかテーブルごとにソートキーとして指定
    - **頻繁に使われる絞り込み（WHERE句）条件キーが筆頭候補**
    - 一般的には日付などの時系列やIDが多い
    - 実際のクエリパターンと処理優先度などから決定
- データは指定のソートキーで事前に並び替えらディスク上に保持される
    - この分ディスク容量を必要とする？

### データ分散

- データ量やクエリの内容に応じて分散形式を選択

| 形式 | 内容 |
| :---: | :---: |
| KEY | 同じキーを同じスライスへ |
| ALL | 全てのデータを全ノードへ | 
| EVEN | ラウンドロビンで均等分散 | 
| AUTO | テーブルサイズに応じてALL -> EVENに自動変換（デフォルト設定） | 

![amazon_redshift-分散.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/42be0328-0f13-f61f-4a22-3136e686ccc4.jpeg)

### クエリキャッシュ

- リーダーノードにてクエリ結果をキャッシュしている
    - キャッシュ機能はデフォルトで有効

### マテリアライズドビューを設定することでさらなる高速化

- 頻繁に実行するクエリパターンを高速化
    - 結合、フィルタ、射影、集計
- RTL/BIパイプラインの簡素化
    - 差分リフレッシュ
    - ユーザーによるメンテナンス
- Redshiftへのより簡単で迅速な移行

## フルマネージド

### 構築・運用の手間を削減

- 1画面の設定のみで起動
- ノード数やタイプはあとから変更可能
- 自動バックアップ
- モニタリング機能
- 自動パッチ適用
    - メンテナンスウィンドウでパッチ適用時間帯を指定可能
- スケジューリング機能
    - クラスターサイズの変更
    - クラスターの一時停止と再開

### 機械学習ベースの自動最適化によるクエリ性能の向上

- テーブルメンテナスの自動化
    - テーブルの分散スタイルの自動最適化
    - 統計情報の自動更新
    - データの再編成の自動実行
- 自動ワークロード管理とクエリ優先度で効率的に処理
- ショートクエリアクセラレーション（SQA）による高速化
- 動的に変更可能なリコメンデーションの提案

## 拡張性・柔軟性

### コンピュートノードの追加

- コンピュートノードの追加でパフォーマンスがリニアに向上する
- マネージメントコンソールから数クリックで拡張・縮小が可能

![amazon_redshift-拡張・縮小.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/dbf758b2-aae0-d0c4-91e6-bf33bac4e985.jpeg)

### 数分でクラスターの伸縮を実現する Elastic Resize

- 既存のRedshiftクラスター上にノードを追加
- 繁忙期にクエリを高速に処理
- データ転送にかかる時間を最小化
- コンピュートとストレージをオンデマンドでスケール
- スケジュール設定可能

### ピーク時にコンピュートを自動拡張する Concurrency Scaling

- [参考:AWSブログ](https://aws.amazon.com/jp/blogs/news/new-concurrency-scaling-for-amazon-redshift-peak-performance-at-all-times/)

## データレイクとAWSサービスとの親和性

### Redshift Spectrum でアーキテクチャをデータレイクに拡大

- 事前のデータロード不要でS3上のデータに対して直接SQLを実行
- RedshiftとS3それぞれに存在するデータを結合可能
- オープンファイルフォーマット対応
    - Parquet、ORC、JSON、Grok、Avro、CSV

![amazon_redshift-Spectrum.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/59a81ef9-5c77-60e4-d6c1-e54f76536ddc.jpeg)

### RA3 と Redshift Spectrum との違い・使い分け

<img width="1002" alt="スクリーンショット 2020-04-06 13.43.36.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/97615/78fa32d7-99b5-0c50-3cd2-fe9a1bc430f2.png">

> 出典：https://d1.awsstatic.com/webinars/jp/pdf/services/20200318_AWS_BlackBelt_Redshift.pdf

#### 使い分け

| 用途 | 選択 | 
| :---: | :---: |
| 全てのデータがデータレイクにありRedshiftだけでなく他のサービスからのアクセスされる場合 | Amazon Redshift Spectrum |
| Redshift内のデータ抑制に過去データを削除したりS3にデータをオフロードしたりでSpectrumを活用していた場合 | RA3ストレージ | 

### データレイクエクスポート

- RedshiftテーブルデータをAmazonS3上へParquet形式でエクスポート可能
- Redshift SpectrumにとどまらずAmazon AthenaやAmazon EMRなど他の分析サービスでもすぐに活用可能

### フェデレーテッドクエリ（2020年4月6日時点：Preview）

- RDS/Aurora PostgreSQLに直接クエリできる機能
    - PostgreSQLに対してのみ
- データ移動なしにライブデータを分析
- データウェアハウス、データレイク、オペレーショナルデータベースのデータを統合して分析
- 高い性能でセキュアにデータアクセス

## 高いコスト効果

- インスタンス起動時間 + ストレージ使用量（RA3のみ）
- コンピュートノード数 * 1時間あたり価格
- RIにも対応
- [AWS公式:料金表](https://aws.amazon.com/jp/redshift/pricing/)

### その他の関連料金

- Concurrency Scaling
    - 各追加クラスターでのクエリ実行時間に応じて課金される（秒単位）
    - 1日あたり1時間の無料クレジットが付与される（最大30時間分貯蓄可能）
- Redshift Spectrum
    - S3データレイクへのクエリ容量で課金
    - S3の圧縮済データ１TBスキャンあたり「$5」

## セキュリティ＆コンプライアンス

### ビルドインされたセキュリティ機能

- エンドツーエンドの暗号化
- データ保管時の暗号化可能
- ネットワーク分離のためのAmazon VPC
- 拡張されたVPCルーティング
- 監視ロギングとAWS CloudTrail統合
- 多くの認定及び準拠
    - SOC 1/2/3
    - PCI-DSS
    - FedRAMP
    - HIPAA

### アクセスコントロール

- テーブル、データベース、スキーマ、関数、プロシージャ、言語、また列に対してのアクセスコントロールが可能
- テーブル、ビューに対して列ごとにアクセスコントロールが可能
    - GRANT/REVOKEコマンドで設定可能
    - テーブルの場合
        - 列レベルでSELECT/UPDATEの権限付与可能
    - ビューの場合
        - 列レベルでSELECTの権限付与可能

# クラスター

- [ドキュメント](https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/welcome.html)

## クラスターの作成と管理

- 小規模からはじめて簡単に拡張可能
- サービス停止なくコンピュートノードを増やすことが可能