【速報】半構造化データをRedshiftテーブルに直接保存できる新しいデータ型『SUPER』をサポートしました(preview) #reinvent

2020.12.10

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

JSON や Nested Parquet などの半構造化データをローカルテーブルに直接取り込み、分析可能が可能になる新しいデータ型 SUPER がサポートされました。

半構造化データはSUPER型のカラムにそのまま格納し、SUPER型のデータとPartiQL言語を使用して、データウェアハウス機能を拡張し、SQLとNoSQLの両方のデータソースと統合します。このようにして、Redshiftは、JSONなどのリレーショナルおよび半構造化された保存データの効率的な分析を可能にします。

※ 以降の解説は、非構造化データはJSONを例に解説しますが、Nested Parquetでも基本的には同じ考えになります。

新しいデータ型『SUPER』とは

Redshiftのストレージに半構造化データのロードの課題

Redshiftのストレージに半構造化データ、例えばJSONファイルを読み込むには、別途マニフェスト作成して読み込む必要があり、更にNested JSONはサポートしていませんでした。そのため、Nested JSONファイルは事前にデータファイルをAWS Glue JobでETL(Relationalize)して、構造化データに変換した後、Redshiftに取り込む必要がありました。

半構造化データを直接保存できる新しいデータ型『SUPER』

データ型『SUPER』は、スキーマ定義を指定せずにJSONテキストをそのまま格納できます。そのため、データをロードする際にスキーマを意識することなくロードができて、クエリする際にJSONのキーを指定して値を取り出します。

つまり、スキーマをあまり理解していないJSONファイルを、まずはSUPER型のカラムに格納して、それから探索的にデータの中身を確認することができます。

また、スキーマレスであるということは、JSONのフォーマットに変更が生じたとしても、テーブル定義の変更は不要で、参照クエリを修正するだけで対応できます。

新しいデータ型『SUPER』の使用例

previewはブログに書けないのですが、実例を挙げないとイマイチ理解できないと思いますので、マニュアルをベースに、あくまでも、仮に動かしたらこうなるという前提での解説になります。(間違いがあったらすいません。)

まずは、rdataというSUPER型のカラムを持つテーブルを作成します。

CREATE TABLE region_nations_noshred (rdata SUPER);

単一のrdataというSUPER型のカラムにデータを取り込むには、FORMAT JSON句でnoshredオプションを指定します。

COPY region_nations_noshred 
FROM 's3://redshift-downloads/semistructured/tpch-nested/data/json/region_nation' 
REGION 'us-east-1' 
IAM_ROLE 'arn:aws:iam::xxxxxxxxxxxx:role/Redshift-S3' 
FORMAT JSON 'noshred';

COPYコマンドでJSONを正常に取り込んだ後、region_nations_noshredテーブルには、単一のrdataというSUPER型のカラムにJSONオブジェクト全体のデータを含まれます。取り込んだデータは、JSON階層のすべてのプロパティを維持しますが、リーフは効率的なクエリ処理のためにAmazon Redshiftスカラータイプに変換されます。

次のクエリを使用して、元のJSON文字列を取得します。JSONがそのまま表示されます。

SELECT rdata FROM region_nations_noshred;
rdata
-------------------------------------------------------------------------------------------------------------------------------
{"r_regionkey":0,"r_comment":"lar deposits. blithely final packages cajole. regular waters are final requests. regular accounts are according to ","r_name":"AFRICA","r_nations":[{"n_comment":" haggle. carefully final deposits detect slyly agai","n_nationkey":0,"n_name":"ALGERIA"},{"n_comment":"ven packages wake quickly. regu","n_nationkey":5,"n_name":"ETHIOPIA"},{"n_comment":" pending excuses haggle furiously deposits. pending, express pinto beans wake fluffily past t","n_nationkey":14,"n_name":"KENYA"},{"n_comment":"rns. blithely bold courts among the closely regular packages use furiously bold platelets?","n_nationkey":15,"n_name":"MOROCCO"},{"n_comment":"s. ironic, unusual asymptotes wake blithely r","n_nationkey":16,"n_name":"MOZAMBIQUE"}]}
(1 row)

恐らく、カラムに rdata.r_regionkeyを指定すると、0が取れるはずです。

SELECT rdata.r_regionkey FROM region_nations_noshred;
rdata.r_regionkey
-----------------
                0
(1 row)

SUPER型の使用(Preview)

SUPER型の使用は、執筆時点では、Previewであるため、Redshiftのメンテナンストラックをsql_previewに変更(Modify cluster)してクラスタを再起動すると反映されます。

SUPER型のユースケース

SUPERデータ型を使って半構造化データの取り込むと、使いやすく、優れたパフォーマンス、柔軟性が得られます。「使いやすく」と「柔軟性」はスキーマレスの特性であり、優れたパフォーマンスはリーフを効率的なクエリ処理のためにスカラータイプに変換して格納されるためです。

JSONデータの迅速かつ柔軟に取り込みしたい場合

Redshiftは、JSONを解析してSUPER型として保存できる高速なトランザクションをサポートしています。挿入トランザクションは、SUPERの属性を従来の列に細断処理したテーブルに同じ挿入を実行するよりも最大5倍高速に動作できます。

また、SUPER型は通常のスキーマを必要としません。JSONを保存するために、事前にデータ構造を確認してクリーンアップする必要はありません。クエリするときにデータを確認すればよいのです。

データ探索目的で柔軟にクエリしたい場合

半構造化データ(JSONなど)をSUPER型に格納した後、スキーマを課すことなくクエリを実行できます。PartiQL動的型付けと緩いセマンティクスを使用してクエリを実行し、クエリの前にスキーマ定義することなく、深くネストとされたデータを柔軟に探索できます。

ETL目的の簡単なクエリでマテリアライズドビューを作成したい場合

スキーマレスおよび半構造化データをSUPER型に格納した後、PartiQLマテリアライズドビューを使用して、データ構造を確認した後、マテリアライズドビューに共有できます。

非構造化データは、マテリアライズドビューでラップすることで、パフォーマンスと構造化された使いやすさの利点が得られます。特にBIツールとの連携では効果的です。

最後に

発表されたばかりのデータ型『SUPER』の使い方を、なんでそんなに詳しいかというと、Snowflake(というDWH)の非構造化データの取扱いとほぼ一緒なのでサラッと読んだだけで理解できました。JSONを始めとする非構造化データの取扱いは、SUPER型の方が高速で柔軟です。今後の非構造化データは、とりあえずSUPER型に取り込み、取り込んだあとに探索的にクエリを実行するのが標準的な使い方になると考えられます。