第2回　Amazon Redshiftとは［後編］

前回はAmazon Redshiftの基本的な機能の説明を行いました。今回は一歩踏み込んで、具体的にAmazon Redshiftはどのように利用することができるのか、また他のデータウェアハウスやHadoopなどのビッグデータ処理ミドルウェアと比べて、どのような点が優れているのかを説明します。

Amazon Redshift の得意な点・不得意な点

前回の説明のように、Amazon Redshiftはクラウド上に構築されたデータウェアハウスサービスです。そのため、蓄積された大量データの集計処理に特化されています。

たとえば、過去半年分の全データに対する日付ごと・属性ごとのアクセスユーザの件数を一覧で出力する、などです。これに対して、通常の（行指向）データベースの利用方法である、ある特定のユーザの、特定のデータを取得する、などの処理は、たとえ1件を取得するだけでも数秒かかることがあります。つまり、レスポンスタイムが重要なオンライントランザクション処理（普通のWebアプリケーションの処理を思い浮かべてください）を行うデータベースとしては、あまり向かないということができます。

また、データベース内のデータ量が少ない場合でも、やはり処理に数秒の時間がかかることがあります。つまり、集計処理の場合であっても、ある程度のデータ量がすでにあるか、将来的にデータがTB級に大きくなることが予想されている場合に利用するというのが良いでしょう。

Amazon Redshiftとその他のビッグデータ技術との比較

次に、他のビッグデータ技術との比較を見て行きましょう。

他のデータウェアハウスとの比較

もしAmazon Redshiftと何かを比較することを考えると、まず他のデータウェアハウスとの比較が通常考えられます。しかし実は、これを実行してそのベンチマーク結果を公開することはできません。なぜなら、エンタープライズ向けデータウェアハウス製品（IBM NetezzaやTeradataなど）は、利用者との契約で大抵ベンチマーク結果を公開することを禁じているためです。そのため、比較するのは公開されているスペックからのみとなります。

その場合、基本的な機能としては前回説明したカラムナーデータベースやそのデータエンコーディング、またMPPなどの機能についても、Amazon Redshiftはその他の先進的なデータウェアハウスと大差がないことがわかります。やはり最大の違いは“⁠クラウド上にあるか⁠”⁠、ということと提供価格ということになるでしょう。価格差については、前回の記事に書いたとおり、Amazon Redshiftは圧倒的な価格優位性を持っています。筆者の所属するHapyrusにも、TCO削減を目的とした、これらの他社データウェアハウス製品からの乗り換えの問い合わせが多数届いています。それらの多くの利用企業は、現状あまりクラウドを利用していないようですが、この価格差のためにクラウドを利用してもいいという会社が多いのが印象的です。

Hadoop＋Hiveとの比較

最近であればビッグデータ技術として、真っ先に思い浮かぶのがHadoopとなるでしょう。実はHapyrusでは、Amazon Redshiftが登場するまではHadoopとそのSQL言語コンポーネントであるHiveを利用した、データアナリスト向けのWebサービスを提供していました。なぜなら、それまではTB級／10億件を超えるようなデータは、通常のデータベースでは取り回しが難しく、たとえばアドネットワークのような、データは多いが顧客へのレポート作成などが必須のシステムでは、Hadoopを利用する必要があったためです。また、データアナリストは直接Hadoopの処理記述言語であるMapReduceでプログラムを作成するのが困難なため、非常に広い範囲でHiveは利用されています。

※注意：今回の比較では、Hive以外のHadoop用途の比較はしていません。自然言語処理や機械学習などの複雑な全件処理は、依然Hadoop向きの処理だと言えます。

そこでまず筆者らは、自分たちの専門性を生かして、Amazon RedshiftとHadoop+Hiveの比較を行いました。その結果がこのベンチマークです。同じデータ、同じSQLなのですが、明らかにAmazon Redshiftの方がクエリスピードが速く、またアドネットワークのような頻繁なクエリ実行環境では、コスト面でも非常に有利ということがわかりました。

もうひとつ、Amazon RedshiftとHadoopの比較で重要な事実としては、RedshiftはHadoopに比べて、非常にリソース消費量が少なくて済む、ということです。これはあまり議論されていない点ですが、実はRedshiftがホストされているAmazon上のインスタンスは、比較的少ないリソースで動作しています。

ECU（EC2 Computing Units：AWS上のCPU能力を表す値⁠）⁠ 4.4というのは、AWSをよく利用されている方だとおわかりかもしれませんが、CPUをよく使う処理を行うインスタンスタイプの、エントリーモデルであるc1.medium（ECU5）よりも少ない値です。Hadoopなどの大量分散処理サーバは、複数台のノードを利用することで処理量を稼ぎますが、大部分はCPUリソース（と必要に応じて大量のメモリ）を必要とします。たとえば、筆者が経験した例だと、1TB超のデータに対して、c1.xlargeインスタンス（ECU20）を15台使って、5時間かかるような処理を行なったことがあります。その間、CPUはフルに利用され続けていました。Redshiftでの集計処理であれば、それよりもっと少ないリソースで計算を行うことができます。

これは全件処理するのが基本のHadoopと、圧縮されたカラムごとの処理のみでよいRedshiftとの、処理量自体の差が現れています。クラウド環境上では、CPUやメモリ使用量の差は、すなわち利用コストの差として現れてきます。少ないリソースで動作するAmazon Redshiftは、非常にエコノミー（またエコロジー）であると言えるでしょう。

NoSQLデータベースとの比較

Amazon RedshiftはPostgreSQL（RDBMS）ベースのデータベースのため、NoSQLデータベースのうちの、MemcachedやRedisなどのKVS（キーバリューストア）とは、利用方法が根本的に異なります。キーによって値を取ってくるだけの用途には、全く向かないと言えるでしょう。また、KVSは原理的に、全体を横断する集計処理は非常に苦手です。よって、データウェアハウスとKVSは、両極端なデータストアであり、あまり比較する意味がないとも言えます。

また、他のMongoDB、Cassandra、HBaseなどの様々なNoSQLデータベースとRedshift（というよりデータウェアハウス製品全般）を比較しても、NoSQL側は単純にある列を集計するという用途に向いている、というには難しいデータ構造なので、Redshiftが提供するもの（OLAP）とはかなり異なると考えられます。

Amazon RedshiftとHadoopの組み合わせ利用

Amazon RedshiftのFAQに、AmazonのHadoopサービスであるElastic MapReduce（EMR）とRedshiftの使い分けの例が出ています。それによると「Amazon Redshiftは長期的にデータを保存し、SQLやBIツールでデータを分析するのに向いている。EMRでは、その前処理を行うためにはおすすめするが、データをその中に保存するものではなく、あくまでも一時的なものとして使うほうが良い」ということです。

筆者が聞いた話だと、シリコンバレーのある大手ウェブサービス企業でも、Hadoopとデータウェアハウスをそのように利用して成功しているとのこと。Hadoop（EMR）＋Redshiftという組み合わせも、近い将来良い事例がたくさん出てくるかもしれません。

Amazon Redshiftの具体的な利用例

では、Amazon Redshiftはどのような場面で利用されていくのでしょうか。まず考えられるのは、クラウド上でTB級のデータを処理できるプラットフォームとして、今までHadoop＋Hiveで処理していたアドテクノロジやデジタルマーケティング、ソーシャルゲームなどの会社のシステム、たとえばレポーティング機能や最適化データの作成などに利用できると考えられます。実際、Hapyrusへの問い合わせも、現時点ではこれらのシステムのために利用することを検討している会社がほとんどです。

たとえばアドネットワークを考えてみると、一番サイズが大きく、かつ重要なデータは、広告ログ表示（impression）情報となります。また、サイズは落ちますがクリックデータやモバイルアプリ用であればインストールデータなどもとても重要です。それらをRedshiftに取り込み、定期的に集計を行なってMySQLなどの行指向データベースに格納しておき、広告レポートの元データとします。

このように、Amazon Redshiftは、ビッグデータの一次格納場所として利用することができます。あとは、この広告レポート作成のように必要な情報を取り出すということを、必要に応じて行えばいいわけです。このような処理方法を、一般的なETL（Extract、Transform、Load）と比較して、ELT（Extract、Load、Transform）といいます。Extractはログからの抽出、LoadはRedshiftへのインポート、Transformはその中でのクエリ実行による（別データベースへの）別テーブルへの加工、と位置づけることができます。ELTは、データベースがパワフルである必要があるのですが、場合によってはETLでは難しい処理を、とても高速に処理することができます。ELTは、ある程度元データが整っている（たとえば元ログがJSON形式である、など）場合に利用しやすい形式です。そうでなければ、Hadoopや他のELTツールでまずは加工するというのが有力な方法でしょう。

前回と今回で、Amazon Redshiftの機能やメリット・デメリットなどを説明しました。次回からは、Amazon Redshiftの具体的な利用方法や、より深い技術的な特徴を説明していきます。

筆者が所属する Hapyrusでは、Amazon Redshift を使いはじめるための継続データインテグレーションサービスFlyData for Amazon Redshiftを提供しています。また、Amazon Redshift の導入コンサルティングも無料で行なっていますので、興味がある方はぜひお気軽に info@hapyrus.com にお問い合わせください。