Amazon Redshift マテリアライズドビューを使用して AXS で Etleap モデルを高速化する

Amazon Redshift のマテリアライズドビュー機能は現在一般公開されており、2019 年 12 月からプレビュー中のお客様およびパートナーにメリットをもたらしてきました。当社のお客様の AXS は、米国、英国、欧州、および日本のライブエンターテインメント会場向けのチケット販売、データ、およびマーケティングの分野における主要なソリューションプロバイダーです。Amazon Redshift パートナーである Etleap は、AWS 用に構築された抽出、変換、ロード、および変換 (ETLT) のサービスです。AXS は Etleap を使用して、ファイルサーバー、Amazon S3、リレーショナルデータベース、アプリケーションなどのさまざまなソースから Amazon Redshift にデータを取り込みます。これらの取り込みパイプラインは、適切な列タイプおよび並べ替えキーと分散キーを使用して、データを分析および構造化し、Amazon Redshift テーブルにロードします。

Etleap モデルでダッシュボードのパフォーマンスを改善する

データを分析するために、AXS は通常、複数のソースから発生する大きなテーブルに対してクエリを実行します。AXS による Amazon Redshift の使用形態の 1 つとして、インタラクティブなダッシュボードを強化することを挙げることができます。ダッシュボードのロード時間を短縮するために、AXS は、ダッシュボードが使用するクエリに対する部分的な回答を事前にコンピューティングします。これらの部分的な回答は、行数の点において、当該回答が基づくテーブルよりも数桁小さくなります。ダッシュボードは、事前にコンピューティングされた部分的な回答を保持する Amazon Redshift テーブルをクエリすることによって、ベーステーブルを直接クエリする場合よりもはるかに高速にロードできます。

Etleap は、models と呼ばれる機能を通じて、このような事前コンピューティングの作成と管理をサポートしています。モデルは、SELECT クエリと更新時期のトリガーで構成されます。トリガーの例は、ベーステーブル、つまりモデルを定義する SELECT ステートメントが使用するテーブルへの変更です。このようにして、モデルはベーステーブルとの一貫性を保つことができます。

次のスクリーンショットは、2 つのベーステーブルの依存関係を持つ Etleap モデルを示しています。

Etleap は、モデルを Amazon Redshift のテーブルとして表します。モデルテーブルを作成するために、Etleap は、CREATE TABLE AS (CTAS) クエリで SELECT ステートメントをラップします。たとえば、ベーステーブルの挿入、更新、または削除が原因で更新がトリガーされると、Etleap は、次のコードを使用してモデルテーブルを再コンピューティングします。

CREATE TABLE model_temporary AS SELECT …
DROP TABLE model;
RENAME TABLE model_temporary TO model;

データの増加に伴う CTAS パフォーマンスを分析する

AXS は、多数の Etleap モデルを管理します。特定のモデルの場合、CTAS クエリは平均で 6 分以上かかります。このクエリは、3 つの異なるテーブルの結合で集計を実行します。これには、常に新しいデータを取り込み、10 億を超える行を含むイベントテーブルが含まれます。次のグラフは、イベントテーブルの行数が増えると CTAS クエリ時間が増加することを示しています。

クエリの処理に時間がかかる場合、主に 2 つの問題が生じます。

更新されたモデルがアナリストに利用可能になるまでに、より長い遅延が発生する
モデルを更新する際に、より多くの Amazon Redshift クラスターリソースを消費する

これに対処するために、AXS は、イベントテーブルから古いデータをアーカイブしたり、Amazon Redshift クラスターを拡張して使用可能なリソースを増やしたりするなど、不便またはコストの高い回避策に頼る必要があります。

CTAS とマテリアライズドビューを比較する

Etleap は、Amazon Redshift のマテリアライズドビュー機能が、この AXS モデルの CTAS アプローチの改善につながることを検証するための実験を行うことにしました。まず、CREATE MATERIALIZED VIEW AS クエリで SELECT ステートメントをラップすることにより、マテリアライズドビューを構築しました。更新の場合、ベーステーブルのデータが変更されるたびにマテリアライズドビューを再作成する代わりに、REFRESH MATERIALIZED VIEW クエリで十分です。マテリアライズドビューの使用は、CTAS ベースの手順よりも大幅に高速であると予想されていました。次のグラフは、CTAS のクエリ時間とマテリアライズドビューの更新を比較したものです。

REFRESH MATERIALIZED VIEW の実行は、CTAS アプローチよりも 7.9 倍高速でした。現在のスケールの平均では 371 秒かかるところ、49 秒でした。また、更新時間は、ベーステーブルの合計サイズではなく、前回の更新以降にベーステーブルに追加された行数にほぼ比例していました。このユースケースでは、この数は 380 万であり、これは 1 日に取り込まれるおおよそのイベント数に相当します。

これは素晴らしいことです。このソリューションは、新しいデータが入ってきてもモデルの更新による遅延が一定であるため、以前の問題を解決します。また、Amazon Redshift が消費するリソースも同様です (ベーステーブルの増加が一定であると仮定した場合)。つまり、マテリアライズドビューを使用すると、データセットが大きくなるにつれて、アーカイブ、クラスターの拡張などの回避策が不要になります。また、SQL ステートメントの数を 3 (CREATE、DROP、および RENAME) から 1 (REFRESH) に減らすことにより、モデル更新の更新手順を簡素化します。

マテリアライズドビューで高速な更新を達成する

Amazon Redshift は、マテリアライズドビューを効率的かつ段階的に更新できます。マテリアライズドビューが以前に更新された時点までのベーステーブルの最新のトランザクションを追跡します。その後の更新において、Amazon Redshift は、delta と呼ばれるベーステーブルに新しく挿入、更新、または削除されたタプルのみを処理し、ベーステーブルでマテリアライズドビューを最新の状態にします。つまり、Amazon Redshift は、ベーステーブルの delta のみを読み取ることでマテリアライズドビューを段階的にメンテナンスできるため、更新時間の短縮につながるということです。

AXS の場合、Amazon Redshift が複数のテーブル、フィルター、および集計を結合するマテリアライズドビュー定義を分析し、特定のマテリアライズドビューを段階的にメンテナンスする方法を見つけ出しました。AXS がマテリアライズドビューを更新するたびに、Amazon Redshift は、更新が必要かどうかを迅速に判断し、必要であれば、マテリアライズドビューを段階的にメンテナンスします。レコードがベーステーブルに取り込まれると、各更新が他の delta とほぼ同じサイズの小さな delta を読み取るため、表示されるマテリアライズドビューの更新時間が非常に速くなり、増加は非常に遅くなります。これに比して、CTAS を使用した更新時間は、各更新がすべてのベーステーブルを読み取るため、非常に遅くなります。さらに、CTAS を使用した更新時間は、各更新が読み込むデータ量が取り込み速度とともに増加するため、はるかに速く増大します。

マテリアライズドビューを更新するタイミングは完全に制御できます。たとえば、AXS は、Etleap で定義されたトリガーに基づいてマテリアライズドビューを更新します。その結果、ベーステーブルで実行されるトランザクションには、依存するマテリアライズドビューをメンテナンスするための追加コストは発生しません。ベーステーブルの更新をマテリアライズドビューの更新から切り離すことにより、AXS は、ベーステーブルに新しいデータを取り込みながら、ダッシュボードユーザーを簡単に隔離し、クエリに対して明確に定義されたスナップショットを提供することができます。AXS が ETL パイプラインを介してベーステーブルデータの次のバッチを精査する際に、マテリアライズドビューを更新して、ダッシュボードの結果の次のスナップショットを提供できます。

AXS は、マテリアライズドビューを効率的にメンテナンスすることに加えて、各マテリアライズドビューをプレーンテーブルとして格納する Amazon Redshift のシンプルさからも恩恵を受けています。マテリアライズドビューのクエリは、Amazon Redshift がクエリを実行するのと同じワールドクラスの速度で実行されます。お客様は、他のテーブルと同様にマテリアライズドビューを編成できます。つまり、分散キーを活用して列を並べ替え、クエリのパフォーマンスをさらに向上させることができます。最後に、ピーク時に多くのクエリを処理する必要がある場合、Amazon Redshift の同時実行スケーリングが自動的に起動して、クエリ処理能力を柔軟にスケーリングします。

まとめ

マテリアライズドビュー機能が一般的に利用可能になったので、Etleap は、モデルを作成する際に、テーブルではなく、マテリアライズドビューを使用するオプションを提供します。お客様は、ETLT 戦略の一部としてモデルをより積極的に使用できます。また、モデルの更新をより頻繁に行うスケジュールを選択できるという、段階的な更新のパフォーマンスのメリットを享受できます。

Amazon Redshift マテリアライズドビューの詳細については、「クエリの実行を速めるために Amazon Redshift のビューをマテリアライズする」および「Amazon Redshift でマテリアライズドビューを作成する」を参照してください。

著者について

Christian Romming 氏は、Etleap の創業者兼 CEO です。 Etleap は、AWS 向けのマネージド型の ETL ソリューションであり、セットアップ、メンテナンス、スケーリングのために大規模なエンジニアリング作業を必要としません。

Prasad Varakur 氏は、データベース、ビッグデータ、および分散システムに強い興味を有するアマゾンウェブサービスのプロダクトマネージャーです。 過去に、彼は、SAP/Sybase、Couchbase、Huawei、Novell、EMC、Veritas でデータベースおよびストレージエンジンを開発してきました。彼は、データベースシステムと分散コンピューティングで 11 の特許を取得しており、彼の論文は、パラメトリッククエリ最適化の基礎研究に貢献しています。彼は、IIT Kanpur でコンピューターサイエンスの修士号を取得しています。

Vuk Ercegovac 氏は、AWS の Redshift のプリンシパルエンジニアです。

Amazon Web Services ブログ