京東小程序數(shù)據(jù)中心架構(gòu)設(shè)計與最佳實踐

一、京東小程序是什么

京東小程序平臺能夠提供開放、安全的產(chǎn)品，成為品牌開發(fā)者鏈接京東內(nèi)部核心產(chǎn)品的橋梁，致力于服務(wù)每一個信任我們的外部開發(fā)者，為不同開發(fā)能力的品牌商家提供合適的服務(wù)和產(chǎn)品，讓技術(shù)開放成為品牌的新機會?！癘nce Build, Run Anywhere”，一個小程序可以在多個APP運行，引擎層抹平差異，一套代碼，相同頁面，云端下發(fā)，多端運行。

可能大家還不太了解我們的京東小程序，京東小程序到底是什么呢？它和微信小程序有什么區(qū)別？首先呢，需要明確的是，京東小程序不是運行在微信端的京東商城購物小程序，而是運行在京東APP的，基于京東小程序引擎的一套京東系的小程序。

它是和支付寶小程序或者微信小程序?qū)说囊活惥〇|化的小程序。

舉個例子，大家可以體驗一下，比如在主站搜索寶格麗，會通過搜索直達直接跳轉(zhuǎn)到寶格麗小程序上，我們可以在這里購買奢侈品，或者在首頁的同城Tab頁下，可以瀏覽到非常多的到家門店類的小程序，總之，京東小程序所覆蓋的業(yè)務(wù)還是極其廣泛的！

當然，京東小程序不僅僅可以運行在京東APP上，只要宿主在運行時依賴了我們的小程序SDK引擎，就可以實現(xiàn)在各類其他宿主APP上的運行，譬如，在京東小家APP上，可以通過小程序去控制智能IOT設(shè)備，在京ME的APP上，可以遠程操作打印機，實現(xiàn)一鍵打印。小程序作為一種輕量級的即用即走的工具，用戶群體廣泛，早已覆蓋到了我們生活的方方面面。

京東小程序是鏈接商家和京東內(nèi)部核心產(chǎn)品的重要橋梁，也是助力商家實現(xiàn)流量增長、業(yè)務(wù)發(fā)展的一個重要方式。

那么，小程序平臺是怎么保證商家業(yè)務(wù)的穩(wěn)定、健康發(fā)展，服務(wù)好這些外部商家的呢？這里面非常重要的是我們平臺對小程序基本流量的運營與監(jiān)控。如何不讓業(yè)務(wù)的小程序在線上裸奔？如何幫助業(yè)務(wù)對自身小程序流量的沖高回落有一種直觀的把握和監(jiān)測？如何基于海量數(shù)據(jù)指導(dǎo)業(yè)務(wù)去進行一個精細化的運營？實際上，京東小程序數(shù)據(jù)中心就扮演了一個這樣的小程序數(shù)據(jù)問題終結(jié)者的角色，充分利用各類數(shù)據(jù)手段，解決這些痛點問題。

二、京東小程序數(shù)據(jù)中心建設(shè)里程碑

京東小程序數(shù)據(jù)中心的建設(shè)，主要經(jīng)歷了四個階段，從最開始的由0到1搭建了數(shù)據(jù)基礎(chǔ)能力，到豐富拓展各類數(shù)據(jù)指標，接著下鉆分析到用戶，幫助商家實現(xiàn)基于用戶的精細化的運營，到目前的小程序數(shù)智化建設(shè)，在整個小程序的迭代建設(shè)的過程中，都從各個維度為小程序的業(yè)務(wù)發(fā)展實現(xiàn)了保駕護航。

三、京東小程序數(shù)據(jù)中心業(yè)務(wù)全景圖

?從功能角度，京東小程序運營數(shù)據(jù)分析，京東小程序監(jiān)控數(shù)據(jù)分析；

?從展現(xiàn)角度，開發(fā)者控制臺，管理后臺，移動端小程序助手，宙斯開放能力；

?從功能領(lǐng)域角度，用戶行為分析，交易鏈路數(shù)據(jù)分析，用戶畫像，流失率監(jiān)控，流量監(jiān)控等；

?從上報通道角度，子午線，自定義上報，服務(wù)端埋點；

?從數(shù)據(jù)存儲角度，JED，JimDB，ES，HBase等；

目前京東小程序數(shù)據(jù)中心功能范圍廣泛，我們在根據(jù)業(yè)務(wù)發(fā)展的需求，不斷完善整個京東小程序數(shù)據(jù)中心的功能架構(gòu)。

從展現(xiàn)角度看，包括開發(fā)者控制臺，管理后臺，移動端小程序助手，實時數(shù)據(jù)大屏, 開放openApi能力；

其次是從功能領(lǐng)域角度看，主要包括運營數(shù)據(jù)分析，監(jiān)控數(shù)據(jù)分析。

運營數(shù)據(jù)分析，包括用戶行為分析，比如小程序基礎(chǔ)的pv和uv；

來源分析，可以去分析小程序在各個廣告投放渠道下的營銷轉(zhuǎn)化效果；

用戶畫像分析，可以分析到瀏覽過小程序的人群中的哪些是高凈值用戶群體，以及性別以及年齡等基礎(chǔ)的用戶畫像數(shù)據(jù)。

監(jiān)控數(shù)據(jù)分析，主要是針對線上運行的小程序的奔潰異常，網(wǎng)絡(luò)請求異常，啟動性能數(shù)據(jù)的分析，用戶流失率的實時監(jiān)測等，可以在小程序出現(xiàn)異常時第一時間通知到開發(fā)者。

四、京東小程序數(shù)據(jù)中心技術(shù)架構(gòu)圖

對于整體的架構(gòu)設(shè)計，其實在我看來，數(shù)據(jù)的分析，主要是解決三個問題，第一個要解決的是數(shù)據(jù)如何上報的問題，第二個是解決數(shù)據(jù)如何存儲的問題？第三個才是解決數(shù)據(jù)如何分析的問題？

1、京東小程序數(shù)據(jù)中心的數(shù)據(jù)上報主要包括三個途徑，主要包括客戶端埋點，服務(wù)端埋點或者其他外部的數(shù)據(jù)源，客戶端埋點主要利用的是子午線，服務(wù)端埋點主要是我們服務(wù)之間采集數(shù)據(jù)，服務(wù)之間消費和同步。

2、數(shù)據(jù)存到哪里去，這個需要基于我們業(yè)務(wù)上對這些數(shù)據(jù)的實時性要求，判斷是實時還是離線，進而采用不同的數(shù)據(jù)源進行存儲，數(shù)據(jù)指標是要秒級的？分鐘級的？還是T+1l類型的，實時性要求不同，那么存儲的數(shù)據(jù)源自然也就不同。

3、數(shù)據(jù)如何分析，實際上就是我們的業(yè)務(wù)邏輯，在設(shè)計時也需要充分考慮數(shù)據(jù)模型的復(fù)用性和可拓展性。

小程序數(shù)據(jù)中心對于來自子午線客戶端埋點數(shù)據(jù)，以離線的方式構(gòu)建小程序自己的業(yè)務(wù)數(shù)倉，一層一層地進行數(shù)據(jù)的降噪，清洗和計算，將聚合好的維度數(shù)據(jù)再推送到關(guān)系型數(shù)據(jù)庫，方便業(yè)務(wù)快速接入。對于來自自建通道的實時數(shù)據(jù)以及外部系統(tǒng)的埋點數(shù)據(jù)，通過統(tǒng)一上報服務(wù)將數(shù)據(jù)上報到消息隊列，進行流量數(shù)據(jù)的異步處理和消峰，采用專門的消費者服務(wù)對上報數(shù)據(jù)進行消費落庫，存儲到ES和HBase數(shù)據(jù)庫，便于平臺進行多維度的明細或者匯總數(shù)據(jù)查詢；同時，也會基于Flink對消息隊列中的數(shù)據(jù)進行流式實時計算，實現(xiàn)異常波動流量的告警和分析。

五、它山之石可以攻玉，借助集團數(shù)據(jù)工具打造小程序業(yè)務(wù)數(shù)倉

痛點問題：

1.京東小程序的數(shù)據(jù)來源多樣化，數(shù)據(jù)量級龐大，如何立足業(yè)務(wù)數(shù)據(jù)，發(fā)揮數(shù)據(jù)價值，幫助商家實現(xiàn)精細化的運營？

2.如何復(fù)用主站已有的數(shù)據(jù)模型和能力，讓更多的小程序商家參與到京東主站的流量場，讓數(shù)據(jù)驅(qū)動商家精準營銷？

3.業(yè)務(wù)指標紛繁復(fù)雜，如何沉淀和抽離通用數(shù)據(jù)模型，減少重復(fù)工作？

如何解決：

基于集團BDP平臺，自上而下構(gòu)建京東小程序的業(yè)務(wù)數(shù)倉，借助BDP平臺豐富的數(shù)據(jù)產(chǎn)品工具，多維度地構(gòu)建小程序的數(shù)據(jù)能力。離線計算+實時計算相結(jié)合，小程序業(yè)務(wù)數(shù)據(jù)+集團模型數(shù)據(jù)相結(jié)合。

1.數(shù)據(jù)分類化，將小程序流量進行主題劃分，拆分為點擊、瀏覽、曝光、訂單等大維度的主題模型，方便數(shù)據(jù)定位，增加業(yè)務(wù)理解；

2.數(shù)據(jù)分層化，同一個流量主題下，進一步按照ODS->DWD->DWS->ADS的層級結(jié)構(gòu)進行分層，方便追蹤數(shù)據(jù)血緣，減少重復(fù)數(shù)據(jù)模型的開發(fā)；

3.數(shù)據(jù)多元化，下游系統(tǒng)可從小程序數(shù)據(jù)倉庫拉取符合業(yè)務(wù)需要的領(lǐng)域數(shù)據(jù)，比如數(shù)紡，搜推廣等系統(tǒng)，利用下游系統(tǒng)成熟穩(wěn)定的數(shù)據(jù)能力，為商家營銷充分賦能；

在京東小程序的業(yè)務(wù)數(shù)倉搭建過程中，主要還是應(yīng)用了集團BDP大數(shù)據(jù)平臺提供的豐富的產(chǎn)品工具和通用能力。

幾種典型的使用案例是：

1、離線hive表數(shù)據(jù)同步到j(luò)ed等關(guān)系型業(yè)務(wù)庫，使用buffalo任務(wù)中的出庫算子；

2、業(yè)務(wù)產(chǎn)生的實時MQ數(shù)據(jù)同步到hive數(shù)倉，使用DTS，實時數(shù)據(jù)傳輸任務(wù)，可以把業(yè)務(wù)數(shù)據(jù)同步到數(shù)倉；

3、我們需要在數(shù)倉中構(gòu)建業(yè)務(wù)維表，比如構(gòu)建小程序基本信息的維表，業(yè)務(wù)數(shù)據(jù)需要同步到hive表，可以采用數(shù)據(jù)直通車DataBus，在表記錄的生成上，可以根據(jù)業(yè)務(wù)的需要，采用全量表，增量表，快照表，拉鏈表或者流水表的不同的記錄生成方式。

京東小程序客戶端埋點統(tǒng)一上報的子午線，需要從最原始的gdm層底表提取小程序自己的業(yè)務(wù)數(shù)據(jù)，原始底表數(shù)據(jù)量級非常大，不可能每次直接對原始底表查詢，這樣的話耗費計算資源，效率較低。所以，我們盡量提高底層數(shù)據(jù)模型的復(fù)用度，對數(shù)據(jù)進行分類化和分層化處理。

所謂分類話，就是將小程序流量進行主題劃分，拆分為點擊、瀏覽、曝光、訂單等大維度的主題模型，方便數(shù)據(jù)定位，增加業(yè)務(wù)理解；

所謂分層化，就是在同一個流量主題下，進一步按照ODS->DWD->DWS->ADS的層級結(jié)構(gòu)進行數(shù)據(jù)分層，方便追蹤數(shù)據(jù)血緣，減少重復(fù)數(shù)據(jù)模型的開發(fā)。

所謂多元化，就是復(fù)用度，加工好的這些數(shù)據(jù)，可以給下游的團隊接入使用，比如商智，黃金眼，數(shù)紡這些團隊。以小程序廣告投放為例，在小程序數(shù)倉中我們構(gòu)建了各個類型的用戶群體，在數(shù)紡注冊了用戶群體標簽，比如關(guān)注用戶，粉絲用戶或者提單用戶等，下游的廣告精準通系統(tǒng)會基于我們的這些標簽進行人群的圈選，進而實現(xiàn)小程序廣告的投放。

總之，根據(jù)業(yè)務(wù)特點，充分利用好集團BDP的數(shù)據(jù)工具，幫助我們實現(xiàn)數(shù)倉的搭建。

六、基于FLINK實時計算，落地小程序異常奔潰監(jiān)控利器

痛點問題：京東小程序在線上運行時，需要實時監(jiān)測到小程序的業(yè)務(wù)代碼崩潰異常、性能數(shù)據(jù)波動，網(wǎng)絡(luò)請求耗時等，在有異常崩潰的情況下，保證可以第一時間通知到商家開發(fā)者，幫助業(yè)務(wù)及時止損。

如何解決：

1.報警規(guī)則可配置，基于Zookeeper分布式配置中心存儲小程序自定義的告警規(guī)則，實時監(jiān)聽規(guī)則節(jié)點變化，當節(jié)點數(shù)據(jù)變化時，實時聚合到業(yè)務(wù)流；

2.自定義滑動窗口，每個小程序的告警窗口大小不一樣，拓展實現(xiàn)WindowAssigner，基于用戶動態(tài)規(guī)則確定告警窗口開始時間和截止時間；

3.廣播變量，broadcast機制，將告警配置信息廣播到各個Task任務(wù)內(nèi)存，廣播變量就是一個公共的共享變量，將一個數(shù)據(jù)集廣播后，不同的Task都可以在節(jié)點上獲取到，每個節(jié)點只存一份，否則，每一個Task都會拷貝一份數(shù)據(jù)集，會造成內(nèi)存資源浪費。

對于小程序的實時監(jiān)控能力，我們采用flink作為實時計算的框架，小程序在線上運行時，需要實時監(jiān)測到小程序的業(yè)務(wù)代碼崩潰異常、這種異常很可能會導(dǎo)致小程序白屏或者閃退，需要在探測到有異常崩潰的情況下，保證第一時間通知到商家開發(fā)者，幫助業(yè)務(wù)及時止損。

這里的難點在于告警的規(guī)則是支持用戶自定義的，比如配置觀測多長時間窗口內(nèi)的異常數(shù)據(jù)，當達到多少的異常閾值，應(yīng)該去觸發(fā)告警，應(yīng)該判定為異常，這里是需要把告警規(guī)則配置的的主動權(quán)交給用戶的，在這樣的背景下，

1、 我們采用的是將告警規(guī)則放到分布式的統(tǒng)一配置中心，實時監(jiān)聽節(jié)點規(guī)則的變化，將業(yè)務(wù)流和規(guī)則流進行connet雙流合并；

2、 然后根據(jù)告警規(guī)則，實現(xiàn)windowAssigner生成自定義的動態(tài)計算窗口，從而實現(xiàn)窗口動態(tài)化；

3、 最后，采用廣播變量的broadcast機制，當告警規(guī)則變更時，可以高效地將告警配置廣播刷新到各個Task任務(wù)內(nèi)存，提高資源利用率，保證計算時效性。

七、探索OLAP領(lǐng)域的黑馬，基于ClickHouse搭建自定義數(shù)據(jù)分析引擎

痛點問題：小程序內(nèi)部的數(shù)據(jù)波動如何自由埋點分析？京東內(nèi)部業(yè)務(wù)直接基于子午線埋點上報，業(yè)務(wù)團隊內(nèi)部自行分析；外部的開發(fā)者需要依賴神策,GA等外部的分析系統(tǒng)，無法將數(shù)據(jù)回流京東，且復(fù)用京東現(xiàn)有流量工具進行精細化運營。

如何解決：

1.選擇合適的表存儲引擎：采用多副本的ReplicatedMergeTree，保證查詢性能和數(shù)據(jù)存儲的高可用；

2.按天分區(qū)存儲數(shù)據(jù)：PARTITION BY：分區(qū)鍵，PARTITION BY toYYYYMMDD(EventDate)，不同分區(qū)下的數(shù)據(jù)會分開存儲，合理建立分區(qū)可以加快查詢的速度；

3.統(tǒng)一上報協(xié)議：生成全局唯一事件ID，事件ID綁定業(yè)務(wù)數(shù)據(jù)；

4.動態(tài)數(shù)據(jù)解析：基于visitParamExtract函數(shù)解析json動態(tài)業(yè)務(wù)數(shù)據(jù)；

5.查詢腳本下推：Sql引擎生成查詢Sql，下沉至ClickHouse完成查詢；

小程序內(nèi)部的數(shù)據(jù)波動如何自由埋點分析？京東內(nèi)部業(yè)務(wù)是可以直接基于子午線埋點上報，業(yè)務(wù)團隊內(nèi)部自行分析，但是子午線這種產(chǎn)品本身不對外開放，外部的開發(fā)者如果想分析小程序自身的內(nèi)部數(shù)據(jù)，需要依賴神策，GA等外部的數(shù)據(jù)分析系統(tǒng)，這樣的話，小程序的數(shù)據(jù)無法回流京東，那么也就無法復(fù)用京東現(xiàn)有流量工具進行小程序的精細化運營。

在這樣的背景下，我們落地了小程序的自定義分析引擎，底層采用了clickhouse這種適合做即席查詢的olap引擎，用來存儲小程序上報數(shù)據(jù).

為什么采用clickhouse? clickhouse是基于列式來存儲數(shù)據(jù)，查詢性能非常高，在億級數(shù)據(jù)的體量下，可以做到秒級的響應(yīng)，適合做在線的OLAP。

同時，ck支持水平的拓展，適合大數(shù)據(jù)量的存儲，支持按天進行數(shù)據(jù)的分區(qū)存儲，在建表時，根據(jù)記錄的創(chuàng)建時間劃分partition，在查詢數(shù)據(jù)時，可以只查某些partition分區(qū)的數(shù)據(jù)，也可以加快查詢的效率。

包括本地表和分布式表，本地表運行在各個具體的數(shù)據(jù)節(jié)點，分布式表負責數(shù)據(jù)的轉(zhuǎn)發(fā)和路由。寫入數(shù)據(jù)只寫本地表，50-200M/S ,對于大量的數(shù)據(jù)更新非常實用。

在小程序自定義分析引擎中，規(guī)范了數(shù)據(jù)上報協(xié)議，首先由用戶配置需要上報的事件ID和業(yè)務(wù)指標，按照協(xié)議約定調(diào)用前端jsAPI上報業(yè)務(wù)數(shù)據(jù)。在自助查詢區(qū)域，當用戶觸發(fā)查詢時，先基于規(guī)則引擎利用自定義事件ID生成查詢規(guī)則SQL腳本，將規(guī)則下推至服務(wù)端執(zhí)行引擎，執(zhí)行引擎從CK獲取業(yè)務(wù)數(shù)據(jù)，完成業(yè)務(wù)數(shù)據(jù)的一次自定義查詢。

八、巧用Elasticsearch特性，讓用戶行為分析不再困難

痛點問題：需要實時分析小程序的pv、uv、新增用戶數(shù)、累計用戶數(shù)以及關(guān)注用戶數(shù)等用戶行為類指標，幫助小程序商家掌握自身小程序的用戶波動情況。

如何解決：

1.實時性，從小程序的用戶行為埋點數(shù)據(jù)上報到可訪問，支持秒級響應(yīng)；

2.全文檢索，基于倒排索引，支持靈活的搜索分析，支持按照小程序不同業(yè)務(wù)維度進行聚合分析，滿足不同的業(yè)務(wù)需要；

3.易于運維，小程序的日均DAU在300W+，可以基于天、月等維度創(chuàng)建索引，方便進行冷熱數(shù)據(jù)分析；

創(chuàng)建ES模板：周期性按天創(chuàng)建ES索引：

利用索引主鍵碰撞實現(xiàn)新增&累計用戶統(tǒng)計：

語法:

index語法: PUT miniapps/_doc/1

create語法: PUT miniapps/_create/1

語義:

index自動生成id,多次創(chuàng)建,會生成多個document;

index多次索引同一個id,會刪除重建,版本號一直++,上個版本刪除,保留最新版本;

create自動生成id,多次創(chuàng)建,會生成多個document;

create的重復(fù)創(chuàng)建指定文檔id的內(nèi)容,第二次執(zhí)行創(chuàng)建會報錯(主鍵碰撞),而不是版本號++;

我們是如何做小程序的實時用戶行為分析的呢？行為分析需要實時計算小程序的pv、uv、新增用戶數(shù)、累計用戶數(shù)以及關(guān)注用戶數(shù)等用戶行為類指標，幫助小程序商家掌握自身小程序的用戶波動情況。我們將這些數(shù)據(jù)統(tǒng)一放在ES中進行查詢，主要考慮到ES支持靈活的搜索分析，支持按照不同維度進行聚合分析，保證了數(shù)據(jù)查詢的靈活性和實時性的需要。

在創(chuàng)建索引時，不是將數(shù)據(jù)都堆放到一個索引，而是將按天去創(chuàng)建，基于索引模板，周期性地創(chuàng)建ES索引，保證索引查詢效率。

在構(gòu)建小程序的新增用戶的指標時，利用了ES索引碰撞的原理，設(shè)置操作類型operateType為create，create的語義是重復(fù)創(chuàng)建指定文檔id的內(nèi)容,第二次執(zhí)行創(chuàng)建會報錯(出現(xiàn)主鍵碰撞),這樣的話，保證新增用戶的記錄在ES索引中只出現(xiàn)一次。

九、不足和展望

1、沉淀小程序行業(yè)數(shù)據(jù)解決方案

沉淀比如車企、保險、3C家電等行業(yè)類數(shù)據(jù)，形成統(tǒng)一的京東小程序行業(yè)數(shù)據(jù)解決方案

2、技術(shù)沉淀復(fù)用

后續(xù)可以把成型的京東小程序數(shù)據(jù)分析技術(shù)方案推廣到其他技術(shù)棧，比如RN等平臺系統(tǒng)

3、智能化建設(shè)

考慮如何基于機器學(xué)習(xí)、人工智能、ChatGPT等技術(shù)手段，加強京東小程序數(shù)據(jù)的智能化建設(shè)，如何結(jié)合機器學(xué)習(xí)、深度學(xué)習(xí)、人工智能AI等技術(shù)手段，繼續(xù)實現(xiàn)京東小程序數(shù)據(jù)中心的智能化建設(shè)。

?預(yù)測性分析能力：

小程序的智能告警，基于時間序列預(yù)測算法，比如Facebook Prophet算法等，做一些告警預(yù)判，提升告警的智能性和準確率；

?數(shù)據(jù)挖掘算法：

在小程序的預(yù)下載場景，可以基于協(xié)同過濾算法，做小程序偏好人群的判斷，實現(xiàn)預(yù)下載的千人千面，從而減少網(wǎng)絡(luò)帶寬，節(jié)省資源成本等；

?語義引擎：

如何將ChatGpt這種AI智能模型，可以分析和理解大量的數(shù)據(jù)，自動提取和歸類數(shù)據(jù)，使得小程序數(shù)據(jù)運維更加高效、準確；

審核編輯 黃宇