Apache Stormでそれをしましたか?ヘロンが急襲して救助

昨年、Twitterは2つの爆弾を落としました。まず、本番環境でApacheStormを使用しなくなります。第二に、それは自家製のデータ処理システム、ヘロンに置き換えられました。

Heronのアーキテクチャを詳述した論文を発表したにもかかわらず、Stormに代わるTwitterの代替手段はTwitterのデータセンターに隠されたままでした。先週、Twitterがオープンソースライセンスの下でHeronをリリースしたとき、それはすべて変わりました。では、Heronとは何であり、大規模なデータ処理の世界のどこに当てはまるのでしょうか。

有向非巡回グラフ(DAG)データ処理エンジンであるHeronは、現在非常に混雑している分野のもう1つのエントリです。しかし、ヘロンは「見た目、私も!」ではありません。ソリューションまたはDAGエンジンをビッグデータのFizzBu​​zzに相当するものに変える試み。

ヘロンは、Twitterがストームトポロジの大規模な展開で抱えていた本当の懸念から生まれました。これらには、データレベルおよびトポロジレベルでスケーリングした場合のStormワーカーに関するプロファイリングと推論の問題、MesosまたはYARNで実行されるシステムと比較したリソース割り当ての静的な性質、バックプレッシャサポートの欠如などが含まれます。

TwitterはApacheSparkまたはApacheFlinkを採用することもできましたが、それにはTwitterの既存のコードをすべて書き直す必要がありました。(Twitterは他の誰よりも長くStormを使用しており、Stormの作成者であるBackTypeをオープンソースになる前の2011年に買収しました。)代わりに、Twitterは別のアプローチを採用しました。Storm互換APIを備えた新しいストリーム処理フレームワークです。 。

新しいフレームワークのウォークスルーのこの時点で、通常、フレームワークでのコーディングがどのように感じられるかを示すためにいくつかの例を見ていきますが、Heronにはほとんど意味がありません-ストームボルトとタプルをまったく同じ方法で記述しますあなたはストームでそうするでしょう。HeronでStormコードを実行するために必要なのは、このセクションをpom.xmlの依存関係に追加することだけです。

 com.twitter.heron

 heron-api

 SNAPSHOT

 compile

 com.twitter.heron

 heron-storm

 SNAPSHOT

 compile

次に、ストームコードとclojure-pluginの依存関係を削除します。再コンパイルすると、コードはHeronで実行され、それ以上の変更は必要ありません。シンプル!(ほとんどの場合、とにかく、しかし私たちはそれに戻ります。)

運用上、Heronの現在の実装は、Twitterによって開発されたMesosスケジューリングフレームワークであるApache Auroraを使用して、Apache Mesos上で実行されます(驚きです!)。StormトポロジをすべてHeronに切り替えて以来、Twitterは、トポロジ専用のハードウェアリソースを3分の1に削減すると同時に、処理のスループットとレイテンシを削減しました。悪くはありません。

おそらく、Heronの最も興味深い側面の1つは、そのコードがJava(またはScala)で記述され、WebベースのUIコンポーネントがPythonで記述される一方で、フレームワークの重要な部分であるトポロジを管理するコードです。ネットワーク通信はJVM言語でまったく書かれていません。

実際、Heronの中心には、予期しない言語であるC ++のコードがあります。これは、今後数年間でさらに多く見られるビッグデータの世界の側面だと思います。 

Apache Stormのメンテナは、Javaの再実装を優先して、元のClojureコードの多くの要素を削除しました。現在、Apache Sparkプロジェクトは、DataFrame処理を高速化するためにオンザフライでJavaコードを生成しています。しかし、どちらも依然としてJVMに関連付けられており、JVMには大規模な問題があります。誤解しないでください。JVMは20年間の試練に耐えてきた素晴らしい作品ですが、大量のRAMを搭載したマシンで実行し、膨大な量のデータを処理すると、何があってもガベージコレクションの問題が発生します。使用するファンシーコレクタースキーム。

その時点で、C ++のような言語に戻ることは魅力的に見え始めます。例として、ApacheCassandraのC ++再実装であるScyllaは、Cassandraの10倍のスループットを持ち、Cassandraが大規模な展開で悪名高いGC一時停止はありません。ヘロンのアプローチがすぐに他のフレームワークに広がるのを見ると私はかなり確信しています。これは、Javaと他の言語との間のインターフェースを改善しようとするProjectPanamaの試みによって助けられるかもしれません。

Heronが必要とするリソースが少なく、Apache Stormよりもスループットとレイテンシが少ないことを考えると、今すぐすべてのトポロジをHeronに移行する必要があります。まあ、多分。Heronは現在Mesosに関連付けられているため、既存のMesosインフラストラクチャがない場合は、それもセットアップする必要があります。これは簡単な作業ではありません。また、StormのDRPC機能を使用している場合、Heronでは非推奨になっています。

プラス面として、HeronはTwitterのすべての処理ニーズを1年以上本番環境で実行しているため、投げることができるものなら何でも処理できるはずです。さらに、Twitterは、HeronがMicrosoftや他のFortune 500企業で使用されていることを指摘しているので、それが定着することを比較的確信できます。

一方、ストームはまだ立っていません。 Apache Stormチームは、TwitterによるHeronの「次世代のApacheStorm」の説明に戸惑うかもしれません。 TwitterがHeronに取り組んでいる間、Apache Stormは1.0に達しました。これには、背圧のサポート、デバッグとプロファイリングのオプションの改善、レイテンシーの60%の削減、最大16分の1の速度の改善が含まれます。

さらに、Storm 1.0は、ZooKeeperからハートビートトラフィックをオフロードするためのデーモンであるpacemakerを追加し、悪名高いZooKeeperのボトルネックからより大きなトポロジを解放します。 Heronの速度の向上は、現在のバージョンではなく、分岐したStorm0.8.xコードから測定されます。すでにStorm1.0に移行している場合は、現在のStormトポロジに比べてそれほど改善が見られない可能性があり、StormとHeron間のバックプレッシャサポートなどの新機能の実装間で非互換性が発生する可能性があります。

全体として、HeronがApache Spark、Apache Flink、ApacheBeamなどのデータ処理フレームワークの取り込みに大きな打撃を与える可能性は低いと思います。それらの高レベルの抽象化とAPIは、低レベルのStorm / TridentAPIよりもはるかに開発者に優しいエクスペリエンスを提供します。ただし、クリティカルパス用のJVMコードと非JVMモジュールのブレンドは、今後より一般的なアプローチになると思います。この点で、Heronは、数か月および数年の間に進むすべての方向性を示しています来る。