GraphX 图数据建模和存储

背景

简单分析一下GraphX是怎么为图数据建模和存储的。

入口

可以看GraphLoader的函数,

def edgeListFile(
      sc: SparkContext,
      path: String,
      canonicalOrientation: Boolean = false,
      numEdgePartitions: Int = -1,
      edgeStorageLevel: StorageLevel = StorageLevel.MEMORY_ONLY,
      vertexStorageLevel: StorageLevel = StorageLevel.MEMORY_ONLY)
    : Graph[Int, Int]
  1. path可以是本地路径(文件或文件夹),也可以是hdfs路径,本质上是使用sc.textFile来生成HadoopRDD的,numEdgePartitions是分区数。
  2. Graph的存储是分EdgeRDD和VertexRDD两块,可以分别设置StorageLevel。默认是内存。
  3. 这个函数接受边文件,即’1 2’, ‘4 1’这样的点到点的数据对组成的文件。把这份文件按分区数和存储level转化成一个可以操作的图。

流程

  1. sc.textFile读文件,生成原始的RDD
  2. 每个分区(的计算节点)把每条记录放进PrimitiveVector里,这个结构是spark里为primitive数据优化的存储结构。
  3. PrimitiveVector里的数据一条条取出,转化成EdgePartition,即EdgeRDD的分区实现。这个过程中生成了面向列存的结构:src点的array,dst点的array,edge的属性array,以及两个正反向map(用于对应点的local id和global id)。
  4. EdgeRDD 做一次count触发这次边建模任务,真正persist起来。
  5. EdgePartition去生成一个RoutingTablePartition,里面是vertexId到partitionId的对应关系,借助RoutingTablePartition生成VertexRDD
  6. EdgeRDDVertexRDD生成Graph。前者维护了边的属性、边两头顶点的属性、两头顶点各自的global vertexID、两头顶点各自的local Id(在一个edge分区里的array index)、用于寻址array的正反向map。后者维护了点存在于哪个边的分区上的Map。

以下是代码,比较清晰地展现了内部存储结构。

private[graphx]
class EdgePartition[
    @specialized(Char, Int, Boolean, Byte, Long, Float, Double) ED: ClassTag, VD: ClassTag](
    localSrcIds: Array[Int],
    localDstIds: Array[Int],
    data: Array[ED],
    index: GraphXPrimitiveKeyOpenHashMap[VertexId, Int],
    global2local: GraphXPrimitiveKeyOpenHashMap[VertexId, Int],
    local2global: Array[VertexId],
    vertexAttrs: Array[VD],
    activeSet: Option[VertexSet])
  extends Serializable {
/**
 * Stores the locations of edge-partition join sites for each vertex attribute in a particular
 * vertex partition. This provides routing information for shipping vertex attributes to edge
 * partitions.
 */
private[graphx]
class RoutingTablePartition(
    private val routingTable: Array[(Array[VertexId], BitSet, BitSet)]) extends Serializable {

细节

分区摆放

EdgeRDD的分区怎么切分的呢?因为数据是根据HadoopRDD从文件里根据offset扫出来的。可以理解为对边数据的切分是没有任何处理的,因为文件也没有特殊排列过,所以切分成多少个分区应该就是随机的。

VertexRDD的分区怎么切分的呢?EdgeRDD生成的vertexIdToPartitionId这份RDD数据是RDD[VertexId, Int]型,它根据hash分区规则,分成和EdgeRDD分区数一样大。所以VertexRDD的分区数和Edge一样,分区规则是Long取hash。

所以我可以想象的计算过程是:

对点操作的时候,首先对vertexId(是个Long)进行hash,找到对应分区的位置,在这个分区上,如果是内存存储的VertexRDD,那很快可以查到它的边所在的几个Edge分区的所在位置,然后把计算分到这几个Edge所在的分区上去计算。

第一步根据点hash后找边分区位置的过程就类似一次建好索引的查询。

配官方图方面理解:

高效数据结构

对原生类型的存储和读写有比较好的数据结构支持,典型的是EdgePartition里使用的map:

/**
 * A fast hash map implementation for primitive, non-null keys. This hash map supports
 * insertions and updates, but not deletions. This map is about an order of magnitude
 * faster than java.util.HashMap, while using much less space overhead.
 *
 * Under the hood, it uses our OpenHashSet implementation.
 */
private[graphx]
class GraphXPrimitiveKeyOpenHashMap[@specialized(Long, Int) K: ClassTag,
                              @specialized(Long, Int, Double) V: ClassTag](

以及之前提到的vector

/**
 * An append-only, non-threadsafe, array-backed vector that is optimized for primitive types.
 */
private[spark]
class PrimitiveVector[@specialized(Long, Int, Double) V: ClassTag](initialSize: Int = 64) {
  private var _numElements = 0
  private var _array: Array[V] = _

全文完 :)

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-06 05:41:45

GraphX 图数据建模和存储的相关文章

图数据存储初见

在<图数据挖掘——基本概念>一文中详细的讲了图数据的基本概念,并在<图数据挖掘之图信息获取及存储>一文中描述了图的信息获取,但并没有对图数据的存储进行详细的介绍,该篇将就图数据存储给大家介绍一下,如有不对之处希望多多指出! 我们都知道图数据主要的信息是节点.边和权重,如何存储这些信息是至关重要的,同时采用何种存储结构对图的还原影响非常大.今天将介绍两种图的存储方式:1)关系数据库存储 2)关系数据库+文本. 1)关系数据库存储 如上面的图,我们知道其中有V1.V2.V3. V4.

《Entity Framework 6 Recipes》翻译系列 (3) -----第二章 实体数据建模基础之创建一个简单的模型 (转)

第二章 实体数据建模基础 很有可能,你才开始探索实体框架,你可能会问“我们怎么开始?”,如果你真是这样的话,那么本章就是一个很好的开始.如果不是,你已经建模,并在实体分裂和继承方面感觉良好,那么你可以跳过本章. 本章将带你漫游使用实体框架建模的基本实例,建模是实体框架的核心特性,同时也是区别实体框架和微软早期的数据访问平台的特性.一旦建好模,你就可以面向模型编写代码,而不用面向关系数据库中的行和列. 本章以创建一个简单概念模型的实例开始,然后让实体框架创建底层的数据库,剩下的实例,将向你展示,如

NoSQL数据建模技术

原文来自“NoSQL Data Modeling Techniques”,由酷壳网陈皓编译<NoSQL数据建模技术>.这篇文章看完之后,你可能会对NoSQL的数据结构会有些感觉.我的感觉是,关系型数据库想把一致性,完整性,索引,CRUD都干好,NoSQL只干某一种事,但是牺牲了很多别的东西.总体来说,我觉得NoSQL更适合做Cache. 下面是正文: NoSQL数据库经常被用作很多非功能性的地方,如,扩展性,性能和一致性的地方.这些NoSQL的特性在理论和实践中都正在被大众广泛地研究着,研究的

数据仓库建设中的数据建模方法(转)

简介: 本文的主要内容不是介绍现有的比较流行的主要行业的一些数据模型,而是将笔者在数据仓库建设项目中的一些经验,在这里分享给大家.希望帮助大家在数据仓库项目建设中总结出一套能够合乎目前业界规范的,满足大部分行业数据仓库建设标准的一种方法. 所谓水无定势,兵无常法.不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的.目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外,也有各自的针对某个行业的数据模型. 例如,在

浅谈数据仓库建设中的数据建模方法

所谓水无定势,兵无常法.不同的行业,有不同行业的特点,因此,从业务角度看,其相应的数据模型是千差万别的.目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR,这两家公司的除了能够提供较为强大的数据仓库平台之外,也有各自的针对某个行业的数据模型.       例如,在银行业,IBM 有自己的 BDWM(Banking data warehouse model),而 NCR 有自己的 FS-LDM 模型.在电信业,IBM 有 TDWM(Telecom Data warehouse model)

NoSQL 数据建模技术(转)

本文转载自:http://coolshell.cn/articles/7270.html ================================================ 全文译自墙外文章"NoSQL Data Modeling Techniques",译得不好,还请见谅.这篇文章看完之后,你可能会对NoSQL的数据结构会有些感觉.我的感觉是,关系型数据库想把一致性,完整性,索引,CRUD都干好,NoSQL只干某一种事,但是牺牲了很多别的东西.总体来说,我觉得NoSQL

用户画像数据建模方法

作者:百分点技术总监郭志金 摘自:百分点(ID: baifendian_com) 从1991年Tim Berners-Lee发明了万维网(World Wide Web)开始,到20年后2011年,互联网真正走向了一个新的里程碑,进入了“大数据时代”.经历了12.13两年热炒之后,人们逐渐冷静下来,更加聚焦于如何利用大数据挖掘潜在的商业价值,如何在企业中实实在在的应用大数据技术.伴随着大数据应用的讨论.创新,个性化技术成为了一个重要落地点.相比传统的线下会员管理.问卷调查.购物篮分析,大数据第一次

MongoDB实战-面向文档的数据(找到最合适的数据建模方式)

前一段时间一直研究通过Ruby操作MongoDB数据库,在学习的过程中也分享了自己学习成长的过程,撰写了包含两篇入门操作文章和十二篇进阶文章.本篇文章开始,我们将进入MongoDB的实战操作流程,MongoDB这一非关系型数据库-是一个文档型数据库,存储的是面向文档的数据. 如何在MongoDB数据库中使用schema 设计数据库schema是在已知数据库系统特性.数据本质以及应用程序需求的情况下为数据集选择最佳表述的过程.传统的关系型数据库RDBMS中鼓励使用正规化的数据模型,从而确保数据的可

[Elasticsearch] 数据建模 - 处理关联关系

数据建模(Modeling Your Data) ES是一头不同寻常的野兽,尤其是当你来自SQL的世界时.它拥有很多优势:性能,可扩展性,准实时的搜索,以及对大数据的分析能力.并且,它很容易上手!只需要下载就能够开始使用它了. 但是它也不是魔法.为了更好的利用ES,你需要了解它从而让它能够满足你的需求. 在ES中,处理实体之间的关系并不像关系型存储那样明显.在关系数据库中的黄金准则 - 数据规范化,在ES中并不适用.在处理关联关系,嵌套对象和父子关联关系中,我们会讨论几种可行方案的优点和缺点.