一、 業務背景

隨著移動互聯網的快速發展，小程序作為當下零售環境下的嶄新載體，它憑借著入口豐富、場景多元、傳播能力強、觸手可及以及用完即走的特點，得到了廣泛的認可和傳播。而在小程序的日常運營與發展中，存在著多樣的數據信息，面對如此豐富的數據生產資料，如何高效靈活地對這些原始數據進行分析與挖掘，迅速掌握小程序數據的波動，洞察小程序用戶行為變化，是目前國內各個小程序平臺不斷追求突破的問題。因為只有不斷提高數據的分析效率，才能更好地沉淀數據分析的能力，進而借助于數據的深層潛在價值為小程序的業務發展而賦能。

京東小程序數據中心已涵蓋用戶行為分析、留存分析、用戶畫像及來源分析等四大基礎數據分析模塊，涉及的數據指標多達60+。

早期的數據主要由京東小程序客戶端引擎SDK進行采集，通過子午線原生渠道進行統一上報，再由服務端統一清洗處理;這種模式雖然可以覆蓋大部分基礎數據分析的場景，但是仍然存在如下痛點問題：

1、數據類型不完整：基礎數據指標僅為小程序框架可以獲取的數據，而小程序內開發者自有代碼的頁面曝光、點擊等業務數據，小程序框架無法自動獲取，導致小程序數據平臺提供數據的完整性無法得到保證。例如，針對ISV商家開發的某營銷類小程序，我們無法采集并分析到該小程序在進行營銷活動時，某一個領券按鈕的用戶點擊數據。

2、行業數據無法沉淀：小程序涵蓋的業務場景豐富多樣，且復雜程度不一，早期的數據中心，僅提供后置的數據分析展示，因為業務數據缺失，無法提供基于行業的預測分析模型，很難為商家提供更為有效的經營指導策略支持。

3、無法滿足多變的數據統計需要：目前已有的數據分析是固化的、預置的且不可變的，自定義數據分析能真正支持數據的靈活統計需要，滿足多變的業務數據分析場景。

以上問題的關鍵，在于如何解決未來海量業務數據的存儲、靈活處理及深度分析，基于此，我們調研了行業內多家成熟數據解決方案，重點考慮京東業務特點，最終構造了一套完整的京東小程序自定義數據分析服務。

接下來，本文將詳細介紹京東小程序自定義數據分析服務的整體技術方案和關鍵流程，重點涵蓋動態規則配置解析、數據存儲設計以及實時數據查詢分析等功能的設計和實現。

二、 技術選型

京東小程序的自定義數據分析需要一種支持海量數據存儲、查詢高效且運維成本較低的數據存儲方式，經過調研對比發現，ClickHouse以下的三點特征可以很好地滿足我們的技術選型訴求。

1、支持列式存儲和數據壓縮

京東小程序自定義數據分析需要滿足用戶在系統查詢分析時的查詢執行效率，我們期望在百億數據集中，秒級返回執行的自定義數據分析的聚合結果，對比發現，ClickHouse按列存儲的特性便可以極大提升數據查詢的效率，因為按列存儲與按行存儲相比，前者可以有效減少查詢時所需掃描的數據量，如果數據按行存儲，數據庫首先會逐行掃描，并獲取每行數據的所有字段，再從每一行數據中返回查詢所需要的字段，導致會掃描所有的字段。如果數據按列組織，數據庫可以直接獲取想查詢的列的數據，從而避免了多余的數據行掃描。

針對分析類查詢，通常只需要讀取表的一小部分列。在列式數據庫中你可以只讀取你需要的數據。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。

ClickHouse采用的壓縮算法可以將列的數據進行壓縮處理，數據中的重復項越多，則壓縮率越高;壓縮率越高，則數據體量越小;而數據體量越小，則數據在網絡中的傳輸越快，對網絡帶寬和磁盤I/O的壓力也就會進一步地變小。

2、MPP架構，支持分布式水平拓展

京東小程序自定義數據分析服務需要支持水平的拓展。因為隨時業務的發展，小程序的數據量勢必會日益龐大，調研發現，ClickHouse天然具備分布式存儲的特點，它本身是一款MPP(Massively Parallel Processing)架構的列式存儲數據庫，支持大規模并行處理，以多主對等的扁平架構，保證了海量數據在各個節點的分布式存儲。

這樣對于我們后期的業務數據的拓展存儲提供了必要的保障，只需簡單增加節點，即可實現水平擴容，極大地降低了運維的成本。

在ClickHouse中，數據可以保存在不同的shard上，每一個shard都由一組用于容錯的replica組成，查詢可以并行地在所有shard上進行處理，如下圖Node1和Node2均為主shard，互為replicate，然而這些對用戶來說完全是透明的。

3、多樣化的表存儲引擎

京東小程序自定義數據分析的場景較多，涉及點擊、瀏覽、曝光和訂單等四大類分析場景，每種場景都有獨特且常見的統計需要，比如常見的計算去重用戶數、求和金額、求金額平均值或最大值等，而在ClickHouse中可以針對表設置對應的表引擎，表引擎決定了表存儲在哪里、以何種方式進行存儲以及支持的查詢方式。同時，表引擎可以結合ClickHouse的物化視圖使用，能夠達到非常好的查詢效果。

ClickHouse共擁有合并樹、內存、文件、接口和其他6大類20多種表引擎。其中每一種表引擎都有著各自的特點和適用的場景，對于簡單的場景，可直接使用簡單的引擎降低運維成本，而復雜的場景也有合適的選擇。

比如，MergeTree家族的ReplacingMergeTree引擎，它會刪除排序鍵值相同的重復項。數據的去重只會在數據合并期間進行，合并會在后臺一個不確定的時間進行，因此你無法預先作出計劃。因此，ReplacingMergeTree 適用于在后臺清除重復的數據以節省空間，但是它不保證沒有重復的數據出現。

SummingMergeTree會把行主鍵相同的行合并為一行，計算求和值，該行包含了被合并的行中具有數值數據類型的列的匯總值。

AggregatingMergeTree在合并分區的時候按照定義的條件聚合數據，將需要聚合的數據預先計算出來，在聚合查詢時直接使用結果數據。

三、 京東小程序自定義數據分析的整體架構

了解了ClickHouse相關特性后，接下來介紹完整的京東小程序自定義數據分析的技術方案。

整體的自定義數據分析功能主要包含自定義數據上報、數據加工計算以及數據存儲三大層次結構。其中最核心的問題是上報的數據如何基于自定義的配置規則進行匹配關聯查詢。而解決辦法是在上報的數據記錄中可以采用一個event_id(事件id)來標識某次上報請求數據，然后將業務字段放在map結構中，如下數據結構所示，這樣可以實現業務數據字段的橫向拓展，又能輕松定位到上報的數據記錄。

上報數據的通道主要包括網關http實時數據通道以及子午線客戶端埋點通道，將這些數據統一下發至實時數倉或者HDFS離線數倉。

通過中間層的數據流轉，執行Flink實時計算或者MapReduce的離線計算，從而對原始的上報數據進行過濾、加工計算，最終批量寫入至ClickHouse來實現數據的最終持久化存儲。

至此，可以基于前端界面上配置的自定義事件和查詢指標、過濾條件、分組條件等自定義查詢規則，實現數據的在線查詢分析。效果展示如下圖所示。

四、 京東小程序自定義數據分析的流程設計

那么，規則引擎服務如何基于自定義規則動態解析處用戶上報的數據的呢?規則引擎的執行流程主要包含兩部分，包含自定義數據上報屬性的配置寫入以及自定義數據分析兩個核心流程。

首先，需要將上報的屬性配置保存至數據庫進行持久化存儲，當進行實時數據查詢時，會先獲取以上的事件規則和指標，之后，規則引擎會構建查詢sql腳本推送至執行引擎，執行引擎下發sql腳本至ClickHouse集群去執行數據的查詢并返回結果至前端，最后，異步將執行結果寫入緩存，并設置數據有效期，便于提升下次查詢效率。整體的解析執行流程如下圖所示。

五、 京東小程序自定義數據分析的表設計

ClickHouse的表分為本地表和分布式表，分布式表是一個邏輯上的表, 可以理解為數據庫中的視圖, 一般查詢都查詢分布式表。分布式表引擎會將我們的查詢請求路由本地表進行查詢, 然后進行匯總最終返回給用戶。本地表是實際存儲數據的表，本地表和分布式表的關系如下圖所示，在寫入和讀取數據時通過nginx實現請求的負載均衡，防止出現寫入和讀取不均衡的情況。

以京東小程序自定義點擊事件的數據統計場景為例，我們創建對應的本地表vapp_analysis_local和分布式表vapp_analysis_dist如下圖所示。

本地表：

分布式表：

舉例說明，根據京東小程序點擊事件的數據存儲特點，我們做了如下的表設計：

• 設置主節點數和副本數。shard屬性設置節點的主數據節點數，replica設置節點的副本數，從而保證數據存儲的多副本高可用。
• 選擇分區字段。ClickHouse支持分區，分區字段是每張表整個數據目錄最外層結構，可以很大程度加快查詢速度。具體的DDL操作關鍵詞是 PARTITION BY，指的是一個表按照某一列數據(比如日期)進行分區，對應到最終的結果就是不同分區的數據會寫入不同的文件中，在我們的業務場景中是按照數據的上報時間取年、月、日按照天來進行分區的，toYYYYMMDD(report_time)。
• 設置排序規則。設置合理的數據排序規則可以提升數據的查詢效率，數據會按照設置的排序字段先后順序來進行存儲，在進行聚合計算時也會按照聚合條件對相鄰數據進行計算。在我們的業務場景中采用的是小程序的AppID來作為排序的規則，小程序AppID是每個小程序的唯一標識，在查詢數據時絕大部分場景會以AppID的維度進行數據的查詢。所以，采用AppID作為排序字段可以很大程度上提升我們的數據聚合運算效率。
• 設置表引擎。在點擊事件的場景中，我們設置的支持多副本的ReplicatedMergeTree引擎，可以支持數據的多副本存儲，保證數據的高可用。

在以上的表設計中，content字段非常關鍵。我們將上報的自定義數據存儲到表中的content字段中，并以json結構進行存儲，這樣即可支持上報字段的水平拓展。當規則引擎將動態生成的sql腳本下發至Clickhouse執行查詢時，利用Clickhouse的json解析函數JSONExtractString進行取值轉換，這樣就可以非常容易得到我們想要分析的指定的業務字段。

舉例說明，當我們想從京東小程序點擊事件表中獲取事件編碼為applets_buy的金額字段amount時，基于規則解析引擎構建并下發至ClickHouse的動態腳本即為如下形式，這樣便可實現上報字段的動態提取。

六、 京東小程序自定義數據分析的監控

在整個自定義數據分析的鏈路中，涉及的環節較多，需要有良好的監控機制，來保證系統功能的穩定運行。

針對MQ消息隊列、Flink實時計算任務、ClickHouse存儲等中間件的監控，我們采取的是Grafana提供的可視化監控能力。如下圖所示，這樣可以直觀地看到諸如CPU、內存、磁盤的I/O、磁盤使用率等情況。

同時，針對京東小程序運行時的監控，我們提供了一套完整的監控告警機制，支持配置自定義告警規則，來幫助我們及時發現京東小程序自身異常頁面數據、性能數據以及網絡請求數據等異常數據信息，目前已可以監控到線上所有小程序的異常數據和性能運行情況，以單個小程序為例，監控的情況如下圖所示。

基于以上兩種監控手段，可以幫忙我們時刻掌握京東小程序在整個鏈路中的性能數據的波動、及時發現性能瓶頸、迅速定位運行中出現的各種問題，從而為整個京東小程序的業務發展保駕護航。

七、 總結展望

京東小程序自定義數據分析服務所提供的高效靈活的處理能力，不僅極大地提高了京東小程序數據平臺的完整性，也為持續沉淀行業業務數據提供了完善的保障，預計首批落地支持50+核心小程序的業務自定義數據上報、分析及可視化，完整串聯用戶在小程序內外的行為路徑，支持商家精細化運營的需要。

京東小程序數據能力已經完成了從0到1的突破，未來將會致力于打造京東小程序智能數據分析模型，從而實現從1到N的飛躍。最終幫助更多京東小程序商家不斷優化運營策略，降低數據分析成本，提升業務產能及效率!