AzureイベントハブとAzure関数を使用したパイプライン処理

Question

azureイベントハブの新機能であり、 にEventHubs/azureを使用してパイプライン処理を実装するオプションがあります機能？

イベントハブを経由してくるデータストリームがあります。いくつかのコンポーネントがあり、各コンポーネントは特定の機能を実行し、その結果を次のコンポーネントに渡します。次のコンポーネントは、イベント元のデータと以前のコンポーネントから生成された結果（シーケンシングの依存関係を持つことができる）の両方を必要とする可能性があります。 このようなシナリオでは、イベントハブ/アズール機能が適していますか？私が理解したところでは、各消費者が独自のイベントコピーを取得するので、消費者のパイプライン化はできません。

紺碧の大きなイベントストリームで、コンポーネントのパイプライン設計（新しいコンポーネントを必要に応じてパイプラインで追加できるようにする）に最適な方法は何ですか？ または、紺碧のハブの唯一のオプションは、単一のコンシューマにコンポーネントの完全な処理パイプラインを作成させることです（これはやや連結されます）。 私は

Answer 1

Eventhubsは、データ/イベント・パイプラインのデータ摂取エンドを形成する（管理するために完全に切り離されていても、あまりにも多くのイベントハブ）の各コンポーネント間で異なるイベントハブを使用する必要はありません。そこからデータが処理され、分析され（リアルタイム）、格納され、おそらく分類され、履歴データが後で分析される。これは典型的なパイプラインを形成します。 イベントハブに取り込まれるすべてのメッセージに対して、さまざまなコンポーネント/ルールエンジンなどを使用して一連の異なるタイプの処理を適用することを検討しています。私は考えることができる

オプションは

1）EventProcessorHostある - ここにあなたが非同期形式でイベントハブのすべてまたは特定のパーティションからのメッセージを受信するために、独自のカスタムコード（部品次々に）書き込むことができます。これには、コード内のすべてのロジックを配線する必要があります。したがって、新しいコンポーネントを導入する必要がある場合は、コードの変更と新しい展開が必要になります。

2）あなたのポイントに基づいて、複数の中間イベントハブを設定して処理することもできますが、それは高価になる可能性があります。後続の処理のためにメッセージをロードするための中間点としてサービスバスのキューを見たい場合は、安価なオプションになります。

3）ロジックアプリケーションは、ワークフローオーケストレーションタイプのモデルを提供します。この場合、ワークフローを開始するためのトリガとして、イベントハブのイベントを持たせることができます。しかし、これがあなたの要求に完全に合っているかどうか、また取り込まれたデータの量が多い場合はスケーリングとパフォーマンスの疑問符があるかもしれません。