正在閱讀:

為什么說(shuō)DataOps是數(shù)據(jù)中臺(tái)的拐點(diǎn)?

掃一掃下載界面新聞APP

為什么說(shuō)DataOps是數(shù)據(jù)中臺(tái)的拐點(diǎn)?

在上數(shù)據(jù)中臺(tái)前,你需要搞明白什么是DataOps。

文|新眸企服組 桑明強(qiáng)

要說(shuō)最近企服圈什么最被關(guān)注,SaaS和數(shù)據(jù)中臺(tái)想必是大多數(shù)人心里的答案。

前者商業(yè)模式已經(jīng)被證明,Salesforce就是最好的例子,后者從剛出現(xiàn)時(shí)的火熱,到被質(zhì)疑跌落谷底只用了短短3、4年時(shí)間。這讓很多人好奇,為什么在“數(shù)據(jù)價(jià)值已經(jīng)被證明”和“企業(yè)數(shù)字化轉(zhuǎn)型也成了多數(shù)CEO共識(shí)”的當(dāng)下,大家對(duì)于數(shù)據(jù)中臺(tái)的看法還會(huì)呈現(xiàn)兩極分化,看好的人堅(jiān)定認(rèn)為數(shù)據(jù)中臺(tái)是企業(yè)數(shù)字化轉(zhuǎn)型的“解藥”,看衰的人規(guī)勸同行不要上中臺(tái),它是雞肋,是“毒藥”。

歸根結(jié)底,是因?yàn)闃I(yè)界對(duì)一個(gè)關(guān)鍵問(wèn)題的看法還沒有達(dá)成一致,即數(shù)據(jù)中臺(tái)究竟是不是支撐企業(yè)數(shù)字化轉(zhuǎn)型的最合理的數(shù)據(jù)基礎(chǔ)架構(gòu)?翻譯一下就是,數(shù)據(jù)中臺(tái)能不能滿足企業(yè)數(shù)字化轉(zhuǎn)型的最大公約數(shù),或者說(shuō)媒體老師們口中的最優(yōu)解。

數(shù)據(jù)中臺(tái)是一個(gè)“新物種”,但它的新僅僅停留在國(guó)內(nèi)廠商的造詞能力上,它誕生于國(guó)內(nèi),不懂技術(shù)的人容易被“中臺(tái)”二字帶偏,誤以為它是一副萬(wàn)能藥,在硅谷,其實(shí)也有一些知名獨(dú)角獸公司有著和數(shù)據(jù)中臺(tái)架構(gòu)相類似的數(shù)據(jù)基礎(chǔ)架構(gòu),但他們習(xí)慣把它叫作數(shù)據(jù)平臺(tái),而不是數(shù)據(jù)中臺(tái)。

這里我們需要明確的是,所謂的“數(shù)據(jù)中臺(tái)”,它只是一種叫法,就像“人工智能”一樣,具體定義和內(nèi)容往往需要根據(jù)要實(shí)現(xiàn)的目標(biāo)和要解決的問(wèn)題來(lái)確定。以Twitter為例,公司從2011年的300人,發(fā)展到2014年的4000人,大數(shù)據(jù)平臺(tái)從80臺(tái)服務(wù)器的單純Hadoop集群,擴(kuò)展到8000臺(tái)服務(wù)器的核心數(shù)據(jù)處理平臺(tái),打從在很小規(guī)模時(shí),Twitter就是一家數(shù)據(jù)驅(qū)動(dòng)型的公司,而它管理的底層支撐,是一個(gè)全局共享的大數(shù)據(jù)平臺(tái)。

圖:Twitter大數(shù)據(jù)平臺(tái)架構(gòu)(來(lái)源:《云原生數(shù)據(jù)中臺(tái):架構(gòu)、方法論與實(shí)踐》)

這種平臺(tái)型架構(gòu)的好處是,Twitter在業(yè)務(wù)和組織快速擴(kuò)張時(shí),能做到統(tǒng)一數(shù)據(jù)規(guī)范、消除數(shù)據(jù)和應(yīng)用孤島。回到國(guó)內(nèi),多數(shù)企業(yè)在搭建數(shù)字化信息系統(tǒng)時(shí),也就是在頂層設(shè)計(jì)的初期,并沒有做到面向未來(lái),所以一旦組織擴(kuò)張速度過(guò)快,數(shù)據(jù)層面的浪費(fèi)和組織層面的冗余也就隨之而來(lái),在這種情況下,企業(yè)往往盲目寄托于上數(shù)據(jù)中臺(tái),把包袱丟給數(shù)據(jù)智能服務(wù)提供商,但卻忽略了自身的癥結(jié)關(guān)鍵所在,所以難免越做越錯(cuò)。

一般來(lái)說(shuō),數(shù)據(jù)智能有3個(gè)發(fā)展階段:大數(shù)據(jù)平臺(tái)建設(shè)階段、數(shù)據(jù)管理及應(yīng)用階段和數(shù)據(jù)能力中臺(tái)化階段。就目前來(lái)看,大部分企業(yè)的數(shù)據(jù)平臺(tái)建設(shè)已經(jīng)進(jìn)行到一、二階段,但要順利過(guò)渡到第三階段,就繞不開一個(gè)關(guān)鍵方法論的幫助——DataOps(數(shù)據(jù)運(yùn)維),值得一提的是,它是很多硅谷公司在解決第三階段問(wèn)題時(shí)普遍采用的方法論。

DataOps由DevOps概念衍生而來(lái),是基于元數(shù)據(jù)開發(fā)和部署數(shù)據(jù)分析應(yīng)用的一種靈活敏捷的方法?!八寯?shù)據(jù)開發(fā)過(guò)程變得敏捷可控,這是眼下很多公司最頭疼的事。對(duì)于大多數(shù)企業(yè)來(lái)說(shuō),數(shù)據(jù)在調(diào)整過(guò)程中容易缺少版本管理、缺少持續(xù)集成,甚至沒有測(cè)試環(huán)節(jié),整個(gè)過(guò)程都要靠人去做這件事情,他們就像是數(shù)據(jù)管道工,更別談最終形成你想要的AI模型?!钡纹湛萍糉astData產(chǎn)品管理部總經(jīng)理曾這樣談到,無(wú)獨(dú)有偶,《數(shù)字化轉(zhuǎn)型架構(gòu):方法論和云原生》一書中也明確提及,云原生應(yīng)用平臺(tái)的發(fā)展將經(jīng)歷DevOps—DataOps—AIOps的演進(jìn)路徑。為此,這篇文章我們將主要探討:

1、為什么有的數(shù)據(jù)中臺(tái)不能成功?

2、突然崛起的DataOps究竟是什么?

3、追求DataOps,為什么要回歸第一性原理?

01、為什么有的數(shù)據(jù)中臺(tái)不能成功?

數(shù)據(jù)中臺(tái)成熟后,會(huì)不會(huì)變成類似數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖一樣的數(shù)據(jù)基礎(chǔ)架構(gòu),可能是大多數(shù)人最為關(guān)心的問(wèn)題,但這對(duì)于數(shù)據(jù)中臺(tái)的發(fā)展來(lái)說(shuō),其實(shí)是一件好事,原因在于它把問(wèn)題收窄了,回歸到數(shù)據(jù)中臺(tái)的產(chǎn)品本質(zhì)上,也就是基本面問(wèn)題。

和以往技術(shù)中間件不同的是,雖然數(shù)據(jù)中臺(tái)也承接底層數(shù)據(jù)和上層業(yè)務(wù)的中間層,但它的價(jià)值更多地體現(xiàn)在與企業(yè)業(yè)務(wù)結(jié)合的能力矩陣維度,而不是簡(jiǎn)單地做一些數(shù)據(jù)標(biāo)準(zhǔn)化和報(bào)表工具。所以這里就涉及到能用和好用的問(wèn)題,同時(shí)也是當(dāng)下的主流問(wèn)題:做一個(gè)能用的數(shù)據(jù)中臺(tái)不難,但要做到好用甚至說(shuō)持續(xù)好用,非常難。

在滴普科技看來(lái),“這和國(guó)內(nèi)企業(yè)數(shù)字化的進(jìn)程有關(guān),很多企業(yè)本身就有自己的一些信息系統(tǒng),大多數(shù)在數(shù)字化升級(jí)時(shí),都是基于現(xiàn)有基礎(chǔ)改造,而不是從0到1摸底建設(shè),這對(duì)于數(shù)據(jù)智能服務(wù)商挑戰(zhàn)極高?!北澈蟮脑蚝芎?jiǎn)單,一般來(lái)說(shuō),傳統(tǒng)信息系統(tǒng)往往建立在多個(gè)數(shù)據(jù)倉(cāng)庫(kù)之上,而數(shù)據(jù)中臺(tái)會(huì)使用數(shù)據(jù)湖來(lái)存儲(chǔ),但根本問(wèn)題是,分割的數(shù)據(jù)層無(wú)法對(duì)核心業(yè)務(wù)流程進(jìn)行全局還原和支持,也無(wú)法實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)的全局決策和產(chǎn)品研發(fā)。

前文提到的Twitter就是最好的例子,在2011年以前,Twitter開發(fā)和發(fā)布產(chǎn)品的流程非常冗長(zhǎng),產(chǎn)品經(jīng)理需要到各個(gè)部門調(diào)研可以使用的數(shù)據(jù),并協(xié)調(diào)數(shù)據(jù)的生產(chǎn)化問(wèn)題。在數(shù)據(jù)平臺(tái)推行后,Twitter整個(gè)產(chǎn)品的開發(fā)和迭代流程從以月計(jì)改為以周計(jì),活躍用戶數(shù)也從2011年不到1億,增長(zhǎng)到2014年接近3億。在當(dāng)時(shí)Twitter大數(shù)據(jù)項(xiàng)目負(fù)責(zé)人看來(lái),“這是架構(gòu)上的勝利?!?/p>

同理到現(xiàn)在的環(huán)境也是一樣,隨著自助服務(wù)分析和機(jī)器學(xué)習(xí)的迅速發(fā)展,公司里的管道數(shù)量也隨著數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師以及數(shù)據(jù)使用者業(yè)務(wù)部門增多而增多,問(wèn)題的關(guān)鍵是,幾乎每一個(gè)都需要專門的數(shù)據(jù)集和數(shù)據(jù)訪問(wèn)權(quán)限才能產(chǎn)生內(nèi)容,而協(xié)調(diào)這些工具、技術(shù)和人員是一項(xiàng)巨大且耗費(fèi)精力的工作,特別是在規(guī)模龐大的開發(fā)團(tuán)隊(duì)里,這也解釋了為什么DataOps會(huì)發(fā)展起來(lái)。

溯源企業(yè)數(shù)據(jù)平臺(tái)項(xiàng)目的失敗案例,你會(huì)發(fā)現(xiàn)它們往往都有一些共性,比如初期啟動(dòng)難,得不到業(yè)務(wù)支持、很難把數(shù)據(jù)源規(guī)模化,缺少對(duì)復(fù)雜源數(shù)據(jù)系統(tǒng)的管理手段、數(shù)據(jù)平臺(tái)項(xiàng)目跟不上企業(yè)創(chuàng)新要求以及開發(fā)和運(yùn)營(yíng)成本極高,無(wú)法正向反哺業(yè)務(wù)。

以往的經(jīng)驗(yàn)告訴我們,很多時(shí)候,一個(gè)高速發(fā)展的業(yè)務(wù)往往是因?yàn)樵缙诩軜?gòu)設(shè)計(jì)的問(wèn)題,變得難以迭代。所以從這個(gè)角度看,并不是數(shù)據(jù)平臺(tái)的理念過(guò)時(shí)了,而是數(shù)據(jù)中臺(tái)的架構(gòu)過(guò)時(shí)了。因?yàn)槌舜_定對(duì)于業(yè)務(wù)的價(jià)值外,建設(shè)數(shù)據(jù)平臺(tái)的根本性問(wèn)題是技術(shù)架構(gòu)的選擇和設(shè)計(jì),但這相當(dāng)于給一架高速行駛的列車更換引擎,難度系數(shù)很高。

02、突然崛起的DataOps究竟是什么?

前文我們提到,DataOps是硅谷公司在解決第三階段問(wèn)題時(shí)普遍采用的方法論,同時(shí)也是數(shù)據(jù)中臺(tái)建設(shè)必須參考的一個(gè)方法論,這在一定程度上證明了DataOps的可行性。眾所周知,數(shù)據(jù)智能要解決的三大問(wèn)題是數(shù)據(jù)處理、模型搭建及交付,想要實(shí)現(xiàn)智能工程化或者大規(guī)??沙掷m(xù)的數(shù)據(jù)智能交付,現(xiàn)在業(yè)內(nèi)公認(rèn)的模式運(yùn)維解法是ModelOps,開發(fā)運(yùn)維解法是DevOps,至于數(shù)據(jù)運(yùn)維,就是DataOps。

在2018年Gartner發(fā)布的《數(shù)據(jù)管理技術(shù)成熟度曲線》報(bào)告中,DataOps概念被首次提出。

維基百科對(duì)DataOps的定義是一種面向流程的自動(dòng)化方法,由分析和數(shù)據(jù)團(tuán)隊(duì)使用,旨在提高數(shù)據(jù)分析的質(zhì)量并縮短數(shù)據(jù)分析的周期,簡(jiǎn)而言之,就是提供一整套工具和方法論,讓數(shù)據(jù)應(yīng)用的開發(fā)和管理更加高效。但Gartner也指出,DataOps雖然可以降低數(shù)據(jù)分析的門檻,但并不會(huì)讓數(shù)據(jù)分析變成一項(xiàng)簡(jiǎn)單的工作,與DevOps的落地一樣,實(shí)施成功的數(shù)據(jù)項(xiàng)目也需要做大量的工作,比如深入了解數(shù)據(jù)和業(yè)務(wù)的關(guān)系、樹立良好的數(shù)據(jù)使用規(guī)范等。

圖:Gartner對(duì)DataOps的定位(來(lái)源:Gartner官方)

就像前文我們所提到的,DataOps的誕生并不是偶然,IBM商業(yè)價(jià)值研究院曾有過(guò)一份研究:數(shù)據(jù)科學(xué)家往往需要花費(fèi)大量時(shí)間準(zhǔn)備、驗(yàn)證和清理數(shù)據(jù)源,然后才能使用這些數(shù)據(jù)源訓(xùn)練數(shù)據(jù)模型,因此他們只能用少得可憐的一點(diǎn)點(diǎn)時(shí)間,去設(shè)計(jì)用于將數(shù)據(jù)轉(zhuǎn)化為價(jià)值的AI模型。據(jù)估計(jì),AI部署過(guò)程中有80%的工作都用于準(zhǔn)備數(shù)據(jù)。

如果從第一性原理出發(fā),你會(huì)發(fā)現(xiàn)DataOps與數(shù)據(jù)中臺(tái)需要解決的問(wèn)題其實(shí)是相類似的,它們都希望能更快、更好地實(shí)現(xiàn)數(shù)據(jù)價(jià)值,實(shí)現(xiàn)數(shù)字化運(yùn)營(yíng),但兩者側(cè)重點(diǎn)卻有所不同。

前者強(qiáng)調(diào)的是數(shù)據(jù)應(yīng)用的開發(fā)和運(yùn)維效率提升,類似于DevOps解放了開發(fā)人員的生產(chǎn)力,后者強(qiáng)調(diào)的是數(shù)據(jù)統(tǒng)一管理和避免重復(fù)造輪子,是對(duì)數(shù)據(jù)能力的抽象、共享以及復(fù)用。

上升到產(chǎn)品原教旨主義層面,如果說(shuō)數(shù)據(jù)中臺(tái)強(qiáng)調(diào)的是戰(zhàn)略層次的布局,即必須有一個(gè)中臺(tái)來(lái)承擔(dān)所有數(shù)據(jù)能力的管理和使用,那么,DataOps強(qiáng)調(diào)的就是戰(zhàn)術(shù)維度的優(yōu)化,即如何讓各個(gè)開發(fā)和使用實(shí)際數(shù)據(jù)應(yīng)用的人員更加高效,換句話說(shuō),數(shù)據(jù)中臺(tái)只是粗線條地描述了最終目標(biāo),而DataOps提供了一條更加精細(xì)化的最佳路徑。

圖:DataOps架構(gòu)(來(lái)源:Diving into DataOps: The Underbelly of Modern Data Pipelines韋恩·??松?/em>

當(dāng)然,這和DataOps的架構(gòu)有關(guān)。按照技術(shù)層面的解釋,DataOps重點(diǎn)放在了數(shù)據(jù)中心,為用戶提供了一系列數(shù)據(jù)工具,并通過(guò)人員協(xié)作與流程管控的模式,實(shí)現(xiàn)持續(xù)的數(shù)據(jù)科學(xué)模型部署,這可以通俗理解成“編排”,同時(shí)也是DataOps核心靈魂所在,因?yàn)橐粋€(gè)好的編排工具意味著它能協(xié)調(diào)數(shù)據(jù)開發(fā)項(xiàng)目的4個(gè)組成部分,包括代碼,數(shù)據(jù),技術(shù)和基礎(chǔ)架構(gòu)。

因此,在云智能時(shí)代,DataOps是面向5G多云復(fù)雜部署數(shù)據(jù)處理的有效手段,也極有可能成為數(shù)據(jù)中臺(tái)的發(fā)展拐點(diǎn)。

03、追求DataOps,需要回歸第一性原理

DataOps的優(yōu)勢(shì)顯而易見,比如它能改善數(shù)據(jù)管理者和數(shù)據(jù)消費(fèi)者角色之間的溝通,讓雙方處于同一頁(yè)面上;整合整個(gè)企業(yè)的數(shù)據(jù)流,并通過(guò)數(shù)據(jù)管道自動(dòng)化降低運(yùn)營(yíng)成本;通過(guò)良好的監(jiān)控,保證可靠性和可觀察性。

滴普科技方面認(rèn)為,“擁有更強(qiáng)大的數(shù)據(jù)管理能力,是面向未來(lái)的架構(gòu)關(guān)鍵特征。以當(dāng)下主流的分析型數(shù)據(jù)庫(kù)湖倉(cāng)一體為例,想要完成湖倉(cāng)一體的最終建設(shè),則必然要經(jīng)歷以下三個(gè)階段:數(shù)據(jù)入湖——數(shù)據(jù)治理和質(zhì)量——DataOps?!?/p>

圖:DataOps開發(fā)流程(來(lái)源:滴普科技官方)

但這并不意味著它是一副萬(wàn)能藥。

就像前文所述,雖然DataOps可以降低數(shù)據(jù)分析的門檻,但不會(huì)讓數(shù)據(jù)分析變成一項(xiàng)簡(jiǎn)單的工作。與DevOps相類似,DataOps的使用與發(fā)展,也是一個(gè)需要有正確工具和正確思維加持的持續(xù)過(guò)程,它的目標(biāo)是用正確的方式實(shí)現(xiàn)數(shù)據(jù)智能項(xiàng)目落地,解放數(shù)據(jù)的功能屬性,形成生產(chǎn)力。

在數(shù)字化浪潮里,企業(yè)數(shù)據(jù)平臺(tái)要想成功落地,是雙向選擇和奔赴的過(guò)程,就像種一棵樹,你不能頭天種下了,第二天就希望它能變成木材,而是觀察它的底部究竟在不在生長(zhǎng)。

在2018年IBM和Forrester Consulting聯(lián)合發(fā)布的報(bào)告《數(shù)字化轉(zhuǎn)型的深層實(shí)質(zhì)》中,數(shù)字化轉(zhuǎn)型的任務(wù)由3個(gè)主要系統(tǒng)承擔(dān):SoE(System of Engagement,行動(dòng)系統(tǒng))、SoI(System of Insight,洞察系統(tǒng))以及SoR(System of Record,記錄系統(tǒng))。SoR主要把系統(tǒng)需要的數(shù)據(jù)記錄下來(lái),SoI負(fù)責(zé)從數(shù)據(jù)中發(fā)現(xiàn)洞見,而SoE負(fù)責(zé)根據(jù)洞見來(lái)引導(dǎo)行動(dòng),雖然數(shù)字化轉(zhuǎn)型的模型可能有多種表現(xiàn)方式,但你會(huì)發(fā)現(xiàn),它的主要功能和建設(shè)內(nèi)容還是繞不開這三個(gè)方面。

延續(xù)到客戶視角來(lái)看,他們往往希望廠商能提供完整數(shù)據(jù)平臺(tái)的搭建以及端到端的技術(shù)能力,并提供相關(guān)行業(yè)的知識(shí)和洞察,但這通常會(huì)牽涉很多賽道,從數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理、數(shù)據(jù)整合、到數(shù)據(jù)治理、人工智能、機(jī)器學(xué)習(xí),再到最終的BI,而這些賽道的技術(shù)差異是很大的,所以對(duì)于數(shù)據(jù)智能服務(wù)玩家來(lái)說(shuō),需要用第一性原理思考問(wèn)題:有所為,有所不為。

本文為轉(zhuǎn)載內(nèi)容,授權(quán)事宜請(qǐng)聯(lián)系原著作權(quán)人。

評(píng)論

暫無(wú)評(píng)論哦,快來(lái)評(píng)價(jià)一下吧!

下載界面新聞

微信公眾號(hào)

微博

為什么說(shuō)DataOps是數(shù)據(jù)中臺(tái)的拐點(diǎn)?

在上數(shù)據(jù)中臺(tái)前,你需要搞明白什么是DataOps。

文|新眸企服組 桑明強(qiáng)

要說(shuō)最近企服圈什么最被關(guān)注,SaaS和數(shù)據(jù)中臺(tái)想必是大多數(shù)人心里的答案。

前者商業(yè)模式已經(jīng)被證明,Salesforce就是最好的例子,后者從剛出現(xiàn)時(shí)的火熱,到被質(zhì)疑跌落谷底只用了短短3、4年時(shí)間。這讓很多人好奇,為什么在“數(shù)據(jù)價(jià)值已經(jīng)被證明”和“企業(yè)數(shù)字化轉(zhuǎn)型也成了多數(shù)CEO共識(shí)”的當(dāng)下,大家對(duì)于數(shù)據(jù)中臺(tái)的看法還會(huì)呈現(xiàn)兩極分化,看好的人堅(jiān)定認(rèn)為數(shù)據(jù)中臺(tái)是企業(yè)數(shù)字化轉(zhuǎn)型的“解藥”,看衰的人規(guī)勸同行不要上中臺(tái),它是雞肋,是“毒藥”。

歸根結(jié)底,是因?yàn)闃I(yè)界對(duì)一個(gè)關(guān)鍵問(wèn)題的看法還沒有達(dá)成一致,即數(shù)據(jù)中臺(tái)究竟是不是支撐企業(yè)數(shù)字化轉(zhuǎn)型的最合理的數(shù)據(jù)基礎(chǔ)架構(gòu)?翻譯一下就是,數(shù)據(jù)中臺(tái)能不能滿足企業(yè)數(shù)字化轉(zhuǎn)型的最大公約數(shù),或者說(shuō)媒體老師們口中的最優(yōu)解。

數(shù)據(jù)中臺(tái)是一個(gè)“新物種”,但它的新僅僅停留在國(guó)內(nèi)廠商的造詞能力上,它誕生于國(guó)內(nèi),不懂技術(shù)的人容易被“中臺(tái)”二字帶偏,誤以為它是一副萬(wàn)能藥,在硅谷,其實(shí)也有一些知名獨(dú)角獸公司有著和數(shù)據(jù)中臺(tái)架構(gòu)相類似的數(shù)據(jù)基礎(chǔ)架構(gòu),但他們習(xí)慣把它叫作數(shù)據(jù)平臺(tái),而不是數(shù)據(jù)中臺(tái)。

這里我們需要明確的是,所謂的“數(shù)據(jù)中臺(tái)”,它只是一種叫法,就像“人工智能”一樣,具體定義和內(nèi)容往往需要根據(jù)要實(shí)現(xiàn)的目標(biāo)和要解決的問(wèn)題來(lái)確定。以Twitter為例,公司從2011年的300人,發(fā)展到2014年的4000人,大數(shù)據(jù)平臺(tái)從80臺(tái)服務(wù)器的單純Hadoop集群,擴(kuò)展到8000臺(tái)服務(wù)器的核心數(shù)據(jù)處理平臺(tái),打從在很小規(guī)模時(shí),Twitter就是一家數(shù)據(jù)驅(qū)動(dòng)型的公司,而它管理的底層支撐,是一個(gè)全局共享的大數(shù)據(jù)平臺(tái)。

圖:Twitter大數(shù)據(jù)平臺(tái)架構(gòu)(來(lái)源:《云原生數(shù)據(jù)中臺(tái):架構(gòu)、方法論與實(shí)踐》)

這種平臺(tái)型架構(gòu)的好處是,Twitter在業(yè)務(wù)和組織快速擴(kuò)張時(shí),能做到統(tǒng)一數(shù)據(jù)規(guī)范、消除數(shù)據(jù)和應(yīng)用孤島。回到國(guó)內(nèi),多數(shù)企業(yè)在搭建數(shù)字化信息系統(tǒng)時(shí),也就是在頂層設(shè)計(jì)的初期,并沒有做到面向未來(lái),所以一旦組織擴(kuò)張速度過(guò)快,數(shù)據(jù)層面的浪費(fèi)和組織層面的冗余也就隨之而來(lái),在這種情況下,企業(yè)往往盲目寄托于上數(shù)據(jù)中臺(tái),把包袱丟給數(shù)據(jù)智能服務(wù)提供商,但卻忽略了自身的癥結(jié)關(guān)鍵所在,所以難免越做越錯(cuò)。

一般來(lái)說(shuō),數(shù)據(jù)智能有3個(gè)發(fā)展階段:大數(shù)據(jù)平臺(tái)建設(shè)階段、數(shù)據(jù)管理及應(yīng)用階段和數(shù)據(jù)能力中臺(tái)化階段。就目前來(lái)看,大部分企業(yè)的數(shù)據(jù)平臺(tái)建設(shè)已經(jīng)進(jìn)行到一、二階段,但要順利過(guò)渡到第三階段,就繞不開一個(gè)關(guān)鍵方法論的幫助——DataOps(數(shù)據(jù)運(yùn)維),值得一提的是,它是很多硅谷公司在解決第三階段問(wèn)題時(shí)普遍采用的方法論。

DataOps由DevOps概念衍生而來(lái),是基于元數(shù)據(jù)開發(fā)和部署數(shù)據(jù)分析應(yīng)用的一種靈活敏捷的方法?!八寯?shù)據(jù)開發(fā)過(guò)程變得敏捷可控,這是眼下很多公司最頭疼的事。對(duì)于大多數(shù)企業(yè)來(lái)說(shuō),數(shù)據(jù)在調(diào)整過(guò)程中容易缺少版本管理、缺少持續(xù)集成,甚至沒有測(cè)試環(huán)節(jié),整個(gè)過(guò)程都要靠人去做這件事情,他們就像是數(shù)據(jù)管道工,更別談最終形成你想要的AI模型?!钡纹湛萍糉astData產(chǎn)品管理部總經(jīng)理曾這樣談到,無(wú)獨(dú)有偶,《數(shù)字化轉(zhuǎn)型架構(gòu):方法論和云原生》一書中也明確提及,云原生應(yīng)用平臺(tái)的發(fā)展將經(jīng)歷DevOps—DataOps—AIOps的演進(jìn)路徑。為此,這篇文章我們將主要探討:

1、為什么有的數(shù)據(jù)中臺(tái)不能成功?

2、突然崛起的DataOps究竟是什么?

3、追求DataOps,為什么要回歸第一性原理?

01、為什么有的數(shù)據(jù)中臺(tái)不能成功?

數(shù)據(jù)中臺(tái)成熟后,會(huì)不會(huì)變成類似數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖一樣的數(shù)據(jù)基礎(chǔ)架構(gòu),可能是大多數(shù)人最為關(guān)心的問(wèn)題,但這對(duì)于數(shù)據(jù)中臺(tái)的發(fā)展來(lái)說(shuō),其實(shí)是一件好事,原因在于它把問(wèn)題收窄了,回歸到數(shù)據(jù)中臺(tái)的產(chǎn)品本質(zhì)上,也就是基本面問(wèn)題。

和以往技術(shù)中間件不同的是,雖然數(shù)據(jù)中臺(tái)也承接底層數(shù)據(jù)和上層業(yè)務(wù)的中間層,但它的價(jià)值更多地體現(xiàn)在與企業(yè)業(yè)務(wù)結(jié)合的能力矩陣維度,而不是簡(jiǎn)單地做一些數(shù)據(jù)標(biāo)準(zhǔn)化和報(bào)表工具。所以這里就涉及到能用和好用的問(wèn)題,同時(shí)也是當(dāng)下的主流問(wèn)題:做一個(gè)能用的數(shù)據(jù)中臺(tái)不難,但要做到好用甚至說(shuō)持續(xù)好用,非常難。

在滴普科技看來(lái),“這和國(guó)內(nèi)企業(yè)數(shù)字化的進(jìn)程有關(guān),很多企業(yè)本身就有自己的一些信息系統(tǒng),大多數(shù)在數(shù)字化升級(jí)時(shí),都是基于現(xiàn)有基礎(chǔ)改造,而不是從0到1摸底建設(shè),這對(duì)于數(shù)據(jù)智能服務(wù)商挑戰(zhàn)極高?!北澈蟮脑蚝芎?jiǎn)單,一般來(lái)說(shuō),傳統(tǒng)信息系統(tǒng)往往建立在多個(gè)數(shù)據(jù)倉(cāng)庫(kù)之上,而數(shù)據(jù)中臺(tái)會(huì)使用數(shù)據(jù)湖來(lái)存儲(chǔ),但根本問(wèn)題是,分割的數(shù)據(jù)層無(wú)法對(duì)核心業(yè)務(wù)流程進(jìn)行全局還原和支持,也無(wú)法實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)的全局決策和產(chǎn)品研發(fā)。

前文提到的Twitter就是最好的例子,在2011年以前,Twitter開發(fā)和發(fā)布產(chǎn)品的流程非常冗長(zhǎng),產(chǎn)品經(jīng)理需要到各個(gè)部門調(diào)研可以使用的數(shù)據(jù),并協(xié)調(diào)數(shù)據(jù)的生產(chǎn)化問(wèn)題。在數(shù)據(jù)平臺(tái)推行后,Twitter整個(gè)產(chǎn)品的開發(fā)和迭代流程從以月計(jì)改為以周計(jì),活躍用戶數(shù)也從2011年不到1億,增長(zhǎng)到2014年接近3億。在當(dāng)時(shí)Twitter大數(shù)據(jù)項(xiàng)目負(fù)責(zé)人看來(lái),“這是架構(gòu)上的勝利?!?/p>

同理到現(xiàn)在的環(huán)境也是一樣,隨著自助服務(wù)分析和機(jī)器學(xué)習(xí)的迅速發(fā)展,公司里的管道數(shù)量也隨著數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家、數(shù)據(jù)工程師以及數(shù)據(jù)使用者業(yè)務(wù)部門增多而增多,問(wèn)題的關(guān)鍵是,幾乎每一個(gè)都需要專門的數(shù)據(jù)集和數(shù)據(jù)訪問(wèn)權(quán)限才能產(chǎn)生內(nèi)容,而協(xié)調(diào)這些工具、技術(shù)和人員是一項(xiàng)巨大且耗費(fèi)精力的工作,特別是在規(guī)模龐大的開發(fā)團(tuán)隊(duì)里,這也解釋了為什么DataOps會(huì)發(fā)展起來(lái)。

溯源企業(yè)數(shù)據(jù)平臺(tái)項(xiàng)目的失敗案例,你會(huì)發(fā)現(xiàn)它們往往都有一些共性,比如初期啟動(dòng)難,得不到業(yè)務(wù)支持、很難把數(shù)據(jù)源規(guī)?;?,缺少對(duì)復(fù)雜源數(shù)據(jù)系統(tǒng)的管理手段、數(shù)據(jù)平臺(tái)項(xiàng)目跟不上企業(yè)創(chuàng)新要求以及開發(fā)和運(yùn)營(yíng)成本極高,無(wú)法正向反哺業(yè)務(wù)。

以往的經(jīng)驗(yàn)告訴我們,很多時(shí)候,一個(gè)高速發(fā)展的業(yè)務(wù)往往是因?yàn)樵缙诩軜?gòu)設(shè)計(jì)的問(wèn)題,變得難以迭代。所以從這個(gè)角度看,并不是數(shù)據(jù)平臺(tái)的理念過(guò)時(shí)了,而是數(shù)據(jù)中臺(tái)的架構(gòu)過(guò)時(shí)了。因?yàn)槌舜_定對(duì)于業(yè)務(wù)的價(jià)值外,建設(shè)數(shù)據(jù)平臺(tái)的根本性問(wèn)題是技術(shù)架構(gòu)的選擇和設(shè)計(jì),但這相當(dāng)于給一架高速行駛的列車更換引擎,難度系數(shù)很高。

02、突然崛起的DataOps究竟是什么?

前文我們提到,DataOps是硅谷公司在解決第三階段問(wèn)題時(shí)普遍采用的方法論,同時(shí)也是數(shù)據(jù)中臺(tái)建設(shè)必須參考的一個(gè)方法論,這在一定程度上證明了DataOps的可行性。眾所周知,數(shù)據(jù)智能要解決的三大問(wèn)題是數(shù)據(jù)處理、模型搭建及交付,想要實(shí)現(xiàn)智能工程化或者大規(guī)??沙掷m(xù)的數(shù)據(jù)智能交付,現(xiàn)在業(yè)內(nèi)公認(rèn)的模式運(yùn)維解法是ModelOps,開發(fā)運(yùn)維解法是DevOps,至于數(shù)據(jù)運(yùn)維,就是DataOps。

在2018年Gartner發(fā)布的《數(shù)據(jù)管理技術(shù)成熟度曲線》報(bào)告中,DataOps概念被首次提出。

維基百科對(duì)DataOps的定義是一種面向流程的自動(dòng)化方法,由分析和數(shù)據(jù)團(tuán)隊(duì)使用,旨在提高數(shù)據(jù)分析的質(zhì)量并縮短數(shù)據(jù)分析的周期,簡(jiǎn)而言之,就是提供一整套工具和方法論,讓數(shù)據(jù)應(yīng)用的開發(fā)和管理更加高效。但Gartner也指出,DataOps雖然可以降低數(shù)據(jù)分析的門檻,但并不會(huì)讓數(shù)據(jù)分析變成一項(xiàng)簡(jiǎn)單的工作,與DevOps的落地一樣,實(shí)施成功的數(shù)據(jù)項(xiàng)目也需要做大量的工作,比如深入了解數(shù)據(jù)和業(yè)務(wù)的關(guān)系、樹立良好的數(shù)據(jù)使用規(guī)范等。

圖:Gartner對(duì)DataOps的定位(來(lái)源:Gartner官方)

就像前文我們所提到的,DataOps的誕生并不是偶然,IBM商業(yè)價(jià)值研究院曾有過(guò)一份研究:數(shù)據(jù)科學(xué)家往往需要花費(fèi)大量時(shí)間準(zhǔn)備、驗(yàn)證和清理數(shù)據(jù)源,然后才能使用這些數(shù)據(jù)源訓(xùn)練數(shù)據(jù)模型,因此他們只能用少得可憐的一點(diǎn)點(diǎn)時(shí)間,去設(shè)計(jì)用于將數(shù)據(jù)轉(zhuǎn)化為價(jià)值的AI模型。據(jù)估計(jì),AI部署過(guò)程中有80%的工作都用于準(zhǔn)備數(shù)據(jù)。

如果從第一性原理出發(fā),你會(huì)發(fā)現(xiàn)DataOps與數(shù)據(jù)中臺(tái)需要解決的問(wèn)題其實(shí)是相類似的,它們都希望能更快、更好地實(shí)現(xiàn)數(shù)據(jù)價(jià)值,實(shí)現(xiàn)數(shù)字化運(yùn)營(yíng),但兩者側(cè)重點(diǎn)卻有所不同。

前者強(qiáng)調(diào)的是數(shù)據(jù)應(yīng)用的開發(fā)和運(yùn)維效率提升,類似于DevOps解放了開發(fā)人員的生產(chǎn)力,后者強(qiáng)調(diào)的是數(shù)據(jù)統(tǒng)一管理和避免重復(fù)造輪子,是對(duì)數(shù)據(jù)能力的抽象、共享以及復(fù)用。

上升到產(chǎn)品原教旨主義層面,如果說(shuō)數(shù)據(jù)中臺(tái)強(qiáng)調(diào)的是戰(zhàn)略層次的布局,即必須有一個(gè)中臺(tái)來(lái)承擔(dān)所有數(shù)據(jù)能力的管理和使用,那么,DataOps強(qiáng)調(diào)的就是戰(zhàn)術(shù)維度的優(yōu)化,即如何讓各個(gè)開發(fā)和使用實(shí)際數(shù)據(jù)應(yīng)用的人員更加高效,換句話說(shuō),數(shù)據(jù)中臺(tái)只是粗線條地描述了最終目標(biāo),而DataOps提供了一條更加精細(xì)化的最佳路徑。

圖:DataOps架構(gòu)(來(lái)源:Diving into DataOps: The Underbelly of Modern Data Pipelines韋恩·埃克森)

當(dāng)然,這和DataOps的架構(gòu)有關(guān)。按照技術(shù)層面的解釋,DataOps重點(diǎn)放在了數(shù)據(jù)中心,為用戶提供了一系列數(shù)據(jù)工具,并通過(guò)人員協(xié)作與流程管控的模式,實(shí)現(xiàn)持續(xù)的數(shù)據(jù)科學(xué)模型部署,這可以通俗理解成“編排”,同時(shí)也是DataOps核心靈魂所在,因?yàn)橐粋€(gè)好的編排工具意味著它能協(xié)調(diào)數(shù)據(jù)開發(fā)項(xiàng)目的4個(gè)組成部分,包括代碼,數(shù)據(jù),技術(shù)和基礎(chǔ)架構(gòu)。

因此,在云智能時(shí)代,DataOps是面向5G多云復(fù)雜部署數(shù)據(jù)處理的有效手段,也極有可能成為數(shù)據(jù)中臺(tái)的發(fā)展拐點(diǎn)。

03、追求DataOps,需要回歸第一性原理

DataOps的優(yōu)勢(shì)顯而易見,比如它能改善數(shù)據(jù)管理者和數(shù)據(jù)消費(fèi)者角色之間的溝通,讓雙方處于同一頁(yè)面上;整合整個(gè)企業(yè)的數(shù)據(jù)流,并通過(guò)數(shù)據(jù)管道自動(dòng)化降低運(yùn)營(yíng)成本;通過(guò)良好的監(jiān)控,保證可靠性和可觀察性。

滴普科技方面認(rèn)為,“擁有更強(qiáng)大的數(shù)據(jù)管理能力,是面向未來(lái)的架構(gòu)關(guān)鍵特征。以當(dāng)下主流的分析型數(shù)據(jù)庫(kù)湖倉(cāng)一體為例,想要完成湖倉(cāng)一體的最終建設(shè),則必然要經(jīng)歷以下三個(gè)階段:數(shù)據(jù)入湖——數(shù)據(jù)治理和質(zhì)量——DataOps?!?/p>

圖:DataOps開發(fā)流程(來(lái)源:滴普科技官方)

但這并不意味著它是一副萬(wàn)能藥。

就像前文所述,雖然DataOps可以降低數(shù)據(jù)分析的門檻,但不會(huì)讓數(shù)據(jù)分析變成一項(xiàng)簡(jiǎn)單的工作。與DevOps相類似,DataOps的使用與發(fā)展,也是一個(gè)需要有正確工具和正確思維加持的持續(xù)過(guò)程,它的目標(biāo)是用正確的方式實(shí)現(xiàn)數(shù)據(jù)智能項(xiàng)目落地,解放數(shù)據(jù)的功能屬性,形成生產(chǎn)力。

在數(shù)字化浪潮里,企業(yè)數(shù)據(jù)平臺(tái)要想成功落地,是雙向選擇和奔赴的過(guò)程,就像種一棵樹,你不能頭天種下了,第二天就希望它能變成木材,而是觀察它的底部究竟在不在生長(zhǎng)。

在2018年IBM和Forrester Consulting聯(lián)合發(fā)布的報(bào)告《數(shù)字化轉(zhuǎn)型的深層實(shí)質(zhì)》中,數(shù)字化轉(zhuǎn)型的任務(wù)由3個(gè)主要系統(tǒng)承擔(dān):SoE(System of Engagement,行動(dòng)系統(tǒng))、SoI(System of Insight,洞察系統(tǒng))以及SoR(System of Record,記錄系統(tǒng))。SoR主要把系統(tǒng)需要的數(shù)據(jù)記錄下來(lái),SoI負(fù)責(zé)從數(shù)據(jù)中發(fā)現(xiàn)洞見,而SoE負(fù)責(zé)根據(jù)洞見來(lái)引導(dǎo)行動(dòng),雖然數(shù)字化轉(zhuǎn)型的模型可能有多種表現(xiàn)方式,但你會(huì)發(fā)現(xiàn),它的主要功能和建設(shè)內(nèi)容還是繞不開這三個(gè)方面。

延續(xù)到客戶視角來(lái)看,他們往往希望廠商能提供完整數(shù)據(jù)平臺(tái)的搭建以及端到端的技術(shù)能力,并提供相關(guān)行業(yè)的知識(shí)和洞察,但這通常會(huì)牽涉很多賽道,從數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理、數(shù)據(jù)整合、到數(shù)據(jù)治理、人工智能、機(jī)器學(xué)習(xí),再到最終的BI,而這些賽道的技術(shù)差異是很大的,所以對(duì)于數(shù)據(jù)智能服務(wù)玩家來(lái)說(shuō),需要用第一性原理思考問(wèn)題:有所為,有所不為。

本文為轉(zhuǎn)載內(nèi)容,授權(quán)事宜請(qǐng)聯(lián)系原著作權(quán)人。