利用例
以下はApache Kafka®の人気のある使い方の2,3の説明です。これらの領域で活動中の多くの概要については、このブログの投稿を見てください。
Kafka は伝統的なメッセージブローカーの代替として良く動作します。メッセージブローカーは様々な理由で使われます (データプロデューサからの処理の切り離し、未処理メッセージのバッファ、など)。ほとんどのメッセージングシステムと比較してKafkaはより良いスループット、組み込みのパーティショニング、リプリケーション、および大規模メッセージ処理アプリケーションのための良い解決法となる耐障害性を持ちます。
私たちの経験では、メッセージの使い方はしばしば比較的低スループットですが、低end-to-endレンテンシを必要とし、しばしばKafkaが提供する強い耐久性の保証に依存するかもしれません。
この領域において、KafkaはActiveMQ あるいは RabbitMQのような伝統的なメッセージングシステムと互換性があります。
Kafkaの元のユースケースはリアルタイム発行-購読フィードのセットとしてユーザのアクティビティトラッキング パイプラインを再構築できるようにすることです。これは、サイトアクティビティ(ページビュー、検索、あるいはユーザが取るかも知れない他のアクション)がアクティビティタイプごとに1つのトピックを持つ中核トピックへ発行されることを意味します。これらのフィードは、リアルタイム処理、リアルタイム監視、および オフライン処理やレポートのためにHadoopあるいはウェアハウス システムへのロードを含む様々な領域の使い方のために購読することができます。
多くのアクティビティメッセージが各ユーザページビューに対して保証されるので、アクティビティトラッキングはしばしば大きなものになります。
Kafka はしばしば操作の監視データのために使われます。これはオペレーションデータの中央集権フィードを生成するために、分散型アプリケーションからの統計の集約を必要とします。
多くの人がKafkaをログ集約の解決法として使います。ログ集約は一般的に物理的なログファイルをサーバから離れて集め、それらを中核の場所(ファイルサーバあるいはHDFSおそらく)に処理のために配置します。Kafka はファイルの詳細を抽象化し、メッセージのストリームとしてログあるいはイベントデータのよりきれいな抽象を行います。これは低レンテンシの処理と、複数のデータソースと分散データの消費のより簡単なサポートを許容します。ScribeあるいはFlumeのようなログ中心のシステムに比べて、Kafkaは同等の良いパフォーマンス、リプリケーションによる強力な耐久性の保証、およびend-to-endのより低いレイテンシを提供します。
Kafkaの多くのユーザは多数のステージから成る処理パイプライン内のデータを処理します。生の入力データはKafkaのトピックから消費され、集約され、質を高められ、あるいは更なる消費または処理のフォローアップのために新しいトピックに変換されます。例えば、ニュースの文章のお勧めのためのパイプラインの処理は、RSSフィードから文章の内容をクロールし、それを "articles" トピックに発行するかもしれません; その先の処理はこの内容を正規化あるいは重複を取り除ききれいになった文章の内容を新しいトピックに発行するかもしれません; 最終的な処理のステージはこの内容をユーザにお勧めするかもしれません。そのような処理パイプラインは各トピックに基づいたリアルタイムデータフローのグラフを生成します。上で述べたようなデータ処理を行うためにApache Kafkaでは0.10.0.0から
Kafka Streamsと呼ばれる軽量だが強力なストリーム処理ライブラリが利用可能です。Kafkaストリームは別として、代替となるオープンソースストリーム処理ツールは
Apache Storm と
Apache Samzaを含みます。
イベント ソーシング は状態の変化がレコードの時間順のシーケンスとして記録されるアプリケーション設計の形式です。とても大きな格納ログデータのためのKafkaのサポートは、この形式で構築されたアプリケーションのための洗練されたバックエンドになります。
Kafkaは分散型システムのための外部コミットログの一種として提供することができます。ログはノード間のデータのリプリケートを助け、障害ノードがデータを復旧するための再同期の仕組みとして振る舞います。Kafkaの
ログ コンパクション 機能はこの使い方をサポートします。この使い方において、Kafkaは
Apache BookKeeper プロジェクトに似ています。
