水槽VS卡夫卡VS別人

Question

可能是這個問題以前有人問，但我認爲這是很好的今天再考慮它給這些技術已經成熟。我們正在考慮使用flume，kafka，抄寫員或其他人將流facebook和twitter個人資料信息存儲到hbase中，以便稍後進行分析。我們正在考慮flume的目的，但我沒有與其他技術合作以做出明智的決定。任何能夠釋放光線的人都會很棒！非常感謝。

Answer 1

的mediawiki（維基百科）經歷了這一點，並發表了他們是如何來到他們的選擇（卡夫卡）VS抄寫，水槽和其他人一個很好的文章。

http://www.mediawiki.org/wiki/Analytics/Kraken/Request_Logging

新鏈接：
https://wikitech.wikimedia.org/wiki/Analytics/Kraken/Logging_Solutions_Recommendation

摘要後人：

「我們的建議是Apache的卡夫卡，一個分佈式的發佈 - 訂閱消息傳遞系統設計吞吐我們評估有關十幾[1]從分佈式日誌收集，CEP /流處理，和實時消息傳送系統的結構域繪製最好的同類系統。雖然這些系統提供surprisingl y類似的特徵，它們在實施方面存在很大差異，並且每個特徵都針對特定的工作情況（更詳細的技術討論可作爲附錄獲得）。 「有趣的是，它也非常關注資源節約[2]，以提供合理的折衷方案，放鬆保證以換取性能 - 某些東西可能不罷工的Facebook或谷歌作爲一個重要的特點在他們設計的系統。約束滋生的創造力。

「此外，卡夫卡具有特別感興趣的讀者操作的幾個特殊待遇。雖然它是用Scala編寫，它附帶有原生C++庫生產者可以嵌入我們的緩存服務器模塊中，從而不需要在這些服務器上運行的JVM。其次，生產者可以配置批量請求以優化網絡流量，但不要創建需要額外維護的持久本地日誌。 Kafka的I/O和內存使用情況由操作系統而不是JVM來決定[3]。在LinkedIn上製作的時候，每個數據中心有大約10,000名製作人員由8臺Kafka服務器處理，這些羣集將他們的數據流整合到一個分析數據中心中，Kafka支持通過簡單的鏡像配置盒

「這些功能是非常容易適合我們的預期使用情況。即使那些我們不打算使用的內容（例如「主題」類別的分片和路由選擇）也很有趣，並且在我們擴展目標時將來可能會有用。

「本文檔的其餘部分將深入更詳細地這些議題......」