各位朋友，上午好。我是周衛(wèi)林，Aloudata 的創(chuàng)始人和 CEO。今天我演講的主題是《NoETL 開(kāi)啟自動(dòng)化數(shù)據(jù)管理新時(shí)代》。在這個(gè)主題中，有兩個(gè)大家很熟悉的詞：ETL 和數(shù)據(jù)管理。但同時(shí)，也有兩個(gè)不太熟悉的詞：NoETL 和自動(dòng)化數(shù)據(jù)管理。我們是否在創(chuàng)造一種新的概念？今天我將回答這個(gè)問(wèn)題，并通過(guò)回答這個(gè)問(wèn)題來(lái)解釋我們?yōu)槭裁匆獎(jiǎng)?chuàng)立 Aloudata 這家公司，以及我們的定位是什么。

我在數(shù)據(jù)領(lǐng)域工作了 21 年，專注于大數(shù)據(jù)領(lǐng)域的學(xué)習(xí)、理解和問(wèn)題解決。其中，我在阿里和螞蟻集團(tuán)工作了 15 年，在阿里巴巴時(shí)期擔(dān)任數(shù)據(jù)倉(cāng)庫(kù)架構(gòu)師 5 年多，在螞蟻集團(tuán)數(shù)據(jù)平臺(tái)部任負(fù)責(zé)人 9 年多。我對(duì)這個(gè)行業(yè)有比較深入的了解和實(shí)踐。

首先，我想從業(yè)務(wù)的角度來(lái)談?wù)剶?shù)據(jù)化運(yùn)營(yíng)和數(shù)字化轉(zhuǎn)型時(shí)公司面臨的典型應(yīng)用場(chǎng)景和挑戰(zhàn)。每家公司都會(huì)通過(guò)指標(biāo)進(jìn)行經(jīng)營(yíng)管理，比如公司層面的 KPI 指標(biāo)，如收入。這些指標(biāo)不僅要監(jiān)控當(dāng)前進(jìn)展，還要與同期值、與目標(biāo)值比較，并且要細(xì)化到不同部門，比如線上銷售部門和線下銷售部門。

這些指標(biāo)一旦細(xì)化到部門，就會(huì)進(jìn)一步拆解成更具體的指標(biāo)。然后，這些指標(biāo)會(huì)與不同團(tuán)隊(duì)綁定，例如渠道運(yùn)營(yíng)團(tuán)隊(duì)、商家運(yùn)營(yíng)團(tuán)隊(duì)、產(chǎn)品運(yùn)營(yíng)團(tuán)隊(duì)和會(huì)員運(yùn)營(yíng)團(tuán)隊(duì)。這樣，團(tuán)隊(duì)可以通過(guò) BI 平臺(tái)、AB 實(shí)驗(yàn)平臺(tái)等找到業(yè)務(wù)問(wèn)題和優(yōu)化機(jī)會(huì)，并將這些機(jī)會(huì)通過(guò)不同的運(yùn)營(yíng)工作臺(tái)、營(yíng)銷投放平臺(tái)等應(yīng)用到業(yè)務(wù)系統(tǒng)中，從而推動(dòng)業(yè)務(wù)的閉環(huán)發(fā)展。

總的來(lái)說(shuō)，通過(guò)管理指標(biāo)的方式，我們可以有效地管理業(yè)務(wù)。通過(guò)指標(biāo)的上卷和下鉆的能力，和跨多主體的指標(biāo)分析等數(shù)據(jù)協(xié)同，可以實(shí)現(xiàn)多團(tuán)隊(duì)多組織的組織協(xié)同。

其次，我想從組織的角度來(lái)談?wù)勂髽I(yè)數(shù)據(jù)化轉(zhuǎn)型對(duì)組織能力結(jié)構(gòu)的演化，我分三個(gè)階段進(jìn)行介紹。

當(dāng)企業(yè)處于信息化建設(shè)的成熟期，通常會(huì)在 IT 技術(shù)部?jī)?nèi)部分出兩層：一層是面向業(yè)務(wù)場(chǎng)景的業(yè)務(wù)技術(shù)團(tuán)隊(duì)，例如面向商家事業(yè)部的商家技術(shù)部；另一層面向技術(shù)基礎(chǔ)設(shè)施的平臺(tái)技術(shù)團(tuán)隊(duì)，負(fù)責(zé)數(shù)據(jù)中心的規(guī)劃、硬件設(shè)備的采購(gòu)和平臺(tái)的運(yùn)維監(jiān)控等工作。

從信息化往數(shù)據(jù)化發(fā)展，在數(shù)據(jù)化管理的早期階段，組織結(jié)構(gòu)中會(huì)增加一條專門負(fù)責(zé) BI 的線，支持 BI 的數(shù)據(jù)技術(shù)團(tuán)隊(duì)可能會(huì)外包給 DT（Data Technolog） 供應(yīng)商。

隨著企業(yè)進(jìn)入數(shù)智化運(yùn)營(yíng)的成熟期或中后期，不僅業(yè)務(wù)團(tuán)隊(duì)內(nèi)部會(huì)有分析師、數(shù)據(jù)科學(xué)家和業(yè)務(wù)算法專家，技術(shù)部?jī)?nèi)部也會(huì)有專門的數(shù)據(jù)團(tuán)隊(duì)，甚至在業(yè)務(wù)技術(shù)團(tuán)隊(duì)里部也會(huì)有數(shù)據(jù)和數(shù)據(jù)工程師，形成一個(gè)面向業(yè)務(wù)場(chǎng)景的技術(shù)特種部隊(duì)。這種組織體系結(jié)構(gòu)是許多行業(yè)頭部公司和互聯(lián)網(wǎng)公司的常態(tài)。

通過(guò)上面從業(yè)務(wù)和組織兩個(gè)角度的介紹，我們可以進(jìn)一步分析數(shù)智化運(yùn)營(yíng)對(duì)數(shù)據(jù)管理的挑戰(zhàn)。核心問(wèn)題是隨著場(chǎng)景的增加，數(shù)據(jù)鏈路也在增長(zhǎng)，導(dǎo)致數(shù)據(jù)管道的復(fù)雜性增加。就像上面介紹的那樣，由于越來(lái)越多的組織參與數(shù)據(jù)技術(shù)，這很容易導(dǎo)致數(shù)據(jù)管道的煙囪化，從而形成更為復(fù)雜的數(shù)據(jù)體系結(jié)構(gòu)，進(jìn)而導(dǎo)致數(shù)據(jù)交付效率和質(zhì)量的雙下降。解決這些問(wèn)題是當(dāng)前數(shù)據(jù)管理面臨的主要挑戰(zhàn)。

首先，我們面臨的挑戰(zhàn)之一是數(shù)據(jù)可用性的風(fēng)險(xiǎn)。數(shù)據(jù)可用性的風(fēng)險(xiǎn)主要是數(shù)據(jù)產(chǎn)出時(shí)效和數(shù)據(jù)質(zhì)量問(wèn)題。數(shù)據(jù)時(shí)效指的是數(shù)據(jù)鏈路沒(méi)有延遲，可以按時(shí)交付，數(shù)據(jù)質(zhì)量主要指的是數(shù)據(jù)的準(zhǔn)確性和完整性。

在數(shù)據(jù)時(shí)效運(yùn)維保障上有一個(gè)重要的概念是“任務(wù)基線”運(yùn)維保障。當(dāng)數(shù)據(jù)處理鏈路依賴加深且鏈路變長(zhǎng)時(shí)，任務(wù)容易出現(xiàn)破線，當(dāng)任務(wù)一旦破線且破線次數(shù)越來(lái)越多，定位和解決問(wèn)題的難度也越來(lái)越大。例如，如果公司的管理層看板需要在早上八點(diǎn)準(zhǔn)時(shí)更新，但由于上游任務(wù)的錯(cuò)誤或延遲，數(shù)據(jù)無(wú)法及時(shí)提供，這就需要進(jìn)行鏈路治理。在這種情況下，可能需要協(xié)調(diào)大量人員來(lái)解決問(wèn)題，在大型金融機(jī)構(gòu)，這種情況可能涉及上百人，需要拉群進(jìn)行鏈路治理。這種做法的效果往往越來(lái)越差，因?yàn)榭咳斯ぴ趲兹f(wàn)、幾十萬(wàn)的任務(wù)里進(jìn)行優(yōu)化的代價(jià)和難度都非常大。這就形成了一個(gè)困境：如何有效保障數(shù)據(jù)的可用性。

為了解決這個(gè)問(wèn)題，我們可以將任務(wù)分為兩個(gè)階段：開(kāi)發(fā)態(tài)和運(yùn)行態(tài)。在從開(kāi)發(fā)態(tài)變更到運(yùn)行態(tài)的過(guò)程中，很重要的是把基線管控列入發(fā)布管控，事前階段確?；€設(shè)置的合理性至關(guān)重要，比如如果沒(méi)有經(jīng)驗(yàn)的人直接設(shè)定了任務(wù)的下游基線，比如說(shuō)八點(diǎn)鐘要完成，但實(shí)際上他們并沒(méi)有客觀地評(píng)估這個(gè)基線是否可行，一旦上線可能就會(huì)出現(xiàn)延遲故障，就會(huì)觸發(fā)報(bào)警，這就是一個(gè)典型的問(wèn)題。

另外，在事中階段，可能沒(méi)有設(shè)置預(yù)警和告警規(guī)則，或者當(dāng)需要告警時(shí)聯(lián)系不上相關(guān)責(zé)任人，所以這種情況就是典型的基線運(yùn)營(yíng)巡檢需要處理的問(wèn)題，一旦出現(xiàn)問(wèn)題后，需要進(jìn)行復(fù)盤，找出問(wèn)題的根本原因。

這種機(jī)制可以幫助解決一部分?jǐn)?shù)據(jù)時(shí)效性問(wèn)題，但是造成時(shí)效性問(wèn)題的還有可能是數(shù)據(jù)質(zhì)量問(wèn)題，比如說(shuō)，上游的任務(wù)出錯(cuò)導(dǎo)致下游受影響，或者任務(wù)雖然正常運(yùn)行，但產(chǎn)出的數(shù)據(jù)是錯(cuò)誤的。這種情況下，問(wèn)題發(fā)現(xiàn)得太晚，需要回溯上游數(shù)據(jù)，這會(huì)影響下游的任務(wù)執(zhí)行，造成下游產(chǎn)出數(shù)據(jù)延遲。

要控制數(shù)據(jù)質(zhì)量問(wèn)題造成的數(shù)據(jù)可用性影響，涉及到數(shù)據(jù)質(zhì)量控制（DQC）、數(shù)據(jù)任務(wù)調(diào)度配置、數(shù)據(jù)鏈路異常恢復(fù)和數(shù)據(jù)影響面評(píng)估等復(fù)雜問(wèn)題，又需要一個(gè)更大更完整的數(shù)據(jù)可用性保障體系，需要制定一個(gè)數(shù)據(jù)可用性保障全景圖的規(guī)劃，這種規(guī)劃從 DataOps 的角度來(lái)看，包括研發(fā)階段，如開(kāi)發(fā)、設(shè)計(jì)、測(cè)試、發(fā)布和運(yùn)維等階段，從數(shù)據(jù)管理和數(shù)據(jù)架構(gòu)的角度，你需要將其分成不同的等級(jí)、維度和方面，比如研發(fā)規(guī)范、數(shù)據(jù)質(zhì)量要求、成本控制和安全合規(guī)等要求，通過(guò)這些功能和平臺(tái)能力來(lái)確保數(shù)據(jù)的高可用性。

數(shù)據(jù)可用性保障功能規(guī)劃全景圖這個(gè)需求一方面是由問(wèn)題倒逼出來(lái)的，比如故障復(fù)盤；另一方面是當(dāng)企業(yè)進(jìn)入數(shù)智化運(yùn)營(yíng)階段，數(shù)據(jù)已經(jīng)直接參與到業(yè)務(wù)中了。例如在金融行業(yè)使用數(shù)據(jù)進(jìn)行風(fēng)控，做授信準(zhǔn)入；例如在營(yíng)銷場(chǎng)景，數(shù)據(jù)可以用來(lái)影響廣告投放和推廣，當(dāng)數(shù)據(jù)進(jìn)入業(yè)務(wù)鏈路時(shí)，如果數(shù)據(jù)不準(zhǔn)確，將直接影響業(yè)務(wù)效果，甚至導(dǎo)致業(yè)務(wù)無(wú)法開(kāi)展。在這種情況下，數(shù)據(jù)技術(shù)體系與業(yè)務(wù)技術(shù)體系是融合的，從開(kāi)發(fā)運(yùn)維一體化的角度來(lái)看，DataOps 體系需要與 DevOps 體系對(duì)接打通，因此 DataOps 體系的發(fā)展可以從邏輯上學(xué)習(xí) DevOps 的體系結(jié)構(gòu)，借鑒引用完善形成 DataOps 體系，形成數(shù)據(jù)可用性保障功能規(guī)劃全景圖。

以上我們分析的是數(shù)據(jù)管理的第一項(xiàng)挑戰(zhàn)——風(fēng)險(xiǎn)。

數(shù)據(jù)管理的第二項(xiàng)挑戰(zhàn)是成本。隨著企業(yè)產(chǎn)生的數(shù)據(jù)量的增加，表的數(shù)量也在增多，這背后意味著需要更多的計(jì)算存儲(chǔ)資源。隨著表和任務(wù)的增加，人力成本和技術(shù)要求也在不斷提高。一個(gè)運(yùn)行五年以上的數(shù)據(jù)平臺(tái)，表數(shù)量和存儲(chǔ)的增長(zhǎng)曲線會(huì)越來(lái)越陡峭，數(shù)據(jù)倉(cāng)庫(kù)各分層的存儲(chǔ)占用也會(huì)隨之增加，尤其是應(yīng)用層，因?yàn)槠髽I(yè)內(nèi)部對(duì)數(shù)據(jù)的使用越來(lái)越廣泛，在組織結(jié)構(gòu)上，業(yè)務(wù)技術(shù)部門和數(shù)據(jù)分析團(tuán)隊(duì)的參與使得表的數(shù)量持續(xù)增加，應(yīng)用層的增長(zhǎng)速度會(huì)明顯快于中間層，形成 數(shù)據(jù)倉(cāng)庫(kù)“頭大腳輕”的現(xiàn)象。

面對(duì)這種情況，成本管理成為一個(gè)挑戰(zhàn)。傳統(tǒng)的做法是采用運(yùn)動(dòng)式治理，例如數(shù)據(jù)模型重構(gòu)或數(shù)據(jù)倉(cāng)庫(kù)重構(gòu)。但是，對(duì)于運(yùn)行了五年或更長(zhǎng)時(shí)間的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，由于表的數(shù)量龐大，進(jìn)行重構(gòu)的難度非常大，甚至不可能實(shí)現(xiàn)。因?yàn)樵谑f(wàn)張表的數(shù)據(jù)量級(jí)下，靠 ETL 架構(gòu)師的個(gè)人能力已經(jīng)無(wú)法看全了。

在業(yè)務(wù)領(lǐng)域，我們可以使用大數(shù)據(jù)和 AI 的技術(shù)去解決復(fù)雜業(yè)務(wù)問(wèn)題，比如會(huì)員運(yùn)營(yíng)、商品交叉銷售這樣的一些場(chǎng)景。那么為什么不能用大數(shù)據(jù)和 AI 的方法來(lái)解決數(shù)據(jù)平臺(tái)內(nèi)部的問(wèn)題呢？

所以我們的思路就是用數(shù)據(jù)治理數(shù)據(jù)，用行為來(lái)改變行為。

具體來(lái)說(shuō)就是像業(yè)務(wù)場(chǎng)景里我們對(duì)用戶打標(biāo)簽形成用戶畫像一樣，我們也可以對(duì)數(shù)據(jù)資產(chǎn)進(jìn)行刻畫，給它打上標(biāo)簽。打標(biāo)簽可以有不同的角度，簡(jiǎn)單舉幾個(gè)例子，比如看數(shù)據(jù)的健康度，可以從穿透率、覆蓋率、復(fù)用率和重復(fù)率等角度來(lái)打分，建立健康度儀表盤。

同樣，類似于業(yè)務(wù)側(cè)的會(huì)員運(yùn)營(yíng)體系會(huì)管理會(huì)員的生命周期，我們也可以建立數(shù)據(jù)資產(chǎn)的治理和運(yùn)營(yíng)體系，對(duì)數(shù)據(jù)資產(chǎn)進(jìn)行生命周期管理。通過(guò)數(shù)據(jù)資產(chǎn)運(yùn)營(yíng)體系的運(yùn)營(yíng)動(dòng)作，比如說(shuō)組織“下存儲(chǔ)送計(jì)算”這樣的活動(dòng)，給數(shù)據(jù)存儲(chǔ)治理優(yōu)秀的團(tuán)隊(duì)獎(jiǎng)勵(lì)更多的計(jì)算資源。另外可以建立數(shù)據(jù)資產(chǎn)健康度的紅黑榜，通過(guò)這樣的方式進(jìn)行效果量化和展示，就可以比較好地促進(jìn)各個(gè)數(shù)據(jù)團(tuán)隊(duì)落實(shí)和優(yōu)化長(zhǎng)效治理機(jī)制。

數(shù)據(jù)管理的第三大挑戰(zhàn)是效率。不同于“風(fēng)險(xiǎn)”挑戰(zhàn)和“成本”挑戰(zhàn)，如果是站在我們過(guò)往的經(jīng)驗(yàn)里，我覺(jué)得“效率”挑戰(zhàn)這個(gè)事情是無(wú)解的，為什么呢？因?yàn)樾蔬@個(gè)問(wèn)題反映在多個(gè)層面。

首先，需求響應(yīng)效率逐漸降低，原因在于當(dāng)前的數(shù)據(jù)需求變得更加靈活，但平臺(tái)卻越來(lái)越復(fù)雜，從數(shù)據(jù)技術(shù)的角度來(lái)看，同樣的需求，滿足需求的周期正在變長(zhǎng)，這是大家都有的體感。

其次，數(shù)據(jù)研發(fā)協(xié)同的效率也在下降。以數(shù)據(jù)模型重構(gòu)為例，數(shù)據(jù)中間層重構(gòu)完成后，需要讓下游數(shù)據(jù)切換到新的中間層上，這個(gè)過(guò)程耗時(shí)很長(zhǎng)。例如，在 8 月份，舊的中間層可能有 2000 張表，四個(gè)月后，可能只遷移了 60 張表，而新的中間層的表數(shù)量從 500 張?jiān)黾拥?1800 張。這是因?yàn)樵谶M(jìn)行中間層重構(gòu)時(shí)，下游的末端節(jié)點(diǎn)可能不屬于你的團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)有業(yè)務(wù)需求需要優(yōu)先滿足，而無(wú)法跟重構(gòu)節(jié)奏同頻。這就進(jìn)入了一個(gè)進(jìn)退兩難的窘境：下游數(shù)據(jù)尚未切換，舊的中間層無(wú)法廢棄，中間層團(tuán)隊(duì)需要同時(shí)維護(hù)二套數(shù)據(jù)鏈路。

再來(lái)看研發(fā)時(shí)間問(wèn)題。隨著需求和 ETL 工作量呈指數(shù)型增長(zhǎng)，運(yùn)維和答疑的工作量也在同步增加。這意味著在工程量增加的同時(shí)，花在運(yùn)維上的成本也在增加，導(dǎo)致研發(fā)投入相對(duì)減少，效率進(jìn)一步降低。

“效率”挑戰(zhàn)背后的原因非常復(fù)雜。

首先，數(shù)據(jù)工程師與其他技術(shù)工程師有所不同。例如，如果是負(fù)責(zé)會(huì)員系統(tǒng)或交易系統(tǒng)的 Java 工程師，系統(tǒng)調(diào)用次數(shù)的增加會(huì)直接證明我的技術(shù)價(jià)值和技術(shù)能力，從而有助于我的職業(yè)晉升。然而，對(duì)于數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)師和 ETL 工程師來(lái)說(shuō)，他們的工作被下游依賴得再多，也不容易直接體現(xiàn)技術(shù)深度。這是因?yàn)閿?shù)據(jù)倉(cāng)庫(kù)本質(zhì)上是一個(gè) Serverless 平臺(tái)，其穩(wěn)定性和計(jì)算能力主要由計(jì)算存儲(chǔ)引擎團(tuán)隊(duì)負(fù)責(zé)，尤其是在大數(shù)據(jù)和分布式計(jì)算普及后，系統(tǒng)的彈性擴(kuò)容變得非常簡(jiǎn)單，ETL 工程師只需確保作業(yè)正確執(zhí)行和模型設(shè)計(jì)合理。更多的下游依賴不僅不能體現(xiàn)技術(shù)深度，還帶來(lái)了更大的運(yùn)維工作量和更多的責(zé)任，這就導(dǎo)致數(shù)據(jù)技術(shù)體系從“我為人人，人人為我”的模式轉(zhuǎn)變?yōu)椤叭巳藶槲遥覟樽约骸?。這種變化導(dǎo)致了每個(gè)團(tuán)隊(duì)只負(fù)責(zé)自己的部分，不再承擔(dān)整體責(zé)任。

其次，從下游的角度來(lái)看，如果我負(fù)責(zé)風(fēng)控或營(yíng)銷業(yè)務(wù)，我需要為我的業(yè)務(wù)數(shù)據(jù)的質(zhì)量和完整性負(fù)責(zé)。如果上游數(shù)據(jù)提供者不承擔(dān)相應(yīng)責(zé)任，我怎么能放心使用他們的數(shù)據(jù)呢？這種情況下，業(yè)務(wù)數(shù)據(jù)團(tuán)隊(duì)可能會(huì)選擇構(gòu)建自己的數(shù)據(jù)鏈路，從而確保全鏈路質(zhì)量，這種做法類似于農(nóng)耕時(shí)代的自產(chǎn)自銷。

最后，數(shù)據(jù)團(tuán)隊(duì)的去中心化趨勢(shì)是不可逆的。隨著業(yè)務(wù)數(shù)智化程度的加深，業(yè)務(wù)與數(shù)據(jù)相互融合，業(yè)務(wù)團(tuán)隊(duì)內(nèi)部自然而然地會(huì)培養(yǎng)數(shù)據(jù)意識(shí)，提出更多數(shù)據(jù)化業(yè)務(wù)需求，這類業(yè)務(wù)需求也是數(shù)據(jù)需求，二者往往是不可分割的，這就要求業(yè)務(wù)技術(shù)團(tuán)隊(duì)也需要有數(shù)據(jù)處理能力，因此一個(gè)數(shù)據(jù)化業(yè)務(wù)需求涉及多個(gè)不同團(tuán)隊(duì)的協(xié)同，而協(xié)同問(wèn)題的解決往往是非常棘手的，這背后是組織架構(gòu)和文化問(wèn)題。當(dāng)問(wèn)題發(fā)展到這一階段時(shí)，你會(huì)發(fā)現(xiàn)這種問(wèn)題似乎無(wú)解，因?yàn)樽鳛閿?shù)據(jù)技術(shù)團(tuán)隊(duì)的一員，我們很難解決這些 CTO 或 CEO 層面的問(wèn)題。

總結(jié)一下，我們面臨的挑戰(zhàn)是：在風(fēng)險(xiǎn)、效率和成本之間很難達(dá)到平衡，甚至兩者之間的平衡都難以實(shí)現(xiàn)。這正是 Aloudata 創(chuàng)立的出發(fā)點(diǎn)——通過(guò)技術(shù)創(chuàng)新，來(lái)解決這一數(shù)據(jù)管理的困局。

要解決這個(gè)問(wèn)題，我們首先需要明確其產(chǎn)生的根因。技術(shù)是為了服務(wù)業(yè)務(wù)的，隨著互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的興起，數(shù)據(jù)需求從穩(wěn)態(tài)需求轉(zhuǎn)變?yōu)槊魬B(tài)需求，這導(dǎo)致我們的 ETL 工程量的指數(shù)級(jí)增長(zhǎng)。

但我們 ETL 工程師的人數(shù)和能力卻是有上限的。因此我們上面提到的大型企業(yè)為了應(yīng)對(duì)數(shù)據(jù)挑戰(zhàn)而實(shí)施的諸多策略與機(jī)制都是不斷把功能做得更多更全，把制度和規(guī)范制定的更多更全，卻無(wú)法從根本上解決數(shù)據(jù)管理的困境。

因此我們需要跳出傳統(tǒng)的 ETL 工程師驅(qū)動(dòng)的模式，尋找全新的思路。

我們認(rèn)為，數(shù)據(jù)管理的本質(zhì)是追求一份統(tǒng)一的數(shù)據(jù)資產(chǎn)。如果我們能夠?qū)崿F(xiàn)“一份數(shù)據(jù)資產(chǎn)”這種干凈的狀態(tài)，那么數(shù)據(jù)的管理問(wèn)題、效率問(wèn)題以及成本問(wèn)題自然可以得到全面解決。但如何實(shí)現(xiàn)這一目標(biāo)呢？是在物理上、邏輯上或在某個(gè)局部實(shí)現(xiàn)“一份數(shù)據(jù)資產(chǎn)”嗎？

Aloudata 給出的解決方案，就是我們首倡的 NoETL 概念。其核心目標(biāo)有三個(gè)：看得清，管得住和變得動(dòng)。即可以更清晰地看到數(shù)據(jù)流動(dòng)，更有效地管控?cái)?shù)據(jù)口徑，以及更靈活地應(yīng)對(duì)業(yè)務(wù)需求的變化。

“看得清”，需要元數(shù)據(jù)。類比業(yè)務(wù)側(cè)通過(guò)構(gòu)建商家畫像和用戶畫像從而實(shí)現(xiàn)智能運(yùn)營(yíng)，通過(guò)元數(shù)據(jù)我們可以創(chuàng)建一份對(duì)數(shù)據(jù)的畫像，通過(guò)血緣分析讓數(shù)據(jù)資產(chǎn)看得清。

“管得住”，數(shù)據(jù)管理的關(guān)鍵不在于管理數(shù)據(jù)和表本身，而是管理數(shù)據(jù)的業(yè)務(wù)含義，即數(shù)據(jù)口徑，也就是業(yè)務(wù)語(yǔ)義，因?yàn)檎嬲馁Y產(chǎn)價(jià)值是數(shù)據(jù)口徑和業(yè)務(wù)語(yǔ)義，代表的是業(yè)務(wù)知識(shí)的沉淀。表里的數(shù)據(jù)只不過(guò)是業(yè)務(wù)語(yǔ)義的計(jì)算結(jié)果的固化。

“變得動(dòng)”，是最具挑戰(zhàn)性的，因?yàn)樗婕暗浇M織協(xié)同，是一個(gè)復(fù)雜的問(wèn)題。比較可行的解決方案是數(shù)據(jù)虛擬化，我打個(gè)比喻，方便大家理解。在商業(yè)世界中，存在著線下零售和線上零售。線下零售的邏輯非常類似于傳統(tǒng) ETL 的邏輯，即通過(guò)多層數(shù)據(jù)搬運(yùn)，例如一級(jí)批發(fā)商、二級(jí)批發(fā)商到零售商，以滿足客戶需求。在門店，為了滿足業(yè)務(wù)場(chǎng)景，往往需要備足貨物，這就導(dǎo)致了庫(kù)存積壓。為什么呢？因?yàn)闉榱藰I(yè)務(wù)的靈活性，你必須備足夠的貨，而這些貨物不可能全部被購(gòu)買，總會(huì)有庫(kù)存，從而導(dǎo)致經(jīng)濟(jì)性下降。

那么，線上零售是如何操作的呢？線上零售的邏輯是，商家發(fā)布商品，形成商品庫(kù)，消費(fèi)者通過(guò)搜索商品庫(kù)找到商品加入購(gòu)物車，下單，商品隨后被配送。在這個(gè)過(guò)程中，庫(kù)存問(wèn)題會(huì)得到極大的緩解，而商品送達(dá)的及時(shí)性問(wèn)題，則可以通過(guò)物流端的優(yōu)化來(lái)解決，例如通過(guò)設(shè)置中央倉(cāng)或前置倉(cāng)來(lái)提高物流效率。

我們提出的 NoETL 理念，類似于線上零售，即基于數(shù)據(jù)虛擬化的自動(dòng)化 ETL 編排，旨在通過(guò)重構(gòu) ETL 和數(shù)據(jù)管理方式來(lái)實(shí)現(xiàn)這一目標(biāo)。這種方式類似于企業(yè)從物理搬運(yùn)轉(zhuǎn)向虛擬化邏輯構(gòu)建的過(guò)程。

正如電商世界中的三種模式：從線下到線上、只做線上（完全虛擬化），以及從線上到線下。我們的理解是，虛擬化與傳統(tǒng)數(shù)倉(cāng)的方式需要結(jié)合起來(lái)，根據(jù)企業(yè)的特點(diǎn)來(lái)實(shí)施，這看起來(lái)是一種比較穩(wěn)妥且可持續(xù)迭代的方法。我們已經(jīng)有許多客戶采用這樣的方法來(lái)應(yīng)用和實(shí)施數(shù)據(jù)虛擬化技術(shù)。

Aloudata的 NoETL 理念與 Data Fabric 不謀而合。Data Fabric 的核心在于引入了一個(gè)切片，這個(gè)切片位于業(yè)務(wù)場(chǎng)景與數(shù)據(jù)之間，通過(guò)語(yǔ)義化的交付方式，旨在快速滿足業(yè)務(wù)需求并隔離背后的復(fù)雜性。在當(dāng)前的數(shù)據(jù)管理和分析領(lǐng)域，虛擬化技術(shù)的應(yīng)用日益重要。這種技術(shù)允許我們?cè)跊](méi)有物理移動(dòng)數(shù)據(jù)的情況下進(jìn)行信息流的管理，類似于電商平臺(tái)在處理商品信息流時(shí)的方式。這種方法不僅提高了效率，還簡(jiǎn)化了數(shù)據(jù)處理流程。

在 NoETL 的整體思路下，我們推出了三款產(chǎn)品。旨在幫助數(shù)據(jù)團(tuán)隊(duì)不再進(jìn)行復(fù)雜重復(fù)和不經(jīng)濟(jì)的層層數(shù)據(jù)處理，而是首先明確業(yè)務(wù)的數(shù)據(jù)口徑，然后再構(gòu)建相應(yīng)的數(shù)據(jù)集和指標(biāo)，以及實(shí)現(xiàn)更加智能的數(shù)據(jù)管理。

Aloudata AIR 是一款邏輯數(shù)據(jù)平臺(tái)。AIR 的典型場(chǎng)景是企業(yè)的業(yè)務(wù)開(kāi)展可能存在多個(gè)云平臺(tái)或多個(gè)區(qū)域的數(shù)據(jù)中心，特別是在涉及跨境和合規(guī)問(wèn)題時(shí)，我們的解決方案能夠支持多云環(huán)境下的數(shù)據(jù)集成與查詢。這種多云聯(lián)合分析的場(chǎng)景，可以有效應(yīng)對(duì)合規(guī)監(jiān)管等需求，允許企業(yè)靈活地進(jìn)行數(shù)據(jù)分析和決策支持。

AIR 的另一個(gè)典型的應(yīng)用場(chǎng)景是大型集團(tuán)公司，這些公司下屬有多個(gè)不同的業(yè)務(wù)實(shí)體。在這種結(jié)構(gòu)中，各個(gè)子公司可能各自擁有獨(dú)立的數(shù)據(jù)倉(cāng)庫(kù)?？偣緦用嫒绾斡行гL問(wèn)和管理這些分散的數(shù)據(jù)成為一個(gè)挑戰(zhàn)。通過(guò)數(shù)據(jù)虛擬化，總公司可以無(wú)需物理遷移所有數(shù)據(jù)，而是通過(guò)虛擬化技術(shù)直接訪問(wèn)和分析各子公司的數(shù)據(jù)，極大地簡(jiǎn)化了數(shù)據(jù)管理和分析過(guò)程。

在先進(jìn)制造領(lǐng)域，一家擁有眾多工廠的企業(yè)，每家工廠的需求各不相同，簡(jiǎn)單地用一套方法管理所有工廠顯然不是最佳選擇，因此每家工廠可能都有自己的信息化系統(tǒng)和數(shù)據(jù)分析平臺(tái)，企業(yè)可以通過(guò)虛擬化技術(shù)訪問(wèn)和分析各個(gè)工廠的數(shù)據(jù)。

這些場(chǎng)景展示了數(shù)據(jù)虛擬化在現(xiàn)代企業(yè)中的強(qiáng)大應(yīng)用潛力，特別是在處理復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和多源異構(gòu)環(huán)境中，提供了一種高效、靈活的解決方案。

第二款產(chǎn)品 Aloudata CAN 是一款 NoETL 的自動(dòng)化指標(biāo)平臺(tái)。指標(biāo)的應(yīng)用覆蓋了從管理層看板到部門看板，再到運(yùn)營(yíng)活動(dòng)和業(yè)務(wù)閉環(huán)運(yùn)營(yíng)的全過(guò)程。這種基于指標(biāo)的管理方式，能夠有效支持企業(yè)的決策和運(yùn)營(yíng)。我們從 NoETL 的角度出發(fā)，關(guān)注的是如何通過(guò)自動(dòng)化技術(shù)來(lái)優(yōu)化指標(biāo)的生產(chǎn)、消費(fèi)和統(tǒng)一管理。這種方法的核心在于通過(guò)定義清晰的語(yǔ)義，對(duì)數(shù)倉(cāng)中間層和應(yīng)用層進(jìn)行建模，然后通過(guò)自動(dòng)化構(gòu)建和物化加速實(shí)現(xiàn)指標(biāo)的定義、開(kāi)發(fā)、管理、消費(fèi)的一體化。

Aloudata BIG 是基于算子血緣解析能力的主動(dòng)元數(shù)據(jù)平臺(tái)。正如我前面介紹的，在處理大規(guī)模數(shù)據(jù)時(shí)，如何有效管理和利用這些數(shù)據(jù)成為了一個(gè)挑戰(zhàn)。這就需要一個(gè)強(qiáng)大的 DataOps 體系來(lái)支持，該體系包含了數(shù)百個(gè)功能項(xiàng)，但真實(shí)場(chǎng)景下，并非所有數(shù)據(jù)需求都需要完整走過(guò)這些功能流程。因此，基于具體的業(yè)務(wù)場(chǎng)景進(jìn)行數(shù)據(jù)需求的分類和分級(jí)，選擇合適的流程至關(guān)重要。

這種流程的設(shè)計(jì)和實(shí)施，最終都依賴于元數(shù)據(jù)的支持。沒(méi)有元數(shù)據(jù)的驅(qū)動(dòng)，平臺(tái)只是一個(gè)簡(jiǎn)單的工具箱，無(wú)法有效地支持研發(fā)過(guò)程和數(shù)據(jù)管理。數(shù)據(jù)管理的理念、思想和控制能力必須體現(xiàn)在研發(fā)流程中，我們需要利用元數(shù)據(jù)來(lái)引導(dǎo)研發(fā)流程并實(shí)現(xiàn)研發(fā)流程的智能化，如果缺乏這樣的能力，再多的工具也只是堆砌，無(wú)法形成真正的數(shù)據(jù)管理解決方案。例如在實(shí)施 DataOps 體系時(shí)，一個(gè)關(guān)鍵的環(huán)節(jié)是模型的 Review，包括判斷模型是否符合要求以及是否存在重復(fù)或需要優(yōu)化，這需要一套基于元數(shù)據(jù)的算法來(lái)實(shí)現(xiàn)。

上述三款產(chǎn)品均在頭部金融企業(yè)的生產(chǎn)場(chǎng)景中獲得了驗(yàn)證。

最后我想分享一下 NoETL 的本質(zhì)， 傳統(tǒng)數(shù)據(jù)管理體系是通過(guò) ETL 工程師來(lái)驅(qū)動(dòng)的。隨著數(shù)據(jù)需求的大幅增長(zhǎng)，數(shù)據(jù)鏈路的日益復(fù)雜，ETL 工程師在數(shù)量和能力上都存在上限。在這種情況下，我們只能通過(guò) NoETL 來(lái)重塑數(shù)據(jù)管理，NoETL 的本質(zhì)是自動(dòng)化，而 ETL Agent 是這種自動(dòng)化的終極實(shí)現(xiàn)，成為推動(dòng)整個(gè)新一代自動(dòng)化數(shù)據(jù)管理的關(guān)鍵。

希望我的分享能對(duì)大家有所幫助，謝謝大家。