大規模データについて第6回～Redshift編～

Last updated at 2014-01-08Posted at 2014-01-08

大規模データについて最後にRedshiftについて書きます。
使い始めたばかりで実践的な話は少ないですが、現場視点の使用感をまとめました。

Redshiftとは

AWSが提供するデータウェアハウスです。
いわゆるフルマネージドサービス（RDS、DynamoDBと同様）ですぐに使い始められます。
操作項目はRDSに近いです。

詳しくは、コチラをご覧下さい。

使い勝手は、他のAWSサービス同様に必要に応じて簡単に拡張できます、
データ抽出のためのSQLは、Postgreペースのカスタム版です。
抽出のための機能は揃っているので問題なく使えます。
詳しくは、コチラをご覧ください。
運用の手間は、バッチ処理の様な比較的時間の余裕がある処理で使う分には問題ないレベルだと思われます。
１時間/週のメンテナンス時間が必要なのでDBが止まっても問題ない(リカバリできる)処理でないと難しいです。
また、落とすと再起動完了までに最低１時間程度かかります。
アプリケーションからの利用について、まず同時接続可能数が5本/clusterとかなり限られてることから
フロントから汎用的に使うのは難しいです。バッチ処理またはバックエンドで使うのが適切に思われます。

初めて使う方は、AWSの入門ページが丁寧なので、コチラをご参照下さい。

AWSではクライアントツールの「SQL Workbench」を使う事を紹介していますが、
すぐにコンソールから操作したくなるため、その方法を紹介します。

 yum install postgresql

※RedshiftはPostgreSQL 8.0.2ベースです。

セキュリティグループの設定を適切に済ませた後に以下のコマンドで接続します。

psql -U 「ユーザ名」 -p 「ポート（5439)」 -d 「データベース名」 -h 「接続先エンドポイント」

後はいつも通りコンソールから操作できます。

SQLで大規模データの抽出が出来る
この利点は大きく、SQLが書ける人は誰でも大規模データ抽出が出来ます。
インターフェースもpsqlなので、アプリケーションとの相性も良いです。
具体的に使えるSQLはコチラにまとまっています。
データ抽出(select, join, group by)が速い
検索すると色々な情報が出てきますが、マシンスペックに対する性能はhiveと比べて圧倒的に速いです。
使い方によってはコーディングしたMapReduceより速くなるように思えます。
運用がラク
AWSなのでインフラ運用がないのはもちろんですが、大規模データ処理で大変なデータのロードと管理がラクにできます。

利用料が高くなる。
データウェアハウスという特性上、常時稼働させておく事が前提なので、EMRと比べると高くつきます。
上記の利点を取ってhiveから置き換えたという方も費用は３倍となったと言っていました。(Redshiftセミナーにて)
現状の我々の使い方ではEMR比１０倍くらいを見積もっています。使い方が特殊という事情もありますが…
データ抽出がSQLで実行できる範囲に制限される。
SQLで実行が難しいデータ抽出処理をRedshiftでやろうとするのは適さないという意味です。
SQLはPostgreペースのカスタム版ですが問題ないレベルで使えます。
EMRでデータを細かいキー毎に時系列に並べ、前後の関係性を見るようなデータ抽出をするような処理は向かないです。
hiveやpigのようなSQLライクな命令で実行できるデータ抽出は簡単に移植できます。

RDMS、hive等で比較的大きいデータを処理していて運用が大変になって来ている。
というケースではRedshiftの強みを最大限に生かす事が出来るので置き換えを検討するに値すると思います。
Hadoop(hive)で大規模データをバッチ集計していたところを、追加開発の工数削減と誰でもデータ抽出を出来るようにしたい。
というケースでは、コストアップにはなりますが利点を取って導入を検討することが出来ると思います。

以上です。

これからも不定期でアップして行きますのでよろしくお願いいたします〜