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

Question

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

• 组件 A 获取页面。

• 组件 B 分析来自 A 的页面。

• 组件 C 存储来自 B 的分析过的点点滴滴。

显然，涉及的组件不止三个。

进一步要求：

• 每个组件都需要是一个单独的进程（或一组进程）。

• 生产者对他们的消费者一无所知。换句话说，组件 A 只生成数据，不知道哪些组件使用该数据。

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

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

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

• 连接到队列

• 处理连接错误

• 将数据序列化/反序列化为通用格式

• 运行实际的工作人员（goroutines 或 fork 子进程）

• 工人的动态扩展

• 容错

• 节点注册

• 处理指标

• 队列限制

• 队列优先级（一些工人不如其他工人重要）

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

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

这种东西是否存在一个好的框架？

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

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

Answer 1

因为 Go 有 CSP 通道，我建议 Go 提供了一个特殊的机会来实现一个简单、简洁但完全通用的并行框架。应该可以用更少的代码比大多数现有框架做得更好。Java 和 JVM 不可能有这样的东西。它只需要使用可配置的 TCP 传输来实现通道。这将包括写入通道端 API，包括一些用于读取端的预期服务器的通用规范一个读取通道端API，包括监听端口配置和支持 select编组/解组胶水以传输数据 - 可能是编码/gob这种框架的成功验收测试应该是使用通道的程序应该可以跨多个处理器分割，但仍保持相同的功能行为（即使性能不同）。Go 中有很多现有的传输层网络项目。值得注意的是ZeroMQ ( 0MQ ) ( gozmq , zmq2 , zmq3 )。

Answer 2

我知道您想避免使用 Hadoop+Java，但与其花时间开发自己的框架，不如看看Cascading。它为底层 MapReduce 作业提供了一个抽象层。维基百科上最好的总结，它 [级联]遵循“源-管道-接收器”范式，其中从源捕获数据，遵循执行数据分析过程的可重用“管道”，其中结果存储在输出文件或“接收器”中. 管道的创建独立于它们将处理的数据。一旦绑定到数据源和接收器，它就被称为“流”。这些流可以组合成一个“级联”，并且进程调度程序将确保给定的流在其所有依赖项都得到满足之前不会执行。管道和流可以重复使用和重新排序以支持不同的业务需求。您可能还想看看他们的一些示例，日志解析器、日志分析、TF-IDF。

Answer 3

我猜你正在寻找一个消息队列，比如beanstalkd、RabbitMQ或ØMQ（发音为 zero-MQ）。所有这些工具的本质是它们为 FIFO（或非 FIFO）队列提供推送/接收方法，有些甚至提供发布/订阅。因此，一个组件将数据放入队列，另一个组件读取。这种方法在添加或删除组件以及放大或缩小每个组件方面非常灵活。大多数这些工具已经有 Go（ØMQ 在 Gophers 中非常流行）和其他语言的库，所以你的开销代码很少。只需导入一个库并开始接收和推送消息。为了减少这种开销并避免对特定 API 的依赖，您可以编写一个瘦包，它使用这些消息队列系统之一来提供非常简单的推送/接收调用，并在您的所有工具中使用这个包。