工业数据分析是指利用数据管理和数据分析技术，对工业数据进行处理和分析，挖掘数据价值，实现设备运行安全可靠、生产效率提升、成本降低、产品质量提升等业务目标。

工业数据分析的基础是对工业数据进行良好的组织和管理。在典型的数据湖-数据仓库两层数据架构中，数据湖让数据聚集、可以被集中访问，但是数据湖中的数据是按照数据源的格式原样存储的。在面向数据分析的场景中，例如设备智能运维、生产过程优化等，还需要利用数据仓库技术，对来自多个数据源的大量历史数据进行格式化处理和集成，建立数据基础，为分析课题的成功提供保障。

然而在实践中，我们发现面向工业数据分析的数据仓库经常存在以下的问题：

• 数据模型的定义比较随意，会随着数据分析的要求随意增减字段和数据表；

• 数据字段和数据表表达的业务语义不明，重要的业务规则隐藏在数据处理逻辑中；

• 业务专家和数据分析师不能很好的参与到数据建模过程中，数据工程师只能根据业务专家的描述和数据分析师的具体需求被动的进行响应；

• 多个相关的数据分析课题不能互相复用数据，存在大量的重复数据处理和清洗过程。

如果您是一名在工业企业内部的IT工程师或数据分析师，您可能对数据仓库这种来自数据管理领域的抽象晦涩的概念不是很了解，更不知道如何在实际的工作中应用此技术；如果您是一名来自较强IT技术背景的数据专家，服务于工业领域，您可能希望了解在工业数据分析领域应用数据仓库和其他数据管理技术的实践经验，少踩一些坑。那么希望本文能够对您有所帮助。

在下文中，我们通过工业场景的示例，对数据仓库建模的基本概念进行解释。本文对解数据仓库的两种基础建模体系-范式建模和维度建模的异同点以及分别适用的工业数据分析场景进行探讨。说明为什么在当前工业数据分析领域成熟度下，应当优先选择范式建模。

工业数据分析的特点

在工业数据分析中，有几个较为突出的特点，在确定数据管理思路时需要结合考虑。

1）需要跨界融合。工业数据分析涉及工业核心设备、生产过程的多领域机理，还需要结合专家经验，因此其行业门槛较高，这就需要工业专家（以下或简称OT）、数据科学家/分析师（以下或简称DT）、IT和数据工程师（以下或简称IT）的跨界沟通、协作。

2）数据质量参差不齐。一个典型的工业企业发展过程中会持续进行自动化和信息化建设，周期跨度从几年到几十年不等，来自不同建设时期和背景的信息化系统中的数据含义、格式、规范区别较大，也较少存在数据标准，因此数据分析课题需要对数据质量有定量理解。

3）数据分析从单点到全面转换。工业数据分析在企业中的应用逐渐广泛，其价值开始体现，越来越多的企业从单点应用开始考虑有规模、有计划的建设数据分析能力，这就需要一个能够持续积累数据资源的数据底座，使得数据仓库能够在多个数据分析课题中得到复用，减少重复建设浪费。

数据仓库建模体系

数据仓库从产生到今日，其建模体系和思路是不断发展的。本文我们着重探讨其中两种最为基础和常用的建模体系：范式建模和维度建模。在了解其基本方法之后，我们讨论如何在工业场景中选择和应用这两种方法。

值得强调的是，任何数据模型都是对要解决的业务问题领域的抽象，强依赖于业务领域中的基本概念和业务规则，因此数据建模一定需要业务专家、数据管理技术专家全程参与创建和更新。

范式建模

数据仓库的范式建模是从OLTP数据库设计中衍生而来，范式建模使用实体-关系模型（Entity-Relationship Model）作为建模语言。在OLTP数据库设计中，范式建模主要强调数据的插入和更新一致性，而数据仓库的范式建模主要强调对业务领域的基本概念、规则的辨析和准确表达。

实体（Entity）指业务领域中我们感兴趣的那些对象和事件，实体可能是物理上的存在，例如一台设备，一条产线，一个产品，也可能是逻辑上的存在，例如一个订单，一次销售。因为笔者主要从事的是以工业设备为核心的生产运行过程的数据智能应用，所以主要涉及的都是前者，我们称为“工业物理对象”。

实体类型（Entity Type）指一批具有相同类型的实体的集合。严格来说，在数据建模的过程中，我们从一个特定的实体（实例）出发，去抽象和定义的是他所属的实体类型。实体及其类型一定是一个名词，命名之后最重要的工作就是仔细辨析这个名称（概念）的内涵和外延，最后定义实体的属性来反映这个概念。

工作组中所有人都应该对模型中的实体类型表达的概念理解一致无歧义。举个例子，在生活中我们提到“物料”和“产品”，通常认为“物料”是原材料，“产品”是最终产品，然而在特定的工业数据模型中，例如ISA95生产信息整合模型，“物料”被定义为可以是原料、半成品或者成品（因为从更大的范围来看，一个生产段产生的“成品”其实是下阶段的“原材料”）。如果不把这个概念表达清楚，工作组中的沟通就会变得失真、低效，甚至南辕北辙。

针对同一个业务问题，数据模型也不是只有一个正确答案，换一个抽象的层次和角度，把“原料”和“最终产品”分开定义当然也是对的。笔者强调的是在一个特定的模型版本中，所有的概念都应该是清晰无歧义，形成共识的；如果模型更新了，所有人的共识都要跟着更新。

关系（Relationships）指实体和实体之间由于某种业务规则而产生的联系和互动。关系就像胶水一样，把原本独立的实体信息整合在一起。例如，一台设备上有多个传感器、多个传感器可能会度量同一个逻辑测点（传感器冗余）、一个车间包含多条产线、一条产线包含多个工段等等。

关系的定义也需要依照业务规则进行，如果我们识别到两个实体之间会产生一个关系，我们要进一步识别以下几方面的内容：

1）关系的基数，即一对一、一对多、还是多对多；

2）关系的强弱，即产生关系的两个实体生命周期是否受关系的影响；

3）关系的附加属性；

4）关系双方在这个关系中的角色名称。

举个例子，假设我们对一个金属铸造的过程进行数据建模。模具需要安装到铸造机台上进行铸造使用，假设业务目标是要找出不同的铸造机台是否会对铸造质量产生影响，那么机台和模具之间的关系可以由下图表示：

在上图中，机台和模具的关系基数是一对一，因为一个机台最多绑定一个模具，同时一个模具也不可能安装到多个机台上；关系的强弱是强关系，因为铸造是由机台和模具共同完成的，在当前定义的问题中，没有必要把他们分开看，如果从系统中把一个铸造机台记录删除，那么上面安装的模具记录也可以一并删除；关系上也无需附加任何额外属性；双方的角色名只有在数据访问的时候才会用到，目前暂不讨论。

之后，我们从业务专家那里了解到，我们忽略了一条重要的业务规则，即“铸造机台和模具之间虽然在一段时间内是一对一的绑定关系，但是每隔一段时间，都会把模具从机台上拆卸下来换上新的模具，拆下的模具会被清洗保存，直到下次安装到其他（不确定是哪台）的机台上使用，如此循环”。基于上述新的业务知识，我们修改关系如下：

在版本2中，关系的基数变成了多对多，因为任何一个机台都可能安装任意一个模具，反过来，一个模具也有可能被安装到任意一个机台上；关系的强弱变成了弱关系，因为模具不再依赖于机台的存在，因为模具会被单独清洗保管，有可能没有安装在任何一个机台上。我们还需要一个关系附加属性来表达“在什么情况下，一个特定的机台会和一个特定的模具绑定在一起”。业务专家反馈说：“换模具是在换批次的间歇进行的，换批次的时候可能换模具，也可能不换，取决于模具是否需要清洗，但是在一个铸造批次执行过程中不可能换模具”，因此我们得知，只要在关系额外属性上记录批次号，机台和模具的绑定关系就完整了。

通过上面的例子，我们体会到数据模型中关系的定义是如何反映实际的业务规则的。假设业务专家说：“换模具的时间没有特定规则，就是班组长觉得需要换了就换，即使在一个批次生产过程中。但是换模具的时候我们有记录，因为工人会扫码”，感兴趣的读者可以思考，在上述规则下，机台和模具的关系应该怎么建。

最后，范式建模也会有一些门槛，即数据模型要满足三范式的要求，这需要一定的数据库模型理论和技能基础，这也是范式建模体系最终不被采用的重要因素之一。但是笔者相信，在工业数据智能领域，最大的门槛不是特定的数据库技术，而是工业知识、IT知识和数据分析知识的融合。在范式建模过程中，业务专家、IT专家、数据分析专家依据业务规则对数据模型进行反复澄清讨论，由此产生的信息交流和最后产出的数据模型会帮助整个团队建立共同业务认知和语言体系，这对后续数据分析和应用的研发是一个重要的基础。

维度建模

在维度建模（Dimensional Modeling）中，数据被分为事实和维度两种类型。事实指在业务过程中发生的一次度量，而维度指这次度量发生的上下文。一次度量（事实表中的一行）可以包含多个度量结果和多个与之关联的维度信息。

在工业领域中，来自于DCS或者SCADA系统中的设备时序数据是最典型的事实数据之一：PLC的一次采样会产生多条测点数据，例如温度、压力等，同时伴随这条事实数据的至少有两个维度——时间戳和点位号。另一个工业产品制造领域常见的事实数据是生产过程中的质检数据：一个半成品或者成品在检测环节经过特定检测手段会产生的一次检测结果记录。检测的指标，例如尺寸、重量等属于度量数据；而被检测的产品ID、检测程序、检测机台等属于维度数据。

在事实表中，维度列的取值只是一个单值（标量），但背后通常代表的是一个业务实体（这也是为什么很多维度列以某某ID命名），我们称其为维度实体。一个维度实体又可以和其他的实体产生联系。例如上面的例子中，设备时序数据表中的“点位号”代表的“点位”可以抽象为一个对象，除了点位号（ID）之外还有度量单位、量程、物理意义等属性。通常多个点位又同属于一台设备，所以一个点位对象又和一个设备对象发生关联，等等。根据事实表和维度表之间组织成的形状不同，维度模型分为星型模型（Star Schema）和雪花模型（Snowflake Schema）两种类型。

星型模型是以事实表为中心，所有的维度直接和事实表相关联，维度和维度之间没有关联，维度表围绕在事实表周围成星状分布。

雪花模型以星型模型为基础扩展，允许维度表和维度表之间继续产生关联关系，也就是说，事实表可以通过维度和维度的关联获得间接维度。

同一个问题，既可以用星型模型组织数据，也可以用雪花模型组织数据，那么这两种模型的优缺点分别是什么呢？我们用设备时序数据为例进行对比说明。

上图是设备时序数据的星型模型组织。首先，点位号是设备时序数据的一个维度，通过一个点位实体类型来记录点位对象的其他属性；时间戳是一个维度但是一般在工业数据分析中，时间戳直接参与运算，并不会像销售数据那样，时间是小时、天、月、年等自然时间段进行分析聚合的，因次不用进行对象化处理。接下来，假设分析课题要在设备的粒度上对监测数据进行聚合，例如存在多个点位是对同一设备组件的冗余测量，我们需要计算他们的平均值。针对这个问题，星型模型方式需要重新处理事实表，增加一个“设备ID“维度，并且与设备实体类型进行关联。

上图是设备时序数据的雪花模型组织。点位号和时间戳两个维度的处理方式与星型模型相同，这里不再赘述。不同之处在于，如果我们要增加一个新的分析维度“设备”，并且经过业务分析我们知道多个点位是属于同一个设备的，也就是说，设备和点位之间存在一个一对多的关系，那么我们就按照范式建模的思维在点位和设备实体类型事件建立一个新的关系，时序数据需要在设备维度进行聚合时，要通过关联点位再关联设备的方式进行。

对于两种模型，我们不难发现雪花模型其实是星型模型的维度部分用范式建模处理的结果。星型模型的好处是维度数据和事实表永远直接关联，因此数据库访问的效率相对较高，但是缺点是间接维度在事实表中存在数据冗余，如果维度数据进行更新，或者业务上提出新的分析需求需要增加维度，那么事实数据就需要重新进行清洗处理，因此星型模型比较适合处理“预先定义的，需求相对确定的”数据分析课题。

相比之下，雪花模型的维度部分用范式建模处理，在关联查询，尤其是多层次的维度关联查询时，效率略低，但是换来的好处是数据模型相对稳定，维度的更新、增加等操作代价较小，对分析需求的变更有一定的自适应性，因此雪花模型适合解决“探索性的、随时有可能变化的、临时的”数据分析课题。

工业领域的数据仓库建模体系选择

表：范式建模对比维度建模

上表对比了数据仓库范式建模和维度建模体系的优缺点。在工业领域应用时，企业应该结合自身的数据智能应用成熟度和具体建设项目目标来确定数据仓库的建模和实施思路。

对于数据智能的尝鲜者，可以采用维度建模针对单个课题进行数据组织建模，这样项目的建设启动时间短，数据建模的难度也相对较低，能够快速完成数据分析课题，获得价值，这样可以帮助团队和企业建立对数据智能应用的信心。

对于开始有规划的建设跨课题、跨部门统一数据底座的企业，建议开始采用范式建模的思路，通过有意识的组织业务专家、IT专家、数据分析专家进行协作，对一个给定的业务范围的基本业务对象、规则进行辨析，规范命名，构建统一范式数据模型；对于事实数据的部分，建议采用维度建模中的雪花模型进行组织，即维度部分也尽量采用范式建模的方式处理。这样可以获得相对稳定，维护代价较小的数据模型，虽然启动的成本增加，但是从长期维护和应用，是总体效率较高的方式。更重要的是，范式建模可以促进团队乃至组织对业务概念、规则、知识进行沟通交流，构建统一语言。

实施范式建模的一大误区就是一开始就陷入大而全的境地。例如以工业设备为核心的生产运行领域，基本生产要素包括设备、工艺方法、物料、人、环境等几大模块，每个模块分解后，其包含的实体类型数量都会有几个到几十个不等，试图一次性把范围如此庞大业务领域梳理清楚是几乎不可能，也没有必要的。建议按照主题的方式进行业务划分，每个主题的范围不宜过大，但是要尽量做透，以业务场景驱动完成底层基础数据建模。如此迭代几次，以拼图的方式完成更大业务范围的基础数据建模工作。

总结

本文介绍了数据仓库建模的两种基本体系：范式建模和维度建模的概念和基础方法。通过与工业数据分析领域相结合，探讨了如何把这些抽象的IT方法与具体的工业数据分析业务结合进行实践。我们着重对比了不同数据建模体系的优缺点，主张结合企业自身数据智能应用的成熟度和项目目标选择合适的数据建模体系。在有可能的情况下，我们推荐优先使用范式建模相关的技术，会给分析课题和企业带来以下价值：

• 有利于在工业企业内部推动工业专家、数据科学家/分析师、IT和数据管理技术的融合，促进跨领域交流，形成共同语言；

• 让数据的业务意义显现化，让业务和数据分析师以更直观的方式获取数据，提高数据的可被消费性；

• 为数据集成奠定良好的元数据基础。

在下一篇文章里，我们将会把视角从单个课题或者项目放大到跨课题、跨团队的共享数据体系，说明如何通过数据的分层架构实现模型复用，数据分层架构的不同层次如何天然的对应到工业企业内部不同的职能组织，希望对读者有所启发。

作者简介

徐地博士，昆仑数据首席架构师，前IBM中国研究院研究员。主要研究实践方向为云服务、工业数据治理、数据驱动应用架构等。曾先后为新能源、石油、装备、化工、电子制造等多行业头部企业提供工业数字化解决方案指导，并将工业数据治理和数字化应用经验总结为工业互联网平台产品。发表国际顶级计算机体系结构会议第一作者文章两篇，专利10余项。同时也是资深软件工程师和架构师，认证ScrumMaster，具备多年敏捷研发团队管理经验。