@Rays
2017-06-24T08:26:36.000000Z
字数 4072
阅读 1723
专访Frances Perry：关注Apache Beam
Apache 数据科学
摘要： InfoQ采访了Apache Beam项目管理委员会的Frances Perry，内容涉及企业采用Beam的动力所在，以及该Apache顶级项目的未来发展。
作者： Dylan Raithel
正文：
本文要点
Apache Beam是一种统一了批处理和流处理的编程模型，在今年年初成为了Apache软件基金会的顶级项目。Beam最初是作为Google Cloud Platform中DataFlow服务的一个组件。自去年年初以来，Beam在被搜索频次上逐渐取得了稳步增长，其社区电子邮件的分发列表也在同步增长。对Beam的搜索主要针对一些反复出现的问题，这些问题被频繁提及。
对于选用Beam的理由，有一系列的帖子、技术演讲和会议讨论已经给出了解释。其中，Beam的可移植性和良好的发展前途，使得Beam比其它任何新的数据流水线项目都更胜任于普遍存在并不断增加的流数据，这也是Beam项目被广泛采用的最重要动机之一。针对Beam的编程模型以及为什么要选用Beam构建新数据流水线等问题，InfoQ对Beam项目管理委员会（PMC，Project Management Committee）顾问和Google DataFlow工程师Frances Perry进行了一次深度采访。
InfoQ：从理念上看，如果仅是根据Beam的语义和概念性术语，感觉Beam在考虑数据流水线问题时，应是采用了一种“数据分析优先”的方法。您能从Beam的核心理念和语言与之前产品的差异上，介绍一下对Beam的考虑过程与设计吗？
Frances Perry：我很喜欢“Beam”一词！Beam在设计上就是要将用户的数据和程序与底层运行时的细节分离开来。这意味着用户在使用Beam时，可以聚焦于数据的属性（受限的，或是非受限的？还是潜在无序的？），以及想要在数据上执行的算法（求和、连接、过滤、直方图等）。用户无需指定底层运行时的相关信息，例如，应如何对数据进行分片以获得更好的性能，当前数据延迟情况如何等。这的确十分重要，因为上述事情并非一成不变的。数据、代码和环境会发生改变，这会使最为细致的手工调优也可能失败。
InfoQ：Beam核心项目主要关注于对Python API的完全支持。即便是在Beam开源前，Python API是否一直是项目的焦点？提供对Python的支持，对底层的Java API有着怎样的影响？
Frances Perry： Python一直是Beam项目的关注点。我们一直谨记需要去满足开发人员的最新需求，尤其是对各种语言的喜好。在项目早期，我们得到的经验教训就是，如果你力图在多种语言上证实同一系列的概念，这就变成了一个十分微妙的平衡协调问题。你需要做抽象，以对齐跨语言的特性，否则在细微差异的追踪、概念的理解等问题上完全是一场噩梦。但是从另一方面看，需要让开发人员认为每个SDK是原生的。Python开发人员想要类似于Python那样的API，而非看上去像是由Java开发人员编写的。
InfoQ：Beam在不断的成熟，添加了对更多处理后端的支持，您以及其他的项目主管是如何看待这一过程中所存在的长期挑战？
Frances Perry： Beam是一个“胶水”项目，其核心抽象表达了这样一种理念，就是通过让多个复杂项目共同工作的方式，将各个项目连接在一起。这样的多点集成不仅是一种关键能力，而且表现了一种真实的挑战。我们自项目起始时，就将Beam设计为可扩展的。我们一开始就给出了多个Runner（译者注：Runner的中文可理解为“执行引擎”或“计算引擎”）这一理念，此后我们也认识到需要提供针对多种SDK、多种IO连接器和多种文件系统的选项。但是正如大家都知道的，没有必要为概化一件事情而构建一个API，正确的做法是给出多个工作实现。虽然多个Runner所做的事情非常相似，但是各个Runner实现上略有不同。因此，解决如何构建能在可移植性和表现力间取得平衡的正确抽象这一问题并非易事。这正是各个社区中的大众经验的最有价值之处。
InfoQ：Beam所支持的后端在不断的增加，这对Beam核心抽象的可用性提出了挑战。例如，在Beam的核心语义中，各处理引擎间存在着重叠的特性集。那么该项目是否存在着扇出（Fan-out）风险？
Frances Perry：我们多次听说了这样的担心，即Beam将最终演化为各种后端引擎的最小公共特性集，进而变为一个索然无味的项目。但是，我们意在使Beam不仅担当所有引擎的功能交集（这个交集规模非常有限！），而且成为它们功能的合集（即使是这些功能中的“无用之物”）。不仅如此，Beam力图立于数据处理的潮头，不仅将功能推送到运行时引擎中，而且从运行时引擎中拉取回模式。Keyed State就是一个很好的例子，虽然它是一个存在于各种引擎中的功能，并提供了有趣的和常见的用例，但是它先前是不能在Beam中表达的。因此，我们最近扩展了Beam模型，并根据Beam的设计原则，加入了该功能的一个实现版本。反过来说，我们希望Beam将同样会对各种引擎的发展路线图产生应用。例如，Flink的DataStreams的语义就受到了Beam模型（née DataFlow）的影响。
InfoQ：现在Beam已经具有了第一个稳定版本。对于那些已采用了颇具规模的Spark、FLink或Hadoop流水线的企业，什么能促使它们从现有的系统迁移到使用Beam？
Frances Perry：我认为相对于其它系统而言，有三个原因导致Beam颇为引人关注。
统一的批处理和流处理：虽然有部分系统也同时支持批处理和流处理，但是这些系统通常是通过独自的API分别实现的。在Beam中，批处理和流处理处理在机制上是相同的，只是在延迟、完整性和代价上存在着一些差异。在Beam中，不存在从批处理转到流处理的陡峭学习和重写曲线。因此，如果用户今天编写了一个批处理流水线，但是第二天就需要对延迟做更改，这在Beam中是非常易于调整的。我们可以从Mobile Gaming例子中看到这一过程。
提升了抽象等级的API： Beam的API聚焦于捕获用户数据和逻辑的属性，而非泄漏低层运行时的细节。这不仅是可移植性（参见下一特性）的关键所在，而且还赋予了运行时大量灵活的执行方式。大部分Runner已经做到了相当基本的ParDo Fusion（也称为函数组合）之类的优化。对部分runner，其它的优化依然正在实现中。例如，Beam的Source API是特定构建的，以避免过度声明流水线中的数据切片。相反，他们赋予Runner以正确的钩子（Hook），动态地重平衡工作。这从根本上消除了低性能的数据切片问题，会在性能上产生很大的差异。总而言之，如果我们在Runner中构建了更多的智能，我们就能更好地从底层细节中抽身出来。当数据、代码和环境发生变化时，即便是最为细致的手工调优也会发生失败。
运行时之间的可移植性：由于在Beam中数据的形状和运行时的需求这两者基本上是分离的，同一流水线可以用多种方式运行。这意味着，当用户不得不从本地部署（on-premise）迁移到云端时，或是不得不从一个经验证运行良好的系统迁移到一个最新的环境上时，不必重写代码。用户可以很容易地从各种选项中做出选取，找出最适合当前工作需求的、综合考虑了环境及性能因素的系统。并可综合地考虑使用开源Runner在本地部署中处理敏感数据，并在云管理的服务上处理其它的数据。
InfoQ：您是否看到过这样的用例，就是为了使用Beam，需要以另一种方式重新实现底层处理引擎？
Frances Perry：当然有。正如前面所提及的，这毫不令人惊奇，甚至是鼓舞人心。但同时，我们正努力去十分现实地解决如何处理这些不匹配的问题。我们已运用能力矩阵（Capability Matrix）去清晰地追踪每个Runner支持的Beam模型部分。一旦有可能，我们就会设计出以可选形式提供的额外功能，如果没有更为简单和正确的实现，添加这样的功能将会改进Runner的性能。
InfoQ：Beam项目下一步将会如何发展？
Frances Perry：在我看来，有三个关键的领域：可移植的架构、准备好用于生产环境，以及项目集成。
我们将可移植性置入了Java SDK，可以在多个Runner上运行同一流水线。但是我们还必须要做更多的工作，以使所有Beam SDK具有这一功能。我迫切期待着有朝一日Python SDK也同样可移植。
其次，已经有用户将Beam用于生产环境。Beam的用户越多，我们就能更好地精雕细琢。要改进每个用户的体验，与社区交互是非常关键的。
最后一点，我们正在不断寻求新的方法去集成Beam与其它的开源项目。我们不仅添加了Apache Apex等的新Runner，而且也创建了与Apache Calcite等项目的集成，使得Beam对新类型用户更加开放。
被访者简介
Frances Perry 是一位软件工程师，工作兴趣在于让大规模数据处理更为简化、直观和高效。在Google内部数据处理栈上工作多年后，她加入了Cloud Dataflow团队，致力于使技术对外部云用户可用。她曾领导了Dataflow的统一流处理/批处理编程模型的早期工作，现在是Apache Beam项目管理委员会的一名成员。
