背景

渠道分析系統(tǒng)，是一個多維度數(shù)據(jù)分析系統(tǒng)，旨在為渠道運營和渠道評估提供數(shù)據(jù)支持。隨著精細化運營需求的日益增長，對渠道數(shù)據(jù)的時效性和準確性要求也越來越高。第一代渠道分析系統(tǒng)，數(shù)據(jù)主要依賴離線計算產(chǎn)生，最小時間粒度為小時，其中，“新增用戶數(shù)”對運營人員及時調整策略起到至關重要的作用，但該數(shù)據(jù)的滯后性比較明顯，導致相應的運營決策比較被動，決策效果較差。

本文實現(xiàn)了一種實時計算與離線計算一體化的解決方案，為渠道新增數(shù)據(jù)提供實時、準確、高效的數(shù)據(jù)支撐。本文將從面臨挑戰(zhàn)、解決方案、難點攻克等幾個方面來詳細描述整個方案實施過程。

面臨挑戰(zhàn)

渠道數(shù)據(jù)涉及多種產(chǎn)品線，因此數(shù)據(jù)打點分散，數(shù)據(jù)源較多，其中包括數(shù)據(jù)中心數(shù)據(jù)、商業(yè)化數(shù)據(jù)、反作弊數(shù)據(jù)等。為了建立通用的渠道評估機制，全面的評估渠道質量從而指導結算，由此面臨的挑戰(zhàn)總結如下：

• 數(shù)據(jù)量大。渠道數(shù)據(jù)匯聚了多個產(chǎn)品的數(shù)據(jù)，每天數(shù)據(jù)量約為5~6TB，高峰期可達100MB/s。
• 數(shù)據(jù)復雜度高。產(chǎn)品的多樣性使得數(shù)據(jù)源種類繁多，且原始日志經(jīng)過多重加密，增加了日志解析的復雜度。
• 低延遲。渠道運營數(shù)據(jù)延遲越低，對運營決策的價值越高，而新增數(shù)據(jù)由于其依賴歷史數(shù)據(jù)，其本身計算邏輯存在復雜性，增加了低延遲的處理難度。
• 數(shù)據(jù)準確性要求高。保證渠道評估的準確性才能做到精準投放和公平結算，因此對渠道數(shù)據(jù)的準確性要求較高，需要有數(shù)據(jù)校準機制。

解決方案

1. 總體設計

基于面臨的挑戰(zhàn)本文采用了實時計算分流、離線計算補充校準的方式來滿足上述數(shù)據(jù)要求，以下是整體數(shù)據(jù)處理架構圖。

圖1 架構圖

從圖1中可以看到，本文采用雙寫的方式存儲原始數(shù)據(jù)：實時流式消息隊列存儲和分布式存儲，通過實時計算分流與離線計算補充的方式來實現(xiàn)實時更新數(shù)據(jù)，實時查詢數(shù)據(jù)和實時展現(xiàn)數(shù)據(jù)。

2. 具體實現(xiàn)

正如上文所提到的渠道分析的數(shù)據(jù)量級龐大，數(shù)據(jù)復雜度高，并且新增計算本身具有復雜性，同時需求本身在數(shù)據(jù)低延遲上的要求，在設計過程中，需要考慮：

• 實時流處理復雜數(shù)據(jù)的時間開銷，比如渠道原始數(shù)據(jù)經(jīng)多次加密和壓縮導致解析時間開銷增大;
• 實時計算引擎自身的特性，本文涉及到的是運營投放和結算，對數(shù)據(jù)統(tǒng)計的正確性要求較高;
• 數(shù)據(jù)指標計算的復雜性，新增數(shù)據(jù)計算嚴重依賴歷史庫的數(shù)據(jù)查詢效率;
• 網(wǎng)絡環(huán)境，當不可抗力影響了實時數(shù)據(jù)的產(chǎn)出，及時報警并啟用離線方案校準數(shù)據(jù)。

圖2 數(shù)據(jù)處理流程圖

從圖2中可以看出，為應對大量復雜的數(shù)據(jù)，盡可能降低處理延遲，實時計算部分采用了數(shù)據(jù)分層與分流相結合的技術路線，將數(shù)據(jù)計算流程拉長，采用單功能多階段的數(shù)據(jù)處理方式將數(shù)據(jù)處理拆分為三個階段：日志解析，產(chǎn)品分流和新增計算。在實時處理部分，采用了Flink 和Spark Streaming 相結合的方式。Flink 是一種具有高吞吐、低延遲的實時離線統(tǒng)一的流式數(shù)據(jù)處理引擎，非常適合本文場景中第一階段的日志解析。而Spark Streaming 是微批處理，可以將實時數(shù)據(jù)流輸入的數(shù)據(jù)劃分為一個個小批次數(shù)據(jù)流，保障后續(xù)新增計算中聚合操作穩(wěn)定的分鐘級響應。為了將計算引擎的性能發(fā)揮到最大，將新增計算的延遲降到最低，在數(shù)據(jù)存儲部分，本方案采用了高性能的消息隊列Kafka 和索引速度快的ES 。另外，本文還設計了離線補充校準數(shù)據(jù)的容災方案，以確保異常情況下數(shù)據(jù)的準確性。

下面分別對日志解析，產(chǎn)品分流，新增計算三個處理階段和容災部分的數(shù)據(jù)校準作詳細說明。

3. 日志解析

圖3 日志解析圖解

本階段采用高性能消息隊列Kafka 與低延遲計算引擎Flink相結合的方式進行日志解析。利用Flink的雙流特性，在消費原始日志消息隊列的同時會間隔一定時間同步產(chǎn)品標識信息，在原始日志打點規(guī)則不變的情況下，動態(tài)可配置的按需獲取數(shù)據(jù)，提升了程序的可擴展性和復用性。

4. 產(chǎn)品分流

圖4 產(chǎn)品分流圖解

本階段采用Spark Streaming和ES對合規(guī)數(shù)據(jù)進行分流。經(jīng)過日志解析，數(shù)據(jù)的量級下降，此時，使用Spark Streaming可以將流式數(shù)據(jù)轉換成微批處理，提高ES的更新效率。同時，利用ES 的主鍵唯一性，按照不同的產(chǎn)品標識進行數(shù)據(jù)更新。因此，ES中始終維護著一個包含所有歷史記錄數(shù)據(jù)的大表，即累計新增庫。

5. 新增計算

本階段利用ES自身的高性能，按照產(chǎn)品類別定期查詢ES以達到統(tǒng)計小時新增和累計新增的目的。借助之前的兩個階段，日志解析和產(chǎn)品分流，將新增計算的響應速度從小時級降到分鐘級，使得運營人員在做出決策調整投放策略后，可以在分鐘級看到投放效果。

6. 容災

容災的主要目的是在不可抗力因素發(fā)生，影響實時數(shù)據(jù)的情況下，盡可能快的將數(shù)據(jù)補回來，盡力保證數(shù)據(jù)的準確性。我們方案實現(xiàn)了一套與實時功能等價的離線數(shù)據(jù)校準流程。如上圖2所示，容災過程通過離線數(shù)據(jù)處理完成主要分為兩個階段：

• 第一階段日志解析階段，此階段通過離線數(shù)據(jù)處理將數(shù)據(jù)按照產(chǎn)品分類的方式按小時解析完成存入HIVE引擎。
• 第二階段新增計算，通過與歷史累計新增表的對比計算出新增數(shù)據(jù)。

這兩個階段是獨立于實時數(shù)據(jù)處理按小時周期進行的，當發(fā)生實時數(shù)據(jù)異常時，即會觸發(fā)補數(shù)流程進行補數(shù)。這個方案通過幾次線上實操驗證，能保證數(shù)據(jù)校準的響應維持在小時級別，數(shù)據(jù)誤差率控制在0.5%以內(nèi)。

方案效果

根據(jù)業(yè)務要求，渠道分析的數(shù)據(jù)延遲應控制在10分鐘以內(nèi)，分析本方案中各個階段處理性能，參數(shù)配置如下：

日志解析和產(chǎn)品分流階段的數(shù)據(jù)處理能力如下圖所示：

圖5 日志解析處理能力統(tǒng)計

圖6 產(chǎn)品分流處理能力統(tǒng)計

日志解析階段，如上圖5為一天內(nèi)所有數(shù)據(jù)的平均處理時間，可以看出，單條數(shù)據(jù)處理延遲約為1.43ms，無累積延遲。產(chǎn)品分流階段，如上圖6為一天內(nèi)所有批次的平均處理時間，可以看出，數(shù)據(jù)處理時間約為1.39s，遠小于批時間，即本方案中數(shù)據(jù)消費能力遠大于數(shù)據(jù)生產(chǎn)速度，無累積延遲。

從分析結果可知，本方案整體數(shù)據(jù)延遲控制在秒級左右，遠小于業(yè)務所要求的10分鐘，滿足業(yè)務需求。其中新增計算與實時查詢部分的延遲均為ms級別，可忽略不計。

難點攻克

1. 低延遲

渠道數(shù)據(jù)原始日志里包含眾多產(chǎn)品，在高峰期數(shù)據(jù)量可以達到100MB/s，并且打點結構設計復雜，需要經(jīng)過多重解碼和結構拆分才能得到所需字段。為了保證新增計算低延遲，本方案將數(shù)據(jù)處理流程拉長，通過數(shù)據(jù)分層，將一個復雜的數(shù)據(jù)流程分解成多個處理流程。雖然拉長了數(shù)據(jù)處理流程，但可以針對性的對不同的處理階段進行調優(yōu)，例如，當日志解析階段出現(xiàn)堆積，可以通過調整并行度提高執(zhí)行效率。細粒度的拆分數(shù)據(jù)處理流程也提高了數(shù)據(jù)的利用率，原始數(shù)據(jù)經(jīng)過日志解析，將數(shù)據(jù)變成有效的規(guī)則的明細層數(shù)據(jù)，再根據(jù)明細層數(shù)據(jù)進行分流獲得不同產(chǎn)品的主題層數(shù)據(jù)，最終根據(jù)主題層數(shù)據(jù)計算獲得應用層數(shù)據(jù)。

2. 數(shù)據(jù)準確性穩(wěn)定性保障

實時處理流程配置有完善的預警和報警措施，可一旦發(fā)生極端情況，如網(wǎng)絡或集群問題導致的實時任務失敗，數(shù)據(jù)丟失不可避免。因此，本方案同時設計了一套穩(wěn)定的小時級離線災備流程，當發(fā)現(xiàn)實時處理出現(xiàn)故障，可及時開啟離線補數(shù)，矯正業(yè)務數(shù)據(jù)。離線校準不僅為實時計算提供正確性校驗，更保證渠道評估的準確性，為運營做到精準投放和公平結算保駕護航。

總結

本文實現(xiàn)了一種以實時計算為主體、離線計算為校準的分鐘級累計新增計算解決方案，在原有的小時級離線新增基礎上，將新增統(tǒng)計提升到分鐘級，有效的降低了響應延遲，將運營決策被動等待轉換成主動調整，為渠道運營和渠道評估提供有力的數(shù)據(jù)支持。

【本文是51CTO專欄機構360技術的原創(chuàng)文章，微信公眾號“360技術（ id: qihoo_tech）”】

戳這里，看該作者更多好文