Twitter HeronはStormに比べてどう進化しているのか？ - 夢とガラクタの集積場
こんにちは。 今月頭、TwitterがHeronという新しいリアルタイム解析基盤について発表していました。 読んでみると、StormとAPIの互換性を保ったまま新しいHeronというリアルタイム解析基盤を開発したそうな。blog.twitter.com ですので、一度Heronの記事を読んでまとめて、Stormと比較しておこうと思います。 StormもOSS化されて4年近く経過し、ストリーム処理プロダクトも世代交代の時期に来ているようですので、その意味でのまとめとしても。 その前に、そもそもStormって？ 2011年にTwitterがOSS化した耐障害性を持つ分散ストリーム処理基盤です。 どういうものかは下記あたりの資料を読むのが私が何か下手に書くよりわかりやすいと思います＾＾； 初めて広く広まったストリーム処理基盤のOSSで、その分野の走りだったのではないか、と考えています。 Twit
TwitterでつぶやいたStormの雑多な情報まとめ（その３ - 夢とガラクタの集積場
こんにちは。 #stormjp のタグでStormの雑多な情報まとめその３です。 段々前置きとかが思いつかなくなってきましたが、とりあえず入ります＾＾； ○19.StormとKestrelを組み合わせることで『Kestrelから取得したメッセージをStormで処理完了したことを保証する』 アプリケーションが構築可能。 Kestrelは「Transaction」という仕組みを持っており、 ackが返されなかったメッセージは一定時間でメッセージを復旧させるため。 そのため、Storm側で成功したらackを返し、失敗／タイムアウトしたらfailを返すように Kestrelとやり取りをすればＯＫ。 上記の動作をする雛形はStorm-Kestrelにある。 ○20.Nimbus、Supervisor、workerは各々ローカルに一時ファイルを出力する。 出力先は【STORM_HOME】ディレクトリ配
TwitterでつぶやいたStormの雑多な情報まとめ（その２ - 夢とガラクタの集積場
こんにちは。 #stormjp のタグでStormの雑多な情報まとめその２です。 ちなみに呟きの過去から情報は追っていっていますが、呟いた後に判明した情報も 芋づる式に記述しています。 そのため、単に過去わかった情報だけではない・・・という構成になっています。 では、始めますか。 ○10.Stormでは一定時間処理されなかったメッセージについてはタイムアウトとなり、 Spoutにfailメソッドの呼び出しという形で戻ってくる。 ただし、Spoutのack/failの機構が有効になるのは下記のようにTupleemit時にMessageIDを指定した場合のみ。 ○11.タイムアウトが発生するタイミングはtopology.message.timeout.secsで決まる。 ただし、「topology.message.timeout.secs」丁度ではタイムアウトしない。 「topology.me
TwitterでつぶやいたStormの雑多な情報まとめ（その１ - 夢とガラクタの集積場
こんにちは。 最近 Twitter上で #stormjp のタグでStormの雑多な情報を呟いているのですが、 ひたすら流れていくばかりだったため、この後ちょこちょこまとめていきます。 ・・・ええ、私自身さっぱり覚えていられなくなりましたので（汗 とりあえずは古い方から・・・気が付いたら #stormjp の呟きだけで900回近いつぶやきになっていました。 ○1.StormのLocalModeはWindows+Eclipseからでも起動可能 → ただし、TempディレクトリにZookeeperのゴミファイルが残るので注意。 特にCIサーバ。 ○2.StormのTupleにはObjectが投入可能だが、プロセスをまたがる際にはシリアライズが行われるため、 独自エンティティクラスは全てシリアライズ可能としておくこと Tupleにはシリアライズ可能なオブジェクトのみ設定すること。 ○3.独自エン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Getting Started with Scalding, Storm and Summingbird
English (US)
