02.13 基於 Flink 的實時特徵平臺在攜程的應用

本文來自7月26日在上海舉行的 Flink Meetup 會議,分享來自於劉康,目前在大數據平臺部從事模型生命週期相關平臺開發,現在主要負責基於flink開發實時模型特徵計算平臺。熟悉分佈式計算,在模型部署及運維方面有豐富實戰經驗和深入的理解,對模型的算法及訓練有一定的瞭解。

本文主要內容如下:

  • 在公司實時特徵開發的現狀基礎上,說明實時特徵平臺的開發背景、目標以及現狀
  • 選擇Flink作為平臺計算引擎的原因
  • Flink的實踐:有代表性的使用示例、為兼容Aerospike(平臺的存儲介質)的開發以及碰到的坑
  • 當前效果&未來規劃

一、實時特徵平臺的開發背景、目標以及現狀 1、原實時特徵作業的開發運維;

1.1、選擇實時計算平臺:依據項目的性能指標要求(latency,throughput等),在已有的實時計算平臺:Storm Spark flink進行選擇

1.2主要的開發運維過程:

  • 80%以上的作業需要用到消息隊列數據源,但是消息隊列為非結構化數據且沒有統一 的數據字典。所以需要通過消費對應的topic,解析消息並確定所需的內容
  • 基於需求中的場景,設計開發計算邏輯
  • 在實時數據不能完全滿足數據需求的情況,另外開發單獨的離線作業以及融合邏輯; 例如:在需要30天數據的場景下,但消息隊列中只有七天內的數據時(kafka中消息的默認保留時間),剩下23天就需要用離線數據來補充。
  • 設計開發數據的校驗和糾錯邏輯 消息的傳輸需要依賴網絡,消息丟失和超時難以完全避免,所以需要有一個校驗和糾錯的邏輯。
  • 測試上線
  • 監控和預警

2、原實時特徵作業的開發痛點

  • 消息隊列數據源結構沒有統一的數據字典
  • 特徵計算邏輯高度定製化,開發測試周期長
  • 實時數據不能滿足需求時,需要定製離線作業和融合邏輯
  • 校驗和糾錯方案沒有形成最佳實踐,實際效果比較依賴個人能力
  • 監控和預警方案需要基於業務邏輯定製

3、基於整理的痛點,確定下來的平臺目標

  • 實時數據字典:提供統一的數據源註冊、管理功能,支持單一結構消息的 topic和包含多種不同結構消息的topic
  • 邏輯抽象:抽象為SQL,減少工作量&降低使用門檻
  • 特徵融合:提供融合特徵的功能,解決實時特徵不能完全滿足數據需求的情況
  • 數據校驗和糾錯:提供利用離線數據校驗和糾錯實時特徵的功能
  • 實時計算延遲:ms級
  • 實時計算容錯:端到端 exactly-once
  • 統一的監控預警和HA方案

4、特徵平臺系統架構

基於 Flink 的實時特徵平臺在攜程的應用

現在的架構是標準lamda架構,離線部分由spark sql + dataX組成。現在使用的是KV存儲系統Aerospike,跟redis的主要區別是使用SSD作為主存,我們壓測下來大部分場景讀寫性能跟redis在同一個數據量級。

實時部分:使用flink作為計算引擎,介紹一下用戶的使用方式:

  • 註冊數據源:目前支持的實時數據源主要是Kafka和Aerospike,其中Aerospike中的數據如果是在平臺上配置的離線或者實時特徵,會進行自動註冊。Kafka數據源需要上傳對應的schemaSample文件
  • 計算邏輯:通過SQL表達
  • 定義輸出:定義輸出的Aerospike表和可能需要的Kafka Topic,用於推送Update或者Insert的數據的key

用戶完成上面的操作後,平臺將所有信息寫入到json配置文件。下一步平臺將配置文件和之前準備好的flinkTemplate.jar(包含所有平臺所需的flink功能)提交給yarn,啟動flink job。

5、平臺功能展示

1)平臺功能展示-數據源註冊

基於 Flink 的實時特徵平臺在攜程的應用

基於 Flink 的實時特徵平臺在攜程的應用

基於 Flink 的實時特徵平臺在攜程的應用

基於 Flink 的實時特徵平臺在攜程的應用

基於 Flink 的實時特徵平臺在攜程的應用

二、選擇Flink的原因

我們下面一個我們說一下我們選擇flink來做這個特徵平臺的原因。

基於 Flink 的實時特徵平臺在攜程的應用

分為三個維度:最高延遲、容錯、sql功能成熟度

  • 延遲:storm和flink是純流式,最低可以達到毫秒級的延遲。spark的純流式機制是continuous模式,也可以達最低毫秒級的延遲,
  • 容錯:storm使用異或ack的模式,支持atLeastOnce。消息重複解決不。spark通過checkpoint和WAL來提供exactlyOnce。flink通過checkpoint和SavePoint來做到exactlyOnce。
  • sql成熟度:storm現在的版本中SQL還在一個實驗階段,不支持聚合和join。spark現在可以提供絕大部分功能,不支持distinct、limit和聚合結果的order by。flink現在社區版中提供的sql,不支持distinct aggregate

三、Flink實踐

1、實⽤示例

基於 Flink 的實時特徵平臺在攜程的應用

2、兼容開發:flink現在沒有對Aerospike提供讀寫支持,所以需要二次開發

基於 Flink 的實時特徵平臺在攜程的應用

3、碰到的坑

基於 Flink 的實時特徵平臺在攜程的應用

四、平臺當前效果&未來規劃

當前效果:將實時特徵上線週期從原平均3天-5天降至小時級。未來規劃:

  • 完善特徵平臺的功能:融合特徵等
  • 簡化步驟,提高用戶體驗
  • 根據需求,進一步完善SQL的功能例如支持win的開始時間offset,可以 通過countTrigger的win等

下一步的規劃是通過sql或者DSL來描述模型部署和模型訓練

基於 Flink 的實時特徵平臺在攜程的應用


分享到:


相關文章: