定向减免!函数计算让 ETL 数据加工更简单
業(yè)內(nèi)較為常見的高頻短時 ETL 數(shù)據(jù)加工場景,即頻率高時延短,一般費用大頭均在函數(shù)調(diào)用次數(shù)上,推薦方案一般為攢批處理,高額的計算成本往往令用戶感到頭疼,函數(shù)計算推出定向減免方案,讓 ETL數(shù)據(jù)加工更簡單、更自動化、容錯能力更強。
自2024年01月01日0時起,函數(shù)計算定向減免來自阿里云消息類產(chǎn)品和云工作流(CloudFlow)的函數(shù)調(diào)用次數(shù)費用,即通過以上產(chǎn)品事件觸發(fā)函數(shù)計算所產(chǎn)生的函數(shù)調(diào)用次數(shù)不再計入費用賬單。定向減免函數(shù)調(diào)用次數(shù)費用的產(chǎn)品包括:
- 阿里云消息類產(chǎn)品:
- 消息服務(wù)MNS
- 云消息隊列 RocketMQ 版
- 消息隊列 RabbitMQ 版
- 云消息隊列 Kafka 版
- 云消息隊列 MQTT 版
- 事件總線EventBridge
-
云工作流(CloudFlow)
這樣用 FC,ETL 場景可立省 87% 計算費用
某出行領(lǐng)域客戶基于函數(shù)計算 FC 構(gòu)建免運維、自動化的 ETL 數(shù)據(jù)加工場景如下:
每天處理10億條 Kafka 消息數(shù)據(jù),每次處理平均耗時10毫秒,算力規(guī)格 0.1c0.5g,其費用組成為:
- vCPU使用量:0.1 * 1000000000 * 0.01 * 0.00009 = 90元
- 內(nèi)存使用量:0.5 * 1000000000 * 0.01 * 0.000009 = 45元
- 函數(shù)調(diào)用次數(shù)費用:1000000000 / 10000 * 0.009 = 900元
注意:以上均按照函數(shù)計算階梯計費的階梯0單價進行計價,忽略免費額度,定價參考:
若定向減免該 ETL 場景下的函數(shù)調(diào)用次數(shù)費用,則該 ETL 場景可立省 87% 計算費用!(不同場景的降本數(shù)字需結(jié)合實際業(yè)務(wù)需求進行測算。)
基于函數(shù)計算 FC 的熱門 ETL 場景
數(shù)據(jù)投遞分析
在數(shù)據(jù)投遞分析場景中,函數(shù)計算可以為用戶的投遞以及數(shù)據(jù)分析提供高*度的模板能力和自定義能力,提供海量下游投遞能力。
數(shù)據(jù)加工清洗轉(zhuǎn)存
數(shù)據(jù)清洗加工和轉(zhuǎn)存場景,函數(shù)計算可以提供數(shù)據(jù) Transform 處理能力,供數(shù)據(jù)加工。
業(yè)務(wù)消息處理
函數(shù)計算 FC 有豐富的事件響應(yīng)場景,消息作為事件驅(qū)動的重要數(shù)據(jù)源,可以驅(qū)動函數(shù)計算執(zhí)行一系列業(yè)務(wù)邏輯,構(gòu)建完整的事件驅(qū)動架構(gòu)。
立即開始
阿里云消息類產(chǎn)品
函數(shù)計算 FC 和阿里云消息產(chǎn)品家族通過產(chǎn)品集成,只需要簡單“點點點”即可實現(xiàn)自動化、高可用的彈性消息 ETL 方案,大幅簡化了 ETL 任務(wù)的難開發(fā)、難運維的痛點。
Connector 生態(tài)集成
在 Kafka、RocketMQ、RabbitMQ 控制臺配置 Connector 實現(xiàn)消息 ETL 任務(wù),選擇函數(shù)計算 FC 模板即可實現(xiàn)預(yù)置過濾、轉(zhuǎn)換、投遞等基礎(chǔ)需求。如若需要實現(xiàn)更自定義的轉(zhuǎn)換需求,也可以在函數(shù)計算 FC 控制臺創(chuàng)建事件函數(shù)進行定制開發(fā),然后在 Connector 界面選擇指定的函數(shù)即可運行特定 ETL 任務(wù)。
同時,也可以通過此類 ETL 任務(wù)實現(xiàn)消息數(shù)據(jù)快速投遞至存儲、大數(shù)據(jù)等,實現(xiàn)數(shù)據(jù)轉(zhuǎn)儲需求。
EventBridge 事件流
在 EventBridge 控制臺配置事件流,快速創(chuàng)建消息隊列、數(shù)據(jù)庫等數(shù)據(jù) ETL 任務(wù),選擇函數(shù)計算 FC 模板即可實現(xiàn)預(yù)置過濾、轉(zhuǎn)換、投遞等基礎(chǔ)需求。如若需要實現(xiàn)更自定義的轉(zhuǎn)換需求,也可以在函數(shù)計算 FC 控制臺創(chuàng)建事件函數(shù)進行定制開發(fā),然后在 Connector 界面選擇指定的函數(shù)即可運行特定 ETL 任務(wù)。
同時,也可以通過此類 ETL 任務(wù)實現(xiàn)消息數(shù)據(jù)快速投遞至存儲、大數(shù)據(jù)等,實現(xiàn)數(shù)據(jù)轉(zhuǎn)儲需求。
云工作流 CloudFlow
云工作流(CloudFlow)是用來協(xié)調(diào)多個分布式任務(wù)執(zhí)行的全托管 Serverless 云服務(wù),簡化開發(fā)、運行業(yè)務(wù)流程需要的任務(wù)協(xié)調(diào)、狀態(tài)管理和錯誤處理等繁瑣工作。云工作流配合函數(shù)計算 FC 支持簡單拖放即可實現(xiàn)復(fù)雜業(yè)務(wù)流程,無需編寫代碼,即可編排 300+? 云服務(wù)實現(xiàn)工作流程自動化,實現(xiàn)流程式編程新范式。
下面是云工作流,函數(shù)計算 FC 搭建一個高可用的數(shù)據(jù)處理流水線的最佳實踐:
來自不同數(shù)據(jù)源的計量數(shù)據(jù)被收集到日志服務(wù),函數(shù)計算 FC 的定時器每小時觸發(fā)工作流,云工作流利用函數(shù)計算 FC 對多個 Shard 的計量數(shù)據(jù)做并行處理,并將結(jié)果分別寫回日志服務(wù)服務(wù);然后可以將所有 Shard 產(chǎn)生文件進行聚合,寫入表格存儲 OTS,最后為每個用戶生成賬單。工作流支持對流程中的單個步驟失敗進行重試,降低流程失敗概率。工作流支持動態(tài)并行任務(wù)執(zhí)行,實現(xiàn)數(shù)據(jù)處理能力的高可擴展性。
銘師堂峰值流量破萬后的實時 ETL 任務(wù)解決方案
業(yè)務(wù)背景
杭州銘師堂,一家在線教育高科技企業(yè),成立十余年來一直致力于用“互聯(lián)網(wǎng)+教育”的科技手段讓更多的學(xué)生能享有優(yōu)質(zhì)的教育。學(xué)生做完作業(yè)后,會將作業(yè)拍照,然后上傳到作業(yè)批閱系統(tǒng),后端系統(tǒng)此時會有多個動作:
- 將作業(yè)照片上傳到 OSS;
- 將用戶作業(yè)信息落到數(shù)據(jù)庫;
- 發(fā)送消息到 Kafka,通過 Kafka Connector 驅(qū)動實時 ETL 任務(wù);
該 ETL 任務(wù)承載了所有的處理邏輯,通過圖像識別和數(shù)據(jù)分類算法,自動識別作業(yè)的完成情況。在一年的大多數(shù)時間里,業(yè)務(wù)流量都比較平穩(wěn),但在寒暑假時,一般會迎來一年中的高峰,在 2022 年暑假期間,平均每天需要處理 100 多萬條作業(yè)圖片處理,峰值流量更是達到了萬級別。
業(yè)務(wù)痛點
銘師堂的 ETL 任務(wù)原先部署在 Kubernetes (簡稱 K8s),通過訂閱 Kafka 的 topic,獲取數(shù)據(jù)路徑,從 OSS 獲取數(shù)據(jù)進行處理,涉及到數(shù)據(jù)并發(fā)度的處理,主要存在兩方面問題:
- Kafka 消費端并發(fā)度受限于 topic partition,消費端數(shù)最多只能跟 partition 數(shù)齊平,超過時會導(dǎo)致部分消費端無法訂閱數(shù)據(jù);
- 消費端將消費到的數(shù)據(jù)進行 ETL,K8s 方案銘師堂在實現(xiàn)時將消費端數(shù)和 partition 保持一致,但因為 K8s 的彈性策略相對滯后,平峰時問題不大,但高峰期因彈性不足會經(jīng)常導(dǎo)致任務(wù)堆積,實時性無法保證;
為了保證 ETL 任務(wù)的實時性,銘師堂架構(gòu)組一直在尋求一種彈性能力更強的新架構(gòu)。經(jīng)過實測對比,基于阿里云函數(shù)計算 FC 構(gòu)建的實時 ETL 任務(wù)解決方案是最適配銘師堂業(yè)務(wù)需求,且彈性能力最強、成本最優(yōu)的選擇。
解決方案
銘師堂基于函數(shù)計算構(gòu)建的實時 ETL 任務(wù)解決方案步驟如下:
- 用戶提交作業(yè)出發(fā)提交流程,將請求打到后端服務(wù)。;
- 后端服務(wù)將用戶提交的作業(yè)圖片上傳到 OSS,并將 OSS 地址作為一條消息發(fā)送到 Kafka;
- 函數(shù)計算的 Kafka 觸發(fā)器實時的感知 Kafka topic,當(dāng)有新數(shù)據(jù)到達,實時觸發(fā)函數(shù)處理;
- 函數(shù)計算獲取到事件數(shù)據(jù),從 OSS 獲取數(shù)據(jù),并對數(shù)據(jù)進行處理,將處理結(jié)果發(fā)回到 Kafka topic;
- 后端程序訂閱 Kafka topic,對處理結(jié)果進行存儲和下一步的展示;
業(yè)務(wù)收益
以上解決方案整體開發(fā)流程順利,項目上線后有超出預(yù)期的收益:
- 執(zhí)行時間快:業(yè)務(wù)高峰期,對比 K8s 方案,單請求響應(yīng)時延 100~200ms,函數(shù)計算 FC 方案則維持在 50ms 左右,大大超出預(yù)期。經(jīng)過分析,主要原因在于函數(shù)計算 FC 資源隔離,每個任務(wù)實例均獨占計算資源,高峰期突發(fā)流量來臨時也不會出現(xiàn)資源爭搶,ETL 任務(wù)的執(zhí)行性能得到保障;
- 彈性效率高:K8s 方案依賴 metrics 數(shù)據(jù)“滯后”地執(zhí)行 HPA 策略調(diào)度資源,而 FC 方案則依賴任務(wù)并發(fā)“提前”實時調(diào)度資源。業(yè)務(wù)高峰期,正在執(zhí)行的 ETL 任務(wù)獨占實例,而新任務(wù)則通過 FC 的“百毫秒彈性能力”實時拉起新實例,F(xiàn)C 會最大化地復(fù)用實例,減少因為“冷啟動”而帶來的實時性、利用率損耗;
- 提效還降本:對比 K8s 方案需要預(yù)留和管控資源水位,基于 FC 的實時 ETL 任務(wù)解決方案實現(xiàn)了按需調(diào)度、按量付費,沒有任務(wù)時資源縮 0,高峰期按業(yè)務(wù)需求實時調(diào)度資源,利用率大大提升。且函數(shù)計算 FC 定向減免來自阿里云消息隊列 Kafka 的函數(shù)調(diào)用次數(shù)費用,業(yè)務(wù)成本得到進一步優(yōu)化。
銘師堂將業(yè)務(wù)上線到函數(shù)計算 FC 后,很好地解決了 K8s 方案高峰期的任務(wù)堆積問題,且通過函數(shù)計算 FC 內(nèi)置的監(jiān)控和日志服務(wù),問題排查效率也得到提升。當(dāng)然最重要的一點,銘師堂通過函數(shù)計算 FC 的實時彈性,不再需要提前規(guī)劃資源、預(yù)留水位、冗余備份,資源成本大幅降低。
開通函數(shù)計算獲試用額度
函數(shù)計算為首次開通服務(wù)的用戶提供免費試用額度,試用額度的有效期為3個月,自購買之日起,超出試用額度的部分均會計入按量付費。試用額度的詳細信息如下。
- GPU試用額度:前100萬GB*秒GPU資源使用免費。
- vCPU試用額度:前50萬vCPU*秒vCPU資源使用免費。
- 內(nèi)存試用額度:前200萬GB*秒內(nèi)存資源使用免費。
- 函數(shù)調(diào)用試用額度:前800萬次函數(shù)調(diào)用免費。
除以上試用額度,2023年12月19日0時之后,函數(shù)計算還為首次開通服務(wù)的用戶發(fā)放有效期3個月,每個月100 GB的CDT公網(wǎng)流量試用額度。
鏈接匯總
計費詳情:https://help.aliyun.com/zh/fc/product-overview/billing-overview
函數(shù)計算官網(wǎng):https://www.aliyun.com/product/fc
總結(jié)
以上是生活随笔為你收集整理的定向减免!函数计算让 ETL 数据加工更简单的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 魔搭+ 函数计算_ 一键部署,缩短大模型
- 下一篇: CPLEX通过Python API获取G