Apache Heron概要とApache Stormとの比較
Apache Heronとは
公式サイトから。
A realtime, distributed, fault-tolerant stream processing engine from Twitter
日本語訳。
Twitter発のリアルタイム、分散、ミス許容ストリーム処理エンジン
注目する点としては、
- Apache Stormのトポロジーが
mavenのpom.yamlを少し編集することで直接採用できること。 - Schduler-driven環境(YARNなど)で動作する。 ステートフルにすることができる。 Heron UIというリッチなUIがある。
設定ファイル
| ファイル名 | 何を設定するか |
|---|---|
scheduler.yaml |
launcher, scheduler, topologyランタイムの設定。 |
statemgr.yaml |
ステートフルにするための設定。 |
uploader.yaml |
topologyのjarファイルをuploaderにuploadするためのもの。 |
heron_internals.yaml |
Heronがどのように動作するかを設定する。 |
metrics_sinks.yaml |
システムのランタイムとトポロジのメトリックすがどこにルーティングされるかを記述。 |
packing.yaml |
packingアルゴリズムのための設定。デフォルトではラウンドロビンである。 |
client.yaml |
Heronのクライアントの挙動を記述する。 |
Apache Heronのダウンロード
Macからは簡単にダウンロードすることができます。
brew install heron
アーキテクチャ
以下のようにアーキテクチャがなっています。
Topologyのコンポーネント
Topology Master topologyのライフサイクルをすべて管理します。 いくつものコンテナで実行する。
Container Heronのトポロジーはそれぞれいくつかのコンテナで構成され、それぞれHeronインスタンスとStream manager, Metrics managerが存在する。Topology Masterと通信してDAGを正しく構成できるかをチェックする。
Stream Manager topologyの構成要素間のタプルの流れに関して働きかける。
*Heron Instance これはspoutかboltとして単一のタスクである。
Metrics Manager コンテナの中で、メトリックスを収集する。 そしてTopology ManagerとGriphiteをはじめとする外部収集基盤に送信する。
クラスタレベルのコンポーネント
Heron CLI CLIツールである。
Heron UI リッチな可視化インターフェースである。
Heron Tracker トポロジの情報を中央に集める役割がある。
Apache Heronのtopology
DAGがストリームを処理するために使われる。 トポロジーはステートレスでもステートフルでもなりうることができる。
二つの重要な概念があります。
- Spout: トポのジーのソースとなるもの。データを取得してくるところ。下の図で言うS1。
- Bolts: 定義した変換処理を施す。下の図でいうBX。
Topologyのアップロード
Heronのtopologyファイル(jar)をアップロードする構成は以下のようになっています。
メッセージセマンティクス
Apache Heronは以下の三つのメッセージセマンティクスをサポートしています。
| 名前 | 概要 |
|---|---|
| At most once | 最高で１つである。しかし、データに欠損があるかもしれない。 |
| At least once | 最低でも一つはあるが、重複はあるかもしれない。 |
| Effectively once | メッセージは重複して永続化されるが、処理するときは重複がないように保証される。 |
図にすると以下のようなものです。公式サイトのものが非常にわかりやすいので抜粋させていただきました。
特にEffectively onceについては、Apache Pulsarの記事で解説しているので、詳しく知りたければご覧ください。
Apache Stormとの比較
メタデータ
採用企業 Apache Stormは非常に多いのに対して、Apache Heronは今のところただ一つ。
機能面
- 各Heron Intstanceが1タスクしか保有しないため、デバックが簡単である。
- メトリックスマネージャーがいて、SpoutとBoltをひと単位として捉えるので、収集・解析が簡単になった
- Apache StormはNimbusがすべてのトポロジーを管理していたので単一障害点であったが、Topology Managerが独立していることで障害に強くなったといえる。
- レイテンシ、スループットなどがApache Heronの方が優れている。
- BackPressureがあることによって、予測を立てられるようになった
