ビッグデータ ストリーム処理: Flume、Kafka、NiFi の比較

ビッグ データ パイプラインを構築するときは、Hadoop エコシステムのエントリ ポイントで通常発生するデータの量、種類、速度の処理を考慮する必要があります。要件を満たすためにどのツールを採用するかを決定する際には、拡張性、信頼性、適応性、開発時間に関するコストなどの予備的な要素が考慮されます。この記事では、Flume、Kafka、NiFi という 3 つの Apache 処理ツールについて簡単に説明します。これら 3 つの製品はいずれも優れたパフォーマンスを備え、水平方向に拡張でき、カスタム コンポーネントを通じて機能を拡張するプラグイン メカニズムを提供します。

アパッチ・フルーム

Flume デプロイメントは、トポロジを使用して構成された 1 つ以上のエージェントで構成されます。 Flume エージェントは、Flume トポロジの基本的な構成要素、つまりソース、チャネル、シンクをホストする JVM プロセスです。 Flume クライアントはイベントをソースに送信し、ソースはそれらのイベントをチャネルと呼ばれる一時バッファに一括して配置します。その後、データはそこからデータの最終的な宛先に接続されたシンクに流れます。シンクは、他の Flume エージェントの後続のデータ ソースになることもできます。エージェントは連鎖させることができ、各エージェントは複数のソース、チャネル、シンクを持つことができます。

Flume は、ストリーミング イベントを収集、集約し、Hadoop に送信するために使用できる分散システムです。 Kafka チャネルや Avro シンクなど、多くの組み込みソース、チャネル、シンクがあります。 Flume は構成ベースであり、チャネル内のデータに対して簡単な変換を実行するインターセプターを備えています。

注意しないと、Flume を使用するとデータが失われやすくなります。たとえば、高スループットのためにメモリ チャネルを選択すると、プロキシ ノードがシャットダウンされたときにデータが失われるという欠点があります。ファイル チャネルは、遅延の増加を犠牲にして永続性を提供します。それでも、データは他のノードに複製されないため、ファイル チャネルの信頼性は、基盤となるディスクの信頼性と同じ程度になります。 Flume は、マルチホップ/ファンインおよびファンアウト フローを通じてスケーラビリティを提供します。高可用性 (HA) を実現するために、ブローカーを水平方向にスケーリングできます。

アパッチカフカ

Kafka は、データ プロデューサーとコンシューマーを分離する分散型の高スループット メッセージ バスです。メッセージはトピックに編成され、トピックはパーティションに分割され、パーティションはクラスター内のノード (ブローカーと呼ばれる) 間で複製されます。 Flume と比較すると、Kafka はスケーラビリティとメッセージの耐久性が優れています。 Kafka には現在 2 つのバージョンがあります。1 つは「クラシック」プロデューサー/コンシューマー モデルで、もう 1 つは外部データ ストアへの構成可能なコネクタ (ソース/シンク) を提供する新しい Kafka-Connect です。

Kafka は、大規模なソフトウェア システムのコンポーネント間のイベント処理と統合に使用できます。さらに、Kafka には Kafka Streams が付属しており、Apache Spark や Apache Flink のような別のクラスターを必要とせずに、シンプルなストリーム処理に使用できます。

メッセージはディスク上に保存され、クラスター全体に複製されるため、Flume の場合ほどデータ損失は発生しません。つまり、Kafka クライアントを使用する場合でも、Connect API を使用する場合でも、プロデューサー/ソースとコンシューマー/シンクの両方には通常、カスタム コーディングが必要です。 Flume と同様に、メッセージ サイズには制限があります。最後に、通信を可能にするには、Kafka のプロデューサーとコンシューマーがプロトコル、形式、スキーマについて合意する必要がありますが、場合によってはこれが問題になることがあります。

アパッチニフィ

Flume や Kafka とは異なり、NiFi は任意のサイズのメッセージを処理できます。 NiFi は、Web ベースのドラッグ アンド ドロップ ユーザー インターフェイスの背後でクラスター内で実行され、リアルタイム制御を提供するため、任意のソースと任意の宛先間のデータの移動を簡単に管理できます。さまざまな形式、モード、プロトコル、速度、サイズの分散型ソースをサポートします。

NiFi は、厳格なセキュリティとコンプライアンスの要件を備えたミッションクリティカルなデータフローで使用でき、プロセス全体を視覚化し、リアルタイムで変更を加えることができます。執筆時点では、ドラッグ アンド ドロップ、構成してすぐに使用できる、すぐに使用できるプロセッサ (Flume プロセッサと Kafka プロセッサを含む) が 200 個近くあります。 NiFi の主な機能としては、優先キューイング、データ追跡、接続ごとのバックプレッシャーしきい値設定などがあります。

NiFi はフォールト トレラントなプロダクション パイプラインを作成するために使用されますが、Kafka のようにデータを複製することはまだできません。ノードに障害が発生した場合、フローは別のノードに転送されますが、障害が発生したノードのキューに入れられたデータは、そのノードが復旧するまで待機する必要があります。 NiFi は本格的な ETL ツールではなく、複雑な計算やイベント処理 (CEP) にも最適ではありません。これを行うには、Apache Flink、Spark Streaming、Storm などのストリーミング フレームワークに接続する必要があります。

組み合わせ

すべての要件を満たす単一のツールは存在しません。さまざまな操作をより効率的に実行するツールを組み合わせることで、機能性が向上し、より多くのシナリオに対応できる柔軟性が高まります。ニーズに応じて、NiFi と Flume はどちらも Kafka プロデューサーまたはコンシューマーとして機能できます。

Flume と Kafka の統合は非常に人気があり、独自の名前「Flafka」が付けられています (これは私が作った名前ではありません)。 Flafka には、Kafka ソース、Kafka チャネル、Kafka プールが含まれます。 Flume と Kafka を組み合わせることで、Kafka はカスタム コーディングを回避し、Flume の実績あるリソースとシンクを活用できます。 Kafka チャネルを通過する Flume イベントは、回復力のために Kafka ブローカーに保存され、複製されます。

ツールを組み合わせると、機能の重複が多くなるため無駄に思えるかもしれません。たとえば、NiFi と Kafka はどちらも、プロデューサーとコンシューマーを接続するブローカーを提供します。ただし、やり方は異なります。NiFi では、データ フロー ロジックのほとんどがプロデューサー/コンシューマー内ではなくプロキシ内にあるため、集中管理が可能になります。 NiFi は、データ フロー管理という 1 つの重要なことを実行するように構築されました。 2 つのツールを組み合わせることで、NiFi は Kafka の信頼性の高いストリーミング データ ストレージを最大限に活用しながら、Kafka では解決できないデータ フローの課題を解決できます。

終わり

要約: