Amazon Web Services ブログ
Amazon Redshift が BI ダッシュボードとリアルタイム分析のパフォーマンスを向上
本記事は 2026 年 6 月 29 日 に公開された「Amazon Redshift delivers faster performance for BI dashboards and real-time analytics」を翻訳したものです。
ビジネスインテリジェンス (BI) ダッシュボードとリアルタイム分析は、迅速な意思決定に欠かせないツールです。現代のデータウェアハウスは、複雑で長時間実行される分析クエリに優れるだけでなく、インタラクティブなリアルタイム体験を支える短時間のアドホッククエリにもサブ秒のレスポンスタイムを実現する必要があります。エージェントが大量のデータから新たなインサイトを探索・導出するようになった今、低レイテンシーの要件はさらに重要になっています。朝のダッシュボードで KPI を確認する経営層から、エージェントを使ってデータセットをインタラクティブに探索するデータアナリストまで、クエリが高速かつ安定した応答を返すことへの期待は明確です。
Amazon Redshift はこうしたユースケース向けに長年最適化されてきました。BI やリアルタイム分析ワークロードのクエリパフォーマンスを向上させるため、結果キャッシュ、マテリアライズドビュー、自動ワークロード管理 (AutoWLM) など、多くの機能を導入しています。こうした機能により、数千のお客様がレスポンスの良いダッシュボードやリアルタイムアプリケーションを Amazon Redshift 上に構築してきました。しかし、インタラクティブ分析ではミリ秒単位の差が重要です。ダッシュボードの読み込み高速化と探索的クエリの応答時間短縮に引き続き注力しています。
本日、Amazon Redshift の新しいパフォーマンス最適化を発表します。リアルタイム分析アプリケーションや BI ダッシュボードが生成する低レイテンシー SQL クエリのレスポンスタイムを改善する機能です。SQL クエリの実行準備にかかる時間を短縮することで、クエリレイテンシーが改善されます。クエリの開始が速くなるため、結果もより早く返されます。
最適化の仕組み
今回の改善を理解するために、まず Amazon Redshift の既存のコアパフォーマンス機能であるコード生成について説明します。コード生成は、各 SQL クエリを分析し、クエリ固有の C++ コードを内部的に生成する最適化手法です。生成されたコードはコンパイルされ、利用可能な Amazon Redshift コンピューティングノード全体で並列実行されて結果を返します。コード生成は Amazon Redshift のクエリパフォーマンスの基盤であり、複雑な分析クエリを高い効率で実行します。
コード生成により高いクエリ実行性能を実現する一方で、新しいクエリは初回実行時に一度だけコンパイルの負荷が発生します。Amazon Redshift はすでにコンパイル済みコードをキャッシュしており、Amazon Redshift フリート内のクエリの 99% 以上がキャッシュされた生成コードで実行され、コンパイルの負荷は発生しません。まだキャッシュされていないクエリの場合、初回コンパイルの負荷は高速実行クエリ (ミリ秒や 1 桁秒台のクエリなど) で特に顕著で、全体の実行時間に対して大きな割合を占めることがあります。
今回の最適化により、Amazon Redshift はコンパイルの負荷を軽減します。具体的には、Amazon Redshift がクエリを受信すると、まずフリート内で過去に類似クエリを実行した際の最適化済みコンパイル済み C++ コードがキャッシュに存在するかを確認します。存在する場合は最高のパフォーマンスを得るためにそのコードを使用します。存在しない場合、Amazon Redshift は新しいクエリコンパイル最適化を適用し、コンポジションを使ってクエリを即座に処理します。コンポジションは、既存のロジックの軽量な組み合わせを生成する手法です。同時に、クエリ固有の最適化コードを作成し、利用可能なコンピューティングリソース全体でコンパイル・実行してパフォーマンスをさらに向上させます。コンポジションにより、コンパイルがクエリ実行のクリティカルパスから外れ、バックグラウンドでコンパイルが進行する間に即座に実行を開始できます。その結果、Amazon Redshift で処理される新しいクエリの開始が速くなり、2 回目以降の実行と同等のパフォーマンスが得られます。
コンポジションにより初回クエリの開始が大幅に高速化される一方、繰り返し実行されるクエリは Amazon Redshift のコード生成がもたらす優れた価格性能比の恩恵を引き続き受けられます。
重要な点として、このパフォーマンス最適化を利用するためにユーザー側の操作は不要です。Amazon Redshift が利用可能なすべての AWS リージョンにおいて、プロビジョンドクラスターまたはサーバーレスワークグループのすべてのユーザーのすべての SQL クエリにデフォルトで有効化されており、追加費用はかかりません。
実環境でのパフォーマンス結果
Amazon Redshift のお客様クラスターに対する今回の最適化の効果を分析しました。コンパイルキャッシュでキャッシュヒットせず、コンパイルが必要だった 1% のクエリセグメントのコンパイル時間を測定しました。次のグラフがその結果です。最適化前の P50 コンパイル時間は 4.3 秒でした。最適化後は 25.7 倍短縮され、170 ミリ秒になりました。

今回の最適化により、BI ダッシュボードの読み込みが速くなり、インタラクティブな探索がよりレスポンシブになり、リアルタイム分析アプリケーションがより低レイテンシーでインサイトを提供できます。
お客様の声
「FastCompile クエリパフォーマンス機能を有効にしたクラスターで、Amazon Redshift がコールドクエリ実行のパフォーマンスを大幅に改善したことを確認しました。コンパイル時間が 12 秒から 5 秒に短縮され、2.4 倍高速なクエリパフォーマンスを達成したことを受け、分析ソリューションとして Amazon Redshift を採用しました」
— Vijay Hiremath 氏 (Intuit、Group Manager、Business Platforms)
「中国の大手酒類企業のデータプラットフォームリーダーとして、エンタープライズデータウェアハウスに Amazon Redshift を活用しています。多様な分析クエリパターンがあるため、初回コンパイル時のパフォーマンスに課題がありました。Redshift の新しいコールドクエリコンパイル強化機能をテストしたところ、コールドクエリがウォームクエリとほぼ同等の速度で実行されるようになり、多様なクエリで大幅な速度改善が見られました」
— Yujie Wang 氏 (JNC、Data Platform Leader)
「約 85 GB のデータを日次で複雑な ETL パイプライン (複数テーブル、混合 DML 操作) を通じて処理し、1.7 TB の Amazon Redshift データウェアハウスに格納する中規模のお客様において、fast compile 機能の強化によりメンテナンス後の ETL パイプラインが 25% 高速化されました。データロードが早く完了し、アナリストがより迅速に意思決定できるようになりました」
— Jagan Mohan 氏 (Algonomy、Product Engineering Head)
技術の詳細については、VLDB 2026 Boston カンファレンスに採択された論文「FastCompose: Eliminating compilation cold starts in query execution with composition」をご覧ください。
あらゆるワークロードに対して業界最高の価格性能比
今回の最適化の効果を示すため、業界標準の TPC-DS ベンチマークから派生したベンチマークを使用して、短時間実行の BI 型低レイテンシーワークロードをシミュレーションしました。3 ノード RG xlarge の Amazon Redshift クラスター上で、比較的小規模な 100 GB のスケールでワークロードを実行しました。このクラスターサイズとスケールでは、クエリはミリ秒から 1 桁秒台で完了し、一般的な BI ダッシュボードで期待されるレイテンシーに相当します。派生 TPC-DS ベンチマークには 99 の異なるクエリが含まれ、レポートクエリ、アドホック分析、データ探索パターンなど、現実的なビジネスインテリジェンスワークロードの組み合わせを表しています。テストでは、Amazon Redshift RG クラスターでのコールド 1 回実行と、同等の他社クラウドデータウェアハウスでの同様の実行を比較しました。ウェアハウスを起動し、データをロードし、99 クエリを 1 回実行して、合計実行時間とクエリの幾何平均を測定しました。その他のクラスターウォームアップやセットアップは行っていません。今回のクエリパフォーマンス改善はハードウェアに依存しません。Amazon Redshift でサポートされるすべてのハードウェアインスタンスタイプ (プロビジョンドクラスターの RA3 と RG、サーバーレスワークグループをサポートするハードウェア) で動作します。
結果を以下の表にまとめ、続くグラフに要約しています。今回の最適化により、Amazon Redshift は短時間クエリに対して最速の実行時間と幾何平均を最低コストで実現し、新しいクエリに対して他社の主要データウェアハウスの最大 8.3 倍の価格性能比を達成しています。
| . | コスト/時間 | 実行時間 (秒) | 幾何平均 (秒) | 実行時間比較 | 幾何平均比較 | 幾何平均価格性能比 |
| Redshift 3-node RG.xlarge | $2.28 | 235 | 1.7 | ベースライン | ベースライン | ベースライン |
| Alternative Warehouse A | $3.00 | 327 | 2.3 | 1.4 倍遅い | 1.3 倍遅い | 1.7 倍高コスト |
| Alternative Warehouse B | $4.00 | 538 | 3.4 | 2.3 倍遅い | 2 倍遅い | 3.4 倍高コスト |
| Alternative Warehouse C | $6.00 | 907 | 5.5 | 3.9 倍遅い | 3.2 倍遅い | 8.3 倍高コスト |

まとめ
Amazon Redshift の新しいクエリ起動最適化は、分析ワークロード全体にわたる高速パフォーマンスへの取り組みの一環です。コンパイルの負荷を軽減することで、BI ダッシュボードやリアルタイム分析アプリケーションのレスポンスを向上させつつ、定評のあるクエリ実行パフォーマンスを維持しています。
すべての Amazon Redshift ユーザーに自動的に有効化されているため、すぐに効果を体験できます。設定変更やクエリの書き換えは不要です。既存のクエリがそのまま高速に実行されます。
詳細については、Amazon Redshift をご覧ください。Amazon Redshift Serverless を使えば、データウェアハウスインフラストラクチャのセットアップや管理なしに数分でクエリを開始できます。パフォーマンスのベストプラクティスについては、Amazon Redshift Database データベース開発者ガイド を参照してください。
ワークロードに最適な価格性能比を見つける
本記事で使用したベンチマークは業界標準の TPC-DS ベンチマークから派生したもので、以下の特徴があります。
- スキーマとデータは TPC-DS をそのまま使用しています。
- クエリは TPC-DS から変更せずに使用しています。ウェアハウスがデフォルトの TPC-DS クエリの SQL 方言をサポートしていない場合は、TPC 承認済みのクエリバリエーションを使用しています。
- テストには 99 の TPC-DS
SELECTクエリのみが含まれます。メンテナンスとスループットのステップは含まれていません。 - TPC-DS キットのデフォルトランダムシードで生成したクエリパラメーターを使用して、単一のパワーランを実行しました。単一のコールド実行の合計実行時間と幾何平均を結果として使用しています。
- 価格性能比は、幾何平均 (秒) を 1時間あたり 3,600 秒で除算し、ウェアハウスの時間あたりのコストを乗算して算出しています。結果はクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで公表されているオンデマンド価格を使用しています。
Cloud Data Warehouse Benchmark と呼ぶこのベンチマークは、GitHub で公開されているスクリプト、クエリ、データを使用して結果を再現できます。TPC-DS ベンチマークから派生したものであり、仕様に準拠していないため、公表された TPC-DS 結果とは比較できません。
ワークロードにはそれぞれ固有の特性があります。初めて検討する場合は、概念実証 (PoC) が要件に対する Amazon Redshift のパフォーマンスを理解する最良の方法です。PoC を実行する際は、適切なクラスターサイジングと適切な指標 (時間あたりのクエリ数であるクエリスループットと価格性能比) に焦点を当ててください。概念実証の支援をリクエストするか、システムインテグレーションおよびコンサルティングパートナーと協力することで、データに基づいた意思決定が可能です。
Amazon Redshift の最新の開発状況を把握するには、What’s New in Amazon Redshift の RSS フィードをご購読ください。
著者について
この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。