mapreduce - 是否有分布式数据处理管道框架，或者组织一个的好方法？

Question

我正在设计一个需要一组分布式处理工作器的应用程序，这些工作器需要在特定流中异步使用和生成数据。例如:

• 组件 A 获取页面。
• 组件 B 分析来自 A 的页面。
• 组件 C 存储来自 B 的经过分析的点点滴滴。

显然不仅仅涉及三个组件。

进一步的要求:

• 每个组件都需要是一个单独的进程(或一组进程)。
• 生产者对其消费者一无所知。换句话说，组件 A 只是产生数据，并不知道哪些组件使用该数据。

这是一种由面向拓扑的系统解决的数据流，如 Storm .虽然 Storm 看起来不错，但我持怀疑态度；它是一个 Java 系统，并且基于 Thrift，我不喜欢这两者。

我目前倾向于使用 AMQP 作为数据传输，使用 HTTP 作为数据共享/存储协议(protocol)的 pub/sub-style 方法。这意味着 AMQP 队列模型成为一个公共(public) API——换句话说，消费者需要知道生产者使用哪个 AMQP 主机和队列——我对此不是特别高兴，但可能值得妥协。

AMQP 方法的另一个问题是每个组件都必须具有非常相似的逻辑:

• 连接到队列
• 处理连接错误
• 将数据序列化/反序列化为通用格式
• 运行实际的 worker(goroutines 或 fork 子流程)
• worker 的动态扩展
• 容错
• 节点注册
• 处理指标
• 队列节流
• 队列优先级(一些 worker 不如其他 worker 重要)

……以及每个组件需要的许多其他小细节。

即使消费者在逻辑上非常简单(想想 MapReduce 作业，比如将文本拆分为标记)，也有很多样板文件。当然，我可以自己完成所有这一切——我非常熟悉 AMQP 和队列以及其他所有东西——并将所有这些都包装在一个由所有组件共享的公共(public)包中，但我已经开始着手发明一个框架了。

是否存在针对此类内容的良好框架？

请注意，我专门询问有关 Go 的问题。我想避免使用 Hadoop 和整个 Java 堆栈。

编辑:为清楚起见添加了一些要点。

Answer 1

因为 Go 有 CSP channel ，我建议 Go 提供一个特殊的机会来实现一个简单、简洁但完全通用的并行框架。它应该可以用更少的代码比大多数现有框架做得更好。 Java 和 JVM 不能有这样的东西。

它只需要使用可配置的 TCP 传输实现 channel 。这将包括

• 一个编写 channel 端的 API，包括一些用于读取端的预期服务器的一般规范
• 一个读取 channel 端的API，包括监听端口配置和对select的支持
• 编码/解码胶水以传输数据 - 可能是 encoding/gob

此类框架的成功验收测试应该是使用 channel 的程序应该可以跨多个处理器进行分割，但仍保留相同的功能行为(即使性能不同)。

有quite a few Go 中现有的传输层网络项目。值得注意的是 ZeroMQ (0MQ) ( gozmq , zmq2 , zmq3 )。