小米資料中臺建設實踐賦能業務增長

　　導讀：本文將介紹小米資料中臺部門在銷售數倉建設方面的實踐。文章將從小米銷售數倉的發展歷程開始，介紹其定位、內容、作用、規模等，並分享數倉建設常用的維度建模和分層理論，以及小米銷售數倉的架構演進和能力沉澱。

　　 01 銷售數倉介紹

　　首先介紹下小米銷售數倉，包括髮展歷程、銷售數倉定義、資料獲取使用、銷售數倉的內容和規模。

　　在 2019 年前，小米的中國區、國際部等業務資料團隊在進行獨立的數倉建設，這個時期是煙囪式的開發。隨著業務飛速發展，在集團技術委 ABC（AI、Big data、Cloud）策略的指導下，開始建設統一的銷售數倉。在 2020 年，完成了離線銷售數倉的建設，同時在籌備實時數倉的建設。2021 年，實時數倉建設完畢，隨著後續的業務和技術升級，進入了迭代最佳化和資料應用階段。　　

　　小米的銷售數倉整體上就是存放整個公司銷售資料的倉庫，包括了訂單資料、物流資料、門店資料、使用者行為資料及商品資料，並按照維度建模和規範進行建設的高效資料集合。　　

　　上圖是銷售數倉的場景圖，資料主要來自於兩個部分，一是線上業務資料，主要是訂單系統、商品中心（小米的所有商品進行管理的地方）、門店系統（線下門店進行管理的地方）、售後系統和進銷存系統。同時也有一些日誌採集資料，經過銷售數倉的處理，劃分為不同的主題進行建設。銷售數倉整體會進行後設資料管理，目標是做到全域的後設資料管理。最上層是資料應用層，包括集團資料看板、三區運營的看板、實時大屏、大促戰報和資料探勘。

　　銷售數倉資料的獲取主要透過以下三種方式：

　　使用者透過資料地圖進行查詢，資料地圖中會顯示叢集、儲存介質、表詳情、血緣等。

　　透過資料工場，可以進行資料查詢以及任務的開發部署等。

　　透過資料百科，對資料指標進行管理錄入和使用。

　　數倉的使用形式有多種，包括傳統的離線 Hive、資料湖 Iceberg、實時訊息佇列 Talos、OLAP 引擎、即時查詢等。

　　銷售數倉的目標是為公司提供準確好用的銷售資料。在區域方面，包含全球的業務；在品類方面，包含手機、筆記本、大家電、生態鏈等；在渠道方面，包含小米網、商城、米家、三方平臺等。我們的日單量在千萬級別，每天會處理上億條日誌資料。　　

　　 02 數倉建設理論

　　在進行數倉建設時，首先是梳理業務，找到核心業務邏輯，對業務過程進行認識和理解，並在資料庫中找到相關的資料表。在此基礎上，站在更高維度對業務流和資料流進行彙總和分類，劃分好主題域，便於後續的管理。然後進行事實表和維表的梳理，藉助資料百科進行指標梳理，以具體的業務為核心，指標與維度同等重要。接下來對數倉進行建模，按照維度建模方式組織資料，在這個過程中需要注意分層和規範。最後就是物理實現，這個環節重點關注的是開發規範、交付物、質量等　　

　　接下來介紹數倉分層方式。數倉分層最底層是 ODS 層，它是貼源資料，與業務資料保持一致。在 ODS 之上是 DW 層，DW 層可以細分為兩層。一層是 DWD 基礎資料，主要做清洗和規範化，不對數倉團隊外部開放使用。另一層是 DWM 層通用資料。基於 DWD 的資料做關聯和聚合，會將核心的邏輯實現放在這一層，用於提升公共資料的複用性，可以開放給外部團隊使用。數倉中還有 DIM 層（維度層），DM 層（寬表層），ADS 層（應用資料層），以及 TMP 層（存放臨時表）　　

　　在數倉建模過程中，需要遵循以下一些基本的建模原則：高內聚低耦合，公共邏輯下層，成本與效能平衡、一致性、資料可回滾。　　

　　1. 高內聚低耦合

　　將業務相近的資料設計為一個邏輯模型或者物理模型。例如訂單有很多來源，包括小米商城、小米網、有品商城以及三方資料等。在 DW 層會整合為同一個訂單表，同時會對一些缺失欄位進行預設處理，保證所有來源的資料最終在 DW 層是統一的，從而實現高內聚。訂單和物流被劃定為不同的主題，以減少其耦合度。

　　2. 公共邏輯下沉

　　前面介紹數倉分層時，指出公共邏輯要儘量放在 DWM 層處理，對下游使用方儘量遮蔽複雜的業務邏輯，從而做到口徑統一。例如在訂單處理過程中，會有很多無效的訂單，識別無效訂單的核心邏輯在 DWM 層，這樣下游業務方就可以直接使用。

　　3. 成本與效能平衡

　　一定的資料冗餘，雖然可能帶來成本增加，但查詢效能可以得到提高。例如在區域維表設計中，針對國家、省份、城市、區縣，透過一個區域層級欄位將其分類，雖然資料是冗餘的，但使用者使用起來會比較方便，並且查詢更快速。　　

　　4. 一致性

　　在數倉建模過程中，要保證欄位含義和命名規範是統一的，這樣可以降低理解和使用的成本。

　　5. 資料可回滾

　　要保證資料可回滾，在不同時間去執行數倉的排程，針對歷史資料計算出的結果是一致的。

　　那我們是如何進行指標管理呢？在小米內部會透過 OSM 模型，根據公司的目標和策略，透過數倉中的度量值進行考核。　　

　　例如 2023 年的目標是手機出貨量要達到 X 萬臺，相關策略是要設計好產品，提高使用者購買；同時嚴控質量，減少質量問題帶來的影響。基於目標和策略，在銷售數倉中透過兩個度量值來衡量，一是手機妥投數量，這個數值要儘可能高；二是手機售後退貨數量，反饋質量情況。

　　指標生產是基於 Hive 離線資料、MySQL 線上資料、分析資料進行建模，建立語義模型，再進行稽核認證，釋出到集團指標庫，與資料百科進行聯動。在指標消費側，使用者可以透過資料百科進行查詢指標口徑詳情、上游血緣、維度等，資料百科與公司的 OA 工具進行聯通，提高指標易用性和使用效率。

　　 03 銷售數倉架構介紹　　

　　小米的銷售數倉採用的是 Lambda 架構。銷售資料是集團數倉中的核心之一，內部關注度高。如果是流處理，部分情況下無法達到百分之百的準確性，因此需要透過批處理，去保證 T+1 資料的準確性。在批處理層使用 Spark 加 Hive 去處理離線資料。在流式處理層，使用 Flink 加訊息佇列 Talos。在 DW 和 DM 層，會透過 Hologres 進行維表的加速查詢。最終再把這兩部分資料進行聯合，提供給下游業務方使用。　　

　　我們在處理銷售實時資料中，會遇到各樣的問題，這裡介紹下實時資料流狀態過期問題的解決方法。在實時資料中，銷售訂單主要分兩部分。第一部分是訂單事實表，第二部分是訂單明細事實表。訂單中所有的狀態變更都體現在訂單事實表，而訂單明細資料在第一次建立之後，就不會再發生變化。大家都知道，實時計算訊息佇列的儲存時間是有限制的，通常會設定一個時間週期。Flink 也有計算狀態的儲存時間，在一定時間週期後計算狀態會過期，需要注意的是，由於訂單明細不再變化，如果一些訂單主表的兩次狀態變化時間大於狀態過期時間，這時候銷售相關指標是失準的。

　　實踐中是透過引入一個離線流，在訂單和訂單明細上各自去識別這部分過期資料，透過一個離線資料的訊息佇列，與原始的實時資料流進行合併，去重後下發到下游進行處理，大幅度提高同類場景下資料準確性。

　　但是這樣會引發另外一個問題，即批處理思維方式帶來的物流指標異常。　　

　　以物流場景為例，一些國際業務在商品出貨後，由於距離較遠或者報關審批等流程，會導致部分貨物可能三個月後才發生一個狀態變更。物流主表記錄物流狀態的變更，物流明細表以及離線的補充物流明細表會進行合併操作，之後對這兩部分進行去重，去重後的結果再與物流主表進行關聯，然後下發進行其他的處理邏輯。這是一個典型的離線處理思維。上述處理方法忽略了一個重要的環節，即 Flink 中運算元 state 的儲存機制。　　

　　在補離線流的時候，由於補充離線任務本身也需要排程時間，導致資料可能無法及時精準的補進去，為了準確的補充離線資料，會多補充一部分資料。在 RANK 運算元下發時，多補的這一部分資料，會導致實時流中的明細資料不過期，即離線資料流跟實時資料流進行合併和排序操作會使實時資料中的原始流過期時間進一步延長，不會下發對應的明細資料到 join 運算元。實際解決是透過利用 Flink 中的處理時間，按照物理明細表的業務聯合主鍵下發最後一條資料，主要的解決思路就是深入理解實時計算過程，避免受離線開發思維影響。

　　接下來介紹一下基於 Iceberg 的儲存批流一體方案。　　

　　主要是將離線處理中的 Hive 和實時處理中的 Talos 全部換成 Iceberg 去處理。選擇 Iceberg 的原因是其對結構化和非結構化資料都有很好的支援。小米有一些非結構化的三方資料以及一些跟谷歌合作的 BQ 埋點日誌，這些資料比較複雜，把這些資料儲存在 Iceberg 中會比較方便。Iceberg 支援事務寫，在其變更過程中，不影響下游業務讀取資料，這方面 Hive 是做不到的。另外小米計算平臺團隊透過 merge into 語法，實現了對 Iceberg 資料的高效修正，使得離線和實時可以高效地相互融合。

　　但這個方案也存在不足之處，由於 Iceberg 的事務提交依賴 Commit，但是在實時寫入中每次 Commit 的速度會依賴 Checkpoint 設定的時長，所以無法做到秒級別的實時。

　　 04 數倉能力層

　　下面介紹銷售數倉能力層，即數倉經過一定的建設和升級，逐漸沉澱下來的一些公共能力。

　　首先是統一的資料架構。準實時資料需求是基於 Iceberg 的分鐘級流批一體處理方案；在實時方面，是基於 Flink + Talos 的秒級處理方案及離線批處理方案。　　

　　數倉規範在數倉能力層中舉足輕重。日常工作中非常重視具體的開發過程和規範，尤其是對一些新同學，規範是必要且實用的。透過數倉開發和質量規範，會統一表命名方式、欄位命名方式、數倉分層等，配置 DQC 相關的完整性校驗、一致性校驗、空值率校驗。　　

　　資料安全是數倉能力建設的一個重要方面。一是透過合規管控，所有的資料生產環節都嚴格遵守國家的法律法規。在公司內部有質量部、隱私委以及法務部會對所有環節進行監控。二是會進行安全分類，即按照資料的敏感度和重要性將資料進行分類。三是在許可權控制方面，會嚴格規範資料流程，在每個部門都會有對應的安全負責人來負責最終的安全校驗。在審批過程中，會遵循許可權最小的原則。核心研發人員和使用人員，簽署資料保密協議。四是叢集隔離，小米是一個國際化公司。在國外會將機房部署在當地，並且機房之間的資料明細是不允許傳輸的。對一些彙總的指標，經過安全負責人的審批之後，可以傳回國內進行分析。在歐洲的資料業務，會嚴格遵守歐盟的 GDPR 條例。針對海外資料，會成立國際資料運營中心，本地開發部署和運維。　　

　　數倉能力建設的一個重要環節就是指標應用。具體的指標應用是資料百科，如下圖右側所示，資料百科中包含全部資料口徑的描述、基礎資訊、維度的拆解和相關指標。在指標口徑上會嚴格指定許可權審批的負責人，明確整個指標的詳情。下游可以透過資料百科，快速瞭解相關指標。部分指標會和集團資料看板進行聯動，提供給集團的管理者使用。　　

　　 05 總結與展望

　　最後進行一下總結和展望。

　　經過幾年的建設和應用，我們已經基本建成了離線銷售數倉，公司的運營和管理層都在深度且廣泛的使用銷售數倉資料。團隊內部沉澱了資料架構和數倉能力規範，會不斷與業界進行交流學習，探索優秀實踐案例。

　　銷售數倉未來的兩個趨勢，一是資料的價值化，二是指標的實時化。由於目前公司處於快速發展的過程中，資料部門和業務需要更緊密地結合，充分挖掘資料的價值，真正將資料的價值體現出來，去賦能業務，為公司帶來業績的增長。目前實時化是一個大的趨勢，資料以及業務的變化，都需要及時體現出來，做到高實時性。