01、業務集市現狀

首先介紹一下京東業務集市的現狀。眾所周知互聯網軌道生命周期已經進入成熟階段處于人口紅利倒退的趨勢中，各個公司都以精細化運營的方式來正面應對此情景，所以數據驅動成為業務決策的中堅力量。

1. 數據驅動力

數據驅動力指的是通過數據體系系統化地獲取及分析數據，為業務決策提供有效支撐，驅動業務發展。

2. 業務市集現狀

在業務數據增長越來越明顯的趨勢下，構建業務體系、獲取數據能力就目前而言是非常重要的，但業務集市的歷史構建主要由各個業務線的數據分析同學負責，他們的關注點更多在于數據的快速交付，一定程度上造成了數據集市無序建設的問題。業務集市的現存的問題主要有以下四點：

（1）煙囪式開發現象嚴重：每一個需求都對應一個模型，每一個模型都需要開發，模型的重復性較高且模型較為分散。此時就會造成冗余計算的情況，浪費了過多集群資源。煙囪式開發也是較為常見的情況。

（2）跨層依賴嚴重：跨層依賴嚴重，讀取共享數據有明顯問題，存在大量重復讀取消耗 IO 資源，缺乏共享復用。業務團隊的數據分析同學使用的數據源通常為貼源層數據，數據量較大、字段較多，會對資源造成一些不必要的消耗。（3）業務數據共享度低：一個公司/部門可能存在多條業務線，但這些業務之間并不是完全獨立的，存在較強的數據的耦合性，但數據共享度較低。（4）無統一的數據標準：各業務團隊之間無統一數據標準，數據口徑難以保持統一，導致數據質量參差不齊，進入惡性循環。業務同學無法感知已有數據維度與需求的關聯匹配程度，從而無法深入挖掘數據價值，也無法得知數據統計的準確口徑，導致數據信任度較低、數據失真的情況。

這樣的集市現狀給數據的使用帶來了很多問題，總結來講就是：不可知、不可取、不可用、不可控。

不可知：用戶不知道集市/平臺中有哪些數據可以使用，是否能夠幫助自己解決核心問題。

不可取：用戶難以做到數據與知識之間的快速轉換，同時集群資源緊張導致取數困難。

不可用：各業務的數據分類體系缺乏統一的原則規范，使得數據定位難、可信度降低。

不可控：不關注集群狀態導致的惡性循環。

02、業務集市治理

對于存在上述問題業務集市治理來說，除了使用現有常見的即時治理工具之外，更還有著更為重要且比較根源性的做法：建立業務集市標準，以及對歷史無序情況進行重構。

由于業務數據分析同學與數據開發同學所在角色和思維角度的不同，業務同學關注點更多在于如何經營階段內的數據目標、階段性的 OKR、KPI 等數據指標如何向下拆解，但數據開發同學的焦點在于如何保證數據的可用性和集市的穩定性。對于一個良好的業務數據集市來說，自上而下通過基礎數據來逐步逐層地、秩序穩定地實現業務數據支撐是極其重要的。

在期望之下衍生出了新的數據框架：

最底層為現有的常規數據倉庫。

中間第二層為基礎建設，此部分主要是建設基于業務基礎的通用層模型，通過此部可以為業務線或耦合性較強的業務群組創建一套標準化通用的基礎層，不僅可以配合一些維表來實現業務數據的維度擴充和數據快速定位，還可以在此基礎上利用一些中間表來減少在計算過程中的資源浪費。

在基礎層的建設之上，基于基礎通用數據模型、結合業務需求將經營目標拆解成具體的數據指標，通過數據之間的交叉計算給出更深層次的分析，或者將部分數據建設成為數據看板進行數據可視化的展示。這些數據指標可以為業務同學的經營分析起到很好的輔助作用，涵蓋從項目規劃、到日常經營、再到效果復盤、最后到下一個新的決策如此循環的完整過程，與此同時也能夠逐層保證產出的數據質量。

在這樣的框架下，越高層級的數據越精細化，數據統計的口徑更加定制化。越底層的數據模型復用度越高，越標準。如此的層級會使數據集市更健康。

業務基礎模型規范

用建設業務數倉的思路來建設標準化的通用模型，主要存儲數據為公司內部標準通用的明細數據。重構建設的主要措施是封裝標準口徑、行列裁剪、維度擴展、跨主題拼接等。此部分的口徑是廣義的，不針對于具體某一個業務需求，而是更專注于一整條業務線或一個大的業務模塊上的普適性。重構建設時，可以按照不同業務線/業務模塊組織數據，進行明細數據的整合，解藕數據源，簡化數倉模型使用復雜度，減少讀取。

業務通用模型實踐

用戶寬表的建設：其實是將一些訂單主題的數據和用戶主題的數據進行融合，在訂單數據的基礎上，將不同業務對于用戶的一些不同身份的定義全部拼接至同一張表中，并擴展一些標準的、通用的數據維度信息，支持不同業務的數據調取。這樣的處理方式可以保證數據口徑的統一。

數據指標體系

數據指標體系，即數據應用層，此層級的主要目的是支持業務進行某些經營專題的分析。這里的數據指標會按照業務的具體需求進行設計并包裝，一般會根據特定的數據統計口徑進行不同交叉維度的計算，用于其他系統的底層數據支持、數據看板可視化展示，或直接提供給業務同學進行深層次的數據分析?？傮w來說此部分數據的口徑更加精準化，更貼切于用戶經營目標的分析和監控。

指標緯度值統一

數據指標總體來講可以分為三類：基礎指標、衍生指標和復合指標。

基礎指標可以理解為較為常見的、直接計算的數據指標，例如成交人數、成交金額等。

衍生指標可以理解為在基礎指標的基礎上結合一些定義將指標之間進行組合或者通過運算得到的一些數據指標，比如復訪率、轉化率等。

復合指標通常指數據的對比情況，比如同比、環比等。

在計算衍生指標時，分子分母可能已經存在在不同的模型中，此時如果能快速定位到需要的分子分母數據，就可以避免計算衍生指標時對分子分母的重復計算。

針對此情況，開發出了一個特有工具，此工具可以根據不同的維度組合生成全局唯一的場景指標編碼，不論在什么時間、什么引擎下，同樣的維度所生成的指標維度 ID 值都是一樣的。這樣在計算衍生指標時，通過維度 ID 一致+維度枚舉值一致，即可獲取相對應的分子分母，快速計算衍生指標。

ClickHouse 字典刷崗

由于 SKU 的歸屬是與人員身份進行相應綁定的，若人員身份產生變動時會影響到某類 SKU 的采銷部署，所以需要進行刷崗操作，其本質是更新 SKU 和維度信息之間的對應關系。

刷崗的整體難度較高，主要體現在三部分：第一是數據量級大，可能涉及到百億數據量級的兩張甚至多張大寬表進行關聯刷新；第二是維度組合較多，導致計算量極大；第三是業務側要求的刷新范圍不斷擴大，甚至個別主題希望全量進行刷新，時效要求較高。

提出了 ClickHouse 字段刷崗的解決方案，在 ClickHouse 中將維表加載到字典，將明細表基于字典直接進行相應崗位的數據查詢，這樣查詢邏輯更簡單，查詢效率更快。

基于此解決方案，也有一些相應的優化措施：

① 字典存儲按照 SKU 分片存儲，可以極大的減少占用內存空間的數量；

② 縮減字段，將維表中無關刷崗的字段過濾掉，此部分可以減少50%的字典存儲空間；

③ 類型優化，比如部門 ID 等 ID 類的字段，在存儲時可以將數據類型由 string 轉化為 int 類型，使用時再轉為 string 類型，在保證正確使用的情況下字典空間占用可減少 60%；

④ 考慮到字典的主鍵唯一性，將 sku 一對多的情況用 Array 類型進行存儲。

為保證刷崗準確性，增加校驗機制，引入版本表，將刷崗的結果先寫入版本表中，將版本表和原有數據進行對比驗證，得到驗證結果是正確的才會寫入正式的明細表中。

字典表的應用同樣可以用于數據看板的服務查詢中，與刷崗原理是一致的，通過加載 sku 對應的字典數據來獲取維度信息。

對于一整套的業務集市建設標準，以一個活動主題的數據舉例說明治理效果。

重構前，數據指標依賴復雜，大多指標直接依賴于貼源層級的數據，比如用戶日志模型。這些模型的數據量極大，對于需求無用的字段很多，因此數據重復讀取率極高，造成了數據資源的浪費。

重構時，針對讀倉成本居高不下問題及用戶使用行為分析，對讀取頻率 top 的大模型（比如用戶日志）進行列裁剪，僅存儲近兩年熱數據。

針對隊列資源緊張，調度不合理的問題，通過對各業務模塊常用的埋點信息進行統一收集，通過埋點過濾構建 app 層加速模型，通過減少數據量，降低任務執行資源消耗。

對于一些與其他業務耦合性較強的應用層數據，封裝標準口徑沉淀至數倉，反哺業務其他指標/其他業務。

在計算數據指標時，不再直接依賴貼源層數據，而是依賴通用層模型，減少讀倉成本。使用產出唯一維度 ID 的工具來減少重復計算。維表存儲數據特性，提供維度信息，通過表關聯拼接快速對數據進行特定維度的定位/區分。合理設計中間表，降低加工過程計算難度，提高運行效率?？稍O置為臨時表，僅幫助加速本次計算，不存儲歷史數據。也可設置長期中間層，包含歷史數據。

采取此方式進行重構后，可以降低 43% 的讀倉成本；應用層模型數量減少51%，存儲降低 34%；末端的的看板產品出數時間縮短 3 小時。

03

展望未來

敏捷、智能、可用、驅動力。

在數倉建設、數據體系建設、資產分級以及對數據智能化自動化的探索（智能標準的建設）等方面，京東數據團隊會對其進行持續的探索，以期望打造一個敏捷、智能的業務數據集市，并能夠以數據驅動業務發展。

04

問答環節

Q1：根據崗位回溯數據代價大是否存在代替方案？

A1：代價是相對的，相對于數據集市建設的意義來說代價是允許存在的。可以弱化回溯的概念，對于數據量可接受范圍內且適用于業務場景的查詢，可以在保留基礎數據信息的前提下，將某些數據信息不進行落表物化數據的操作，通過查詢進行數據的展示，例如用戶在查詢 SKU 數據時，用 SKU 去查關聯字典數據并進行相應的數據展示。

Q2：在數倉之上再建數倉的形式增加了數據跑數的周期，是否可以對原始數倉進行治理？

A2：原始數倉治理和新建業務層級數倉是兩個概念，不是沖突的，本次分享基于業務數倉的治理，新建業務層級數倉時有必要的。在現狀中，業務側的數據大多直接來自貼源層，若以極小數據量級的查詢調取數據量較大的貼源層數據，也是得不償失的。且基于京東這樣的大平臺來說，存在著許多條業務線，那優先考慮、兼顧的一定是全局的數據情況，而不是某一條具體的業務線。

Q3：指標是按照主題域的方式來劃分管理的嗎？多鏈路漏斗指標追蹤是如何實現的？

A3：可以理解為按照主題域的方式來劃分管理的，但實現過程中并不是以此單一條件進行實現的。數據溯源的最底層級是貼源層數據，是按照主題域劃分的。但主題域的數據在使用時也不是單獨使用的，也存在著主題域之間的交叉計算等。將數據指標進行主題劃分后對上游數據源可以更好的追蹤管理，對數據之間關系的管理也會相對簡單，所以在計算時會先按照不同的主題進行劃分，后在結果表中對不同主題的數據進行拼接。