一、大數據 AI 開發范式的演變

近年來，機器學習備受關注，但開發流程上并沒有本質的變化，依舊是從數據準備到預處理，到模型的開發、訓練，再到評估、上線，依次反復迭代。流程沒有本質變化，但在不同階段所花費的精力和時間正在發生變化。

隨著大模型等新型機器學習項目逐漸成為主流，機器學習項目從以模型為中心的開發范式，向以數據為中心的開發范式轉變。在過去，計算的算力有限，沒辦法低成本處理大規模數據，更多是在模型上通過多次迭代調參處理各種過擬合、欠擬合等問題。當時的機器學習訓練非常依賴于數據的準確性，依賴于標注數據的質量，而標注數據的成本是非常高的。在 Transform 模型出現之后，工程師精力的中心從模型的調優轉向了數據質量的提升，不再完全依賴于標注數據的獲取，這時數據平臺的效率就成為了整個開發流水線中的關鍵瓶頸。

最近大家經常說，成功的機器學習項目，80% 來自于數據加工效率的改進，20% 來自于模型的優化。當然沒有算力不行，但光有算力也不行，所以公式就變成了算力+數據+模型。數據部分包括結構化數據處理、非結構化數據處理、海量文件數據處理等等。

大數據 AI 一體化并不是今天才有的課題，已經發展很久了。很多公司都在做的推薦系統就是一個典型的大數據+AI 的工作，要通過數據做標簽化，形成特征庫，訓練推薦模型。推薦模型分很多版本，要不斷迭代，做各種 AB test，反復調整模型再持續上線。有些是離線的模型，有些是在線的，還有的是離在線一體的。

上圖中就是典型的實現路徑，也是阿里云上最經典的解決方案，包括用 Flink 處理標簽實時加工，通過 MaxCompute 處理離線批量數據，然后通過 PAI-TF 進行在線訓練。訓練出的模型在線服務之后要做指標實時采集，以及多維度對比分析，多數交互式分析的場景使用 Hologres 這樣的 OLAP 工具，支持秒級的快速查詢響應。

近一年時間里大模型成為焦點，使用大模型的一個典型場景是各種公司都在建設專屬知識庫。阿里云的網站也做了類似的工作，在每個工單控制臺會有一個提問按鈕，以前提問的背后都是真人在服務，服務響應時間無法保證，現在工單第一輪會是智能機器人在服務，它可以針對上下文和產品知識庫，為用戶提供最有相關性、更準確、更及時的回答。

具體做法是把相關的技術文檔、產品使用文檔做向量化處理，輸入到向量數據庫。當用戶提出問題，會把問題做一定的改寫使其上下文更加豐富，并與向量數據庫做近似度匹配計算，把問題最相關的上下文文檔信息抽取出來，再把這些文檔一起喂給大模型，讓大模型基于這些上下文相關文檔輸出一份準確的、可理解的、有上下文的、可解讀的回答。在這個基本的流程中涉及到的技術包括了文本處理、向量數據庫、大模型等等。

然而實現這樣一個系統并不容易，要同時考慮成本、效率、運維等多方因素，會遇到很多問題。第一個問題是研發階段割裂感非常強，做數據的人和做 AI 的人往往屬于不同的團隊，使用不同的平臺和不同的開發語言，大家互相交流很困難。數據人喜歡做數倉、做結構化，聚焦元數據生產。而AI 同學往往基于 Python 開發語言在單機上做開發，開發之后與數據不再做閉環交互，導致這份數據往往是單向流動，造成很多的數據割裂。

其次，效率也是個問題。大數據同學非常擅長處理并行化分布式的問題，AI 同學往往更擅長怎么把模型調參，在單機上跑足夠好。但如今重要的點不再是模型是否要反復調優，而是數據處理的量要上幾個數量級，這時單機的算子是否還能適合新的場景，就是很大的問題，可能會遇到性能的瓶頸。

第三個是工程化的問題。過去公司數據平臺，AI 平臺往往是因為不同的場景，不同的目的采購不同的供應商，平臺之間很難打通。很多公司采購了很多系統，用不同賬號，不同權限，被不同人運維，這樣會把公司平臺的脆弱性全部暴露出來。

最后是數據管理能力，這是整個項目的核心。由于系統上的割裂，很難看到一個全局的、統一的數據的治理能力。大數據平臺和 AI 開發平臺的元數據割裂也是不容易解決的問題。

大數據 AI 一體化就是要解決上述問題。大數據平臺要做好幾件事情，包括統一的元數據管理，大規模的數據處理能力，分布式計算的算子，以及提供豐富的、海量的、彈性的計算資源。AI 平臺要提供統一的模型管理，可視化的建模流程，分布式的訓練環境，以及豐富的 GPU 的資源。大數據與 AI 的結合就是一個互相支撐的過程，大數據平臺要為 AI 平臺做好數據支撐，AI 平臺則通過智能化的算法，讓數據平臺更好用。接下來將介紹阿里云在數據支撐和算法優化上所做的工作。

二、阿里云大數據 AI 一體化架構演進

上圖展示了阿里云所提供的解決方案，包括了基礎的資源層，中間的大數據 AI 一體化 PaaS 平臺服務層，上層的模型服務層，最后是應用層。其中大部分應用和模型來自于我們的合作伙伴，藍色的部分是阿里云原生的產品和服務，本文重點介紹的是其中數據平臺的部分，在豐富的計算資源之上提供一個易用的可擴展的數據處理平臺，同時和 AI 機器學習平臺 PAI 集成、打通。

數據平臺核心的部分是 MaxCompute，以前的名字叫 ODPS，即 Open Data Processing Service，其中包含兩個主要的引擎，一個就是離線數倉 MaxCompute，另一個是實時數倉 Hologres。MaxCompute 是一款比 Spark 更易用，執行效率更高，企業級能力更豐富的大數據平臺。

MaxCompute 經歷了 15 年的迭代發展，在不同階段，著力解決的重點問題是有差異的。最早 09 年開始做這款產品的時候，是因為阿里集團內部有海量的數據要做分析，既要替換 Oracle 降低成本，又需要很強的擴展性，支持當時業務的快速發展。當時做了 5K 項目，也就是單集群超過 5000 個節點，解決集群的可擴展問題，從此數據量不再是瓶頸。

17 年之后，開始做公有云服務，做 Serverless，這實際上是對運維方式的一個本質性變革。其背后的挑戰非常大，比如升級怎么做到業務無感，無中斷，怎么做到流量分配均衡，怎么做到灰度和回滾等等。Serverless 背后是租戶體系的改革，一個集群服務一個 Region 所有的用戶，所有類型的作業。

第三個階段是湖倉一體的改造。這個時候我們發現結構化數據已經無法滿足用戶的靈活性需求，有很多非結構化、半結構化的數據需要管理和加工，有很多第三方的 Hadoop 集群需要被托管，需要更有質量的數據治理，我們提出了湖倉一體的架構，可以把基于開放存儲，使用開放格式的數據統一納管到 MaxCompute 的元數據體系下。同時也做了離線實時一體，一個在線的交互式分析引擎 Hologres 和一個離線數據加工引擎 MaxCompute 之間的元數據和數據之間的集成。

從 2023 年開始走向下一個階段。這一階段的一個特征是我們提出了開放架構，我們希望數倉應該是開放的、多元的，在數倉存儲層提供一個 MaxCompute Storage API，第三方的計算引擎可以直接以原生的、底層的、高吞吐的方式訪問數倉里的數據。過去數倉是為性能優化設計的，但今天不再是封閉的。其次我們也提出了 Data+AI 這樣一個解決方案，稍后會大家做進一步解析。

MaxCompute 的核心形態是完全的 Serverless。上圖是來自于 Gartner 的分析報告，Serverless 分很多級別，體現在對資源共享的力度不同。從最原始的機器層面上的機器資源共享，到后來操作系統層面的共享、容器層面的共享、應用層的共享、租戶的共享。一層層共享力度的提升，背后對于服務提供方來說，技術難度都是一個指數級的提升，但是對用戶來說，收益則會越來越大。通過資源復用，有機會把整個服務的成本降得足夠低，給用戶更低價格的計算服務。這對資源隔離要求更高，做系統升級的難度也更大。

MaxCompute 從設計之初就被定位為一個 serverless 的產品，只有把運維效率解決好，提高資源利用率，才能提供更有競爭力的數據計算服務。除了成本之外，還有另外一個好處就是彈性。特別在機器學習場景下，只在部分時間有大量的資源需求，如果采購一臺機器，有大部分時間閑置，是巨大的浪費。所以機器學習場景下對 Serverless 服務有很強的訴求。

接下來給大家講講 Data+AI 的解決方案，MaxCompute 針對 AI 場景的創新主要包括以下幾大方面。

• 首先是在數據管理層面上。數倉是很擅長處理結構化數據的，但是在機器學習場景下，有大量的非結構化數據、文件數據、圖像數據等等，所以我們在非結構化數據的管理上有了一些創新，引入了 Object Table 這種新型的表類型。
• 其次是計算框架，我們推出了針對 Python 開發的分布式執行框架 MaxFrame。過去數據平臺往往是提供 SQL 接口來開發，但數據科學家們最習慣使用 Python 及各類 Python 開源工具包。通過 MaxFrame，MaxCompute 數據平臺提供了 SQL+Python 雙引擎的能力，Python 成為數據平臺的一級開發語言。
• 第三是提供了交互式的 Notebook 開發環境，這也是 AI 同學非常喜歡的開發環境，在 Notebook 里邊可以做交互式的驗證和作業分享。
• 最后是鏡像管理。Python 開發中版本管理、鏡像打包等一系列的工程問題也是效率的關鍵。

數據管理能力的演進分為幾個階段。

第一個階段解決聯邦問題，當數據交互雙方使用不同引擎時，數據是否可以兼容，讓數據不搬遷，就可以實現聯邦查詢。希望以聯邦為中心，打通元數據管理，給用戶統一的元數據視圖和權限管理。

第二個階段，僅有聯邦不夠，希望不同的存儲格式，可以放在湖上提供一份數據多引擎的能力，所以第二階段做了湖倉一體的能力，提高數據的易用性，提供原生的查詢的能力和元數據的管理能力。

第三個階段，越來越多的用戶提出非結構化數據管理的需求。大量非結構化數據作為輸入給很多 Python library 進行向量化轉化，但是這些文件背后缺乏一個元數據管理能力，也很難進行分布式計算，因此我們做了 Object Table 來解決這個問題。

Object Table 是一種新的表類型，用來處理非結構化數據。其中存儲的是非結構化數據的元數據，而不是數據本身。存儲的元數據包括文件的路徑、文件名、文件的大小、更新時間等等，還有不少可擴展的 tag 值。

基于這些元數據可以做很多提升開發效率的事情，假如有 1000 萬個文件，要交給一個大數據平臺，希望平臺可以并行化處理這些文件，從 PDF 文件抽取文本。一種簡單的做法是一個文件啟動一個進程，但是對于 1000 萬個文件就要啟動 1000 萬個進程，調度上開銷非常大。如果這些文件里邊有些文件可以跳過，可以忽略，比如太小的文件不打開，很長時間沒人動的文件可以跳過，其實有很多需要對元數據過濾的場景，過去沒有元數據信息，很難做這件事情，但現在表里面有元信息就可以處理。

還有就是并行化處理的問題，一個進程處理一個文件，還是一個進程處理 10 個文件，對吞吐的影響是非常大的，過去沒有元信息很難做，但現在有元信息之后 worker 可以進行判斷。假設一個 worker 可以處理 100 兆數據，就可以把 100 兆數據以批量的形式作為輸入傳給一個進程 worker 并行化處理，這樣整體處理的吞吐量會有本質性的提升，這也是工程化非常常見的做法。

除了這些元數據管理之外，還有很多性能上的優化，比如在海量小文件、碎片文件處理上有幾十倍的提效，在單一大文件的訪問 IO 上的也做了提效。

第二大創新是 MaxFrame，把 Python 的開發體驗做到原生化。我們希望給用戶的心智是，在單機上本地開發的 Python 程序，基于主流的 Pandas 接口開發的，可以 100% 透明的遷移到 MaxFrame 平臺之上，可以享受平臺上可擴展的計算算力，MaxFrame 提供并行化的計算能力。

用戶寫的 Python code 并不是針對分布場景，而是針對單機場景寫的。但數據的輸入來自于 MaxCompute 表的輸入，MaxFrame 會將算子并行化，運行在不同的分布式節點之上，這也意味著在單機上跑的 Python 的作業，以前要運行幾十個小時，現在可能僅需幾十分鐘，甚至更快。MaxFrame 的核心理念就是讓使用 Pandas 接口開發的數據分析、數據加工的程序，可以無縫的、透明的遷移到大數據平臺上。同時平臺做到了跟 MaxCompute 底層數據的原生打通，可以高吞吐、高效率的方式訪問所有數據，不只是讀也包括寫。

上圖左側是 Pandas 算子，包含表連接、關聯、過濾、聚合等等，幾乎所有的數據分析常見的 Pandas 算子都支持。右邊是機器學習平臺數據處理部分的 55 個算子，有大量的文本處理、文本過濾、文本去重、文本計數等等，都是 MaxFrame 原生支持的算子。這些算子背后都做了性能和可擴展性支持，用戶使用起來會非常簡單。

這里是一個對比的例子，左側是開源的 RedPajama，在大模型場景下，端到端的，從數據的采集加工處理，到產出結果等七八個環節，每個環節有不同算子，以前是單機運行，跑這一流程得需要 59 個小時。轉成 MaxFrame 之后僅用 1.3 小時即可跑完，對效率提升是非常明顯的。

Python 開發非常依賴于不同的版本管理，鏡像管理。一份作業里會依賴幾十個不同的 library，所以我們做了一套鏡像管理，包含內置鏡像和自定義鏡像。內置鏡像部分把很多主流的常見的數據分析，數據加工用到的 Python library 都做了內置化，用戶引用就可以了。

講完加工的環節之后，接下來介紹數據服務環節，以向量檢索服務為例。這兩年向量數據庫特別火，但業界常存在一個困惑就是每家公司是應該采購一個專屬的向量數據庫，還是選一款帶有向量擴展能力的通用分析數據庫。我們看到主流的云廠商大多采用后者，數據庫增加向量化檢索能力，通過與原生的 OLAP 能力結合，場景更豐富、開發更易用，用戶使用門檻更低。阿里云也是采用這種方式。

Hologres 是一款分布式的高性能的 OLAP 引擎。在 2020，Hologres 與達摩院合作，將高性能的向量化引擎 Proxima 集成到 SQL 引擎中，提供 SQL 查詢接口。Proxima，性能優異，精度也高，計算效率非常快，內置多種檢索的算法。

當 Proxima 和 Hologres 結合在一起的時候，就能夠把 Hologres 強大的性能充分發揮出來。Hologres 是一個面向高并發、低延遲場景設計的一個 OLAP 引擎，性能可以做到毫秒級的響應。同時也滿足了易用性要求，因為不需要學習新的接口，就是 SQL 接口，對于數據同學來說非常容易使用。

向量這件事情其實并不復雜，是把文本、圖片等轉化為向量數組，存儲在數據庫表中的一個字段，Hologres 在底層自動構建各類向量索引。向量計算廣泛應用在推薦引擎，大模型推理等。

數據庫和向量融合在一起的好處在哪里呢？以前向量引擎只能做向量查詢，數據庫只能做結構化查詢，現在把向量和數據庫放在一起，既可以做結構化的過濾，也可以做向量化檢索，所以 SQL 語句寫起來就很簡單，很多以前必須在專業的向量數據庫里做的事情，現在在一個通用數據庫里面就做好了，一個 SQL 實現向量檢索、過濾、排序、去重等操作，真正實現了一個引擎，一份數據，多個場景。

以上介紹了數據平臺如何為 AI 提供支持，是 Data for AI 的視角，那么反過來 AI 平臺怎么讓數據平臺變得更好用呢？今天所有的數據分析都在從 BI 演化到 BI 加 AI 的場景。

Copilot 從去年開始變為主流，NL2SQL 是常見場景，它可以幫用戶寫 SQL，幫助用戶找表，幫助用戶更容易地診斷出 SQL 的錯誤。阿里云推出了 DataWorks Copilot，在背后，工程師把很多 SQL 語料喂給 Copilot 的模型，希望產出一個好用的，更智能的 SQL Copilot 能力。

除了寫 SQL 的開發階段之外，分析階段更為重要，所以 DataWorks 和 DataV 也在做合作實現增強分析，這意味著過去以經驗為主的分析范式，將轉化為由機器做推斷。增強分析，可以自動生成各種洞察，不同的報表，不同的視圖，不同的看數角度。

三、Data+AI 場景實踐分享

最后通過具體場景實踐來介紹一下數據平臺怎么用。

這是通義大模型的一個加工場景的簡化版本，主要是在處理文本去重。主要環節包括數據采集、讀取、處理到模型訓練。中間有很多小的環節，比如文本的去重、敏感詞的過濾、copy write 刪除、文本標準化等等，依賴了很多不同的 Python library。

文本去重的基本流程是，先做分詞，之后計算哈希值，然后求哈希近鄰。

我們的做法是，首先把依賴鏡像做一個好的鏡像管理，這個鏡像里邊的用戶很多依賴第三方的 library。不同的 python 的版本，不同 library 版本，大家要有共享的開發環境，所以首先要做鏡像管理，把這些依賴鏡像做成一個團隊內可以共享的。

之后是開發環節。右側部分是一段 demo 代碼，這段代碼最后不超過 100 行。初始化依賴 4-5 行代碼，初始化框架資源，身份認證，就可以有幾行代碼做數據過濾，再有幾行代碼做分詞，背后通過 Pandas 開發接口。Pandas 接口里邊有各種各樣的數據轉換邏輯。這 100 行代碼，可以跑在幾乎無限擴展的計算平臺之上，我們希望實現的效果是可以用小代碼快速迭代的方式，在更規模化計算平臺上處理規模化的問題。分布式怎么調度，怎么容錯，數據該怎么切分，怎么做并行化的切分，大量類似的工程化細節都由底層的大數據平臺來完成，可以大大提升效率。

如果不喜歡寫代碼，也可以用拖拽的方式，平臺提供了一個可拖拽的 pipeline 的組合方式，可以把整個計算流程中不同的算子以拖拽的方式組合在一起。

從通用場景來看，絕大部分性能都有 70% 到 90% 的提升，數據量越大，提升越明顯。同時環境準備方面，我們反復強調工程一定要提效率，效率不一定都是計算效率，往往開發、調試、環境準備會占用大量的精力，我們希望通過平臺來減少這部分的工作量，我們的數據平臺在這方面也實現了很好的效果。

最后對大數據AI 一體化的工作進行一下總結。在本次分享中沒有專門講大數據做哪些事，也沒有專門講 AI 做哪些事，更多的是討論二者如何更好地集成。阿里云大數據平臺 MaxCompute 做了非結構化的元數據管理，支持 Python 開發語言，也讓 Python 可以跑在并行化的運行環境里邊。還做了大量 IO 的優化，調度的優化，提供了很好的 notebook 交互式的開發環境，提供了鏡像管理的能力。這些工程化能力實現之后，可以實現大數據和 AI 之間的數據一體化、權限一體化和開發界面上的一體化。通過這些一體化，可以讓 AI 同學更熟悉數據平臺，也讓數據平臺同學可以更快地上手 AI 應用。這正是我們希望實現的效果。