工业大数据分析实践：基于CRISP-DM方法论的再认识

本文将基于CRISP-DM（Cross-Industry Standard Process for Data Mining）方法论，阐述工业大数据场景下的挑战及做法，以期对工业大数据实践提供一点参考。上篇参见：工业大数据分析实践：基于CRISP-DM方法论的再认识（上篇）

CRISP-DM方法论

CRISP-DM是一种广泛采用的数据挖掘分析方法论（其他方法论请参阅文献1），由SPSS、Teradata等公司起草于1999年发布第一版。该方法将一个数据分析项目分为业务理解（Business Understanding）、数据理解（Data Understanding）、数据准备(Data Preparation)、建模(Modeling)、验证(Evaluation)、部署(Deployment)等6个阶段(如下图所示)的迭代过程（更多细节可以参阅文献2）

1

业务理解阶段（Business Understanding）

在CRISP-DM方法论中，这一阶段从业务的角度理解项目的目标和需求，并将其转为一个可解的数据分析问题，可采用业务流程建模、决策建模等方法，分解业务目标，分析业务用例（use case），厘清关键因素，确定分析问题的范围(scope)。

工业数据分析常常是一个知识严重二分的情形。数据分析师对工业过程缺乏深入了解，而业界人员对数据分析的了解相对缺乏。可采用如下所述的三类形式化模型提高沟通协调效率。

系统上下文模型(System Context)

在关键要素分析上，工业分析问题的上下文（Context）模型很重要，包括生产、运作、环境、时空等多个方面上下文。只有这样，数字空间才可能部分反应物理空间。

在装备制造业，BOM（Bill of Material）是了解上下文的一个好的起点。例如，在风电装备制造业，需要了解风机工作机理、风电场业务运作机制、设备关键动作状态（比如偏航对风、解缆、降功率运行、保养、故障停机等）。只有这样数字可能形成对物理世界的一个相对完整的描述与刻画。

在流程行业，PFD（Process & Flowing Diagram）、PID（Piping & Instrument Diagram）这两类图很重要，可以帮我们了解相关化学/物理过程，以及前后环节的相互影响（比如，后面环节的反应速度会通过管道压力反过来影响前置工序的反应条件）。

系统动力学模型(System Dynamics)

现实中并非所有因素都有数据支撑或直接可以操控的。从可操控性和可观测性两个维度将Context model中因素进行刻画，如下表所示：

可操控性

可观测性

l 控制变量

l 外生变量（有影响，但无法直接控制）

l 状态变量（中间状态或结果量）

l 不可观测量

l 离线检测量

l 在线监测量

基于这样的分类，形成分析问题过程的因子动力学关系图，如下图所示（为突出分析目标，特别将目标量标出）。对于外生变量（特别是不可观测的）虽然我们无法直接优化，但至少清晰提醒了分析模型的适用前提。

业务用例（Use Case/Scenario）

工业分析问题定义的一个重要内容就是回答谁来用、什么时候用、如何用。系统用例就是这方面的一个好工具。在刻画业务用户、业务流程的基础上，分析业务对分析模型的核心需求，从而确定分析模型的度量指标。比如，在抽油机故障检测中，判断机器状态是否正常，若异常，给出故障类型。业务需求是降低一线监测人员的工作量，而不是简单的决策支持。精度达到99%的分析模型也没有多大用，无法指明哪1%是错误的，还是需要全时的人工审查，还不如一个模型可以完全准确的排除30%的样本，其余的70%留给人去判断，或提供初判结果，至少节省了30%的工作量。

这也就是数据分析中常谈的误报、漏报的问题，但和经典N分类问题（N种状态类型，包括正常状态和N-1类故障状态）存在一点微妙区别，现场运作允许分析模型输出(N+1)类状态（第N+1类是不确定状态），将前N类判别成N+1类的惩罚很小（可以留给人去处理），但前N类间的误判是不允许的（模型给出的结果一定是正确的）。

另外，业务用例的分解也可以帮助大家理性的思考业务问题，避免人为的“创造”技术挑战。很多原来看起来属于“故障预测“的业务需求，也许”故障的及时检测“就可以满足，但两者在技术难度上差别可能很大。

比如，对于风机发电机结冰问题，结冰预测需要小尺度的天气预报，若做到风机层面的预测还需要叶片表面光洁度等信息（否则，解释不了平原风场的3台相邻的风机，只有1台结冰，另外2台没有结冰的现象，这3台风机同型号同时期建设，地形和周边环境也几乎一样）。但做到结冰检测基于SCADA风机状态数据就可以做得比较准确。从业务用例分析来看，风场运维需要是：能在风机严重结冰前采取适当措施，避免高载荷下运行对风机造成损害。及时的结冰检测报警也可以满足业务需求。

分析问题的规约

数据分析是手段，而不是目的，把数据分析方法应用在一个恰当的位置解决一个有价值的实际问题才有意义。根据上面的分解，可初步把问题规约到四种类型问题，不同问题的应用前提和需要解决的挑战也略有不同。

本文重点讨论数据挖掘类（即狭义的数据分析范畴），也是CRISP-DM方法论的侧重点。

统计类和专家知识自动化的需求，主要是对工业大数据平台的要求（多类型数据的有机融合、以设备/工艺为中心的全维度数据查询引擎、非侵入式的数据分析并行化等），可参阅文献3，4。业务人员给出业务逻辑，通常不完备、不确定，需要利用大数据进行精细化，比如，“存在2Hz的主振动分量”的业务逻辑已经非常明确，但在变成可自动化执行的引擎前，要细化“2Hz”的范围区间、“主分量“（占总能量的15%之上？还是比第二高分量高5倍？）的定义。

大数据情形下的运筹优化和经典调度在技术挑战上没有本质区别，关键是如何定义一个合适的范围，很多业务因素缺乏数据支撑、很多业务逻辑用数学规划语言描述太复杂（可以用规则）、约束松弛逻辑复杂，实际中常采用“规则+数据规划”的方式去求解。大数据为运筹优化提供了更多的基础数据（比如，成本结构、天气信息、道路交通流量）和预测性信息（如需求预测）的支持，而这些和数据挖掘类问题是一致的。

类别

典型场景

主要关注点

统计分析类

目的：基于大数据形成相对可靠的认识。

应用场景包括：

l 基础数据的统计：风机经历EOG风的次数、工程机械工作强度画像

l 假设检验：风机结冰是否是由于温差变化引起的

l 根因分析：defect与哪些工艺参数密切相关。

分析的开发/迭代速度

- 如何充分利用已有的Python/R/Matlab等程序

- 大数据平台多维数据访问的便捷性

专家知识自动化

目标：业务人员有相对比较完备的业务逻辑描述，需要形式化、自动化。

主要应用场景：异常类型研判、报警的综合研判（消除虚假报警）

专家逻辑无歧义、完备性的保证，和逻辑（特别是复杂逻辑flow）精化

专家逻辑验证的迭代速度

数据挖掘类

这里姑且仅包括有监督学习的分类或回归问题（无监督和关联规则分析可以归结到统计分析类，更全面了解数据分布）

本文将在“建模”阶段详细讨论

最后，应该充分认识到数据分析的迭代性。在早期，对问场景、因素的认识很难完备，实际数据与假设是否相符有待验证。这些不确定性都留给后面的阶段，只有经过多次迭代才有可能形成相对完备的问题理解。

2

数据理解（Data Understanding）

数据理解的目标是确认当前数据是否支撑分析问题，主要任务包括数据质量审查、数据分布，形成数据的初步洞察和直觉判断力。下面就工业大数据分析中的四个特别之处进行讨论。

数据分析的根基：以认真负责的态度去审视数据质量

在工业领域，一种常见数据类型是传感器监测或检测数据，除了数值质量本身外，还要考虑传感器本身的可靠性和安装方式，分析传感器的R&R (Gage Repeatability and Reproducibility)。在风电领域，风机测风仪测的风速值是尾流风速，而不是轮毂风速，另外，测风仪的安装位置本身也可能存在偏差，也可能结冰。

在化工领域，气体产量不仅要关注其流量（体积），还要关注对应的气压和温度，否则可能会被“虚假表征”误导。

在工程机械车联网分析中，因为施工动态性（如传统油位传感器数据噪声太大）、施工环境（数据传输存在缺失）、人为破坏、部件更换、传感器及解析程序的升级换代等多种外部因素的共同作用，造成数据质量审查非常繁杂，有些存量数据的质量问题甚至无法解释（例如，月开工时长甚至超过744小时）。但这些艰苦基础性的数据治理工作必不可少，否则分析结果可信度很难保证。

在实践中，可以采用经典的统计方法去发现数值异常，然后不断深入理解哪些“异常”是系统的动力学特征（比如炉温是一个大惯、高时滞的过程）、哪些是控制逻辑行为（比如磨煤机出口温度的闭环控制）、哪些是测量系统问题、哪些是外部干扰等。只有把数据吃透，后面的算法模型才有好的基础。

你以为你以为的不是你以为的：透过业务场景还原，发现隐性质量问题

更为挑战的是，很多数据质量问题并非常规手段可以发现的，有的甚至连业务人员也没有意识到。在实战中，可利用数据去还原典型过程，发掘数据中表现出的“异常”场景，去完善业务上下文的理解。

例如，气化炉炉内温度软测量的一个前提假设是CH4浓度相对稳定，且与炉内温度密切相关。但实际数据探索中发现其中一台气化炉并不满足这样的假设（CH4浓度逐年上升，工艺对此的猜想是炉子内壁不断扩大造成的），而这样的现象过去谁也没有意识到。

运营和运作数据也有类似问题，比如，备件销量大不一定反映真正的市场需求，也可能是代理商囤货（冲业绩）。只有把影响数据质量的主要因素考虑全面，才可能做出有意义的分析。

数据量的困境：“大数据”量下的“小数据”信息

另外一个被经常追问的就是数据分析需要的数据量。工业分析问题即使做过独立性分析后，相关因子也通常成百上千，若严格按照全组合覆盖，需求量远远超过现实中可以采集的数量。

假设有20个变量，根据局部连续性假定，每个变量取4个数值就可以很好的拟合整个参数空间，全组合意味则需要条数据(约1千亿)，即使采集频率可达1000Hz，也需要近35年的历史数据。另外，工业过程通常一个运行在精心设计规律下的稳态过程（实际生产中并没有遍历整个参数空间），这也就意味着大数据中隐含的信息量其实是“很小”的。因此，关于数据量的问题，我们通常的回答：如果不融入领域认识去消减因子数量，通常你是无法提供“足够”的历史数据去覆盖所有组合情形。

数据的成本意识：数据分析师不要太任性

虽然总期望所有的重要因子数据都能被全量采集，但现实中数据采集是有成本的，同时也受制于当前的技术水平（比如，气化炉内温度是很重要的状态量，但目前的热电偶等传感器技术还无法长期可靠工作）和安全/环境考虑（比如，长输油气管道的压力传感器只能在阀室或场站部署）。

另外，在设备故障预警或检测分析中，故障数据是非常稀缺的，历史的运维数据通常也是不完整的。这些给数据分析带来了很大挑战，但同时也应认识到这就是现实（也许永远都不完美），我们的工作就是在现实的数据条件下进行的（根据数据基础，修改分析问题的提法，或通过其他信息补偿关键因子的缺失，或限定分析模型的适用范围等），而不是任性的一味要求数据。

3

数据准备（DataPreparation）

本阶段目标是建模分析所需的数据加工，包括原始数据抽取、多数据源融合、数据清洗与质量提升、特征提取。实际分析项目中，特征加工会占整个项目时间的40～60%。

针对一些特定领域问题，特征提取应充分利用已有的专业知识（不要浪费时间用数据分析手段挖掘出该领域早已熟知的规律）。以2009年国际PHM Data Challenge的齿轮箱故障模式研判题目为例，专业组冠军利用了旋转设备的典型故障模式（各种倍频）的领域知识，进行特征加工，再用数据挖掘算法，取得了很好的结果，模型的物理含义对现场实操人员也比较容易理解。近年来，深度学习的发展，在一些特定类型的问题上可以降低分析人员的特征提取工作量，但对关键特征变量的理解在工业分析仍必不可少。

4

建模（Modeling）

机器学习（或统计学习、数据挖掘）分析理论发展成熟，也有很多明确的指导原则和丰富的算法工具，因而，建模过程在实际分析项目中花的时间反而不多，因此这里不再赘述。为保证模型的可消费性（Consumability）而非技术上的自娱自乐，下面仅仅谈三点“形而上”的原则。

结果要有“新意“：避免挖掘常识（common sense），常识应当作为前处理或特征变量融入数据分析模型

模型应遵循“极简”原则：用最简单的算法去解决问题，不要为了微不足道的性能指标提升而使用看起来“高大上”的复杂模型。为此，就需要抓住问题的主要矛盾，到底是censored data问题、样本不均衡、模型的鲁棒性问题（应对个别极端异常数据）、过拟合（样本量相对模型参数空间不足）、模型的自适应性和提前性（比如针对宏观市场的变化，是否要求提前预估还是事后及时适应跟踪）、模型追求的指标（比如，回归问题追求是平均精度还是最差底线？分类问题对漏报、误报的侧重点）、模型的可解释性（对于根因分析，识别哪些因素在什么情形下重要对改进工艺更有实操性）。

模型的可控性和可解释性：任何模型都是在一定前提假设下对物理世界的简化，分析模型在建模时候不仅要关心平均性能，还应关心”worst-case”（最坏情形），最好能够清晰给出什么时候场景模型不适用（以及对应的处理措施）。对于性能提升，可以解释清楚其原因。

如前所述，数据分析是一个迭代过程。很多模型性能瓶颈并非来自于算法，而是来自于业务定义、数据理解、数据准备，例如一些很少发生但重要的业务/生产场景没有考虑到，一些重要因素甚至没有包含在当前数据集，一些严重的数据质量没有意识到。因为工业大数据分析技能的二分化，数据分析人员无法独立穷尽业务描述和数据集范围之外的情形，而业务专家也不可能思虑万全。

例如，在与一个国际客户合作地下管道失效风险评估项目中，根据业务专家和领域调研，我们拿到相对完备的数据集，第一期模型的总体性能还不错，但就在几个区域我们发现模型表现不好。

当把这些区域以GIS的形式可视化到业务专家面前，他们很快意识到一个重要因子的缺失（这些区域是围海造田，围海造田区的不均匀沉降比其他区域要大很多，这在当前数据集中没有体现），这些的信息对一个非本地人士/非专业人士来说几乎是不可能想象到的。

在建模过程中，不是泛泛谈模型的性能或数据质量，而是采用”worst-case”驱动的方式去和业务专家交流，告诉业务专家在什么情形下分析模型工作不好（给出具体的例子），触发业务专家的思考，借助专业外脑去发现问题的根因和解决手段。

5

评估（Evaluation）

建模阶段已经对分析模型从数据和技术的角度的进行充分检验。评估阶段再次从业务的角度审视模型的业务可用性(Actionable)，特别要定义清楚模型在什么情形下不适用，数据模型与业务流程的融合方式(Consumable)。

企业生产与管理是以工艺流程或业务流程为驱动的活动，经典信息化大多就流程（或改造后的流程）进行数据采集/整合和流转，以提升了业务效率；数据驱动的大数据方法尝试从数据产生/消费过程和多维度关联的新视角再次审视其中的蕴含的业务价值。但数据分析的结果若不能落到企业流程（现有的或新创建的），分析模型就游离在企业现有系统之外，很难实现价值落地。

对于采用已有的成熟模型，本阶段尤为重要。任何模型都有一定的适用前提，有些在对外宣传时候被忽略，有些前提在模型开发时没有意识到，因此，这些模型是否适用于当下场景需要大量的严谨的测试。

6

部署（Deployment）

部署的目的是保证模型的结果可被业务持久自动地消费(Consume)，除了大数据平台的计算性能问题，还应该注意分析模型的全生命周期管理。因为，在工业应用中，材料/工艺/装备/传感技术的不断更新。尽可能对部署模型进行密切的性能监控，通过闭环反馈进行模型成熟度评估和状态管理（试用、正式应用、需更新、退役等），保证生产的持续性和可靠性。

后记

本文以CRISP-DM方法论为基础，讨论工业大数据分析在不同阶段的挑战、需求与做法。CRISP-DM方法论是众多数据分析方法论的一种。任何数据分析方法论的要旨不外乎以下三点：1）定义一个好问题（有业务价值，技术可解，数据可支撑）；2）整理出值得信赖的数据；3）构建一个可被消费(consumable)的模型。一个认真负责、脚踏实地的工业数据分析师应尊重领域知识，了解数据的来源和业务意义，把握分析项目的主要矛盾，以“极简主义”的思路去建模，将分析技术与业务流程有机结合。

CRISP-DM方法论的六个阶段在不同问题中的重要度也不同。例如，有很多经典数据分析问题（如人脸识别、语音识别、文本分析）本身就很具体，这时主要的精力在数据预处理和算法精度上。

从宏观层面来讲，工业大数据和商业大数据在分析方法论上没有本质区别，只不过分析对象、数据特点、现有基础、应用期望等方面存在较大差异而已（详细阐述请参阅5）。再加上一些简洁的大数据思维（如从样本到全量思维；由精确到模糊思维；由因果到关联思维）、AI等宣传，若脱离了上下文和应用场景限定，很容易误导工业大数据的实践。

方法论为分析项目推进提供了很好的方向性指导，分析项目的成功更离不开数据分析师和业务人员的专业精神和务实态度，以及行业深入理解、相关的案例知识、丰富的实践经验、行业算法库以及合适的大数据分析平台支撑。

参考文献

1. CRISP-DM, still the top methodology foranalytics, data mining, or data science projects

2. Cross-industry standard process for datamining

作者简介

“

田春华博士：昆仑智汇数据科技（北京）有限公司首席数据科学家，2004年1月清华大学自动化系博士毕业。2004年-2015年在IBM中国研究院工作，负责数据挖掘算法研究和产品工作，分析应用成果在美国西南航空、中国香港水务署、韩国能源、和记黄埔等国际领先企业实施应用，发表学术论文（长文）82篇（其中第一作者42篇），拥有36项专利申请（10项已授权）。研究兴趣是数据挖掘算法与应用。

”