2

有没有人有机会在这两个方面工作？我需要建立一个框架来移动数据。基本上，我们将点击流数据作为文本文件传入。这些数据需要从应用服务器转移到 HDFS，然后在归档后转移到 S3。

在 Flume 和 Scribe 之间进行选择时，我需要帮助。哪个在可管理性、设置方面更好，哪个更容易定制？

4

1 回答 1

2

查看此处发布的答案

我将引用答案：

  1. Flume 允许您从中心点配置 Flume 安装，而无需 ssh 进入每台机器、更新配置变量并重新启动一两个守护程序。您可以使用可用的 Flume jar 从网络中的任何命令行启动、停止、创建、删除和重新配置运行 Flume 的任何机器上的逻辑节点。

  2. Flume 还具有集中的活性监控。我们听说过一些关于 Scribe 进程静默失败的故事，但几天后一直未被发现，直到 Scribe 安装的其余部分在增加的负载下开始吱吱作响。Flume 允许您在一个地方查看所有逻辑节点的健康状况（请注意，这与机器活跃度监控不同；通常机器会在进程可能失败时保持运行）。

  3. Flume 支持三种不同类型的可靠性保证，允许您在资源使用和可靠性之间进行权衡。特别是，Flume 支持完全 ACKed 可靠性，并保证所有事件最终都会通过事件流。

  4. Flume 也非常可扩展 - 编写自己的源或接收器并将大多数系统与 Flume 集成非常容易。如果您自己滚动是不切实际的，那么让您的应用程序以 Flume 可以理解的形式输出事件通常非常简单（例如，Flume 可以运行 Unix 进程，所以如果您可以使用 shell 脚本来获取您的数据，那么您就是金的）。

这并不是使用 Flume 的所有好处的详尽列表——我没有涉及使用装饰器进行轻量级转换或元数据提取、配置语言、在单个 Flume 进程中运行多个逻辑节点的能力、自动分桶和滚动HDFS 中的日志文件……还有更多关于 Flume 的内容，我们期待与大家分享。

The key difference to me is that Cloudera is actively supporting Flume. While I do generally trust Facebook to maintain great open source projects, Cloudera's business is built around providing support for tools like this, so I have faith that Flume will longterm be better supported. I want to minimize the time I have to think about this particular problem. That said, so far I've had a lot of annoying issues where Flume was either a bit convoluted in its abstraction or buggy in its implementation, as you might expect from a pre-1.0 technology. If Asana weren't still in beta, I'd probably have chosen Scribe

于 2011-09-24T19:05:54.827 回答