编辑更新2016年2月9日：向Apache孵化器提交的数据流于2016年2月1日被接受，由此产生的项目现在被称为Apache Beam.

想象一下，如果每次升级服务器时，你都必须学习一个新的编程框架并重写所有应用程序。这听起来可能很疯狂，但大数据管道就是这样。

不久前，Apache Hadoop MapReduce是所有大数据的明显引擎，后来Apache Spark出现了，最近又出现了Apache Flink，一个流本地引擎。与升级硬件不同，采用这些更现代的引擎通常需要重写管道以采用特定于引擎的api，通常针对流式处理和批处理场景采用不同的实现。这可能意味着扔掉那些刚刚被认为（大部分）没有bug的用户代码，并用不成熟的新代码替换它们。所有这些仅仅是因为数据管道需要更好地扩展，或者具有更低的延迟，或者运行更便宜，或者完成更快。

调整这些方面不应该要求丢弃经过良好测试的业务逻辑。您应该能够将应用程序或数据管道移动到适当的引擎，或移动到适当的环境（例如，从on prem到cloud），同时保持业务逻辑完好无损。但是，要做到这一点，需要满足两个条件。首先，您需要一个可移植的SDK，它可以生成可以在许多可插拔执行环境之一上执行的程序。第二，SDK必须公开一个编程模型，它的语义关注于您的工作负载，而不是底层引擎的功能。例如，MapReduce作为一种编程模型并不符合要求（尽管MapReduce作为一种执行方法在某些情况下可能是合适的），因为它不能有效地表达低延迟计算。

Google专门设计了Dataflow来解决这两个问题。dataflowjavasdk的架构支持可插入的"runner"连接到执行引擎，目前已有四个引擎：data Artisans为Apache Flink创建了一个，Cloudera为Apache Spark创建了一个，Google实现了一个单节点本地执行运行程序以及一个用于Google托管云数据流服务的运行程序。

这种可移植性是可能的，因为数据流编程模型专注于现实生活中的流语义，比如实时事件时间（与事件到达的时间相反），和实际会话（与批处理循环强加的任意边界相反）。这使得数据流程序可以根据需要以批处理或流模式执行，并且可以在不需要重写的情况下从一个可插入执行引擎切换到另一个执行引擎。

今天我们在这个协作中又迈出了一步。与来自Cloudera、dataartisans、Talend、Cask和PayPal的参与者一起，我们发送了一份关于Dataflow成为Apache软件基金会（ASF）孵化器项目的提案。在这个提议中，数据流模型、javasdk和runner将被捆绑到一个孵化项目中，pythonsdk将在将来加入这个项目。我们认为，这一建议是朝着能够为多种处理需求定义一个数据管道的方向迈出的一步，而无需权衡，它可以在许多运行时、本地、云中或本地运行。googleclouddataflow仍将是一个"无操作"的托管服务，用于在googlecloud平台上快速、经济地执行数据流管道。