码迷,mamicode.com
首页 > 其他好文 > 详细

Spark的TorrentBroadcast:实现

时间:2015-08-19 09:25:12      阅读:143      评论:0      收藏:0      [点我收藏+]

标签:

序列化和反序列化

前边提到,TorrentBroadcast的关键就在于特制的序列化和反序列化方法。1.1版的TorrentBroadcast实现了自己的readObject和writeObject方法,但是1.4.1版的TorrentBroadcast没有实现自己的readObject方法,那么它是如何进行序列化和反序列化的呢?

// obj就是被广播的对象
private val numBlocks: Int = writeBlocks(obj) override protected def getValue() = { _value } @transient private lazy val _value: T = readBroadcastBlock()

可以认为TorrentBroadcast对象经过了三个主要阶段的处理:构造器,序列化,反序列化

构造器

在构造TorrentBroadcast对象时,numBlocks会被初始化,此时writeBlocks会被执行。writeBlocks会执行把obj序列化,分块,存储进BlockManager等操作。

而_value域是lazy的,因此在TorrentBroadcast对象初始化时,_value不会初始化,readBroadcastBlock也不会执行。

序列化

当在driver端对RDD调用一个action时,会生成Task对象,Task对象引用到的对象会被序列化,然后对每一个task,反序列化一个Task对象。

TorrentBroadcast需要保证被广播的对象不会随Task一起序列化。需要注意以下两点:

private[spark] class TorrentBroadcast[T: ClassTag](obj: T, id: Long)
  extends Broadcast[T](id) with Logging with Serializable {
  ……
}
@transient private lazy val _value: T = readBroadcastBlock()

Scala的构造函数里的参数并不一定会成为对象的字段,像obj这种只是用来构造对象、没有被用于实现方法的构造器参数,不会成为TorrentBroadcast的字段,因此不会被序列化。

而_value尽管引用了被广播的数据,但它是@transient的,因此也不会被序列化。

反序列化

反序列化的关键在于,_value不会被反序列化。因此,如果某个executor没有task使用TorrentBroadcast的value方法,被广播的数据就不会被在这个executor端获取。

实现这种功能的关键在于Scala的lazy val。

首先,考虑这个问题:lazy val可能被多个线程同时访问,这会触发lazy val的初始化,但是需要保证这个初始化的过程就线程安全的,即lazy val只被初始化一次,且初始化的结果对所有线程可见。实现这种行为,最简单的做为是使用this做同步,但是这样的效率会很低,而Scala实现lazy val使用了一种效率更高的方法,但不管怎么做,lazy val比普通的val的访问效率会降低。

举一个Double-checked locking idiom, sweet in Scala!中的例子:

lazy val myLazyField = create();

会被编译成:

   public volatile int bitmap$0;
   private Object myLazyField;

   public String myLazyField() {
        if((bitmap$0 & 1) == 0)
        {
            synchronized(this)
            {
                if((bitmap$0 & 1) == 0)
                {
                    myLazyField = ...
                    bitmap$0 = bitmap$0 | 1;
                }
            }
        }
        return myLazyField;
    }

即通过一个volatile变量来判断这个lazy val是否已经初始化,通过双重检查加锁来做初始化。

现在有了新的问题:

1. 默认的序列化过程是否会触发lazy val被初始化呢?

2. 如果在TorrentBroadcast对象被序列化之前,lazy val被访问,触发了初始化过程,那么被广播的数据相关于作为TorrentBroadcast的一个field,也会被序列化。

问题1的答案是不会触发。问题2的答案_value需要被注明是transient,就像TorrentBroadcast里所做的一样。

所以,在函数中如果经常使用Broadcast.value方法返回的对象时,比如在循环中使用它,最后先在循环外创建一个对这个对象的引用,以减少一些开销。

但是,lazy val的这种线程安全机制对于TorrentBroadcast是浪费的。因为Broadcast变量是随Task一起序列化的,每个线程有自己的Task对象,也就是线程间不共享Broadcast对象。实际上,为了保证同一个JVM上运行的不同task得到同样的被广播的对象,readBroadcastBlock方法是使用TorrentBroadcast这个class做了同步,

下面来看一下把被广播的对象分块存储的过程

将广播的对象分块存储

这一步是在TorrentBroadcast对象初始化时候做的。

由 

val numBlocks: Int = writeBlocks(obj)

 

触发。下面看一下writeBlocks方法

writeBlocks

  private def writeBlocks(value: T): Int = {
    // Store a copy of the broadcast variable in the driver so that tasks run on the driver
    // do not create a duplicate copy of the broadcast variable‘s value.
    SparkEnv.get.blockManager.putSingle(broadcastId, value, StorageLevel.MEMORY_AND_DISK,
      tellMaster = false)
    val blocks =
      TorrentBroadcast.blockifyObject(value, blockSize, SparkEnv.get.serializer, compressionCodec)
    //blocks的类型是Array[ByteBuffer]
    blocks.zipWithIndex.foreach { case (block, i) =>
      SparkEnv.get.blockManager.putBytes(
        BroadcastBlockId(id, "piece" + i),//以BroadcastBlockId为BlockId存储
        block,
        StorageLevel.MEMORY_AND_DISK_SER,
        tellMaster = true)
    }
    blocks.length
  }

 

正如代码中的注释所说的,writeBlocks会首先把被广播的对象用putSingle方法放在driver的BlockManager里,这是为了当在driver运行task时,不会额外创建一个被广播的对象的副本。若没有这一步,在driver端运行task时,会和executor端一样,通过Broadcast对象的value方法新建一个被广播的对象,这就使得driver端有两份这个对象。但实际上driver端运行task的情况并不常见。所以这里最好根据conf判断下是否有必要这么做。

接下来,使用伴生对象的blockifyObject方法把对象分块,得到的结果是一个ByteBuffer的数组。然后把这些块存进BlockManager, 这里有两点需要注意:

1. 把块存进BlockManager时,使用的id是BroadcastBlockId(id, "piece" + i)。也就是说跟据Broadcast对象的id,以及总共的块的数量就可以还原出所有的块存储时所使用的id。这也就是为什么TorrentBroadcast要有numBlocks这个field的原因。而id字段是Broadcast这个虚类里的val, 所以根据TorrentBroadcast对象的字段,即可以它所划分的所有block的id。在从这些块还原被broadcast的对象时,也的确是这么做的。

2. 把划分出的块存储进BlockManager时,tellMaster字段的值为true,这就使得master可以知道哪个BlockManager存储了这个块,因此executor端的BlockManager最初的时候才能从driver端的BlockManager获取这个块。相反的是,writeBlocks第一句putSingle时,tellMaster是false,因为并不准备让其它BlockManager获取putSingle进去的对象。

blockifyObject

blockifyObject作的工作就是将被广播的对象序列化,如果启用了压缩就进行压缩,然后将得到的字节流写入到一系列字节数组中。

它的返回值类型为:Array[ByteBuffer], 之所有是ByteBuffer, 是为了BlockManager使用方便,因为BlockManager的putBytes方法接受ByteBuffer作为参数。

  def blockifyObject[T: ClassTag](
      obj: T,
      blockSize: Int,
      serializer: Serializer,
      compressionCodec: Option[CompressionCodec]): Array[ByteBuffer] = {
    val bos = new ByteArrayChunkOutputStream(blockSize)
    val out: OutputStream = compressionCodec.map(c => c.compressedOutputStream(bos)).getOrElse(bos)
    val ser = serializer.newInstance()
    val serOut = ser.serializeStream(out)
    serOut.writeObject[T](obj).close()
    bos.toArrays.map(ByteBuffer.wrap)
  }

它实现的关键在于ByteArrayChunkOutputStream, 这个类实现了Java的OutputStream接口。它的主体部分如下:

private[spark] class ByteArrayChunkOutputStream(chunkSize: Int) extends OutputStream {

  private val chunks = new ArrayBuffer[Array[Byte]]
  private var lastChunkIndex = -1
  private var position = chunkSize
  override def write(b: Int): Unit = {
    allocateNewChunkIfNeeded()
    chunks(lastChunkIndex)(position) = b.toByte
    position += 1
  }

 override def write(bytes: Array[Byte], off: Int, len: Int): Unit = { ... }
 def toArrays: Array[Array[Byte]] = { ... }
 ... 

}

即,它在内部使用一些长度等于chunkSize的数组来存储被写入的字节。

组装还原被广播的对象

在executor端(如果有task在driver执行的话,也可以是在driver端)需要把被切块后的对象组装起来,还原成被广播的对象。这是通过对lazy val _value访问触发的。

 @transient private lazy val _value: T = readBroadcastBlock()

readBroadcast会首先在本地的BlockManager寻找之前存入的被广播的对象,因此如果同一个executor中已经有task访问过_value,那么它就能直接取到已被放入本地BlockManager中的对象,

如果本地还没有, 那么就会调用readBlocks获取组成这个对象的块,然后用unblockifyObject还原这个对象,接着把它放入BlockManager,以使得同一个executor的其它task不必重复组装还原。

 private def readBroadcastBlock(): T = Utils.tryOrIOException {
    TorrentBroadcast.synchronized {
      setConf(SparkEnv.get.conf)
      //从本地的blockManager里读这个被broadcast的对象,根据broadcastId
      SparkEnv.get.blockManager.getLocal(broadcastId).map(_.data.next()) match {
        case Some(x) => //本地有
          x.asInstanceOf[T]

        case None => //本地无
          logInfo("Started reading broadcast variable " + id)
          val startTimeMs = System.currentTimeMillis()
          val blocks = readBlocks()//如果本地没有broadcastId对应的broadcast的block,就读
          logInfo("Reading broadcast variable " + id + " took" + Utils.getUsedTimeMs(startTimeMs))

          val obj = TorrentBroadcast.unBlockifyObject[T](
            blocks, SparkEnv.get.serializer, compressionCodec)
          // Store the merged copy in BlockManager so other tasks on this executor don‘t
          // need to re-fetch it.
          SparkEnv.get.blockManager.putSingle( //读了之后再放进BlockManager
            broadcastId, obj, StorageLevel.MEMORY_AND_DISK, tellMaster = false)
          obj
      }
    }
  }

这里有一个细节是,组装还原之后的对象被用putSingle放入BlockManager, 存储级别为MEMORY_AND_DISK,这就意味着,在MemoryStore无法容纳被广播的对象时,同一个executor的两个task可能会获取两个不同的对象(需要研究下BlockManager相关的代码才能确定)。如果这种情况发生,而被广播的对象是线程安全的,那么就是对内存的浪费。如果这种情况不发生,一个executor的所有task共享一个被广播的对象,那么可能会产生线程安全的问题。但是无论如何,使用被广播的对象时,需要以只读的方式,对它的修改可能会产生问题。

TorrentBroadcast是通过readBlocks获取构成序列化后的对象的块。

  /** Fetch torrent blocks from the driver and/or other executors. */
  private def readBlocks(): Array[ByteBuffer] = {
    //获取到的block被存在本地的BlockManager中并且上报给driver,这样其它的executor就可以从这个executor获取这些block了
    val blocks = new Array[ByteBuffer](numBlocks)
    val bm = SparkEnv.get.blockManager

    //需要shuffle,避免所有executor以同样的顺序下载block,使得driver依然是瓶颈
    for (pid <- Random.shuffle(Seq.range(0, numBlocks))) {
      val pieceId = BroadcastBlockId(id, "piece" + pid)//组装BroadcastBlockId
      logDebug(s"Reading piece $pieceId of $broadcastId")
      // 先试着从本地获取,因为之前的尝试可能已经获取了一些block
      def getLocal: Option[ByteBuffer] = bm.getLocalBytes(pieceId)
      def getRemote: Option[ByteBuffer] = bm.getRemoteBytes(pieceId).map { block =>
        //如果从remote获取了block,就把它存在本地的BlockManager
        SparkEnv.get.blockManager.putBytes(
          pieceId,
          block,
          StorageLevel.MEMORY_AND_DISK_SER,
          tellMaster = true)
        block
      }
      val block: ByteBuffer = getLocal.orElse(getRemote).getOrElse(
        throw new SparkException(s"Failed to get $pieceId of $broadcastId"))
      blocks(pid) = block
    }
    blocks
  }

readBlocks还是很简单易懂的,只是这里使用putBytes时,使用的存储级别是MEMORY_AND_DISK_SER,有些奇怪,不知道为啥对于这些bytes还需要序列化。

总结

TorrentBroadcast的实现有一些巧妙的细节,但是整体的代码还是很简洁,也比较容易理解。之所以有如此少的代码,是因为BlockManager已经提供了足够的基础设施。 

Spark的TorrentBroadcast:实现

标签:

原文地址:http://www.cnblogs.com/devos/p/4739987.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!