網易數帆資料生產力方法論

導讀：2021年，網易數帆大資料團隊正式提出資料生產力的理念，資料生產力從廣義上講，是指“透過使用資料，帶來組織生產力的提升”;從狹義上講，是指“資料採集、清洗、加工、視覺化等資料處理和資料治理的軟體生產能力以及持續運營能力”。

資料生產力的願景是構建“人人用資料，時時用資料”的企業資料文化，願景代表的是目標和方向，支撐這個目標的達成，必然需要一系列的方法論。方法論，是以解決問題為目標，透過對具體方法的分析和總結，提出的一般性原則。方法論可以指引技術的發展方向。很多從事資料分析的人，容易沉溺於技術實現，而忽視技術背後的方法論。在資料分析的歷史上，其實誕生過很多優秀的方法論，這些方法論指導了資料分析技術的不斷演進和迭代。

1、歷史上出現過的方法論

1970年，IBM的研究員，有“關聯式資料庫之父”之稱的埃德加·弗蘭克·科德(Edgar Frank Codd或E. F. Codd)博士在刊物《Communication of the ACM》上發表了題為“A Relational Model of Data for Large Shared Data banks(大型共享資料庫的關係模型)”的論文，文中首次提出了資料庫的關係模型的概念，奠定了關係模型的理論基礎。

1973年，Don Chamberlin博士在研發System R專案時，使用結構化英語查詢語言作為關聯式資料庫的操作語言，SQL由此誕生。關聯式資料庫和SQL語言提供了基礎的資訊表達和統計能力，在此指引下，Oracle 無疑是關聯式資料庫時代最成功的商業化產品。

在1991年出版的“Building the Data Warehouse”，資料倉儲之父比爾·恩門首次提出資料倉儲的概念，資料倉儲是一個面向主題的，整合的，相對穩定的，反映歷史變化的資料集合，用於支援管理決策。維度建模是資料倉儲建設中的一種資料建模方法，由Ralph Kimball提出，是一種將資料結構化的邏輯設計方法，它將客觀世界劃分為度量和維度。維度建模是一種自下而上的建模方法，它是從需求出發構建模型，所以能夠較好的應對快速變化的業務場景。

1993年關聯式資料庫之父埃德加·弗蘭克·科德提出聯機分析處理的概念，即OLAP，它是使分析人員、管理人員或執行人員能夠從多種角度對從原始資料中轉化出來的、能夠真正為使用者所理解的、並真實反映企業維特性的資訊進行快速、一致、互動的存取，從而獲得對資料更深入瞭解的一類軟體技術。資料倉儲和OLAP提供了構建部⻔級及企業級多維分析系統的方法，Apache Kylin™就是一個開源的、分散式的分析型資料倉儲，提供SQL 查詢介面和多維分析(OLAP)能力以支援超大規模資料的多維分析。

資料探勘是基於人工智慧、機器學習、模式識別、統計學、資料庫、視覺化技術等，高度自動化地分析企業的資料，做出歸納性的推理，從中挖掘出潛在的模式，幫助決策者調整市場策略，減少風險，做出正確的決策，常用的資料探勘方法包括聚類、迴歸分析、偏差分析等，資料探勘提出了超越基礎統計的知識發現方法;

資料視覺化主要是藉助於圖形化手段，清晰有效地傳達與溝通訊息。資料視覺化技術的基本思想，是將資料庫中每一個資料項作為單個圖元元素表示，大量的資料集構成資料影像，同時將資料的各個屬性值以多維資料的形式表示，可以從不同的維度觀察資料，從而對資料進行更深入的觀察和分析。資料視覺化提供了有效利用人類直覺的資訊呈現和知識發現方法。資料視覺化技術廣泛應用於以tableau為代表的BI分析工具中。

1996年全球頂級資料分析研究機構Gartner提出“商業智慧”概念，它是將企業中現有的資料轉化為知識，幫助企業做出明智的業務經營決策的工具，它包含了資料倉儲、聯絡分析處理(OLAP)和資料探勘，是融合式創新的典範。商業智慧提出了綜合性的分析理論，定義了“描述-預測-解釋-規範”等分析層次。在商業智慧方法論的指導下，tableau、powerbi等被廣泛的應用於企業的決策分析。

從2003年開始，作為全球最大的搜尋引擎Google先後發表了Google File System，MapReduce，BigTable三篇論文，在其引領下大資料開始在網際網路行業廣泛應用。大資料提供了全體而非抽樣、相關而非因果等思想，促成了從ETL到ELT的轉變。在大資料的方法論的指引下，Hadoop成為最流行的大資料計算、儲存基礎設施。

資料治理(Data Governance)是組織中涉及資料使用的一整套管理行為，國際資料管理協會(DAMA)給出的定義：資料治理是對資料資產管理行使權力和控制的活動集合。資料治理主要從管理學角度提出了質量、標準、主資料、後設資料、安全等眾多領域的管理方法。Informatica是目前相對成熟的資料治理的產品。

2016年阿里首次提出資料中臺的方法論，資料中臺方法論包括OneModel，OneEntity，OneService，強調構建企業統一的資料公共層，由一個統一的資料中臺組織負責實施。資料中臺提出了組織角度的實踐方案。

透過回顧歷史中出現過的資料分析領域的方法論，我們發現任何方法論都不是一個孤立的個體，這些方法論之間都有著相互聯絡，例如商業智慧中包含資料探勘的方法，資料中臺中包含了資料治理的方法。所以我們提出的資料生產力的方法論，它同樣不是一個全新的概念，它是在前面的方法論基礎上，融合了新的思想，進行的融合式創新。那接下來，我們就來看看，網易數帆提出的資料生產力的方法論，到底包含什麼內容。

2、網易數帆資料生產力方法論

網易數帆資料生產力的方法論，我們將其稱為3個Data：DataOps、DataFusion和DataProduct。

2.1 DataOps

在軟體工程領域有一個非常經典且被網際網路公司廣泛推崇的方法論，叫CI/CD：可持續整合(Continus Integration)、可持續交付(Continus Delivery)和可持續部署(Continus Deployment)。

·可持續整合：是指開發人員將程式碼變更儘可能早的、高頻的合入主幹分支，且進行有效的測試，提高程式碼的釋出頻率。

·可持續交付：是指開發人員對於專案的變更程式碼， 可以透過自動化迴歸測試，構建出一個可被運維人員在生產環境部署的可執行包或者容器映象。

·可持續部署：是指透過高效的自動化部署工具將程式碼釋出到使用者使用的生產環境。

那為什麼會有這樣一個方法論的誕生呢?

原來傳統軟體開發採用的是瀑布式軟體開發模式，專案經理會將軟體開發過程嚴格劃分為若干個階段，例如需求，設計，編碼，整合，測試和部署，每個階段都有序進行且依賴上個已完成的階段。因為專案管理簡單，流程清晰，該模式一度成為傳統軟體的標準開發模式。

但是隨著網際網路時代的到來，業務高速發展，讓我們在專案開發過程中隨時可能面臨需求變更的問題，所以我們需要採取更加敏捷的方式應對變化中的需求，將一個大的目標拆成若干個可交付的小目標，透過不斷的持續迭代，以”小步快跑”的方式實現持續交付，能夠讓業務不斷看到新的進展的同時，階段性驗證成果，避免最後交付的軟體與最初的業務需求大相徑庭。

再者，因為瀑布式開發，所有的測試都集中在程式碼整合之後，導致發現問題時間過晚，軟體要持續的返工，最終影響交付時間。一個比較理想的狀態是在軟體開發過程中就能夠開始進行測試，開發和測試交替進行，程式碼一旦發生變更，透過自動化的方式構建可執行的程式碼包，自動化迴歸測試確保程式碼包的功能正確性和穩定性。

最後，原先程式碼部署上線，都是全靠IT運維人工操作，不僅效率低下，同時還因為各種人工操作疏漏，導致線上事故頻發。隨著業務服務架構升級，系統逐步從單體服務過渡到分散式微服務狀態，原先運維管理的幾個服務，變成了幾百個，甚至上千個服務，每天都有大量的服務需要釋出更新上線，完全靠人工的方式已經成為軟體研發的瓶頸。透過自動化的釋出工具將程式碼包釋出到生產環境，成為必然的發展趨勢。

在這樣的背景下，可持續整合、可持續交付和可持續部署成為軟體開發的必然選擇，三者共同構築了一個軟體開發的流水線，以更高效的開發、更頻繁的釋出、更穩定的質量為目標，實現了開發、測試、運維一體化，也就是後來被頻繁提起的DevOps。

那CI/CD 跟我們今天要講的DataOps又有什麼關係呢?如果我們把資料看作是一種軟體，用軟體開發的視角來審視資料開發的過程，我們會驚奇的發現，在這兩個完全不同的技術領域，竟然面臨著相似的問題。

首先，資料分析支撐的是企業日常運營活動，由於運營更加趨向於高頻且常態化，我們在淘寶上每天都能看到各個商家在搞各種促銷活動，企業對資料分析的結果時效性要求越來越高，一個活動從上線到下線可能只需要幾天時間，在活動過程中，可能還面臨的活動策略需要不斷調整，資料分析的需求也面臨隨時變化，我們必須使用更加敏捷迭代的方式，才能滿足業務資料分析快速試錯的需求。

其次，資料的正確性校驗比軟體功能校驗更加複雜，每個任務都依賴其上游任務的資料產出的正確性，所以更加需要在每個任務開發完，就能夠及時的對資料進行驗證。但是很可惜，我們發現在資料開發領域，資料測試還大量依賴資料開發的手工測試，這不僅導致測試的質量面臨很大的風險，還導致測試的效率非常低下，也難以做到每個任務開發完就能夠及時的驗證資料。據網易內部業務統計，有超過50%以上的資料線上事故都是由於資料開發的任務變更引起的。所以，資料開發也需要將自動化測試融入開發流程中。

最後，資料領域同樣也面臨著架構的升級，原先煙囪式的資料架構逐步過渡到資料中臺模式下高度複用的公共資料分層架構，一個大的任務被拆分成若干個小的可獨立排程執行的任務，任務之間相互依賴，任務釋出的頻率和複雜度大幅提升，對自動化部署提出更高的要求。

基於這樣相似的一個背景，我們不妨用相同的解藥跨界應用在資料開發的領域，至此便有了DataOps。DataOps 其實並不是網易數帆第一個提出來的方法論，早在2014年，InformationWeek的特約編輯Lenny Liebmann 在“ DataOps對大資料成功至關重要的三個原因”中首次提出了DataOps的概念。DataOps(資料操作)是一門新興學科，將DevOps團隊與資料工程師和資料科學家角色結合在一起，提供一些工具、流程和組織結構服務於以資料為中心的企業。

DataOps 真正被業界開始廣為熟悉，要到2018年，Gartner 正式將DataOps納入到Data Management技術能力成熟度曲線，作為全球頂級權威研究機構，Gartner對DataOps定義如下：

“DataOps is a collaborative data management practice focused on improving the communication, integration and automation of data flows between data managers and data consumers across an change management of data, data models and related artifacts. DataOps uses technology to automate the design, deployment and management of data delivery with appropriate levels of governance, and it uses metadata to improve the usability and value of data in a dynamic environment.”

這個定義中值得我們關注的是，DataOps 的目標是實現更敏捷的資料交付，運用的技術手段是自動化設計，部署和交付，同時Gartner 強調DataOps必須要結合基於後設資料的資料治理。

Wiki 對DataOps 定義如下：

“DataOps is an automated, process-oriented methodology, used by analytic and data teams, to improve the quality and reduce the cycle time of data analytics. ”

Wiki對DataOps的定義目標非常明確，DataOps的核心是減少資料分析的週期，改善資料分析的質量。

下面是來自Techopedia的定義：

The DataOps approach seeks to apply the principles of agile software development and DevOps (combining development and operations) to data analytics, to break down silos and promote efficient, streamlined data handling across many segments.

DataOps是一種敏捷的軟體開發模式，它將DevOps理念應用於資料分析領域，打破了資料孤島，促進了資料處理的效率。

從各種對DataOps的定義來看，大家對DataOps的一個核心共識，就是DataOps追求的是敏捷、高質量的資料需求交付。網易數帆對DataOps的定義是，DataOps是一種將軟體工程CI/CD的方法融入資料開發的流程，基於自動化的資料測試、任務釋出等技術，構建資料釋出流水線，使得資料開發效率更高、交付更加頻繁，交付質量更有保障。

DataOps的核心是要構建一條資料釋出的流水線，接下來我們要討論的是應該如何構建這條流水線。我們不妨再次參考一下軟體開發領域的DevOps，看看DevOps 的流水線包括哪些環節。

軟體開發的流水線以編碼作為起點，緊接著是程式碼構建，單元測試，整合測試，全部透過後程式碼才能被合入主幹分支，此時可持續整合階段完成。然後進行程式碼的釋出，首先需要進行程式碼的稽核，經過稽核後的程式碼被打包成可用於生產環境執行的釋出包，這個階段為可持續交付階段。最後透過自動化部署工具完成釋出包在生產環境的部署，可持續部署完成。

如果我們參照軟體開發的流水線構建一條資料開發的流水線，可以同樣將資料開發劃分為以下幾個階段。

編碼：DataOps 同樣以編碼作為起點，為了支援高效的程式碼開發，必須擁有一個能夠支援豐富的運算元進行資料開發的IDE。IDE需要具備程式碼格式化、語法檢查、高亮顯示、程式碼執行、執行結果展示、日誌跟蹤等功能。同時程式碼還必須具備多版本管理的能力，能夠進行不同版本的差異對比。另外資料開發與軟體開發的差異，在於資料開發存在大量的UDF，所以必須有一個統一的UDF 開發和管理的工具。此外，任務模板也是編碼階段不可缺失的技術能力，因為很多資料清洗任務可以抽象為任務模板，只需要透過引數化的注入表名稱或者欄位名稱，就可以完成任務程式碼的複用，對於提高編碼效率非常重要。

編排：在資料中臺的模式下，任務被切割為很多不同的子任務(Job)，多個Job可以被編排為一個工作流(Flow)，Flow可以被設定週期性排程。最常見的編排是基於時間的排程模式，可以透過任務依賴實現有相互資料依賴關係的任務有序進行。但是基於時間的排程會產生很多的間隙，一個比較理想的狀態是能夠直接根據任務的依賴關係進行排程。另外任務的依賴需要透過資料血緣能夠自動識別，減少建立任務依賴的複雜度。同時，任務執行引數的配置和管理，需要引入引數組的方式，一個引數組是可以被多個job或者flow共享的引數列表，透過修改引數組中的引數，就可以控制多個job或者flow的引數變更。最後在資料開發過程中，還經常需要引用一些Jar，透過資源組的方式，可以將這些jar方便的在不同的job或者flow中引用。

測試：測試是資料開發最容易被遺漏的環節，資料測試的目標是驗證資料的正確性。常見的資料測試主要包括3類。第一類是資料形態探查，它主要是透過對資料的掃描，對主鍵是否唯一、空值\零值比例、列舉值的分佈比例、欄位的均值、最大值、最小值等給出分析報告，透過報告，我們可以清楚的瞭解資料形態，發現可能存在的資料質量的問題。資料形態探查既可能發生在資料開發任務之前，尤其是當我們剛剛從業務系統源資料庫抽取資料到ods層時，我們需要透過探查任務瞭解源系統的資料分佈，為後續制訂資料標準，進行資料建模提供依據。同時，資料探查也可能發生在我們開發任務之後，我們需要對產出資料進行探查，確保符合設計預期。第二類常見的資料測試是資料比對。對已經發布的模型進行區域性的修改，例如增加或者刪除欄位，是資料開發非常常見的現象。我們經常關注新增的欄位是否邏輯正確，但是往往會忽略這種調整可能會影響已經存在的欄位，導致未修改的欄位的產出資料被修改，最終影響了下游依賴的任務。所以我們必須要透過資料比對，去分析對比一個模型修改前和修改後，資料變化是否符合預期，對於未修改的欄位，要確保修改前和修改後資料是完全一致的。資料比對，透過全量或者抽樣掃描，針對每個對比欄位，給出一致性比例。最後一類資料測試就是自動化迴歸測試。由於在資料中臺中，為了避免煙囪式的資料開發，我們設計了高複用的公共資料層，任務之間依賴大幅度增加，我們不僅要確保我們當前開發的任務正確性，還要同時確保下游任務的邏輯正確性。所以我們需要透過在測試環境，執行當前任務，自動調起下游的任務，透過每個任務上配置的稽核規則，校驗資料的產出邏輯是否符合預期。資料測試，除了測試技術本身之外，另外一個難題在於測試資料的準備，一般在企業級資料平臺架構中，開發環境和生產環境會獨立部署兩個物理叢集，但是如果每次做資料測試，需要將生產叢集的資料全量匯入到測試叢集，那將會非常影響測試的效率。所以一個比較理想的架構，就是我可以在開發叢集，直接使用生產叢集的脫敏資料進行驗證，而不需要去匯入生產叢集的資料，此時就需要引入資料沙箱的技術，確保在開發叢集，可以直接執行任務，讀取生產環境脫敏資料進行測試，同時又只能寫入開發環境，避免了汙染生產環境的問題，既保證了兩個環境的隔離，又解決了跨環境資料測試的難題。

程式碼審查：任務釋出之前，我們需要對程式碼進行的審查。程式碼審查主要有系統和人工兩種方式。SQL Scan是一種系統靜態程式碼掃描技術，透過自動掃描任務程式碼，我們可以發現很多規範類、語法類的問題。例如我們在程式碼提交上線時使用了固定的分割槽，未替換成排程時間引數，這種情況在測試提交到生產的時候尤為常見，因為我們在測試階段經常使用固定分割槽的方式除錯，到生產環境又要將這些固定分割槽替換成時間引數，由於生產環境的程式碼可能非常複雜，有上百行，所以經常遺漏，透過靜態程式碼掃描可以很容易發現此類問題。人工的程式碼審查就是我們日常經常講的CodeReivew，一般是有由另外一名有經驗的程式碼開發人員對程式碼進行閱讀，在閱讀過程中針對程式碼的編碼規範、邏輯正確、異常處理、抽象封裝等問題進行審查，對於發現的問題，需要在程式碼釋出之前進行修復。一般來說，CodeReview需要包括程式碼完整性檢查、程式碼一致性檢查、程式碼正確性檢查、程式碼可維護性檢查、程式碼可預測性檢查、程式碼健壯性檢查、程式碼結構性檢查、程式碼可理解性檢查、程式碼可驗證性檢查。在實際操作過程中，CodeReview是容易被忽略的環節，主要是因為大部分的CodeReview的過程都是線上下完成的， 如果我們可以將CodeReview作為一個檢查項融入到程式碼的釋出流程中，同時對Review的人在任務出現問題的時候進行追責，就可以確保該項工作可以高質量的完成。

釋出稽核：任務釋出上線需前要經過釋出稽核流程，一方面是提高任務釋出規範性，確保相關的人和各級主管都能夠了解發布過程，有完整的上線釋出記錄，另外一方面也是再次對釋出過程進行稽核，例如排程的配置資訊，報警配置資訊，程式碼是否經過完整的測試，稽核規則是否配置正確等進行稽核。釋出稽核的物件是釋出包，所以首先需要生成釋出包，一個完整的釋出包既要包括任務程式碼以及相關的排程配置、引數配置、報警配置等，同時還應該包括任務相關的模型。在實際操作環節，經常會出現模型釋出了，任務忘記釋出，或者任務釋出，模型遺漏的情況，所以透過釋出包的形式，可以有效杜絕此類問題。釋出包同時需要支援多版本，可以實現不同的版本的一鍵釋出。在資料中臺模式下，任務依賴層次增多，經常會出現修改上游任務，影響下游任務的情況，所以在釋出包正式釋出前，必須要經過基於資料血緣的全鏈路影響檢測，一方面，是明確釋出包的影響範圍，透過影響的下游資料的重要性(一般是依賴資料資產等級)以及資料上的資產標籤，確定釋出稽核的流程，例如如果檢測到下游鏈路中涉及帶資損的表，則需要在釋出稽核流程中增加資料中臺負責人的審批。另外一方面，檢測到受影響的下游表之後，被影響的下游表的負責人或者應用的負責人同樣可以受到上游任務釋出變更的通知。所以全鏈路的影響檢測對於釋出稽核來說非常關鍵。最後，如果所有的釋出包都需要經過非常繁雜的稽核釋出流程，會大幅度影響釋出的效率，所以一個比較理想的方式，是結合受影響的資料的資產等級來構建釋出的稽核流程，根據不同的資產等級，制訂不同的稽核流程。當然，我們還可以在表上增加一些資產標籤，例如資損，財報之類的，可以基於下游影響的表的標籤，制訂審批流程。審批過程本身要支援多級審批。

部署上線：資料釋出流水線的最後一個環節是部署上線。在金融級的資料平臺架構中，除了有開發叢集和生產叢集，還有測試叢集和預釋出叢集。預釋出叢集和生產叢集都屬於線上環境，由運維管理。開發叢集和測試叢集屬於非生產環境，由開發管理。生產環境和非生產環境網路完全隔離。釋出包在非生產環境經過稽核後，匯入預釋出叢集，在預釋出叢集運維可以使用生產叢集的脫敏資料進行線上模擬測試，驗證透過後釋出到生產叢集。透過預釋出叢集的驗證，我們可以在任務部署上線前直接使用真實生產資料進行驗證，釋出質量得到進一步增強。由於資源競爭導致任務之間的相互影響是線上任務產出時間不穩定的一個重要因素，為了確保核心任務能夠更優先的獲取執行資源，所以必須要藉助基於優先順序的執行資源排程策略。同時對於海量任務的日常管理，我們也必須要透過基線的方式進行運維。基線，代表的是中臺承諾的最晚任務產出時間，我們把任務掛載到基線上，然後按照基線的方式，監控任務的完成進度，在大規模任務運維中非常實用。此外，由於日常的任務運維和任務開發往往不是一個人，為了提高異常問題的排查效率，我們必須要能夠有任務智慧診斷的能力，基於錯誤的異常堆疊，可以快速的定位問題，有效提高運維效率。

這六個環節共同構建了一個資料釋出流水線，在保障質量的前提下，實現了資料開發的敏捷交付。在整個流水線中，實際涉及到了多個角色，包括開發、測試、運維等，一個成熟的DataOps工具，必須構建在一個流程引擎之上，而流程引擎可以完成資料流水線上不同角色之間的相互協作。同時參照DevOps，當整個流水線打通的同時，配套需要建設的一定是效能平臺，統計各個階段，各個角色的耗時，實現需求的全流程跟蹤和專案管理。

DataOps是資料中臺架構下對資料研發的必備要求。其一，資料中臺對需求交付效率要求非常高。資料中臺構建了一個企業的公共資料層，同時也限定業務必須基於這個公共層去分析資料。如果這個公共層無法快速滿足業務的需求，那必然會面臨業務的嚴峻挑戰。同時，由於資料中臺的終極目標是讓資料更廣泛的使用起來，必然面臨著需求爆炸式增長。DataOps提供了一種更為敏捷的資料交付模式，可以快速滿足業務需求。其二，資料中臺對質量要求嚴苛。在資料中臺模式下，資料高度共享，任務依賴繁雜，一旦某個任務出錯，可能導致下游成百上千個任務或者應用無法按時產出，所以資料中臺，必須要依賴DataOps提供的資料測試、程式碼審查和釋出稽核過程，確保資料高質量產出。

2.2 DataFusion

DataFusion是資料生產力的第二個方法論，援引Wiki對Fusion的定義，“Fusion, is the process of combining two or more distinct entities into a new whole.” Fusion 意味著兩個不同的個體組合成一個新的整體的過程。之所以取名Fusion，就是因為在原先的資料開發過程中，因為煙囪式的開發模式，導致資料架構上形成了很多資料豎井，為了解決指標口徑的一致性，提效降本，沉澱企業的資料資產，我們需要構建企業的公共資料層，也就是我們經常聽到的資料中臺，透過資料中臺的方式重塑我們的資料架構，這個過程與Fusion所要表達的融合之意相同，所以我們取名為DataFusion。

既然DataFusion是資料中臺建設方法論，那在資料中臺建設上，業界還有哪些成熟的方法論呢?

資料中臺業界最被熟知的方法論，就是阿里的OneData體系，在2019年雲棲大會上，阿里官方對OneData體系給出了明確的定義，OneData體系的核心包OneModel，OneEntity和OneService。

OneModel，統一模型構建與管理。透過全域資料整合、資料分層架構、業務視角標準規範定義資料和處理資料，致力於統一資料口徑、消除指標二義性;OneModel將資料模型作為數倉構建的基礎，以Kimball的維度建模作為基礎建模方法論，在此基礎上，抽象業務過程，劃分主題域，構建匯流排矩陣，設計明細表和一致性維度表，然後定義原子指標，修飾詞，派生詞，最終可以透過自動化的方式生成可用於業務分析的派生指標。OneModel的優勢，一方面從根本上解決了指標口徑二義性的難題，另外一方面，透過設計高度規範、可複用的資料模型，達到了資料開發降本提效的目的。但是也要特別指出的是OneModel 在宣傳中會過分的強調自動化程式碼的構建，實際上程式碼的自動化構建是發生在明細資料表構建完成之後，自動化並不能完全取代資料清洗和原子指標的開發過程。此外，OneModel中雖然也有對錶命名、欄位命名的規範性要求，但是相比資料標準，缺少對每個欄位，甚至是欄位內容的規範化約束。

OneEntity，核心商業要素資產化。以業務和自然物件為基礎，以標籤資料為核心，能夠實現全域實體識別與連線，資料價值深度萃取，助力企業構建標籤體系、完成核心商業要素資產化;這裡的核心商業要素指的是什麼呢?對電商平臺來說，最重要的當然就是人、貨、場。OneEntity有兩個重點，第一個是對於核心商業要素，全域要有唯一的標識，且基於這個標識，可以實現不同業務過程的資料連線，支撐全域資料分析。簡單的來說，就是在供應鏈倉儲管理業務流程中的商品ID和在交易下單業務流程中的商品ID必須是一致的，這其實用資料治理的視角來看，屬於主資料的範疇。第二個重點，是基於這個核心商業要素，構建豐富的標籤體系，且這些標籤可以作為企業的資料資產，可以讓每個業務都能夠使用。

OneService，統一資料服務。即由資料中臺提供統一的資料接入和資料查詢服務。統一出口的目的，是為了實現資料規範化交付，提高資料接入的效率，遮蔽底層的異構資料來源，提供基於邏輯表的主題式查詢服務。

從OneData體系中我們能夠看到很多傳統資料治理的身影，例如在OneModel中有部分資料標準的因素，在OneEntity中又有主資料的因素，當然OneData體系本身對資料治理進行了進一步的創新，例如全域資料標萃取和資料服務化，這些都是網際網路資料智慧場景中經常用到的技術，可以說OneData是網際網路版的資料治理。當然這種經驗對網易數帆的資料生產力建設也非常具有指導意義，DataFusion 繼承自OneData體系，同時又在OneData體系中又融入了具有網易數帆特色的實踐。

網易數帆OneFusion 方法論具體包括以下內容：

(1)構建統一的指標管理體系

指標是資料和業務的交匯點，是資料分析需求的載體。如果指標口徑定義不一致，就會導致看資料的人對資料的理解產生很大的障礙，最終導致資料失去分析價值。確保指標口徑一致，就必須要實現指標的統一管理。指標統一管理需要組織架構、流程規範和工具產品的三者結合。首先，要有能夠統一管理指標的組織，這個組織必須是跨業務部門的，一般就是資料中臺部門。其次，要有統一的指標管理流程規範，包括指標的規範化定義，指標分類管理以及審批流程等。最後，指標的管理必須還要有與規範相配合的工具產品。

(2)設計高複用、規範的資料模型

網易數帆同樣認為資料模型是構建資料中臺的基石，推崇基於維度建模的資料模型設計的方法論。但是網易數帆認為，一個面向資料中臺的模型設計，必須有一套可以量化的衡量標準，能夠評價當前資料模型設計的質量。網易數帆推薦的資料中臺的建設方式是採用迭代式構建，所以必須要對建設過程中模型的設計質量進行持續跟蹤，確保模型的設計符合資料中臺建設的規範和高複用的設計目標。為此，網易數帆提出了業界首個面向資料中臺的模型設計標準，提出透過跨層引用率、模型引用係數等指標評價模型設計質量。

(3)基於ROI的資料資產沉澱

網易數帆認為一個企業中並不是所有的資料都能稱之為資料資產，資料資產需要透過ROI的方式進行精細化管理。我們需要從資料應用的角度，計算整個資料加工鏈路上每個模型、任務消耗的資源，同時還要基於這個模型以及下游應用的使用者使用情況進行價值衡量，最終要沉澱高價值的資料作為資產，消滅高成本低價值的資料。在資料中臺模式下，資料分析需求一定面臨井噴式增長，在有限的資源內，如何實現價值的最大化，必須依賴基於ROI方式的精細化管理。

(4)組合式資料服務

網易數帆認為資料服務一方面作為服務閘道器，提供了鑑權、日誌、限流、熔斷等能力，實現了資料的規範化交付，提高了資料交付的效率。同時，資料服務還必須具備編排的能力，透過API之間的組合，可以建立出滿足不同應用場景的服務。此外，資料服務還能夠提升資料管理的效率，資料服務打通了資料應用和資料模型的血緣，實現了資料血緣從源系統到資料應用的全鏈路覆蓋。一方面出現問題的時候，資料中臺可以快速評估影響範圍，另外一方面，也可以透過資料服務，快速的對髒資料進行止損。

(5)資料標準化

網易數帆認為在資料規範化建模之前，還要增加資料標準化作為前置步驟。在資料標註的制訂過程中，需要明確每個資料元的唯一標識，列舉值範圍，值域約束等。基於資料標準，一方面我們可以進行規範化建模，資料元可以形成資料模型中的欄位。另外一方面，資料標準對應的值域約束，可以形成稽核規則，在模型上線後進行生產環境的稽核監控。

(6)主資料治理

主資料是指參與業務事件的主題或者資源，是具有高業務價值的、跨流程和跨系統重複使用的資料。雖然一般意義上認為，主資料的建設並不在資料體系構建的範圍內，它是面向業務系統的，但是主資料卻深刻影響著資料分析的質量。我們經常會發現不同業務過程中的相同實體標識不一致，最終導致無法跨業務流程聯合分析。一般來說，構建企業全域實體資料標識統一有兩種方式，第一種是透過主資料的方式，保證業務系統產生的資料本身就是統一的。第二種方式是在資料中臺內部透過演算法對映的方式進行轉換連線。但是前者治本，後者治標。

2.3 DataProduct

雖然Tableau倡導的敏捷式自助分析極大的提升了資料分析的效率，但是不可否認的是Tableau的主要使用者還是一些資料分析師。前面我們提出，資料生產力的目標是實現人人用資料，時時用資料，要讓能夠參與企業運營的一線業務人員也能使用資料，網易數帆認為達成這樣一個目標，就必須透過資料產品的方式實現。

資料產品的核心思想是打造一個資料驅動的業務決策執行的閉環。資料產品首先要完成資料組織，資料的組織結構中包含了使用者應該要看哪些資料，看資料的邏輯是什麼。接下來會進入一個迴圈，這個迴圈的起點是監控資料，發現異常指標。然後是針對異常指標進行根因分析，找到問題的原因。再下來就是根據原因，產生計劃建議，這個時候要告訴使用者，應該如何做才能解決問題。最後是使用者採納該建議，完成決策執行。

圍繞這個流程，DataProduct 包含以下內容：

透過“資料門戶”組織資料，聚焦業務場景。我們看到一個企業中，經常會存在多個BI工具，每個BI工具的報表的組織是透過目錄樹的方式進行組織，目錄可能是分析師個人，也可能是組織部門，這樣的一個資料分佈非常零散，對一線業務人員來說，使用資料的成本非常高，他必須要知道我要看哪些資料，知道去哪裡看這些資料，最終可能就導致他沒辦法真正去使用這些資料。解決這個問題的關鍵，是我們要從業務過程的視角去組織資料，而資料門戶是資料組織的載體。

例如，在嚴選，我們針對不同的業務場景，設計了一系列的資料產品，在商品運營場景中，我們有大麥，在使用者行為分析場景中，我們有神相，在供應鏈場景中，我們有河洛，在商品輿情監控場景中，我們有諦聽，在市場渠道管理場景中，我們有刑天。這些資料產品，共同構建了嚴選全場景的資料消費，滿足了不同場景下資料分析的需求。對於一個業務人員來說，他可以根據他從事的業務，去選擇對應的資料產品，瞭解整個業務資料分析的思路。當然資料門戶並不侷限於PC端，我們為了服務於嚴選管理層看數，設計了VipApp，可以隨時隨地的看到管理層希望看到的資料。

透過“智慧預警”，發現業務問題。針對核心指標，可以設計靈活的規則，基於規則設定預警策略，進行實時監測，發現異常的資料，從而監控整個業務過程。例如，我們在商品運營場景中，商品銷量是一個核心指標，我們設計一個規則，就是監控近7日主站在架商品0銷量(不含贈品)的天數，預警策略就是大於等於3天，透過該異常監控，我們能夠發現所有主站慢動銷的商品，而這些產品是屬於需要運營介入處理的商品。

透過“異動分析”，並找到問題原因。針對慢動銷的商品，我們必須找出慢動銷的原因，才能採取有效的措施進行干預。根因分析，首先要對指標進行拆解，指標拆解的方法可以參考經典的杜邦分析法，在前面的例子中，我們可以從轉化分析的角度將商品銷量按照支付使用者數、人均支付件數進行拆解，支付使用者數又可以進一步按照訪問uv和轉化率進行拆解。對於轉化率我們又可以按照商品因素進一步拆解為sku缺貨率和商品累計差評率以及商品詳情頁質量等因素。透過逐層分析，我們最終可以找到慢動銷商品的原因。

透過“決策引擎”，將資料轉化為有效決策。根據根因分析的結果，我們可以採取不同的措施進行干預。資料轉化為決策可以依賴規則，也可以依賴演算法。基於規則的就需要提前預置好決策流，基於決策引擎，發起計劃建議。例如，在前面例子中，我們發現是商品缺貨率最終導致了商品轉化率下降，那就應該發起補貨建議，根據過往的銷量，我們可以設計規則，補多少貨，向誰補貨。

透過“機器學習”，智慧化產生計劃建議。在一些複雜的場景中，我們有必要藉助一些機器學習演算法來提升計劃建議的精準性。例如在前面的案例中，我們也可以藉助演算法，實現銷量預測，根據預測的結果發起最終的補貨建議。

透過“連線中心”，完成決策執行。決策最終是要在業務系統中完成執行落地的，所以我們必須要將資料產品產生的決策建議能夠方便的推送到業務系統中，完成決策的執行落地。例如，在前面的例子中，最終的補貨建議必須推送給採購系統，在採購系統中完成補貨流程，這個連線可以透過API的形式進行整合。

資料產品的設計必須結合業務場景，我們根據不同的業務場景，可以構建出一個企業的全場景資料產品矩陣，最終實現人人用資料，時時用資料的企業資料文化願景。

3、資料生產力方法論與過往方法論的關係

從資料分析發展的歷史軌跡來看，任何一個有生命力的方法論，它都不是憑空出現的，資料生產力的方法論也是如此，它是在過往資料分析理論的基礎之上進行的融合式創新，與歷史上的資料分析的方法論一脈相承，彙集了主流資料分析方法論的核心要素。

在DataOps要構建的資料釋出流水線中 ，需要用到大資料、資料倉儲和關聯式資料庫的相關技術。在DataFusion要建設的企業公共資料層中，包含了資料中臺、資料治理的相關內容。在DataProduct 所要構建的全場景資料產品矩陣中，包括了商業智慧、資料視覺化以及資料探勘的相關理論。資料生產力的三大方法論，是支撐我們實現“人人用資料，時時用資料”這個願景的指導原則。

作者簡介：孫仲謀，網易數帆大資料專家，大資料平臺負責人，曾任網易雲資料庫產品負責人，十多年網際網路資料研發和管理經驗，網易資料中臺建設的親歷者和實踐者。