一、京東小程式是什麼

京東小程式平臺能夠提供開放、安全的產品，成為品牌開發者連結京東內部核心產品的橋樑，致力於服務每一個信任我們的外部開發者，為不同開發能力的品牌商家提供合適的服務和產品，讓技術開放成為品牌的新機會。「Once Build, Run Anywhere」，一個小程式可以在多個APP執行，引擎層抹平差異，一套程式碼，相同頁面，雲端下發，多端執行。

可能大家還不太瞭解我們的京東小程式，京東小程式到底是什麼呢？它和微信小程式有什麼區別？首先呢，需要明確的是，京東小程式不是執行在微信端的京東商城購物小程式，而是執行在京東APP的，基於京東小程式引擎的一套京東系的小程式。

它是和支付寶小程式或者微信小程式對標的一類京東化的小程式。

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

當然，京東小程式不僅僅可以執行在京東APP上，只要宿主在執行時依賴了我們的小程式SDK引擎，就可以實現在各類其他宿主APP上的執行，譬如，在京東小家APP上，可以通過小程式去控制智慧IOT裝置，在京ME的APP上，可以遠端操作印表機，實現一鍵列印。小程式作為一種輕量級的即用即走的工具，使用者群體廣泛，早已覆蓋到了我們生活的方方面面。

京東小程式是連結商家和京東內部核心產品的重要橋樑，也是助力商家實現流量增長、業務發展的一個重要方式。

那麼，小程式平臺是怎麼保證商家業務的穩定、健康發展，服務好這些外部商家的呢？這裡面非常重要的是我們平臺對小程式基本流量的運營與監控。如何不讓業務的小程式線上上裸奔？如何幫助業務對自身小程式流量的衝高回落有一種直觀的把握和監測？如何基於海量資料指導業務去進行一個精細化的運營？實際上，京東小程式資料中心就扮演了一個這樣的小程式資料問題終結者的角色，充分利用各類資料手段，解決這些痛點問題。

二、京東小程式資料中心建設里程碑

京東小程式資料中心的建設，主要經歷了四個階段，從最開始的由0到1搭建了資料基礎能力，到豐富拓展各類資料指標，接著下鑽分析到使用者，幫助商家實現基於使用者的精細化的運營，到目前的小程式數智化建設，在整個小程式的迭代建設的過程中，都從各個維度為小程式的業務發展實現了保駕護航。

三、京東小程式資料中心業務全景圖

• 從功能角度，京東小程式運營資料分析，京東小程式監控資料分析；
• 從展現角度，開發者控制檯，管理後臺，行動端小程式助手，宙斯開放能力；
• 從功能領域角度，使用者行為分析，交易鏈路資料分析，人物誌，流失率監控，流量監控等；
• 從上報通道角度，子午線，自定義上報，伺服器端埋點；
• 從資料儲存角度，JED，JimDB，ES，HBase等；

目前京東小程式資料中心功能範圍廣泛，我們在根據業務發展的需求，不斷完善整個京東小程式資料中心的功能架構。

從展現角度看，包括開發者控制檯，管理後臺，行動端小程式助手，實時資料大屏, 開放openApi能力；

其次是從功能領域角度看，主要包括運營資料分析，監控資料分析。

運營資料分析，包括使用者行為分析，比如小程式基礎的pv和uv；

來源分析，可以去分析小程式在各個廣告投放渠道下的行銷轉化效果；

人物誌分析，可以分析到瀏覽過小程式的人群中的哪些是高淨值使用者群體，以及性別以及年齡等基礎的人物誌資料。

監控資料分析，主要是針對線上執行的小程式的奔潰異常，網路請求異常，啟動效能資料的分析，使用者流失率的實時監測等，可以在小程式出現異常時第一時間通知到開發者。

四、京東小程式資料中心技術架構圖

對於整體的架構設計，其實在我看來，資料的分析，主要是解決三個問題，第一個要解決的是資料如何上報的問題，第二個是解決資料如何儲存的問題？第三個才是解決資料如何分析的問題？

1、京東小程式資料中心的資料上報主要包括三個途徑，主要包括使用者端埋點，伺服器端埋點或者其他外部的資料來源，使用者端埋點主要利用的是子午線，伺服器端埋點主要是我們服務之間採集資料，服務之間消費和同步。

2、資料存到哪裡去，這個需要基於我們業務上對這些資料的實時性要求，判斷是實時還是離線，進而採用不同的資料來源進行儲存，資料指標是要秒級的？分鐘級的？還是T+1l型別的，實時性要求不同，那麼儲存的資料來源自然也就不同。

3、資料如何分析，實際上就是我們的業務邏輯，在設計時也需要充分考慮資料模型的複用性和可拓展性。

小程式資料中心對於來自子午線使用者端埋點資料，以離線的方式構建小程式自己的業務數倉，一層一層地進行資料的降噪，清洗和計算，將聚合好的維度資料再推播到關係型資料庫，方便業務快速接入。對於來自自建通道的實時資料以及外部系統的埋點資料，通過統一上報服務將資料上報到訊息佇列，進行流量資料的非同步處理和消峰，採用專門的消費者服務對上報資料進行消費落庫，儲存到ES和HBase資料庫，便於平臺進行多維度的明細或者彙總資料查詢；同時，也會基於Flink對訊息佇列中的資料進行流式實時計算，實現異常波動流量的告警和分析。

五、它山之石可以攻玉，藉助集團資料工具打造小程式業務數倉

痛點問題：

1.京東小程式的資料來源多樣化，資料量級龐大，如何立足業務資料，發揮資料價值，幫助商家實現精細化的運營？

2.如何複用主站已有的資料模型和能力，讓更多的小程式商家參與到京東主站的流量場，讓資料驅動商家精準行銷？

3.業務指標紛繁複雜，如何沉澱和抽離通用資料模型，減少重複工作？

如何解決：

基於集團BDP平臺，自上而下構建京東小程式的業務數倉，藉助BDP平臺豐富的資料產品工具，多維度地構建小程式的資料能力。離線計算+實時計算相結合，小程式業務資料+集團模型資料相結合。

1.資料分類化，將小程式流量進行主題劃分，拆分為點選、瀏覽、曝光、訂單等大維度的主題模型，方便資料定位，增加業務理解；

2.資料分層化，同一個流量主題下，進一步按照ODS->DWD->DWS->ADS的層級結構進行分層，方便追蹤資料血緣，減少重複資料模型的開發；

3.資料多元化，下游系統可從小程式資料倉儲拉取符合業務需要的領域資料，比如數紡，搜推廣等系統，利用下游系統成熟穩定的資料能力，為商家行銷充分賦能；

在京東小程式的業務數倉搭建過程中，主要還是應用了集團BDP巨量資料平臺提供的豐富的產品工具和通用能力。

幾種典型的使用案例是：

1、離線hive表資料同步到jed等關係型業務庫，使用buffalo任務中的出庫運算元；

2、業務產生的實時MQ資料同步到hive數倉，使用DTS，實時資料傳輸任務，可以把業務資料同步到數倉；

3、我們需要在數倉中構建業務維表，比如構建小程式基本資訊的維表，業務資料需要同步到hive表，可以採用資料直通車DataBus，在表記錄的生成上，可以根據業務的需要，採用全量表，增量表，快照表，拉連結串列或者流水錶的不同的記錄生成方式。

京東小程式使用者端埋點統一上報的子午線，需要從最原始的gdm層底表提取小程式自己的業務資料，原始底表資料量級非常大，不可能每次直接對原始底表查詢，這樣的話耗費計算資源，效率較低。所以，我們儘量提高底層資料模型的複用度，對資料進行分類化和分層化處理。

所謂分類話，就是將小程式流量進行主題劃分，拆分為點選、瀏覽、曝光、訂單等大維度的主題模型，方便資料定位，增加業務理解；

所謂分層化，就是在同一個流量主題下，進一步按照ODS->DWD->DWS->ADS的層級結構進行資料分層，方便追蹤資料血緣，減少重複資料模型的開發。

所謂多元化，就是複用度，加工好的這些資料，可以給下游的團隊接入使用，比如商智，黃金眼，數紡這些團隊。以小程式廣告投放為例，在小程式數倉中我們構建了各個型別的使用者群體，在數紡註冊了使用者群體標籤，比如關注使用者，粉絲使用者或者提單使用者等，下游的廣告精準通系統會基於我們的這些標籤進行人群的圈選，進而實現小程式廣告的投放。

總之，根據業務特點，充分利用好集團BDP的資料工具，幫助我們實現數倉的搭建。

六、基於FLINK實時計算，落地小程式異常奔潰監控利器

痛點問題：京東小程式線上上執行時，需要實時監測到小程式的業務程式碼崩潰異常、效能資料波動，網路請求耗時等，在有異常崩潰的情況下，保證可以第一時間通知到商家開發者，幫助業務及時止損。

如何解決：

1.報警規則可設定，基於Zookeeper分散式設定中心儲存小程式自定義的告警規則，實時監聽規則節點變化，當節點資料變化時，實時聚合到業務流；

2.自定義滑動視窗，每個小程式的告警視窗大小不一樣，拓展實現WindowAssigner，基於使用者動態規則確定告警視窗開始時間和截止時間；

3.廣播變數，broadcast機制，將告警設定資訊廣播到各個Task任務記憶體，廣播變數就是一個公共的共用變數，將一個資料集廣播後，不同的Task都可以在節點上獲取到，每個節點只存一份，否則，每一個Task都會拷貝一份資料集，會造成記憶體資源浪費。

對於小程式的實時監控能力，我們採用flink作為實時計算的框架，小程式線上上執行時，需要實時監測到小程式的業務程式碼崩潰異常、這種異常很可能會導致小程式白屏或者閃退，需要在探測到有異常崩潰的情況下，保證第一時間通知到商家開發者，幫助業務及時止損。

這裡的難點在於告警的規則是支援使用者自定義的，比如設定觀測多長時間視窗內的異常資料，當達到多少的異常閾值，應該去觸發告警，應該判定為異常，這裡是需要把告警規則設定的的主動權交給使用者的，在這樣的背景下，

1、 我們採用的是將告警規則放到分散式的統一設定中心，實時監聽節點規則的變化，將業務流和規則流進行connet雙流合併；

2、 然後根據告警規則，實現windowAssigner生成自定義的動態計算視窗，從而實現視窗動態化；

3、 最後，採用廣播變數的broadcast機制，當告警規則變更時，可以高效地將告警設定廣播重新整理到各個Task任務記憶體，提高資源利用率，保證計算時效性。

七、探索OLAP領域的黑馬，基於ClickHouse搭建自定義資料分析引擎

痛點問題：小程式內部的資料波動如何自由埋點分析？京東內部業務直接基於子午線埋點上報，業務團隊內部自行分析；外部的開發者需要依賴神策,GA等外部的分析系統，無法將資料迴流京東，且複用京東現有流量工具進行精細化運營。

如何解決：

1.選擇合適的表儲存引擎：採用多副本的ReplicatedMergeTree，保證查詢效能和資料儲存的高可用；

2.按天分割區儲存資料： PARTITION BY：分割區鍵，PARTITION BY toYYYYMMDD(EventDate)，不同分割區下的資料會分開儲存，合理建立分割區可以加快查詢的速度；

3.統一上報協定：生成全域性唯一事件ID，事件ID繫結業務資料；

4.動態資料解析：基於visitParamExtract函數解析json動態業務資料；

5.查詢指令碼下推：Sql引擎生成查詢Sql，下沉至ClickHouse完成查詢；

小程式內部的資料波動如何自由埋點分析？京東內部業務是可以直接基於子午線埋點上報，業務團隊內部自行分析，但是子午線這種產品本身不對外開放，外部的開發者如果想分析小程式自身的內部資料，需要依賴神策，GA等外部的資料分析系統，這樣的話，小程式的資料無法迴流京東，那麼也就無法複用京東現有流量工具進行小程式的精細化運營。

在這樣的背景下，我們落地了小程式的自定義分析引擎，底層採用了clickhouse這種適合做即席查詢的olap引擎，用來儲存小程式上報資料.

為什麼採用clickhouse? clickhouse是基於列式來儲存資料，查詢效能非常高，在億級資料的體量下，可以做到秒級的響應，適合做線上的OLAP。

同時，ck支援水平的拓展，適合巨量資料量的儲存，支援按天進行資料的分割區儲存，在建表時，根據記錄的建立時間劃分partition，在查詢資料時，可以只查某些partition分割區的資料，也可以加快查詢的效率。

包括本地表和分散式表，本地表執行在各個具體的資料節點，分散式表負責資料的轉發和路由。寫入資料只寫本地表，50-200M/S ,對於大量的資料更新非常實用。

在小程式自定義分析引擎中，規範了資料上報協定，首先由使用者設定需要上報的事件ID和業務指標，按照協定約定呼叫前端jsAPI上報業務資料。在自助查詢區域，當用戶觸發查詢時，先基於規則引擎利用自定義事件ID生成查詢規則SQL指令碼，將規則下推至伺服器端執行引擎，執行引擎從CK獲取業務資料，完成業務資料的一次自定義查詢。

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

痛點問題：需要實時分析小程式的pv、uv、新增使用者數、累計使用者數以及關注使用者數等使用者行為類指標，幫助小程式商家掌握自身小程式的使用者波動情況。

如何解決：

1.實時性，從小程式的使用者行為埋點資料上報到可存取，支援秒級響應；

2.全文檢索，基於倒排索引，支援靈活的搜尋分析，支援按照小程式不同業務維度進行聚合分析，滿足不同的業務需要；

3.易於運維，小程式的日均DAU在300W+，可以基於天、月等維度建立索引，方便進行冷熱資料分析；

建立ES模板： 週期性按天建立ES索引：

利用索引主鍵碰撞實現新增&累計使用者統計：

語法:

index語法: PUT miniapps/_doc/1

create語法: PUT miniapps/_create/1

語意:

index自動生成id,多次建立,會生成多個document;

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

create自動生成id,多次建立,會生成多個document;

create的重複建立指定檔案id的內容,第二次執行建立會報錯(主鍵碰撞),而不是版本號++;

我們是如何做小程式的實時使用者行為分析的呢？行為分析需要實時計算小程式的pv、uv、新增使用者數、累計使用者數以及關注使用者數等使用者行為類指標，幫助小程式商家掌握自身小程式的使用者波動情況。我們將這些資料統一放在ES中進行查詢，主要考慮到ES支援靈活的搜尋分析，支援按照不同維度進行聚合分析，保證了資料查詢的靈活性和實時性的需要。

在建立索引時，不是將資料都堆放到一個索引，而是將按天去建立，基於索引模板，週期性地建立ES索引，保證索引查詢效率。

在構建小程式的新增使用者的指標時，利用了ES索引碰撞的原理，設定操作型別operateType為create，create的語意是重複建立指定檔案id的內容,第二次執行建立會報錯(出現主鍵碰撞),這樣的話，保證新增使用者的記錄在ES索引中只出現一次。

九、不足和展望

1、沉澱小程式行業資料解決方案

沉澱比如車企、保險、3C家電等行業類資料，形成統一的京東小程式行業資料解決方案

2、技術沉澱複用

後續可以把成型的京東小程式資料分析技術方案推廣到其他技術棧，比如RN等平臺系統

3、智慧化建設

考慮如何基於機器學習、人工智慧、ChatGPT等技術手段，加強京東小程式資料的智慧化建設，如何結合機器學習、深度學習、人工智慧AI等技術手段，繼續實現京東小程式資料中心的智慧化建設。

• 預測性分析能力：

小程式的智慧告警，基於時間序列預測演演算法，比如Facebook Prophet演演算法等，做一些告警預判，提升告警的智慧性和準確率；

• 資料探勘演演算法：

在小程式的預下載場景，可以基於協同過濾演演算法，做小程式偏好人群的判斷，實現預下載的千人千面，從而減少網路頻寬，節省資源成本等；

• 語意引擎：

如何將ChatGpt這種AI智慧模型，可以分析和理解大量的資料，自動提取和歸類資料，使得小程式資料運維更加高效、準確；

作者：京東零售 徐佳慶

來源：京東雲開發者社群 轉載請註明出處