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