您好,登錄后才能下訂單哦!
作者:劉康
本文來自7月26日在上海舉行的 Flink Meetup 會議,分享來自于劉康,目前在大數(shù)據(jù)平臺部從事模型生命周期相關(guān)平臺開發(fā),現(xiàn)在主要負責基于flink開發(fā)實時模型特征計算平臺。熟悉分布式計算,在模型部署及運維方面有豐富實戰(zhàn)經(jīng)驗和深入的理解,對模型的算法及訓(xùn)練有一定的了解。
本文主要內(nèi)容如下:
在公司實時特征開發(fā)的現(xiàn)狀基礎(chǔ)上,說明實時特征平臺的開發(fā)背景、目標以及現(xiàn)狀
選擇Flink作為平臺計算引擎的原因
Flink的實踐:有代表性的使用示例、為兼容Aerospike(平臺的存儲介質(zhì))的開發(fā)以及碰到的坑
1.1、選擇實時計算平臺:依據(jù)項目的性能指標要求(latency,throughput等),在已有的實時計算平臺:Storm Spark flink進行選擇
1.2主要的開發(fā)運維過程:
80%以上的作業(yè)需要用到消息隊列數(shù)據(jù)源,但是消息隊列為非結(jié)構(gòu)化數(shù)據(jù)且沒有統(tǒng)一的數(shù)據(jù)字典。所以需要通過消費對應(yīng)的topic,解析消息并確定所需的內(nèi)容
基于需求中的場景,設(shè)計開發(fā)計算邏輯
在實時數(shù)據(jù)不能完全滿足數(shù)據(jù)需求的情況,另外開發(fā)單獨的離線作業(yè)以及融合邏輯;
例如:在需要30天數(shù)據(jù)的場景下,但消息隊列中只有七天內(nèi)的數(shù)據(jù)時(kafka中消息的默認保留時間),剩下23天就需要用離線數(shù)據(jù)來補充。
設(shè)計開發(fā)數(shù)據(jù)的校驗和糾錯邏輯
消息的傳輸需要依賴網(wǎng)絡(luò),消息丟失和超時難以完全避免,所以需要有一個校驗和糾錯的邏輯。
測試上線
消息隊列數(shù)據(jù)源結(jié)構(gòu)沒有統(tǒng)一的數(shù)據(jù)字典
特征計算邏輯高度定制化,開發(fā)測試周期長
實時數(shù)據(jù)不能滿足需求時,需要定制離線作業(yè)和融合邏輯
校驗和糾錯方案沒有形成最佳實踐,實際效果比較依賴個人能力
實時數(shù)據(jù)字典:提供統(tǒng)一的數(shù)據(jù)源注冊、管理功能,支持單一結(jié)構(gòu)消息的topic和包含多種不同結(jié)構(gòu)消息的topic
邏輯抽象:抽象為SQL,減少工作量&降低使用門檻
特征融合:提供融合特征的功能,解決實時特征不能完全滿足數(shù)據(jù)需求的情況
數(shù)據(jù)校驗和糾錯:提供利用離線數(shù)據(jù)校驗和糾錯實時特征的功能
實時計算延遲:ms級
實時計算容錯:端到端 exactly-once
cdn.xitu.io/2019/4/26/16a58bda2256a5fc?w=865&h=525&f=png&s=57691">
現(xiàn)在的架構(gòu)是標準lamda架構(gòu),離線部分由spark sql + dataX組成?,F(xiàn)在使用的是KV存儲系統(tǒng)Aerospike,跟redis的主要區(qū)別是使用SSD作為主存,我們壓測下來大部分場景讀寫性能跟redis在同一個數(shù)據(jù)量級。
實時部分:使用flink作為計算引擎,介紹一下用戶的使用方式:
注冊數(shù)據(jù)源:目前支持的實時數(shù)據(jù)源主要是Kafka和Aerospike,其中Aerospike中的數(shù)據(jù)如果是在平臺上配置的離線或者實時特征,會進行自動注冊。Kafka數(shù)據(jù)源需要上傳對應(yīng)的schemaSample文件
計算邏輯:通過SQL表達
用戶完成上面的操作后,平臺將所有信息寫入到j(luò)son配置文件。下一步平臺將配置文件和之前準備好的flinkTemplate.jar(包含所有平臺所需的flink功能)提交給yarn,啟動flink job。
1)平臺功能展示-數(shù)據(jù)源注冊
2)實時特征編輯-基本信息
3)實時特征編輯-數(shù)據(jù)源選擇
4)實時特征編輯-SQL計算
5)實時特征編輯-選擇輸出
我們下面一個我們說一下我們選擇flink來做這個特征平臺的原因。
分為三個維度:最高延遲、容錯、sql功能成熟度
延遲:storm和flink是純流式,最低可以達到毫秒級的延遲。spark的純流式機制是continuous模式,也可以達最低毫秒級的延遲
容錯:storm使用異或ack的模式,支持atLeastOnce。消息重復(fù)解決不。spark通過checkpoint和WAL來提供exactlyOnce。flink通過checkpoint和SavePoint來做到exactlyOnce。
sql成熟度:storm現(xiàn)在的版本中SQL還在一個實驗階段,不支持聚合和join。spark現(xiàn)在可以提供絕大部分功能,不支持distinct、limit和聚合結(jié)果的order by。flink現(xiàn)在社區(qū)版中提供的sql,不支持distinct aggregate
1、實?示例
2、兼容開發(fā):flink現(xiàn)在沒有對Aerospike提供讀寫支持,所以需要二次開發(fā)
3、碰到的坑
當前效果:將實時特征上線周期從原平均3天-5天降至小時級。未來規(guī)劃:
完善特征平臺的功能:融合特征等
簡化步驟,提高用戶體驗
下一步的規(guī)劃是通過sql或者DSL來描述模型部署和模型訓(xùn)練
更多資訊請訪問 Apache Flink 中文社區(qū)網(wǎng)站
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。