殷鵬翔：51信用卡的日志分析變遷史和技術細節

編者按： 51 信用卡管家是國內信用卡管理第一品牌。自 12 年創業開始，至 14年開始的“瞬時貸”上線，15年完成p2p金融信貸服務。51 信用卡 的 CTO 殷鵬翔在 UPYUN Open Talk “移動時代互聯網金融的架構趨勢”主題線下沙龍中，分享了 51 信用卡的日志分析演變過程：

一、 日志變遷過程

1. 12 年初創期，用戶數量在 50 萬以內，處于原始數據積累期。日志分析主要用來關注每天新增用戶、新增郵箱總數。整個系統完全同步處理數據庫，只有業務處理、業務展示兩個簡單的層級結構。

2. 規模性增長期，用戶量到達 200 萬，日志慢慢開始轉向為運營和產品服務。在運營層面，關注轉化率（郵箱轉化率，設備新增數等）；產品層面，基于點擊量 判斷產品功能、系統流程的好壞，以及關注系統穩定性（應用層故障指標，同步報警等）。在這個階段，數據處理的方式也由同步處理轉變成異步處理。

3. 高度增長期，當用戶量達到 500 萬時，業務耦合性高。為了避免資源浪費，創建了統一的數據分析接口，將所有日志全部匯總到一個數據統計分析平臺，各業務線復用數據處理平臺。

二、日志變遷中技術細節

在引入日志分析前，最早的方式是 DB Select Count 的形式，整個系統采用同步處理的方式，一臺 Nginx 做前端，兩臺 DB，兩臺 Sever，簡單處理數據，展示結果。

最初采用同步日志結構，所有東西都保存 Queue 里面，有一個線程掃描 Queue。當時訪問量較少，用了六臺機器，完全用 JVM 內存保 存瞬時數據，使用線程池保證異步數據處理。問題是并發峰值、井噴訪問的時候，線程池過大就很容易導致內存溢出，線程死鎖也比較嚴重，導致 JVM 崩潰， 內存里面的數據就全部丟失了。在數據量初步增長期，可以接受，但一旦達到一定規模后就完全無法承擔。數據還有高峰低谷期的差別，需要以高峰期的資源配置保 證整個系統的正常運行，因此加到了 20 個 JVM 存放數據。當日志量成倍增加的時候，明顯感覺到當前的架構遇到了性能瓶頸，這時我們考慮到需要采用 異步流程。

在日志收集過程中，我們增加了一個 MongoDB Capped Collection 模塊。Capped Collection 的好處是 有一個固定的結合點，比如說保存 10G、50G 的集合，先寫入到 Capped Collection 中。它的性能很高，順序插入速度很快，插入的 時候每個數據有一份 Object ID。在插入最新數據的時候，淘汰最早的數據。所有的數據都是暫存MongoDB 里面，一旦這個數據超過 了 50G，前面的數據會摘掉，這樣可以排除前面的異常數據。最后根據一秒偽實時，保證數據都是順序的處理。因為 Object ID 不同的機器收集的 數據不是完全順序的，系統允許一秒鐘的偽實時算法，能夠拋棄一秒鐘的數據。

現在用 Fluentd 的方式收集日志，通過 Fluentd 實時采集到 Dashbroad，放 到 MongoDB 的 Capped Collection 中。第二個就是 Log4j Append，Append 主要是采集系統應用層的數據， 還有一些實時數據（比如頁面的點擊數）。部分行為日志會將實時數據采集到 MongoDB 的 Capped Collection。接下來 是 Schedule，線程定時掃描收集到得日志進行分析統計，在同一個 Schedule 里面會存三份數據，一份存到 Result 作為統計結果， 一份數據存到 HDFS，主要作為離線的數據預演，還有一份保存到 SolrCloud。 SolrCloud 最早是把它作為一個搜索引擎，也是為了一 些預演，在 SolrCloud 上面做了一些定制，可以做很多維度的統計。在這個系統里面，SolrCloud 主要用來實時查數據、統計數據和驗證數 據。

在 2014 年的五六月份，我們開始行為數據的收集。在移動互聯網領域，一般都會使用第三方工具來做數據統計，但統計結果不夠詳盡，無法很好地 滿足我們的業務需求。行為日志主要就是統計產品各個方面的日志，包括各個 UI 界面上的點擊數、渠道轉化率，用于控制成本和產品迭代。這些東西在當時沒 有更全面的數據來支撐，而且我們風控團隊希望有更多的基礎數據支撐風控結果驗證。

客戶端的每一個操作我們都會記錄到行為日志中，再通過一定的壓縮規則，上傳到日志服務器中。使用 Hadoop 做離線分析，通過客戶端的實時記錄預測下一個時間段的交易量。實時數據是通過業務網關主要是 HDBS 的方式上傳到服務器上面。

2014 下半年的時候，數據量井噴導致延遲加大，增加業務線需要修改代碼、擴展性差，以及 Mongo 本身分布式能力不夠、單點風險大，MongoDB方式在 15 年無法支撐現有的數據分析和處理的實時性，我們引入了 Storm。

之前的日志系統不能進行數據分級處理，會因某一數據過大，而影響所有分析延遲。比如說由于郵件收集數據過大，瞬時貸的日志會同期往后延遲，這樣的 話任何一筆業務都是在計算以前的數據。這是整個實時數據分析的改進邏輯，我們將網關數據和前端服務器的日志分開處理。現在打算在業務數據采 用 Kafka，訪問數據延用 MongoDB 的方式，系統日志和其余重要的業務數據走 MQ，能保證不同的業務場景使用不同的流處理，分級處理。

現階段基于日志的分析，行為日志、業務服務日志、系統日志和網絡日志都會經過日志分析，也會有中間統計結果。中間統計結果數據會出運營報表、訪問 量統計、系統監控、服務監控以及產品跟蹤，中間結果 ETL、消費行為、風控和授信評分，及其他終端業務產品做數據支撐，用戶數據進入金融產品。在金融產 品逐步增多的過程中，整個 ETL 過程變成最耗時、耗資源的部分。下一步在就是把 ETL 作為整體的數據分析平臺，基于Hadoop HDFS，包 括 map reduce 和 Storm 結合做一個分析平臺。

目前各業務線都要特定的 ETL 目標，上線一個新功能，需要遍歷數據庫，重新編寫獲取元數據。這種情況下，各業務線會用到 90% 相同的數據 處理結果，比如用戶訪問頻次、用戶注冊地、用戶賬單分析結果，便會造成資源浪費和入口不統一。因此，需要搭建一個數據平臺——提供統一數據接口、統一分 析、標準化 IPO 模式，實現 ETL 邏輯。

處理 ETL 目標不一樣，邏輯也不一樣，這需要不同的處理過程，和不同的存儲框架。為實現日志分析平臺化，將日志分為實時和離線兩種形式，足以確保所有數據都經過實時流或離線處理。

實時流處理訪問日志，用于判斷服務器有無被攻擊、后端服務器是否出現異常，以及地區訪問量、業務收入等數據。

Hive 異步離線分析用于分析用戶行為日志。行為日志存儲在手機上，在面臨用戶低頻率啟動應用的情況下，系統半個小時做一次異步離線處理。在這 個過程中，最關鍵的是，用戶的消費數據會根據 ETL目標，進行 Map Reduce 處理或其他處理，采用數據結構較豐富的 Redis 做輸出。最 后會將數據結果輸出到 SAS 中聚合和相關性分析，得到相關性模型。這就是整個數據分析平臺化的過程。

我們下一步的目標是引入規則引擎，因為整個統計過程中，包括計算都是一個規則，如果所有的規則都做好了，這種算法是完全規則化的。引入引擎之后我們應用層的開發量就比較少了，但定制量比較多，業務人員和運營人員就可以配置規則進行數據統計分析。（責編/錢曙光）

作者：2002年~2004年一直從事HIS系統開發實施，2005~2007年信雅達主要從事金融系統研發， 2007后進入互聯網和移動互聯網創業，房途網、快的、51信用卡?。

來自：http://www.csdn.net/article/2015-02-09/2823887