Amazon Redshiftのクエリを10倍速くするAQUA

米国時間12月3日、AWSのre:InventカンファレンスでCEOのAndy Jassy(アンディ・ジャシー)氏は、同社のデータウェアハウスサービスであるAmazon Redshif向けのAQUA(Advanced Query Accelerator)を発表した。ジャシー氏が基調講演で述べたように、データを分析する際にデータウェアハウスをスケールすることは難しい。データウェアハウスやデータレイクが大きくなると、現在の高速ネットワークや高速チップをもってしても、ある時点でデータはネットワークや利用可能なコンピューティングを圧迫し始める。AQUAはこれに対処するためのもので、基本的にはハードウェアアクセラレーションキャッシュであり、クエリのパフォーマンスはクラウドベースのデータウェアハウスのコンピューティングに比べて10倍速くなるという。

同氏は「コンピューティングのためにどれほどのデータがネットワーク上で移動しなくてはならないかを考えてみてほしい。今はこのことが問題になっていない企業でも、生成されるデータの量を考えれば、すぐに問題になるだろう」と述べた。

ジャシー氏は「AQUAは求められるコンピューティングのパワーをストレージレイヤーに直接もたらす。Amazonの標準的なS3サービスの上位にキャッシュが置かれるため、必要な数のノードに必要なだけスケールできる」と説明した。

AWSは、このサービスを実現し、データ圧縮と暗号化をオンザフライで高速化するために、独自の分析プロセッサを設計した。当然、このサービスはRedshiftの現在のバージョンと100%互換性がある。

同日、AWSはさらに、Redshiftの次世代のコンピューティングインスタンス、RA3インスタンスも発表した。48個のvCPU、384ギビバイトのメモリ、最大64テラバイトのストレージを備える。これを利用して最大128インスタンスのクラスタを構築することができる。

[原文へ]

(翻訳:Kaori Koyama)

シリコンバレーで勝負できる条件がそろった、FlyData藤川氏が5年目につかんだマーケットフィット

photo

シリコンバレーで起業した日本人の1人から、ちょっと明るいニュースがTechCrunch Japanに届いた。

ビッグデータ解析関連スタートアップの「FlyData」を率いる創業者の藤川幸一氏が、総額約2億円の追加資金調達に成功して、成長軌道に乗り始めたという。今年2月に活動を開始したばかりのオプトベンチャーズが今回7月1日に情報公開されたラウンドで新規出資したのをはじめ、すでに以前のラウンドで投資しているニッセイ・キャピタルや個人投資家の西川潔氏、新規でドワンゴ取締役の夏野剛氏、クロスカンパニー代表取締役の石川康晴氏ら個人投資家数名やバリュー・フィールド(代表は市川貴弘氏)も今回のラウンドで出資している。

website

シリコンバレーで戦うスタートアップとして2億円という金額は決して大きくない。だから、ぼくは今回の資金調達からは、どちらかと言えば次のシリーズAへ向けたブリッジ・ファイナンスというニュアンスを感じた。実際、藤川氏に話を聞けば、創業5年目にしてついに米国内でのビジネスを大きくスケールさせられる手応えを感じているというから、どこかでアクセルを踏み込むのかなと見ている。

photoこれまでのFlyDataは創業2年目の2012年にチームが空中分解してシリコンバレーで1人きりになったり、プロダクトが日本の限られた会社にしか売れなかったりと、何度か苦しい時期があって、「針の穴を通すような生き残り方」(藤川氏)をしてきたという。それがいま、初めて「グローバルマーケットでプロダクト・マーケットフィットをつかんだ」と、成長軌道に乗ったと感じているという。

まだFlyDataは「シリコンバレーで成功した」と言える段階ではないし、これからが本当の勝負というところ。だから藤川氏はTechCrunchのようなメディアで「語る」ことに積極的ではない面もあって、今回の資金調達についても特に何か情報発信しようとは思っていなかったそうだ。このインタビュー記事は、たまたま6月末の週末に東京で行われたSkyland Ventures Fest Tokyo 2015(SVFT)というイベントで、ぼくが藤川氏と立ち話したことがキッカケとなっている。現在進行形であるにしても、そのチャレンジを広くシェアさせてほしいということで改めて藤川氏にSkypeで話を聞かせてもらった形だ。

5年目でつかんだ「マーケット・プロダクトフィット」

FlyDataの創業から現在までを少し振り返ろう。

藤川氏はもともと2009年のIPAの未踏事業でHadoopのミドルウェアを作成するというプロジェクトで採択されたことがあり、それがFlyData創業のきっかけになっている(創業時の社名はHapyrus)。当時藤川氏は、後にヤフージャパンに買収されることになる携帯電話向け位置連動広告のシリウステクノロジーズでプロダクトマネージャーをしていた。昼はプロマネ、夜はIPAのプロジェクトを進める二重生活を送っていた。シリウステクノロジーズがヤフーに買収され、スタートアップのM&Aのダイナミックさを感じて、自らも起業。どうせやるならシリコンバレーでとの思いから、未踏でのプロジェクトを元に会社化した。

日本のVCやエンジェルから約5000万円を資金調達して渡米。著名アクセラレーターの500 Startupsに入ることができ、さらに追加資金調達もできたものの、苦戦した。苦戦の理由の1つは、シリコンバレーにはHadoop関連の競合が多数いたこと。有名投資家によるHadoop関連スタートアップなんかもあって顧客獲得に苦労したという。さらに、「英語ができない、スタートアップのことも分からないという状態でシリコンバレーに来ていた」ことから現地の日本人コンサルタントに入ってもらっていたが、そのアドバイスを巡って共同創業者と意見が対立してしまったという。当事を振り返って藤川氏は言う。

「たとえそれが経験豊富なコンサルタントや投資家であっても、自分が起業したことがない、さらにいうとその時にその事業をやっていない人のアドバイスは所詮アドバイスなんです。それを自分でどう考えて実行するのかは起業家自身が決めること。自分の意思でやっていくしかないんです。どんなにすごい人から意見をもらったりしても」

まだ意味のあるプロダクトが世に出ていない状態だったこともあって意見は割れた。結局、そのコンサルタントと共同創業者は会社を去り、藤川氏は1人だけになってしまったという。

「物を作れない人間だったら、そこで終わっていたと思います。実際、危機的な状況でした。知り合いにはもうダメじゃないか、事業たたむことを考えたほうがいいということも言われたりして。(マーケットフィットした)プロダクトもまだできていなかったんですよね」

「ただ、自分は何とかしてやるという気持ちもあったし、(DeNA共同創業者の)川田さんや、(VCのアーキタイプ)中嶋さんなど、投資家たちは支えてくれました。個人投資家の皆さんに支えられ、500 Startups創業者のデーブ・マクルーアも人に紹介してくれたりして。1人だったけど、1人じゃなかったんですよね」

最初のピボット、そもそもクラウドにデータが存在していないことが課題

Hadoopによるクラウドビッグデータ処理を軸に起業していたが、やがて別のニーズに気付いたという。「そもそもクラウド上にデータがない。これではクラウド上のビッグデータ分析ツールは、お客さん使わないな、と気付いたんです。まずオンプレミスからクラウドにデータを送らないといけないな、と」

この頃にWantedlyで募集をしたところ「グリーンカードを当てて、次週どうしようかというタイミングだった日本のエンジニアがいて応募してくれた」のだそうだ。「さらに未踏出身の貴重な人材で、ラッキーでした。スタートアップはラッキーが必要だなと思っています」。

2012年にオンプレミスからクラウドへデータを移すというプロダクトを作った。ログデータをAmazon S3に入れるプロダクトだ。ただ、これは「面白いけど使われなかった。ユーザーの大きなペインポイントではなかったということ」。ところがこのプロダクトが後への布石となる。

Amazon Redshift登場で走った激震と、再度のピボット

2012年末に突如として追い風が吹き始めた。この年の11月、AWSの年次イベントであるre:inventで大きな発表があったのだ。クラウド上でデータウェアハウス(DWH)を実現する「Amazon Redshift」が発表されたのだ。DWHは大規模データの分析を行う古くからあるエンタープライズ向けのソリューション。IBMのネティーザや、HPのバーティカといった専業ベンダーのソリューションが数千万円とか数億円するところ、AWSはクラウドに入れただけで年額1000ドルで使えるようにしてしまった。しかもサーバがクラウド化したときと同じで、規模拡張の対応が極めて短期間でできるようになった。

藤川氏は、このクラウドのデータウェアハウスの出現を「激震が走った」と振り返る。それまでHadoopがDWHをディスラプトするテクノロジーと見られていたが、DWHそのものが、いきなりクラウドで容易に利用可能になってしまったのだ。HadoopはDWHをディスラプトはしていたものの、MapReduceやHive、Pigといった独自言語の存在など使いづらい面もあった。一方、RedshiftはベースエンジンがPostgreSQLベースなので、基本的に通常のSQLでオッケーなのだそうだ。

まだリリースされていなかったRedshiftだが、FlyDataは再びピボット。500Startupsの助けもあり、数千倍の応募倍率をくぐり抜けて、Redshiftへのプレビューアクセスの権利を取得。翌年2月の一般公開のときには、4日間かけて取ったHadoopとRedshiftのベンチマークをHackerNewsに投稿してバズらせた。

ただ、これも思ったほど上手くいかない。最初はこのRedshift対応プロダクトはHerokuのアドオンとして提供した。手応えがあったものの、Herokuのアドオンは総じて課金が少額だし、さらにそこまで顧客数が増えない。だから、マーケットとしては小さかったという。Heroku利用者は、サービスが大きくなると別のプラットフォームを考え始めるという問題もあったそうだ。結局、国内でゲームやアドテク企業に利用されたものの、アメリカ市場でFlyDataの利用は広がらず。それは、アメリカではログデータをデータベースに直接入れるという文化がなかったことも背景にあるという。

ここでまた別の問題が出てくる。顧客データはMySQLなどのRDBに入っている。これは日米で変わらない。これを、Redshiftのようなカラムナーデータベースにスムーズに入れるのは実は難しい。

RDBとカラムナーの違いは、Excelの表の縦と横を無理やり入れ替えるような話だ。データベースといえばRDBを指すのが一般的だが、これは行指向。ユーザーのレコードを検索して引っ張ってくるようなことは極めて高速に行える。しかし、ユーザー数が増えてテーブル数もそれなりにあるアプリケーションだと、特定フィールドの集計を行うといった処理に時間がかかるようになる。カラムナーデータベースは、文字通りカラム(列)指向で、縦方向のデータ圧縮もしているため、RDBに比べてある種の集計処理が劇的に高速化する。初期ユーザーであるクラウドワークスやSansanなどで10時間かかるバッチ処理がFlyData+Redshift導入で1分程度になった例もあるという。

RDBのデータをカラムナーに移行するには、1度入れ替えをするだけならエイヤでやれば難しくない。ただ、リアルタイムに変更が加えられる巨大なRDBのデータについて、カラムナーのほうも最新にしつつ解析に利用しようとすると、これは自明で簡単な処理ではなくなる。なぜなら変換のバッチ処理に非常に時間がかかるからだ。これをリアルタイムでやるのが「FlyData Sync」だそうだ。

FlyData SyncはRDBの更新処理を監視して、データの変更差分をキャプチャ。このCDC(Change Data Capture)と呼ばれる処理に加えて、マイクロ・ストリーミング・バッチと呼ぶ小粒度のリアルタイム変換技術を組み合わせることで、RDBのデータ解析をリアルタイムに高速にRedshiftで行えるというシステムを実現できるのがFlyData Syncなのだという。

「昨年リリースしたFlyData Syncが大きく伸びていて、とくにアメリカで売れ出しています。すでに売上、顧客数ともにアメリカが大きくなっている。これが出るまで、売上は日本が主流で停滞していましたが、99designs(事例)やSidecarといった著名なテクノロジー企業が利用を開始しています」と、藤川氏はいう。

次のステージへ行くための条件がそろった

シリコンバレーで勝つために必要なことは、資金調達力と、それを成長に変えていく力だというのが藤川氏の見立てだ。このプロダクトはイケるとなったときにガツンと資金調達できるのがシリコンバレーのアドバンテージでもある。

今回の資金調達も、このFlyData Syncが現在MySQLだけに対応しているものを、PostgreSQLやOracle DBに対応するためのエンジニア採用の資金でもあるという。

では、シリコンバレーで大きな投資を受けるために必要なことは?

藤川氏はいくつか仮説を立てていて、FlyData Syncによって最後に残っていた1ピースがそろったように感じているという。

藤川氏が考える必要な条件の1つ目は、創業者の国籍がどうあろうとチームがアメリカ人中心のインターナショナルなチームであること。「アメリカではCEOを変えることも良くあります。そのとき日本人が率いる日本人チームだと立ちゆかなくなる」。米国VCから投資を受けるためには、アメリカの常識に合っていることが大事なので、仕事のやり方がアメリカ流であることも条件だという。メインのチーム、特に本社がシリコンバレーにあって、創業者が物理的にシリコンバレーにいることも大事という。法人登記も米国にあることも条件。なぜなら法律関係の書類が英語(それもデフォルトのデラウェア州設立)でないと、アメリカのVCには理解できないないからだ。日本語が読めないというより、不確定要素を入れたくないのだ。

シリコンバレーで大きな資金調達をするために必要な条件の最後の1ピースは、顧客ベースとお金の流れがアメリカにあること。FlyDataは長らく売上の中心がアメリカではなかったが、これがFlyData Syncが売れ始めたことで変わったという。いま10人いる社員のほとんどはエンジニアで、セールス専業のチームを持たないことも最近の、アメリカのSaaSスタートアップの流儀に従ったものだ。

シリコンバレーで勝てれば、世界で勝てる

なぜ、そこまでしてシリコンバレーにこだわるのか? それはグローバルで大きく勝つために必要なことだという。

「シリコンバレーと、その他の地域の違いは競争の激しさです。シリコンバレーだと1つの分野でも競合が多数で、ホットな分野だと100社くらい競合がいることもあります。日本だと競合がゼロということもある」

「日本のスタートアップで、まず日本で勝ち上がってからシリコンバレーに来るということがありますよね。でも日本で一番になってもシリコンバレーで勝てるかどうか。一方シリコンバレーで一番だと、その他の地域でもあまり例外はありません」

例えば、FlyData SyncのウリであるCDCやマイクロ・ストリーミング・バッチの両方を高いレベルで実装している会社というのはまだ存在していなくて、「いまのプロダクトはグローバルで競合にほぼ勝っている」という実感があるそうだ。しかし、マーケットフィットを探り当てたこのタイミングで一気にアクセルを踏み込まないと、シリコンバレーでは新しい競合が現れてひっくり返される可能性も十分にある。B向け市場では、そういうタイミングで大型資金調達をして走り抜けるという1つの道筋のようなものがあって、FlyDataは、今のところそのパスに乗りはじめたということのようだ。

日本市場で顧客をつかむのはディスアドバンテージ?

メルカリやスマートニュース、KAIZEN Platformなどは、日本国内で顧客をつかみ、大きめの資金調達をしてシリコンバレーに打って出ている。その動向を注目している人は多いだろう。いわゆる大リーグ理論だ。日本のスタートアップがメジャーリーグに行って通用するのかどうか、関係者が注目している。

このアプローチに藤川氏は懐疑的だ。

「日本で大型調達してアメリカに挑戦している人たちもいます。みんな友だちだし、成功してほしいとは思いますが、ぼくの仮説だとこれはなかなか難しいと思います。もちろん、シリコンバレーに来てから競争で勝つことができれば問題ないと思います。でも、それには日本のプロダクトが足かせになる可能性もあります。日本のお客さんからの要求とグローバルなそれとはかなり異なると思っていますので、日本にしっかりとしたお客さんがすでにいるのは、グローバルプロダクトとしてはディスアドバンテージになりかねず、かえって難しい。だから、シリコンバレーで勝ちたいなら最初からシリコンバレーから始めたほうがいい、というのがぼくの仮説なんです」

「そうはいっても日本をレバレッジするポイントはあると思います。FlyDataも日本の資金や人脈、日本の投資家に支えられてきました。それがなければ最初の1年か2年で死んでたはずです。FlyDataでも、日本でうまく行って、アメリカではあまりうまく行かなかったプロダクトもありますが、でもその結果として日本で資金調達ができたりもしています」

グローバルで活躍する日本人起業家のロールモデルに

世界で勝つために、法人もチームもビジネスもアメリカで作る。となれば、いくら創業者が日本人であっても、そもそも「シリコンバレーで勝つ」ことの意義とは何だったのかという話にならないだろうか? 起業家の成功が特定の国に紐付いているべきだなどと言うつもりはないが、藤川氏はどう考えているのだろうか?

「日本人が作った会社が世界的に大きくなることには価値があると思っています。まず1つは日本人起業家のロールモデルになれること。日本の起業家を増やすことになります。もし大きく成功できれば、日本の起業レベルを上げることができる。メジャーリーグが日本のプロ野球のレベルを上げたように、あるいはサッカーでも世界的に活躍する日本人選手のおかげで、日本のサッカーのレベルが上がったようにです。日本の起業環境を良くする底上げになると思います。確かに直接的には日本のGDPを上げるようなことにはなりませんが、日本人起業家であれば、日本でもビジネスをやるでしょうし、日本への投資や日本市場でレバレッジすることはやりやすいはず。シリコンバレーの人たちが日本市場にあまり投資していないのは、単に日本のビジネスが分からないからなんです。日本だけでも、市場は十分大きいはずなので」

「日本人起業家のレベルが上がらない限り、世界で成功したプロダクトが日本から出てくるということが減っていく。日本以外から出てきたプロダクトやサービス、それが日本に入ってくるばかりだと、日本の存在感は減っていくばかりですよね」

FlyData Syncによってプロダクト・マーケットフィットの手応えを感じていて、プロダクトや資金調達の面での不安が少し落ち着いた状態とはいえ、藤川氏はプレッシャーは大きくなっていると言う。「『以前よりはるかにマシな状態』というふうに常に言っています(笑)。でもいつも次のステージに向けてスケールしないと、というプレッシャーがあります」。

FlyDataがビジネスをスケールさせ、数十億円とか数百億円といったレベルでエグジットできるかどうかはまだ分からないが、TechCrunch Japanでは今後も同社の動向をお伝えしていければと思う。

Amazon Web ServicesはデータウェアハウスサービスRedshiftの基盤としてデータ移行プラットホームAmiatoを買収していた

screen-shot-2015-04-20-at-16-29-50

Amazon Web Services(AWS)は、2012年にローンチしたRedshiftにより、サービスのリーチをデータウェアハウジングやビッグデータ分析の分野にも広げてきた。CTOのWerner Vogelsによると、それはAWSの中でも今いちばん急成長のプロダクトだ。このRedshiftには、AWS生え抜きの技術者たちだけでなく、買収によって獲得した人材も開発に関わっていたことが、このほど明らかになった。

実は昨年の5月にAmazonは、NoSQLデータベースから非定型データを取り出してRedshiftにポートするプラットホームAmiatoを秘かに買収していた。ポートされたそれらのデータは、Amiatoの技術やそのほかのBI(business intelligence)ツールで分析できる構造を持つ。

そういう買収があったらしい、ということは今月初めにBloombergが初めて報じた。本誌は、Amazonと、Amiatoの元協同ファウンダでCEOのMehul Shahらにコンタクトして、買収の確証を得た。

Amiatoに投資しているSignatures Capitalは、Amiatoの一件はうまくいったイグジット(出口, exit)だ、と言う。Amazonに買収されたのは2014年の5月だそうだ。

Screen Shot 2015-04-20 at 16.58.41

Amiatoの元社員(の一部)も、LinkedInなどで見ると、今はAWSにいる。

AmiatoのTwitterアカウントは2013年以降更新されていないが、サービスを停止したという告知はない。

Amiatoは、2012年にY Combinatorで孵化されているときはNou Dataという名前で、その後Bobby YazdaniやData Collective、Andreessen Horowitz、Ignition Partnersらから200万ドルを調達した

しかしながら、観測筋によれば、同社はローンチ前から問題を抱えていた。要するに同社は、Redshiftがもうすぐローンチするという時期に、Redshiftのデータウェアハウジングサービスと同じプロダクトを開発していた。Amiatoが2013年3月にステルスを脱したとき、同社は準定型データのためのビッグデータA/Bテストプラットホーム、を自称していた。

しかしその後同社は進化し、ホームページでは次のように述べた: “AmiatoのSchema-lift™技術はNoSQLデータベースからすべてのデータを取り出し、それらを自動的に変換し、Amazonのペタバイト級のデータベースRedshiftに連続的にロードする。それらを直ちにSQLでクエリしたり、TableauやExcelにコネクトしたり、あるいはLookeのようなBIディスカバリツールで分析できる”。

元CEOも社員の一部も今はAmazonにいるのだから、それは技術と人材獲得を目的とする買収だったようだ。

RedshiftのローンチやAmiatoの買収等で最新のデータ技術をサービスの基盤に据えたAWSは、最近では2lemetryを買収するなどにより、今度はIoT方面の地固めに着手している。AWSがこうして買収に走るのも、過去にはなかった傾向だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Amazon Redshift はビッグデータ分析を変えるのか

編集部注: この記事はシリコンバレーでHapyrusを起業した藤川幸一(@fujibee)によるゲスト記事である。Hapyrusはクラウド上のビッグデータのためのウェブサービスを提供する会社で、500startupsや日本の有名な複数のエンジェルから投資を受けている。

昨年11月にAmazon Web Services(以下AWS)が初めてのユーザーカンファレンスre:InventでAmazon Redshift(以下Redshift)を発表して以来、ビッグデータ分野での破壊的プロダクトとしてメディアに紹介されて来ました。そしてついに、先日2月15日に一般公開されたRedshiftですが、エンタープライズ向け製品ということもあって、AWSの他のプロダクトよりも単価が高め(1時間あたり0.85ドルの利用料)です。このため触ってみたいけれども敷居が高いという方も多いのではないでしょうか。また、破壊的と言われていてもピンと来ない方が多いと思います。Hapyrusでは、長年AWS上のHadoopサービスであるAmazon Elastic MapReduceを簡単に利用できるようにするサービスを提供してきた経験と、米国でRedshiftの検証に公開前からAWSチームとともに携わってきた実績を踏まえて、Redshiftの特徴と用途について解説したいと思います。

Redshiftはデータウェアハウスの価格破壊

データウェアハウスとは、データ分析や管理のためのシステムですが、要するにデータの追加のみで、更新をほとんどしないビッグデータ向けのデータベースのことです。MySQLなどの通常のDBシステムとの違いはトランザクションをミリ秒単位で処理(OLTP)したり、頻繁に更新したりはできないですが、大量の過去データを保持し、データ集計などの計算(OLAP)を得意としています。企業の意思決定のためのBI(Business Intelligence)システムや、過去のデータを元にしたシステムの最適化などに利用されます。

この用途の違いのため、特殊なハードウェアなどで提供されることが多く、また大企業のデータ分析で利用されることが多かったため、数千万円から数億円以上という価格帯で、大変高価と考えられて来ました。

しかし、最近のHadoopを始めとする低コストなビッグデータ処理技術の発達から、大量データ分析の価値が見直され、広告テクノロジーやソーシャルゲームなどの、より小さな組織でもビッグデータを分析して新しいビジネスを生み出す事例も出始めています。

今まではビッグデータ分析とデータウェアハウスは、その価格差ゆえに別物と考えられることが多かったのですが、Redshiftはその価格差を壊し、スタートアップなどの小規模なビジネスでもビッグデータ分析を十分可能にしてしまったのです。ここが「破壊的」と称される所以です。今までも、Hadoopを利用すれば比較的低コストで同様な処理(例えば Hadoop Hiveを利用するなど)ができましたが、実はHadoopを実用化する場合、優秀なHadoopエンジニアの獲得や大規模なサーバ管理など、潜在的なコストが大きく、小規模ビジネスが簡単かつ十分にその恩恵を受けるのは難しかったのです。

具体的なポイント

では、Redshiftと既存のデータウェアハウス技術、Hadoopとの違いは何なのでしょうか。

- 価格
例えば、このようなキーワード(データウェアハウス 価格 億円)で検索してみて下さい。数テラバイト規模のデータウェアハウスでも、億円単位のプライスタグがついています。さらに、その管理のために複数のデータベース管理者を雇う必要があります(参考資料)。 これと同様なものをAmazonはテラバイト単価で最低年間1,000ドル(3年reserved instance/最低2TBから)で提供するというのです。さらに、データベース自体はAmazonがクラウド上で管理しますので、この価格に管理コストに含まれています。はっきり言うと、100万ドル対1,000ドルレンジの比較です。桁が3つも違います。実際に、このコストの差を埋める根拠を求めるのは非常に困難だと思います。これが、なぜあんなに騒がれていたかの理由です。

Hapyrusで、Hadoopで同等な処理(Hive上で同じSQLクエリー)でのベンチマークを集計して公開した(下図・日本語版はこちら)のですが、通常の実行コストを比較したものだけでも速度・コスト共に10倍以上もRedshiftが優っているという結果がでました。このベンチマークは一時SlideShareのHottest Slideにもなりました。それだけRedshiftはビッグデータ関連のエンジニアの関心が高いということです。HadoopやHiveは、基本的にその専門家を雇う必要がありますが、Redshiftは後述するように普通のWebエンジニアでも操作ができます。


- データウェアハウスとしての性能
ここから少し技術的な説明になりますが、最大の特徴はカラムナー(列指向)と呼ばれるデータ格納方式です。IBM NetezzaやHP Verticaなどの最新のデータウェアハウスで採用されている方式ですが、これはデータベースの各カラム(列)ごとに、データを保存する方法です。これに対して、通常のデータベースは行指向データベースと呼ばれます。行指向の場合、インデックスを利用して特定の行を瞬時に取り出すのは得意ですが、データの全件集計などはすべてのデータを処理する必要があるので不得手です。カラムナーの場合は、特定のカラムのみ計算すればよく、集計処理に向いています。

さらに、カラム内には特定のデータが繰り返し現れることが多いので、圧縮効率が非常に良くなります。Redshiftでは、7種類(2月28日現在・参考資料PDF)の圧縮アルゴリズムから各カラムごとにそれを選べます。さらに、投入するデータや現在格納されているデータから最適な圧縮方法を見つける方法も提供されています。

このように、クエリーに必要な、圧縮されたカラムだけをメモリ上に載せて計算を実行するので、対象がビッグデータであっても驚くようなスピードで結果を得られるのです。

Hadoopでもこのカラムナーのメリットを活かす追加モジュール(RCFile、HBaseなど)がいくつか公開されていますが、技術的な敷居もあり、標準的に使われているかというとそうでもないと考えています。

他のデータウェアハウスと比較しての最大の特徴は、Amazonらしくスケーラビリティーです。MPP(Massively Parallel Processing)と呼ばれる仕組みを備えていて、データ量が増えるに従って処理・保存サーバー数を増やし、処理速度を維持・向上することができます。Hapyrusではこの機能について、データ読み込みとクエリー速度の両方をベンチマークで確認しました


実はRedshiftは元々、Amazonが出資しているParAccelという会社が提供するテクノロジーを元に開発されています。MPPはその会社や、他のベンダーからも提供されている機能ですが、これがAWSから提供されるということに意味があります。つまり、これがAmazon独自の最大の特徴なのですが、スケールアウト(台数を増やす)のが、ものの数クリックで完了するのです! これは他のベンダーがどんなに頑張っても真似できない、パブリッククラウドサービス独自の部分だと思います。

まとめると、カラムナーデータベースであり圧縮オプションが豊富、MPPによりスケーラブルでスケールアウトは数クリックで完了。初めてこれらの事実を知って、さらに検証が完了した時、身震いしたのを覚えています。

- 既存技術との互換性
RedshiftはPostgreSQLという既存のデータベースを元に構築されています。つまり、PostgreSQLのドライバーや、それに対応している各種ツールはほぼすべて利用できるということです。通常のJDBCドライバーですべての操作が可能です。つまり、一度データをRedshiftに入れてしまえば、既存のアプリケーションや新規に作ったウェブサービスなどからも、容易に利用できるということです。もちろん、PostgreSQLのすべての機能が使えるというわけではありませんが(例えばデータタイプがプリミティブに限定されるなど)、利用する敷居はHadoopに比べて格段に低いと考えられます。

- 現状の問題点
一番の懸念点は、まだ一般公開されたばかりで、実績があまり公表されていないことでしょう。しかし、そもそもこの技術は世界一のECサイトであるアマゾンで利用されて検証されているものですし、かなり前から非公開ながら、いろいろな企業で検証されてきたということです。公開当初は広く使われるようになるということでいくつか問題も出てくると思いますが、すぐに落ち着いてくるでしょう。

前述のベンチマークで、Redshiftへのデータの一括ロードにかなりの時間がかかるという結果がでましたが、インスタンスを複数にすることでかなり改善することがわかっていますし、またHapyrusでも一括ではない継続データアップロードの仕組みを提供しようとしています

また、技術内容や利用方法についてもまだ広く知られていませんが、このような記事を通して、HapyrusとしてもRedshiftを利用する方々を応援して行きたいと思っています。

Hadoopとの住み分け
もちろん、Hadoopのほうが得意なことも多々あります。例えば、各レコード全体を処理していくものや、複雑な機械学習を利用した分析など、より高度な処理はHadoopでしか出来ないものもあります。また、頻繁に分析しない処理(例えば年に1回、月に1回のペタバイト級のバッチ処理など)は、Hadoopのほうがコストパフォーマンスが良くなる可能性があります。逆に、数分や数十分前のデータに対して短時間にリアルタイムに近い分析をしたい広告テクノロジーやデジタルマーケティング、ソーシャルゲームなどの分析には、テラバイト級のデータである限り、Hadoopや他のテクノロジーよりもRedshiftのほうが優位にあると考えられます。

Redshiftはビッグデータ分析のキラーアプリケーション
今まで、筆者はビッグデータ技術で一般利用が可能なものはHadoopしかなく、それをどれだけ使いやすくするか、ということがどのような規模の会社でもビッグデータの恩恵に与れる最短の道だと信じて進んできました。しかしまさに、それはRedshiftによってひっくり返されてしまいました。これはとても嬉しいことです。なぜならば、より簡単に、より低コストでビッグデータ分析の道がどんな規模の会社に対しても開けたということだからです。Redshiftを利用することで、皆がクラウドビッグデータを活用してよりよい世界が実現されることを願っています。