spark如何进行聚类可视化_基于集成Spark的图解决方案的AI实践

​企业常用Spark作为ETL的工具，其在批处理和流数据处理上都有不错的表现。同时，Spark上的MLib可在集群上跑机器学习算法，因此相较于python，它能支持更大的数据量。

为什么采用TigerGraph + Spark？

TigerGraph作为首款原生并行图数据库，同样基于MPP架构，支持分布式。当TigerGraph和Spark两者结合起来使用时，会产生出什么样神奇的效果呢？

上图是Spark + TigerGraph解决方案的数据流，批数据与流数据进入Spark后，Spark对数据进行清洗，然后将结果数据导入到TigerGraph中。

接着，在TigerGraph中提取图特征，将特征实时地返回给Spark。Spark再基于TigerGraph返回的图特征以及其他的一般特征（如基于统计的特征），进行机器学习的训练，训练结果再写回到TigerGraph中。

然后，新的流数据进入TigerGraph后，就可以根据实时地提取它们的特征，再用上面的训练模型，对新数据进行预测了。这些预测可以用来做数据洞察、商业智能以及图的可视化。

按时间顺序，Spark + TigerGraph的解决方案各阶段两者分别起着不同的作用。

1数据准备与集成阶段

此时Spark发挥其ETL的优势，但TigerGraph也能在一些特殊的场景下起着不同低估的作用，比如第四部分将提到的实体解析。

2无监督学习

图算法中的社区发现可以将顶点按社区进行聚类，能实现无监督学习中的聚类算法。

3监督学习的特征提取

这也是TigerGraph在所有环节中最有价值的一环，是非图数据库难以替代的一步。它给Spark中所能提取到的一般特征做了非常有效的补充，对于存在复杂网络关系的数据，其价值甚至超越了一般特征。

4模型训练

这一步由Spark负责

5验证和应用模型

这一步发挥了TigerGraph实时并发处理大量请求的优势，将模型训练结果应用于预测新数据上。

6可视化和探索相互关联的数据

TigerGraph有GraphStudio可供给数据科学家进行数据探查，发现图中存在的规律。

基于图特征的机器学习案例

特征工程是几乎所有机器学习算法的第一步，其耗时耗力，需要一定的业务经验。而且特征的设计直接决定了算法的效果。

如上一个简单的案例，最终是要预测房价，现设计了面积、房间数以及卫生间数三个特征，基于训练数据集训练得到一个函数，可以用来预测新的数据。

但如果设计特征设计得不好，比如设计了大量类似于房间颜色这种与房价相关性低的特征，那么即使我们使用再好的机器学习算法，预测结果也会差强人意。

再者我们知道，计算机科学的发展大致分为三个阶段。

第一个阶段是程序时代，我们基于规则编写程序用于预测结果。

第二个阶段，对于复杂的、难以用规则处理的问题，我们将训练集喂给机器学习算法，获得一个预测函数，实践表明这一方法效果很好，然而问题是缺少可解释性。因为计算过程和模型本身在是一个黑匣子，对于严谨的决策过程，业务人员很难基于这样的黑匣子做出业务决策。

第三个阶段，则用上了可解释的AI，我们既要AI的结果是什么，也要知道为什么如此。

如上图所示，图是由节点和边构成的，每个节点对应一个业务概念，每条边代表两个业务概念之间的关系，比如投保人购买保单，投保人和保单就是两类节点，而购买的动作就可以设计为投保人和保单之间的边。图本身就有着语义表达能力，基于图而设计的特征同样有着业务意义。下面举一个某省级运营商实时反诈骗的案例，其中的每个图特征都很容易解释。

如上图所示，左侧为好的电话，右侧则为不好的电话。好的电话有如下一些特征：

1. 来回呼叫频繁；

2. 有着稳定的通话群体；

3. 回拨率高；

4. 朋友之间也存在稳定的通话；

5. 朋友之间虽然没有直接通话，但朋友的朋友则为同一人。

好的电话这五个特征的分值应该更高，而坏的电话则与以上五点相反。

用图算法实现非监督学习

图算法中有个社区发现算法，很类似于非监督学习中的聚类。如下图，即存在三个社区，发现社区后，可进一步找到各个社区的特点，然后为业务目标服务，比如做精准营销。

标签传播是比较常用的社区发现算法， TigerGraph自带的GSQL语言实现的代码如下，您可在github上下载，下载地址为：https://github.com/tigergraph/gsql-graph-algorithms/blob/master/algorithms/examples/Community/label_prop.gsql。

从以上的代码中，我们可以看到GSQL几个显著的特点：

1. 不同于JAVA、C++等较低层语言，GSQL是一门更偏向语义层的语言，就像SQL语言一样，而且其语法中最常用的取数模块很类似SQL语法，也有SELECT、FROM、WHERE、HAVING、ORDER BY和LIMIT等部分，见上图红色圈出的内容；
2. GSQL是一门图灵完备的语言，支持while循环、foreach遍历、if-else条件判断、case when条件判断等功能，因此能实现相当复杂的算法，见上图黄色圈出的内容；
3. GSQL中的累加器非常强大，能在图遍历时给顶点添加临时的属性，以供进行复杂计算，加上累加器在每一跳时是并行计算的，因此性能强劲，如上图的@@changed就是一种或操作累加器，

图数据库助力实体解析

数据清洗是相当耗时的一项工作，使用图数据库一定程度上让数据清洗的工作目标更清晰。比如以往如果您的目标是建一张大宽表的话，就涉及到不同颗粒度的表进行关联的操作，这对业务的理解、对数据的理解都有一定的要求，同时很容易出错，比如对增量数据的关联就陷阱多多。

相比之下，由于图数据库每个节点都对应着一个明确的业务概念，数据清洗过程输入和输出为相同颗粒度的表，最多只有一些简单的汇总，因此操作难度大大下降。

除此之外，在某些场景——也是很常见的场景——下，比如下面介绍的实体解析中，图的加入让原来使用SQL时一筹莫展的难题迎刃而解。实体解析要解决的是，业务上同一概念，但由于源系统不同、数据录入要求不严格等原因，在不同系统中，或者同一系统的不同表中，以不同的主键存在的情况。

举个例子，同样是客户，在各个系统中其主键不一致，有些是以证件号码为主键，有些是以客户号为主键的，还有些只留下email地址或者电话的，最终要将疑似同一客户的数据统一为一条数据。

上图即是合并疑似同一客户的案例，三个源系统各有一些客户的属性，但每个系统都不完整，当导入图数据库时，还是视为两个不同的客户，但通过图将疑似同一客户的两个客户融合为同一客户，就可以补全了他更多的信息。

实体解析应用广泛，金融和保险公司通常都有ECIF系统，其核心功用就是统一客户，然而鉴于关系型数据库在表达网状关系能力的薄弱，实现统一客户功能相当繁琐，而且人工维护成本极高。

除了做统一客户，实体解析还有很多其他案例，比如寿险想推广家庭组合险种时，要基于存量客户找到家庭，并分析每个家庭的特点。

但数据库中并没有家庭信息，只有保单信息，记录着投保人、被保人以及投被保人的关系（如夫妻、父母子女、朋友等等）。此时通过图数据库的实体解析，就可以解析出家庭，以供做精准营销之用。

完整演讲PPT，可以点击链接下载

基于集成Spark的图解决方案的AI实践​info.tigergraph.com.cn