大模型、實(shí)時(shí)需求推動(dòng)湖倉平臺走向開放
大模型、實(shí)時(shí)需求高漲
AGI 時(shí)代，以 ChatGPT、Midjourney 等為代表的大模型迅速應(yīng)用加速了 AI 普及，越來越多的企業(yè)選擇搭建自己的 AI 基礎(chǔ)設(shè)施，訓(xùn)練行業(yè)大模型。
另一方面，企業(yè)為了在瞬息萬變的市場環(huán)境中更快的做出商業(yè)決策，正在將數(shù)據(jù)平臺從離線轉(zhuǎn)向?qū)崟r(shí)數(shù)據(jù)平臺?！半p十一 ”和春晚直播實(shí)時(shí)大屏、銀行和證券交易行為實(shí)時(shí)監(jiān)控、電商和短視頻的實(shí)時(shí)個(gè)性化推薦等只是全行業(yè)在線化的冰山一角。
AI + 實(shí)時(shí)，儼然成為了企業(yè)數(shù)據(jù)平臺無法避免的技術(shù)焦點(diǎn)。那么，如何讓企業(yè)數(shù)據(jù)平臺擁抱AI+實(shí)時(shí)的雙重能力？
為什么難實(shí)現(xiàn)？
對于現(xiàn)階段的大數(shù)據(jù)平臺和傳統(tǒng)數(shù)據(jù)倉庫等企業(yè)數(shù)據(jù)平臺，姑且不論同時(shí)整合 AI + 實(shí)時(shí)，單獨(dú)的 AI 平臺或者實(shí)時(shí)數(shù)據(jù)平臺都不得不通過復(fù)雜架構(gòu)，耗費(fèi)大量資源和人力來實(shí)現(xiàn)。我們不妨先來分別看看現(xiàn)在的 AI 和實(shí)時(shí)架構(gòu)是如何實(shí)現(xiàn)的。
AI 與數(shù)據(jù)平臺
機(jī)器學(xué)習(xí)和人工智能的模型訓(xùn)練采用結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。結(jié)構(gòu)化數(shù)據(jù)價(jià)值非常高，數(shù)據(jù)質(zhì)量也非常好，因此有些 AI 問題主要基于結(jié)構(gòu)化的數(shù)據(jù)建模。一個(gè)很典型的例子就是銀行基于結(jié)構(gòu)化數(shù)據(jù)，面向個(gè)人客戶開發(fā)的信用評分卡，既有可解釋性，又能滿足實(shí)時(shí)的信用評估。
那么，傳統(tǒng)數(shù)倉的大量結(jié)構(gòu)化數(shù)據(jù)該如何被用于訓(xùn)練 AI 模型呢？常見的方式是，當(dāng)機(jī)器學(xué)習(xí)平臺需要訪問數(shù)據(jù)集時(shí)，需要先通過 JDBC 或者外部表的形式把數(shù)據(jù)從數(shù)據(jù)倉庫導(dǎo)出到分布式存儲中，然后再并行處理這些數(shù)據(jù)，用以進(jìn)行模型訓(xùn)練和分析。在大規(guī)模數(shù)據(jù)處理場景中，這種不斷導(dǎo)出數(shù)據(jù)的方式顯然是不現(xiàn)實(shí)的，因?yàn)閷?dǎo)出 TB 或者 PB 級別的數(shù)據(jù)通常得花好幾個(gè)小時(shí)甚至幾天的時(shí)間，既費(fèi)力又費(fèi)時(shí)。
在過去幾年中，在業(yè)界產(chǎn)生廣泛影響力的機(jī)器學(xué)習(xí)和 AI 模型幾乎都是從非結(jié)構(gòu)化數(shù)據(jù)中獲取的。盡管在傳統(tǒng)數(shù)據(jù)倉庫中，可以將非結(jié)構(gòu)化數(shù)據(jù)視為簡單的文本或二進(jìn)制類型 (TEXT、VARCHAR、BLOB)，然而通過這種方式訓(xùn)練AI模型效率低下，同樣需要從數(shù)據(jù)倉庫中導(dǎo)出數(shù)據(jù)后再做建模。
因此，企業(yè)逐漸選擇數(shù)據(jù)湖這種更加開放的形態(tài)來訓(xùn)練 AI 模型。結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)（文本和圖像等）直接進(jìn)入數(shù)據(jù)湖，以數(shù)據(jù)湖開放的存儲格式存儲，如 ORC 和 Parquet，使用開源工具去直接操作數(shù)據(jù)。傳統(tǒng)數(shù)據(jù)湖平臺通常由 Hadoop 實(shí)現(xiàn)，因?yàn)?Hadoop 的局限性，比如缺乏事務(wù)支持，缺乏很好的數(shù)據(jù)治理方法等等，數(shù)據(jù)湖都難免形成數(shù)據(jù)沼澤。
實(shí)時(shí)數(shù)據(jù)平臺
傳統(tǒng)數(shù)據(jù)平臺不僅在 AI 模型的支持上出現(xiàn)了諸多問題，在實(shí)時(shí)數(shù)據(jù)處理方面也面臨著極大挑戰(zhàn)。
傳統(tǒng)數(shù)據(jù)平臺的數(shù)據(jù)處理流程一般是這樣的。首先，從業(yè)務(wù)系統(tǒng) CRM、ERP 或者其他數(shù)據(jù)源把這些業(yè)務(wù)數(shù)據(jù)收集過來，然后經(jīng)過離線數(shù)據(jù) ETL 對數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗、數(shù)據(jù)加工。在這個(gè)過程中會涉及數(shù)據(jù)建模和分層，最終會把加工后的數(shù)據(jù)提供給 BI 工具，或者寫到數(shù)據(jù)庫并推到一個(gè)在線服務(wù)系統(tǒng)，供用戶進(jìn)行訪問，這些用戶包括用戶、運(yùn)營人員或管理團(tuán)隊(duì)等等。
我們可以發(fā)現(xiàn)，即便在沒有做實(shí)時(shí)數(shù)據(jù)處理的情況下，這樣的數(shù)據(jù)處理鏈路就已經(jīng)很冗長了。然而，當(dāng)我們不解決既有離線問題的情況下就向?qū)崟r(shí)轉(zhuǎn)型，問題將更加復(fù)雜。
實(shí)時(shí)數(shù)據(jù)是如何處理的？
目前主要采用傳統(tǒng) Lambda 和 Kappa 架構(gòu)。以 Lambda 架構(gòu)的實(shí)現(xiàn)方法為例，Lambda 以傳統(tǒng)的離線數(shù)倉為主，然后引入了實(shí)時(shí)數(shù)據(jù)的處理鏈路。T+1 數(shù)據(jù)仍然是走傳統(tǒng)離線數(shù)倉鏈路，然后再加上一個(gè)實(shí)時(shí)的數(shù)據(jù)鏈路，再把這些實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)匯總到一起，然后再通過一個(gè)服務(wù)層提供數(shù)據(jù)服務(wù)，對外提供的服務(wù)可能是點(diǎn)查詢，也可能是做復(fù)雜分析。
因此 Lambda 架構(gòu)并沒有從源頭上解決傳統(tǒng)離線數(shù)倉的問題，而是在傳統(tǒng)離線數(shù)倉上加了一條鏈路，讓整個(gè)系統(tǒng)變得更加復(fù)雜。數(shù)據(jù)可能會存兩份或者存多份，實(shí)時(shí)鏈路和離線鏈路數(shù)據(jù)也不統(tǒng)一。除此之外，整個(gè)架構(gòu)維護(hù)起來是非常復(fù)雜的，學(xué)習(xí)和開發(fā)成本比較高。
如何破局？
為了實(shí)現(xiàn)用更豐富的數(shù)據(jù)源訓(xùn)練 AI 模型，我們以極高的代價(jià)將數(shù)倉的數(shù)據(jù)導(dǎo)出后再并行處理；為了實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理，我們不惜選擇冗長的數(shù)據(jù)處理鏈路，造成多份數(shù)據(jù)和多個(gè)計(jì)算引擎煙囪林立。這些痛點(diǎn)都將我們引向?qū)σ粋€(gè)問題的思考：我們能不能只用一份數(shù)據(jù)，精簡計(jì)算引擎？
答案是可以的。
當(dāng)下，存儲和計(jì)算的數(shù)據(jù)無非是結(jié)構(gòu)化、非結(jié)構(gòu)化和流式數(shù)據(jù)。破局的第一步，就是在數(shù)據(jù)的存儲方面采用開放格式的一份數(shù)據(jù)，如 Parquet、ORC、Hudi 等。各個(gè)計(jì)算引擎都使用開放的數(shù)據(jù)格式（如 ORC 或 Parquet 等），數(shù)據(jù)以開放文件格式被寫入數(shù)據(jù)平臺，之后就能被多個(gè)引擎多次直接讀取和使用。
有了存儲的開放性，在計(jì)算引擎方面，我們就可以盡量優(yōu)化和減少計(jì)算引擎的數(shù)量，并針對結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)和流式數(shù)據(jù)，選用各具優(yōu)勢的計(jì)算引擎：● 針對流數(shù)據(jù)的計(jì)算，采用常見的 Flink；● 針對非結(jié)構(gòu)化數(shù)據(jù)和機(jī)器學(xué)習(xí)，可以采用 Spark；● 針對結(jié)構(gòu)化數(shù)據(jù)，需要兼容開放數(shù)據(jù)格式，兼顧實(shí)時(shí)查詢、離線分析、高并發(fā)和高可用的分析引擎，比如偶數(shù)的 OushuDB。
“一數(shù)多擎”是我們在多個(gè)行業(yè)的湖倉一體項(xiàng)目落地中不斷迭代的最佳實(shí)踐。企業(yè)在選擇多個(gè)引擎時(shí)一定需要基于“化繁為簡”和“揚(yáng)長避短”原則，比如 OushuDB 可以完全實(shí)現(xiàn)Hive、Presto、ClickHouse、HBase 等引擎的功能，引入 OushuDB 后就不需要再依賴這些引擎，這樣可以極大簡化系統(tǒng)開發(fā)和運(yùn)維的復(fù)雜度。Flink 擅長流處理，就使用 Flink 做流處理，而不是使用 Flink 來做 SQL 查詢，Spark 擅長做機(jī)器學(xué)習(xí)，就使用 Spark 做機(jī)器學(xué)習(xí)，而不是使用 Spark 來做流處理和 SQL 查詢。Hive 查詢慢，就不必再保留 Hive，可以使用 OushuDB 取代。
開放的“一數(shù)多擎”
帶來哪些價(jià)值？
● 首先就是開放本身的價(jià)值，開放直接解決了當(dāng)前數(shù)據(jù)平臺在AI模型訓(xùn)練和實(shí)時(shí)數(shù)據(jù)處理過程中多份數(shù)據(jù)造成的數(shù)據(jù)冗余和數(shù)據(jù)不一致。同時(shí)，開放的格式讓湖倉一體很容易獲得最優(yōu)的 SQL 引擎、ETL、流處理引擎和機(jī)器學(xué)習(xí)引擎的支持。● 其次，一份數(shù)據(jù)整合了非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)存儲，圖像、文本可以直接用于 AI 模型訓(xùn)練，結(jié)構(gòu)化數(shù)據(jù)也無需被多次讀取、復(fù)制和導(dǎo)出。● 再次，“一數(shù)多擎”必然要求徹底的存算分離架構(gòu)，讓企業(yè)湖倉平臺不受集群規(guī)模的限制，動(dòng)態(tài)擴(kuò)展集群規(guī)模。
● 另外，由于過往實(shí)時(shí)、離線數(shù)據(jù)處理鏈路極其冗長和復(fù)雜，造成數(shù)據(jù)建模、元數(shù)據(jù)管理、數(shù)據(jù)治理都難以高效的實(shí)施，“一數(shù)多擎”精簡了不必要的引擎組件，整個(gè)架構(gòu)變得簡潔，既為數(shù)據(jù)建模、數(shù)據(jù)治理提供了平臺基礎(chǔ)，又讓學(xué)習(xí)、開發(fā)和維護(hù)成本都大幅下降。
總結(jié)
IDC 調(diào)研顯示，企業(yè)在數(shù)字化商業(yè)過程中更加關(guān)心利用數(shù)據(jù)和信息來創(chuàng)造自身競爭優(yōu)勢，因此實(shí)現(xiàn)底層統(tǒng)一的數(shù)據(jù)管理是進(jìn)行上層資產(chǎn)管理和業(yè)務(wù)決策分析的關(guān)鍵。
以往，由于技術(shù)水平的制約和方案的局限性，我們難以實(shí)現(xiàn)底層統(tǒng)一的數(shù)據(jù)管理。因此，為了能用更豐富的數(shù)據(jù)源訓(xùn)練AI模型，我們以極高的代價(jià)將數(shù)倉的數(shù)據(jù)導(dǎo)出；為了實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)處理，我們不惜選擇冗長的數(shù)據(jù)處理鏈路，造成多份數(shù)據(jù)和多個(gè)計(jì)算引擎煙囪林立。
