以下文章來源于美團技術團隊?，作者祿平 周成 黃浪

在現有大數據平臺的基礎上，借鑒業界成熟OneData方法論，構建合理的數據體系架構、數據規范、模型標準和開發模式，以保障數據快速支撐不斷變化的業務并驅動業務的發展，最終形成我們自己的OneData理論體系與實踐體系。

背景

隨著業務的發展，頻繁迭代和跨部門的垂直業務單元變得越來越多。但由于缺乏前期規劃，導致后期數倉出現了嚴重的數據質量問題，這給數據治理工作帶來了很大的挑戰。在數據倉庫建設過程中，我們總結的問題包括如下幾點：

• 缺乏統一的業務和技術標準，如：開發規范、指標口徑和交付標準不統一。

• 缺乏有效統一的數據質量監控，如：列值信息不完整和不準確，SLA時效無法保障等。

• 業務知識體系散亂不集中，導致不同研發人員對業務理解存在較大的偏差，造成產品的開發成本顯著增加。

• 數據架構不合理，主要體現在數據層之間的分工不明顯，缺乏一致的基礎數據層，缺失統一維度和指標管理。

目標

在現有大數據平臺的基礎上，借鑒業界成熟OneData方法論，構建合理的數據體系架構、數據規范、模型標準和開發模式，以保障數據快速支撐不斷變化的業務并驅動業務的發展，最終形成我們自己的OneData理論體系與實踐體系。

OneData探索

OneData：行業經驗

在數據建設方面，阿里巴巴提出了一種OneData標準，如圖-1所示：

圖1 OneData標準

OneData：我們的思考

他山之石，可以攻玉。我們結合實際情況和業界經驗，進行了如下思考：

1. 對阿里巴巴OneData的思考

• 整個OneData體系覆蓋范圍廣，包含數據規范定義體系、數據模型規范設計、ETL規范研發以及支撐整個體系從方法到實施的工具體系。

• 實施周期較長，人力投入成本較高。

• 推廣落地的工作比較依賴工具。

2. 對現有實際的思考

• 現階段工具保障方面偏弱，人力比較缺乏。

• 現有開發流程不能全部推翻。

經過綜合考量，我們發現直接全盤復用他人經驗是不合理的。那我們如何定義自己的OneData，即能在達到目標的前提下，又能避免上述的難題呢？

OneData：我們的想法

首先，結合行業經驗，自身階段的實踐及以往的數倉經驗，我們預先定義了OneData核心思想與OneData核心特點。

OneData核心思想：從設計、開發、部署和使用層面，避免重復建設和指標冗余建設，從而保障數據口徑的規范和統一，最終實現數據資產全鏈路關聯、提供標準數據輸出以及建立統一的數據公共層。

OneData核心特點：三特性和三效果。

• 三特性：統一性、唯一性、規范性。

• 三效果：高擴展性、強復用性、低成本性。

圖2 OneData的六個特性

OneData：我們的策略

OneData即有核心思想又有核心特點，到底怎么來實現核心思想又能滿足其核心特點呢？通過以往經驗的沉淀，我們提出兩個統一方法策略：統一歸口、統一出口。

根據兩個統一的方法策略，我們開啟了OneData的實踐之路。

OneData實踐

統一業務歸口

數據來源于業務并支撐著業務的發展。因此，數倉建設的基石就是對于業務的把控，數倉建設者即是技術專家，也應該是“大半個”業務專家。基于互聯網行業的特點，我們基本上采用需求推動數據的建設，這也帶來了一些問題，包括：數據對業務存在一定的滯后性；業務知識沉淀在各個需求里，導致業務知識體系分散。針對這些問題，我們提出統一業務歸口，構建全局知識庫，進而保障對業務認知的一致性。

?

圖3 支持業務的數據源知識庫

設計統一歸口

為了解決數據倉庫建設過程中出現的各種痛點，我們從模型與規范兩個方面進行建設，并提出設計統一歸口。

1. 模型

規范化模型分層、數據流向和主題劃分，從而降低研發成本，增強指標復用性，并提高業務的支撐能力。

(1) 模型分層

優秀可靠的數倉體系，往往需要清晰的數據分層結構，即要保證數據層的穩定又要屏蔽對下游的影響，并且要避免鏈路過長。結合這些原則及以往的工作經驗，我們將分層進行統一定義為四層：

圖4 數據分層架構

(2) 模型數據流向

重構前，存在大量的煙囪式開發、分層應引用不規范性及數據鏈路混亂、血緣關系很難追溯和SLA時效難保障等問題。

圖5 重構前和重構后的數據流向圖

重構之后，穩定業務按照標準的數據流向進行開發，即ODS-->DWD-->DWA-->APP。非穩定業務或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP兩個模型數據流。在保障了數據鏈路的合理性之后，又在此基礎上確認了模型分層引用原則：

• 正常流向：ODS>DWD->DWT->DWA->APP，當出現ODS >DWD->DWA->APP這種關系時，說明主題域未覆蓋全。應將DWD數據落到DWT中，對于使用頻度非常低的表允許DWD->DWA。

• 盡量避免出現DWA寬表中使用DWD又使用（該DWD所歸屬主題域）DWT的表。

• 同一主題域內對于DWT生成DWT的表，原則上要盡量避免，否則會影響ETL的效率。

• DWT、DWA和APP中禁止直接使用ODS的表， ODS的表只能被DWD引用。

• 禁止出現反向依賴，例如DWT的表依賴DWA的表。

2. 主題劃分

傳統行業如銀行、制造業、電信、零售等行業中，都有比較成熟的主題劃分，如BDWM、FS-LDM、MLDM等等。但從實際調研情況來看，主題劃分太抽象會造成對業務理解和開發成本較高，不適用互聯網行業。因此，結合各層的特性，我們提出了兩類主題的劃分：面向業務、面向分析。

• 面向業務：按照業務進行聚焦，降低對業務理解的難度，并能解耦復雜的業務。我們將實體關系模型進行變種處理為實體與業務過程模型。實體定義為業務過程的參與體；業務過程定義是由多個實體作用的結果，實體與業務過程都帶有自己特有的屬性。根據業務的聚合性，我們把業務進行拆分，形成了七大核心主題。

• 面向分析：按照分析聚焦，提升數據易用性，提高數據的共享與一致性。按照分析主體對象不同及分析特征，形成分析域主題在DWA進行應用，例如銷售分析域、組織分析域。

3. 規范

模型是整個數倉建設基石，規范是數倉建設的保障。為了避免出現指標重復建設和數據質量差的情況，我們統一按照最詳細、可落地的方法進行規范建設。

(1) 詞根

詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根，提高詞根的易用性和關聯性。

• 普通詞根：描述事物的最小單元體，如：交易-trade。

• 專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。

(2) 表命名規范

通用規范

• 表名、字段名采用一個下劃線分隔詞根（示例：clienttype->client_type）。

• 每部分使用小寫英文單詞，屬于通用字段的必須滿足通用字段信息的定義。

• 表名、字段名需以字母為開頭。

• 表名、字段名最長不超過64個英文字符。

• 優先使用詞根中已有關鍵字（數倉標準配置中的詞根管理），定期Review新增命名的不合理性。

• 在表名自定義部分禁止采用非標準的縮寫。

表命名規則

表名稱 = 類型 + 業務主題 + 子主題 + 表含義 + 存儲格式 + 更新頻率 +結尾，如下圖所示：

圖6 統一的表命名規范

(3) 指標命名規范

結合指標的特性以及詞根管理規范，將指標進行結構化處理。

A. 基礎指標詞根，即所有指標必須包含以下基礎詞根：

B. 業務修飾詞，用于描述業務場景的詞匯，例如trade-交易。

C.日期修飾詞，用于修飾業務發生的時間區間。

D.聚合修飾詞，對結果進行聚集操作。

E.基礎指標，單一的業務修飾詞+基礎指標詞根構建基礎指標 ，例如：交易金額-trade_amt。

F.派生指標，多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性，例如：安裝門店數量-install_poi_cnt。

G.普通指標命名規范，與字段命名規范一致，由詞匯轉換即可以。

圖7 普通指標規范

H.日期類型指標命名規范，命名時要遵循：業務修飾詞+基礎指標詞根+日期修飾詞/聚合修飾詞。將日期后綴加到名稱后面，如下圖所示：

圖8 日期類型指標規范

I.聚合類型指標，命名時要遵循：業務修飾詞+基礎指標詞根+聚合類型+日期修飾詞。將累積標記加到名稱后面，如下圖所示：

圖9 聚合類指標規范

(4) 清洗規范

確認了字段命名和指標命名之后，根據指標與字段的部分特性，我們整理出了整個數倉可預知的24條清洗規范：

結合模型與規范，形成模型設計及模型評審兩者的工作職責，如下圖所示：

圖10 模型設計和審計職責

統一應用歸口

在對原有的應用支持流程進行梳理的時候，我們發現整個研發過程是煙囪式。如果不進行改善就會導致前面的建設“毀于一旦”，所以需對原有應用支持流程進行改造，如下圖所示：

圖11 應用歸口

從圖中可以看出，重構前一個應用存在多次迭代，每次迭代都各自維護自己的文檔。煙囪式開發會導致業務信息混亂、應用無法與文檔對齊、知識傳遞成本、維護成本和迭代成本大大增加等問題。重構后，應用與知識庫相對應，保證一個應用只對應一份文檔，且應用統一要求在一份文檔上進行迭代，從根源上改變應用支持流程。同時，針對核心業務細節和所支撐的數據信息，進行了全局調研并歸納到知識庫。綜合統一的知識庫，降低了知識傳遞、理解、維護和迭代成本。

統一歸口策略包含業務歸口統一、設計歸口統一和應用歸口統一，從底層保證了數倉建設的三特性和三效果。

統一數據出口

數倉建設不僅僅是為了數據內容而建設，同時也為了提高交付的數據質量與數據使用的便利性。如何保證數據質量以及推廣數據的使用，我們提出了統一數據出口策略。在進行數據資產管理和統一數據出口之前，必須高質量地保障輸出的數據質量，從而樹立OneData數據服務體系的權威性。

1. 交付標準化

如何保證數據質量，滿足什么樣的數據才是可交付的，是數據建設者一直探索的問題。為了保證交付的嚴謹性，在具體化測試方案之前，我們結合數倉的特點明確了數據交付標準的五個特性，如下圖所示：

圖12 交付標準化

《交付標準化》完善了整個交付細節，從根本上保證了數據的質量，如：業務測試保障數據的合理性、一致性；技術測試保障數據的唯一性、準確性；數據平臺的穩定性和后期人工維護保障數據的及時性。

2. 數據資產管理

針對如何解決數據質量中維度與指標一致性以及如何提高數據易用性的問題，我們提出數據資產的概念，借助公司內部平臺工具“起源數據平臺”實現了整個數據資產管理，它的功能如下圖所示：

圖13 起源功能體系

借用起源數據平臺，我們實現了：

• 統一指標管理，保證了指標定義、計算口徑、數據來源的一致性。

• 統一維度管理，保證了維度定義、維度值的一致性。

• 統一數據出口，實現了維度和指標元數據信息的唯一出口，維值和指標數據的唯一出口。

通過交付標準化和數據資產管理，保證了數據質量與數據的易用性，同時我們也構建出OneData數據體系中數據指標管理的核心。

實踐的成果

流程改善

我們對開發過程進行梳理，服務于整個OneData體系。對需求分析、指標管理、模型設計、數據驗證進行了改善，并結合OneData模型策略，改善了數倉管理流程。

圖14 數倉管理流程

數倉全景圖

基于OneData主題建設，我們采用面向業務、面向分析的建設策略，形成數倉全景圖，如下圖所示：

圖15 數倉全景圖

資產管理列表

基于起源數據平臺形成的資產管理體系，如下圖所示：

圖16 數據資產管理

項目收益

基于OneData建設成果，我們結合實際項目建設樣例，對比以前未進行OneData建設時的收益。如下圖所示：

圖17 價值收益

總結和展望

我們結合了OneData核心思想與特點，構建一種穩定、可靠的基礎數據倉庫，從底層保障了數據質量，同時完成OneData實踐，形成自有的OneData理論體系。

未來，我們還將在技術上引入實時數據倉庫，滿足靈活多樣、低延時的數據需求；在業務層面會橫向拓展其他業務領域，不間斷地支撐核心業務的決策與分析。下一步，我們將為企業級One Entity數據中臺（以Data As a Service為理念），提供強有力的數據支撐。在后續數倉維護過程中，不斷地發現問題、解決問題和總結問題，保障數據穩定性、一致性和有效性，為核心業務構建價值鏈，最終形成企業級的數據資產。

總結

以上是生活随笔為你收集整理的OneData建设探索之路：SaaS收银运营数仓建设的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。