攜程基于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、特征平台系統架構

現在的架構是标準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）平台功能展示-資料源注冊

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

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

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

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

二、選擇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、實⽤示例

2、相容開發：flink現在沒有對Aerospike提供讀寫支援，是以需要二次開發

3、碰到的坑

四、平台目前效果&未來規劃

目前效果：将實時特征上線周期從原平均3天-5天降至小時級。未來規劃：

• 完善特征平台的功能：融合特征等
• 簡化步驟，提高使用者體驗
• 根據需求，進一步完善SQL的功能例如支援win的開始時間offset，可以通過countTrigger的win等

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

更多資訊請通路

Apache Flink 中文社群網站