UPYUN Open Talk：51 信用卡日誌分析變遷史

首先恭喜 UPYUN 的好夥伴 51信用卡 得到B輪 5000萬美圓的融資。51 信用卡管家是國內信用卡管理第一品牌。自 12 年創業開始，至 14 年開始的 「瞬時貸」上線，15年完成p2p金融信貸服務。51 信用卡的 CTO 殷鵬翔在 UPYUN Open Talk 《移動時代互聯網金融的架構趨勢》主題線下沙龍中，分享了 51 信用卡的日誌分析演變過程。

1、 日誌變遷過程
一、12 年初創期，用戶數量在 50 萬之內，處於原始數據積累期。日誌分析主要用來關注天天新增用戶、新增郵箱總數。整個系統徹底同步處理數據庫，只有業務處理、業務展現兩個簡單的層級結構。
二、規模性增加期，用戶量到達 200 萬，日誌慢慢開始轉向爲運營和產品服務。在運營層面，關注轉化率（郵箱轉化率，設備新增數等）；產品層面，基於點擊量判斷產品功能、系統流程的好壞，以及關注系統穩定性（應用層故障指標，同步報警等）。在這個階段，數據處理的方式也由同步處理轉變成異步處理。
三、高度增加期，當用戶量達到 500 萬時，業務耦合性高。爲了不資源浪費，建立了統一的數據分析接口，將全部日誌所有彙總到一個數據統計分析平臺，各業務線複用數據處理平臺。

2、日誌變遷中技術細節

在引入日誌分析前，最先的方式是 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 中聚合和相關性分析，獲得相關性模型。這就是整個數據分析平臺化的過程。

咱們下一步的目標是引入規則引擎，由於整個統計過程當中，包括計算都是一個規則，若是全部的規則都作好了，這種算法是徹底規則化的。引入引擎以後咱們應用層的開發量就比較少了，但定製量比較多，業務人員和運營人員就能夠配置規則進行數據統計分析。

UPYUN Open Talk是 UPYUN 發起主辦的行業技術沙龍，旨在以邀請各行各業優秀的企業技術負責人分享介紹本身工做過程當中的技術架構經驗的方式，推進整個移動互聯網時代的企業員工的我的技術成長，從「人」這個關鍵點的我的成長提高去幫助推進企業的快速成長。