【TigerGraph】图在复杂制造业中的应用

一、制造业与图
（一）复杂制造业的特点
常见的复杂制造业包括汽车制造业、芯片制造业、化工行业等等。
　　复杂制造业之所以复杂，有如下几个原因：
　　1. 物料变化复杂
　　以汽车制造业为例，一辆汽车有上万零件，而每个零件的产商、型号、版本都很多样，所以组合变种就极其多。制造业常用物料清单（Bill of Material，简称BOM）来表示终产品由子件构成，而子件又拆分为更小的子件，终形成母件和子件组成的关系树。越是复杂的产品，其BOM也越大。
　　2. 流程工序复杂
　　生产一个复杂的产品，往往需要成百上千步，而每一个步骤又可以用相同类型的不同机器生产，如何变种可能性很多的流程中挖掘出有价值的信息，优化流程，提高生产率，是一个不小的挑战。　
　　3. 供应链路复杂
每件产品的生命周期中，都涉及与多方（如供应商、合作伙伴和零售商等）的交互数据，随着公司规模的扩大，如何基于大量结构错综复杂的数据，实时掌握库存信息和零售需求，及时调配库存，对于重资产的制造业来说尤为重要。
（二）复杂制造业的数据建设

对一家制造企业来说，各种企业活动中都会产生出大量的数据，比如产品数据、制造数据、销售数据、售后数据、物*流*数*据和供应链数据等等。很多企业已经做到相当程度的数字化，将相关数据收集和存储到各大业务系统中，比如ERP、CRM、APS、SCM、MES、WMS和DRP等系统中。这些业务系统往往是使用传统的关系型数据库存储的，比如Oracle、MySQL等等。

还有些企业走得更远些，对业务系统的数据进行二次加工，放到数据集市中、数据仓库。

关系型数据库的特点是很擅长处理事务型任务，但对于分析型任务其能力相当有限，并且只能处理单机的数据。随着近年来大数据的蓬勃发展，以Hadoop为代表的大数据平台利用其分布式存储和计算的优势，大大增强了企业数据整合、数据加工的能力。

然而，无论是关系型数据库，还是像Hadoop这类键值数据库，由于并不存储关系，对于深度关联的数据的分析并不具有优势。对于一家大型复杂制造企业来说，无论是想要深入分析大量数据，进行多类型数据的关联分析，还是需要实时更新和分析数据，都需要一款原生存储点边关系，并且支持分布式的图数据库，而TigerGraph正是这样一款完美解决这类需求的企业级图数据库产品。下图展示了关系型数据库、键值数据库和图数据库的差别。

（三）图数据库在复杂制造业中的应用
我们分别从微观和宏观两个角度看图数据库在复杂制造业中的应用。
首先，从微观上来看，图数据库在解决某些有明确业务需求的应用场景上，有着巨大的作用。以下举几例，作为抛砖引玉之用。

1. 物料清单查询
物料清单本身就是树状结构，而树是图的一种特殊形态，因此图是表示物料清单的非常自然的方式。
下文第二大点“图应用场景举例”中将重点介绍此案例。

2. 生产流程优化
复杂数据之所以复杂，主要来源于两个维度，一个是广度，可能深度。广度指的是与单个节点有关联的节点非常多，比如社交网络，就是这样案例的典型，每个账号的关注人往往都非常多。而深度指的是要完整地表达某种关系，必须进行非常多跳的查询。企业数据可能既广又深，也可能广而不深，而生产流程则是深而不广的代表。因为每个生产步骤的下一跳只有一个节点，然后这样的跳跃可能上百上千步，而且很多时候每个产品的跳数是不确定的。
这种数据的分析，既有对图数据库性能上的要求，也有对图查询语言的要求，必须支持循环操作，才可解决跳数不确定的问题。而TigerGraph的GSQL是一款图灵完备的语言，能轻松应对循环操作。

3. 供应链管理
供应链管理涉及到多人协作，需要实时返回新的库存信息，包括汇总后的信息和明细数据的查询，查询过程涉及涉及实体很多，关系复杂。关系型数据库和键值数据库在处理这类深度关联的场景时，往往要事先做好数据关联，将关联结果存储起来，提供查询，而无法实现实时查询复杂关系。图数据库此时的优势就突显出来，因为只要通过边找到相关联的数据，而无需对某一类型的顶点做全局扫描。

其次，从宏观上来看，图数据库可连接企业各部门、各阶段的数据，有助于建立企业知识图谱，为更多未知的应用场景提供基础平台。企业在数据探索过程中，发现新的应用场景时，可通过图查询语言关联数据进行查询和分析，而无需对整个图数据库做重新建模。这也是在我们的客户中时常发生的事，一开始使用图数据库的动机主要是一些明显的业务场景，后来在使用过程中，又发现了许多新的业务场景，这主要得益于TigerGraph的易用性和灵活性，以及数据互联的普遍性。

二、图应用场景举例
（一）物料清单
物料清单（BOM）是定义产品结构的技术文件，又称产品结构树。
下图是同一份物料清单的不同展示方式，左图为单级展开，右图为多级展开。

落到数据上，由于每个装配件（Item）又区分不同版本（Item Revision），每个版本的装配件可能在上一级装配件中出现多次（Occurrence），为避免数据冗余，会将它们的配置存到Item Revision上。因此就形成了Item->Item Revision-> Occurrence的树状结构，这样的结构又会多层重复出现，有时甚至超过30层。

再加上，有时Occurrence会地使用某一版本的Item进行装配，故此又存在Occurrence指向Item Revision的情况，同时也不排除存在环的情况，这样就使得整个结构更加复杂。

除了结构复杂外，BOM的数据量往往也非常大，到Occurrence一级甚至能达到十亿级。另外，BOM作为多部门多人更新和查询的数据，还必需支持实时更新和并发查询。以上这些特点都给存储和查询BOM的数据库提出了不小的挑战。

（二）TigerGraph应用于BOM场景
面对以上的挑战，TigerGraph是如何一一化解的？

下面用一个简单的demo，说明在TigerGraph中是如何实现BOM的。
1. 建立Schema

2. 映射和导入数据

3. 创建query

CREATE QUERY q1_explore(vertex<Item> input, INT depth) FOR GRAPH BOM {
OrAccum @visited;
SetAccum<Edge> @@EdgeSet;
INT iteration;
//-------- inialization --------
Items = {input};
ItemRevisions = SELECT t
FROM Items:s -(Configuration:e)-> ItemRevision:t
ACCUM @@EdgeSet += e,
s.@visited = True,
t.@visited = True
;
Occurrences = SELECT t
FROM ItemRevisions:s -(Has_Child:e)-> Occurrence:t
ACCUM @@EdgeSet += e,
t.@visited = True
;
//-------- traverse --------
WHILE TRUE LIMIT depth DO
Items = SELECT t
FROM Occurrences:s -(Uses_Item:e)-> Item:t
WHERE t.@visited == False
ACCUM @@EdgeSet += e,
t.@visited = True
;
ItemRevisions = SELECT t
FROM Items:s -(Configuration:e)-> ItemRevision:t
WHERE t.@visited == False
ACCUM @@EdgeSet += e,
t.@visited = True
;
ItemRevisions_2 = SELECT t
FROM Occurrences:s -(Precise:e)-> ItemRevision:t
WHERE t.@visited == False
ACCUM @@EdgeSet += e,
t.@visited = True
;
ItemRevisions = ItemRevisions UNION ItemRevisions_2;
Occurrences = SELECT t
FROM ItemRevisions:s -(Has_Child:e)-> Occurrence:t
WHERE t.@visited == False
ACCUM @@EdgeSet += e,
t.@visited = True
;
END;
//-------- print result --------
PRINT @@EdgeSet;
}

4. 查询
比如输入Item为i1，depth为2（涉及3层item，共8跳），得到如下结果：