大数据图数据库之数据分片

节选自《大数据日知录:架构与算法》十四章,书籍目录在此

对于海量待挖掘数据,在分布式计算环境下,首先面临的问题就是如何将数据比较均匀地分配到不同的服务器上。对于非图数据来说,这个问题解决起来往往比较直观,因为记录之间独立无关联,所以对数据切分算法没有特别约束,只要机器负载尽可能均衡即可。由于图数据记录之间的强耦合性,如果数据分片不合理,不仅会造成机器之间负载不均衡,还会大量增加机器之间的网络通信(见图14-5),再考虑到图挖掘算法往往具有多轮迭代运行的特性,这样会明显放大数据切片不合理的影响,严重拖慢系统整体的运行效率,所以合理切分图数据对于离线挖掘类型图应用的运行效率来说非常重要,但是这也是至今尚未得到很好解决的一个潜在问题。

对于图数据的切片来说,怎样才是一个合理或者是好的切片方式?其判断标准应该是什么?就像上面的例子所示,衡量图数据切片是否合理主要考虑两个因素:机器负载均衡以及网络通信总量。如果单独考虑机器负载均衡,那么最好是将图数据尽可能平均地分配到各个服务器上,但是这样不能保证网络通信总量是尽可能少的(参考图14-5右端切割方式,负载比较均衡,但是网络通信较多);如果单独考虑网络通信,那么可以将密集连通子图的所有节点尽可能放到同一台机器上,这样就有效地减少了网络通信量,但是这样很难做到机器之间的负载均衡,某个较大的密集连通子图会导致某台机器高负载。所以,合理的切片方式需要在这两个因素之间找到一个较稳妥的均衡点,以期系统整体性能最优。

下面介绍两类从不同出发点切割图数据的方法,并分别介绍典型的具体切分算法及其对应的数学分析,首先需要强调一点:在选择具体的切分算法时并非越复杂的算法越可能在实际系统中被采纳,读者可以思考其中的道理,在后面会给出解答。

14.3.1  切边法(Edge-Cut)

现在面临的问题是:给定一个巨大的图数据和p台机器,如何将其切割成p份子图?解决这个图切割问题有两种不同的思路。

切边法代表了最常见的一种思路,切割线只能穿过连接图节点的边,通过对边的切割将完整的图划分为p个子图。图14-6代表将7个节点的图分发到3台机器上,左端展示了切边法方式,图节点的编号代表节点被分发到的机器编号。

          

通过切边法切割后的图数据,任意一个图节点只会被分发到一台机器,但是被切割开的边数据会在两台机器中都保存,而且被切割开的边在图计算的时候意味着机器间的远程通信。很明显,系统付出的额外存储开销和通信开销取决于被切割开的边的数量,图切割时通过的边越多,则系统需额外承载的存储开销和通信开销越高。

前文有述,衡量图数据分片合理与否有两个考虑因素:负载均衡和机器通信量,所以对于切边法来说,所有具体的切割算法追求的目标不外是:如何在尽可能均衡地将图节点分配到集群中的不同机器上这一约束下,来获得最小化切割边数量。

即在每台机器被分发到的节点尽可能均匀的条件约束下,求切割边最少的方法。其中,|V|/p代表所有的节点被p台机器均分所得数值,l≥1代表不平衡调节因子,通过调节l的大小可以控制节点分配的均匀度,当其值为1时,要求完全均分,其值越大,允许的不均衡程度越高。

从上述形式化描述可以看出,lamda约等于1的时候,这个问题本质上是一个图切割中的均衡p路分区(Balanced p-way Partitioning)问题,解决这个问题有很多相关研究(有兴趣的读者可以阅读本章参考文献[4]),但是由于图切割算法的时间复杂度较高,基本不太适合处理大规模数据,所以在真实的大规模数据场景下很少被采用。

在实际的图计算系统中,经常使用的策略是节点随机均分法,即通过哈希函数将节点均分到集群的各个机器中,并不仔细考虑边切割情况。Pregel和GraphLab都采用了这种策略。这种方法的优点是快速、简单且易实现,但是从定理14.1可以证明这种方法会将图中绝大多数的边都切开。

由定理14.1可知,假设集群包含10台机器,则被切割的边比例大约为90%,即90%的边会被切开,而如果包含100台机器,则99%的边会被切开。可见,这种切分方式是效率很低的一种。

14.3.2  切点法(Vertex-Cut)

切点法代表另外一种切割图的不同思路。与切边法不同,切点法在切割图的时候,切割线只能通过图节点而非边,被切割线切割的图节点可能同时出现在多个被切割后的子图中。图14-6右侧是切点法示意图,从图中可看出,图中心的节点被切割成三份,也就是意味着这个节点会同时出现在被切割后的三个子图中。

与切边法正好相反,切点法切割后的图中,每条边只会被分发到一台机器上,不会重复存储,但是被切割的节点会被重复存储在多台机器中,因此,同样存在额外存储开销。另外,如此切割带来的问题是:图算法在迭代过程中往往会不断更新图节点的值,因为某个节点可能存储在多台机器中,也即存在数据多副本问题,所以必须解决图节点值数据的一致性问题。对这个问题,在后面讲解PowerGraph系统时,会给出一种典型的解决方案。

那么,既然切点法图中的边都没有被切割,机器之间是否就无须通信开销了呢?事实并非如此,在维护被切割的图节点值数据一致性时仍然会产生通信开销。所以,对于切点法来说,所有具体算法追求的合理切分目标是:如何在尽可能均匀地将边数据分发到集群的机器中这个约束条件下,最小化被切割开的图节点数目。

即在每台机器被分发到的边尽可能均匀的条件约束下,求平均副本数最少的方法。其中,|E|/p代表所有边被p台机器均分所得数值,l≥1代表不平衡调节因子,通过调节l的大小可以控制边分配的均匀度,当其值为1时,要求完全均分,其值越大,允许的不均衡程度越高。

同样,由于采用复杂图切割算法的时间复杂度太高,所以实际系统中最常用的还是边随机均分

现实世界中的大多数图的边分布都遵循power law法则,理论和实践已经证明,对于遵循这一法则的图数据来说,属于切点法的边随机均分法要比切边法里的节点随机均分法强,其计算效率要高出至少一个数量级。所以总体而言,对于一般情形的图数据,采取切点法要明显优于切边法。

请思考:为何不是越复杂、有效的切分算法越受欢迎?

解答:一般来说,图挖掘算法分为两个阶段。

阶段一:集中式图数据切分与分发;阶段二:分布式图计算。

如果采用复杂的图切割算法,则系统负载均衡好,机器间通信量较少,所以第二阶段运行的效率高,但是采用复杂算法不仅开发成本高,在第一阶段付出的时间成本也很高,甚至因此付出的时间成本要高于在第二阶段产生的效率收益,所以选择何种切分算法也需要有全局的效率权衡。

时间: 2024-10-05 23:32:00

大数据图数据库之数据分片的相关文章

大数据图数据库之TAO数据库

节选自<大数据日知录:架构与算法>十四章 14.1.2  TAO图数据库 Facebook是目前世界上最著名的社交网站,如果从数据抽象的角度来看,Facebook的社交图不仅包括好友之间的关系,还包括人与实体以及实体与实体之间的关系,每个用户.每个页面.每张图片.每个应用.每个地点以及每个评论都可以作为独立的实体,用户喜欢某个页面则建立了用户和页面之间的关系,用户在某个地点签到则建立了用户和地点之间的关系--如果将每个实体看作是图中的节点,实体之间的关系看作是图中的有向边,则Facebook的

大数据图数据库之离线挖掘计算模型

/* 版权声明:可以任意转载,转载时请务必标明文章原始出处和作者信息 .*/            author: 张俊林 节选自<大数据日知录:架构与算法>十四章,书籍目录在此 对于离线挖掘类图计算而言,目前已经涌现出众多各方面表现优秀而各具特点的实际系统,典型的比如Pregel.Giraph.Hama.PowerGraph.GraphLab.GraphChi等.通过对这些系统的分析,我们可以归纳出离线挖掘类图计算中一些常见的计算模型. 本节将常见的计算模型分为两类,一类是图编程模型,另一类

jdbc mysql 取数,突然取不到数据,数据库中有数据

项目用的是jdbc+mysql,局网取数据的时候,数据一切正常,但是传到服务器上以后,曾经是好的 不知道为什么,近期一传就取不到数据,发现android写的也没有问题,至少大体上没有语法问题. 跟踪后发现sql没问题,直接放到mysql中执行有数据. 但是奇了怪了,后来发现了一个就是where 后面没有条件的时候,传入了1=1 然后就取不出来了,我把where 1=1 去掉,或者where 字段='xxxx' 这样就有数据了. 不知道为什么会这样,不过,问题算是解决了.

大数据图数据库之MapReduce用于图计算

/* 版权声明:可以任意转载,转载时请务必标明文章原始出处和作者信息 .*/                 CopyMiddle: 张俊林 节选自<大数据日知录:架构与算法>十四章,书籍目录在此 1.使用Mapreduce进行图计算 使用MapReduce框架来针对大规模图数据进行计算的研究工作相对较少,这主要归结于两方面原因:一方面,将传统的图计算映射为MapReduce任务相对其他类型的很多任务而言不太直观:另一方面,从某种角度讲,使用该分布计算框架解决图计算任务也并非最适宜的解决方案.

30天搞定大数据爬虫项目,数据爬虫、全文检索、数据可视化、爬虫项目监控

好,开始今天的文章. 今天主要是来说一下怎么可视化来监控你的爬虫的状态. 相信大家在跑爬虫的过程中,也会好奇自己养的爬虫一分钟可以爬多少页面,多大的数据量,当然查询的方式多种多样.今天我来讲一种可视化的方法. 关于爬虫数据在mongodb里的版本我写了一个可以热更新配置的版本,即添加了新的爬虫配置以后,不用重启程序,即可获取刚刚添加的爬虫的状态数据. 1.成品图 这个是监控服务器网速的最后成果,显示的是下载与上传的网速,单位为M.爬虫的原理都是一样的,只不过将数据存到InfluxDB的方式不一样

大数据量数据库优化 - CodeMain - 博客园

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

大数据量数据库优化

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

【基于WinForm+Access局域网共享数据库的项目总结】之篇二:WinForm开发扇形图统计和Excel数据导出

篇一:WinForm开发总体概述与技术实现 篇二:WinForm开发扇形图统计和Excel数据导出 篇三:Access远程连接数据库和窗体打包部署 [小记]:最近基于WinForm+Access数据库完成一个法律咨询管理系统.本系统要求类似网页后台管理效果,并且基于局域网内,完成多客户端操作同一数据库,根据权限不同分别执行不同功能模块.核心模块为级联统计类型管理.数据库咨询数据扇形统计.树的操作.咨询数据的管理.手写分页.Excel数据的导出.多用户操作服务器数据等.并支持多用户同时操作,远程连

大数据时代数据库-云HBase架构&amp;生态&amp;实践

摘要: 2018第九届中国数据库技术大会,阿里云高级技术专家.架构师封神(曹龙)带来题为大数据时代数据库-云HBase架构&生态&实践的演讲.主要内容有三个方面:首先介绍了业务挑战带来的架构演进,其次分析了ApsaraDB HBase及生态,最后分享了大数据数据库的实际案例. 2018第九届中国数据库技术大会,阿里云高级技术专家.架构师封神(曹龙)带来题为大数据时代数据库-云HBase架构&生态&实践的演讲.主要内容有三个方面:首先介绍了业务挑战带来的架构演进,其次分析了A