| 编辑推荐: |
本文将基于CRISP-DM（Cross-Industry Standard Process
for Data Mining）方法论，阐述工业大数据场景下的挑战及做法，以期对工业大数据实践提供一点参考。希望对您的学习有所帮助。
本文来自于微信公众号昆仑数据K2Data，由Linda编辑、推荐。 |
|
前由
在与工业界交流中，多次被问到工业大数据的实践方法论。就我个人而言，不喜欢过多谈论方法论（行业洞察/实践经验/内容积累/问题理解比方法更重要），更不愿意再提出一种新的方法论。在与王建民、郭朝晖等专家的交流中深受触动，必要的流程梳理对协调大家的认识和行动还是很重要，虽然没有必要再“创造”一套全新的方法论。因此，本文将基于CRISP-DM（Cross-Industry
Standard Process for Data Mining）方法论，阐述工业大数据场景下的挑战及做法，以期对工业大数据实践提供一点参考。
在CRISP-DM和传统商业数据分析中，分析题目假设是事先给定的，作为业务理解阶段的前置输入，即分析题目通常由业务分析师（Business
Analyst）或业务部门定义提供给数据分析师(Data Analyst)。但在工业实践中，通常很难实现这样清晰的分工。在讨论CRISP-DM之前，先总结一下工业企业对大数据的一些常见问题，基于这些问题，探讨大数据分析课题识别问题，然后再讨论CRISP-DM的6个阶段中工业大数据领域的挑战、需求与做法。
工业大数据分析答疑
随着数据采集能力和计算能力的发展，数据技术在企业经营/生产业务转型和提升中发挥着重要作用。大数据分析作为数据价值变现的核心技术手段之一，其作用得到充分认可。但很多简洁（或不带前提的）的宣传也给业界带来了一些误解。
大数据在商业领域已经有了不少很好的应用。工业作为一个重设计和机理的领域，大数据如何应用，大家还有不少疑问。这里列举了一些常见的问题和简要解析，后面将详细讨论。
Q
需要多少数据才能做大数据分析？
A
数据量的客观需求量：数据与问题的匹配（度量指标、关键因素完备性、数据质量、正/负样本平衡性、先经知识等）
业务人员对数据基础有个理专业的认识：数据量大不意味着信息量大
数据分析师要认真务实：认识核实数据，但不要一味要求数据量
Q
大数据分析如何推进？
A
规划：业务价值驱动+数据基础支撑
执行：业务专家与数据分析的协同
Q
大数据分析是不是不需要业务和领域知识？
A
工业大数据更需要领域知识
了解数据从哪儿来？如何采的？什么时候可信？
领域知识去细化解空间，降低对数据量的要求
领域经验指导特征提取，提高算法的求解效率，提高模型的可解释性
更全面客观评估模型的适用范围
Q
什么样的模型是一个好模型
A
可被业务用户消费(consumable)
极简原则：在保证性能满足的前提下，算法越简单越好
可控性：明确给出什么时候模型不适用
Q
为什么很多“开箱即用”算法没有宣传得那么好用
A
在分析实战中的重要度排序：定义一个好问题>整理完备可靠的数据>加工好的特征变量>算法
任何算法都有一定适用前提（了解什么时候模型不适用比笼统的性能指标有时候还重要），需要严格的测试验证
Q
工业大数据分析需要什么样的大数据平台
A
开发阶段：
1）提供全维度数据关联查询（时序数据、业务数据、非结构化数据等）；
2）支持快速迭代（支撑R/Python/Matlab等工业界常用工具，支持已有单机分析程序的重用）
部署阶段：
业务闭环，对分析模型进行全生命周期管理
分析题目的识别与规划
分析题目识别的前提是对行业和企业的基本面有一个全面把握，充分利用行业已有的参考模型（比如质量管理中可以参阅PDCA、6-sigma等已有的参考模型）。下面从工业大数据分析能做什么和如何进行优先级排序两个方面进行讨论。
工业大数据分析场景
工业大数据的典型分析场景如下表所示。
不同行业的侧重点有所不同，高端装备制造业多强调“服务性制造”和“智能装备”，化工行业则强调“安稳长满优“，电子行业以产品质量为核心，石油石化则注重资产管理和生产效率提升。
大数据分析规划
大数据分析规划宜采用“业务导向+数据驱动”的方式（如下图所示）。从关键业务目标分解出发，关联到具体的业务领域（研发、建设、运行、运维、安全环保、销售、采购等），从重要度和紧迫度的角度，对可能的业务分析问题进行评估。然后，结合初步的因子分解，评估每个题目的所需数据的完备度（Readiness）。综合业务价值和数据完备度，进行多个项目的优先排序。
业务理解阶段（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中因素进行刻画，如下表所示：
基于这样的分类，形成分析问题过程的因子动力学关系图，如下图所示（为突出分析目标，特别将目标量标出）。对于外生变量（特别是不可观测的）虽然我们无法直接优化，但至少清晰提醒了分析模型的适用前提。
业务用例（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倍？）的定义。
● 大数据情形下的运筹优化和经典调度在技术挑战上没有本质区别，关键是如何定义一个合适的范围，很多业务因素缺乏数据支撑、很多业务逻辑用数学规划语言描述太复杂（可以用规则）、约束松弛逻辑复杂，实际中常采用“规则+数据规划”的方式去求解。大数据为运筹优化提供了更多的基础数据（比如，成本结构、天气信息、道路交通流量）和预测性信息（如需求预测）的支持，而这些和数据挖掘类问题是一致的。
最后，应该充分认识到数据分析的迭代性。在早期，对问场景、因素的认识很难完备，实际数据与假设是否相符有待验证。这些不确定性都留给后面的阶段，只有经过多次迭代才有可能形成相对完备的问题理解。
数据理解（Data Understanding）
数据理解的目标是确认当前数据是否支撑分析问题，主要任务包括数据质量审查、数据分布，形成数据的初步洞察和直觉判断力。下面就工业大数据分析中的四个特别之处进行讨论。
数据分析的根基：以认真负责的态度去审视数据质量
在工业领域，一种常见数据类型是传感器监测或检测数据，除了数值质量本身外，还要考虑传感器本身的可靠性和安装方式，分析传感器的R&R
(Gage Repeatability and Reproducibility)。在风电领域，风机测风仪测的风速值是尾流风速，而不是轮毂风速，另外，测风仪的安装位置本身也可能存在偏差，也可能结冰。
在化工领域，气体产量不仅要关注其流量（体积），还要关注对应的气压和温度，否则可能会被“虚假表征”误导。
在工程机械车联网分析中，因为施工动态性（如传统油位传感器数据噪声太大）、施工环境（数据传输存在缺失）、人为破坏、部件更换、传感器及解析程序的升级换代等多种外部因素的共同作用，造成数据质量审查非常繁杂，有些存量数据的质量问题甚至无法解释（例如，月开工时长甚至超过744小时）。但这些艰苦基础性的数据治理工作必不可少，否则分析结果可信度很难保证。
在实践中，可以采用经典的统计方法去发现数值异常，然后不断深入理解哪些“异常”是系统的动力学特征（比如炉温是一个大惯、高时滞的过程）、哪些是控制逻辑行为（比如磨煤机出口温度的闭环控制）、哪些是测量系统问题、哪些是外部干扰等。只有把数据吃透，后面的算法模型才有好的基础。
你以为你以为的不是你以为的：透过业务场景还原，发现隐性质量问题
更为挑战的是，很多数据质量问题并非常规手段可以发现的，有的甚至连业务人员也没有意识到。在实战中，可利用数据去还原典型过程，发掘数据中表现出的“异常”场景，去完善业务上下文的理解。
例如，气化炉炉内温度软测量的一个前提假设是CH4浓度相对稳定，且与炉内温度密切相关。但实际数据探索中发现其中一台气化炉并不满足这样的假设（CH4浓度逐年上升，工艺对此的猜想是炉子内壁不断扩大造成的），而这样的现象过去谁也没有意识到。
运营和运作数据也有类似问题，比如，备件销量大不一定反映真正的市场需求，也可能是代理商囤货（冲业绩）。只有把影响数据质量的主要因素考虑全面，才可能做出有意义的分析。
数据量的困境：“大数据”量下的“小数据”信息
另外一个被经常追问的就是数据分析需要的数据量。工业分析问题即使做过独立性分析后，相关因子也通常成百上千，若严格按照全组合覆盖，需求量远远超过现实中可以采集的数量。
假设有20个变量，根据局部连续性假定，每个变量取4个数值就可以很好的拟合整个参数空间，全组合意味则需要条数据(约1千亿)，即使采集频率可达1000Hz，也需要近35年的历史数据。另外，工业过程通常一个运行在精心设计规律下的稳态过程（实际生产中并没有遍历整个参数空间），这也就意味着大数据中隐含的信息量其实是“很小”的。因此，关于数据量的问题，我们通常的回答：如果不融入领域认识去消减因子数量，通常你是无法提供“足够”的历史数据去覆盖所有组合情形。
数据的成本意识：数据分析师不要太任性
虽然总期望所有的重要因子数据都能被全量采集，但现实中数据采集是有成本的，同时也受制于当前的技术水平（比如，气化炉内温度是很重要的状态量，但目前的热电偶等传感器技术还无法长期可靠工作）和安全/环境考虑（比如，长输油气管道的压力传感器只能在阀室或场站部署）。
另外，在设备故障预警或检测分析中，故障数据是非常稀缺的，历史的运维数据通常也是不完整的。这些给数据分析带来了很大挑战，但同时也应认识到这就是现实（也许永远都不完美），我们的工作就是在现实的数据条件下进行的（根据数据基础，修改分析问题的提法，或通过其他信息补偿关键因子的缺失，或限定分析模型的适用范围等），而不是任性的一味要求数据。
数据准备（DataPreparation）
本阶段目标是建模分析所需的数据加工，包括原始数据抽取、多数据源融合、数据清洗与质量提升、特征提取。实际分析项目中，特征加工会占整个项目时间的40～60%。
针对一些特定领域问题，特征提取应充分利用已有的专业知识（不要浪费时间用数据分析手段挖掘出该领域早已熟知的规律）。以2009年国际PHM
Data Challenge的齿轮箱故障模式研判题目为例，专业组冠军利用了旋转设备的典型故障模式（各种倍频）的领域知识，进行特征加工，再用数据挖掘算法，取得了很好的结果，模型的物理含义对现场实操人员也比较容易理解。近年来，深度学习的发展，在一些特定类型的问题上可以降低分析人员的特征提取工作量，但对关键特征变量的理解在工业分析仍必不可少。
建模（Modeling）
机器学习（或统计学习、数据挖掘）分析理论发展成熟，也有很多明确的指导原则和丰富的算法工具，因而，建模过程在实际分析项目中花的时间反而不多，因此这里不再赘述。为保证模型的可消费性（Consumability）而非技术上的自娱自乐，下面仅仅谈三点“形而上”的原则。
● 结果要有“新意“：避免挖掘常识（common sense），常识应当作为前处理或特征变量融入数据分析模型
● 模型应遵循“极简”原则：用最简单的算法去解决问题，不要为了微不足道的性能指标提升而使用看起来“高大上”的复杂模型。为此，就需要抓住问题的主要矛盾，到底是censored
data问题、样本不均衡、模型的鲁棒性问题（应对个别极端异常数据）、过拟合（样本量相对模型参数空间不足）、模型的自适应性和提前性（比如针对宏观市场的变化，是否要求提前预估还是事后及时适应跟踪）、模型追求的指标（比如，回归问题追求是平均精度还是最差底线？分类问题对漏报、误报的侧重点）、模型的可解释性（对于根因分析，识别哪些因素在什么情形下重要对改进工艺更有实操性）。
● 模型的可控性和可解释性：任何模型都是在一定前提假设下对物理世界的简化，分析模型在建模时候不仅要关心平均性能，还应关心”worst-case”（最坏情形），最好能够清晰给出什么时候场景模型不适用（以及对应的处理措施）。对于性能提升，可以解释清楚其原因。
如前所述，数据分析是一个迭代过程。很多模型性能瓶颈并非来自于算法，而是来自于业务定义、数据理解、数据准备，例如一些很少发生但重要的业务/生产场景没有考虑到，一些重要因素甚至没有包含在当前数据集，一些严重的数据质量没有意识到。因为工业大数据分析技能的二分化，数据分析人员无法独立穷尽业务描述和数据集范围之外的情形，而业务专家也不可能思虑万全。
例如，在与一个国际客户合作地下管道失效风险评估项目中，根据业务专家和领域调研，我们拿到相对完备的数据集，第一期模型的总体性能还不错，但就在几个区域我们发现模型表现不好。
当把这些区域以GIS的形式可视化到业务专家面前，他们很快意识到一个重要因子的缺失（这些区域是围海造田，围海造田区的不均匀沉降比其他区域要大很多，这在当前数据集中没有体现），这些的信息对一个非本地人士/非专业人士来说几乎是不可能想象到的。
在建模过程中，不是泛泛谈模型的性能或数据质量，而是采用”worst-case”驱动的方式去和业务专家交流，告诉业务专家在什么情形下分析模型工作不好（给出具体的例子），触发业务专家的思考，借助专业外脑去发现问题的根因和解决手段。
评估（Evaluation）
建模阶段已经对分析模型从数据和技术的角度的进行充分检验。评估阶段再次从业务的角度审视模型的业务可用性(Actionable)，特别要定义清楚模型在什么情形下不适用，数据模型与业务流程的融合方式(Consumable)。
企业生产与管理是以工艺流程或业务流程为驱动的活动，经典信息化大多就流程（或改造后的流程）进行数据采集/整合和流转，以提升了业务效率；数据驱动的大数据方法尝试从数据产生/消费过程和多维度关联的新视角再次审视其中的蕴含的业务价值。但数据分析的结果若不能落到企业流程（现有的或新创建的），分析模型就游离在企业现有系统之外，很难实现价值落地。
对于采用已有的成熟模型，本阶段尤为重要。任何模型都有一定的适用前提，有些在对外宣传时候被忽略，有些前提在模型开发时没有意识到，因此，这些模型是否适用于当下场景需要大量的严谨的测试。
部署（Deployment）
部署的目的是保证模型的结果可被业务持久自动地消费(Consume)，除了大数据平台的计算性能问题，还应该注意分析模型的全生命周期管理。因为，在工业应用中，材料/工艺/装备/传感技术的不断更新。尽可能对部署模型进行密切的性能监控，通过闭环反馈进行模型成熟度评估和状态管理（试用、正式应用、需更新、退役等），保证生产的持续性和可靠性。
后记
本文以CRISP-DM方法论为基础，讨论工业大数据分析在不同阶段的挑战、需求与做法。CRISP-DM方法论是众多数据分析方法论的一种。任何数据分析方法论的要旨不外乎以下三点：1）定义一个好问题（有业务价值，技术可解，数据可支撑）；2）整理出值得信赖的数据；3）构建一个可被消费(consumable)的模型。一个认真负责、脚踏实地的工业数据分析师应尊重领域知识，了解数据的来源和业务意义，把握分析项目的主要矛盾，以“极简主义”的思路去建模，将分析技术与业务流程有机结合。
CRISP-DM方法论的六个阶段在不同问题中的重要度也不同。例如，有很多经典数据分析问题（如人脸识别、语音识别、文本分析）本身就很具体，这时主要的精力在数据预处理和算法精度上。
从宏观层面来讲，工业大数据和商业大数据在分析方法论上没有本质区别，只不过分析对象、数据特点、现有基础、应用期望等方面存在较大差异而已（详细阐述请参阅5）。再加上一些简洁的大数据思维（如从样本到全量思维；由精确到模糊思维；由因果到关联思维）、AI等宣传，若脱离了上下文和应用场景限定，很容易误导工业大数据的实践。
方法论为分析项目推进提供了很好的方向性指导，分析项目的成功更离不开数据分析师和业务人员的专业精神和务实态度，以及行业深入理解、相关的案例知识、丰富的实践经验、行业算法库以及合适的大数据分析平台支撑。
|
