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

工业数据分析的基础是工业数据的良好组织和管理。在典型的数据湖-数据仓库两层数据架构中，数据湖允许数据集中聚集和访问，但数据湖中的数据是按照数据源的格式原样存储的。在面向数据分析的场景中，比如智能设备运维、生产流程优化等。还需要使用数据仓库技术对来自多个数据源的大量历史数据进行格式化和整合，建立数据库，以保证分析项目的成功。

然而，在实践中，我们发现用于工业数据分析的数据仓库往往存在以下问题：

数据模型的定义是相当随机的，字段和数据表会根据数据分析的要求随机增减。

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

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

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

如果你是一个工业企业的IT工程师或者数据分析师，你可能并不太了解来自数据管理领域的数据仓库这个抽象晦涩的概念，更不知道如何在实际工作中应用这项技术。如果你是一个有很强IT技术背景的数据专家，服务于工业领域，不妨了解一下在工业数据分析领域应用数据仓库等数据管理技术的实践经验，以免踩一些坑。那么希望这篇文章能帮到你。

下面，我们通过工业场景的例子来解释数据仓库建模的基本概念。本文讨论了数据仓库的两个基本建模系统——常规建模和维度建模的异同，以及它们适用的工业数据分析场景。解释在当前工业数据分析领域的成熟度下，为什么应该首选范式建模。

工业数据分析的特点

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

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

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

3)数据分析由单点向综合转变。工业数据分析在企业中的应用越来越广泛，其价值开始显现。越来越多的企业正在考虑从单点应用开始规模化、有计划地建设数据分析能力，这就需要一个能够不断积累数据资源的数据库，使数据仓库能够在多个数据分析主题中重用，减少重复建设的浪费。

数据仓库建模系统

从数据仓库的产生到今天，其建模体系和思想都在不断发展。本文重点介绍两个最基本和最常用的建模系统：范式建模和维度建模。在了解了基本方法之后，我们讨论如何在工业场景中选择和应用这两种方法。

值得强调的是，任何数据模型都是要解决的业务问题域的抽象，强烈依赖于业务域中的基本概念和业务规则，因此数据建模必须让业务专家和数据管理技术专家参与整个创建和更新过程。

范式建模

数据仓库的范式建模源于OLTP数据库设计。范式建模使用实体关系模型作为建模语言。在OLTP数据库设计中，范式建模主要强调数据插入和更新的一致性，而数据仓库的范式建模主要强调业务领域基本概念和规则的辨析和准确表达。

实体是指业务领域中我们感兴趣的那些对象和事件。实体可以是物理存在的，如设备、生产线、产品，也可以是逻辑存在的，如订单和销售。因为作者主要从事以工业设备为核心的生产经营过程中数据的智能化应用，所以主要涉及前者，我们称之为“工业实物”。

实体类型是指相同类型的实体的集合。严格来说，在数据建模的过程中，我们从一个具体的实体(实例)出发，抽象定义其所属的实体类型。实体及其类型必须是名词。命名之后，最重要的工作就是仔细分析这个名称(概念)的内涵和外延，最后定义实体的属性来体现这个概念。

工作组中的每个人都应该对模型中实体类型所表达的概念有一致且明确的理解。比如，我们在日常生活中谈到材料和产品时，通常认为材料是原材料，产品是最终产品。但在特定的工业数据模型中，如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和数据管理技术的融合，促进跨领域交流，形成共同语言;

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

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