新機能『Redshift Spectrum』の内部構造を考察する

はじめに

こんにちは、yokatsukiです。

日本時間2017/04/20深夜に発表されたAmazon Redshift(以下Redshift)の新機能『Redshift Spectrum』、RedshiftからS3のファイルを直接参照できるということで熱い視線を浴びています。弊社でも早速使ってみて、多数の"試してみた"記事を書きました。

ドキュメントを参照していると、機能としてAmazon Athena(以下Athena)を利用しているような文言がいくつもあり、またこれら検証記事を書いている内に、Redshift SpectrumがS3へアクセスする際に、裏側でAthenaを使っているのは確実になってきました。本エントリでは、その調査結果を皆さんと共有します。

最初に結論

Redshift SpectrumのS3アクセス機能は、裏でAthenaを利用している
Redshift Spectrumは、AthenaとRedshiftを連携する部分の実装である

RedshiftとAthena、S3の連携イメージは以下の形になることがわかってきました。
※画像はクリックで拡大できます。

以下、確認の項で詳しく検証していきます。

確認

外部テーブル作成までの流れ

Redshiftクラスタから、Redshift Spectrumを使用してS3上のファイルを外部テーブルとして使えるようになるためには、以下の作業が必要になります。

IAMロールの作成とRedshiftクラスタへの適用
S3へファイル配置
外部スキーマの作成
外部テーブルの作成

これらの手順において、裏側ではどのようなことが起きているのかを確認します。

IAMロールの作成とRedshiftクラスタへの適用

RedshiftがAthena経由でS3ファイルにアクセスできるようになるためには、Redshiftに以下の権限が必要になります。

Athenaデータベース作成
Athenaテーブル作成
S3ファイルアクセス

これらをができるようになるマネージドポリシーがAmazonS3ReadOnlyAccessとAmazonAthenaFullAccessの2つに該当するわけです。

これらをロールとしてまとめ、Redshiftクラスタに適用することで、データ連携を実現しています。

S3へファイル配置

Redshiftと同じリージョンにS3バケットおよびフォルダを作成し、テーブルとして読み込みたいファイルを配置します。

この作業について特記することはありませんが、RedshiftクラスタにAmazonS3ReadOnlyポリシーが与えられているので、配置したファイルはRedshiftクラスタが読める状態になっています。

外部スキーマの作成

以下のようなCREATE EXTERNAL SCHEMA文で外部スキーマを作成します。

CREATE EXTERNAL SCHEMA spectrum_schema
FROM DATA CATALOG
DATABASE 'spectrum_database'
IAM_ROLE 'arn:aws:iam::012345678901:role/Redshift-Spectrum-Role'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

この時、新規に作られたRedshiftのスキーマspectrum_schemaの裏側で、自動的にAthenaのデータベースspectrum_databaseが作成され、Redshiftスキーマとの関連付けが行われています。

ここで、RedshiftスキーマとAthanaデータベースが関連付けられるところがポイントになります。このSQL実行後にAthenaの設定を確認してみると、データベースspectrum_databaseが作成されていることがわかります。

システムカタログテーブルでも、Redshiftのスキーマspectrum_schemaとAthenaのデータベースspectrum_databaseが関連付いていることが確認できます。

SELECT * 
FROM pg_external_schema pe 
JOIN pg_namespace pn
ON pe.esoid = pn.oid;

細かい挙動：外部スキーマを削除した場合

ちなみにここで外部スキーマを削除した場合はどうなるでしょう？

DROP SCHEMA spectrum_schema;

この操作によって、外部スキーマは削除され、システムカタログテーブルのエントリも削除されます。しかし、外部スキーマを削除してもAthenaのデータベースは残ります。

完全に削除したい場合は、別途AthenaからDROP DATABASE文を発行する必要があるので気をつけておきましょう。

細かい挙動：同名のAthenaデータベースが既にある場合

同名のAthenaデータベースが既に存在していても、外部スキーマ作成においては特にエラーは発生しませんでした。その点ではCREATE EXTERNAL DATABASE IF NOT EXISTS句の存在は関係なさそうです。

細かい挙動：Athenaデータベース作成忘れの場合

逆に、Athenaデータベースが存在しない状態で、かつCREATE EXTERNAL DATABASE IF NOT EXISTS句を付けずに外部スキーマを作成した場合はどうなるでしょう？確認したところ、外部スキーマ作成時にはエラーは発生しません。システムカタログテーブルにもきちんと紐付けの情報が書きこまれます。

しかし、外部テーブルを作成する段階で、Athenaデータベースが存在しないとのエラーが発生します。

従って、このような事態が起きないためにも、外部スキーマの作成時には、CREATE EXTERNAL DATABASE IF NOT EXISTS句は付けておいた方が良さそうです。

外部テーブルの作成

CREATE EXTERNAL TABLE文で外部テーブルを作成しますが、この際に内部ではAthenaのテーブルが作成され、Redshiftのテーブル情報との関連付けが行われています。これによって、Redshiftからテーブルを確認することができ、かつそのテーブルへの問合せがAthenaを経由してS3へと繋がることになるわけです。

細かい挙動：外部テーブルの削除

作成した外部テーブルを削除してみましょう。外部テーブルの削除はスキーマの削除と異なり、Athenaのテーブルは削除されます。

ただし、S3上のファイルは残っているので、再びCREATE EXTERNAL TABLE文で外部テーブルを作成することは可能です。

まとめ

Redshiftの新機能、Redshift Spectrumの挙動を確認し、内部構造に迫ってみました。一通り調べると、より気になる点が発生するわけで、

Redshift Spectrum使用と、Athena単体使用の場合分け
それぞれの場合における適、不適のシチュエーションや、コスト、性能の違い

などについて、今後も継続して調査したいと思います。

おまけ「AWS妄想劇場」

このエントリを書いている最中に交わされた、弊社社員達の会話：

A「RDSとかDynamoDB対応とかも出そうな気がする。」
B「RDS、特にAurora対応は出してもおかしくないですが、DynamoDBは性能命な筈なので、対応はしないのではないかと想像してます。」
A「Spectrumの言葉の意味は周波数なので、いろんなプロダクトに周波数を合わせるのではと予想」
B「Spectrumは、Redshiftの元々の意味(赤方偏移)に掛けてる感じがするんですよね。なので基本的にはRedshift専用なんじゃないかと。ただ、オーロラも光学現象なので、絡めるのはアリかと(自分で言ってて面倒くさい人になってきた感が)」
C「Aurora SpectrumでAuroraの外部テーブルとしてAthena経由S3はアリかなと。」
A「天体に磁場を発生させるメカニズムをダイナモ効果という。（俺も面倒になってきたw）」
D「ぽえまーがたんじょうしそうなふいんきになってきた」

Spectrumの将来が楽しみです。それでは、また。

前の記事へ