Hadoop 与Flink 应用场景研究*

白玉辛，刘晓燕

（昆明理工大学，云南 昆明 650500）

0 引言

大数据的时代已经悄然来临，信息技术发展上升到了一个新的历史阶段，影响着社会生产模式和人们生活的方方面面。我国高度重视大数据技术的研究和产业发展，把大数据技术研究纳入国家战略发展的重要项目，以期在“第三次信息化浪潮中”占得先机、引领市场。近年来，华为公司提出5G概念并将其投入生产实践，使得5G 网络逐步取代第四代移动通信网络，峰值理论传输速度可达10 Gb/s，比4G 网络的传输速度快数百倍。可见，大数据正在改变着人们的生活、工作和思想[1-2]。

2004 年Google 的3 篇 论 文MapReduce[3]、GFS[4]和BigTable[5]开启了针对大数据问题的关键技术研究。Cutting 等人根据论文的描述实现开源的MapReduce 计算框架，将其和NDFS 结合在一起，使其成为今天熟知的Hadoop，并在2008 年成为Apache软件基金会旗下的顶级项目，命名为Hadoop[6]。

2008 年，柏林理工大学开发了一套大数据处理平台，此为Flink 的前身。随后，在2014 年被Apache 孵化器所接受，然后迅速成为阿帕奇基金会（Apache Software Foundation，ASF）的顶级项目之一。Flink 是一个用于分布式数据处理的开源平台，可以用于Google 数据流模型[7]。它使用户能够编写可以分布在多个工作节点的程序，使得可以比单个计算机更快地处理大规模数据集。Flink 核心是一个流式的数据流执行引擎，提供抽象层的API，以便用户编写分布式任务。目前，互联网领域的实时搜索、数据平台整合、数据分析和机器学习任务等，都可以在Flink 平台上运行。

Flink 和MapReduce 相比较具有各种优点，但Flink 始终是一款大数据的计算框架，与Hadoop 中的MapReduce 具有类似的数据处理功能，都是拿来做数据处理的计算引擎。所以，在数据计算过程中Hadoop 的分布式文件系统HDFS 不可或缺。Hadoop一开始的设计思路是为了用户不用清楚详细了解分布式底层细节实现的情况下开发分布式应用程序，使用集群开发环境使运算性能最大化，同时利用分布式文件系统存储数据处理后的结果，实现了大规模的批处理，是一款真正意义上的大数据处理平台。Flink 支持数据流中的迭代，一个特例是Delta Iterations[8]。对于Delta 迭代的某些计算，并非每个迭代步骤都要更新每个数据项。他们在工作集和解决方案集上工作，工作集是推动迭代的动力。在每个步骤中，计算新的工作集并将其反馈到迭代中。Delta Iteration 在工作集为空或达到最大迭代次数时终止。两者有着不同的实际应用场景。

1 Hadoop 技术原理及其生态系统

1.1 Hadoop 技术原理

Hadoop 中的分布式文件系统（Hadoop Distribute File System，HDFS）较好地满足了大规模数据存储需求，通过网络实现文件在多台机器上的分布式存储。大数据时代需解决大规模数据的高效存储问题，还需要解决大规模数据的高效处理问题。Hadoop中的MapReduce 基于分布式并行编程框架，有利于提高程序性能，实现高效的批量数据处理。随着hadoop 生态系统其他组件的不断丰富，为了使hadoop 可以支持更多的应用场景，提供更高的可用性，资源管理调度框架YARN 脱颖而出。以上3 大模块共同组成了Hadoop 的基础架构。

1.1.1 HDFS

HDFS[9]是基于谷歌文件系统（Google File System，GFS）的开源实现，并与MapReduce 计算框架一起成为Hadoop 的核心组成部分。HDFS 采用“主-从”节点的理念，使用名称节点（namenode）负责文件和目录的创建、删除和重命名等，同时管理数据节点和文件块的映射关系；使用数据节点（datanode）负责数据的存储和读取。HDFS 兼容廉价的硬件设备，支持流数据读写，可以处理大规模数据集，遵从“一次写入、多次读取”的理念，同时支持跨平台。HDFS 的基本架构以及数据读写流程，如图1 所示。

1.1.2 MapReduce

大规模数据集的处理包括分布式存储和分布式计算两个核心环节。整个MapReduce 的思想可以用“分而治之”来概括。可以将一个大规模数据集切分为许多个Map 任务在多台机器上并行执行，每个Map 任务通常运行在数据存储的结点上。当Map 任务结束后，会生成k-v 键值对形式表示中间的结果，然后这些中间结果会被发送到Reduce 任务机器上进行汇总得到最后结果，最后输出到分布式文件系统。图2 是MapReduce 的整个流程。

1.1.3 YARN

为了克服Hadoop1.0 版本的缺陷，重新设计了Hadoop2.0 以后版本的体系结构，以MapReduce2.0 与另一种资源协调者（Yet Another Resource Negotiator，YARN）[10]全新模式进行数据处理。重新设计后的YARN 包 括ResourceManager、ApplicationMaster 和NodeManager。其中，ResourceManager 负责资源管理，由ApplicationMaster 负责任务调度和监控，由NodeManager 负责执行原TaskTracker 的任务。通过这种“放权”设计，大大降低了JobTracker 的负担，提升了系统运行的效率和稳定性。它的架构设计思路如图3 所示。

图1 HDFS 的架构以及数据读写流程

图2 MapReduce 的整个流程

图3 YARN 架构设计思路

1.2 Hadoop 生态系统

Hadoop 在不断完善自身核心组件性能的同时，生态系统也在不断丰富发展。为了应对大数据时代不同应用场景的数据处理，Hadoop 衍生出许多重要的子项目，共同构成了Hadoop 生态系统[11]，如表1 所示。

表1 Hadoop 生态系统

2 Flink 技术原理及其生态系统

2.1 Flink 技术原理

任何类型的数据都是作为事件流产生的。信用卡交易、传感器测量、机器日志、网站或移动应用程序上的用户交互，所有这些数据都以流的形式生成[12]。Apache Flink 正是为处理这些流而设计的。首先，Apache Flink 是一个框架，其分布式的计算模式使其成为一个可伸缩的开源流处理平台，用于无界数据集和有界数据集进行状态计算。核心模块是一个数据流引擎，主要通过Java 代码实现。对时间和状态的精确控制，使Flink 运行时无界流能运行任何类型的应用程序。有界流由专门固定大小的数据集设计的数据结构和算法进行内部处理，从而获得优异的性能。Flink 常被设计应用于集群环境中运行，以内存中的速度和任何规模执行计算，使得可以比单个计算机更快地处理大规模数据集。Flink 最近提出了本地闭环迭代操作符[13]和基于成本的自动优化器，能够重新排序操作符，并更好地支持流。

Apache Flink 功能强大，支持开发和运行多种不同种类的应用程序。它的主要特性包括批流一体化、精密的状态管理、事件时间支持以及精确一次的状态一致性保障等。Flink 不仅可以运行在包括YARN、Mesos、Kubernetes 在内的多种资源管理框架上，还支持在裸机集群上独立部署[14]。在启用高可用选项的情况下，它不存在单点失效问题。事实证明，Flink 已经可以扩展到数千核心，其状态可以达到TB 级别，且仍能保持高吞吐、低延迟的特性。世界各地有很多要求严苛的流处理应用运行在Flink 上。

Flink 提供3 层API。每个API 在简洁性和表达性之间提供不同的权衡，并针对不同的用例。如图4 所示，层级越高，代码越简洁，同时表达能力越弱，层级越低。

图4 Flink 的3 层API 及各接口内容

Process Functions 是Flink 提供的最具表现力的功能接口[15]。Flink 提供Process Function 来处理来自窗口中分组的一个或两个输入流或事件的单个事件。它提供对时间和状态的细粒度控制，还可以任意修改其状态并注册将在未来触发回调函数的定时器。因此，Process Functions 可以根据许多有状态事件驱动的应用程序的需要实现复杂的事件业务逻辑[16]。

数据流API 可用于Java 和Scala 和基于功能，如map()、reduce()和aggregate()，可以通过扩展接口或Java 或Scala lambda 函数来定义函数。Flink 具有两个关系API、Table API 和SQL。这两个API 都是用于批处理和流处理的统一API，即在无界的实时流或有界的记录流上以相同的语义执行查询，并产生相同的结果。Table API 和SQL 利用Apache Calcite 进行解析、验证和查询优化。它们可以与DataStream 和DataSet API 无缝集成，并支持用户定义的标量、聚合和表值函数。

该引擎同样可以在独立Hadoop YARN 或Apache Mesos 集群模式下运行，提供了具有不同抽象级别的API。最低级API 为有状态流处理提供构建块。核心数据集（批处理）和DataStream API 位于最常用的位置，且表和SQL API 位于其顶部[17]，提供其他库以直接支持各种特定上下文。核心API支持Java 和Scala，数据集API 还支持Python。可以使用驱动程序中的循环或通过Iterative Stream 或Iterative data集类实现迭代。前者在技术上不是迭代，而是驱动程序根据需要循环和扩展DAG，这是有限的可约性。在DAG 中，单个节点可以迭代地执行一组转换，使用最后计算的值或解决方案集状态可以在每次迭代中修改。Flink 还主要利用内存计算来最小化磁盘通信[17]。

为了实现稳健性，它在JVM 中实现了自己的内存管理，尝试通过溢出到磁盘来防止内存错误，减少垃圾回收压力等。系统不对键值对进行操作，但对于某些操作员（如分组）需要“虚拟”键。它处理任意数据类型，并通过简化键控（如基于元组索引或对象属性）为元组和对象提供额外支持。它的核心API 支持一组转换，这些转换与Apache Spark 的核心API 大致类似。

2.2 Flink 生态系统

社区正在努力支持catalog、schema registries 以及metadata stores，包括API 和SQL 客户端的支持，并且正在添加数据定义语言（Data Definition Language，DDL）支持，以便能方便地添加表和流到catalog中[18]。还有一个巨大的工作是集成Flink 与Hive 生态系统。Flink 和Hadoop、Spark 一样，是Apache软件基金会下的顶级项目，所以Flink 也有属于自己的生态系统，基本框架如图5 所示。

图5 Flink 生态系统

Flink 框架图从下到上有部署层、核心层、库和API 接口。其中，接口层提供CEP 复杂事件处理接口，主要是获取大量流数据中的重要信息。Flink和Sprak 一样，提供一个机器学习的库，里面包含许多数据挖掘的算法和机器学习的算法，支持向量机、回归问题、k-means 等一些常用算法。Gelly 库里面的函数用于解决大量图形计算。现在主流的大数据处理引擎都支持类SQL 语言，Table API 提供流处理及批处理中使用的SQL 语言，将SQL 嵌入Flink，满足用户从数据库中提取数据做分析。核心的两个接口是DataStream API 和DataSet API。在流处理场景中，使用DataStream API 接口对数据进行有状态的计算，最后输出到本地文件系统或者分布式文件系统HDFS。而DataSet API 接口应用于批处理场景中，将批数据作为流数据的极限特例进行数据分析。可以将Flink 部署到云，也可以使用单机模式。

3 Hadoop 与Flink 特性分析

3.1 Hadoop 技术优势

Hadoop 是一个能够对大量数据进行分布式处理的软件框架，且是以一种可靠、高效、可伸缩的方式进行处理的[19]。MapReduce 是与Flink 相对应的大数据编程框架，因此下面将主要阐述MapReduce的技术优势。

3.1.1 可读性

开发者将整个MapReduce 非常复杂的并行计算过程高度抽象成两个函数，一个是Map 函数，另一个是Reduce 函数。整个框架核的核心设计是这两个函数，所以极大地降低了分布式并行编程的难度[19]。

3.1.2 可扩展性

整个集群可以动态地随意增加或者减少相关的计算节点，不需要高端的机器，只需要普通廉价的PC 机即可。

3.1.3 高可靠性

采用典型的非共享式架构，使得在整个集群中每个节点都拥有自己的内存。任何一个节点出现问题，不会影响到其他节点正常运行。此外，整个集群设计了冗余和容错机制。

3.2 Hadoop 技术劣势

3.2.1 抽象层次低

实际开发过程中，许多的业务逻辑没有办法从更高层撰写相关的逻辑代码，需要去最底层人工进行编码。即使是完成一个非常简单的任务，都需要编写一个完整的MapReduce 代码，然后编译打包运行。

3.2.2 表达能力有限

现实中一些实际的问题没有办法用Map 和Reduce 两个函数完成相关任务。

3.2.3 执行迭代操作效率低

对于MapReduce 来说，它本身将整个作业划分成多个阶段进行，每一个阶段完成后将结果写入分布式文件系统HDFS，供下一个MapReduce 作业阶段调用。这样高代价的磁盘I/O，造成了执行迭代操作效率低[20]。

3.2.4 资源浪费

整个任务执行严格划分阶段（Map 阶段和Reduce 阶段），要求所有的Map 任务都处理完成后才能开始Reduce 任务阶段。这样Reduce 任务的结点一直处于空闲状态，导致资源的浪费。

3.2.5 实时性差

MapReduce 计算框架是针对批处理设计的，因此在实时交互查询应用中一般很难实现。

3.3 Flink 技术优势

Flink 以流数据处理为核心，借鉴MapReduce计算框架存在的诸多问题，设计弥补了MapReduce不能处理实时计算的局限，因此它的优势极为明显。

（1）Flink 擅长处理无界和有界数据集。精确控制时间和状态，使Flink 的运行能够在无界流上运行任何类型的应用程序[21]。有界流由算法和数据结构内部处理，这些算法和数据结构专为固定大小的数据集而设计，从而拥有出色的性能。

（2）Flink 最明显的优势在于充分利用内存中的性能，将任务状态始终保留在内存中，如果状态大小超过可用内存，则保存在访问高效的磁盘上的数据结构中。因此，任务通过访问本地（通常是内存中）状态来执行所有计算，从而产生非常低的处理延迟。Flink 通过定期和异步地将本地状态检查点持久存储来保证出现故障时一次性状态一致性[22]。

（3）Flink 旨在以任何规模运行有状态流应用程序。应用程序并行化为数千个在集群中分布和同时执行的任务，因此应用程序可以利用几乎无限量的CPU、主内存、磁盘和网络IO。Flink 很容易保持非常大的应用程序状态，其异步和增量检查点算法可确保对处理延迟的影响最小，同时保证一次性状态一致性。

（4）Flink 是一个分布式系统，需要计算资源才能执行应用程序。Flink 可与所有常见的集群资源管理器（如Hadoop YARN、Apache Mesos 和Kubernetes）集成，也可以设置为独立集群运行[23]。Flink 旨在很好地运作以前列出的每个资源管理器。这是通过特定于资源管理器的部署模式实现的，这些模式允许Flink 以其惯用方式与每个资源管理器进行交互。

3.4 Flink 技术劣势

虽然Flink 处理实时数据的性能要远优于MapReduce，但大数据时代下很多的处理数据场景是将过去几年或者过去几十年的数据从数据仓库中提取出来做批处理。如果这些数据量超过内存大小，Flink 将不再适用，这时使用MapReduce 做数据处理更合适。Flink 近几年才流行起来，目前尚不成熟，是一款大有前途的软件，因此目前的一些设计使得其在适用性方面存在一定的局限性。

4 Hadoop 与Flink 应用场景

4.1 Hadoop 应用场景

从MapReduce 的所有长处来看，它基本上是一个批处理系统，并不适合交互式分析，不可能执行一条查询并在几秒内或更短的时间内得到结果。典型情况下，执行查询需要几分钟或者更久。因此，MapReduce 更适合没有用户在现场等待查询结果的离线使用场景。然而，从最初的原型到现在，Hadoop 的发展已经超越了批处理本身。实际上，“Hadoop”一次有时被用于指代一个更大的、多个项目组成的生态系统，而不仅是HDFS 和MapReduce。这些项目都属于分布式计算和大规模数据处理范畴。这些项目中许多都是由Apache 软件基金会管理。该基金会为开源软件项目社区提供支持，所以大多数应用场景都是用Hadoop 中的分布式文件系统HDFS 或者分布式数据库HBase存储数据，用YARN 做集群资源调度框架，根据需求使用不同的计算框架处理数据。例如，针对大规模数据的批量计算，使用MapReduce、Spark等；针对流数据的实时计算，使用Storm、Flink、S4、Flume、Streams、Puma、DStream、Super、Mario 以及银河流数据处理平台等；针对大规模图结构数据的处理，使用Pregel、GraphX、Giraph、PowerGraph、Hama 以及GoldenOrb 等；大规模数据的存储管理和查询分析，使用Dremel、Hive、Cassandra 以及Impala 等。

Hadoop 设计之初以离线处理大批量的数据为主，通过10 年的发展，其生态系统技术不断完善，使得Hadoop 在大多数基于大规模离线数据处理场景中得到了广泛应用，主要包括ETL、日志分析、数据挖掘与机器学习等场景。

4.1.1 ETL

要想使MapReduce 处理得数据更加准确，首先得保证其处理的数据不是“脏数据”。大型企业使用数据仓库存放历史数据，在实际开发中这些原始数据不能达到存储规范，所以需要对存入数据仓库数据进行预处理，即数据的抽取、转换和装载（Extract-Transform-Load，ETL）[24]。当前主流的ETL 抽取方式是基于MapReduce 的并行ETL。由Bala[25]带头开发一套与传统ETL 工具相比性能更好的且基于MapReduce 并行计算框架的数据仓库ETL 平台；而Zhang[26]等人实现了ETL 处理Web页面也是基于MapReduce 框架；Li[27]率先将基于MapReduce 思想的ETL 应用在种子筛选的生活实际问题上，取得了不错的结果；Priya[28]的团队开发了基于MapReduce 的ETL 工具进行识别，成绩斐然。总而言之，MapReduce 在ETL 场景中优势明显。

4.1.2 日志分析

日志分析是大数据处理场景中的典型案例之一。2009 年谷歌计算机工程师通过分析海量的用户查询日志，对冬季流感的传播趋势进行了准确预测,其中MapReduce 起着决定性作用。Dewangan 的团队[29]利用MapReduce 编程模型对事物日志文件进行分析，证明了事物日志系统上应用MapReduce计算的优势。MaRAOS 是Chen 团队[30]开发的新框架，框架是Web 日志分析下的离线流数据的处理。Xhafa[31]利用MapReduce，通过对诸多类型日志的分析，揭示了Hadoop 处理海量日志数据的潜力。简而言之，日志分析是大数据分析不可或缺的部分，充分利用MapReduce 对离线日志进行有效的分析，为企业决策提供参考。

4.1.3 数据挖掘与机器学习

因为Hadoop 是针对大规模批量数据处理，所以在数据挖掘或者是统计机器学习的应用场景下占有一席之地。因为每次都要将中间结果写入本地磁盘，所以迭代效率低下。Hadoop 下的机器学习Mahout 组件在Spark 提出了其机器学习算法库MLIib 停止更新，所以机器学习的应用场景更多使用的是Spark中的MLlib 组件。Flink 中也有自己的机器学习组件FLinkML，所以数据挖掘与机器学习的场景不建议使用Mahout，建议使用Spark 中的MLib。

4.1.4 数据采集与处理场景

MapReduce 能够有效支持爬虫技术，包括增量爬虫的实现。所以，Cafarella 的团队[32]实现了MapReduce 主要算法对Nutch 提供计算支持，成为Nutch 的标准计算引擎。Li 团队[33]利用MapReduce框架进行网页评分的计算，得到用户偏好音乐的推荐；Zhang 等人[34]通过收集微博数据，在Nutch 框架下利用MapRedcue 分析微博站点的特色。可见，MapReduce适合应用于大规模数据采集的应用场景。

4.2 Flink 应用场景

Flink 因其丰富的功能集而成为开发和运行多种不同类型应用程序的绝佳选择。Flink 的功能包括支持流和批处理、复杂的状态管理、事件时处理语义以及状态的一次性一致性保证[35]。此外，Flink可以部署在各种资源提供者（如YARN、Apache Mesos 和Kubernetes）上，也可以作为裸机硬件上的独立群集。配置为高可用性，Flink 没有单点故障。Flink 已被证明可扩展到数千个核心和太字节的应用程序状态，提供高吞吐量和低延迟，并为世界上最苛刻的流处理应用程序提供支持。Flink 将数据产生当做流处理，擅长处理有界流和无界流。

4.2.1 流数据处理场景

Flink 将流数据[36]定义成无界流。无界流有一个开始但没有定义的结束。它们不会在生成时终止并提供数据。必须连续处理无界流，即必须在摄取事件后立即处理事件。无法等待所有输入数据到达，因为输入是无界的，且在任何时间点都不会完成。处理无界数据通常要求以特定顺序摄取事件，如事件发生的顺序，以便能够推断结果完整性。Flink 中的DataStream程序是实现数据流转换的常规程序（如过滤、更新状态、定义窗口以及聚合）[37]，最初从各种源（如消息队列、套接字流、文件）创建数据流，结果通过接收器返回，接收器可以将数据写入文件或标准输出（如命令行终端）。DataStream 程序可以在各种环境中运行，或独立运行或嵌入其他程序中[38]。执行可以在本地JVM 中执行，也可以在许多计算机的集群上执行。

4.2.2 批数据处理场景

Flink 将批数据[39]定义成有界流，具有定义的开始和结束。Flink 建立在DataSets（特定类型的元素集合，其上定义了隐式类型参数的操作）、作业图和Con-tracts（PACTs）。作业图表示具有任意任务的并行数据，消耗和产生数据流。PACT 是二阶函数，用于定义其相关用户定义（一阶）函数（User-Defined Function，UDF）的输入/输出数据的属性。这些属性进一步用于并行化UDF 的执行并应用优化规则[40]，可以在执行任何计算前通过摄取所有数据来处理有界流。处理有界流不需要有序摄取，因为可以始终对有界数据集进行排序。Flink中的DataSet 程序是实现数据集转换的常规程序，如过滤、映射、连接以及分组等。数据集最初是从某些来源创建的，如通过读取文件或从本地集合创建，结果通过接收器返回，接收器可以将数据写入（分布式）文件系统或标准输出（如命令行终端）。DataSet 程序可以在各种环境中运行，或独立运行或嵌入其他程序。执行可以在本地JVM 中执行，也可以在许多计算机的集群上执行。

4.2.3 数据挖掘与机器学习

Flink 在2014 年才成为Apache 基金会的顶级项目，社区正在为其开发适合自己的FLinkML 的机器学习组件。所以，FlinkML 相对于Hadoop 中的Mhout 组件和Spark 中MLlib 不是很成熟，在数据挖掘、机器学习场景中还是使用成熟的Spark MLlib或者Hadoop 的Mhout 组件。Flink 在Terasort 算法和KMeans 上表现良好，编码工作量最小，而在更复杂的MDS 算法上表现不佳[41]。大量的机器学习算法属于K-Means 和Terabyte 排序复杂度，并且可以在这些平台中有效实现它们。对于更复杂的算法，需要改进这些框架以支持算法要求。例如，Flink需要高效的通信算法扩展需要紧密同步和集体通信的复杂机器学习算法。目前，Flink 主要是做流处理和批处理[42]。

4.2.4 图计算

从大类来看，根据图是否有方向，可以将图分为有向图（Directed Graph）和无向图（Undirected Graph）[43]。Gelly 是Flink 的Graph API[44]，包 含一组方法和实用程序，旨在简化Flink 中图形分析应用程序的开发。在Gelly 中，可以使用与批处理API 提供的类似的高级函数转换和修改图形。Gelly 提供了创建、转换和修改图形的方法以及图形算法库[45]。

4.3 应用场景总结

针对以上应用场景对比分析，得出Hadoop 与Flink 并不能适应所有的应用场景。所以，表2 给出了Hadoop 与Flink 的适用场景总结。

表2 Hadoop 与Flink 场景适用性总结

5 结语

本文从Hadoop 与Flink 的技术原理及其生态系统出发，重点分析Flink 与MapReduce 各自适用的应用场景特性，通过对比分析两种不能完全适用所有的大数据处理应用场景。所以，面对大数据环境下日益增长的数据处理需求，实际应用场景中数据处理非常复杂。为了解决实际问题，需要将Hadoop与Flink 联合使用，这是当前大数据解决方案的发展趋势。