業(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)此時會有多個動作：

1. 將作業(yè)照片上傳到 OSS；
2. 將用戶作業(yè)信息落到數(shù)據(jù)庫；
3. 發(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ā)度的處理，主要存在兩方面問題：

1. Kafka 消費端并發(fā)度受限于 topic partition，消費端數(shù)最多只能跟 partition 數(shù)齊平，超過時會導(dǎo)致部分消費端無法訂閱數(shù)據(jù)；
2. 消費端將消費到的數(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ù)解決方案步驟如下：

1. 用戶提交作業(yè)出發(fā)提交流程，將請求打到后端服務(wù)。；
2. 后端服務(wù)將用戶提交的作業(yè)圖片上傳到 OSS，并將 OSS 地址作為一條消息發(fā)送到 Kafka；
3. 函數(shù)計算的 Kafka 觸發(fā)器實時的感知 Kafka topic，當(dāng)有新數(shù)據(jù)到達，實時觸發(fā)函數(shù)處理；
4. 函數(shù)計算獲取到事件數(shù)據(jù)，從 OSS 獲取數(shù)據(jù)，并對數(shù)據(jù)進行處理，將處理結(jié)果發(fā)回到 Kafka topic；
5. 后端程序訂閱 Kafka topic，對處理結(jié)果進行存儲和下一步的展示；
   

業(yè)務(wù)收益

以上解決方案整體開發(fā)流程順利，項目上線后有超出預(yù)期的收益：

1. 執(zhí)行時間快：業(yè)務(wù)高峰期，對比 K8s 方案，單請求響應(yīng)時延 100～200ms，函數(shù)計算 FC 方案則維持在 50ms 左右，大大超出預(yù)期。經(jīng)過分析，主要原因在于函數(shù)計算 FC 資源隔離，每個任務(wù)實例均獨占計算資源，高峰期突發(fā)流量來臨時也不會出現(xiàn)資源爭搶，ETL 任務(wù)的執(zhí)行性能得到保障；
2. 彈性效率高：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ù)用實例，減少因為“冷啟動”而帶來的實時性、利用率損耗；
3. 提效還降本：對比 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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。