2.2 图分析与数据科学

图分析（Graph Analytics）在本质上是对图数据的处理与分析，其过程可以概括为图计算。而图计算的范畴不仅包含数据的计算或分析，还包含元数据管理、模式管理、数据建模、数据清洗、转换、加载、治理、图分析与计算等一系列操作。或许我们用大数据生命周期来剖析图分析、图计算会有一个更全面的理解。

图2-5所示的是大数据发展历程中通常会遇到的五大问题，依次是大数据存储、大数据治理、大数据计算与分析、大数据科学和大数据应用。

图2-5中的大数据在很大程度上可以直接替换为图数据，毕竟图数据是大数据发展的必然趋势、终极阶段（图2-6）。我们解决图2-5中的五大问题的目的如下：

1）通过信息的关联化（高维、原生图）存储，采集更准确、更灵活、更能直观反映真实世界问题的数据，用于支撑决策。

2）通过图数据建模、血缘分析、数据核验、元数据管理等一系列数据治理工作来为科学的数据存储、计算与应用提供保障。

3）通过让信息更灵活、更透明、更实时化地被计算与分析，解锁大（图）数据的价值。

4）通过数据科学指导的图计算与关联分析，例如对风险传导的深度下钻与科学计量、对用户群体进行精细化产品、服务定位等，进行深度、复杂、白盒化（可解释）的数据分析及预测来提升决策准确率。

5）通过基于数据科学的应用与解决方案开发（高维建模、白盒化算法、决策与反馈机制），改善下一代产品、服务的开发。

图2-6中所示的数据发展趋势有两条主线和一个核心观点。

❑ 主线1：数据处理底层技术的核心发展趋势是从关系型数据到大数据直至深数据（图数据）。

❑ 主线2：对应底层技术的面向数据的处理维度呈现了从点到线、由线及面再到体的由简入繁、自低维到高维、自低算力需求到高算力需求、自简单分析到复杂分析的一个自然发展过程。

❑ 核心观点：图计算的本质是复杂网络化计算，是与人类大脑工作最为贴切的逆向工程，图数据库相对于传统关系型或NoSQL数据库的效率与性能有指数级的提升。

我们以主线1为例简要展开论述。20世纪70年代至80年代是关系数据库发展的早期阶段，它迅速地占领了政企IT市场，其中的佼佼者有IBM Db2、Oracle、Sybase等。1983年是关系数据库发展的标志性年份，SQL（结构化查询语言）国际标准应运而生，作为关系数据库的通用查询语言，尽管各个厂家都有自己的特殊语法与功能实现，但大体上都会支持通用的SQL，以保证系统间通信、系统迁移、升级换代与维护等操作的便捷性。随着互联网，特别是移动互联网、云计算业务的兴起，大多数基于单机、小型机或集中式架构设计的关系数据库在面向海量数据、多样多维多模态异构数据处理时的缺陷开始体现得越来越明显，于是基于分布式架构理念设计的Hadoop、非关系数据库等阵营开始出现，大数据库处理与分析技术开始得到越来越多人的关注。在大数据发展的历程中，出现了多种类型的架构阵营，可以简单地梳理为如下几个阵营。

❑ 基于MapReduce理念的架构阵营：最为常见的是Hadoop阵营，以及基于内存加速的Spark项目。

❑ 基于NoSQL理念的非关系数据库阵营：包含多种数据库架构，如列数据库、宽表、KV、文档、时序、多模数据库以及图数据库等。

❑ 基于SQL接口，但对底层进行了扩充与增强的新型关系型数据库、数仓、数湖阵营：数量庞大的各种商业或开源关系数据库、MPP数仓、各类流批一体化数仓、实时数仓等。

需要指出的是，尽管出现了多个阵营，但是自1983年开始的以SQL为主流的趋势并没有因为大数据等架构的出现而产生实质变化，毕竟绝大多数的新型数据库与框架依然还在向SQL兼容。然而，这一切可能会在2024年迎来一个实质性的转变。届时，数据库查询语言将迎来第二个国际标准—GQL，即图查询语言。换言之，Hadoop、Spark、NoSQL、数仓数湖尽管制造了无数的“噪声”，但是并没有形成一整套国际标准—一个会推动全球IT生态自上而下革新的标准。这种革新从底层上要解决的是SQL与关系数据库在处理多维、多模态数据时的无力—无法深层、动态、灵活、高效地完成对数据的处理与分析，特别是对于复杂关联、深层递归形式的分析—SQL在语言设计层面就不具备这种能力，而关系数据库二维表结构的低维性让分析实时性的问题变得更加“不可能”。事实上，SQL的这种低维性已经被诟病了很多年，但是在底层架构上一直没有本质的改变，尽管MapReduce等架构的出现让数据处理量大幅提升，但是并没有改变浅层数据处理的特征。换言之，几乎所有的分布式数据库只能面向浅层数据处理，任何深层数据处理依然会遇到效率低下、延迟巨大甚至错误求解的问题。而这一“不可能的任务”有望在图数据库的时代被解决。因为图数据库自下而上关注的是数据的关联关系，从建模、存储到数据治理再到数据计算与分析，以及数据查询与应用，它不再拘泥于关系数据库的表结构，不再受限于主键、外键，让数据建模更加灵活和高维，不再专注于浅层查询，也第一次让计算引擎成为数据库的一等公民，进而意味着在面向深层、复杂、动态、递归查询、分析与计算时的效率有指数级提升。这也是为什么我们会提出一个观点：图数据库是终极数据库，或最接近终极数据库的一种形态。

辩证地看待任何问题，我们需要意识到，无论是出于认知的局限性还是有意的误导，市场上很多所谓的图数据库在本质上都和图没有太大关系，它们都不具备对数据进行灵活建模、深度处理与分析、高效处理的能力，尽管它们都会毫无例外地宣称自己是高性能、分布式图数据库。这些以假乱真的图计算或图数据库产品有哪些特点呢？在此梳理如下几条线索以供读者迅速辨别真伪。

❑ 底层存储引擎基于NoSQL或RDBMS实现。这是典型的拿来主义，如此构建的非原生图不可能具有高性能处理能力，也没有灵活的数据建模的能力。其中，最典型的有基于HBase、Cassandra、ClickHouse、Hadoop甚至MySQL、PostgreSQL、Oracle实现。

❑ 计算引擎基于Spark GraphX或第三方“图上计算”引擎实现。以Spark GraphX为例，它仅仅是借用了图的名字而已，其数据加载与处理效率相对于Hadoop而言只提高了1～2个数量级，但是距离真正的高性能依然非常遥远，特别是面向实时数据时，Spark缺乏数据加载更新的能力，更缺乏深度下钻与分析的能力。

❑ 宣称可以同时支持多种图查询语言。例如，能同时支持OpenCypher与Gremlin可能意味着它对任何一种语言都没有极致的性能优化，因为数据库与查询语言是一一匹配的，而通用性则需要长时间的性能优化来实现。甚至还有的图数据库可以通过SQL来实现查询与分析，这基本就能断定该系统依旧是传统关系数据库，而且也无法支持图数据库所应该具有的任一优点—灵活性、高效性、深度下钻计算与分析能力。

❑ 一味鼓吹分布式、鼓吹万亿规模，但是却连一个百万量级的数据集都无法深度下钻与高效处理。图计算或图数据库面临的最大挑战并不在于数据存储，而在于计算，特别是复杂计算、深度计算与关联、灵活计算，这才是数仓数湖无法有效解决的。这种挑战有的时候不是通过100台低配服务器解决的，而是应该通过可能10台高配服务器来高效解决的—本质上我们是在回答一个问题：到底是100台1线程的大集群的计算能力高，还是10台10线程的小集群的计算能力高？答案是后者。然而大多数人都会回答错误，因为大多数人忽略了网络延迟与I/O对于分布式系统在数据关联计算时的降维打击。这就是算力引擎在图数据库中必须成为一等公民的最核心原因。所谓高性能计算绝不等于高性能存储，存得多并不意味着算得动。

❑ 基于开源项目或社区版项目包裹。基于开源尽管可以快速地出“成果”，但对于底层代码却是失控的，因为极少有人能真正去吃透别人的底层代码，安全风险隐患无法得到有效控制。至于社区版，更是赤裸裸地对别人知识产权的侵犯，也意味着任何底层功能的改进都不可能实现（通常基于别家项目包裹的产品会出现宣称支持多种查询语言的情况，读者可自行甄别）。

图2-7描述了从源数据到数据应用与产品、围绕数据全链路生命周期的分步流程。

1）多源数据采集：多源、多维、多模态数据采集、ETL/ELT。

2）图数据建模：高维建模，设计并创建点、边Schema。

3）图数据存储与数据治理：数据持久化、元数据库管理、核验、血缘分析等。

4）图计算与分析：图查询逻辑与功能设计与实现（后文将展开讨论）。

5）图算法与映射：图算法调用（通常作为图计算与分析的子集存在）。

6）图谱管理与可视化：集成化、图谱化、可视化数据管理与展示，以及二次开发。

7）商务智能与决策：可看作包含以上所有步骤。

8）图应用与产品：可看作以上7条的超集。

以上可以看作大数据应用视角下图计算与分析结合数据科学的完整链路，涉及数据建模、存储与治理、计算与分析、算法与映射、二次开发与应用场景等核心功能模块。

提及数据科学与大数据分析，人们很自然地会联想到商业智能（Business Intelligence，BI）。BI使用统一的衡量标准来评估企业的过往绩效指标，并用于帮助制定后续的业务规划。常见的BI组件一般包括：

1）建立KPI（Key Performance Index，关键绩效指标）以明确面向所服务用户的功能目标。

2）多维数据的汇聚、去正则化、标记、标准化等。

3）实时报表生成、报警等。

4）处理结构化、简单数据集为主，而发展的趋势是集成越来越多源、复杂的数据集，并进行更深度的计量、下钻、关联分析。

5）集成统计学分析模块与概率模型模拟等功能。发展的趋势还包括集成AI、图嵌入算法等。

BI通常会在底层依赖某种数据处理（如ETL，数据抽取、转换、装载）架构，如数据仓库等。随着大数据技术的发展，BI系统正在越来越多地拥抱诸如内存计算（如IMDG数据库技术）、实时图计算或图数据库等新事物，归根结底是为了更高的数据处理效率、更深的数据处理能力、更灵活的数据建模方式，以及对于真实业务挑战的更真实的还原方式，而图计算显然是一个可以同时满足以上限定条件的答案。

数据科学则可以通过科学的方法论来指导实现BI系统中的预测分析、数据挖掘等功能。数据科学使用统计分析、模式识别、机器学习、深度学习、图计算等技术，对获取到的数据中的信息形成推断及洞察力。相关方法包括回归分析、关联规则计算（如风险传导路径分析、链路分析、购物篮分析）、优化技术和仿真（如蒙特卡罗仿真用于构建场景结果）。在BI系统的基础上，数据科学又可为其增添如下组件与功能：

❑ 结构化/非结构化数据、多种类型数据源、超大数据集。

❑ 优化模型、预测模型、预报、统计分析模型等。

数据科学的发展从分析复杂度与价值两个维度看，可分为3种境界、5个阶段（图2-8）。3种境界分别如下：

1）后知后觉—传统的BI，滞后的延时分析。

2）因地制宜—实时化分析。

3）未卜先知—预测性分析。

图2-8所示的5个阶段与3种境界匹配关系如下：

❑ 后知后觉—描述性+诊断性

❑ 因地制宜—描述性+诊断性+指示性+（部分）预测性

❑ 未卜先知—描述性+诊断性+预测性+指示性+抢先式（基于预测的行动指南）

这5个阶段自上而下实现的复杂度越来越高，毕竟每向前一个阶段，所涵盖的阶段性能力就越完整，价值也越大，这也是为什么越来越多的企业、政府机构要把大数据科学驱动的大数据分析引入并应用到BI、智慧城市等广泛的领域中来。

与大数据处理与分析项目中通常需要多种角色类似，依托图计算技术，同样需要行业问题专家（Subject Matter Expert, SME）、数据分析专家、建模工程师、大数据系统专家等一众人才。区别在于，建模工程师需要摆脱传统的二维表思维束缚，掌握用图数据的高维建模，以及掌握如何进行高效的图分析，在什么场景下用何种图算法来实现更低的成本与更高的回报率。

数据科学属于典型的把多学科知识集于一身的实践，图2-9示意了这种融合。

1）行业经验：对垂直领域的深刻理解。

2）产品开发能力：能够将数学模型转换为可在图数据处理平台上运行的代码，还能设计、实现和部署统计模型和数据挖掘方法等，最终形成产品或解决方案。

3）数理统计知识：能够以数学、统计学模型、算法（如图算法、机器学习、深度学习等）来抽象业务需求与挑战。

我们看到国内大量的银行只能把产品开发能力外包，原因在于业务人员缺乏开发能力，而那些号称有自研能力的大型银行，业务与科技部门也经常被各种问题困扰，其根本原因在于业务与科技之间没有融会贯通，缺少具备“三江交汇”式数据科学分析能力的专业人员。

数据科学是一个新兴的领域。数据分析专家负责为复杂的业务问题建模，运用业务洞察力找到新的商业机遇。对于这种能够从海量数据中提取有用信息，再从信息中提炼出具有高度概括性与指导意义的知识、智慧甚至转变为可以自动化智能（例如图增强智能或图AI）的新型人才，可以预见会受到来自市场越来越多的青睐。