一、阿里在數據穩定性保障中遇到的問題

1、阿里大數據工作開展架構

阿里大數據計算的離線數據處理部分，主要是基于MaxCompute引擎+DataWorks大數據開發治理平臺來完成日常的數據開發管理工作。平臺產品方在響應數據研發、數據管理等團隊的數據治理需求過程中，通過沉淀的相關規范和方法論，逐步積累落地到平臺產品模塊中，形成了完整的大數據開發治理鏈路。

阿里內部通過這樣一套統一的大數據計算技術體系，來支撐不同的業務的發展和創新。從最早的淘寶、天貓電商業務，到后續的優酷、高德、菜鳥等板塊，業務的蓬勃發展，帶來了單日EB級的數據處理量，DataWorks上單日千萬級別的數據處理調度實例數，以及高達50多種的復雜業務依賴關系。

高并發的數據任務背后，是上萬名平臺數據工作者，進行日常的數據加工與運維管理分析，以滿足業務對于各種場景下的數據要求以及各類數據治理需求。

2、數據穩定性問題的常見表現

通常業務方對于數據的基本要求為每天能夠準時看到正確的數據，越重視數據即時交互與用戶體驗的應用場景，對于數據穩定性的要求也越高。因此數據團隊除了進行本身的數據研發以外，最關鍵的問題是保障數據的穩定產出。

面對如此大規模的數據處理任務、如此復雜的處理鏈路與層次結構，數據團隊在穩定性保障方面也面臨不小的壓力，數據運維機制應運而生。最直接的方式是用人力來保障數據產出。針對數據問題，平臺提供了各類告警方式，比如通過短信、電話、郵件、釘釘等快速地發送告警信息。

但在人力保障過程中，一方面，大量的離線處理在夜間執行，出現問題后值班人員需要整夜盯盤和響應異常；另一方面，問題處理可能需依賴上下游協調，跨團隊、跨業務的協作排查效率較低；有的還需等待集群計算資源，這導致值班工作變成辛苦、低效且耗時很長的過程。

同時，這種運維值班加單任務負責人問題響應機制并沒有在本質上解決數據穩定性問題，數據產出失敗、產出延遲、數據異常等問題依然屢屢發生。這些問題通常由多種因素引起，有可能是代碼本身或配置錯誤，有可能是平臺資源的問題，也有可能是上游源頭側的級聯問題，甚至是人員誤操作、系統誤識別及誤報等問題。

以上圖中的真實案例為例，問題的解決也常常面臨著責任機制、優先級分配、上下游協作機制等現實資源瓶頸問題，導致處理效果不佳。所引起的客戶投訴和資損故障，在不斷地提醒數倉團隊重視數據穩定性問題。

二、阿里數據穩定性治理方案

1、數據穩定性治理原則

實際上，數據穩定性保障的問題根源在于人力資源及計算資源是有限的，大量的數據交互與人員交互又是不可避免的。為了解決復雜數據鏈路系統里的這些問題，數據團隊在不斷地升級優化數據穩定性治理方案。基于數據是服務于業務的前提，結合業務方對于客戶的承諾，以及業務的優先級來評估需要投入的運維力量，設置對應的數據產出約定。

數據穩定性治理的原則，即為，通過合理的人力協作及治理工作，高效保障業務所需的重點數據，能及時、準確產出，滿足數據對業務的約定。實現重要數據重點保障，嚴重問題優先處理，故障機制掛鉤責任機制。

2、如何定義重點數據

首先要定義出重點數據。通過對業務部門的應用進行盤點，劃分應用等級，數據資產的話也會根據其支撐的業務應用去評定資產等級，高等級資產一般會配備高等級的穩定性保障。有了這樣的級別標簽之后，則可以建立配套的故障等級機制。一般來說，數據異常時長越久、資產等級越高，對應的故障級別越高。故障會有對應的責任團隊去認領、復盤，以及保障運維資源。

3、如何保障重點數據的及時性與準確性

那么如何去保障數據重點數據的及時性和準確性呢？以單點運維保障機制來講，建設初期的時候，數據節點少，數據鏈路少，可以通過責任人做監控運維的方式，對每個節點進行監控。但是在數據鏈路復雜了之后，不同的角色都要對自己負責的單點任務或者單點表去進行梳理和運維，導致在配置單點監控告警時，配置邏輯繁雜，且基于人肉識別的方式難以準確地完成監控運維保障。傳統的單任務監控機制只適用于小規模團隊的監控配置。

真正面向于應用去做對應的監控配置時，穩定性治理方案的最大轉變，其實就是把單任務監控轉為全鏈路的基線監控。按照業務優先級，結合全鏈路數據血緣梳理出與最終產出節點相關聯的數據任務節點。如上圖示例，圖中的K節點和L節點為分別給到不同業務方的產出節點，通過血緣可以梳理出數據工作流。對應的監控，只需要在 DataWorks里面配置我們稱之為基線監控的兩條鏈路就可以?；€針對核心應用對應的任務組，包括產出的上下游所有節點。通過基線能提高對業務或產品整體運行情況的認知，并前瞻性的予以優化以保障其穩定。

基線鏈路信息中包含了產出時間要求、告警余量、報警方式、接收人等。系統就會根據基線鏈路設定的基線優先級，識別穩定性保障重要程度，分配計算資源與調度資源。

基線可保障核心任務資源穩定。按照優先級為核心數據產出進行重要性分級，高優先級任務會獲得更多的調度與計算資源。平臺每隔30秒會識別目前的資源情況，進行資源向重點任務傾斜與自動調整，減輕相關責任人的告警處理工作量。那如果在系統自動調整的情況下，基線任務還是沒有辦法按時產出，則會通知到當日的值班人員，提前干預延遲任務來保障最終的基線不會破線引起故障。

在穩定性治理方案中，除了對數據及時性的保障，還需要對數據準確性進行治理?；谝酝涷灒瑪祿蚀_性的問題，大概40%來自于數據源頭方的變動和一些數據質量問題，因此數據鏈路源頭側的業務數據也應引入到整體的保障機制里。通過DataWorks數據質量規則保障重點數據的準確性，在數據引入層設置好對應的監控數據穩定性相關的質量規則，如果出現了問題，則通過數據質量的強規則機制提前去阻斷任務，讓基線監控告警提前暴露出風險。

4、如何實現合理的團隊協同

基于數據穩定性治理研發協作流程，穩定性治理團隊基于基線協調各環節保障。在研發過程中，數據研發和數據測試需要對數據的穩定性進行事前保障，研發類角色與運維類角色進行事中監控，事后再與質量團隊協同進行問題的復盤，共同建立各角色、各流程中有共識的數據穩定性保障規則。

同時需完善角色設置與責任認定機制。設置基線評審委員會和基線評審小組來確定基線的合理性，評審基線的等級是否合理；設置基線負責人角色，作為基線的第一責任人，進行基線的整體管理，關注基線的風險，推動任務責任人與質量負責人以及平臺的資源運維方去評估風險，解決問題；設置任務負責人角色，了解運維保障的機制和規范，保障任務問題能夠及時響應和處理；基線保障的業務方負責人，需為業務訴求的合理性做背書，輔助基線負責人推動基線優化落地；計算平臺側負責人，則需要關注資源情況是否符合基線的穩定性要求，執行應急運維的操作，如資源的擴容、優先級調整等。

三、阿里數據穩定性治理實踐

基于DataWorks的常見分析和處理手段，最直接的產品工具界面其實就是基線下鏈路運行的甘特圖。甘特圖展現了節點任務的先后順序，每個單點任務的實際運行時間和預估運行時間、預警時間與破線時間。基于基線運維的告警一般分為兩類，一是執行之前的提前預警，二是執行之后的即時告警。通過甘特圖可對影響產出的超長任務、調度依賴配置錯誤、單點運行失敗、全鏈路運行緩慢等問題進行識別與預警。下面是幾個實例。

上圖是一個超長任務的例子，在基線實例已經生成，但還未運行前，就對破線風險進行了預警。

上圖是一個調度依賴配置錯誤的例子。

上圖是實際運行中的排查，一個單點運行失敗的例子。如果在歷史產出時間節點前還沒有處理好，就會有一些應急手段來保證數據產出。

上圖反應的是全鏈路的運行變慢，但沒有特別突出的問題，通常是集群資源不足導致的，需要及時進行資源優化和擴容操作。

基線應用團隊總結歸納了實際運維中的常用應急操作，比如停止任務、重跑、續跑、解除依賴、置成功等操作。

針對上游業務、數倉流程和平臺引擎在日常的基線告警治理過程中出現的問題，進行了梳理和分類，找到問題根因和對應的優化方式，形成了《故障處理手冊》。

評估穩定性治理的效果，兩個核心指標就是基線的破線率和運維人員的起夜率。若破線率和起夜率在逐步下降，或者穩定在很低值的時候，則可以說明數據穩定性是做得較好的。

以內部某數倉團隊為例，經過穩定性治理后，破線率和起夜率都大幅下降。整體數據運維和研發的效率都有了大幅提升，這就是穩定性治理的意義所在。

四、事前穩定性治理探索

穩定性問題更重要的是能在事前就進行預防和消除。治理工作在數據研發的全鏈路中，將實踐中沉淀下來的主動化治理手段融入到各個環節中去，構建主動規范建模、主動規范校驗、自動質量監控等治理策略。

事前的主動規范數據建模，需要在數據建模系統中，先設定數據標準，形成模型評審機制，明確數據指標對應的標準規范、口徑與質量要求。

有了明確的標準要求后，可基于DataWorks數據治理中心內置檢查項，對于治理問題的新增引入進行自動預防攔截，提升事前問題攔截率。

數據穩定性治理的目標為打造主動式，可量化、可持續的全鏈路數據治理。將DataWorks的數據治理融入開發流程，拋棄“先開發后治理”的模式，保障DataWorks的數據治理成效可量化、可持續運營，避免“應對式治理”。

我們也已將穩定性治理的經驗提供給了阿里云上的用戶來使用，歡迎大家來參與DataWorks相關的試用活動，希望能幫助更多企業找到更好的可落地的數據治理方案。