使用函數(shù)計(jì)算,數(shù)禾如何實(shí)現(xiàn)高效的數(shù)據(jù)處理?

作者｜邱鑫鑫，王彬，牟柏旭

公司背景和業(yè)務(wù)

數(shù)禾科技以大數(shù)據(jù)和技術(shù)為驅(qū)動(dòng)，為金融機(jī)構(gòu)提供高效的智能零售金融解決方案，服務(wù)銀行、信托、消費(fèi)金融公司、保險(xiǎn)、小貸公司等持牌金融機(jī)構(gòu)，業(yè)務(wù)涵蓋消費(fèi)信貸、小微企業(yè)信貸、場(chǎng)景分期等多個(gè)領(lǐng)域，提供營(yíng)銷獲客、風(fēng)險(xiǎn)防控、運(yùn)營(yíng)管理等服務(wù)。數(shù)禾科技通過(guò)自主開(kāi)發(fā)的消費(fèi)信貸產(chǎn)品，連接金融機(jī)構(gòu)與普羅大眾，賦能金融機(jī)構(gòu)數(shù)字化轉(zhuǎn)型，迎接中國(guó)消費(fèi)升級(jí)的大潮。 數(shù)禾當(dāng)前有三款主要產(chǎn)品，還唄，還享花，小店邦。每款產(chǎn)品都有大量的受眾，每天會(huì)產(chǎn)生大量的應(yīng)用日志，數(shù)據(jù)通過(guò)壓縮后歸檔到阿里云 OSS 存儲(chǔ)，以達(dá)到最優(yōu)的存儲(chǔ)成本。

低效的數(shù)據(jù)處理

應(yīng)用日志通過(guò) SLS 收集，壓縮并歸檔到 OSS，整個(gè)鏈路都非常順滑。但日常有些業(yè)務(wù)需要查看詳細(xì)的應(yīng)用日志，由于日志收集會(huì)將 APP 上不同應(yīng)用的日志都打到一起。因此，獲取某個(gè)應(yīng)用的日志，需要從 OSS 解壓大量的文件，并從中過(guò)濾出特定的應(yīng)用，才可以進(jìn)一步分析排查。這個(gè)過(guò)程在實(shí)效性和數(shù)據(jù)處理效率上都存在很大的問(wèn)題，為此，數(shù)禾運(yùn)維團(tuán)隊(duì)計(jì)劃從源頭重構(gòu)整個(gè)任務(wù)處理鏈路，以求以最低的開(kāi)發(fā)成本，最高的處理效率，最優(yōu)的資源費(fèi)用，最好的擴(kuò)展性打造高可用，易升級(jí)，低維護(hù)的解決方案。 首先想到的采用容器自建的方案。自建的處理程序從 Kafka 獲取數(shù)據(jù)，并負(fù)責(zé)數(shù)據(jù)的處理，K8s 集群保證任務(wù)的彈縮，配合自建的發(fā)布平臺(tái)，初步能夠滿足設(shè)計(jì)的需求。 該方案的優(yōu)勢(shì)在于，對(duì)于 K8s 的使用和任務(wù)發(fā)布平臺(tái)，數(shù)禾運(yùn)維團(tuán)隊(duì)都有了不少的積累，整體實(shí)施起來(lái)難度會(huì)比較小。但對(duì)比設(shè)想的鏈路目標(biāo)，卻還有些欠缺，主要表現(xiàn)在：

1. 任務(wù)開(kāi)發(fā)成本較高：從 Kafka 獲取數(shù)據(jù)，數(shù)據(jù)的業(yè)務(wù)處理、異步壓縮上傳，任務(wù)的發(fā)布更新系統(tǒng)對(duì)接，K8s 的彈縮策略，都需要研發(fā)人員全新開(kāi)發(fā)。
2. 鏈路彈性有限：一是 K8s 通過(guò)指標(biāo)彈出資源速度需要10+s，對(duì)于突發(fā)的日志流量，可能會(huì)出現(xiàn)資源彈出不及時(shí)的情況；二是 Kafka Topic 數(shù)據(jù)處理的并發(fā)度受限于 Topic Partition，當(dāng)消費(fèi)程序達(dá)到 Partition 數(shù)目時(shí)，消費(fèi)程序沒(méi)法繼續(xù)水平擴(kuò)大并發(fā)度。
3. 資源利用率不夠極致：在業(yè)務(wù)低峰期，特別是夜間，存在流量很小甚至是無(wú)流量的時(shí)段，但處理程序還是得最小保持1個(gè)實(shí)例的運(yùn)行，造成了一定的資源浪費(fèi)。
4. 升級(jí)維護(hù)工作依然很多：業(yè)務(wù)處理邏輯的修改，發(fā)布平臺(tái)的更新對(duì)接，K8s 平臺(tái)的彈縮規(guī)則等，都需要持續(xù)的維護(hù)。

就在數(shù)禾運(yùn)維團(tuán)隊(duì)陷入選型沉思的時(shí)候，阿里云函數(shù)計(jì)算（后面簡(jiǎn)稱 FC）團(tuán)隊(duì)的交流讓數(shù)禾運(yùn)維團(tuán)隊(duì)眼前一亮，阿里云函數(shù)計(jì)算在 Kafka->FC 的鏈路已經(jīng)打磨多時(shí)，對(duì)于數(shù)禾的業(yè)務(wù)需求，正可以使用到函數(shù)計(jì)算很多的已有功能，數(shù)禾的研發(fā)團(tuán)隊(duì)只需要專注在自身的業(yè)務(wù)處理邏輯，就能快速的搭建一套高可用，易升級(jí)，低維護(hù)的任務(wù)處理鏈路。

函數(shù)計(jì)算的出現(xiàn)恰逢其時(shí)

函數(shù)計(jì)算是事件驅(qū)動(dòng)的全托管計(jì)算服務(wù)。使用函數(shù)計(jì)算，客戶無(wú)需采購(gòu)與管理服務(wù)器等基礎(chǔ)設(shè)施，只需編寫(xiě)并上傳代碼或鏡像。函數(shù)計(jì)算會(huì)準(zhǔn)備好計(jì)算資源，彈性地、可靠地運(yùn)行任務(wù)，并提供日志查詢、性能監(jiān)控和報(bào)警等功能。
通過(guò)函數(shù)計(jì)算自帶的 Kafka 觸發(fā)器和定時(shí)觸發(fā)器，數(shù)禾運(yùn)維團(tuán)隊(duì)架構(gòu)出了一套理想的解決方案。架構(gòu)圖如下：

函數(shù)的處理邏輯如下：

1. 數(shù)據(jù)拆分函數(shù)：通過(guò) Kafka 觸發(fā)器觸發(fā)，觸發(fā)器會(huì)將 Kafka 數(shù)據(jù)攢批，以 batch的形式發(fā)送到函數(shù)計(jì)算，函數(shù)計(jì)算處理邏輯負(fù)責(zé)將數(shù)據(jù)塊通過(guò)標(biāo)識(shí)字段拆分，同一個(gè)應(yīng)用的數(shù)據(jù)匯聚到一起，在 NAS 目錄形成獨(dú)立的文件。屬于 io 密集型操作。

2. 數(shù)據(jù)壓縮函數(shù)：在一批數(shù)據(jù)到達(dá)函數(shù)計(jì)算拆分匯聚之后，先對(duì)數(shù)據(jù)進(jìn)行壓縮，然后將壓縮后的數(shù)據(jù)追加到 NAS 目錄對(duì)應(yīng)的文件，在寫(xiě) NAS 前，借助 Redis 處理并發(fā)鎖的問(wèn)題，大大減少了小文件的數(shù)量，屬于算力密集型操作。

3. 數(shù)據(jù)上傳函數(shù)：通過(guò)定時(shí)觸發(fā)器觸發(fā)，將第二步壓縮完成的數(shù)據(jù)上傳到 OSS 對(duì)應(yīng)目錄，然后清理本地目錄。屬于 io 密集型操作。

通過(guò)將處理邏輯拆分，將對(duì)資源要求不同的操作拆分到不同函數(shù)，實(shí)現(xiàn)了每個(gè)函數(shù)資源利用率的最大化，降低了總體實(shí)現(xiàn)的費(fèi)用成本。

相比通過(guò) ECS/K8s 自建的方案，優(yōu)勢(shì)還是十分明顯的：

從對(duì)比可以看出，采用函數(shù)計(jì)算的方式，在開(kāi)發(fā)效率，彈性，升級(jí)部署，費(fèi)用成本方面，相對(duì) ECS/K8s 自建方案，都有明顯的優(yōu)勢(shì)。

落地中的問(wèn)題

Serverless 理念跟整個(gè)任務(wù)的架構(gòu)十分的契合，但在落地中還是可以看到有些處理不夠優(yōu)雅的地方，總結(jié)起來(lái)主要有兩處：

1. 函數(shù)計(jì)算同步調(diào)用的攢批大小是16M，異步調(diào)用的攢批大小是128K，為了降低調(diào)用函數(shù)的計(jì)算頻率，達(dá)到更好的攢批效果，從而在成本和性能上都達(dá)到好的效果，使得觸發(fā)器配置時(shí)只能配置同步調(diào)用，同步調(diào)用時(shí)，函數(shù)計(jì)算側(cè)的并行度取決于調(diào)用方，這就要求觸發(fā)器任務(wù)配置多任務(wù)分片，造成了一定的資源浪費(fèi)。

2. 在第一個(gè)函數(shù)中，主要處理邏輯是根據(jù) Kafka 消息的應(yīng)用 id 信息，拆分?jǐn)?shù)據(jù)，將同一個(gè) id 應(yīng)用的數(shù)據(jù)聚合在一起，由于本身 NAS 和 OSS 都沒(méi)有提供文件鎖，所以當(dāng)多個(gè)函數(shù)并發(fā)寫(xiě)同一個(gè)id應(yīng)用文件時(shí)，如果程序?qū)用娌惶幚砦募i的問(wèn)題，會(huì)導(dǎo)致寫(xiě)數(shù)據(jù)相互覆蓋。對(duì)于每個(gè)函數(shù)實(shí)例拆分小文件的方案，由于 Kafka 消息中應(yīng)用的種類很多，拆分?jǐn)?shù)據(jù)總是會(huì)形成很多小文件，數(shù)據(jù)合并需要很長(zhǎng)的時(shí)間。經(jīng)過(guò)多種方案的檢驗(yàn)比較，最終選擇了通過(guò) Redis 處理文件鎖，每個(gè)應(yīng)用全局最多產(chǎn)生10個(gè)并發(fā)寫(xiě)文件，函數(shù)計(jì)算運(yùn)行實(shí)例寫(xiě) NAS 文件時(shí)，先去Redis獲取文件鎖，獲取成功才能真正開(kāi)始寫(xiě)入。這種方案在寫(xiě)數(shù)據(jù)性能上有很好的表現(xiàn)，代碼復(fù)雜度得到了一定的增加，但總體可控。

最終，這些問(wèn)題沒(méi)有成為數(shù)禾方案的卡點(diǎn)，通過(guò)交流和方案驗(yàn)證，最終都得到了一定程度的解決。

出色的效果和進(jìn)一步的期待

在全鏈路角度看，整條鏈路非常的 Serverless，資源使用效率也非常高，再配合函數(shù)計(jì)算2023云棲大會(huì)推出的梯度計(jì)價(jià)，整個(gè)方案在資源成本上也達(dá)到了非常好的控制。

在期望方面，針對(duì)本次場(chǎng)景落地中遇到的問(wèn)題，還是希望可以得到更好的優(yōu)化。異步調(diào)用放寬消息體大小，可以以最少的觸發(fā)器資源，達(dá)到函數(shù)計(jì)算的大并發(fā)處理。通過(guò) NAS/OSS 原生支持文件鎖的能力，可以減少文件的數(shù)量，同時(shí)也減少業(yè)務(wù)層代碼在這方面的處理復(fù)雜度。

任務(wù)從10月份上線以來(lái)，數(shù)禾運(yùn)維團(tuán)隊(duì)在該任務(wù)的運(yùn)維投入上得到了人力釋放，幾乎達(dá)到了0運(yùn)維；在功能迭代上，通過(guò)函數(shù)計(jì)算控制臺(tái)提供的多版本和灰度能力，快速的完成了升級(jí)的灰度。

后續(xù)數(shù)禾運(yùn)維團(tuán)隊(duì)會(huì)將更多適合 Serverless 的業(yè)務(wù)采用函數(shù)計(jì)算方案，最大限度將精力專注在公司業(yè)務(wù)，逐漸剝離運(yùn)維和底層資源的簡(jiǎn)單維護(hù)。數(shù)禾運(yùn)維團(tuán)隊(duì)也十分開(kāi)放的與函數(shù)計(jì)算團(tuán)隊(duì)探討更多的場(chǎng)景，希望將公司的業(yè)務(wù)架構(gòu)在新一代的 Serverless 架構(gòu)上。