Question

查看outerJoinVertices

的来源

我想知道这是一个错误还是一个功能

override def outerJoinVertices[U: ClassTag, VD2: ClassTag]
      (other: RDD[(VertexId, U)])
      (updateF: (VertexId, VD, Option[U]) => VD2)
      (implicit eq: VD =:= VD2 = null): Graph[VD2, ED] = {
    // The implicit parameter eq will be populated by the compiler if VD and VD2 are equal, and left
    // null if not
    if (eq != null) {
      vertices.cache() // <===== what if I wanted it serialized? 
      // updateF preserves type, so we can use incremental replication
      val newVerts = vertices.leftJoin(other)(updateF).cache()
      val changedVerts = vertices.asInstanceOf[VertexRDD[VD2]].diff(newVerts)
      val newReplicatedVertexView = replicatedVertexView.asInstanceOf[ReplicatedVertexView[VD2, ED]]
        .updateVertices(changedVerts)
      new GraphImpl(newVerts, newReplicatedVertexView)
    } else {
      // updateF does not preserve type, so we must re-replicate all vertices
      val newVerts = vertices.leftJoin(other)(updateF)
      GraphImpl(newVerts, replicatedVertexView.edges)
    }
  }

问题

如果我的图表/已加入顶点已经通过其他StorageLevel进行了缓存（例如MEMORY_ONLY_SER） - 这是导致org.apache.spark.graphx.impl.ShippableVertexPartitionOps ... WARN ShippableVertexPartitionOps: Joining two VertexPartitions with different indexes is slow.的原因吗？
如果是这种情况，那么这是Spark中的一个错误（这是从1.3.1开始）吗？如果是这样就找不到JIRA问题（但我看起来并不太难......）
为什么修复此方法不是一个新的StorageLevel？
这有什么办法？（我能想到的一个是创建一个带有vertices.join（otherVertices）和originalGraph.edges等的新图表......但感觉不对......

Answer 1

嗯，我认为这实际上不是一个错误。

查看VertexRDD的代码，它会覆盖缓存方法，并使用用于创建此顶点的原始StorageLevel。

  override def cache(): this.type = {
    partitionsRDD.persist(targetStorageLevel)
    this
  }

加入顶点时，我是否被迫使用MEMORY_ONLY缓存？

1 个答案: