水路対kafka対他
この質問は以前に尋ねられた可能性がありますが、これらのテクノロジーが成熟していることを考えると、今日もう一度考え直すことは良いことだと思います。 Flume、kafka、scribeなどのいずれかを使用して、ストリーミングFacebookとTwitterのプロファイル情報をhbaseに保存し、後で分析を行います。目的のために水路を検討していますが、私は情報に基づいた決定を行うために他のテクノロジーを使用していません。いくつかの光を当てることができる人は誰でも素晴らしいでしょう！どうもありがとう。
Mediawiki（ウィキペディア）がこれを検討し、彼らがどのようにして選択（Kafka）とScribe、Flumeなどに到達したかについての素晴らしい記事を公開しました。
http://www.mediawiki.org/wiki/Analytics/Kraken/Request_Logging
新しいリンク：
https://wikitech.wikimedia.org/wiki/Analytics/Kraken/Logging_Solutions_Recommendation
後世の要約：
「私たちの推奨は、スループット用に設計された分散pub-subメッセージングシステムであるApache Kafkaです。分散ログ収集、CEP /ストリーム処理、およびリアルタイムのドメインから引き出された約12の最良のシステムを評価しましたメッセージングシステムこれらのシステムは驚くほど似た機能を提供しますが、実装は大幅に異なり、それぞれが特定の作業プロファイルに特化しています（詳細な技術的な説明は付録として提供されています）。
「カフカは、スループットに特化しており、アーキテクチャのすべての層に明示的に分散されているため、際立っています。興味深いことに、リソースの節約にも関心があり[2]、パフォーマンスと引き換えに保証を緩める賢明なトレードオフを提供しています。 FacebookまたはGoogleは、彼らが設計したシステムの重要な機能として、制約が創造性を生み出します。
「また、Kafkaには、Operationsリーダーにとって特に興味深いいくつかの特典があります。Scalaで記述されていますが、キャッシュサーバーのモジュールに埋め込むことができるネイティブC++プロデューサーライブラリが付属しています。 、これらのサーバーでJVMを実行する必要をなくします。2番目に、プロデューサーはリクエストをバッチ処理してネットワークトラフィックを最適化するように構成できますが、追加のメンテナンスを必要とする永続的なローカルログを作成しません。KafkaのI/Oとメモリの使用量は残されますJVMではなくOSに[3]。
「KafkaはLinkedInによって作成され、現在はApacheプロジェクトです。LinkedInでの運用では、約10,000のプロデューサーがデータセンターごとに8つのKafkaサーバーによって処理されます。これらのクラスターは、ストリームを単一の分析データセンターに統合します。 Kafkaは、単純なミラーリング構成を介して、箱から出してすぐにサポートします。
「これらの機能は、私たちの使用目的に非常に適しています。「トピック」カテゴリによるシャーディングやルーティングなど、使用するつもりのないものも興味深いものであり、将来的に目標を拡大する際に役立つ可能性があります。
「このドキュメントの残りの部分では、これらのトピックについて詳しく説明しています...」