數(shù)據(jù)運行時如何保證快穩(wěn)準？規(guī)范在前、開發(fā)在后、實時運維、有的治理。
采訪嘉賓｜梅容，明源云天際·PaaS 平臺數(shù)據(jù)云事業(yè)部產(chǎn)品負責人
“數(shù)據(jù)”是新的生產(chǎn)要素已成為共識，而要挖掘數(shù)據(jù)價值，就繞不過數(shù)據(jù)管理。在數(shù)據(jù)管理層面，近幾年業(yè)界有一個相關概念受到廣泛關注——DataOps。
DataOps 的概念自首次被提出至今已有 8 年，并在 2018 年被 Gartner 納入數(shù)據(jù)管理技術成熟度曲線。從實施上看，當下 DataOps 仍處在發(fā)展初期，鮮少企業(yè)或團隊能據(jù)此真正沉淀一套方法論或技術產(chǎn)品的體系。不過，隨著越來越多的企業(yè)開啟 DataOps 實踐，相信令人“霧里看花”的 DataOps 方法體系也會逐漸明朗起來。
明源云是其中一個探索者，過去 25 年，明源云的數(shù)字化服務主要聚焦在住宅開發(fā)領域。隨著房地產(chǎn)行業(yè)從過去的紅利時代急轉進入混沌時代，不少企業(yè)開始紛紛布局存量市場，并注重精細化管理，明源云的下一步業(yè)務戰(zhàn)略正是沿著不動產(chǎn)的產(chǎn)業(yè)數(shù)字化方向擴展。不動產(chǎn)企業(yè)的發(fā)展戰(zhàn)略趨向多元化，對于經(jīng)營決策、運營服務等的需求越來越迫切，同時，明源云意識到，在企業(yè)經(jīng)營管理戰(zhàn)略上，如果數(shù)據(jù)不能保證及時和準確，數(shù)字化價值則會大打折扣。為此，過去幾年在業(yè)務發(fā)展路徑和客戶數(shù)字化訴求的驅動下，明源云持續(xù)結合 DataOps 實踐、探索數(shù)據(jù)治理體系的落地。近期我們與明源云天際·PaaS 平臺數(shù)據(jù)云事業(yè)部產(chǎn)品負責人梅容進行了一次交流，以進一步了解明源云 DataOps 的實踐過程、從中收獲的經(jīng)驗和認知。
什么是 DataOps？
關于 DataOps，一個常見的基本問題是，DataOps 和 DevOps 有什么關系和區(qū)別？
2021 年，Gartner 發(fā)布的“十大數(shù)據(jù)和分析技術趨勢”中有一項是“XOps”，Gartner 研究總監(jiān)孫鑫對此解讀道：
現(xiàn)在的分析和 AI 解決方案沒有跟上日益增長的實踐的多樣性，其原因在于應用當中的 DevOps 的最佳實踐的多個 Ops 學科，大家可以看到的有 DataOps、ModelOps 以及 DevOps，造成了市場的混亂，所以 Gartner 把它叫做 XOps。
無論是什么 Ops，它的目標都是利用 DevOps 的最佳實踐去實現(xiàn)效率和規(guī)模經(jīng)濟，并確?？煽啃浴⒖芍赜眯院涂芍貜托?，同時減少技術和流程的重復，從而實現(xiàn)自動化。
同樣地，明源云的 DataOps 實踐也是基于 Devops 衍生而來?！皩?DevOps 中使用的 CI/CD 理念應用于 DataOps，實現(xiàn)數(shù)據(jù)橫縱鏈路上的自動化和自主管理?！泵啡荼硎?，DataOps 是數(shù)據(jù)管理的工具化和自動化的方法體系，將數(shù)據(jù)的需求設計、研發(fā)實現(xiàn)、發(fā)布運行、交付運維等關鍵流程自動化，從而提高對業(yè)務場景的價值，其同樣需要將標準、流程、機制、組織和技術融合落地。
今天，企業(yè)在構建數(shù)據(jù)資產(chǎn)的過程中離不開數(shù)據(jù)治理，但在梅容團隊看來，數(shù)據(jù)治理是方法論，它能指導大家怎么去把數(shù)據(jù)治理得準確和穩(wěn)定，但它沒有辦法負責數(shù)據(jù)運行時的及時、穩(wěn)定和準確。因此其引入的 DataOps 會更偏向“運行態(tài)”，并在數(shù)據(jù)應用的整個流程體系進行探索和實踐。
DataOps 的探索與實踐
2017 年，某個頭部地產(chǎn)客戶的數(shù)據(jù)治理和 BI 項目讓明源云意識到一個迫切待解的問題：如何保證持續(xù)穩(wěn)定的數(shù)據(jù)質量？
當時，團隊在快速兌現(xiàn)了該客戶預期的數(shù)據(jù)指標體系和管理看板后，在交付過程中卻經(jīng)常收到來自用戶的反饋——數(shù)據(jù)錯誤影響業(yè)務使用。
團隊在排查問題后發(fā)現(xiàn)是數(shù)據(jù)在定期清洗過程中，經(jīng)常出現(xiàn)數(shù)據(jù)質量問題，其中既有來自業(yè)務的影響，如：數(shù)據(jù)來源的業(yè)務系統(tǒng)不規(guī)范的更新表結構；數(shù)據(jù)口徑不一致，同一個指標數(shù)據(jù)在不同的業(yè)務系統(tǒng)有不同的表述；數(shù)據(jù)填報不規(guī)范等。
也有技術問題帶來的影響，如 ETL 過程中某字段變更導致數(shù)據(jù)加工出錯，數(shù)據(jù)處理引擎突發(fā)數(shù)據(jù)變更峰值造成鏈路阻塞，系統(tǒng)服務出現(xiàn)異常導致調度任務執(zhí)行失敗等。
當時的 BI 產(chǎn)品只能檢測到系統(tǒng)里面的數(shù)據(jù)有沒有出問題，其清洗和運行服務是不是正常，但是沒有辦法覆蓋到數(shù)據(jù)產(chǎn)生端的異常問題。在這樣的背景下，團隊提出了“全鏈路的數(shù)據(jù)巡檢監(jiān)控和預警”機制。它可以回溯到數(shù)據(jù)產(chǎn)生的業(yè)務源、在工具里面對數(shù)據(jù)進行加工的清洗過程，再回溯到 BI 里面，把每一端的巡檢來串聯(lián)起來，通過 OLTP 邏輯去判斷最后呈現(xiàn)的數(shù)據(jù)是否準確。
但巡檢事后預警機制，并不能根本性地解決事前發(fā)生的問題。于是團隊又開始進一步探索，怎么能夠保障它不出問題？這相當于要在“事前”的數(shù)據(jù)研發(fā)側做探索。
數(shù)據(jù)建模
前面提到，數(shù)據(jù)質量問題頻出與業(yè)務端的影響有關，這里涉及一個常發(fā)生的情況是：開發(fā)人員經(jīng)常改“口徑”。究其原因，和管理層經(jīng)常需要從不同維度去看數(shù)據(jù)有關，一旦管理層提出了基于某個指標的新的看數(shù)據(jù)的維度，開發(fā)人員可能又得重新去開發(fā)一次。
“從數(shù)據(jù)模型的角度來講，這種需求場景往往只要在數(shù)據(jù)多維模型上增加維度或者調整已有指標的計算邏輯就可以解決。數(shù)據(jù)是衡量業(yè)務過程和管理結果的，和業(yè)務模型是一一映射關系。我們在研發(fā)過程中會做 DDD 領域建模，但卻忽略了數(shù)據(jù)建模過程。等到要使用數(shù)據(jù)時，例如輸出業(yè)務報表或者跨業(yè)務間數(shù)據(jù)指標查詢時，才會考慮給數(shù)據(jù)團隊提需求，此時再介入設計，識別到業(yè)務開發(fā)問題的變更成本較高，往往就埋下了技術債務，在數(shù)據(jù)治理過程中進行糾偏，處理成本和效果都不太好?！泵啡葜赋?，這一點反映出團隊原先在開發(fā)前置環(huán)節(jié)的數(shù)據(jù)建模有所欠缺。
所有業(yè)務模型是相對穩(wěn)定的，映射到數(shù)據(jù)模型也是一樣。為了考慮功能和服務的可復用性，會進行應用業(yè)務建模，相對應的數(shù)據(jù)模型也要同步設計。業(yè)務應用研發(fā)和數(shù)據(jù)資產(chǎn)構建不應該是上下游關系，而應該是并行關系，通過業(yè)務建模和數(shù)據(jù)建?？梢韵嗷ヒШ蟻眚炞C設計的合理性。
因此，為了在事前避免引入數(shù)據(jù)質量隱患，梅容團隊認為第一要點是要保障數(shù)據(jù)開發(fā)人員可以基于業(yè)務建模的思路去映射完成數(shù)據(jù)模型設計，定義數(shù)據(jù)邏輯規(guī)范，然后再去切入開發(fā)過程。
這個思路類似于現(xiàn)在常見的應用開發(fā)流程，產(chǎn)品經(jīng)理會去基于領域建模、基于領域的實體、對象、事件去做通用模型的設計，設計完之后，由研發(fā)人員基于這個設計去完成代碼實現(xiàn)，去滿足事件、對象以及事件對象的交互過程。
參照上述思路，團隊把數(shù)據(jù)研發(fā)的過程分成了兩段——先數(shù)據(jù)建模后開發(fā)。“通過我們對業(yè)務過程的分析，去定義這個業(yè)務過程中它涉及到的維度、事實，建立多維模型?！钡冉ê昧酥?，開發(fā)的同學才接著做。規(guī)范在前，開發(fā)在后，它能按照業(yè)務語言和需求保持一致性，也能約束開發(fā)實現(xiàn)的嚴謹性，從而預防業(yè)務源頭端引入的質量問題。
統(tǒng)一數(shù)據(jù)標準體系
“先建模，再開發(fā)”是在事前解決問題的第一類舉措，團隊提出的第二類舉措則是在明源的體系里統(tǒng)一數(shù)據(jù)體系，實現(xiàn)“實時運維、有的治理”的數(shù)據(jù)工具。
明源云的業(yè)務系統(tǒng)和很多企業(yè)一樣是“煙囪式建設”，每個業(yè)務系統(tǒng)各有各的數(shù)據(jù)服務中心。各數(shù)據(jù)服務中心的數(shù)倉構建過程、規(guī)范、標準、清洗的腳本和清洗的語句都不一樣，導致嚴重的“數(shù)據(jù)孤島”問題。
團隊認為，要解決這個問題，要以統(tǒng)一數(shù)據(jù)體系為基礎。為此，明源云建立了 5 個“1”的數(shù)據(jù)工具標準：
- 統(tǒng)一數(shù)據(jù)架構標準。所引用的大數(shù)據(jù)引擎、數(shù)據(jù)開發(fā)工具必須統(tǒng)一，這樣才能保證開發(fā)腳本 SQL 語句是一樣的，從而約束每個業(yè)務員出來的數(shù)據(jù)的一致性。
- 統(tǒng)一基礎數(shù)據(jù)標準。將各業(yè)務系統(tǒng)的組織、項目、人員、客戶、供應商等高度共享的數(shù)據(jù)進行統(tǒng)一采集管理與分發(fā)，實現(xiàn)基礎數(shù)據(jù)實體 ID 統(tǒng)一，為支撐企業(yè)數(shù)據(jù)資產(chǎn)沉淀做好鋪墊。
- 統(tǒng)一數(shù)據(jù)資產(chǎn)標準，即上文提到的先建模再開發(fā)，要求每一個業(yè)務板塊都按照這種模式去把其數(shù)據(jù)進行規(guī)范化的治理，形成多維模型、指標模型和標簽模型等數(shù)據(jù)資產(chǎn)，并基于模型的應用場景封裝，提供標準的查詢服務 API。
- 統(tǒng)一數(shù)據(jù)分析標準。數(shù)據(jù)分析師可以直接應用數(shù)據(jù)資產(chǎn)模型的查詢服務，不用進行繁瑣的數(shù)據(jù)準備，大大減少了 SQL 開發(fā)，從而保證數(shù)據(jù)口徑的一致性。
- 統(tǒng)一數(shù)據(jù)開放標準。面向業(yè)務數(shù)據(jù)消費場景提供統(tǒng)一數(shù)據(jù)共享工具，打造除 BI 外的智能流程引擎、自動化營銷引擎、預警簡訊等一系列智能數(shù)據(jù)產(chǎn)品。通過 5 個“1”，把數(shù)據(jù)的產(chǎn)生端、數(shù)據(jù)的生產(chǎn)端、數(shù)據(jù)的消費端和數(shù)據(jù)的開放端都統(tǒng)一，明源的業(yè)務體系里的數(shù)據(jù)才能完成標準化。
部署和運維
在數(shù)字化轉型中，企業(yè)對于數(shù)據(jù)安全和數(shù)據(jù)資產(chǎn)的價值要求越來越高，不論是業(yè)務系統(tǒng)內(nèi)置的數(shù)據(jù)中心，還是明源為企業(yè)提供數(shù)據(jù)治理服務和構建數(shù)據(jù)資產(chǎn)中心，都要求能夠私有化，部署在國資云或者自建機房環(huán)境。團隊利用 Kubernetes 容器應用集群化管理，能夠對引擎中間件、平臺服務等以應用組合包方式，進行一鍵部署和統(tǒng)一運維。整套系統(tǒng)云端和私有化的部署交付在 30 分鐘內(nèi)完成，并具備自動化資源調度，動態(tài)擴容等能力。
數(shù)據(jù)工具的統(tǒng)一應用，解決了數(shù)據(jù)管理流程化的落地性。在數(shù)據(jù)生產(chǎn)和消費鏈路中，仍然會有技術側或者人為引入的異常。還需要在數(shù)據(jù)流程中通過巡檢、運維機制的在線化保證，以規(guī)則的確定性應對結果的不確定。
明源云數(shù)據(jù)運維的基本原則如下：
- 業(yè)務規(guī)則穿插在設計中完成，設計即標準。不增加用戶的工作量，自動形成數(shù)據(jù)質量知識庫沉淀。
- 監(jiān)控先建立全局視角，分主次、優(yōu)先級和處理時效。對重要場景的數(shù)據(jù)終端和基線做高優(yōu)先級兌現(xiàn)，避免無效信息爆炸。
- 建立業(yè)務和技術雙視角的責任模式，自動定位根因指向確定的排錯解決方。尊重人性，誰利害相關，誰主責解決，避免靠人線下推進導致的多方拉扯情況。通過以上原則，在工具產(chǎn)品中落地了全鏈路巡檢機制，拉通業(yè)務數(shù)據(jù)庫和業(yè)務應用場景，形成從數(shù)據(jù)發(fā)生、數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)服務、數(shù)據(jù)查詢和數(shù)據(jù)呈現(xiàn)等關鍵環(huán)節(jié)的規(guī)則巡檢，并基于分級規(guī)則預警和推送優(yōu)化建議。對運行態(tài)的風險、異常實時可知，保障數(shù)據(jù)穩(wěn)定、準確和及時性。
難題與挑戰(zhàn)
技術架構選型和內(nèi)部推行的阻力
明源云在 DataOps 上的探索與實踐之路并非一帆風順。技術層面，在大數(shù)據(jù)技術方案選型上一直在“踩坑”和“填坑”。
據(jù)了解，一開始數(shù)據(jù)團隊是基于公有云商業(yè)化的數(shù)據(jù)平臺架構去做業(yè)務實踐，后來發(fā)現(xiàn)在服務器上花了大量成本之余，也依然有很多解決不了的場景。因此，團隊就堅定地選擇了自建大數(shù)據(jù)底層架構的道路。
據(jù)梅容介紹，一開始先做離線架構的搭建，選用 Lambda 架構，由于明源云的 SaaS 服務報表的查詢并發(fā)很高，查詢場景多樣化，因此前后有過不少技術選型嘗試，例如在離線部分，嘗試過 StarRocks、Presto、TiDB......
做實時計算框架也是，“當時行業(yè)流行數(shù)據(jù)湖，包括 SnowFlake、Databricks 等國際一流廠商都用數(shù)據(jù)湖的架構，當時我們還跟 AWS 的工程師去聊，想搭數(shù)據(jù)湖的架構，但像 Hudi 和 Iceberg 在前兩年的時候都不太成熟，過去也是嘗試過一段時間。最終從生產(chǎn)穩(wěn)定性角度考慮沒有選擇數(shù)據(jù)湖，而是結合 B 端管理實際場景，采用 CDC+自研 SQL 計算框架的實時監(jiān)聽來滿足業(yè)務人員查看實時明細報表的場景；采用 Flink 流計算模式來滿足營銷等業(yè)務，基于實時指標運營的場景。基于社區(qū)版 Flink 的自研，把各團隊使用的商業(yè)版，以及 Kafka、Pulsar 等消息隊列進行適配改造。最終統(tǒng)一了技術架構，同步演進?！?/p>
梅容表示，大數(shù)據(jù)的組件不像原來的關系型數(shù)據(jù)庫那么成熟，行業(yè)也一直在發(fā)展，不斷有廠商去做各種各樣的嘗試，明源云需要結合自己的業(yè)務場景去選擇最適合自己的架構。
除了技術挑戰(zhàn)，DataOps 實踐面臨的另一大挑戰(zhàn)是在內(nèi)部推行統(tǒng)一數(shù)據(jù)體系?！皩τ跇I(yè)務團隊而言，雖然一些已有的數(shù)據(jù)基礎設施存在一些問題，但也能基本滿足業(yè)務快速迭代、快速創(chuàng)新的需求。但在這個人人都忙于兌現(xiàn)客戶需求的過程中，怎么樣‘對運行的飛機換引擎’，如何在契合業(yè)務快速發(fā)展對數(shù)據(jù)技術升級要求的機會下，既保留現(xiàn)有數(shù)據(jù)成果，又能夠讓大家快速應用我們的數(shù)據(jù)體系產(chǎn)品，以實現(xiàn)組織效率成本的最優(yōu)化？”
“整個過程并非要大拆大建，把所有數(shù)據(jù)拉取過來進行集中式治理，而是以“分區(qū)治理、分區(qū)入湖”的模式展開?！泵啡菡f到，“對于數(shù)據(jù)質量相對較好的業(yè)務團隊，采用逆向建模方式，以結果映射的方式，對客戶數(shù)據(jù)消費場景進行規(guī)范化和一致性的數(shù)據(jù)管理，以保證交付客戶應用的準確性和穩(wěn)定性；而對于要為客戶提供數(shù)據(jù)資產(chǎn)價值創(chuàng)造的業(yè)務團隊，和數(shù)據(jù)團隊合作，按數(shù)據(jù)標準體系共建的方式，形成數(shù)據(jù)驅動業(yè)務價值的場景化數(shù)據(jù)中臺解決方案，例如行業(yè)客戶數(shù)據(jù)中臺（CDP）、供應鏈協(xié)同平臺（SDP）、企業(yè)一體化經(jīng)營決策平臺等?！?/p>
數(shù)據(jù)治理的效果如何顯現(xiàn)
探索 DataOps 也讓明源云更堅定了一個目標：需要從用戶視角，建立一套持續(xù)、穩(wěn)定、可快速復制的面向交付的數(shù)據(jù)體系，也就是讓數(shù)據(jù)資產(chǎn)對所有的利益相關者來說都是現(xiàn)成的、可訪問的和價值最大化的。
DataOps 在明源云的數(shù)據(jù)資產(chǎn)體系中也會應用在交付實施的方案中，用于支撐數(shù)據(jù)業(yè)務化產(chǎn)品的靈活交付，以及持續(xù)穩(wěn)定、準確的運維保障。
但數(shù)據(jù)治理的效果很難顯性化體現(xiàn)，難以讓客戶感知到成果。這也是明源云在落地 DataOps 的過程中，遇到的主要挑戰(zhàn)之一。為解決該問題，面向客戶三類角色，團隊把 DataOps 實施的成果可視化和價值化呈現(xiàn)：
- 業(yè)務視角的數(shù)據(jù)資產(chǎn)全景圖：實時看到按業(yè)務主題域構建的四類資產(chǎn)多維模型、指標、標簽、API 服務資產(chǎn)等，穿透查看資產(chǎn)模型的生產(chǎn)鏈路，便于識別業(yè)務系統(tǒng)數(shù)據(jù)風險。
- 價值視角的數(shù)據(jù)資產(chǎn)信息架構：包含面向高層決策的指標價值樹和業(yè)務人員的指標目錄，能夠洞察業(yè)務發(fā)展趨勢、異常變化、晴雨表現(xiàn)，分類管理高層和業(yè)務人員使用的指標體系。
- 技術視角的數(shù)據(jù)地圖：數(shù)倉分層的各類表清單，數(shù)據(jù)生產(chǎn)流程和血緣關系，體現(xiàn)拉通了哪些系統(tǒng)的數(shù)據(jù)，支撐了哪些業(yè)務場景的應用。
- 運維視角的數(shù)據(jù)全鏈路巡檢監(jiān)控告警：基于終端用戶（重點高層報表）數(shù)據(jù)消費場景，對數(shù)據(jù)采、建、用數(shù)據(jù)全鏈路進行自動化的巡檢，主動及時地推送對數(shù)據(jù)應用的異常。
從 DataOps 到 AIOps
“DataOps 的設計理念是以用戶為中心，用確定性的工具來解決不確定性的業(yè)務變化?！蹦敲?，一般行業(yè)上怎么解決這類不確定性的問題？
梅容進一步總結道：“第一點是有規(guī)范，怎么樣都在框架內(nèi)，這樣就不至于說各自發(fā)散收不回來。第二點是工具化，一定要有在線化的工具，可以按照其規(guī)范一步步執(zhí)行?！?/p>
需要注意的是，現(xiàn)階段也有 DataOps 解決不了的問題，比如 DataOps 更多是方法論和一系列有效的工具集合，并沒有業(yè)務知識的沉淀，即行業(yè) Know-how 的開箱即用內(nèi)容；缺乏發(fā)現(xiàn)和排除問題、自動修復能力；另外，DataOps 目前是基于項目實踐經(jīng)驗的規(guī)則治理，應該加入更多自學習的能力，向 AIOps 演進。
談及接下來明源云在 DataOps 的探索，梅容告訴我們，首先是數(shù)據(jù)體系落地，即明源云產(chǎn)研體系里的五層數(shù)據(jù)體系，先把它做實；其次是 AIops 數(shù)據(jù)準確性盤點，目前 DataOps 更多還是要靠人去維護規(guī)則標準，后續(xù)需要能根據(jù)數(shù)據(jù)趨勢去預判數(shù)據(jù)的增減對于業(yè)務是否合理等等；第三是智能化的問題排查恢復，以及最佳實踐的優(yōu)化建議，即基于終端業(yè)務用戶的數(shù)據(jù)消費場景，事前提供數(shù)據(jù)變更時的關聯(lián)影響體系，事中提供告警并針對異常提供數(shù)據(jù)血緣、生產(chǎn)鏈路關系分析，事后提供數(shù)據(jù)質量巡檢規(guī)則配置加強。
電子書推薦
本文選自《中國卓越技術團隊訪談錄》（2022 年第二季），本期精選了微軟 Edge、螞蟻可信原生、明源云、文因互聯(lián)、Babylon.js 等技術團隊在技術落地、團隊建設方面的實踐經(jīng)驗及心得體會。本期電子書已經(jīng)在 InfoQ 網(wǎng)站上線，大家可以掃描下圖二維碼下載，查看更多精彩內(nèi)容。
《中國卓越技術團隊訪談錄》是 InfoQ 打造的重磅內(nèi)容產(chǎn)品，以各個國內(nèi)優(yōu)秀企業(yè)的 IT 技術團隊為線索策劃系列采訪，希望向外界傳遞杰出技術團隊的做事方法 / 技術實踐，讓開發(fā)者了解他們的知識積累、技術演進、產(chǎn)品錘煉與團隊文化等，并從中獲得有價值的見解。
訪談錄現(xiàn)開放長期報名通道，如果你身處傳統(tǒng)企業(yè)經(jīng)歷了數(shù)字化轉型變革，或者正在互聯(lián)網(wǎng)公司進行創(chuàng)新技術的研發(fā)，并希望 InfoQ 可以關注和采訪你所在的技術團隊，可以添加微信：caifangfang842852，請注明來意及公司名稱。
好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525 備注：發(fā)貨聯(lián)盟引流學習； 我拉你進直播課程學習群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術課程免費分享！
