BigData JAWS #22 論⽂から垣間⾒るRedshiftの進化と深化 2022/12/19 データアナリティクス事業本部 ⽯川 覚

⾃⼰紹介 2 名前︓⽯川 覚（いしかわ さとる） 所属︓データアナリティクス事業本部 インテグレーション部 コンサルティングチーム 担当︓コンサルタント、ブログ・登壇等 経歴︓メーカーでSE、研究開発 →ITベンチャーで製品開発、受託研究 →クラスメソッド（2014/6〜） 好きなサービス︓Amazon Redshift/Athena、Google BigQuery 2022 ALL Certified & APN AWS Top Engineers Sapporo

論⽂「Amazon Redshift re-invented」 3 2022年5⽉に発表された論⽂ 「Amazon Redshift re-invented」に対して、最新 のre:Invent2022のBreakout Session 「10 years of innovation in integration, data sharing & more」の内容も加味して、Redshiftの進化と深化についてご紹介 します︕ 参考：Amazon Redshift: Ten years of continuous reinvention 参考：Amazon Redshift re-invented 参考：AWS re:Invent 2022 - [NEW] Amazon Redshift: 10 yrs of integration & data sharing innovation (ANT345) Rahul Pathakさん Ippokratis Pandisさん

Amazon Redshift の 進化の歴史とこれから 4 Redshift Serverlessが発表される前（2021年3⽉）の資料なので、ちょっと前の 資料ですが、進化の歴史が良くまとまっており、論⽂を読む前に⽬を通しておくと 理解がはかどるのでおすすめです。 参考：Amazon Redshift の 進化の歴史とこれから/redshift-evolution-2021

アジェンダ 5 1. INTRODUCTION 2. PERFORMANCE THAT MATTERS 3. SCALING STORAGE 4. SCALING COMPUTE 5. AUTOMATED TUNING AND OPERATIONS 6. USING THE BEST TOOL FOR THE JOB 7. CONCLUSION

1. INTRODUCTION

Redshift開発の4つの重点ポイント 7 2013年の Redshift の発表以来エクサバイト単位のデータを処理し、 他社のイノベーションを刺激しており、Redshift は 4つのニーズを満た すことに重点を置いている 1. 複雑な分析クエリのパフォーマンスをアップさせるため、コード⽣成による各 Queryフラグメントのデータベースオペレータをブレンドするクエリ実⾏でパ フォーマンスを上げ、プリフェッチ、ベクトル化実⾏などで効率を上げている。 2. より多くのデータ、ユーザーに拡張するために、ストレージとコンピュートを分 離してエラスティックにスケール可能にした。 3. 簡易化のために機械学習ベースの⾃律制御（オートノミクス）を取り⼊れ、ワー クロード管理、物理的チューニング、マテリアライズドビューのリフレッシュ、 マテビューを使⽤するクエリの書き換え処理を⾃動化した。 4. AWS のサービスと統合するため、DynamoDB、Aurora、S3、SageMakerとク エリ連携。Glue Elastic Views でDynamoDB や OpenSearch のデータをマテ ビュー化。半構造データもサポートする。

補⾜︓Redshiftの成り⽴ち 8 元々 ParAccel社が開発したコモディティハードウェアで動作するデー タウェアハウスのソフトウェアをAWSがソースとライセンスを購⼊、 AWS上のインフラに展開したのが始まり。 サービス開始時のSQLを書き換えることなく、現在でも動作する⾼い互 換性を維持している。 ⼀⽅、現在のアーキテクチャは、クラウドネイティブなデータウェアハ ウスに正常進化を遂げ、全く別物になっている。 参考：RDBMS_Genealogy_V6

2. PERFORMANCE THAT MATTERS

System Architecture 10 Amazon Redshift︓列指向の超並列処理（MPP）型のデータウェアハ ウスです。Redshiftクラスタは、1つのコーディネータであるリーダー ノードと、複数のコンピュートノードで構成されている。

System Architecture 11 Redshift Managed Storage︓S3上のRedshift Managed Storage （RMS）に保存され、コンピュートノードではローカルに取り付けられ たSSDに圧縮された列指向のフォーマットでキャッシュされる。

System Architecture 12 Concurrency Scaling︓より多くの処理能⼒を必要とする状況におい て、動的にスケールアウトし、何百もの同時実⾏クエリに対して⼀貫し て⾼速なパフォーマンスを提供できる。

System Architecture 13 AQUA︓FPGAを活⽤してパフォーマンスを向上させるクエリアクセラ レーションレイヤーです。

System Architecture 14 Compilation-As-A-Service︓Redshiftフリートで実⾏されるさまざ まなクエリフラグメントに対して最適化された⽣成コードをキャッシュ するマイクロサービスです。

System Architecture 15 Data Sharing︓Redshiftクラスタ間で、読み取り⽬的のライブデータ を安全かつ容易に共有することができる。

System Architecture 16 参考︓Redshift Serverless • ノードの代わりにRPU（Redshift Processing Unit）という単位に応じてコン ピューティングが割り当てられ、インテリジェントに⾃動スケールする 参考︓[レポート] (New Launch) Introducing Amazon Redshift Serverless

Query Flow 17 ①リーダーノードは、クエリを受信 ②クエリを受信すると、Parser、Rewrite、Optimaizerを順に実⾏ ③コストベースのオプティマイザが、最適なプランを選択 ④実⾏計画⽴案後は、クエリの実⾏を制御は、ワークロード管理（WLM）が担う ⑤カラムナデータは、ローカルに接続されたSSDからスキャンされるか、S3上の RMSから読み込まれる

Redshift のコード⽣成 18 Redshiftは、⼤量のデータに対する複雑なクエリの⾼速実⾏に重点を置 いた分析⽤データベースです。 • Redshiftはスキーマとクエリプランに対応するC++コードを⽣成する • ⽣成されたC++コードはコンパイルされてコンピュートノードに転送される • コンパイルされたファイルは segment と呼ばれる • segment は step と呼ばれるオペレーターのパイプラインで構成される • segment と step は物理クエリプラン (physical query plan) の⼀部である • segment の最後の step だけがパイプラインを終了できる

Redshift のコード⽣成（擬似コード例） 19 単純なスキャン→結合→集約クエリについて、単⼀ノードクラスタ上で ⽣成されたC++コードの⾼レベルの例を⽰す。 SELECT sum(R.val) FROM R, S WHERE R.key = S.key AND R.val < 50; • ベーステーブルRのスキャン（3〜6⾏⽬） • フィルタの適⽤（8⾏⽬） • Sのハッシュテーブルのプローブ（10⾏⽬） • 集約sum()の計算（13⾏⽬） ⽣成されたコードは、作業セットを可能な限り CPUに近づけて性能を最⼤化するという原則に 従っている。（標準的なVolcano execution modelとは対照的） 参考：Volcano-styleの処理と問題点

Vectorized Scans 20 Vectorized Scansは、カラムナデータの⼀般的な⾼速化技法 • ベクトル化されたコンパイル済みスキャン関数は、すべてのデータ型とエンコー ディングおよび圧縮スキームをカバーしており、この層の出⼒は、述語から修飾 されたタプルの列値を、下流のステップからアクセスされるスタック上のローカ ル配列に格納する。 • 1マシンサイクルで複数の列を処理できるSIMD命令によるスキャンコードの⾼速 化に加え、レジスタの圧迫やコンパイルすべきインラインコードの量を減らし、 広いテーブルに対する特定のクエリのコンパイルを桁違いに⾼速化することに成 功している。 • スキャンステップではタプルのチャンクをカラム単位で実⾏し、結合と集約ス テップではダウンストリームでタプル単位で実⾏します。 • カラム毎に処理されるチャンクのサイズは、アクセスされるカラムの総幅とス レッドプライベート（L2）CPUキャッシュのサイズに基づいて、コード⽣成時に 動的に決定されます。

Reducing Memory Stalls with Prefetching 21 プリフェッチを使⽤してキャッシュミスによって発⽣するストール（前 の処理が終わるまで次の処理が待たされること）を緩和する • Redshiftのパイプライン実⾏は、中間カラム値をCPUレジスタに保持することで、 結合と集約の外側ストリームに対する中間結果の実体化を回避している • ハッシュテーブルが⼤きすぎてCPUキャッシュに収まらない場合、Redshiftは キャッシュミスのオーバーヘッドを完全に負担することになる • パーティションのハッシュテーブルがCPUキャッシュに収まるまで⼊⼒をパー ティション化し、キャッシュミスを回避する • キャッシュミスは実⾏エンジン設計に固有の特性であるため、プリフェッチを使 ⽤して失速を緩和する • ハッシュテーブルまたはブルームフィルタの各プローブをプリフェッチ命令でイ ンターリーブします。

Inline Expression Functions 22 基本的な操作にはインライン関数を利⽤して、処理の⾼速化をしている • 基本操作の例: • ⽂字列⽐較、ハッシュ化 • インライン関数 • メイン処理に直接関数の処理内容が展開される • 通常の関数がメインの処理とは異なるメモリ上に保存され、関数呼び出しのた びにオーバーヘッドが発⽣するのに対して、インライン関数ではそれが発⽣し ない

Compilation Service 23 Compilation Serviceとは、クエリ実⾏に使⽤される最適化された C++コードをオブジェクトファイルにコンパイルするサービス • 同⼀または類似のクエリを実⾏する場合、コンパイル済みのセグメントのキャッ シュを再利⽤することで、コンパイルのオーバーヘッドがなく、実⾏時間が短縮 する • 最初のクエリーセグメントのコンパイルは、追加のレイテンシーを発⽣する • 多数のセグメントをコンパイルする必要がある場合に、クラスタリソースの競合 のため、遅延が発⽣することもある • Compilation Serviceは、Redshiftクラスタを超えて計算資源とメモリ資源を使 ⽤し、スケーラブルで安全なアーキテクチャによってクエリのコンパイルを⾼速 化します。 • Compilation Serviceは、クラスタ外の外部コードキャッシュに、コンパイルし たオブジェクトをキャッシュし、同じクエリセグメントを必要とする複数のコン ピュートクラスタにサービスを提供します

CPU-Friendly Encoding 24 カラムをディスクに保存する時の圧縮⽅式はLZOやZSTDなどの汎⽤圧 縮アルゴリズムに加え数値や⽇付/時刻型に適したAZ64アルゴリズムで ⾼い圧縮率と解凍速度を両⽴させた。

Adaptive Execution 25 実⾏エンジンは、実⾏統計に基づいて⽣成されたコードや実⾏時のプロ パティを動的に変更し、パフォーマンスを⾼めるための実⾏時決定を⾏ う。 • ⼤量データのJOINが発⽣すると • コンピュートノード間のデータ転送 => ネットワーク ボトルネック • メモリ不⾜のためにページアウトの発⽣ => I/O ボトルネック • ハッシュテーブルに存在しないキーを除外し、これらを抑制したい • Bloom Filter(BF)を使い、JOIN不要な⾏(データ)を除外

AQUA for Amazon Redshift 26 Advanced Query Accelerator（AQUA）は、Redshift Managed Storageのオフクラスターキャッシング層および複雑なスキャンと集計 のプッシュダウンアクセラレータのマルチテナントサービス。

AQUA for Amazon Redshift 27 • クラスタ外部のReshiftのストレージとの中間に 位置するキャッシュレイヤーとして機能する • AQUAはReshiftクラスタのローカルSSDのホッ トデータをキャッシュする • S3のようなリージョナルサービスからの データ取得のレイテンシーを減らす • コンピュートノードのキャッシュストレージ にデータをロードする機会を減らす • ネットワークボトルネックを意識させないよう に、AQUAはストレージではなく関数としての インタフェースを提供する • Nitro ASICによる暗号化処理のハードウェアア クセラレーション

Query Rewriting Framework 28 DSLベースの新しい Query Rewriting Framework（QRF）を備え ており、これは２つの⽬的に対応しています。 • クエリの書き換えや最適化 • 結合、接合、集約の実⾏順序を最適化する書き換えルールの導⼊に利⽤ • サブクエリをブルートフォースで繰り返し実⾏するよりも、⼤規模な結合の⽅ が実⾏モデルのメリットが⼤きいので、クエリのデコレーション時にも利⽤ • マテリアライズド・ビューを使ったクエリの書き換え • QRFによるクエリ書き換えは、問い合わせ表現（ASTまたは代数）の⼀部を マッチングして抽出するパターンマッチャーと、パターンマッチャーによって 抽出された部分を⽤いて新しい問い合わせ表現を作成するジェネレータのペア として簡単に表現できる。概念がシンプルなため、数⽇で⾮相関の書き換えを 開発できた • さらに、Redshiftが⼊れ⼦や半構造化データ処理に関わる書き換えを導⼊する ことを可能にし、マテリアライズドビューの適⽤範囲を広げた

3. SCALING STORAGE

Redshift Managed Storage 30 RMSは、ユーザーデータとトランザクションメタデータの両⽅を管理し、 AWS Nitro Systemの上に構築されています。 • RMSは、ベアメタルと区別でき ない⾼帯域幅のネットワーキン グとパフォーマンスを備えてい る • Redshiftは、ワークロードのパ ターンと、⾃動的なきめ細かい データ退避やインテリジェント なデータプリフェッチなどの技 術を活⽤し、ローカルSSDのパ フォーマンスを実現しながら、 S3にストレージを⾃動的にス ケーリングする

Redshift Managed Storage 31 • トランザクションは、RMSによってS3に同期的にコミット、複数のクラスター がライブでトランザクション的に⼀貫性のあるデータにアクセスできる • 状態は1つのクラスターによって所有および管理されますが、並⾏リーダーとラ イターはRMS上でコンピューティングスケーリングを提供します • オンデマンドでスピンアップされる並⾏クラスターは、スナップショットアイソ レーションに依存し、クエリ要求に対応するためにデータのオンデマンドフェッ チを優先します

Decoupling Metadata from Data 32 データからメタデータを分離すると、ElasticResizeとクロスインスタ ンスリストアが可能になる。 • どちらの機能も、メタデータを1つのクラスター構成から別のクラスター構成に シャッフルするため、メタデータをデータから分離すると、効率的な実装につな がる可能性がある • Elastic Resizeを使⽤すると、ノードを追加してパフォーマンスを向上できる • クロスインスタンスリストアを使⽤すると、ユーザーは、あるインスタンスタイ プのクラスターから取得したスナップショットを、異なるインスタンスタイプま たは異なる数のノードのクラスターに復元できる • ElasticResizeとクロスインスタンスリストアは、Elastic Resizeテクノロジーを 活⽤して、数分で移⾏を提供します。

Expand Beyond Local Capacity 33 S3を使⽤してクラスターのストレージ容量を拡張し、ローカルメモリ とSSDをキャッシュとして利⽤することで、スケーラビリティを強化 • セクションでは2つのコンポーネント︓階層型ストレージキャッシュとダイナ ミックディスクキャッシュ • RMSは、階層型ストレージキャッシュを使⽤して、クラスターの再構成（Elastic Resize、クラスターの復元、ハードウェア障害など）後にローカルSSDにデータ をキャッシュします。アクセスされる可能性が最も⾼いデータブロックでローカ ルディスクをキャッシュする • Redshiftは階層型ストレージキャッシュの上にダイナミックディスクキャッシュ を利⽤して、メモリ内の最もホットなブロックを維持する • さらに、ディスクキャッシュは、新しいデータブロックやクエリ固有の⼀時ブ ロックなど、クエリによって作成された他のブロックを保持する

Incremental Commits 34 S3をプライマリストレージとして使⽤するには、データのフットプリ ントとコストを削減するために増分コミットが必要 • RMSは変更されたデータだけを検知し、ログを反映 • 差分更新⽅式（旧型）:redirect-on-write protocol • 変更のあったブロックをまるごと新規に書き込み、ポインターを付け替える • 差分更新⽅式（新型）:log-based commit protocol • このログはLog-structured file systemのことAurora なども採⽤ • インメモリ構造と永続構造で処理を分ける • 永続構造のスーパーブロックでは、単にログを記録するだけ • ランダムI/OではなくシーケンシャルI/Oのため、コミット・パフォーマンス40％向上 • メタデータはグローバルに分散、耐久性・可⽤性のため複数AZ/リージョンにまたぎ、メ タデータはAWSグローバルインフラで共有・リレーできる • ログ構造メタデータが特に有効なのは、並列スケーリング、データ共有でトランザクショ ンの⼀貫したデータが必要 • 新しいログをローカルスーパーブロックに適⽤→ソースデータと同期

Concurrency Control 35 Redshiftはマルチバージョン同時実⾏制御（MVCC）を実装している • Readerはブロックしないし、ブロックもされない。 • Writerは他のWriterにブロックされる場合がある。 • トランザクション開始時のスナップショットを参照可能。 • Redshiftは serializable 分離レベルを強制しているのでロストアップデートや read/writeのスキューが発⽣しない。 • RedshiftのドキュメントではMVCCという単語では紹介されていない • 以前はトランザクションの依存性管理をグラフベースの仕組みで⾏っていた。 • この⽅法は同時に実⾏されている個々のトランザクションの状態を保持してお く必要があった。

Concurrency Control 36 （続き） • スナップショット分離の certifier (証明者) として Serial Safety Net (SSN) ベー スのデザインを採⽤した。 • 前回コミット時からのサマリー情報を保持するだけで良くメモリ効率が向上 • SSNは Serializable Snapshot Isolation (SSI) のようなアルゴリズムと⽐べ ても性能がよい。 • SSNベースのアルゴリズムに最適化と拡張を加えた。 • 以前利⽤していた certifier と互換性を持つようにした。 • オリジナルのSSNはコミット時にabort検出していたのを処理中にも検出す るようにした。 • 古いデザインと⽐べてリソースの消費量がかなり減った。特にメモリは ワークロードにもよるが最⼤で8GB下がった。

4. SCALING COMPUTE

Cluster Size Scaling 38 Elastic Resizeにより、お客様は現在のコンピュートニーズに応じて、 クラスターからコンピュートノードを迅速に追加または削除することが できる • サイズ変更後、移動したデータ・パーティションはオンデマンドのリクエストと ホットデータを優先して、バックグラウンドでS3からローカルストレージに読み 込む • データパーティションの再割り当てのため、Elastic Resize後のノードあたりの データパーティション数は、リサイズされていないRedshiftクラスタのものと異 なる

Concurrency Scaling 39 同時実⾏スケーリングは、単⼀のRedshiftクラスターが提供できるより も多くの同時実⾏性を必要とする場合に、Redshiftを動的にスケールア ウトできる • 1つのクラスタではクエリを同時実⾏できないと きにクラスタの追加が⾏われる • クラスタ内ノードではなく、既存とは別のクラ スタが追加される • キューに溜まっているクエリは追加されたクラス タにルーティングされる • ユーザ側は考慮不要。気にせず既存クラスタの エンドポイント宛にクエリを投げてOK • 新たに追加されたクラスタはRMSからデータを取 得する

Compute Isolation 40 Redshift Data Sharing を⽤いたコンピュートの分離 • RA3インスタンスで利⽤可能 • RA3インスタンスではストレージが分離されている • コンシューマクラスタ側が必要なコンピューティングリソースを使⽤する • コンシューマ側で書き込みもできる • オブジェクト 「datashare」に共有したいスキーマ、表などを追加する

5. AUTOMATED TUNING AND OPERATIONS

Automatic Table Optimizations 42 テーブルの分散キーやソートキーなど、ワークロードのパフォーマンス 最適化の⾃動化 • Automatic Table Optimization(ATO)がキーの選出・適⽤を⾃動化 • ワークロードの解析・推薦の流れ • 最適化されたクエリープラン、カーディナリティー、predicate selectivitiesといったメタデータを定期的に収集し、推奨値を⽣成 • 期待される効果も予測し、効果の⾼いもののみを推薦 Automatic Table Optimization(ATO)が順次⾃動適⽤ され、35時間後にはパフォーマンス が改善

Automatic Workload Management 43 Redshiftの⾃動ワークロード管理（AutoWLM）は、アドミッションコ ントロール、スケジューリング、およびリソース割り当てを担当 • クエリの受け⼊れはクエリの同時実⾏に様々な影響を与える。 • 受け⼊れを少なくしすぎるとキューイングされたクエリの待ち時間が増加し、CPUやメモリなどのリソー スが無駄になる。 • 受け⼊れを増やしすぎるとキューイングされたクエリ数は減るがリソースがサチる。 • 例えばクエリ毎のメモリが少なすぎる場合ディスクに書き込むことになり、クエリの待ち時間が増え る。 • Redshiftは必要なリソースが異なるワークロードの変化が頻繁に起こるような使われ⽅をしている。 • レスポンスタイムとスループットを向上するため機械学習を利⽤している。具体的には必要なリソー スと同時実⾏するクエリ数を予測している。 • Automatic Workload Manager (AutoWLM) はクエリの受け⼊れ管理、スケジューリング、リソース割当を 担当している • AutoWLMは実⾏プランとオプティマイザーによる統計情報を特徴ベクトルに変換する。特徴ベクトルは 実⾏時間、メモリ使⽤量、コンパイル時間などのメトリクスを予測するため機械学習モデルに利⽤される。 クエリはこれらの特徴に基づいて実⾏キュー内の位置を⾒つける。 • Redshiftは実⾏時間の予測を⻑い時間のクエリより短い時間のクエリを⼿前にスケジューリングするため に利⽤している。

Query Predictor Framework 44 RedshiftのQuery Predictor Framework による AutoWLMは、クエリ のメモリ消費量と実⾏時間を予測するための機械学習モデル • Query predictor frameworkとは、機械学習を⽤いてリソースを最適化するフ レームワークのこと • AutoWLMは、各Redshiftクラスタ内にquery predictor frameworkを持つ • クエリのメモリ消費量と実⾏時間を予測するのにXGBOOSTによる推論を実施し ている • そうすることで変化するワークロードに迅速に対応できる • コードコンパイルのサブシステムも、query predictor frameworkを利⽤して最 適化コンパイルとデバッグコンパイルのどちらかを選択してクエリ全体の応答時 間を向上させている。

Materialized Views 45 マテリアライズド・ビュー（MV）は、予測可能で繰り返されるクエリ を⾼速化するために特に有効 • Redshiftは、3つの⽅法でMVの効率的な維持と利⽤を⾃動化します。 • マテリアライズド・ビュー（MV）は、事前集約された実データを持つビュー • アクセスするデータ量を減らすメリットが得られる • ベーステーブルの変更をインクリメンタルに維持 • Redshiftはバッチ処理を得意としているため、MVは遅延的にメンテナンスされ、トランザク ションのワークロードが遅くならないようにする • RedshiftはどのMVが古くなったかを検知し、バックグラウンドでメンテナンスするMVを選択す るための優先キューを保持する。⽬標は、実体化されたビューの全体的な性能上の利点を最⼤化 することです。95%のMVについて、Redshiftはベーステーブルの変更から15分以内にビューを 最新にする • Redshiftの洗練されたMVベースの⾃動書き換えを利⽤して、クエリに最適に答えるために最適な 実体化ビューを使⽤するようにベーステーブル上のクエリを書き換えることも可能です

Smart Warmpools, Gray Failure Detection and Auto-Remediation 46 ⽇常的に起こるハードウェア障害やサービス障害を発⽣させないための ⼯夫 • Warmpool の設置 • Warmpool: すぐに使える状態のEC2インスタンス群 • 必要なソフトウェアインストール済み、ネットワーク設定済み • 各リージョンの各AZに⽤意されている • ウォームスタンバイしているリソースプール • EC2 AutoScalingにもある • Gray Failure への対応 • システム停⽌を起こすような障害は発⾒しやすいので対応は簡単 • すぐに復旧処理を開始できる • Gray Failure は対応が難しい

Serverless Compute Experience 47 Redshift Serverlessは、コンピューティングリソースの⾃動プロビ ジョニング、サイジング、スケーリングをアルゴリズムに依存 • autonomics（⾃動化）に取り組みを拡張して、Redshift Serverless を導⼊した • Serverless は、コンピューティングリソースの⾃動プロビジョニング、サイジン グ、スケーリングのためのアルゴリズムにrely(依存)する • 従来のRedshiftでは、データウェアハウス環境を最適化するためのチューニング ノブを提供しているが（インスタンスタイプ、クラスタのノード数、ワークロー ド管理キュー、スケーリングポリシーなど）、Serverlessは、ほぼゼロタッチイ ンターフェースを提供する • クエリを実⾏した秒数だけ課⾦されます(最⼩60秒から) • 次のセクションで説明する幅広いサービスとの統合のような豊富な分析機能を維 持しています

6. USING THE BEST TOOL FOR THE JOB

Data in Open File Formats in Amazon S3 49 Redshift Spectrumを介して、S3のオープンファイル形式のデータに アクセスする機能 • RedshiftからOpen Data FormatのS3オブジェクトにアクセス • Parquet、Text、ORC、AVRO • データレイクのエクサバイト規模の分析を容易にし、スキャンされたデータの量 に基づく従量課⾦制で⾮常に費⽤対効果が⾼い • Redshift compute sliceからSpectrum Nodeへのfan-outは1:10 • データカタログは、Hive Metastore、AWS Glue、AWS Lake Formation • クエリープラニング中 • Spectrumテーブルは⼀時テーブルとして利⽤可能 • その後、フィルターや集約をpushdownするために、Spectrum向けにクエ リーは書き換えられ、分離(isolate)される

Redshift ML with Amazon SageMaker 50 Redshift MLは、SQLを使⽤して機械学習モデルをトレーニングし、予 測（推論）を簡単に実⾏ • Redshift MLを利⽤することで機械学習モデルの学習と推論をSQLでできる。 • Redshift MLはSageMakerを利⽤している。 • SageMakerで機械学習モデルを作成した後にSQL関数として推論を実⾏できる • AUTO OFF modeも存在する • 前処理やアルゴリズム/モデルの選定をユーザーが実施することも出来る • MODEL_TYPE { XGBOOST | MLP | LINEAR_LEARNER } • ユーザーが処理を開始するとRedshiftは学習⽤のサンプリン グデータをS3にアンロードする • Sagemaker Autopilot jobが実⾏される（SageMaker Autopilotを利⽤している） • 機械学習の推論をローカル（Redshiftのノード上で）実⾏で きるようにSagemaker Neoでコンパイルする • 前処理、予測、後処理を抽象化する • Redshiftはコンパイルされた成果物を推論関数として登録す る。モデルを実⾏するためC++のコードを⽣成する • 以上の処理（前処理、機械学習モデルの選定、ハイパーパラ メータのチューニングなど）はすべて⾃動的に実⾏される

OLTP Sources with Federated Query and Glue Elastic Views 51 Federated Queryは、RedshiftからOLTPサービスのライブデータに直 接クエリを実⾏したり、GlueElasticViewsを使⽤してRedshiftへのデー タのシームレスなコピーと同期の両⽅を容易に実現する。 • Redshift Federated Queryを⽤いてOLTPデータベースサービスからライブデー タを取り込んだり、 Redshiftのデータをブレンディングできる • Federated Queryは、OLTPソースデータベースにプリディケイトプッシュダウン するのでパフォーマンスも良い • Glue Elastic Views（GEV）とRedshiftの統合により、OLTPソースからRedshift へのデータの取り込みが容易になる

Redshiftʼs SUPER Schemaless Processing 52 RedshiftのSUPER型は、スキーマレスな半構造化データの効率的かつ 柔軟に保存が可能です。 • RedshiftのSUPER型のINSERTは、JSONの⾼速解析とそれをSUPER値として保存 することをサポート • SUPERの属性を従来の列に細断処理したテーブルに同じ挿⼊を実⾏するよりも最 ⼤5倍⾼速に動作 • SUPER型は、通常のスキーマを必要としないため、ELT処理のためにスキーマレ スデータを取り込む⼿間が不要 • スキーマレスおよび半構造化データをSUPERに保存した後、PartiQLマテリアライ ズド・ビューを作成することでパフォーマンスと使いやすさの利点をもたらす

Redshift with Lambda 53 Redshiftは、AWS Lambdaコードに基づくユーザー定義関数（UDF） の作成をサポートしている ● クラスタ内の各データスライスは関連したタプルを⼀括でLambdaに 送り、Lambda関数を並列で起動するため効率的 ● データ転送は隔離されたネットワーク経由で⾏われ、そのネットワー クにクライアントはアクセスできないのでセキュア ● ユースケース ■ 外部データやAPIを利⽤したデータ増強 ■ 外部サービスを使ったデータのマスキングやトークン化 ■ CやC++, Javaで書かれた既存UDFをLambdaに移⾏し再利⽤

7. CONCLUSION

CONCLUSION 55 • マネージドストレージ、スケーリング、データ共有、AQUAなどのイノベーショ ンにより、パフォーマンスとスケーラビリティを成⻑させてきた • 同時に、使いやすさも進化してきた • ⾃動化されたワークロード管理、⾃動化されたテーブル最適化、マテリアラ イズドビューを使⽤した⾃動クエリ書き換え • 優れたクエリパフォーマンスを実現 • さらに、Redshiftは、追加のデータ（半構造化、空間）および複数のAWSサービ スとのインタフェースが可能になった • Amazon Redshiftは、 • 分化された実⾏コア、 • 数⼗PBsのデータと数千⼈の同時ユーザーに対応する拡張性 • 使いやすいMLベースの⾃動化 • 幅広いAWSエコシステムと緊密に統合された、クラウドDWHのベストソ リューション

Amazon Redshift re-invented 2022

Cross­AZ cluster recovery 57 •クロスAZクラスターリカバリー • AZ障害があってもクラスターを別のAZに再配置できる

Automated Materialized views 58 •⾃動マテリアライズドビューによるさらなるパフォーマンス向上

Redshift - New Features 59 • Apache Spark統合 • Multi-AZのプレビュー開始 • SQL機能を強化(MERGE, ROLLUP, CUBEなど) • S3からの⾃動データ取込み • Real-time Streaming Ingestion • 動的データマスキング • Centralized Access Control • Informatica Data Loader が利⽤可能に • AWS Backupがサポート • Zero-ETL

Amazon Redshift 10 years of innovation 60

61