計量日志記錄了使用者涉及計費的項目，背景計費子產品根據計費項和規則進行運算，産生最後賬單。例如如下原始通路日志記錄了項目（project）使用情況：
計量計費程式讀取原始日志，根據規則生成使用者在各次元使用資料（包括流量、使用次數、出流量等）：
讓我們看下幾個計量日志計費場景：
電力公司：每10秒會收到一條日志，記錄該10秒内每個使用者id下該周期内功耗、峰值、均值等，每天、每小時和每月給使用者提供賬單
營運商：每隔10秒從基站收到時間段内某個手機号碼的動作（上網、電話、短信、voip），使用量（流量），時長等資訊，背景計費服務統計出該區間内消耗資費
天氣預測api服務：根據使用者調用接口類型、城市、查詢類型、結果大小等對使用者請求進行收費
既要算對，又要算準是一件要求很高的事情，系統要求如下：
準确可靠：多算使用者吃虧，少算我們吃虧
靈活：支援補資料等場景，例如一部分資料沒有推過來，當需要修正時可以重新計算
實時性強：能夠做到秒級計費，對于欠費場景快速切斷
其他需求（plus）：
賬單修正功能：在實時計費失敗時，我們可以通過理想計費進行對賬
查詢明細：支援使用者檢視自己消費明細
現實中還有兩類不小的挑戰：
不斷增長資料大量：随着使用者以及調用上升，資料規模會越來越大，如何保持架構的彈性伸縮
容錯處理：計費程式可能有bug，如何確定計量資料與計費程式獨立
這裡我們讨論一種阿裡雲基于日志服務開發計量計費方案，該方案已線上上穩定運作多年，從未出現過一粒算錯，延遲等情況，供單價參考
使用loghub進行計量日志實時采集與計量程式對接：loghub 支援的30+種api和接入手段，接入計量日志非常容易
計量程式每隔固定時間消費loghub中步長資料，在記憶體中計算結果生成計費資料
（附加）對明細資料查詢需求，可以将計量日志配置索引查詢
（附加）将計量日志推送至oss、maxcompute進行離線存儲，進行t+1等對賬與統計
實時計量程式内部結構：
在記憶體中進行資料統計與計算，拿到結果，生成計費資料
(我們可以以此類推，把選擇時間計算邏輯修改為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種手段：
我們對于産生計量日志程式進行改造（例如nginx），先在記憶體中做了聚合，每隔1分鐘dump一次該時間段聚合的彙總計量日志結果。這樣資料量就和總體的使用者數相關了：假設nginx該時間段内有1000個使用者，一個小時資料點也才1000 200 60 = 12gb（壓縮後為 240 mb）
loghub下每個日志庫可以配置設定不同shard（分區），我們可以配置設定3個分區，3個計量消費程式。為了保證一個使用者計量資料總是由一個消費程式處理，我們可以根據使用者id hash到固定shard中。例如杭州市西湖區使用者寫在1号shard，杭州上城區使用者資料寫在2号shard，這樣背景計量程式就可水準擴充。
loghub 下每個logstore可以設定生命周期（1-365天），如果計費程式需要重新消費資料，在生命周期内可以任意根據時間段進行計算。
在對loghub中資料打開索引後，即可實時實時查詢與分析
也可以在查詢後加上統計分析：