背景

結合《螞蟻金服面對億級并發場景的組件體系設計》，我們能夠通盤了解支付寶移動端基礎組件體系的構建之路和背后的思考，本文基于服務端組建體系的大背景下，著重探討“自動化日志手機與分析”在支付寶 App 內的演進之路。

支付寶移動端技術服務框架

這是整個支付寶移動端無線基礎團隊的技術架構圖，同時螞蟻金服體系內的其他業務 口碑、網商銀行、香港支付寶、天弘基金等) 通過移動開發平臺 mPaaS進行代碼開發、打包、灰度發布、上線、問題修復、運營、分析。因此，mPaaS 源自于支付寶移動端的核心技術架構，并在 App 全生命周期的每個環節提供特定的能力支持。接下來，我們將著重分享“日志診斷”和“移動分析”兩個能力背后的架構演進和選型思考。

支付寶移動端技術服務框架：數據分析框架

如圖所示，即數據分析能力的技術架構圖，其中“數據同步”、“埋點SDK”、“日志網關”是移動端專屬的能力，其余部分是所有的數據分析平臺都必須具備的數據結構。

1. 日志采集

接下來我們重點分析支付寶移動端的日志采集框架，首先第一部分是“日志 SDK”，日志 SDK 會向業務層提供一個埋點接口，使用起來就和 Java 里面的 logger.info 的感覺一樣：業務層只需要把想記錄的信息傳遞給日志 SDK。日志 SDK 會在拿到業務日志后，去系統內部獲取相關的系統級別的上下文信息，比如機型、操作系統版本、App 版本、手機分辨率、用戶ID (如果用戶登錄了)、設備ID、上一個頁面、當前頁面等，接著把這些信息與業務日志內容整合成一個埋點，然后記錄到設備的硬盤上。對，只是記錄到硬盤上，并沒有上報到服務端。

日志 SDK 會在合適的時機，去和日志網關交互，判斷獲取什么樣的日志、什么級別的日志可以上報。如果可以上報，是以什么頻率上報、在什么網絡條件下上報。因此通過日志 SDK 與日志網關的交付，我們可以來實現日志的策略式降級。日志的策略式降級這點對于支付寶特別重要，因為目前支付寶的體量，日常的日志上報量為約 30W 條日志/s；而在大促的時候，日志量會是日常的幾十倍！ 所以，如果大促期間不采用任何的日志降級策略的話，我們的帶寬會被日志打包，支付寶的正常業務功能就不可用了。

由此，我們可以總結，在大促高并發場景下，我們需要只保留關鍵日志的上傳，其余日志統統降級。即使是日常業務處理，我們也只允許日志在 WIFI 條件下上報，防止發生流量相關的投訴。

埋點網關除了提供日志上報的策略開關能力之外，就是接收客戶端的日志。它在接受到客戶端日志之后，會對日志內容進行校驗，發現無效的日志會丟棄掉。而對有效合法的埋點，會根據客戶端上報的公網 IP 地址，反解出城市級別的地址位置信息并添加到埋點中，然后將埋點存放在它自己的硬盤上。

2. 埋點分類

經過多年的實踐，支付寶把日志埋點分為了四類。

（1）行為埋點：用于監控業務行為，即業務層傳遞的日志埋點屬于行為埋點，行為埋點屬于“手動埋點”，需要業務層開發同學自己開發。不過也不是全部的業務行為都需要業務方手動開發，有一些具備非常通用性的業務事件，支付寶把它們的埋點記錄放到了框架層，如報活事件、登錄事件。因此，行為埋點也可以叫做 "半自動埋點"。

（2）自動化埋點：屬于“全自動化埋點”，用于記錄一些通用的頁面級別、組件級別的行為，比如頁面打開、頁面關閉、頁面耗時、組件點擊等。

（3）性能埋點：屬于“全自動化埋點”，用于記錄 App 的電量使用情況、流量使用、內存使用、啟動速度等。

（4）異常埋點：屬于“全自動化埋點”，嚴格上講，也算是性能埋點的一種。但是它記錄的是最關鍵的最直接影響用戶的性能指標，比如 App 的閃退情況、卡死、卡頓情況等。這類埋點，就屬于即時大促期間也不能降級的埋點！

圖中的代碼示例即為一條行為埋點樣例，大家可以看到，埋點實際上就是一條 CSV 文本。我們可以看到里面有日志網關添加進行的地址位置信息內容，也有日志 SDK 給添加的客戶端設備信息。

3. 日志處理模型

下面我們來整體了解支付寶內部日志處理的通用流程：

（1）日志切分

我們已經了解到，埋點實際上即為一段 CSV 文本。而所謂日志切分呢，即將 CSV 格式的文本轉成 KV，通俗點說就是內存里面的 HASHMAP。這個切分的過程，可以直接根據逗號進行切換，當然也還有很多其他的辦法。

（2）日志切換

日志埋點中的內容，并不是直接可以拿來進行分析的。比如客戶端啟動時間，相關數據是按照毫秒級別的顆粒度進行上報，但實際應用上我們只需要把數據分析到某個特定區間內的個數，所以在處理之前一般會做一個具體啟動時間到截止時間范圍編碼的映射。除了這種轉換之外，還會有一些白名單、黑名單之類的過濾轉換。

（3）維表影射

因為客戶端并不能拿到業務方需要分析的所有數據維度，如用戶的性別、職業等內容，因此在真實分析之前，我們可以通過維表映射，將日志埋點中的用戶 ID 映射成業務層面的具體屬性來進行后續的分析。

（4）UID 的濾重

UID 濾重的指標有兩種：一種是 PV 指標，一種是 UV 指標。

UV 指標在做具體的計算之前，要做一步 UID 去重。所謂 UID 去重就是指檢查這個 ID 在一定時間范圍內有沒有出現過，如果出現過，那么這條記錄就必須丟棄了。UV 是有時間周期的概念的，比如日 UV、小時 UV、分鐘 UV、月 UV 等。

（5）指標聚合

在完成了上述的所有過程后，終于要進行指標的計算了。計算的方式包括求和、平均值、最大值、最小值、95 百分位。

（6）結果寫出

就是指把計算的指標的結果輸出到各種存儲或者通過接口發送給 mPaaS 的客戶。目前我們的計算方式有三大類，實時計算、即時計算和離線計算。下面我會介紹這三種計算方式。

• 實時計算

實時計算模式：接收到日志后，模型立即開始進行計算，數據結果將在N分鐘(N<=2)內產出，延遲非常的低。

推薦用作實時計算的技術選型包括：1) Flink 2) Spark 3) Storm (阿里做的 JStorm） 4) akka；其中 akka 適合用作業務邏輯較輕的實時監控和報警；關鍵的業務大盤、日志翻譯回放這些都用 Flink 做比較好。

簡單總結如下：

實時計算的優勢是產出結果速度快、資源消耗少、靈活度中等；
實時計算的劣勢是學習曲線相對陡峭、維護成本較高、配置復雜度高。

• 離線計算

離線計算模式：接收到日志后，直接保存下來，不做任何處理。待日志量積攢一段時間后，模型可進行一次性處理多日或者多月的日志數據。

推薦用作實時計算的技術選型包括: 1) Flink 2) Spark 3) Hive 4) Hadoop；大家看到了 FLINKSPARK 也出現在了實時模型的推薦技術選擇中。這兩個技術呢，分別從不同的起點出發，達到了相同的終點。

Flink 一開始是只做實時計算的，后來他開始提供批量離線計算能力；Spark 則正好相反。我們目前呢，還是充分利用每個技術棧的最大優勢，離線還是選擇 Spark，而不是 Flink。在這里多說兩句，之前有一個經典架構是 “Lambda”模型，是指實時計算的結果要在離線里面再算一遍，這是因為之前總會出現實時計算丟數據、計算不準的情況，所以實時計算出來的結果只是用來觀察一個趨勢，再等第二天用離線的結果做補充，從而確保業務方能夠看到準確的數據。但是在谷歌的 data-flow 計算模型的論文出來之后，目前市面上的實時計算引擎都具備了 "exactly-once" 的計算能力，換句話說，實時計算不會再出現丟數據以及計算不準的問題了。目前雖然還有“Lambda”模型，即數據會流向實時計算、離線計算兩個引擎，但是離線不再是為實時計算做補充，而是為了充分利用它的性能，計算多日、多月的指標。

簡單總結如下：

離線計算的優勢是 計算性能高、學習難度低；
離線計算的劣勢是 消耗資源大、延遲高、靈活度偏低。

• 即時計算

即時計算模式：接收到日志后，只做簡單的預處理，比如日志切分，之后就直接入庫。在需要展示界面的時候，根據用戶配置的過濾和聚合規則即時進行數據處理。

推薦用作即時計算的的技術選型包括: Clickhouse (來自俄羅斯 yandex)、Apache Druid (來自 MetaMarket)、 Pinot (來自 ：LinkedIn)。支付寶內部將即時計算模型應用到下鉆分析、漏斗分析這些場景中，有時候也直接把它當做 OLAP 數據庫使用。

簡單總結如下：

即時計算的優勢是超高靈活度、任務維度UV聚合、無限下鉆能力、交付式的查詢延遲(15s內)、學習成本低；
即時計算的劣勢是資源消耗巨大、延遲中等無法用于做實時監控與報警、維度成本高，結構復雜。

這是目前支付寶內部的一個即時計算框架的技術架構圖。從圖中可以看出來目前即時計算的技術架構包括用來接收數據寫入的實時日志節點（Read-time Nodes）、用于存儲歷史數據的深度存儲（HDFS、AFS、OSS 等多種類型）、用來對歷史數據（一天以前的數據）提供查詢分析能力的歷史節點（historical）。這個計算框架完全的支持 MySQL 協議，用戶可以直接用 MySQL 客戶端對其進行操作。還有一個重要特性是，他可以對任意的外部數據聯合進行分析。

• 日志處理模型

我們再總結一下三種計算模式：

實時計算模型：數據攝入后立即按照預定規則執行計算，并在N分鐘內產出需要的計算結果。

適用場景: 實時監控預警、鏈路追蹤

優勢: 消耗資源少、產出速度快

劣勢: 配置復雜度高，靈活度低

離線計算模型：數據攝入后積攢N 小時/天 后按照預定規則進行批量處理。

適用場景: 用戶分群、數據集市

優勢:性能高、學習成本低

劣勢: 延遲高、靈活度低

即時計算模型：數據攝入后只做簡單的預處理立即入庫，待查詢時根據查詢需求實時計算出指標。

適用場景: 下鉆分析、漏斗分析

優勢: 靈活度高、學習成本低

劣勢: 資源消耗巨大、延遲中

希望大家能夠根據我們的推薦選擇適合的技術棧。

• 動態埋點

說完了我們目前的埋點類型、埋點計算模型，下面來說一下我們目前在內部使用的下一代埋點框架，動態埋點。

我們先針對以上四個問題進行思路串聯，每個問題我也給出了相應的思路和解決辦法。那么，這些答案是針對以上問題的最優解或者唯一解嗎？很顯然不是，因為這些解法都會帶來開發量。而對于客戶端來說，新的開發量就要發布版本，同時開發新的埋點，也可能會導致 App 內部的埋點臃腫不堪。

什么是動態埋點呢？有三個核心概念1) 埋點集、2) 動態埋點上報規則、3) 指標計算動態配置。

有了以上三項能力和配置，我們便可以根據現有的埋點集來配置某個鏈路的監控埋點，并依據這個復雜埋點來定義具體的指標的計算規則，從而做到不用增加開發量，同樣可以快速監控新的指標的效果。不僅如此，我們還能夠讓埋點變成一種通用的資源，讓大家更好地去使用它，而不是無謂地增加埋點，使得代碼變得更臃腫。

讓我們一起看一下動態埋點框架的一些 UI 交付圖。

相應的，我們再對焦看一下支付寶埋點相關的應用服務：實時日志拉取。其中，它的主要技術框架包括了 mPaaS 里面的 MPS (消息推送)、MSS(數據同步)、以及日志網關。這是因為螞蟻系 App 會與 MPS (安卓系統)、MSS (蘋果系統) 保持長連接，在需要實時拉取日志的時候，用戶可以在 mPaaS 的控制臺上面通過這兩個渠道下發指令，然后客戶端就會把加密的明細日志全部上報到日志網關。

這是實時日志拉取的界面操作展示圖。

針對于非常重要的性能指標: 閃退、卡頓、卡死， mPaaS 根據多年經驗準備了對應的大盤。如圖所示，上半部分是每分鐘的閃退數，下面是我們根據閃退分類算法梳理出來的各個閃退分類情況，針對每個分類大盤里我們還能看到具體的設備分布情況。

最后，讓我們從邏輯結構上再梳理一下 mPaaS 的服務端結構。mPaaS 包含五個核心組件:

1)?MGS（網關服務）：將客戶端的請求轉發到業務服務器.

2)?MDS（發布服務）：為客戶端提供多種資源的多種灰度策略發布能力。

3)?MPS & MSS（消息推送和數據同步服務）：以長連接為基礎，來提供數據下發能力。

4)?MAS,（分析服務）：也是今天講解的重點，以日志埋點為基礎的分析能力。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的自动化日志收集及分析在支付宝 App 内的演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。