前言近年来，随着5G时代的到来，物联网和云计算的快速发展，人类社会逐渐进入大数据时代。所谓大数据，是指涉及的数据量巨大，无法在合理时间内截取、管理、处理和整理成人类可以解读的信息。大数据在带来发展机遇的同时，也带来了新的挑战，催生了新技术的发展和旧技术的革新。例如，不断增长的数据规模和动态快速生成的数据，需要使用分布式计算框架来实现匹配的吞吐量和实时性。1大数据计算的基本概念1.1离线计算大数据离线计算技术应用于静态数据的离线计算和处理。框架设计的初衷是为了解决大规模、非实时的数据计算，更注重整个计算框架的吞吐量。离线计算的数据量大，计算周期长，在大量数据的基础上进行复杂的批量计算。离线计算的数据将不再变化。通常离线计算的任务是有调度的，使用场景一般对时效性要求比较低。1.2实时流计算实时流计算，或者实时计算和流计算，在大数据领域是类似的概念。那么，什么是实时流计算呢？Google大神TylerAkidau在文章《the-world-beyond-batch-streaming-101》中提到了实时流计算的三个特点：无限数据、无限制数据处理、低延迟：无限数据：指的是一个不断增长的、本质上是无限的数据集，这些通常被称为“流数据”，而不是有限数据集。无界数据处理：是一种连续的数据处理方式，可以通过处理引擎对以上无限数据进行重复处理，可以突破有限数据处理引擎的瓶颈。低延迟：延迟是指数据进入系统和流出系统所花费的时间。实时流计算业务对时延要求很高。延迟越低，越能保证数据的实时性和有效性。2.离线计算框架：大数据之家2.1MapReduce计算框架Hadoop是由Apache基金会开发的分布式系统架构。其核心主要包括两个组件：HDFS和MapReduce。前者为海量存储提供存储，后者为海量数据提供计算。这里我们主要关注MapReduce。以下信息来自于Hadoop的官方文档和论文。MapReduce是一个易于使用的软件框架。基于它编写的应用程序可以运行在由数千台商用机器组成的大型集群上，并以可靠和容错的方式并行处理T级数据集。计算过程分为Map和Reduce两个阶段。Map阶段并行处理输入数据，Reduce阶段汇总Map结果。MapReduce作业通常将输入数据集分成若干个独立的数据块，Map任务以完全并行的方式处理它们。该框架首先对Map的输出进行排序，然后将结果输入到Reduce任务。通常作业的输入输出都会保存在文件系统中。整个框架负责调度和监控任务，并重新执行失败的任务。通常，MapReduce框架和分布式文件系统运行在同一组节点上，即计算节点和存储节点通常在一起。这样的配置可以让框架高效的在已经存储数据的节点上调度任务，可以让整个集群的网络带宽得到非常高效的利用。MapReduce框架由每个集群节点的一个主JobTracker和一个从属TaskTracker组成。master负责调度构成作业的所有任务。这些任务分布在不同的slaves上。master监控它们的执行并重新执行失败的任务。slave只负责执行master分配的任务。应用程序至少应指定输入/输出路径，并通过实现适当的接口或抽象类来提供map和reduce功能。它与其他作业的参数一起构成了作业配置。然后，Hadoop的JobClient将作业和配置信息提交给JobTracker，JobTracker负责将这些软件和配置信息分发给slave，调度任务并监控它们的执行，并向JobClient提供状态和诊断信息。MapReduce框架运行时，应用程序通常通过提供map和reduce来实现Mapper和Reducer接口，它们构成了作业的核心。map函数接受一个键值对并生成一组中间键值对。MapReduce框架会将map函数生成的中间key-value对中具有相同key的值传递给reduce函数。reduce函数接受一个键和一组相关联的值，并组合这组值以产生更小的值集。如图1所示，在MapReduce工作流中，一切都是从最上层的用户程序开始的。用户程序链接MapReduce库，实现最基本的Map功能和Reduce功能。图中的执行顺序用数字标出。图1MapReduce执行流程2.2Spark计算框架Spark基于MapReduce算法的离线计算具有HadoopMapReduce的优点；但是与MapReduce不同的是，Job的中间输出结果可以保存在内存中，所以不需要读写HDFS，所以Spark更适合数据挖掘和机器学习等需要迭代的MapReduce算法。Spark中的一个主要结构是RDD（ResilientDistributedDatasets），它是一个只读的数据分区，丢失后可以重建。它使用Lineage的概念来实现容错。如果一个RDD丢失，有足够的信息支持RDD重建。RDD可以被认为是提供高度受限的共享内存，但这些限制使自动容错变得非常便宜。RDD使用了Lineage的容错机制，即每一个RDD都包含了它是如何从其他RDD转化过来的，以及如何重构某一块数据的信息。RDD只支持粗粒度的转换，即只记录对单个块执行的单个操作，然后创建并存储一个RDD的转换序列。当数据丢失时，我们可以使用转换序列重新计算并恢复丢失的数据。以达到容错的目的。Spark中的应用程序称为驱动程序，这些驱动程序实现在单个节点上或在一组节点上并行执行的操作。驱动程序可以对数据集执行两种类型的操作：操作和转换。动作对数据集执行计算并返回一个值给驱动程序；转换从现有数据集创建新数据集。操作示例包括执行Reduce操作和迭代数据集。转换的示例包括映射操作和缓存操作。与Hadoop类似，Spark支持单节点集群或多节点集群。对于多节点操作，Spark依赖于Mesos集群管理器。Mesos为分布式应用程序的资源共享和隔离提供了一个有效的平台，参见图2。图2Spark依赖于Mesos集群管理器2.3Dryad计算框架Dryad是构建微软云计算基础设施的核心技术。编程模型比MapReduce更通用——使用有向无环图（DAG）来描述任务的执行，其中用户指定的程序是DAG图的节点，数据传输通道是边，可以是通过文件、共享内存或传输控制协议（TCP）通道传输数据，该任务相当于图的生成器，可以合成任何图，甚至这些图在执行过程中可以响应事件发生变化发生在计算过程中。图3展示了整个任务的处理流程。Dryad在容错方面有很好的支持，底层数据存储支持数据备份；在任务调度方面，Dryad具有更广泛的适用性，不仅适用于云计算，在多核、多处理器和异构集群上也有不错的表现；在可扩展性方面，它可以扩展到各种规模的集群计算平台，从单机多核计算机到多台计算机组成的集群，甚至是拥有数千台计算机的数据中心。在Dryad的帮助下，微软在大数据处理方面也形成了完整的软件栈，部署了分布式存储系统Cosmos，并提供了DryadLINQ编程语言，让普通程序员可以轻松进行大规模分布式计算。图3Dyrad计算框架的任务处理流程3、实时流计算框架：如果未来大数据遇到更多时间敏感的业务需求，我们需要使用哪些实时计算引擎？目前有很多专业的实时流计算框架，比较知名的有ApacheStorm、SparkStreaming、LinkInSamza、ApacheFlink和GoogleMillWheel等，但最主流的无疑是Storm、SparkStreaming、Flink和萨姆扎。3.1StormComputingFrameworkHadoop提供了Map和Reduce原语，使得批处理数据变得非常简单和优雅。同样，Storm也提供了简单的Spout和Bolt原语，用于数据的实时计算。从表面上看，Storm集群与Hadoop集群非常相似，但MapReduce作业运行在Hadoop上，而拓扑运行在Storm上。他们非常不同。例如，MapReduce作业最终会结束，而StormTopology将永远运行。Storm的集群架构如图4所示。图4Storm的集群架构在应用Storm的过程中，会遇到Topology、Tuple、Spout、Bolt、stream和streamgrouping等概念。其中，Topology是实时应用，Tuple是处理的基本消息单元，Spout是Topology流的源头，是Topology中生成源数据流的组件。Topology中所有的处理逻辑都在Bolt中完成。流由无数的元组序列组成。这些元组是并行和分布式创建和执行的。Stream分组用于定义Stream应如何将数据分发给Bolt上的多个任务。早期的Storm无法提供exactlyonce语义支持，后来Storm引入了Trident高级原语来提供exactlyonce语义支持。然后提出了流计算中的背压概念，指的是Storm中的拓扑处理数据的速度超过数据流入速度时的处理机制。一般来说，当背压发生时，数据会快速积累。如果处理不当，会导致资源耗尽甚至任务崩溃。这在流处理中很常见，通常是由于源数据量突然急剧增加造成的，比如电商促销、节日等。新的Storm自动反压机制是通过监听Bolt中的接收队列来实现的。当超过高水位线时，会有专门的线程将背压信息写入ZooKeeper，ZooKeeper上的Watch会通知拓扑中的所有Worker进入背压状态，最后Spout降低Tuple的发送速度。3.2SparkStreaming计算框架SparkStreaming是Spark核心API的扩展，用于处理实时数据流。SparkStreaming处理的数据源可以是Kafka、Flume、Twitter、HDFS或Kinesis。这些数据可以使用map、reduce、join、window方法进行转换，也可以直接使用Spark内置的机器学习算法和图算法包进行处理。数据。最终处理后的数据可以存储在HDFS，Database或Dashboard，数据库中。与Storm原生的实时处理框架相比，SparkStreaming是基于微批处理的。微批处理是一种组织独立数据操作的方法。术语中的微，更具体地说，是指内存中的处理。术语中的批处理是指SparkStreaming中数据处理的单位是批而不是一个。Spark会在收集到的源数据累计到设定的区间条件后，对数据进行统一的批处理。这个区间是SparkStreaming中的核心概念和关键参数，它直接决定了SparkStreaming作业的数据处理延迟，当然也决定了数据处理的吞吐量和性能。SparkStreaming提供了一个抽象概念DStream，代表连续的数据流。在SparkStreaming中，DStream实际上是由一系列连续的RDD组成的。每个RDD包含一定时间间隔内的数据，这些离散的RDD连接在一起形成对应的DStream。SparkStreaming的架构如下图5所示。图5SparkStreaming架构3.3Flink计算框架Storm低延迟低吞吐，SparkStreaming高吞吐高延迟。有没有兼具低延迟和高吞吐量的流计算技术？答案是肯定的，就是Flink。事实上，Flink在2008年作为柏林工业大学的研究项目诞生，直到2015年之后才逐渐被认可和接受。这和它自身的技术特点契合了大数据对低实时延迟的要求，高吞吐量、容错性、可靠性、灵活的窗口操作、状态管理等显着特性是分不开的，当然也离不开对实时数据的日益重视。阿里巴巴启动了Blink项目，旨在对Flink进行扩展、优化和完善，使其能够应用于阿里巴巴的大规模实时计算场景。Flink的整体结构如下图6所示。部署：Flink支持运行在本地（直接在IDE中运行程序），运行在独立的集群（Standalone模式）或运行在YARN、Mesos、K8s管理的集群上，也可以部署在云端。Kernel：Flink的核心是一个分布式的流式数据引擎，也就是一个事件一个事件地处理数据。API：包含DataStream、DataSet、Table、SQL等API。库：Flink还包括CEP（复杂事件处理）、机器学习和图处理的场景。图6Flink整体结构Flink容错机制的核心是分布式数据流和状态的快照。为了确保在发生故障时从错误中恢复，需要数据对齐。Flink使用了单机性能优异的RocksDB作为状态的后端存储，但是单机是不可靠的，所以Flink也会将单机的状态同步到HDFS来保证状态的可靠性。此外，对于RocksDB到HDFS的checkpoint同步，Flink也支持增量方式，可以大大提高checkpoint的效率。Flink相对于其他流计算技术的一个重要特点是支持基于EventTime的窗口操作。但是，事件时间来自源系统。网络延迟、分布式处理、源系统等多种原因可能导致源数据的事件时间发生乱序，即晚发生的事件比早发生的事件早，或者某个事件会被晚的。Flink参考了Google的CloudDataflow，引入了watermarks的概念来解决和度量这种乱序问题。并且在一些实时计算的场景下，需要撤回之前的计算结果，Flink提供了撤回机制。Storm通过监控进程螺栓中的接收队列负载来处理背压。如果超过高水位，会将背压信息写入ZooKeeper，ZooKeeper上的watch会通知该拓扑的所有worker进入背压状态，最后spout停止发送tuples进行处理。SparkStreaming可以通过设置属性“spark.streaming.backpressure.enabled”自动进行背压处理，动态控制数据接收速率以适应集群数据处理能力。对于Flink来说，无需特殊设置，其纯数据流引擎可以非常优雅地处理背压。3.4Samza计算框架Samza是Linkedin开源的分布式流处理框架。其架构如图8所示，Kafka提供底层数据流，YARN提供资源管理、任务分配等功能。图7也展示了Samza的作业处理流程，即Samza客户端负责将任务提交给YARN的资源管理器，由YARN分配相应的资源完成任务的执行。每个容器中运行的流式任务是相对于Kafka的消息订阅者，负责拉取消息并执行相应的逻辑。在扩展性方面，Kafka底层通过Zookeeper实现动态集群水平扩展，可以提供高吞吐量和水平扩展的消息队列。YARN为Samza提供了分布式环境和执行容器，因此也易于扩展；在容错方面，如果服务器出现故障，Samza和YARN会一起进行任务迁移、重启和重新执行，YARN还可以提供任务调度、执行状态监控等功能；在数据可靠性方面，Samza遵循Kafka中的信息分区进行处理，保证分区内消息有序，分区间并发执行。Kafka将消息持久化到硬盘，保证数据安全。此外，Samza还提供了对流数据状态管理的支持。在需要记录历史数据的场景下，实时的数据流动使得状态管理难以实现。为此，Samza提供了一个内置的键值数据库来存储历史数据。图7Samza整体架构4.总结大数据计算框架的应用促进了技术的发展和创新。目前，业界不断提高大数据计算框架的吞吐量、实时性、可扩展性等特性，以应对不断增长的数据大数据计算框架仍然是现在和未来的研究热点。未来的发展趋势是：随着商业智能、计算广告等领域的发展，强调实时性的流计算框架将受到更广泛的关注。总之，应用的推广和技术的进步都会产生新的问题。作为大数据应用的核心，在挖掘数据价值中发挥着重要作用的计算框架将面临更多亟待解决的挑战。本文参考了一些文献和网络资源，感谢他们的观点和技术对本文的贡献。参考文献[1]李川，鄂海红，宋美娜．基于Storm的实时计算框架研究与应用[J]．软件,2014,35(10):16-20.[2]https://izualzhy.cn/dataflow-reading[3]https://juejin.im/post/5d49830cf265da03f3333b4c#heading-11[4]田文宏，赵勇，云资源优化管理与调度[M]，2015[5]https://greensy.github.io/2014/06/15/批量计算/
