論文から垣間見るRedshiftの進化と深化

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

CrossAZ 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

論文から垣間見るRedshiftの進化と深化

論文から垣間見るRedshiftの進化と深化

More Decks by Satoru Ishikawa

Other Decks in Technology

Featured

Transcript