Twitter が提供する、Hadoop ライクな OSS とは？

August 9, 2011

Twitter が提供する、Hadoop ライクな OSS とは？

Filed under: Big Data,Hadoop,Twitter — Agile Cat @ 7:17 am
Tags: BackType, Hadoop, HStreaming, MapReduce, Nathan Marz, Open Source, OSS, S4, Storm, Strange Loop, StreamBase, Twitter

Twitter to open source Hadoop-like tool
By Stacey Higginbotham Aug. 4, 2011
http://gigaom.com/cloud/twitter-to-open-source-hadoop-like-tool/

Attention webscale aficionados, Twitter says it is planning to open source Storm, its Hadoop-like real-time data processing tool. In a blog post Thursday, the microblogging network said it plans to release the Storm code on Sept. 19 at the Strange Loop event in St. Louis, Mo.

Webs Scale マニアよ注意せよ – Twitter は、Hadoop ライクなリアルタイム･データ･プロセシング･ツールに関して、オープンソースの嵐を巻き起こそうと計画しているらしい。木曜日（8/4）のブログポストで、このマイクロ･ブログ･カンパニーは、9月19日に St. Louis, Mo で開催される Strange Loop というイベントで、Storm のコードを公表する計画を練っていると発言した。

The question is — does the world need another real-time data processing tool? After all there are many tools like HStreaming (using Hadoop), the open source S4 and StreamBase, but the overall analytics market (if you can call it a market) is already fragmented. The Storm code comes from Twitter’s acquisition of BackType last month and seems to be an effort to get folks comfortable parsing data on Twitter.

そこでの疑問は以下のとおりであるー世界は、もう 1つのリアルタイム･データ･プロセシング･ツールを必要とするか？結局のところ、オープンソースである S4 や StreamBase といった、数多くの HStreaming（Hadoop を利用）ツールがあが、分析のための全体的なマーケットは（単にマーケットと呼ぶなら）、すでに分裂している。 Storm のコードは、先月に Twitter が買収した BackType がベースとなり、また、同社におけるデータ解析を快適にするために、folk したものと思われる。

The post does an excellent job laying out use cases for Storm and hints at more to come. While the code can deal with distributed nodes and huge amounts of data a la Hadoop or Map Reduce, Storm handles jobs that are “infinite.” It’s not for a data processing job with an end point, it’s good for streams of data and continual processing. From the post by Nathan Marz:

そのポストは、Storm のユースケースを概説し、これから加えられる機能をほのめかすという意味で、良い仕事をしている。そのコードは、Hadoop あるいは Map Reduce のように、分散ノードと大量データを取り扱いう。そして、Storm が処理するのは、「無限」のジョブとなる。それは、エンドポイントを用いたデータ･プロセシング･ジョブのためのものではなく、データ･ストリーミングと継続的な処理に適している。Nathan Marz によるポストは、以下のとおりである：

Here’s a recap of the three broad use cases for Storm:

Stream processing: Storm can be used to process a stream of new data and update databases in realtime. Unlike the standard approach of doing stream processing with a network of queues and workers, Storm is fault-tolerant and scalable.
Continuous computation: Storm can do a continuous query and stream the results to clients in realtime. An example is streaming trending topics on Twitter into browsers. The browsers will have a realtime view on what the trending topics are as they happen.
Distributed RPC: Storm can be used to parallelize an intense query on the fly. The idea is that your Storm topology is a distributed function that waits for invocation messages. When it receives an invocation, it computes the query and sends back the results. Examples of Distributed RPC are parallelizing search queries or doing set operations on large numbers of large sets.

広範囲におよぶ、Storm の 3つのユースケースを、以下に要約する：

Stream processing: Storm は、新規データのストリームを処理し、データベースをリアルタイムで更新するために使用できる。Qqueue と Worker のネットワークを用いてストリームを処理をする、従来からの標準的なアプローチとは異なり、Storm はフォールト･トレラントであり、また、スケーラブルである。
Continuous computation: Storm は継続的にクエリーを発行し、また、その結果をクライアントへ向けて、リアルタイムにストリーミングする。たとえば、Twitter のトレンディングなトピックを、ブラウザへ向けてストリーミングすることが可能だ。対象となるブラウザは、それらのトレンディングなトピックが発生するたびに、リアルタイムなビューで参照することになる。
Distributed RPC: Storm は、高負荷なくエリーを、on the fly で並列化するために利用できる。この発想により、Stormトポロジーは、呼出しメッセージを待つための分散的な機能になる。呼び出しが受信されたとき、クエリーが処理され、その結果が返される。 Distributed RPC の例としては、検索クエリーの並列化、および、膨大なデータセットに対する設定オペレーションなどがあげられる。

But wait! There’s more! At the end of the post we are assured that there’s more to Storm than the blog post has even defined, which we can learn more about next month at the Strange Loop event. From the post:

しかし、これで、すべてではない！さらに、多くの事柄がある！このブログポストの終わりには、そこに記載された以上の機能があるとされ、来月の Strange Loop イベントで、詳細を学ぶことが可能と約束されている。以下は、そのポストから：

I’ve only scratched the surface on Storm. The “stream” concept at the core of Storm can be taken so much further than what I’ve shown here — I didn’t talk about things like multi-streams, implicit streams, or direct groupings. I showed two of Storm’s main abstractions, spouts and bolts, but I didn’t talk about Storm’s third, and possibly most powerful abstraction, the “state spout”. I didn’t show how you do distributed RPC over Storm, and I didn’t discuss Storm’s awesome automated deploy that lets you create a Storm cluster on EC2 with just the click of a button.

私は、Storm の表層を語ったただけである。 Srtorm のコアにある「Stream」のコンセプトは、ここに記した以上のものである。つまり、multi-streams および、implicit streams、direct groupings について、私は言及していない。私は、Storm における主要な抽象概念である、spouts and bolts について説明したが、3番目の概念については話していない。それは、おそらく最も強力な、state spout という抽象概念である。また、Storm 上に分散 RPC を展開する方式や、ボタンをクリックするだけで EC2 上に Storm クラスタを作成する、素晴らしく自動化されたデプロイメントについても説明していない。

So for those anxious to test out a new method of crunching terabytes of real-time data on the fly, get thee to GitHub! And wait.

テラバイトのリアルタイム･データを on the fly で処理するための、この新しい方式を試したいなら、GitHub へ行け！そして、待て。

Related research and analysis from GigaOM Pro:

ーーーーー

このところ、Twitter のテクノロジーに、いくつかの変更と拡張が加えられているようです。 Facebook との棲み分けの時代から、Google＋との競合の時代へと、Twitter の環境は変化しています。たいへんだろうけど、頑張って欲しいです。ーーー