S4 0.3.0 のリリース

S4 0.3.0 をリリースしました。0.2.1 からの変更点は次のとおりです。

  • ビルドとアセンブリを Maven から Gradle に移行
  • 3 つのリポジトリ (core, comm, examples) を 1 つ (s4) に統合
  • クライアントアダプタ
  • ZooKeeper を使った S4 の実行についてドキュメントを用意
  • API をシンプルにする作業に着手: ProcessingElement インタフェースを削除; すべての PE は AbstractPE を継承しなければならない。ほかにも修正予定多数。
間もなく登場予定:
  • チェックポイント機能: 担当グループで実装を完了し、現在テストを実行中。

クライアント API、Hadoop Interop、Scala による PE

前回の投稿以降の S4 プロジェクトの活動状況をまとめて紹介します。

ドキュメントは徐々に充実してきていて、手順を詳しく説明した的確なサンプルもいくつか用意しました。サンプルのコンパイル、ビルド、実行方法なども含めて、コードについて詳細に説明しています。Scala で PE を記述した Twitter トピックカウントサンプルの実装もあります。こうなればもう S4 を使わない手はありません。使い始めにつまづいたら、遠慮なくフォーラムにメッセージを投稿してください。

12 月には、KDDCloud 2010S4 に関する論文を提出しました。また、リアルタイムデータマイニングに関する問題を研究している人たちとも会い、多くの有益なフィードバックをもらいました。

以下に示すのは、「間もなく登場予定」のものです。

  • アダプタ API は、プログラミング言語に依存しない双方向クライアントプロトコルで置き換えているところで、Java、C、Perl、および Python によるリファレンス実装を用意しています。新設計の S4 では、S4 クライアントドライバが存在する任意のプログラミング言語を使って、外部イベントを S4 に投入できるようになります。JSON 形式でイベントを送信する場合は、S4 単独でその処理を行うことができます。レガシー形式でデータを送信する必要がある場合には、レガシーデータ形式を S4 イベントオブジェクトに変換するためのスタブを書くだけで目的を実現できます。S4 クラスタから送出されたイベントをリスンする場合も、同じしくみがサポートされています。出力は、出力ストリームでも、シンプルなクエリに対する応答としての、一連の不連続なイベントでもかまいません。
  • もうひとつの有益なサブプロジェクトに、Hadoop で実行可能な S4 コンテナがあります。S4 コンテナを使うと、膨大な静的データを使って自分の好みのモデルをトレーニングし、結果を S4 クラスタにデプロイすることができます。このようなアプローチを使うメリットとして、オフラインとオンラインで同じコードベースを使ってデータを処理できることがあります。つまり、コードを書いて、このコードを機械学習モデルのトレーニングを目的として Hadoop で使用してオフラインシミュレーションを実行し、後で同じコードをリアルタイム S4 クラスタで再利用することができます。先週聞いたところによると、S4 のサンプルは Hadoop で問題なく実行できたとのことです。
  • 何人かの人たちからは、ZMQ を使って低レベルネットワーク通信レイヤを実装したいという提案がありました。このプロジェクトは非常に興味深く思われるので、私たちもテストしているところです。
  • あるグループは、クラッシュ後の回復を改善するために、PE へのチェックポイント機能の追加を検討しています。続報を待ってください。

以上がプロジェクトの現状です。アイデアや新しいプロジェクトについてはフォーラムで知らせてください。意見や感想をお待ちしています。

S4 入門

開発の動機

ビッグデータの世界には、データストリームが溢れかえっています。思い付くままに挙げるだけでも、Twitter、検索クエリ、株価情報、サイト分析、センサーデータなど、膨大な数のデータストリームがあります。ただ、この規模のデータ処理に対する一般的なアプローチは、MapReduce、すなわちバッチ指向のフレームワークをベースにしたもので、それ以外では、プロプライエタリなストリーム処理システムや特定の問題を対象としたアドホックなソリューションが使われています。

私たちは、データが手に入ると同時に処理することが、しばしばそのデータから最も大きな価値を引き出すことにつながると考えます。S4 は、データストリームの処理のためにまったく新しく構築された汎用のオープンプラットフォームです。S4 は、恣意的なかたまりになるまでデータをバッファリングすることはせず、イベントが発生するたびに、つまりデータが届くたびにデータを処理します。

アプリケーション

検索広告で私たちが目標にしているのは、ユーザー、パブリッシャー、および広告主のすべてにとってメリットになるような方法で、広告を選択し、ランク付けし、フィリタリングし、掲載することです。換言すれば、表示する広告を可能な限り少なくし、最も高いクリック数と収益をもたらす的確な広告だけを表示したいと考えています。このような目標を実現するために、私たちはまず、ユーザーが広告をクリックするかどうかを正確に予測する機械学習モデルを構築します。そして、このクリック予想の正確性を向上させるために、最近の検索クエリ、クリック、およびタイミングに関する情報を処理します。こうした処理のことを、私たちはパーソナライゼーションと呼んでいます。これをスケーリングするには、1 日数百万人にも上るユーザーの検索クエリを 1 秒に数千件処理する必要があります。このような課題こそ、イベントを処理するための新しいソフトウェアプラットフォームの構築を私たちが決心するきっかけとなったものです。この点は、MapReduce と Hadoop がバッチ処理におけるスケーラビリティの問題に取り組み、各種の NoSQL プロジェクトもデータストレージのスケーラビリティの問題に取り組んでいるのとまったく同じです。

チームの紹介

Leo Neumeyer は検索広告最適化チームを率い、自分が中心となってプロジェクトの意義を社内のあちこちで説いてまわるとともに、最初の設計者の役割を果たしました。Bruce Robbins は、システムの 80% のコードを書いた中心的なソフトウェアエンジニアで、現在でも主要設計者の 1 人です。また、Anish NairAnand KesariStefan SchroedlErick Cantu-Paz、Jon Malkin をはじめとする多くのサイエンティストは、パーソナライゼーション、クリック予想、オンラインパラメータ最適化のためのアルゴリズムを実装しました。プロジェクトの設計は、彼らの実装したアルゴリズムを柱として、幾度かのイテレーションを経て進められました。Kishore Gopalakrishna は、ZooKeeper を土台としたスタンドアロンコンポーネントとして、通信レイヤを設計、実装しました。Ben Reed は私たちに数多くのアドバイスを与えくれ、JC Mao は役員として S4 のオープンソースプロジェクト化を支援してくれました。Yahoo! でオープンソースのディレクターを務め、オープンソース化のノウハウを熟知しているオープンソースエバンジェリスト Gil Yehuda も私たちの一員です。

私たちは、現実世界の問題を解決しようと試みることによって学習を重ね、まさに今、さまざまなユースケース、そして解決する必要のある課題について理解し始めたところです。こうした背景から、数年間にわたって独自に開発を続けた後、私たちは 2010 年 10 月に S4 をオープンソースにする決断を下しました。その結果は驚くべきものです。1 日で、過去 2 年を合わせたものより多くのフィードバックをコミュニティから受け取ったからです。注意していただきたいのは、現在のリリースは初期段階のリリースであり、まだまだ道のりは長く、ドキュメントも充実させる必要があるということです。私たちは、ストリーム処理に興味を持っている人たちが開発に参加し、プロジェクトが大きく育つのを手伝ってくれることを願っています。S4 に触れる最もよい方法は、サンプルアプリケーションをいじってみたり、自分で独自にアプリケーションを作成したりすることです。私たちへの質問やフィードバックには、フォーラムを活用してください。