使用函數計算，數禾如何實現高效的數據處理？

公司背景和業務

數禾科技以大數據和技術爲驅動，爲金融機構提供高效的智能零售金融解決方案，服務銀行、信託、消費金融公司、保險、小貸公司等持牌金融機構，業務涵蓋消費信貸、小微企業信貸、場景分期等多個領域，提供營銷獲客、風險防控、運營管理等服務。數禾科技通過自主開發的消費信貸產品，連接金融機構與普羅大衆，賦能金融機構數字化轉型，迎接中國消費升級的大潮。

數禾當前有三款主要產品，還唄，還享花，小店邦。每款產品都有大量的受衆，每天會產生大量的應用日誌，數據通過壓縮後歸檔到阿里雲 OSS 存儲，以達到最優的存儲成本。

低效的數據處理

應用日誌通過 SLS 收集，壓縮並歸檔到 OSS，整個鏈路都非常順滑。但日常有些業務需要查看詳細的應用日誌，由於日誌收集會將 APP 上不同應用的日誌都打到一起。因此，獲取某個應用的日誌，需要從 OSS 解壓大量的文件，並從中過濾出特定的應用，纔可以進一步分析排查。這個過程在實效性和數據處理效率上都存在很大的問題，爲此，數禾運維團隊計劃從源頭重構整個任務處理鏈路，以求以最低的開發成本，最高的處理效率，最優的資源費用，最好的擴展性打造高可用，易升級，低維護的解決方案。

首先想到的採用容器自建的方案。自建的處理程序從 Kafka 獲取數據，並負責數據的處理，K8s 集羣保證任務的彈縮，配合自建的發佈平臺，初步能夠滿足設計的需求。

該方案的優勢在於，對於 K8s 的使用和任務發佈平臺，數禾運維團隊都有了不少的積累，整體實施起來難度會比較小。但對比設想的鏈路目標，卻還有些欠缺，主要表現在：

1. 任務開發成本較高：從 Kafka 獲取數據，數據的業務處理、異步壓縮上傳，任務的發佈更新系統對接，K8s 的彈縮策略，都需要研發人員全新開發。
2. 鏈路彈性有限：一是 K8s 通過指標彈出資源速度需要10+s，對於突發的日誌流量，可能會出現資源彈出不及時的情況；二是 Kafka Topic 數據處理的併發度受限於 Topic Partition，當消費程序達到 Partition 數目時，消費程序沒法繼續水平擴大併發度。
3. 資源利用率不夠極致：在業務低峯期，特別是夜間，存在流量很小甚至是無流量的時段，但處理程序還是得最小保持1個實例的運行，造成了一定的資源浪費。
4. 升級維護工作依然很多：業務處理邏輯的修改，發佈平臺的更新對接，K8s 平臺的彈縮規則等，都需要持續的維護。

就在數禾運維團隊陷入選型沉思的時候，阿里雲函數計算（後面簡稱FC）團隊的交流讓數禾運維團隊眼前一亮，阿里雲函數計算在 Kafka->FC 的鏈路已經打磨多時，對於數禾的業務需求，正可以使用到函數計算很多的已有功能，數禾的研發團隊只需要專注在自身的業務處理邏輯，就能快速的搭建一套高可用，易升級，低維護的任務處理鏈路。

函數計算的出現恰逢其時

函數計算是事件驅動的全託管計算服務。使用函數計算，客戶無需採購與管理服務器等基礎設施，只需編寫並上傳代碼或鏡像。函數計算會準備好計算資源，彈性地、可靠地運行任務，並提供日誌查詢、性能監控和報警等功能。

通過函數計算自帶的 Kafka 觸發器和定時觸發器，數禾運維團隊架構出了一套理想的解決方案。架構圖如下：

 

函數的處理邏輯如下：

1. 數據拆分函數：通過 Kafka 觸發器觸發，觸發器會將 Kafka 數據攢批，以batch的形式發送到函數計算，函數計算處理邏輯負責將數據塊通過標識字段拆分，同一個應用的數據匯聚到一起，在 NAS 目錄形成獨立的文件。屬於 io 密集型操作。
2. 數據壓縮函數：在一批數據到達函數計算拆分匯聚之後，先對數據進行壓縮，然後將壓縮後的數據追加到 NAS 目錄對應的文件，在寫 NAS 前，藉助 Redis 處理併發鎖的問題，大大減少了小文件的數量，屬於算力密集型操作。
3. 數據上傳函數：通過定時觸發器觸發，將第二步壓縮完成的數據上傳到 OSS 對應目錄，然後清理本地目錄。屬於 io 密集型操作。

通過將處理邏輯拆分，將對資源要求不同的操作拆分到不同函數，實現了每個函數資源利用率的最大化，降低了總體實現的費用成本。

相比通過 ECS/K8s 自建的方案，優勢還是十分明顯的：

 

從對比可以看出，採用函數計算的方式，在開發效率，彈性，升級部署，費用成本方面，相對 ECS/K8s 自建方案，都有明顯的優勢。

落地中的問題

Serverless 理念跟整個任務的架構十分的契合，但在落地中還是可以看到有些處理不夠優雅的地方，總結起來主要有兩處：

1. 函數計算同步調用的攢批大小是16M，異步調用的攢批大小是128K，爲了降低調用函數的計算頻率，達到更好的攢批效果，從而在成本和性能上都達到好的效果，使得觸發器配置時只能配置同步調用，同步調用時，函數計算側的並行度取決於調用方，這就要求觸發器任務配置多任務分片，造成了一定的資源浪費。
2. 在第一個函數中，主要處理邏輯是根據 Kafka 消息的應用id信息，拆分數據，將同一個id應用的數據聚合在一起，由於本身 NAS 和 OSS 都沒有提供文件鎖，所以當多個函數併發寫同一個id應用文件時，如果程序層面不處理文件鎖的問題，會導致寫數據相互覆蓋。對於每個函數實例拆分小文件的方案，由於 Kafka 消息中應用的種類很多，拆分數據總是會形成很多小文件，數據合併需要很長的時間。經過多種方案的檢驗比較，最終選擇了通過 Redis 處理文件鎖，每個應用全局最多產生10個併發寫文件，函數計算運行實例寫 NAS 文件時，先去 Redis 獲取文件鎖，獲取成功才能真正開始寫入。這種方案在寫數據性能上有很好的表現，代碼複雜度得到了一定的增加，但總體可控。

最終，這些問題沒有成爲數禾方案的卡點，通過交流和方案驗證，最終都得到了一定程度的解決。

出色的效果和進一步的期待

在全鏈路角度看，整條鏈路非常的 Serverless，資源使用效率也非常高，再配合函數計算2023雲棲大會推出的梯度計價，整個方案在資源成本上也達到了非常好的控制。

在期望方面，針對本次場景落地中遇到的問題，還是希望可以得到更好的優化。異步調用放寬消息體大小，可以以最少的觸發器資源，達到函數計算的大併發處理。通過 NAS/OSS 原生支持文件鎖的能力，可以減少文件的數量，同時也減少業務層代碼在這方面的處理複雜度。

任務從10月份上線以來，數禾運維團隊在該任務的運維投入上得到了人力釋放，幾乎達到了0運維；在功能迭代上，通過函數計算控制檯提供的多版本和灰度能力，快速的完成了升級的灰度。

後續數禾運維團隊會將更多適合 Serverless 的業務採用函數計算方案，最大限度將精力專注在公司業務，逐漸剝離運維和底層資源的簡單維護。數禾運維團隊也十分開放的與函數計算團隊探討更多的場景，希望將公司的業務架構在新一代的 Serverless 架構上。

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

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。