图数据库 | 21、如何规划、评测和优化图系统（中）

书接上文，图数据库如何做容量规划呢？

图系统的容量一直是个非常有趣的问题。笔者试图从两个角度来帮助读者厘清并抓住系统容量规划的核心，核心问题解决了，其他问题自然迎刃而解。

·受大数据流派影响而追求万亿级图系统；

·受传统数据库影响对于数据容量的计数偏差。

受到大数据浪潮的洗礼，很多技术人员在刚开始接触图系统的时候，会很容易把Hadoop/HDFS的理念套在图系统上面，并且直接把系统的数据容量预期设置为“万亿”量级，尽管现在手头的数据在可预见的未来连1亿都没有。

关于图的容量大小，本质上取决于业务，或者说是真实世界的挑战用何种数据、何种建模方式来解决，而不是能否去构建万亿级图系统。

这个问题如果搞反了，一定是本末倒置。如果用Hadoop（或Spark）的模式去做图系统，当然可以存储万亿级的数据，老夫在前面的内容中已经多次提及相关的议题，然而这种系统能存下数据却未必能完成计算，这才是致命的。

换言之，图系统解决的挑战是对多维数据的关联、穿透、下钻和聚合，并在更短的时间、更低的（硬件）资源消耗情况下完成任务，这些任务都是计算驱动的，以计算为核心的。

笔者发现业界在近些年有一个趋势，就是在突出存储与计算分离的同时，又忽略了计算的时效性，并且把算力完全等同于底层硬件的罗列、叠加，而忽略了软件能否释放硬件算力的能力！

简而言之，没有软件对底层算力的充分并发、充分释放，存得下再多的数据，也是徒劳。图系统首先要解决的是计算，然后再是去匹配与之相符的存储，最终完整的系统一定是缺一不可。

另一方面，万亿的数据集，即便它是真实存在的，如果任何系统把上万亿量级的数据都无差别对待，只有两种可能：

·系统的性能很糟糕（低性能）​；

·系统造价成本极高（高性能）​。

前者指的就是HDFS模式的系统，而后者则会采用非常昂贵的硬件设备来实现。如果数据集是万亿量级，任何明智的系统架构设计中都会对数据进行分层处理。

例如，100亿的数据是热数据，1000亿的数据是温数据，9000亿的数据是冷数据。这样设计的原因是要平衡成本与性能，我们如果可以把所有的数据都塞进内存，其性能可能会高于全部数据都在硬盘上至少100倍，但是内存比硬盘贵了很多倍，因此我们只能选择平衡（Spark系统之所以比Hadoop快并且近几年更为流行，除了架构和代码效率提升外，很大一部分原因是内存利用率更高，另一部分是因为内存价格在过去10年间逐渐便宜）​。图1示意了这种典型的数据按照热度分层存储的概念。

万亿数据全是热数据，不但不现实，也不符合真实的业务情况，还有一个方面就是这种图的建模、构图一定没有充分的优化。

简而言之，很多所谓的千亿、万亿规模图，实际上实体的规模仅有不到10亿，大量的实体都应该作为点、边的属性存在，并且大量的边都是“无效边”​（有的图数据库仅支持单边图模式，例如两个用户账户之间会存在多笔交易，但是每笔交易无法以边的形式存在，只能用顶点来表达交易，进而需要在交易顶点与账户顶点间形成2倍的边，这种单边图就会形成3倍数量的点边集合）​。

即便是在社交网络场景中，以全球最大的社交网络Facebook与微信为例，前者用户数多达30亿，后者超过12亿，如果我们设计一张图的目标是把用户间的每一句话、每一笔转账、每一个红包都作为一条边，那么这张图的确可达万亿级，甚至百万亿级。但是这样构图既不高效，也忽略了图系统的核心价值——对元数据及元数据间所形成的关联网络的价值抽取。

什么样的数据能够叫元数据呢（顶点为主，边为辅）​？在传统数据库中，那些与主键、外键所对应的数据或可以与之1:1匹配的字段，通常可以作为元数据，例如持卡人、SNS用户（或用户ID）​、账户等。哪些数据没有作为元数据的价值呢？比如一条聊天语句、一段文字、一条语音、一张配图等，这些数据更适合作为辅助数据，例如元数据的属性字段，或者作为时序或列数据进行分库存储，即作为温数据进入可以存储海量数据的列数据库或数据仓库之中，而图系统则作为在线热数据的存储引擎。

目前全球最大的金融机构的用户规模在3亿～4亿量级，账户+卡号在10亿量级，商户POS机在千万量级，交易每年在几十亿量级，即便是把电话号码、邮件、亲属关系放入一张图内，这种图也最大就到百亿量级。如果把10年的数据都存储，那么我们可以预期这样的图达到了千亿规模。然而，这种思维方式是数仓甚至数湖化的，按照这种存储逻辑，数据一旦入仓、入湖，旋即“沉底”​，不大可能作为一种线上系统使用。

如果把上面这个具体例子中的10年最多1000亿数据分层来提供服务，一种分解思路如下：

·第一层：过去1～3个月的数据进入线上图系统，数据规模约10亿级，支持低延迟、高并发查询操作；

·第二层：过去4～12个月的数据进入图数仓系统，可以提供向线上系统快速迁移，并进行近实时的批处理操作；

·第三层：过去13～120个月的数据进入图数湖系统，可以提供向数仓快速迁移及大规模批处理操作。

当然，另一种分解思路是采用图分片或分区的思路，让全部10年1000亿的数据都进入线上系统，该系统采用大规模水平分布式架构，其规模相当于上面的列表中第一层系统的至少40～120倍。显然，这套水平分布式系统搭建与维护的复杂度、成本指数级高于前面数据分层系统搭建的思路。

容量规划的另一个误区，就是对于实际可能需要构建的图的规模的误判。通常都是受到传统的数据库或数仓中的数据在进行多表关联（join）查询时会出现“笛卡尔乘积”问题的影响。

老夫曾经在和一家做知识图谱的公司探讨其服务客户的“惊为天人”的图规模时，发现它们把SQL数据库中几张表的行数进行了简单的乘积，得到了432万亿的图规模，而实际上，它的实体只有不到2万个，其中包含4000家公司、3000个财务指标、跨度30年（120个季度）​、30个行业、10 000个高管，把这些全都相乘得出432万亿这样一个“天文数字”​。真正惊人的是，这些实体间如果全部关联可以产生万亿级别的关系，如果通过多步的深度关联，甚至可以产生无穷多的（路径）关系。把这种图算作万亿级图，可以算是一种典型的无中生有了。

我们总结一下图系统的容量规划的要旨：

1）根据你的实际业务需求来定夺到底哪些数据适合作为实体，哪些作为关系，哪些作为属性；

2）以上这些在不同的场景下不是一成不变的，是可以相互转换的；

3）图的容量规划为，以现今的数据量级（点和边的实际数量）乘以，其中g%为预计每年的数据量增长百分比，N为预计该系统的服务年限。

如果1套系统预计服务10年，每年有20%的数据增长，第一年有1亿的数据量，10年后有大约5亿数据。

实际上，绝大多数客户并没能达到亿级的数据量，那么规划万亿级图系统听起来有些好高骛远——能存与能算并且能以较低的成本完成运算是个挑战拾级而上的问题，而实际现有市场上的号称支持万亿级图系统解决方案的架构还在以数仓为中心的思路构建——管存不管算。不能支持深度计算的图系统没有其存在的合理性，因为图颠覆传统的要素之一就是可以进行深度的下钻、穿透、关联分析。

无深度，不成图！

· END ·

（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）