564
汽車大全
日誌係列--計量日誌處理方案
使用雲服務最大好處是按量付費，無需預留資源，因此各雲產品都有計量計費需求。這裏我們介紹一種基於日誌服務計量計費方案，該方案每天處理千億級計量日誌，被眾多雲產品使用：
計量日誌生成計費結果過程
計量日誌記錄了用戶涉及計費的項目，後台計費模塊根據計費項和規則進行運算，產生最後賬單。例如如下原始訪問日誌記錄了項目（Project）使用情況：
microtime:1457517269818107 Method:PostLogStoreLogs Status:200 Source:10.145.6.81 ClientIP:112.124.143.241 Latency:1968 InFlow:1409 NetFlow:474 OutFlow:0 UserId:44 AliUid:1264425845278179 ProjectName:app-myapplication ProjectId:573 LogStore:perf UserAgent:ali-sls-logtail APIVersion:0.5.0 RequestId:56DFF2D58B3D939D691323C7
計量計費程序讀取原始日誌，根據規則生成用戶在各維度使用數據（包括流量、使用次數、出流量等）：
讓我們看下幾個計量日誌計費場景：
- 電力公司：每10秒會收到一條日誌，記錄該10秒內每個用戶ID下該周期內功耗、峰值、均值等，每天、每小時和每月給用戶提供賬單
- 運營商：每隔10秒從基站收到時間段內某個手機號碼的動作（上網、電話、短信、VoIP），使用量（流量），時長等信息，後台計費服務統計出該區間內消耗資費
- 天氣預測API服務：根據用戶調用接口類型、城市、查詢類型、結果大小等對用戶請求進行收費
要求與挑戰
既要算對，又要算準是一件要求很高的事情，係統要求如下：
- 準確可靠：多算用戶吃虧，少算我們吃虧
- 靈活：支持補數據等場景，例如一部分數據沒有推過來，當需要修正時可以重新計算
- 實時性強：能夠做到秒級計費，對於欠費場景快速切斷
其他需求（Plus）：
- 賬單修正功能：在實時計費失敗時，我們可以通過理想計費進行對賬
- 查詢明細：支持用戶查看自己消費明細
現實中還有兩類不小的挑戰：
- 不斷增長數據大量：隨著用戶以及調用上升，數據規模會越來越大，如何保持架構的彈性伸縮
- 容錯處理：計費程序可能有Bug，如何確保計量數據與計費程序獨立
這裏我們討論一種阿裏雲基於日誌服務開發計量計費方案，該方案已在線上穩定運行多年，從未出現過一粒算錯，延遲等情況，供單價參考
係統架構
以阿裏雲日誌服務的LogHub功能為例：
使用LogHub進行計量日誌實時采集與計量程序對接：LogHub 支持的30+種API和接入手段，接入計量日誌非常容易
計量程序每隔固定時間消費LogHub中步長數據，在內存中計算結果生成計費數據
（附加）對明細數據查詢需求，可以將計量日誌配置索引查詢
-
（附加）將計量日誌推送至OSS、MaxCompute進行離線存儲，進行T+1等對賬與統計
實時計量程序內部結構：
根據LogHub讀取接口GetCursor功能，選定某個時間段日誌（例如10：00-11：00）Cursor
通過PullLogs接口消費該時間段內數據
-
在內存中進行數據統計與計算，拿到結果，生成計費數據
(我們可以以此類推，把選擇時間計算邏輯修改為1分鍾，10秒鍾等)
性能分析：
- 假設有10億條/天計量日誌，每條長度為200字節，數據量為200GB
- LogHub 默認SDK或Agent都帶壓縮功能，實際存儲數據量為40GB（一般至少有5倍壓縮率），一個小時數據量為40/24 = 1.6GB
- LogHub讀取接口一次最大支持讀1000個包（每個包最大為5MB），在千兆網條件下2秒內即可讀完
- 加上內存中數據累計與計算時間，對1小時計量日誌進行匯總，不超過5秒
數據量大如何解決，例如一天十萬億
在一些計費場景下（例如運營商、IoT等）計量日誌量會很大（例如十萬億，數據量為2PB/Day)，折算壓縮數據後一小時有16TB，以萬兆網絡讀取需要1600秒，已不能滿足快速出賬單需求。
這裏一般使用2種手段：
1. 控製產生的計費數據量
我們對於產生計量日誌程序進行改造（例如Nginx），先在內存中做了聚合，每隔1分鍾Dump一次該時間段聚合的匯總計量日誌結果。這樣數據量就和總體的用戶數相關了：假設Nginx該時間段內有1000個用戶，一個小時數據點也才1000 * 200 * 60 = 12GB（壓縮後為 240 MB）
5. 將計量日誌處理並行化
LogHub下每個日誌庫可以分配不同Shard（分區），我們可以分配3個分區，3個計量消費程序。為了保證一個用戶計量數據總是由一個消費程序處理，我們可以根據用戶ID Hash到固定Shard中。例如杭州市西湖區用戶寫在1號Shard，杭州上城區用戶數據寫在2號Shard，這樣後台計量程序就可水平擴展。
其他問題
1.補數據怎麼辦？
LogHub 下每個Logstore可以設置生命周期（1-365天），如果計費程序需要重新消費數據，在生命周期內可以任意根據時間段進行計算。
2. 計量日誌散落在很多服務器（前端機）怎麼辦
- 使用Logtail Agent實時采集
- 使用機器標示定義一套動態機器組彈性伸縮
3. 查詢明細需求如何滿足
對LogHub中數據可以創建索引，支持實時查詢與統計分析，例如我們想調查有一些特別大的計量日誌：
Inflow>300000 and Method=Post* and Status in [200 300]
在對Loghub中數據打開索引後，即可實時實時查詢與分析
也可以在查詢後加上統計分析：
Inflow>300000 and Method=Post* and Status in [200 300] | select max(Inflow) as s, ProjectName group by ProjectName order by s desc
4. 存儲日誌並進行T+1對賬
日誌服務提供LogHub中數據投遞功能，支持自定義分區、自定義存儲格式等將日誌存儲在OSS/MaxCompute上，利用E-MapReduce、MaxCompute、HybridDB、Hadoop、Hive、Presto、Spark等進行計算。
最後更新：2017-07-12 09:02:48