Flink流式計算在節省資源方面的簡單分析

關於Flink流式計算節省資源方面你必須知道的技巧 

資訊流推薦業務是小米從Spark Streaming遷移到Flink流式計算最早也是使用Flink最深的業務之一，在經過一段時間的合作最佳化後，對方同學給我們提供了一些使用效果小結，其中有幾個關鍵點：

• 對於無狀態作業，資料處理的延遲由之前Spark Streaming的16129ms降低到Flink的926ms，有94.2%的顯著提升（有狀態作業也有提升，但是和具體業務邏輯有關，不做介紹）；
• 對後端儲存系統的寫入延遲從80ms降低到了20ms左右，如下圖（這是因為Spark Streaming的mini batch模式會在batch最後有批次寫儲存系統的操作，從而造成寫請求尖峰，Flink則沒有類似問題）:
  
  
• 對於簡單的從訊息佇列Talos到儲存系統HDFS的資料清洗作業（ETL），由之前Spark Streaming的佔用210個CPU Core降到了Flink的32個CPU Core，資源利用率提高了84.8%；

Spark的核心資料結構RDD包含了幾個關鍵資訊，包括資料的分片（partitions)、依賴（dependencies)等，其中還有一個用於最佳化執行的資訊，就是分片的“preferred locations”

// RDD
/**
 * Optionally overridden by subclasses to specify placement preferences.
 */
protected def getPreferredLocations(split: Partition): Seq[String] = Nil

”排程計算”的方法在批處理中有很大的優勢，因為“計算”相比於“資料”來講一般資訊量比較小，如果“計算”可以在“資料”所在的節點執行的話，會省去大量網路傳輸，節省頻寬的同時提高了計算效率。但是在流式計算中，以Spark Streaming的排程方法為例，由於需要頻繁的排程”計算“，則會有一些效率上的損

耗。首先，每次”計算“的排程都是要消耗一些時間的，比如“計算”資訊的序列化 → 傳輸 → 反序列化 → 初始化相關資源 → 計算執行→執行完的清理和結果上報等，這些都是一些“損耗”。

另外，使用者的計算中一般會有一些資源的初始化邏輯，比如初始化外部系統的客戶端（類似於Kafka Producer或Consumer)；每次計算的重複排程容易導致這些資源的重複初始化，需要使用者對執行邏輯有一定的理解，才能合理地初始化資源，避免資源的重複建立；這就提高了使用門檻，容易埋下隱患；透過業務支援發現，在實際生產過程中，經常會遇到大併發的Spark Streaming作業給Kafka或HBase等儲存系統帶來巨大連線壓力的情況，就是因為使用者在計算邏輯中一直重複建立連線。

Spark在官方文件提供了一些避免重複建立網路連線的示例程式碼，其核心思想就是透過連線池來複用連線：

這個資訊提供了該分片資料的位置資訊，即所在的節點；Spark在排程該分片的計算的時候，會盡量把該分片的計算排程到資料所在的節點，從而提高計算效率。比如對於KafkaRDD，該方法返回的就是topic partition的leader節點資訊：

rdd.foreachPartition { partitionOfRecords =>
// ConnectionPool is a static, lazily initialized pool of connections
    val connection = ConnectionPool.getConnection()
    partitionOfRecords.foreach(record => connection.send(record))
    ConnectionPool.returnConnection(connection)  // return to the pool for future reuse
  }
}

// Not a POJO demo.public class Person {  private Logger logger = LoggerFactory.getLogger(Person.class);  public String name;  public int age;}

針對這一情況我們做了一些最佳化嘗試，由於在小米內部很多業務是透過Thrfit定義的資料，正常情況下Thrift類是透過Kryo的預設序列化器進行序列化和反序列化的，效率比較低。雖然官方提供了最佳化文件，可以透過如下方式進行最佳化，但是對業務來講也是存在一定使用門檻；

// KafkaRDD
override def getPreferredLocations(thePart: Partition): Seq[String] = {
    val part = thePart.asInstanceOf[KafkaRDDPartition]
    Seq(part.host) 
    // host: preferred kafka host, i.e. the leader at the time the rdd was created
  }