2010/06/28

BIGDATAを処理する技術はどう使われているのか


 ここまでご紹介したBIGDATAを扱う技術ですが、実際にはどのように利用されているのでしょうか。

 myNoSQLというNo-SQLに関する記事を掲載するサイトに、HBASECassandra利用事例がわかりやすくまとめられていました。



 このまとめを見ると、多くのユーザを集めるWebサービスは、すでにHBASECassandraを様々な目的で利用し始めています。

 おそらく、これらの利用方法は、BIGDATA以前には、従来のリレーショナル・データベースで処理でしていたものの、ユーザの増加とともに、やがてBIGDATAとなり、その処理をノン・リレーショナルやNoSQLと呼ばれる分散型の処理に移行していったものと想定されます。

 また、もしかすると、これまでは、ユーザーの利用履歴やログなどのデータは、ストレージせずに捨て去られていたものが、ストレージし、処理する手段を得たことにより、新たな分析の対象となり始めたとも言えるかもしれません

BIGDATAを処理する技術の性能比較をしてみると


さて、CAP定理による分類に続き、性能比較をしてみます。この性能比較は、Geminiのラボにおいて実施し、GoogleBigTableの論文の比較方法に基づき、データは次のオープンソースの性能比較ソフトを利用しています。
(org.apache.hadoop.hbase.PerformanceEvaluation.)

そして、5台のPCサーバーを利用し、処理性能を測定しました。ここでは、100万リクエストの場合のランダムの書き込みと読み込みの結果をご紹介します。X軸は、キーに対応するバリューのサイズを1KB、10KB、20KBの3つのケースを表しています。Y軸は、1秒あたり、ノードあたりのスループットで単位はMBです。

この結果を見ると、Cassandraは、全般的に読み込みよりも書き込みの処理能力が優れるよう最適化されていることがわかります。




 次のグラフは、同様の条件におけるHBASEの性能です。HBASEは、比較的小さなバリューサイズに優れていることがわかります。









 3つめのグラフはHibariを同様の条件でテストしてみた結果です。Hibariは大きなバリューに優れており、また、書き込みよりも読み込みに最適化されています。




 これは、Hibariは、SNSやCloud(Web)メールにおいて写真や画像などの大きなファイルがあることを前提に、テクストだけの小さなデータから、添付ファイルなどを伴う大きなデータサイズまでを一定の処理性能を提供するよう開発されており、結果として、HBASECassandraと比較した場合に、大きなデータサイズの処理性能に優れるという結果となりました。

2010/06/25

BIGDATAを処理する技術の課題と解決方法は?


 この分散型によりBIGDATAを扱う技術には課題もあります。

 図に示すように、複数のPCサーバーにデータの複製(レプリカ)をストレージ(格納)するため、データの書き込み(更新)があった場合、データを読み込むタイミングによっては、更新前のデータを読み込んでしまう場合があります。



 このような状態を、データの一貫性(Consistency)が無いと言います。

 Geminiは、この分散型の課題である一貫性(Consistency)を保証するキー・バリューストアであるHibariを開発し、商用として提供しています。この一貫性を保証するために、チェイン・レプリケーションという技術を実装しました。

 このチェイン・レプリケーションは、複数(この例では3台)のPCサーバーを、1つのチェインとして、そのチェインにデータを複製(レプリカ)します。そして、このチェインにある3つのPCサーバーに格納されるデータのブリック(塊)をHeadMiddleTailとして、書き込みは常にHeadから行い、読み込みは、常Tailから行います。このアルゴリズムにより、複数のPCサーバーにデータが複製(レプリカ)されている場合にも、更新前のデータが読み込まれることが無いという、強い一貫性(Strong Consistency)を保証するというものです。



BIGDATAを処理する技術の呼び方は?


このような分散型によりBIGDATAを処理するデータベースの技術は、いろいろな名称で呼ばれています。 
 
 リレーショナル・データベースと異なることから、ノン・リレーショナル・データベース。

 リレーショナル・データベースで用いられるSQL言語を利用しないことから、NO-SQL

 とはいえ、SQLがもはや不要という意味では無く、今後は補完関係になるであろうという議論があり、Not-Only SQL

 データ構造から、キー・バリュー・ストア、キーに対してコラムを持つ構造のものは、コラム型、XMLよるものはドキュメント型などとも呼ばれます。

 また、分散型がその特徴であることから、分散型キー・バリュー・ストアとも呼ばれます。




2010/06/23

BIGDATAを処理する技術


 さて、このBIGDATA処理にはどんな技術が用いられているのでしょうか。

 先にご紹介したTwitter開発者向けのChirpのプレゼン資料に戻ると、このBIGDATAをストレージ(格納)するためには、単体のマシーンを使い、そのHDの書き込みスピードが80MB/秒だとした場合に、24.3時間かかると試算しています。

 つまり、単体のマシーンでこのBIGDATAを高速で処理するとなると、相当にハイグレードなコンピューターが必要となります。予算に糸目をつけないというのであれば、CPUを高速化し、メモリを増設し、ストレージを大容量化するという、「スケールアップ」を選択しても良いでしょう。




 しかし、こんなBIGDATAを扱うビジネスは、その大半がクリス・アンダーセンの著書「Free」で指摘されているように、5%の有料ユーザーが残りの95%の無料ユーザーを支えるといった新しいビジネスモデルにより成り立っています。

 そうなると、低コストでの事業運営が求められます。そこで、最近では5000ドル(約50万円)PCサーバーと呼ばれる汎用PCサーバーを多数、分散、並列して規模を拡大する、「スケールアウト」が注目を集めています。

 このスケールアウトでは、通常、分散、並列したPCサーバを同時に稼働させて分散処理を行います。この分散処理は簡単に説明すると、この図のようになります。




 つまり、大きなデータの塊を細かく砕き、分散、並列したサーバーで同時に処理して、そして再度集めて並べ直すという手順です。 このような分散処理を行うソフトウェアは、Googleの「Big Table」という論文を参考に開発されたオープンソースであるHadoopMapReduce(マップリデュース)が有名です。


 また、分散した汎用PCサーバーにデータをストレージ(格納)する分散ストレージの技術も様々あります。 最近注目を集めているのは、先ほどご紹介したHadoopと一体となったHBASEや、Facebookのために開発されたCassandraです。このHBASECassandraのいずれもが、Twitterにおいても利用されてます。






 そして、これらの分散ストレージの特徴は、数十台、数百台、時には数千台と並べたPCサーバーの複数台に、データの複製(レプリカ)を作り、ストレージ(格納)するという点にあります。

 複数台にデータの複製(レプリカ)を作ることで、仮に1台のPCサーバーが壊れたとしても複製(レプリカ)されたデータは、他のPCサーバーに残っているので安全という考え方です。逆に、安価なPCサーバーは故障するものだという前提でシステムが構築されていると言うこともできます。

 ところで、現在のデータベースの主流であるリレーショナル・データベースは、更新が終了されたデータが常に読み込まれるというデータの一貫性(Consistency)を維持します。そのために、データが書き込みされている際には、読み込みができないよう、ロックを行います。




この書き込みをする機会が少ない場合には問題になりませんが、BIGDATAのような場合、一度に多くの書き込み処理が行われます。その都度、ロックされていては、BIGDATAを速く処理することが難しくなります。

 また、この分散型の処理は、リレーショナル・データベースのデータ間の関係づけを行う構造とは異なり、キーとバリューというシンプルなデータモデルという構造です。このシンプルなデータモデルが分散型でBIGDATAの高速な処理を可能としています。 




2010/06/22

BIGDATAとは

昨年の暮れあたりからでしょうか。日本においても、急にTwitterがブームになり始めたように見受けられます。

このTwitter。新しいコミュニケーションの手段として、またマーケティングツールとしても脚光を浴びています。しかし、ここでは、このTwitterを少し違う角度から見てみましょう。

私たちにとっては、Twitterは、この写真のような状況に見えて仕方がありません。





Chirpと呼ばれるTwitterの開発者の会議があります。その会議におけるプレゼン資料がSlideshareで公表されています。


“Big Data at Twitter, Chirp2010”というタイトルの資料によれば、Twitterの1日あたりのデータ量は7TB(テラバイト)とのことです。テラとは約1兆を表します。




7TBと言われても、なかなかピンとはこないのではないでしょうか。そこで、たいへんにわかりやすい比較データを発見しました。“What Do 12 Terabytes-Worth of Data Look Like”というタイトルで、Neatoramaというニュースブログに12TBを様々な媒体と比較していました。


その試算を利用すれば、7TBは、人間の脳の記憶容量5.6個分、DVDが1500枚、CDが約11,000枚相当になります。





最近では、このように爆発的に増加し始めたデータをBIGDATAと呼び始めています。