Spark Streaming中foreachRDD的陷阱

我们的项目需要从Kafka消费消息,在对消息进行处理后,再写入到ActiveMQ,以作为外部系统的数据源。基于这样的逻辑,我们就需要通过Spark Streaming读取Kafka的消息,获得的结果其实是一个RDD。DStream提供了foreachRDD(func)方法,通过该方法可以遍历RDD的每条记录,然后再通过ActiveMQ的Producer将处理后的消息发送到ActiveMQ。

要将消息发送到ActiveMQ,就需要建立与消息队列的连接。在传统编程实现中,最直观的做法一定是将获取连接的代码放在foreachRDD(func)方法之外,如此可以避免不必要的资源消耗与时间消耗。例如:

1
2
3
4
5
6
7
8
9
10
11
12
dstream.foreachRDD { rdd =>
val producer = createProducer()
rdd.foreach { message =>
producer.send(message)
}
}

def createProducer(): MessageProducer = {
val conn = createActiveMQConnection()
val session = sessionFrom(conn)
producerFrom(session)
}

但是,这一做法在Spark Streaming中却行不通。原因在于:foreachRDD(func)方法中的func是在调用Spark流式计算程序的Driver进程中执行的,而遍历得到的RDD中的操作却是在worker中执行

1
2
3
4
5
6
dstream.foreachRDD { rdd =>
val producer = createProducer() //在driver进程执行
rdd.foreach { message =>
producer.send(message) //在worker进程执行
}
}

这就需要将获得的对象(例子中包括了Connection、Session和Producer)进行序列化,使其能够从driver发送到worker。然而,连接等于资源相关的对象往往无法支持序列化,也无法在worker正确的初始化。

为了避免这种情况,一种做法是将前面的createProducer()方法搬到内部的rdd.foreach(fn)中来。可是,创建一个connection对象往往既费时间又费资源,针对每个RDD不停地创建连接,然后又关闭连接,会影响到整个系统的吞吐量和性能。

解决方案是使用foreachPartition(func)方法,通过它创建一个单独的connection对象,然后在RDD分区里使用这个连接对象将所有数据发送出去:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
dstream.foreachRDD { rdd =>
rdd.foreachPartition { partitionOfRecords =>
sendToActiveMQ { producer =>
partitionOfRecords.foreach(record => producer.send(record))
}
}
}

def sendToActiveMQ(send: MessageProducer => Unit):Unit => {
val conn = createActiveMQConnection()
val session = sessionFrom(conn)
val producer = producerFrom(session)
send(producer)
conn.close()
}

为了避免过多的创建和释放connection对象,还有一个更好的方案是使用连接池。由于我在前面的代码已经将连接创建与关闭提取出专门的方法,因此只需要修改前面的sendToActiveMQ()即可:

1
2
3
4
5
6
7
def sendToActiveMQ(send: MessageProducer => Unit):Unit => {
val conn = ActiveMQConnectionPool.getConnection()
val session = sessionFrom(conn)
val producer = producerFrom(session)
send(producer)
ActiveMQConnectionPool.returnConnnection(conn)
}

Spark这种Driver与Worker互相协作的分布式架构,与单节点的编程模型存在细微差异。开发时,稍不注意就可能出现问题。当然,面对这些问题,最根本的还是要从Spark的设计本质来理解,问题也就迎刃而解了。