比较有前景和新的开源大数据技术分享给你

在实现企业背景调查平台的过程中，除了Spark，我们使用了很多开源组件：Flume、canal、HBase、Neo4j等。这些优秀的开源组件使得工程师拥有了更多可能。在大数据领域，开源软件更是最主要的力量。本节将介绍一些比较有前景和新的开源大数据技术。

16.3.1　Apache Flink

不同于大多数起源于硅谷的大数据开源项目，Flink起源于2010年几个德国柏林的大学和研究机构的研究项目，最初项目名是StratoSphere，2014年5月加入Apache软件基金会，改名Flink，并于当年年底从孵化器毕业成为Apache顶级项目。自从加入了Apache，Flink发展速度非常迅猛，截至目前已经有500余名贡献者。如今，每年4月，Flink的技术盛会Flink Summit也会在旧金山如期举行。

与Spark不同，Flink诞生较晚，但具有很强的后发优势，尤其是在流处理方面。另外，Flink也用Table API统一了流和批的处理方式，这点与Spark的DataFrame API类似，但是比Structured Streaming要早。图16-6是Flink的架构图，FlinkML是Flink的机器学习库，Gelly是图处理框架。

图16-6　Flink架构

如图16-6所示，可以看到在Flink中流处理和批处理底层处理引擎是通用的。总的来说，Flink和Structured Streaming都是Dataflow模型的开源实现，差别会越来越小。

最后我们可以从Beam的角度来对比下Spark、Dataflow和Flink，Beam官网从“3W1H”这4个维度来横向比较Flink、Spark、Dataflow以及多种主流计算框架，如图16-7所示。

图16-7　计算框架功能对比

毋庸置疑，Google Dataflow无论从推出时间和设计思想来说都占据优势，功能最完备，而Flink目前功能性要明显优于Structured Streaming。

2019年1月，来自中国的互联网巨头阿里巴巴宣布以9000万欧元的价格收购总部位于柏林的Flink母公司Data Artisans，并立刻启动Blink与Flink合并事宜，有了巨头的资本和赋能，对Flink来说无疑是巨大利好。

16.3.2　Apache Apex

Apache Apex由DataTorrent公司在2015年6月推出，是一个企业级的基于Hadoop和YARN的数据处理平台，也是成为Apache顶级项目用时最短的项目之一（其标识如图16-8所示）。Apex和Spark与Flink一样，也统一了流处理和批处理。Apache Apex同样借鉴了Dataflow的思想，将数据抽象为无边界表，支持基于事件时间处理和窗口操作以及端到端的恰好一次的消息送达保证。Apex也可以作为Beam后端的执行引擎，具有分布式、可扩展、低延迟的特性，编程语言为Java。

图16-8　Apache Apex

16.3.3　Ray

随着机器学习算法和技术的发展，越来越多的机器学习应用需要在多台机器上并行执行，但是集群中的机器学习基础架构仍然是专门设计的。当然，确实存在一些优秀的特定解决方案（如参数服务器和超参搜索）以及一些高质量的分布式系统，如Hadoop和Spark。但是，对于那些前沿探索者来说通常要从0开始构建自己的系统，这意味着要耗费大量的时间和精力。例如，一个简单概念的算法，如论文“Evolution Strategies as a Scalable Alternative to Reinforcement Learning”。算法包含数十行的伪代码，它的Python实现也很简单。但是，如果想在一个较为大型的集群上运行，需要上千行代码的实现，其中包含通信协议、数据序列化和反序列化的策略以及各种数据处理策略。

Ray是RISE实验室针对机器学习领域开发的一种新的分布式计算框架，官方对它的定义是“灵活的高性能的分布式执行框架”。Ray要解决的问题，主要是在类似增强学习这样的场景中所遇到的工程问题。增强学习需要模拟目标系统的环境来实时获取反馈信息，从而判断收益并调整参数。模拟环境的过程可能涉及大量低延迟的计算任务，而这些计算任务通常来说执行时间差别很大，有些数百毫秒就完成任务，有些可能需要十几分钟。像Spark这样的MapReduce类型计算框架很难支持上述需求，Spark的计算资源本质上是对基于CPU的操作系统线程抽象，因此Spark很难将数以亿计的仿真实体合理地同时调度到集群中的CPU中，CPU数和计算任务数之间通常差了很多个数量级，而且MapReduce这种类型的计算框架是一种同步计算框架，等待所有计算任务完成同步不仅开销很大而且很难实现。此外，Spark的计算任务图是静止的，不会改变，而在增强学习中，整个任务流程的计算任务图也可能是动态变化的，系统往往可能需要根据前一个环节的结果，调整下一个环节的行为参数或者流程。这些大量的对计算任务图的修改很难在Spark中得到有效的支持。

Ray与TensorFlow、PyTorch和MXNet等深度学习框架互相兼容，在很多应用中，我们都可以很自然地在Ray中使用一个或多个深度学习框架。而其他分布式系统，例如Spark或者Hadoop都不是以构建人工智能应用为目标，基于此UC Berkeley的研究员认为目前的分布式系统缺乏以下特性：

• 支持毫秒级延迟的任务处理，每秒处理百万级任务；
• 嵌套的并行化（任务内的并行化任务，例如超参数搜索中的并行模拟）；
• 在运行时动态确定任意任务的依赖性（例如，避免等待缓慢的工作节点）；
• 在共享可变状态下运行任务；
• 支持异构计算（GPU、CPU等）。

这些都是Ray与MapReduce类型的计算框架不同之处。

Ray的架构分为两层，第一层为应用层，第二层为系统层，如图16-9所示，应用层实现了计算模型和逻辑，系统层负责调度、数据管理以满足性能和容错的需求。

图16-9　Ray架构

在应用层中，Driver是执行用户程序的进程；Worker会执行由Driver或者其他Worker调用（远程调用）的任务。Actor是一个有状态的进程，在调用时执行暴露的方法。与Worker不同，Actor由Worker和Driver显式地实例化。Actor和Worker都是串行执行方法。Worker是无状态的，所以它不用跨任务维护本地状态，相同的参数远程调用相同的远程函数将返回相同的结果，与具体执行的Worker无关。Actor是一个有状态的进程，方法调用的结果取决于该Actor之前执行的方法。

在系统层中，核心是全局控制存储（GCS），它存储所有最新的元数据并控制系统中的状态信息，通过这种集中式存储状态，GCS使其他每个组件都无状态了。这不仅简化了容错机制（故障时，组件重启并从GCS中读取最新的状态），并且可以轻松扩展（扩展的副本都可以从GCS中获取最新的状态）。

Ray采用两层（本地-全局）调度方案，与普通的两层调度方案不同，在节点上创建的计算任务首先会交给本地的调度器，而不是提交给全局调度器。本地调度器在本地调度计算任务，除非节点不堪重负，或者不能满足任务的要求（如缺少GPU、任务输入在远端）。如果本地调度程序未调度任务，则它将任务发送到全局调度器，由全局调度器再次进行调度，如果全局调度器遇到瓶颈，我们可以实例化多个全局调度器，本地调度器会随机选择一个并向其提交任务，如图16-10所示，这种调度方式称为自下而上的分布式调度器（bottom-up distributed scheduler）。

图16-10　自下而上的分布式调度器

为了最小化计算任务的延迟，Ray实现了一个内存分布式存储系统，本质上是一个对象存储（object store）来存储每个任务的输入和输出。它可以使Actor和Worker之间高效地共享数据。在每个节点上，Ray通过共享内存存储对象。这种架构使任务之间无须进行数据复制。此外，Ray使用了Apache Arrow这种高效的内存布局。

由于Ray采用Python作为编程语言，底层采用了Actor框架来进行远程调用，开发者只需要通过寥寥数行代码就能将在笔记本电脑里运行的算法原型转换成在分布式集群上运行的高性能应用。Ray本质上是面向人工智能应用的分布式计算框架，它和Spark这类面向海量数据处理的计算框架不存在竞争关系而是互为补充：我们可以用Spark进行数据预处理，接着用Ray来进行人工智能应用开发。

16.4　Spark未来发展方向

从2009年Spark诞生之日起，距今已经过十年，Spark也将在今年迎来自己的第三个大版本Spark 3.0。在这十年里，Spark经历了脱胎换骨的变化，目标也逐渐清晰，社区对Spark未来的规划也逐渐明朗，可以预见的是在未来一段时间，Spark将沿着这个路线飞速发展，Spark目前的三大目标如下。

• 统一数据处理 + 人工智能。从2017年Spark Summit改名为Spark + AI Summit开始，Spark也将官网的口号从“闪电般的数据分析引擎”改为“大数据的统一分析引擎”，这些都昭示了Spark在数据科学和数据工程领域的宏大愿景：统一与融合。在Hydrogen项目中，我们可以清晰地看到Spark为之而努力的路线图。在Spark 2.x中：SPARK-21190实现了向量化的UDF，SPARK-24374实现了同步栅调度。在Spark 3.x中：Hydrogen项目将会实现加速器（GPU、FPGA）感知调度（SPARK-24615）和通用（支持更多语言）的向量化UDF（SPARK-24579）。
• 随处运行。随处运行一直是Spark的目标，Spark最初是被设计运行在Mesos中，随着使用人数和部署需求的不断增多，Spark增加了YARN、local和standalone模式。随着Kubernetes击败Mesos成为最流行的容器编排系统，目前运行在Kubernetes中的Spark实例数量突飞猛进。社区很早就注意到了Kubernetes的潜力，Spark 2.4适时推出了Spark on Kubernetes模式，在3.x中，会继续增加Pod模板、动态资源分配和外部Shuffle服务等新特性。
• 简洁易用的API。Spark深受用户喜爱的一个很重要的原因就是其简洁易用的API，作者有个朋友，平时一直用Spark做数据处理，但是他处理的数据量并不大，问其原因，答曰API好用，加上对SQL支持很好。从Spark诞生之日开始，Spark使用的接口从最初的RDD API、DataFrame API进化到最后的Dataset API，从最初的只支持一种语言到支持多种语言，Spark在降低用户学习成本和提升用户体验方面不遗余力。

优化和提升从来都是无止境的，Databricks在Spark Summit 2019公布了一个开源项目：koalas，这个项目的初衷是，很多数据工程师和数据科学家最开始在学校学习的是pandas（Python DataFrame），工作后仍使用pandas处理小批量数据，处理海量数据时则会选用Spark，虽然Spark DataFrame API和pandas比较类似，但还是有所不同，为了进一步降低这类人群的使用成本并统一API，Databricks推出了koalas项目，为数据工程师和数据科学家提供了与pandas一模一样的Spark API。

总体来说，Spark的这三个目标其实都是为了一个目标而服务：为了让数据科学家更富成效地进行工作。目前，Spark完美地完成了任务，对于Spark的未来，我们拭目以待！

我们从GitHub上的代码仓库可以看到，Spark下一个大版本将会是Spark 3.0而不是2.5，如图16-11所示。从JIRA官网上可以看到，目前和Spark 3.0有关的issue一共有242个。在这242个issue中，涉及Spark 3.0未来发展方向的史诗，只有一个SPARK-24579：标准化Spark和人工智能、深度学习框架，如TensorFlow、MXNet之间的数据交换过程，并优化其传输性能，该史诗的出发点在于目前大数据与人工智能的结合是很多业务与应用成功的关键，而这两个领域的顶级开源社区也多次尝试整合，但由于Spark SQL、DataFrame、Structured Streaming的日趋成熟，Spark仍然是大数据社区的首选，因此人工智能框架如何与Spark进行集成是整合的关键，当然，目前已经存在一些解决方案如TensorFlowOnSpark、TensorFrames等，但是并没有一种标准化传输方案，所以性能优化只能根据具体情况来实现，例如TensorFlowOnSpark使用Hadoop的InputFormat/OutputFormat格式来加载和保存TensorFlow的TFRecords，并用RDD将数据传输给TensorFlow。SPARK-24579所探讨的正是如何降低整个过程的复杂性：标准化Spark和人工智能、深度学习框架之间的数据交换接口。这样，人工智能、深度学习框架可以利用Spark从任何地方加载数据，而无须花费额外的精力来构建复杂的数据解决方案，例如从数据仓库或流模型推断中读取某个特征。Spark用户可以使用人工智能、深度学习框架，而无须学习特定的数据API，并且双方的开发人员可以独立地进行性能优化，因为接口本身不会带来很大的开销。SPARK-24579只是Spark在人工智能领域的一个开始，这也和2018年的Spark Summit首次改名为Spark + AI Summit相契合，预示着Spark将在人工智能领域发力。Spark 3.0到底会加入哪些令人激动的特性，会朝着哪个方向发展，我们拭目以待。

图16-11　原本的2.5的编号被修改为3.0

本文摘自《Spark海量数据处理 技术详解与平台实战》

• 基于Spark新版本编写，包含大量的实例
• 用一个完整项目贯穿整个学习过程的实用Spark学习指南
• 层次分明、循序渐进，带你轻松玩转Spark大数据

本书基于Spark发行版2.4.4写作而成，包含大量的实例与一个完整项目，层次分明，循序渐进。全书分为3部分，涵盖了技术理论与实战，读者可以从实战中巩固学习到的知识。第一部分主要围绕BDAS（伯克利数据分析栈），不仅介绍了如何开发Spark应用的基础内容，还介绍了Structured Streaming、Spark机器学习、Spark图挖掘、Spark深度学习等高级主题，此外还介绍了Alluxio系统。第二部分实现了一个企业背景调查系统，比较新颖的是，该系统借鉴了数据湖与Lambda架构的思想，涵盖了批处理、流处理应用开发，并加入了一些开源组件来满足需求，既是对本书第一部分很好的巩固，又完整呈现了一个实时大数据应用的开发过程。第三部分是对全书的总结和展望。 

本书适合准备学习Spark的开发人员和数据分析师，以及准备将Spark应用到实际项目中的开发人员和管理人员阅读，也适合计算机相关专业的高年级本科生和研究生学习和参考，对于具有一定的Spark使用经验并想进一步提升的数据科学从业者也是很好的参考资料。