情弱のためのRedshiftまとめ
先日、Redshift童貞を卒業しました情弱です。卒業するにあたり困り事がいくつかあったので、そのあたりまとめを作りたいと思います。
そもそもこれなに?
情弱な私はここからのスタートです。データウェアハウス(DWH)でテラバイトクラスでも分析出来るらしいということはわかっていましたが、そこから先がよくわかりません。
これ、つまるところでいうと 集計がめちゃくちゃ速いPostgres です。なので、これを使えばおばあちゃんの病気が治るとかそういった素敵なものではなく、create tableしてデータ入れて、group byしてcount()やsum()するだけです。ただ、DWH用途に特化しているだけあって、通常のPostgresにはない特徴がいくつかあります。
ふつうのPostgresとの違い
私がぱっと気付いたものなので、もっとたくさんあるはずですが、多分主なヤツ。
- サポートしてるデータ型が少ない ※text型はエラーにならないけどvarchar(256)にされるとか
- ユニークキー等の制約は基本効かない
- データ投入の基本はS3のCSVかDynamoから。しかも並列インポート出来る
- クラスタノードを増やすことで、だいたいリニアに性能上がる
- sortkey, distkeyといった普通に無いヤツがいる
- 列指向なので
select *
は基本ダメ。必要なカラムだけ採る - alter table基本NG ※再インポート前提と思っておくと気楽
つかいどころ
私が使ったのはログ解析です。とはいえ、いわゆるRDBベースなのでテーブルを作らないといけないですし、高速に検索する場合はある程度情報を切り出して別カラムに入れる等の準備が必要です。というわけで、そこでやったことのまとめ。
ログ情報のタグ付けとCSV化
採りたい情報はある程度限られていたので、生ログをスクリプトに放り込んで、必要な情報を別カラムに書き出しました。また、その際にDateTimeのフォーマットをPostgresが解釈可能なように直したり、テキストを256文字以下に納める等の整形処理をしています。
ログファイルの分割
S3からの並列インポートが出来るので、一定量で分割してあげます。こんな感じ。これをS3に上げます。
-rw-rw-r-- 1 ec2-user ec2-user 6182167 Oct 2 07:02 access_log-130901.csv.1.gz
-rw-rw-r-- 1 ec2-user ec2-user 5422438 Oct 2 07:05 access_log-130901.csv.2.gz
-rw-rw-r-- 1 ec2-user ec2-user 6343272 Oct 2 07:09 access_log-130901.csv.3.gz
-rw-rw-r-- 1 ec2-user ec2-user 6250919 Oct 2 07:13 access_log-130901.csv.4.gz
-rw-rw-r-- 1 ec2-user ec2-user 7215392 Oct 2 07:16 access_log-130901.csv.5.gz
-rw-rw-r-- 1 ec2-user ec2-user 6502100 Oct 2 07:20 access_log-130901.csv.6.gz
-rw-rw-r-- 1 ec2-user ec2-user 6172786 Oct 2 07:23 access_log-130901.csv.7.gz
-rw-rw-r-- 1 ec2-user ec2-user 5950203 Oct 2 07:27 access_log-130901.csv.8.gz
-rw-rw-r-- 1 ec2-user ec2-user 5311772 Oct 2 07:30 access_log-130901.csv.9.gz
Redshiftへのインポート
普通にpostgresクライアントで接続し、普通のpostgresっぽく操作します。こんな感じ
CREATE TABLE access_logs (
date timestamp sortkey,
message varchar(256),
user_name varchar(256),
ipaddr varchar(15),
error_type varchar(256)
);
copy access_logs from 's3://bucket/data.csv' gzip credentials 'aws_access_key_id=aaaaaaaaaaaa;aws_secret_access_key=aaaaaaaaaaaaaaaaaaaa' delimiter '|';
ここでのポイントはS3のパラメータ部分で、この例だとdata.csv
というファイル名になっていますがこれ、分割していてもそれを追っかけてくれるのと、なおかつそれがgzip圧縮されていても追っかけてくれます。なので、実体は以下のような状態で大丈夫です。
s3://bucket/data.csv.1.gz
s3://bucket/data.csv.2.gz
s3://bucket/data.csv.3.gz
s3://bucket/data.csv.4.gz
ふつうにselect
Postgres対応のBIツールとかも使えますが、詳しくないのでそこは割愛。普通にselect文を発行していろいろやってください。
さいごに
Redshiftは何を入れても何でも出来るものではなくて、「できることが限定的な反面、かなり速い処理が出来るもの」だと思ってます。なので、いろいろ考えるのであればHadoop系の方がやれるでしょうし、お手軽さで言えばスキーマレスなもの(JSONベースとか)の方が強いと思います。使いどころはちょっと難しいですが、数百億件を普通に処理できる時間貸しはRedshiftだけだと思うので、うまく付き合っていきたいところですね。