S3へのデータアップロード
ファイルはタブ区切りテキストを1億レコード単位（数GB程度）に分割した後、gzip圧縮したものを転送しました。COPYコマンドのオプションで複数の圧縮ファイルを並列にRedshiftにロードできること、転送時間の節約が主な理由です。データ量が多いとアップロードにも時間がかかってしまいます。転送速度から、ある程度の転送時間を見積もっておくと良いでしょう。
S3のバケットは、Redshiftと同じリージョンに作成しましょう。筆者は、S3バケットを東京リージョンに作成し、米国東部リージョンのRedshiftクラスタにデータをロードしようとして失敗しました。TB級のデータをS3にアップロードする時間を無駄にしないためにも、小さなデータセットをアップロードして、S3からRedshiftにデータロードできることを確認してから、分析対象データをS3にアップロードするのがよいでしょう。
S3からRedshiftへのデータロード
EC2インスタンスにログインしたら、psqlを起動し、COPYコマンドでロードします。100MB未満のデータなら、数十秒でロードが完了します。筆者は1.5TBのデータセット（3カラム、約400億レコード）をロードするのに、約4時間かかりました。
データロードが長時間におよぶ場合、ロード中に何レコードがテーブルに入っているか、途中経過を見たい場合があります。しかし、ロード中のテーブルに対してSELECT COUNT(*)を実行しても、なかなか結果が返ってきません。
次のSQLで確認すると、tablenameというテーブルのレコード件数を比較的早く知ることができます（それでも7～8秒かかります）。
select trim(name) tablename, col, to_char(sum(num_values), '999,999,999,999') count from SVV_DISKUSAGE where name = 'tablename' group by name, col order by 1, 2;
分析
あとはクエリを実行するだけです。クエリを書いたファイルをEC2インスタンスに置いて、psqlコマンドで実行して結果を待ちましょう。
また、必要に応じて標準出力や標準エラー出力の結果をファイルに保存します。
$ (psql -a -f sample.sql) >& sample.log &
分析クエリの実行結果を別のテーブルにINSERTしようとしたら、ディスクを使いきって異常終了、ということが使っているときに起こりました。データ量の見積りはとても重要です。
tablenameというテーブルがどれくらいのディスクを使用しているかを確認する場合は、次のSQLを実行します。sizeの単位はMBです。
select trim(name) name, count(*) size from SVV_DISKUSAGE where name = 'tablename' group by name order by 1;
AWS Developer Forumsはこまめにチェックしよう
クエリの異常終了はDisk Fullだけが原因ではありません。時々メンテナンスでダウンタイムが発生していたり、原因が特定できないエラーも何度か経験しました。
AWS Developer Forumsでは、メンテナンスの告知やユーザからの質問をチェックできます。使用中におかしな事象に遭遇した場合は、似た事象が報告されていないか確認してみてください。
まとめ
Amazon Redshiftを使ったデータ分析において、筆者が実際につまずいた点も含めて紹介しました。
特にお伝えしたいのは、効率よく分析を行うためには、入念な事前準備が重要だということです。当たり前のことかもしれませんが、データ転送時間の見積り、テーブル設計、分析クエリの作成、実施計画などはできるだけ事前にやっておくこと、小規模のデータセットでひととおり確認することをおすすめします。
まだ日本国内から発信される情報は少ないですが、本記事をきっかけに多くの事例が出てくることを期待しています。
