大型机组的高效稳定的运行与火力发电企业的经济收益与电力系统的安全运行有直接关系，它们的突然故障会给企业的经济效益带来巨大的负面影响，更有甚者会危及现场操作工人的生命安全。

为实时监测火力发电厂中各个热工设备的运行状态，对设备可能发生的异常状态进行预警，研究人员已经提出了大量基于不同机理的状态监测方法。

然而，随着数据收集技术的发展，所能得到的相关设备的历史运行数据也呈指数性的增长，这给现有状态监测方法提出了两方面的挑战。

其一是随着可利用数据量的增多，运行数据中所隐含的设备运行状态的不精确与不确定信息量增大，而现有方法无法同时描述这两类不完备信息。

其二是可用数据量的增大会增加计算机的计算负荷，导致由于算法复杂度过高所造成的计算内存溢出以及运行时间过长的问题。

针对上述两方面挑战，本论文借助先进的ApacheSpark并行计算框架，提出了适用于不同计算资源可支配情况的两套大数据证据驱动型状态监测模型建模方法。

两套方法均能够充分描述在大量历史运行数据中隐藏的运行状态的不精确与不确定信息，能够最大程度地利用所能支配的全部计算资源。

在锅炉水冷壁上的应用实例表明，本文所提出的方法能够在合理的运算时间内，快速准确地完成设备健康状态监测以及异常状态预警的任务，对火电机组安全运行具有重大的实际工程意义。

理论基础与计算框架

证据理论，又称为Dempster-Shafer理论，是由Dempster于1967年首先提出，随后被Shafer在各方面完善。

证据理论中研究对象的形式由传统的点值函数形式被扩展为集合函数，因而证据理论具有表达“不精确”和“不确定”信息的能力。

正是由于这种表达不完美信息的能力，证据理论已经在很多领域得到了广泛应用，如：专家系统，图像分类，集成学习，回归分析，聚类分析等。

MapReduce计算范式

MapReduce是一种编程模型和相关的实现方式，用于在集群上用并行的分布式算法处理和生成大数据集。

一个MapReduce程序由一个map程序和一个reduce方法组成，前者执行过滤和排序（如按名字将学生排序到队列中，每个名字一个队列），后者执行汇总操作（如计算每个队列中的学生数量，得出名字的频率）。

MapReduce系统（也称为”基础设施”或“框架”）通过集合分布式服务器来协调处理，并行运行各种任务，管理系统各部分之间的所有通信和数据传输，并提供冗余和容错。

MapReduce范式是数据分析“分割-应用-组合策略”的具体化。它受到函数式编程中常用的map和reduce函数的启发，尽管在MapReduce框架中这些函数的目的与原始形式不一样。

MapReduce范式的关键贡献不是实际的map和reduce函数（它类似于1995年提出的消息传递接口标准的reduce和scatter操作），而是通过优化执行引擎为各种应用实现的可扩展性和容错性。

因此，MapReduce的单线程实现通常不会比传统（非MapReduce）的实现快，也就是说，任何运算时间的收益通常只有在多处理器硬件上的多线程实现才能看到。

只有在MapReduce范式的优化分布式洗牌操作的降低网络通信成本和容错功能发挥作用时，使用这种范式才是有益的。优化通信成本对于一个好的MapReduce算法是至关重要的。

MapReduce范式用于使用大量计算机（节点）处理大型数据集上的可并行问题，这些计算机统称为集群（如果所有节点都在同一个本地网络上并使用类似的硬件）或网格（如果节点在地理上和行政上的分布式系统中共享，并使用更多异质的硬件）。

处理可以存储在文件系统（非结构化）或数据库（结构化）中的数据。MapReduce可以利用数据的位置性，在数据存储地附近进行处理，以减少通信开销。

一个MapReduce范式（或系统）通常由三个操作（或步骤）组成：Map：每个工作节点对本地数据应用map函数，并将输出写入临时存储。一个主节点确保只有一份冗余的输入数据被处理。

Shuffle：工作节点根据输出的key（由map函数产生）重新分配数据，这样，属于一个key的所有数据都位于同一个工作节点上。

Reduce：工作节点以并行方式处理每组输出数据。MapReduce允许分布式地处理map和reduction操作。

只要每个映射操作都是独立于其他操作的，那么映射就可以并行进行；在实践中，这受限于独立数据源的数量和/或每个数据源附近的CPU数量。

同样，一组"reducers"可以执行reduction阶段，前提是所有共享相同key的映射操作的输出都同时呈现给同一个reducer，或者reduce功能是关联的。

虽然与顺序性更强的算法相比，这个过程往往显得效率低下（因为必须运行多个reduce的实例），但MapReduce可以应用于明显大于单个"商品服务器"所能处理的数据集。

一个大型服务器群可以使用MapReduce在短短几个小时内对PB级的数据进行分类。并行性还为操作过程中服务器或存储的部分故障提供了一些恢复的可能性：如果一个mapper或reducer出现故障，工作可以重新安排（假设输入数据仍然可用）。

另一种看待MapReduce的方式是将其视为一个五步并行和分布式计算。准备map输出：MapReduce系统指定了Map处理器，指定了每个处理器要处理的输入key1，并向该处理器提供与该key相关的所有输入数据。

运行用户提供的map代码：map对每个key1精确运行一次，生成按key2组织的输出。对map输出和Reduce处理器洗牌：MapReduce系统指定Reduce处理器，为每个处理器分配key2键，并向该处理器提供与该键相关的所有map生成的数据。

运行用户提供的Reduce代码：对于map步骤产生的每个key2键，Reduce正好运行一次;生成最终的输出：MapReduce系统收集所有的Reduce输出，并按key2排序，产生最终结果。

这五个步骤在逻辑上可以认为是依次运行的，即，每个步骤只有在前一个步骤完成后才开始，尽管在实践中，只要不影响最终结果它们可以交错进行。

在许多情况下，输入数据可能已经分布在许多不同的服务器中，此时可以通过分配地图服务器来处理本地的输入数据，从而大大简化步骤1。

同样地，步骤3有时也可以通过指定尽可能接近他们需要处理的map生成的数据的reduce处理器来加速。

ApacheSpark计算框架

ApacheSpark最初由加州伯克利大学的Algorithm，Machines，People（AMP）实验室在2009年开发，以应对MapReduce集群计算范式中对分布式程序强制采用特定的线性数据流结构的局限性。

Spark的架构基础是弹性分布式数据集（RDD），这是一个分布在机器集群上的只读多数据集，并以容错的方式维护。

在Spark1.x中，RDD是主要的应用编程接口（API），但从Spark2.x开始，尽管RDD的API没有被废弃，但已经开始鼓励使用DatasetAPI。

在Spark程序运行时，Map与Reduce程序从磁盘上读取输入数据，然后在数据上映射一个函数来还原映射的结果，并将还原结果存储在磁盘上。

Spark的RDDs作为分布式程序的工作集，提供了一种受限制的分布式共享内存形式。在Spark内部，工作流被管理为一个有向无环图，其中的节点（nodes）代表RDDs，而边（edges）代表RDDs上的操作。

对RDDs的操作可以分为两类，行动（action）与转换（Transformation）。前者执行计算并指定RDD的输出形式，后者指定RDD直接的互相依赖关系。

转化操作包括：map，filter，groupBy，join等，它接受的输入为RDD形式并输出RDD；而行动操作包括：count，collect等，它接受RDD输入但返回的是一个非RDD形式的值或者结果。

转换操作所提供的接口非常简单，例如map，filter，groupby以及此，对数据集元素中的相同的批量操作更适合在Spark中完成，而那些异步的，细粒度操作则不适用于Spark中，如网络爬虫等应用。

已经被证明的是，Spark有利于实现迭代算法（循环多次访问其数据集）和交互式/探索式数据分析，即重复数据库式数据查询。

与ApacheHadoop实现相比，这类迭代算法的应用延迟可能会减少几个数量级。在迭代算法中，机器学习系统的训练算法是其中之一，这也是开发ApacheSpark的最初动力。

Spark还需要一个集群管理器和一个分布式存储系统。对于集群管理，Spark支持独立的（本机Spark集群，使用者可以手动启动一个集群，或者使用安装包提供的启动脚本。

也可以在一台机器上运行这些守护程序进行测试）、HadoopYARN、ApacheMesos或Kubernetes。对于分布式存储，Spark可以与多种多样的接口。

包括Alluxio、Hadoop分布式文件系统（HDFS）、MapR文件系统（MapR-FS）、Cassandra、OpenStackSwift、AmazonS3、Kudu、Lustre文件系统，或者可以实现一个自定义解决方案。

Spark还支持伪分布式本地模式，通常只用于开发或测试目的，在这种模式下不需要分布式存储，可以使用本地文件系统代替；在这种情况下，Spark在单机上运行，每个CPU核有一个执行器。

SparkSQL:SparkSQL是SparkCore之上的一个组件，它引入了一个名为DataFrames的数据抽象，从而为结构化和半结构化数据提供支持。

SparkSQL提供了一种特定领域的语言（DSL），可以在Scala、Java、Python或.NET中操作DataFrames。它还提供了SQL语言支持，有命令行接口和ODBC/JDBC服务器。

尽管DataFrames缺乏RDDs所提供的编译时类型检查，但从Spark2.0开始，SparkSQL也完全支持强类型的DataSet。

SparkStreaming：SparkStreaming使用SparkCore的快速调度能力来执行流分析。它以小批量的方式摄入数据，并对这些小批量的数据进行RDD转换。

这种设计使得为批处理分析编写的同一套应用程序代码可以用于流式分析，从而便于实现lambda架构。然而，这种便利伴随着相当于小批处理时间的延迟惩罚。

MLlib：SparkMLlib是建立在SparkCore之上的分布式机器学习框架，在很大程度上是由于基于分布式内存的Spark架构。

其速度是ApacheMahout使用的基于磁盘的实现的9倍之多（根据MLlib开发者对交替最小二乘法（ALS）实现的基准测试，在Mahout本身获得Spark接口之前），并且比VowpalWabbit的扩展性更好。

GraphX：GraphX是建立在ApacheSpark之上的分布式图形处理框架。因为它是基于RDDs的，而RDDs是不可变的，所以GraphX不适合需要更新的图，更不用说像图数据库那样以事务性的方式进行更新。

GraphX为实现大规模并行算法（如PageRank）提供了两个独立的API：一个是Pregel抽象，另一个是更通用的MapReduce风格的API。

与ApacheSpark一样，GraphX最初是作为加州大学伯克利分校AMPLab和Databricks的一个研究项目，后来被捐赠给Apache软件基金会和Spark项目。

小结

对本文所使用的证据理论中的基本概念与相关计算以及所使用的Spark并行计算框架进行了介绍。为本后续中的分布式证据聚类算法，分布式EKNN算法，分布式证据样本选择算法以及稀疏重构EKNN算法的提出，以及相应算法在设备状态监测模型的建立打下了理论基础。