DataOps成熟度框架與云原生數(shù)據(jù)中臺的關(guān)系

DataOps成熟度框架與云原生數(shù)據(jù)中臺的關(guān)系01

什么是DataOps？Q：現(xiàn)在越來越多的技術(shù)和廠商都在產(chǎn)品中會提到DataOps，但是可能目前大家對DataOps定義還沒有很統(tǒng)一的定義。那么，到底什么是DataOps？為什么它現(xiàn)在會被很多企業(yè)青睞？A：DataOps是從DevOps借鑒的一個理念?？梢岳斫鉃镈ataOps是把DevOps的一些理念映射到了數(shù)據(jù)開發(fā)上，它們的很多觀點是可以一一對應(yīng)的，如開發(fā)及運維、云原生、微服務(wù)化、CI/CD，這些都可以在DataOps里找到，如果你的DevOps里沒有這些概念，就要考慮下你的開發(fā)流程是不是符合最佳實踐。但DataOps與DevOps也有區(qū)別。DataOps是想處理數(shù)據(jù)，而在DevOps里是不需要處理數(shù)據(jù)的，它主要是做應(yīng)用的開發(fā)，應(yīng)用的CI/CD、發(fā)布及運維。但就像剛才說的，DataOps實際上屬于一個比較早期的概念，大家對它的解讀還是會有不一樣。在DataOps里面有很重要的一點，就是要處理數(shù)據(jù)的各種不可預知性。數(shù)據(jù)語義是一個難題，它沒辦法在CI/CD里被容易定義，不是沒有辦法，但很困難。之前大部分原生大數(shù)據(jù)組件開發(fā)時并沒有考慮到這個規(guī)范。DevOps也經(jīng)過了很長一段時間的演變，像Git逐漸成為規(guī)范，微服務(wù)基本上都是標準的組件。大數(shù)據(jù)組件體系架構(gòu)特別多、選擇特別多，發(fā)展也特別快，現(xiàn)在的Spark、流數(shù)據(jù)，F(xiàn)link，卡夫卡，底層基本上也是K8S、Hadoop和Hdefs，這些基本上可以形成標準化。那么，現(xiàn)在就是做DataOps一個比較好的時候。DataOps的工作主要有五個方向：第一個是任務(wù)調(diào)度。主要包括云原生調(diào)度、容器的調(diào)度，這跟DevOps是一樣的。第二個是數(shù)據(jù)安全。數(shù)據(jù)安全以前基本不在DataOps的考慮范圍，也不在數(shù)據(jù)開發(fā)的范圍內(nèi)，但現(xiàn)在數(shù)據(jù)安全很重要。第三個就是數(shù)據(jù)管理和數(shù)據(jù)門戶。大家可能會說原數(shù)據(jù)管理不都好多年了，但以前的原數(shù)據(jù)管理主要是針對關(guān)系型數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫對原數(shù)據(jù)的管理相對容易，只要到數(shù)據(jù)庫里把原數(shù)據(jù)爬出來就可以。但現(xiàn)在有流數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)，還有TaiDB等，各種各樣的原數(shù)據(jù)怎么樣去管理？血緣管理更復雜了。之前是幾個SQL之間的血緣管理，現(xiàn)在關(guān)系到各種各樣的查詢、各種各樣的系統(tǒng)、數(shù)據(jù)門戶跟MapDatas是一樣的。第四是數(shù)據(jù)檢測的可視化。DevOps里有很多可監(jiān)測到的指標，數(shù)據(jù)層面也一樣。用多少資源、花多少時間、創(chuàng)造了多少價值，之前都是一個黑盒子，但DataOps的整個數(shù)據(jù)都是端到端的，相關(guān)指標可觀測、可管理。第五就是集成開發(fā)。所有的工具必須是可集成的，不可能做一個工具負責血緣管理，再做一個工具負責調(diào)度。我認為，DataOPS里面必須具備這五個工具體系，如果你的DataOps體系里面缺了任何一個，我都覺得是不完善的。Q：DataOps如何做持續(xù)測試？A：數(shù)據(jù)開發(fā)、數(shù)據(jù)程序的測試一直是老大難問題，甚至頭部大廠整套流程做下來也是現(xiàn)在非常困難的。現(xiàn)在DevOps里有一個很有意思的觀念，就是把集訓資源的管理全部用Code來管理，大數(shù)據(jù)也一樣。美國有一個很火的公司叫DTB，它是要把所有的ETL（數(shù)據(jù)倉儲技術(shù)）流程做成代碼管理，將SQL的所有轉(zhuǎn)換變量化、代碼化，將所有ETL程序間的關(guān)系、血緣全部用代碼的形式來進行管理?？梢哉f，不只SQL是代碼，整個調(diào)度也都是代碼。所以，DBT的整個ETL程序可以被放到Git里面。用戶可以在指定的data

source的測試環(huán)境中可以測試，可以到Data生態(tài)環(huán)境中直接切換一個Data

source，將其變成生產(chǎn)環(huán)境，所以它允許支撐ETL流程的CI/CD。將所有ETL程序之間的依賴全部代碼化，這就是DTB的一個思路。除了ETL之外，我們現(xiàn)在做的事就是把所有大數(shù)據(jù)組件里面的關(guān)系、程序全部代碼化，這是未來的必然趨勢。02

DataOps與云原生數(shù)據(jù)中臺的關(guān)系Q：DataOps與云原生數(shù)據(jù)中臺是什么樣的關(guān)系？他們目前各自的發(fā)展情況如何？A：國內(nèi)數(shù)據(jù)中臺也提了兩三年了，有成功的案例也有失敗的。我們在這方面也做了很多探索。我們的觀點是，數(shù)據(jù)中臺絕對要做，但DataOps是實現(xiàn)數(shù)據(jù)中臺的一個最好的方法論和工具體系。這跟DevOps是一樣的。一個業(yè)務(wù)系統(tǒng)可以使用DevOps方法來做，也可以使用傳統(tǒng)方法去做，兩種方法最后做成的業(yè)務(wù)系統(tǒng)可能都差不多，但這只是開始的時候差不多，后面的持續(xù)迭代、持續(xù)運維的時候，就能看出來DevOOps的優(yōu)勢了。數(shù)據(jù)中臺也是一樣，它是給大家提供一個數(shù)據(jù)開發(fā)和運營的底座，開始你可以用各種各樣的方法去做一個數(shù)據(jù)平臺，但是后續(xù)迭代和不斷發(fā)展的時候，DataOps就成為最合適的一種方法。DevOps提倡的是賦能和自助，通過CI/CD持續(xù)發(fā)布，開發(fā)工程師自己來做運維測試，DataOps也一樣，也是提供工具讓各個業(yè)務(wù)部門等數(shù)據(jù)使用者，能夠在中臺上拿到自己需要的功能。我們認為這是DataOps和數(shù)據(jù)中臺的關(guān)系。Q：企業(yè)如何去做云原生數(shù)據(jù)平臺的改造？整個過程可能會面臨哪些問題？A：我覺得，現(xiàn)在云原生的數(shù)據(jù)中臺還是一個比較有挑戰(zhàn)性的課題，但也是個必然的趨勢。很多企業(yè)的數(shù)據(jù)平臺效率非常低，因為傳統(tǒng)大數(shù)據(jù)平臺使用的Hadoop、卡夫卡等都不是在云原生的方式下開發(fā)，資源使用效率低、管理復雜，但云原生會大大降低整個系統(tǒng)的管理復雜度，提高系統(tǒng)的使用效率和運營效率。這個過程中會面臨的困難，主要是人才問題。這個技能的門檻比較高，需要研發(fā)既懂云原生又懂新技術(shù)，這樣的人才缺口還是挺大的。但這也有個好處就是，云原生產(chǎn)品的標準化程度比較高，這樣容易做出標準化的產(chǎn)品讓大家使用。舉個例子，以前裝一個大數(shù)據(jù)平臺需要直接面對底下的物理及虛擬機，但各種各樣的配置，不同的操作系統(tǒng)、環(huán)境和網(wǎng)絡(luò)，所有這些都得去管理。K8S的出現(xiàn)就讓大家不必再考慮所有的底層組件，只要跟云原生這個體系對接就可以了。這是一個很好的機會，所有的企業(yè)一定會看到，但這個過程肯定是需要時間的。

Q：您之前多次提到過“數(shù)據(jù)中臺方法論”，這個方法論具體都包含哪些內(nèi)容？A：這個方法論的主要目的就是追求效率。我們國內(nèi)很多客戶的大數(shù)據(jù)平臺的資源使用率大概都是15%-20%，但Twitter的自然使用率一般能達到50%-60%，而且還有各種各樣的彈性擴展、自動容錯等云原生功能。了解這個之后，需要做到以下四點：第一，選擇合適的工具和平臺。這個是基礎(chǔ)，選不到合適的架構(gòu)工具，也就不存在效率了，所以如何選擇合適的平臺工具很重要。第二，要有一個完善的頂層架構(gòu)設(shè)計。因為數(shù)據(jù)平臺要把大家的數(shù)據(jù)接進來，與業(yè)務(wù)系統(tǒng)對接起來才能產(chǎn)生效果。DevOps分布式的開發(fā)，集中式的管理，但這個集中式管理不是靠人，而是靠體系和工具。第三，業(yè)務(wù)驅(qū)動。為了大數(shù)據(jù)而大數(shù)據(jù)一般成功不了，一定是可以解決業(yè)務(wù)問題的才能走到最后，解決不了業(yè)務(wù)問題的數(shù)據(jù)平臺是偽命題。解決業(yè)務(wù)痛點之后，還要賦能業(yè)務(wù)。要把業(yè)務(wù)部門引入進來，不斷使用這個數(shù)據(jù)平臺，獲得業(yè)務(wù)部門認可后這個東西才能走。第四，要有價值衡量體系。如何量化產(chǎn)生的價值，很困難但是也很重要。我們一般要求決策方、業(yè)務(wù)方，技術(shù)方和數(shù)據(jù)平臺等各方面職責明確，避免后面出現(xiàn)越來越多的問題。

03

DataOps應(yīng)用Q：2018年，高德納把DataOps納入了技術(shù)管理成熟體系曲線里面，DataOps被正式接納和推廣。三年過去了，目前有什么成熟的應(yīng)用案例出來嗎？A：DataOps在云原生出來之前就有，但可能沒有叫這個名字。頭條、騰訊等大廠們都有自己的一套DataOps體系，Twitter等硅谷公司也有，那為什么現(xiàn)在才提出來？因為這個東西要產(chǎn)品化。雖然大廠都有DataOps體系，但是將近一百人的數(shù)據(jù)團隊，eBay大概有三百多人，一般企業(yè)很難請得起這么多高薪的人才?，F(xiàn)在DataOps火了是因為大家都需要，數(shù)據(jù)價值不是大廠獨有的。但橫梗在前的成本問題怎么解決？這就需要DataOps工具將數(shù)據(jù)價值開發(fā)平移化。為什么稱為云原生的DataOps？因為只有云原生技術(shù)統(tǒng)一了各種各樣的硬件環(huán)境、開發(fā)環(huán)境、發(fā)布環(huán)境、運維流程等等之后，DataOps才可以將聚焦在數(shù)據(jù)開發(fā)、數(shù)據(jù)監(jiān)控、數(shù)據(jù)管理、原數(shù)據(jù)和數(shù)據(jù)安全上。Q：您在Twitter的時候，一個主要職責就是讓公司所有的人避免重復開發(fā)數(shù)據(jù)組件。這個需求是在一個什么樣的背景下產(chǎn)生的？A：這個就是很重要的不要重復造輪子的問題。重新造輪子會造成資源消耗，然后減慢開發(fā)速度。要避免不重新造輪子，那么就必須知道現(xiàn)在有什么“輪子”，但很多企業(yè)并不知道自己有什么“輪子”。DataOps很重要的一點就是原數(shù)據(jù)管理，它的原數(shù)據(jù)管理比原來的要更廣泛，它可以知道整個企業(yè)有什么樣的數(shù)據(jù)功能。更重要的是，企業(yè)重新造輪子，一旦兩個輪子造得不一樣，會把這個車開垮。我們原來做數(shù)據(jù)門戶，就要求所有的業(yè)務(wù)部門和數(shù)據(jù)分析師必須做統(tǒng)一的接口，然后發(fā)現(xiàn)有兩個部門就在重復造輪Q：DataOps會有開源生態(tài)嗎？A：目前是逐漸成熟的過程中，還沒有成熟到大家都可以使用的端到端產(chǎn)品。我們之前公眾號有篇文章講到，硅谷的大概十幾家公司，每個公司都有自己的數(shù)據(jù)門戶和產(chǎn)品，但是沒有成熟的產(chǎn)品。今年6月份左右，Linking將自己的數(shù)據(jù)門戶產(chǎn)品開源了，也有人在做血緣管理，但都是這兩年才起來的公司。這個生態(tài)在逐漸形成，但是遠遠沒有到達成熟的階段。Q：現(xiàn)在，DataOps還解決不了哪些問題？A：我覺得，當前DataOps沒辦法解決業(yè)務(wù)價值的挖掘問題。DataOps實際是降低了數(shù)據(jù)使用門檻，讓更多的業(yè)務(wù)人員可以直接開發(fā)他們需要的數(shù)據(jù)并將這個開發(fā)成果給大家使用，這在以前必須要依賴數(shù)據(jù)科學家或者數(shù)據(jù)工程師。但是，如何把這些數(shù)據(jù)與業(yè)務(wù)結(jié)合起來、用數(shù)據(jù)去促進業(yè)務(wù)，這不是DataOps能回答的問題。我們只是賦能，但是真正怎么樣讓你的數(shù)據(jù)去促進企業(yè)的業(yè)務(wù)發(fā)展，那一定需要企業(yè)懂自己的業(yè)務(wù)。04

DataOps成熟度框架在2022大數(shù)據(jù)產(chǎn)業(yè)峰會上，中國信通院正式發(fā)布了《DataOps成熟度框架》。自2014年大數(shù)據(jù)首次寫入政府工作報告起，我國大數(shù)據(jù)產(chǎn)業(yè)飛速發(fā)展，需求旺盛、供給強勁。在國家大數(shù)據(jù)相關(guān)政策的護航下，我國的大數(shù)據(jù)產(chǎn)業(yè)已進入深化階段。隨著發(fā)展的不斷深入，企業(yè)數(shù)智化轉(zhuǎn)型逐漸到達了瓶頸，各類矛盾浮出水面。一是效率與管理之間的矛盾。數(shù)據(jù)項目尋求快速交付，那么管理就難以貫徹落實。在執(zhí)行上往往就出現(xiàn)了管理和實施兩張皮的現(xiàn)象，許多基礎(chǔ)工作遭到了忽視，從而產(chǎn)生了諸多的質(zhì)量問題；二是業(yè)務(wù)與技術(shù)之間的矛盾。以前我們技術(shù)水平落后，面對的是巧婦難為無米之炊的問題?，F(xiàn)在技術(shù)發(fā)展迅猛，但在業(yè)務(wù)和技術(shù)的銜接上出現(xiàn)了問題，難以有的放矢。三是需求與供給之間的矛盾?，F(xiàn)在的技術(shù)發(fā)展迅猛，面對企業(yè)提出的需求，供給側(cè)能夠給出各式各樣的解決方案。需求方精力都用在識別和對比，缺乏對需求的深入思考，遠離了問題的本質(zhì)。在數(shù)智化轉(zhuǎn)型的大背景下，企業(yè)逐步意識到數(shù)據(jù)的重要程度空前。各行各業(yè)加速建設(shè)企業(yè)內(nèi)部信息系統(tǒng)，加快數(shù)據(jù)平臺構(gòu)建。但在朝數(shù)智化轉(zhuǎn)型邁進的過程中，總是存在著一些問題，阻擋著企業(yè)完成數(shù)智化蛻變。從企業(yè)角度來看，在數(shù)據(jù)項目的開發(fā)、維護、管理的過程中，普遍會遇到一些典型的問題，例如數(shù)據(jù)項目的人工依賴度高、團隊協(xié)作配合困難、需求響應(yīng)時間低于預期、開發(fā)流程不夠順暢、管理要求難以貫徹等問題。已有研究數(shù)據(jù)報道：99%的企業(yè)數(shù)字化轉(zhuǎn)型以失敗告終，84%的數(shù)字化轉(zhuǎn)型項目未能達預期。在數(shù)智化轉(zhuǎn)型這一階段，企業(yè)的業(yè)務(wù)正處于發(fā)展的關(guān)鍵時期，組織內(nèi)的數(shù)據(jù)意識已經(jīng)逐漸成熟，數(shù)據(jù)相關(guān)的需求在這一階段激增。但是這一階段，技術(shù)引擎的動力略顯不足，數(shù)據(jù)項目的成本高、數(shù)據(jù)準備的時間長、數(shù)據(jù)需求的響應(yīng)不及時。種種問題阻礙住了企業(yè)完成數(shù)智化蛻變。也是與此同時，DataOps以破局者的身份出現(xiàn)在大家的視野當中，為企業(yè)的數(shù)據(jù)引擎換擋。DataOps的概念最早在2014年由國外學者提出，隨后業(yè)界逐步對其內(nèi)涵進行補充。在2018年DataOps正式被納入Gartner的數(shù)據(jù)管理技術(shù)成熟度曲線當中，由此進入了國際的視野當中。2022年中國信通院正式牽頭啟動了DataOps的標準建設(shè)工作，以此為基礎(chǔ)推動我國大數(shù)據(jù)產(chǎn)業(yè)的多元化發(fā)展，助力企業(yè)完成數(shù)智化蛻變。從發(fā)展上看，自2018年被Gartner納入到數(shù)據(jù)管理技術(shù)成熟度曲線以來，DataOps熱度逐年上升，在21年處在一個從萌芽期到爆發(fā)期的關(guān)鍵過渡階段，預示著未來2-5年內(nèi)DataOps將得到廣泛的實踐應(yīng)用。從定義上看，Gartner、IBM、Wikipedia爭相對DataOps提出了自己的定義。普遍認同DataOps具有敏捷、協(xié)作、自動化等特點。并且也提到了人員、流程、技術(shù)三者融合協(xié)作的重要性。實踐上看，歐美國家的一些公司在DataOps的探索和發(fā)展上要早于中國?，F(xiàn)階段，我國有更廣闊的發(fā)展空間和挖掘潛力，在制度保障、人才培養(yǎng)、技術(shù)儲備發(fā)展上都有著長期優(yōu)勢。在國外。有如Twitter、Google等公司使用面向未來的數(shù)據(jù)架構(gòu)，有如IBM公司也在多年前就開始研發(fā)了諸如Knowledgecatalog、DataStage、CloudPakforData等符合DataOps理念的解決方案，也有像StreamSets公司這樣以DataOps思想來引領(lǐng)開發(fā)的工具產(chǎn)品。在國內(nèi)。也有很多的企業(yè)先驅(qū)者，通過敏銳的嗅覺和強大的管理執(zhí)行力去探索DataOps的實踐。如中國工商銀行、農(nóng)業(yè)銀行、平安銀行等多家銀行機構(gòu)，聯(lián)通數(shù)科、廣東移動、江蘇移動、浙江移動等通信企業(yè)，阿里、騰訊、浩鯨、數(shù)造科技等科技公司，都在積極探索并嘗試用DataOps的理念來推動我國數(shù)據(jù)文化的建設(shè)和發(fā)展。DataOps標準的建設(shè)意義在于在于三定：即確定Data