Help us understand the problem. What is going on with this article?

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

More than 5 years have passed since last update.

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

Redshiftとは

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

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

特徴をまとめると

  • 使い勝手は、他のAWSサービス同様に必要に応じて簡単に拡張できます、

  • データ抽出のためのSQLは、Postgreペースのカスタム版です。
    抽出のための機能は揃っているので問題なく使えます。
    詳しくは、コチラ をご覧ください。

  • 運用の手間は、バッチ処理の様な比較的時間の余裕がある処理で使う分には問題ないレベルだと思われます。
    1時間/週のメンテナンス時間が必要なのでDBが止まっても問題ない(リカバリできる)処理でないと難しいです。
    また、落とすと再起動完了までに最低1時間程度かかります。

  • アプリケーションからの利用について、まず同時接続可能数が5本/clusterとかなり限られてることから
    フロントから汎用的に使うのは難しいです。バッチ処理またはバックエンドで使うのが適切に思われます。

使い始め

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

PostgreSQLクライアントコンソールから使う

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

psqlインストール(CentOS)

 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から置き換えたという方も費用は3倍となったと言っていました。(Redshiftセミナーにて)
    現状の我々の使い方ではEMR比10倍くらいを見積もっています。使い方が特殊という事情もありますが…

  • データ抽出がSQLで実行できる範囲に制限される。
    SQLで実行が難しいデータ抽出処理をRedshiftでやろうとするのは適さないという意味です。
    SQLはPostgreペースのカスタム版ですが問題ないレベルで使えます。
    EMRでデータを細かいキー毎に時系列に並べ、前後の関係性を見るようなデータ抽出をするような処理は向かないです。
    hiveやpigのようなSQLライクな命令で実行できるデータ抽出は簡単に移植できます。

実用のポイント

  • RDMS、hive等で比較的大きいデータを処理していて運用が大変になって来ている。
    というケースではRedshiftの強みを最大限に生かす事が出来るので置き換えを検討するに値すると思います。

  • Hadoop(hive)で大規模データをバッチ集計していたところを、追加開発の工数削減と誰でもデータ抽出を出来るようにしたい。
    というケースでは、コストアップにはなりますが利点を取って導入を検討することが出来ると思います。

以上です。

今回まで我々の大規模データ処理について全6回アップし予定した連載を終了しました。
「大規模データについていろいろやってみます!(第1回)」
「大規模データについて第2回~EMR(Hadoop)について、なぜEMRなのか〜」
「大規模データについて第3回~EMR開発_基礎編〜」
「大規模データについて第4回~EMR開発_実践編〜」
「大規模データについて第5回~EMR開発_運用編〜」

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

参照

f81@github
Fringe81のエンジニアが頑張って執筆ちゅうです! Scala の修行を始めました。 みなさま、温かい目で見守ってください。
fringe81
Fringeは、最新のテクノロジーとプロフェッショナルによるサービスにより、社会課題に仮説を立てて市場に広げていくことで、数十年という長期的なスパンで価値を生み出し続け、より良い世界を創る集団です。 既存の領域に限らず、時流を読み、仮説を生み出し、テクノロジーの力で優れたサービスを生み出し続けます。
https://www.fringe81.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away