原創(chuàng) 艾瑞 艾瑞咨詢

數(shù)智融合丨研究洞察

核心摘要：

VUCA時代，市場變化加速。企業(yè)需要更加敏捷而準確的數(shù)智化決策，這些決策應(yīng)當是分鐘級的而非天級的，應(yīng)當是基于全量數(shù)據(jù)的而非局部數(shù)據(jù)的，應(yīng)當是基于準確數(shù)據(jù)的而非基于“臟數(shù)據(jù)”的，應(yīng)當是業(yè)務(wù)人員和數(shù)據(jù)分析人員任意發(fā)起的而非是通過復(fù)雜流程和多部門配合才能實現(xiàn)的。

傳統(tǒng)的數(shù)倉或者湖倉分離架構(gòu)讓數(shù)智融合和企業(yè)敏捷決策變得困難：數(shù)據(jù)孤島存在，決策無法基于全量數(shù)據(jù)；數(shù)據(jù)來回流轉(zhuǎn)，成本高、周期長、時效差?；诖鎯?緩存-計算分離，湖-倉-AI數(shù)據(jù)統(tǒng)一元數(shù)據(jù)管理的Serverless，可在數(shù)據(jù)量、成本、效率、敏捷方面取得最優(yōu)解。

開源為數(shù)智生態(tài)貢獻重要力量，但這不預(yù)示所有企業(yè)需通過開源產(chǎn)品自建數(shù)智平臺。實際上，大多企業(yè)聚焦自己核心業(yè)務(wù)，選擇性能穩(wěn)定、無須運維、數(shù)智融合、端到端自動化與智能化的商業(yè)化數(shù)智平臺，ROI會更高。當然，平臺應(yīng)與主流開源產(chǎn)品具有良好繼承性，如此，更加靈活開放，企業(yè)的IT人才補給成本也更低。

數(shù)據(jù)量和非結(jié)構(gòu)化數(shù)據(jù)占比上升

統(tǒng)一管理，統(tǒng)一查詢使用，成為新的挑戰(zhàn)

全球數(shù)據(jù)量以59%以上的年增長率快速增長，其中80%是非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，中國數(shù)據(jù)量的上升較全球更為迅速。數(shù)據(jù)量和非結(jié)構(gòu)化數(shù)據(jù)的上升，使得基于對象存儲的數(shù)據(jù)湖越來越為普及。此時，如何使用統(tǒng)一管理，統(tǒng)一查詢使用，成為新的挑戰(zhàn)。

數(shù)據(jù)多源異構(gòu)成為常態(tài)

數(shù)據(jù)從“匯聚才可被用”到“鏈接即可被用”

在傳統(tǒng)數(shù)倉中，多源數(shù)據(jù)經(jīng)ETL過程并集中入倉，方可被使用。該方式有許多不足：第一，因有復(fù)雜的ETL過程及大量數(shù)據(jù)的傳輸，數(shù)據(jù)實時性難以保障，因此分析常必須T+1才可完成；第二，數(shù)據(jù)的全量存儲和存儲成本之間難以取舍，因此必須提前抉擇保留哪些數(shù)據(jù)，隨著數(shù)據(jù)種類的逐漸增多，這很難做到；第三，對于異常值的下鉆、回溯等，無法回溯到最為原始的數(shù)據(jù)。隨著應(yīng)用場景的增多，數(shù)據(jù)庫的種類也逐漸豐富，如更適應(yīng)物聯(lián)網(wǎng)場景的時序數(shù)據(jù)庫、更適應(yīng)知識譜圖應(yīng)用的圖數(shù)據(jù)庫，等等。

綜上，多源異構(gòu)、分布存儲、現(xiàn)用現(xiàn)傳、統(tǒng)一查詢與應(yīng)用的架構(gòu)，逐漸被敏捷型企業(yè)認可。

大數(shù)據(jù)的5V價值有待進一步釋放

可從平臺性工具入手，進而解決思維和技能的問題

大數(shù)據(jù)產(chǎn)業(yè)作為以數(shù)據(jù)生成、采集、存儲、加工、分析、服務(wù)為主的戰(zhàn)略性新興產(chǎn)業(yè)，提供全鏈條技術(shù)、工具和平臺，孕育數(shù)據(jù)要素市場主體，深度參與數(shù)據(jù)要素全生命周期活動，是激活數(shù)據(jù)要素潛能的關(guān)鍵支撐，是數(shù)據(jù)要素市場培育的重要內(nèi)容。目前，大數(shù)據(jù)產(chǎn)業(yè)仍存在數(shù)據(jù)壁壘突出、碎片化問題嚴重等瓶頸約束，大數(shù)據(jù)容量大、類型多、速度快、精度準、價值高的5V特性未能得到充分釋放。這其中既有思維、技能的要素，又有工具的要素，三者也并非割裂存在，一般來說，性能穩(wěn)定、簡單易用的全鏈條平臺工具有助于消除思維的“不敢”和技能的“不會”，化解掉5V特性釋放的原始阻力，使得大數(shù)據(jù)更加普適化。

云原生：從微服務(wù)走向Serverless

從PaaS到FaaS，基礎(chǔ)設(shè)施被更深層次地托管和“屏蔽”

當前，微服務(wù)的生態(tài)和實踐已經(jīng)比較成熟，其設(shè)計方法、開發(fā)框架、CI/CD工具、基礎(chǔ)設(shè)施管理工具等，都可以幫助企業(yè)順利實施，然而其仍有許多不足：（1）粒度仍然比較大。（2）開發(fā)仍有較高門檻。（3）微服務(wù)基礎(chǔ)設(shè)施管理、高可用和彈性仍然很難保證。（4）基礎(chǔ)設(shè)施的成本依然較高。而Serverless中，開發(fā)者不再需要將時間和資源花費在服務(wù)器調(diào)配、維護、更新、擴展和容量規(guī)劃上，這些任務(wù)都由平臺處理，開發(fā)者只需要專注于編寫應(yīng)用程序的業(yè)務(wù)邏輯。如果再結(jié)合低零代碼，則 “編寫應(yīng)用程序”的難度也大為降低，企業(yè)內(nèi)的技術(shù)人員更加貼近業(yè)務(wù)。

人工智能：需要大規(guī)模準確數(shù)據(jù)哺育

人工智能應(yīng)用引發(fā)數(shù)據(jù)治理需求

企業(yè)在部署AI應(yīng)用時，數(shù)據(jù)資源的優(yōu)劣極大程度決定了AI應(yīng)用的落地效果。因此，為推進AI應(yīng)用的高質(zhì)量落地，開展針對性的數(shù)據(jù)治理工作為首要且必要的環(huán)節(jié)。而對于企業(yè)本身已搭建的傳統(tǒng)數(shù)據(jù)治理體系，目前多停留在對于結(jié)構(gòu)性數(shù)據(jù)的治理優(yōu)化，在數(shù)據(jù)質(zhì)量、數(shù)據(jù)字段豐富度、數(shù)據(jù)分布和數(shù)據(jù)實時性等維度尚難滿足AI應(yīng)用對數(shù)據(jù)的高質(zhì)量要求。為保證AI應(yīng)用的高質(zhì)效落地，企業(yè)仍需進行面向人工智能應(yīng)用的二次數(shù)據(jù)治理工作。

業(yè)務(wù)敏捷需要IT架構(gòu)“去過程化”

通過抽象解耦、水平擴展、自動化與智能化實現(xiàn)去過程化

VUCA時代，市場變化加速，通過數(shù)據(jù)來分析和決策的需求，也有了更高的不確定性。當這些需求提出，通過一套復(fù)雜的IT流程和漫長的等待，變得不再現(xiàn)實，IT架構(gòu)的去過程化變得極為重要。去過程化是指減少或完全去掉原始數(shù)據(jù)/原子能力與業(yè)務(wù)需求之間的中間數(shù)據(jù)/步驟，或使中間數(shù)據(jù)/步驟無須人為干預(yù)，自動化、智能化完成。其可實現(xiàn)架構(gòu)的簡單化、扁平化，同時可對業(yè)務(wù)需求實時響應(yīng)，以進一步實現(xiàn)敏捷和創(chuàng)新。架構(gòu)一開始就放棄“精細梳理方可使用”以及“梳理完成千萬別動”思想 ，用全量原始數(shù)據(jù)保障讀時模式，有助于打破“僵”與“亂”的悖論，使得企業(yè)用更少的“能量” 便可以維持數(shù)字化系統(tǒng)的持續(xù)運行。

痛點一：數(shù)據(jù)量-成本-效率難以兼得

不可能三角需要更高維的技術(shù)去打破

在傳統(tǒng)架構(gòu)中，數(shù)據(jù)量、存儲成本和計算效率是一組不可能三角。如果不考慮數(shù)據(jù)量和數(shù)據(jù)類型，那么一個傳統(tǒng)的數(shù)倉或者單體的DBMS即可滿足；不考慮計算效率，那么基于HDFS或者公有云對象存儲即可滿足，當下價格僅約0.1元/G/月，并持續(xù)下降，歸檔存儲等價格更低；不考慮存儲成本，可使用非易失性存儲，其擁有一般硬盤的無限容量和斷電保護特性，卻有接近于內(nèi)存的性能。

應(yīng)對一：存儲-緩存-計算三層分離

以內(nèi)存為中心的架構(gòu)，在大數(shù)據(jù)量下降低成本、保持性能

為了使數(shù)據(jù)充分共享，降低均攤成本且打破數(shù)據(jù)孤島，存算分離架構(gòu)產(chǎn)生，存儲和計算各自彈性伸縮，按需使用。但此時，因存儲拉遠，IO成為瓶頸，性能有所下降，因此需要緩存層來存儲高IO的熱數(shù)據(jù)，并最終形成以內(nèi)存為中心的架構(gòu)。

從必要性看，以計算為中心架構(gòu)已經(jīng)無法適應(yīng)當前數(shù)據(jù)生態(tài)發(fā)展：數(shù)據(jù)方面，大數(shù)據(jù)、人工智能等以數(shù)據(jù)為中心的工作負載快速發(fā)展；云方面，數(shù)據(jù)湖存算分離架構(gòu)存儲訪問性能低，不支持實時分析。從可行性看，介質(zhì)、網(wǎng)絡(luò)、協(xié)議的高速發(fā)展驅(qū)動架構(gòu)轉(zhuǎn)型：SCM填補了內(nèi)存縱向擴展的介質(zhì)空白；緩存一致性標準的爭奪進入白熱化；高速內(nèi)存直連協(xié)議及技術(shù)（如華為1520，InfiniBand，Converged Ethernet）使得內(nèi)存的遠程直接訪問不再是障礙。

痛點二：倉-湖-AI數(shù)據(jù)形成新孤島

要么隔離，要么遷移，均無法適應(yīng)全量、敏捷、低成本需求

數(shù)據(jù)分析和AI分析經(jīng)過多年的發(fā)展，出現(xiàn)了很多面向不同任務(wù)的專用數(shù)據(jù)系統(tǒng)：數(shù)倉系統(tǒng)處理結(jié)構(gòu)化數(shù)據(jù)，規(guī)模不夠大；基于對象存儲的大數(shù)據(jù)系統(tǒng)處理海量數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)；AI系統(tǒng)一般是數(shù)據(jù)存儲在本地。這些專用系統(tǒng)要么無法打通，形成新的數(shù)據(jù)孤島，要么不同業(yè)務(wù)的開發(fā)要遷移數(shù)據(jù)，耗費存儲和網(wǎng)絡(luò)資源，數(shù)據(jù)準備慢、等待周期長，且面臨后期數(shù)據(jù)不一致的風(fēng)險，發(fā)現(xiàn)異常時數(shù)據(jù)的下鉆、溯源等也相對困難，無法適應(yīng)市場環(huán)境快速變化下敏捷數(shù)據(jù)分析的需求。

應(yīng)對二：統(tǒng)一元數(shù)據(jù)到中心節(jié)點

Master-Slave架構(gòu)，以集中管理代替集中存儲

把數(shù)倉、數(shù)據(jù)湖、AI數(shù)據(jù)的目錄、數(shù)據(jù)權(quán)限、事務(wù)一致性、多版本管理等能力都統(tǒng)一到一個中心點，依賴于這個中心點來訪問數(shù)據(jù)，這樣數(shù)據(jù)的利用就不會被孤立的系統(tǒng)束縛。這種分布式存儲，統(tǒng)一管理的Master-Slave架構(gòu)，類似于計算領(lǐng)域的Mapreduce。這種方式：首先，可以打破數(shù)據(jù)孤島、讓一份數(shù)據(jù)在多個引擎間自由共享，例如同一個表格可以被不同的分析工具做分析，既可以跑數(shù)倉任務(wù)，也可以做大數(shù)據(jù)和機器學(xué)習(xí)任務(wù)，不同的用戶角色不管用什么工具訪問數(shù)據(jù)，都有一致的權(quán)限，一致的事務(wù)控制；其次，可以避免數(shù)據(jù)來回遷移而造成資源的浪費；再次，任何環(huán)節(jié)都可以看到自己權(quán)限下的全量數(shù)據(jù)，例如ML工程師可以利用整個數(shù)據(jù)湖的數(shù)據(jù)做特征訓(xùn)練；最后，所有模型均基于唯一事實來源（原始數(shù)據(jù)），避免不同團隊基于不同數(shù)據(jù)分析造成結(jié)果不一致，且一旦發(fā)現(xiàn)異?？梢员憬莸叵裸@、回溯。

痛點三：開源產(chǎn)品豐富，但開發(fā)運維難

開發(fā)成本高，運維成本高，技術(shù)與時俱進難，風(fēng)險大

盡管在云、數(shù)、智體系下，開源產(chǎn)品極為豐富，但企業(yè)安全、穩(wěn)定地駕馭，TCO并不低。在開發(fā)上，企業(yè)一般需花費20-1000人力年的時間，不能滿足業(yè)務(wù)敏捷性；在運維上，人工運維，事后補救，宕機頻繁，耗時耗力；在技術(shù)更新上，開發(fā)人員難以與時俱進，資源浪費嚴重；在IT風(fēng)險上，企業(yè)將面對IT團隊自身的風(fēng)險（復(fù)雜架構(gòu)下，團隊離職無人接手）以及開源產(chǎn)品的漏洞風(fēng)險（如log4j4漏洞事件），還可能面對因經(jīng)驗不足選型錯誤的風(fēng)險；在體驗上，因產(chǎn)品自產(chǎn)自用，復(fù)用率低，技術(shù)團隊一般只保障基礎(chǔ)需求，對于降低業(yè)務(wù)人員使用難度、提升使用體驗的附加性需求響應(yīng)度低。并且，這些基礎(chǔ)的開發(fā)、運維等，與企業(yè)核心業(yè)務(wù)常無必然聯(lián)系，并不會帶來企業(yè)核心競爭力的提升，導(dǎo)致企業(yè)數(shù)智化的ROI較低。

應(yīng)對三：DataOps和MLOps融合

享受成熟產(chǎn)品的紅利，兼顧與開源產(chǎn)品的繼承和包容性

企業(yè)在數(shù)智化選型中，應(yīng)首先明確自身的核心競爭力和能力邊界，摒棄“重即好”思想，以更加輕盈的Serverless、Lowcode/Nocode、SaaS等方式享受社會分工和先進技術(shù)的紅利。以數(shù)智融合為例，拋開IaaS層，企業(yè)自研還需掌握Kubernetes+Docker生態(tài)、Java+Hadoop生態(tài)、Python+Pytorch/Tensorflow生態(tài)、SQL生態(tài)……即便成功對接，往往也離好用、敏捷相去甚遠，最終往往只形成指標長期不變的靜態(tài)報表。而與此同時，業(yè)界已存在較為領(lǐng)先的一站式數(shù)智平臺，讓數(shù)據(jù)工程師甚至業(yè)務(wù)人員以簡單、熟悉的工具/語言，甚至拖拉拽即可在全域數(shù)據(jù)內(nèi)使用預(yù)置AI算法，打通大數(shù)據(jù)和人工智能，使得DataOps和MLOps融合，使數(shù)據(jù)和模型的開發(fā)成本大為降低，周期大為縮短。

企業(yè)選擇基于開源產(chǎn)品自研，不少時候是出于一種怕被“綁架”的防御心態(tài)，以化解供應(yīng)商倒閉或漲價等風(fēng)險。為此，企業(yè)可從供應(yīng)商綜合實力，與開源產(chǎn)品的包容度和繼承性等方面綜合考慮，做到可組可分，靈活裝配。

痛點四：數(shù)據(jù)準備工作復(fù)雜低效

數(shù)據(jù)長生命周期決定了其復(fù)雜性

數(shù)據(jù)質(zhì)量至關(guān)重要，錯誤數(shù)據(jù)致使企業(yè)做出錯誤決策。數(shù)據(jù)的生成、采集、存儲、加工、分析、服務(wù)、安全、應(yīng)用長生命周期，使得數(shù)據(jù)的準備工作復(fù)雜、低效。例如，數(shù)據(jù)工程師開發(fā)大量的ETL任務(wù)，依賴大量算力資源，運行成本高，作業(yè)管理復(fù)雜，時間周期長，而此時數(shù)據(jù)分析師和AI開發(fā)者都需要等待ETL任務(wù)執(zhí)行完，才能做相應(yīng)的分析工作和建模工作。Cognilytica調(diào)研顯示，機器學(xué)習(xí)中，超過80%的時間都用于數(shù)據(jù)的準備，預(yù)示著大量的數(shù)據(jù)工作其實與企業(yè)的經(jīng)營目標并不相關(guān)，只是不得以而為之。并且，當任務(wù)不能便捷地執(zhí)行和即時的反饋，偏業(yè)務(wù)側(cè)的數(shù)據(jù)分析師常主動放棄“不太重要的”需求和對數(shù)據(jù)的深入探索。顯然，這些都不符合企業(yè)數(shù)智化轉(zhuǎn)型的真正目標。

應(yīng)對四：端到端的自動化與智能化

低零代碼實現(xiàn)自動化，AI反哺數(shù)據(jù)實現(xiàn)智能化

實現(xiàn)數(shù)據(jù)應(yīng)用的敏捷化和去過程化，需要在整個數(shù)據(jù)鏈條的端到端實現(xiàn)自動化和智能化。自動化一般用低/零代碼實現(xiàn)：一方面可以屏蔽軟硬件差異和復(fù)雜的底層技術(shù)，以便于理解的拖拉拽和少量代碼，來降低使用門檻；另一方面，可以基于規(guī)則，配置自動化的工作流，以ifttt的方式減少重復(fù)工作量。智能化是指基于半監(jiān)督或無監(jiān)督的學(xué)習(xí)，自動發(fā)現(xiàn)數(shù)據(jù)管理中的規(guī)則，在Data4AI的同時，實現(xiàn)AI4Data，目前人工智能已經(jīng)用于數(shù)據(jù)集成、數(shù)據(jù)質(zhì)量、數(shù)據(jù)建模、數(shù)據(jù)安全與訪問控制、數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)洞察等多個場景中。另外，低/零代碼常和人工智能結(jié)合使用：將人工智能的統(tǒng)計意義上的規(guī)則，融入到低/零代碼的邏輯化的流程中。

原標題：《2022年中國數(shù)智融合發(fā)展洞察》

閱讀原文