large graph挖掘的技术基础 转

http://www.cnblogs.com/sing1ee/archive/2012/11/18/2776178.html

我一直在做社交网络的挖掘工作，深感目前的一些技术并不能满足社交挖掘的需要。我并没有用过太多的工具，而且图计算的平台也没有用过，涉及到大规模数据的离线分析，主要是依赖hadoop。不过，这并不妨碍，我从挖掘需求的角度来探讨：社交挖掘到底需要哪些技术基础，需要一些什么样的工具。

题目中有一个词：large graph。也有很多人认为是big graph。我之所以改变称谓，主要的原因在我前面的博客中有体现。因为big data中的个体之间，往往具有关系，这个样就组成了一个graph，并且这是个超大的graph。元数据信息要比单纯的big data要高几个量级。所以，为了进一步体现graph之大，我称之为large graph。到底于多大呢？我以新浪微博为例来说明（其实新浪微博在这些large graph中，目前算比较小的）。新浪微博号称4亿的用户，那么用户关系有多少呢？我估计在大概在300亿-400亿。我们在处理社交网络的时候，绝大多数是要和边（也就是关系）打交道的，那这样的一个规模，如何高效存储、计算对挖掘效果的影响，是非常直接的。如果这是一个面试题，大家该如何分析并给出方案呢。

首先根据自己之前做挖掘的一些经验，总结一下，在large graph上，要进行哪些操作：

1. 随机访问：
   1. 读取一个节点的邻居（在微博中，就是读取关注或者粉丝，如何读取粉丝？？）
   2. 读取两个节点之间的关系
2. 顺序访问：
   1. 图的遍历：宽度优先，深度优先等
   2. 最短路径
3. 其他分析：介数计算等

这个是我在挖掘过程中，主要涉及的操作，而且要针对不同的访问分析需求，速度要快。如果要求某个计算平台，能够全部满足，并且速度都很快，那是不现实的。所以，针对特定功能需求，特殊的去优化性能。比如，我在挖掘过程中有一个特定的需求：快速判断两个人之间的关系，要在尽可能短的时间内，完成百万次的判断。这个为基础计算平台的设计，提出了一个直接的挑战。

在big data出来的时候，相伴着NoSQL也火了起来。这都是相辅相成的，数据多了，自然就需要适合的存储技术，那一台及其无法存储，那么直接的想法就是划分，多台进行存储。可是关系如何划分呢？

这个要从large graph的分析开始，large graph有哪些性质，这些性质对快速存取、快速计算都有哪些影响呢？

1. 幂律分布
   1. 首先是正向的影响。这个性质的意思直白一点说，就是粉丝多的人比较集中，很少。更多的是长尾的、粉丝比较少的用户。这个可以帮助我们在计算过程中，合理的做一些剪枝。
   2. kv数据之所以可以采用NoSQL，进行划分存储的主要原因是，它可以均匀的划分，让每台机器的负载都近乎均衡。但是关系数据呢？这个幂律分布直接击碎了按人划分，存储关系的美梦。这是绝对不会均匀的。少数机器的数据很大，其它的机器数据很少。
2. 小世界特性
   1. 这个很直接，就是两个人之间的最短路径很短。最直接的体现了六度分离的理论。
   2. 在做一些图分析的时候，代价很大，涉及的节点很多。
3. 社团结构
   1. 社团结构本身是很重要的性质。我之前的博客有详细的介绍。
   2. 社团结构的存在，直接导致了图划分的问题难度增加。要保证均匀，保证划分之间边最少。社团结构是个很大的障碍。

上面的三个特性，使得图划分的难度大大增加。但是，由于数据量级的剧增，图的划分还是非常重要的选择。目前已经有的一些算法，KL，metis（目前state-of-the-art的方法）等，在处理百万、千万级节点的网络时，还可应付。但是亿级节点呢？十亿级呢？其实，划分是个核心，是重中之重，存储、计算都依赖这个。否则，就会有大量的冗余，更多的IO消耗。

需求就在我们面前。现在产生巨大关系数据的公司已经产生，Facebook、微博等。但是能够处理这些数据的公司呢？可以断言，能够大规模挖掘关系数据的公司，必将是下一个Google。这是一波浪潮，让我们加入进去，一起冲浪。

【完】

【思考题】

1亿节点，100亿关系，如何迅速判断连个节点是否有边？节点用整数唯一标识。如果大家对这个问题感兴趣，可以和我一起探讨，解决实际问题。