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

Ververica發表於2019-04-26

作者：劉康

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

本文主要內容如下：

一、在公司實時特徵開發的現狀基礎上，說明實時特徵平臺的開發背景、目標以及現狀

1.1、選擇實時計算平臺：依據專案的效能指標要求（latency，throughput等），在已有的實時計算平臺:Storm Spark flink進行選擇

1.2主要的開發運維過程：

80%以上的作業需要用到訊息佇列資料來源，但是訊息佇列為非結構化資料且沒有統一的資料字典。所以需要通過消費對應的topic，解析訊息並確定所需的內容
基於需求中的場景，設計開發計算邏輯
在實時資料不能完全滿足資料需求的情況，另外開發單獨的離線作業以及融合邏輯；

例如：在需要30天資料的場景下，但訊息佇列中只有七天內的資料時（kafka中訊息的預設保留時間），剩下23天就需要用離線資料來補充。
設計開發資料的校驗和糾錯邏輯

訊息的傳輸需要依賴網路，訊息丟失和超時難以完全避免，所以需要有一個校驗和糾錯的邏輯。
測試上線
監控和預警

現在的架構是標準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。

1）平臺功能展示-資料來源註冊

2）實時特徵編輯-基本資訊

3）實時特徵編輯-資料來源選擇

4）實時特徵編輯-SQL計算

5）實時特徵編輯-選擇輸出

我們下面一個我們說一下我們選擇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、實⽤示例