『Amazon Redshift & Tableau パフォーマンスチューニング』に関するホワイトペーパーの改訂版を読んでみた（Amazon Redshiftクラスタのチューニング編）

「カスタマーストーリー」を支えるツール特集

#Tableau

#Amazon Redshift

#AWS

石川覚

2018.03.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Tableau Software社が公開しているホワイトペーパーの改訂版『Tuning your Amazon Redshift and Tableau Software Deployment for Better Performance v2』が公開されていますので、数回に分けてそのポイントについて紹介します。今回はテーマは、「Amazon Redshiftクラスタのチューニング」です。

ホワイトペーパーの中では、”A few other considerations”でしたが、「Amazon Redshiftクラスタのチューニング」という切り口で紹介しますドキュメントのダウンロードは、以下のリンクをクリックして、ログインした後ダウンロードできます。

Optimizing your Amazon Redshift and Tableau Software Deployment for Better Performance v2

カーソルの詳細

Tableauは、Amazon Redshiftからクエリされたデータを返すときにカーソルを使用します。カーソルを使用すると、一度にまとめて検索するのではなく、一度に結果をチャンクで取得することで、Tableauは大きなデータセットを効率的に取得し、消費されるメモリ量を削減できます。

他の方法よりも多くのデータを取得することができますが、カーソルにはいくつかのパフォーマンス上の副作用があります。カーソルは、データをTableauに返す前にすべてのデータをリーダーノードにストリーミングする必要があり、応答時間が遅くなる可能性があります。

Tableau Desktop から Amazon Redshift に送信するクエリのカーソル定義を無効化するでも、解説したとおり、カーソルをオフにすることができますが、これにより、Amazon Redshiftはすべてのデータを一度に戻そうとします。これにより、クライアント側でメモリー不足エラーが発生する可能性があります。 Amazon Redshiftのデータセットが大きすぎて、カーソルを使用せずに取得できないことは珍しくありません。この挙動についても、Amazon Redshift カスタムODBCドライバを試してみましたにて解説しています。

ホワイトペーパーでは、ノードタイプ、ノード数、同時実行数に従い、カーソルサイズ（max_cursor_result_set_size）のチューニングについて解説していますが、max_cursor_result_set_size パラメータは廃止されています。現在の仕様では、カーソルの結果セットのサイズはクラスタのノードタイプに基づいて制限されます。よって、カーソルサイズの調整は下記の表の「クラスターあたりの最大結果セット (MB)」に応じて「ノードの種類」を選択することになります。詳細については、「カーソルの制約」を参照してください。(2015/07/24:廃止されたパラメータ)

ノードの種類	クラスターあたりの最大結果セット (MB)
DS1 または DS2 XL 単一ノード	64000
DS1 または DS2 XL 複数ノード	1800000
DS1 または DS2 8XL 複数ノード	14400000
DC1 大型単一ノード	16000
DC1 大型複数ノード	384000
DC1 8XL 複数ノード	3000000
DC2 大型単一ノード	8000
DC2 大型複数ノード	192000
DC2 8XL 複数ノード	3200000

現在のカーソルの仕様については、以下のブログを参照してください。

Amazon Redshift: 気付いたらクラスタの『カーソル数設定』の仕様が変わっていた件

ワークロード管理（WLM）のキュー

Amazon Redshiftでは、ワークロード管理（WLM）キューを介してクエリの実行を管理できます。 WLMキューは、実行される並行クエリの数と、クエリが消費できるクラスターのRAMの量を管理します。デフォルトでは、各Amazon Redshiftクラスタには1つのWLMキューがあり、最大で5つの同時クエリを実行できます。この値は変更できますが、Amazon Redshiftは現在、クラスタ全体で最大15個までの同時クエリに設定することを推奨しています。各WLMキューは、クラスタのRAMの設定量を消費するように設定することもできます。

新しいAmazon Redshift WLM クエリモニタリングルール機能を使用して、ワークロード管理（WLM）キューのメトリックベースのパフォーマンスのしきい値を設定し、クエリがそのしきい値を超えた場合に実行するアクションを指定します。たとえば、実行時間の短いクエリに専用のキューの場合、60秒を超えて実行されるクエリを中止するルールを作成することがあります。不適切に設計されたクエリを追跡するには、ネストされたループを含むクエリを記録する別のルールがあるとします。AWSはAmazon Redshift管理コンソールにあらかじめ定義されたルールテンプレートを提供しています。

追加のWLMキューを作成し、Tableauの初期SQL機能と組み合わせることができます。そうすることで、特定のWLMキューに特定のクエリを配置することができます。単純なクエリは専用のRAMを必要としない「高速」キューに指定し、より複雑なクエリはRAMが多い「低速」キューに指定します。

異なるWLMキューを作成して構成したら、Tableauで複数のデータ接続を同じAmazon Redshiftデータベースに作成します。接続するときは、初期SQL機能を使用してSET query_group文を実行します。これはAmazon Redshiftに、どのWLMキューにクエリを送信するかを指示します。

初期SQLは、Tableau Workbookの名前やTableau Serverユーザーの名前などの変数を含むパラメータの使用もサポートしています。これらのパラメータを効果的に使用して、特定のTableauワークブックの作業を「高優先」（または「低優先」）WLMキューに強制することができます。特定のユーザーが実行するクエリを特定のWLMキューに送ることもできます。

Amazon Redshift Workload Management Queuesの詳細については、チュートリアル: クエリ処理を改善するワークロード管理 (WLM) キューの設定を参照してください。

Tableauと初期SQLの詳細については、Tableauのオンラインヘルプセクションの初期 SQL の実行を参照してください。

Amazon Redshift と Tableau のデータ抽出

クエリ中に、Tableauは Amazon Redshiftとのライブ接続を活用したり、Tableau データ抽出を使用したりすることができます。ライブ接続は、Amazon Redshiftに対してアドホックにクエリを実行します。一方、データ抽出は事前にクエリを実行（抽出）した結果をTableauに保存して、そのデータに対してクエリを実行します。

データ抽出は、Amazon Redshiftの並行処理に関する問題を回避するのに役立ちます。また、事前に集約を実行することができるのは、価値のあることです。TDE(Tableau Data Extracts)導入に向けた検討とテスト：Amazon Redshiftデータベースの一部分を抽出することをお勧めします。大抵のユーザーに関連するデータの「スライス（切り口）」を選択します。

この方法を追求する場合は、以下の点を考慮する必要があります：

可能であれば、集約を抽出します。 Tableauには、ワークブック内で使用されていないフィールドを削除する方法や、より詳細なレベルまで（たとえば、数秒ではなく月）など、さまざまな方法があります。
開いているカーソルのサイズ制限にぶつからないように、複数の抽出リフレッシュを並行してスケジュールすることを避けます。
事前に抽出するデータのサイズを確認します。カーソルを活用すると仮定すると、Amazon Redshiftの結果は、クラスタのLeaderノードに反映されます。これにより抽出プロセスが遅くなります。リーダーノードには、クラスタ内のノードのサイズとタイプに応じて、マテリアライズ可能な最大量のデータがあります。
Amazon Redshiftクラスタの他のユーザーも検討してください。 Amazon Redshiftクラスタ上のすべてのカーソルスペースを使用してエラーが発生した場合、同じクラスタ上で現在カーソルを使用している他の人にもエラーが発生します。
前述のとおり、ノードサイズが大きいとカーソルスペースが増えます。大規模ノードから8xlargeノードへの移行を検討してください。

Amazon Redshift Spectrum

2017年11月にAmazon Redshift Spectrum（外部S3テーブル）をサポートするAmazon Redshiftコネクタのアップデートを発表しました。この機能はTableau 10.3.3の一部としてリリースされ、Tableau 10.4.1で広く利用可能になります。 Tableauでは、Amazon Redshiftのデータに直接接続し、Amazon Simple Storage Service（S3）のデータと併せて分析することができます。

Amazon Redshift Spectrumのサポートはどのようにお客様の役に立ちますか？

Tableauの多くの顧客は、Amazon S3に格納されている大きなデータバケットを持っています。このデータを頻繁にアクセスして一貫性のある高度に構造化されたフォーマットで保存する必要がある場合、Amazon Redshiftのようなデータウェアハウスにそのデータをプロビジョニングできます。インフラストラクチャの設定と管理を必要としない、AWSのサーバーレスのインタラクティブなクエリサービスであるAmazon Athenaを使用して、このS3データをアドホックベースで探索したい場合は、プロビジョニングするかどうかを決定します。

しかし、Amazon Redshiftでローカルに格納された頻繁にアクセスされるデータとAmazon S3に格納された完全なデータセットの両方を分析したい場合はどうすればよいですか？
Amazon Redshiftのディスクと洗練されたクエリ最適化のスループットと、サーバーレスのスケールアウト処理機能と大規模で信頼性の高い拡張性のあるS3インフラストラクチャを組み合わせたサービスをご希望の場合はどうすればよいですか？
Amazon Redshiftの超高速パフォーマンスと、S3のオープン・ストレージ・フォーマット（例えば、Parquet、ORC）のサポートをしたい場合はどうでしょうか？

これらを可能にして、その無謀な要求を解決するために、AWSはAmazon Redshift Spectrumを2017年の早い時期に開始しました。

Amazon Redshift Spectrumは、自由にデータを保存し、あなたが望む形式で、必要なときにいつでも処理できます。 Amazon Redshift Spectrumがリリースされて以来、Tableauはこの新しいサービスのクラス最高のサポートを提供するために労を惜しまず作業を進めてきました。利用者はAmazon Redshift分析をS3データレイク内のデータ全体に拡張できます。

TableauがAmazon Redshift Spectrumでどのように動作するかを見てみましょう。この例では、ユースケースに応じて、さまざまな方法でAWSデータに接続する方法とその理由を示します。

検証

次のパイプラインを使用して、AWSスタック上のTableauでデータを取り込み、処理し、分析しています。

この例では、New York City Taxi data set をソースデータとして使用します。このデータセットには、9年間のタクシー運転手の活動が含まれています。これには、ピックアップとドロップオフの場所、支払額、支払いタイプが12億レコードに収録されています。

データはS3に格納されます。これは、Amazon EMRを介してクレンジング・分割して、分析的に最適化されたカラムナのParquetのフォーマットに変換されます。

TableauはS3の生データ（AWS Glue データカタログ経由）を指し示すことができ、Amazon EMRクラスタを介してPrestoを使用してTableauでクレンジングされたデータにアクセスすることもできます。パイプラインの早い段階でTableauを使用したい理由は、そこにあるものを発見し、分析を開始する前に尋ねるだけの価値のある質問を理解したい場合があるからです。

これらの質問を発見し、この種の分析が長期的な利点を持っているかどうかを判断したら、パイプラインを自動化・最適化し、新しいデータが到着するとすぐに追加して、プロセスや必要な人にデータを渡すことができます。また、このデータを高性能な「Hotter」レイヤー（Amazon RedshiftまたはTableau抽出）にプロビジョニングして、繰り返しアクセスすることもできます。

この事例の詳細については、Tableau 10.4 Supports Amazon Redshift Spectrum with External Amazon S3 Tablesを参照してください。

Amazon Redshift Spectrumを使用すると、ダイナミックパーティションプルーニング（対象外のパーティションのデータをスキャンしない）で処理されたデータを最小限に抑える、高速でコスト効率の高いエンジンが実現しました。スキャンしたデータを減らすことで、クエリのパフォーマンスをさらに向上させるこれを行うには、データを分割して圧縮し、ストレージにカラムナフォーマットを使用します。

１日の終わりに、Tableauで接続するデータソースは、最適化する変数に基づいて選択する必要があります。たとえば、Amazon Athena、Amazon Redshift、Amazon Redshift Spectrumにライブ接続するか、データのサブセットをTableau抽出にインポートすることができます。

検討事項

コスト：Amazon Athenaのサーバーレスコストモデルに慣れていますか？
パフォーマンス：スループットが必要か？
セットアップと時間：Amazon Redshiftクラスタセットアップのリードタイムは大丈夫ですか、すべてをTableauのエキスに入れるだけですか？

顧客の多くのニーズを満たすために、Tableauのアプローチは簡単です。すべてが選択肢です。これには、データへの接続と分析の選択方法も含まれます。

企業のデータアーキテクチャー決定にどのようにアプローチするかについては、Big Data Strategy セッションをご覧ください。私の友人Robin Cottissと私はTableau Conference 2017で提供済みです。Tableau on AWS platformを活用している企業のいくつかの例を紹介し、前述のデモンストレーションの詳細な説明を提供します。

さらに、AWSからのAmazon Redshift Spectrum 10 のベストプラクティスをご確認ください。とりわけ、これは、パフォーマンスの向上を目指して、スキャン集中型の作業負荷を改善し、ストレージを最適化し、クラスタを構成するための推奨事項を提供します。

最後に

『Tuning your Amazon Redshift and Tableau Software Deployment for Better Performance v2』の最終回のAmazon Redshiftクラスタのチューニング編として、ご紹介しました。明らかに古い情報については最新の仕様にアップデートして修正や加筆を加えていますので、ご了承ください。

Amazon Redshift Spectrumと同様に、S3のデータセットに対してアドホックなクエリーを実行できるAmazon Athenaというサービスがあります。ホワイトペーパーの中で紹介されていませんが、こちらもデータソースとしてぜひご検討ください。Tableau 10.3.0以降（日本語のデータは10.3.3以降）からJDBCドライバ経由でデータソースとしてアクセス可能です。

最新のクラスタのチューニングという観点では、Result CachingやShort Query Acceleration(SQA)なども押さえておくことをお薦めします。