scribe - 水槽 vs 卡夫卡 vs 其他

Question

可能以前有人问过这个问题，但鉴于这些技术已经成熟，我认为今天再次考虑是件好事。我们希望使用 Flume、kafka、scribe 或其他之一将流式 facebook 和 twitter 个人资料信息存储到 hbase 中，以便稍后进行分析。我们正在考虑使用水槽，但我没有使用其他技术来做出明智的决定。任何能够揭示一些光芒的人都会很棒！非常感谢。

Answer 1

Mediawiki（维基百科）经历了这一点，并发表了一篇很好的文章，介绍了他们如何选择（Kafka）与 Scribe、Flume 等。

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

新链接：
https ://wikitech.wikimedia.org/wiki/Analytics/Archive/Hadoop_Logging_-_Solutions_Recommendation

后人总结：

“我们的推荐是 Apache Kafka，这是一个为吞吐量而设计的分布式发布-订阅消息系统。我们评估了大约十几个 [1] 来自分布式日志收集、CEP / 流处理和实时领域的最佳系统消息系统。虽然这些系统提供了惊人的相似特性，但它们在实现上却大不相同，并且每个系统都专门针对特定的工作配置文件（附录中提供了更全面的技术讨论）。

“Kafka 之所以脱颖而出，是因为它专门用于吞吐量并明确分布在其架构的所有层中。有趣的是，它还非常关注资源节约 [2] 以提供合理的权衡，以放松保证以换取性能——这可能不会发生Facebook 或 Google 作为他们设计的系统中的一个重要功能。约束孕育创造力。

“此外，Kafka 有一些操作读者特别感兴趣的好处。虽然它是用 Scala 编写的，但它附带了一个本地 C++ 生产者库，可以嵌入到我们的缓存服务器的模块中，从而无需在其上运行 JVM其次，生产者可以配置为批处理请求以优化网络流量，但不要创建需要额外维护的持久本地日志。Kafka 的 I/O 和内存使用由操作系统而不是 JVM [3 ]。

“Kafka 是由 LinkedIn 编写的，现在是一个 Apache 项目。在 LinkedIn 的生产中，每个数据中心大约有 10,000 个生产者由 8 个 Kafka 服务器处理。这些集群将它们的流整合到一个分析数据中心，Kafka 通过一个开箱即用的简单的镜像配置。

“这些功能非常适合我们的预期用例；即使是我们不打算使用的那些——例如按“主题”类别进行分片和路由——也很有趣，并且在我们扩展目标时可能在未来证明是有用的。

“本文档的其余部分将更详细地探讨这些主题……”