極客傳媒：2023年度技術盤點與展望報告AIGC熱潮下的技術與行業百態（249頁）.pdf

《極客傳媒：2023年度技術盤點與展望報告AIGC熱潮下的技術與行業百態（249頁）.pdf》由會員分享，可在線閱讀，更多相關《極客傳媒：2023年度技術盤點與展望報告AIGC熱潮下的技術與行業百態（249頁）.pdf（249頁珍藏版）》請在三個皮匠報告上搜索。

1、 目錄目錄 卷首語 綜述 今年技術除了AIGC真沒啥看頭？別讓“網紅效應”遮住了真正的創新！.1 2023年度技術盤點 爭議與熱度并存，越來越多開發者正在拋棄他們的舊語言轉向Rust.17 你當初被誰“忽悠”上了云，現在又在被誰“忽悠”下云？.24 挑戰Spark和Flink？大數據技術棧的突圍和戰爭.36 WebAssembly 2023年回顧與2024年展望.49 并發王座易主？Java 21虛擬線程強勢崛起，Go&Kotlin還穩得住嗎？.60 Andy教授2023年數據庫回顧：向量數據庫沒有技術護城河！沒人能靠技術大佬背書“假裝成功”.71 顛覆軟件工程、“殺死”開發者？回溯大模型落地

2、應用這一年.83 今年向量數據庫“殺瘋了”，但純向量數據庫“涼”了？.93 金融業采用大模型，是“用大炮轟蚊子”嗎？.104 大模型時代，我們可以用Julia做什么？.114 既怕“錯過”又怕“錯付”，數字化投入與產出該如何量化.122 國產編程語言新拐點：聊聊從Mojo到MoonBit的思考.130 2023年十大數字化政策盤點：激活萬億數據，加速提升千行百業數字化服務.154 2024技術人如何迎接大模型時代 代碼人生攻略：程序員們如何為自己編織一份明朗未來？.162 大模型時代下的技術管理“新思維”.191 2024年入局大模型，晚了嗎？.211 大模型應用成本百萬級起步，該如何與企業現

3、有信息系統融合？.225 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 卷首語卷首語 作者：InfoQ編輯部 過去一年，我們經歷了許多意外瞬間，或許當時我們感到有些措手不及，但如今再回首，一切都變得一目了然。這正是我們每年對各領域進行盤點的意義所在，我們追求的是在迷霧中找到清晰的方向。而在2023年，這一盤點顯得更為特殊。比爾蓋茨指出，過去12個月人工智能領域發生的事情“與個人電腦或互聯網一樣重要”。大模型項目在過去一年中如雨后春筍般涌現，這波創新浪潮給各領域都帶來了巨大的變化。在2023年結束之際，InfoQ編輯部重磅推出了一年一次的“年度技術盤點與展望”專題，

4、聚焦AIGC引發的變革，與50多位頭部專家深度對話，細數過去一年不同領域的創新和進展，希望能為你揭示未來技術發展方向，明晰不同行業大模型應用思路和路徑。同時，我們圍繞“2024技術人如何迎接大模型時代”主題，邀請10+位專家進行直播對話，探討不同崗位的技術人/數字化人才，如何應對大模型時代帶來的新變化、新挑戰，2024年需要聚焦什么方向、做好哪些準備等。在這場盤點中，我們也收獲了關于技術圈的2023、2024的許多精彩觀點和認知，比如：2023年，大前端領域的各種語言和技術邊界都在面臨打破和重建；在性能和應用元框架領域，大前端技術處處都在孕育著新的可能性；國產自研終端OS的爆發，將能打破國內移

5、動原生軟件平臺生態雙足鼎立的現狀，對國內大前端領域從框架到工程到行業分工提出新的機遇和挑戰，而鴻蒙與安卓徹底分家，雖然會帶來生態體驗的風險，但也代表著新崗位的出現；2023年，Golang成為國內諸多大廠主流或最熱門的編程語言，Golang相關的開源中間件生態繁榮，競爭加??；Rust成為最有潛力的編程語言，諸多大廠紛紛投資入局，新的Rust微服務框架如Volo推動Rust在企業內部更廣泛落地；AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 2023年，在大模型技術的加持下，編碼工具能力邊界得到了進一步拓展，2024年，基于大模型的編程能力的工具軟件將逐漸落地，越來越多的開發者將開

6、始使用大模型進行輔助編程；2024年，向量數據庫會弱化為數據庫索引特性，通過一體化能力與其他數據庫系統集成，而從技術和需求來看，傳統數據庫均會快速具備向量特性；2024年，可以期待AI在架構領域應用增多：AI技術將更廣泛地用于架構設計，包括AI輔助設計、決策支持與建議、智能監控等方面，從而提高架構設計的智能水平；20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 綜綜 述述 1 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 今年技術除了今年技術除了AIGCAIGC真沒啥看頭？別讓“網紅真沒啥看頭？別讓“網紅效應”遮住了真正的創新！效應”遮住了真正的創新！

7、作者：Tina、褚杏娟 過去一年，我們經歷了許多意外瞬間，或許當時我們感到有些措手不及，但現在回首一望，這一切都變得一目了然。這正是我們每年對各領域進行盤點的意義所在，我們追求的是在迷霧中找到清晰的方向。而在2023年，這一盤點顯得更為特殊。比爾蓋茨指出，過去12個月人工智能領域發生的事情“與個人電腦或互聯網一樣重要”。大模型項目在過去一年中如雨后春筍般涌現，這波創新浪潮給各領域都帶來了巨大的變化。然而，除了AIGC領域取得的突破外，在前端、架構、運維和云計算等領域中，也涌現了一系列引人矚目的進步和革新。在年終盤點之際，InfoQ邀請到了黃玄（黃玄（Hux）、曹立成）、曹立成（蒜蓉）、羅廣明、

8、董曉聰、楊振濤、張凱（蒜蓉）、羅廣明、董曉聰、楊振濤、張凱，分享在過去一年中各自領域的創新和進展，2 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 為我們揭示未來技術發展方向。前前端遇到麻煩了嗎？端遇到麻煩了嗎？前兩三年，前端技術的發展相對平穩，主要以React、Vue等成熟框架的演進為主。但今年，前端技術的發展呈現出新的活力。編編程技術的多樣化程技術的多樣化 相比于過去“各司其職”井水不犯河水的光景，今年大前端領域的各種語言和技術邊界都在面臨打破和重建。新興系統語言Rust、Zig已經通過Rspack、Bun這樣的工具鏈切入到廣大開發者的日常工作中。而WebAs

9、sembly GC的落地，以及Static Hermes這類JavaScript原生化探索，也繼續宣告著大前端技術進一步“下沉”系統的趨勢。另一邊，無論是React Native、Kotlin Multiplatform、Flutter以及國內各大廠自研跨端技術的愈演愈烈，還是Web領域JavaScript框架Next、Remix、Astro、Qwik、Fresh紛紛侵蝕服務端的陣勢，則宣告著大前端技術進一步在應用層“泛化”的趨勢。我們有理由相信，雖然由React，Vue引領的聲明式編程范式趨于穩定，但是在性能和應用元框架領域，大前端技術處處都在孕育著新的可能性，我們說不定就在大前端又一輪百花

10、齊放的前夜。終終端平臺多元化，前端迎來新機遇端平臺多元化，前端迎來新機遇 在劇烈變化的環境下，大家可能會更關注生存問題，2023年，雖然“前端已死”的論調不絕于耳，但這一年也在終端平臺上孕育了新的可能性。去年6月，在一年一度的科技春晚WWDC上，蘋果發布了Vision Pro。目前，蘋果已正式推出Vision Pro應用商店，百萬款App準備上架；去年9月，Meta發布Quest 3，對打蘋果。MR設備設備的發布，表明硅谷并不服氣華爾街資本的短視，依然在為元宇宙成為下一代計算平臺而蓄勢待發，XR與圖形作為大前端的一個垂類，值得軍備和持續關注。小米澎湃OS、vivo藍河BlueOS等國產操作系統

11、先后發布，HarmonyOS NEXT也在去年8月 3 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 華為開發者大會上第一次公開亮相。其中，HarmonyOS NEXT的進展受到大量關注，華為的“1+8+N”戰略，即以手機為核心的全場景智慧化（物聯網）戰略，一旦成功了，未來更多廠商OS都會涌現出來，大家都可以摸著石頭過河。這將能打破國內移動原生軟件平臺生態雙足鼎立的現狀，大概率會像小程序生態的碎片化一樣，對國內大前端領域從框架到工程到行業分工，提出新的機遇和挑戰。鴻鴻蒙大考，你準備好了嗎？蒙大考，你準備好了嗎？今年9月鴻蒙將跟安卓徹底切分，僅支持鴻蒙內核及鴻蒙系統的應用。同時，

12、原生鴻蒙的開發語言以ArkTS為主，不同于iOS開發使用的Swift語言，以及安卓開發使用的Java語言，且不支持打開APK文件，開發環境與IDE深度綁定，這意味著如果使用今年的最新版本，會跟iOS、安卓產生巨大的割裂。開發者需要維護包括iOS、安卓、Web以及鴻蒙在內的四端體驗一致。生態體驗是風險，但這對開發者來說，也代表著新的崗位的出現。在QCon閉門會上，有鴻蒙技術專家透露出一個特別積極的信息：鴻蒙開發供不應求，連外包開發價格都水漲船高。舉例來說，假如原來一位外包價格在兩千元左右，現在只要做過兩個月的鴻蒙功能，價格就翻了一倍。做六個月的，價格可以達到5-6000元以上。他還表示，鴻蒙項目

13、非常受歡迎，只要沾上邊，就會有大批公司去搶人。尤其像美團、京東等公司，開出的價格都很高。鴻蒙官方表示，首批200+鴻蒙原生應用已啟動開發，其中100+完成了鴻蒙原生應用Beta版本。鴻蒙適配之路，協議是第一步。就像蓋房子需要地基一樣，沒有協議作為基礎，開發者就難以下手。設備、教程、專家指導等關鍵資源，都依賴于雙方明確的權利和義務。有企業向InfoQ表示，其與鴻蒙系統的合作目前仍處于前期階段，尚未進入駐場開發環節。目前的工作主要集中在備忘錄簽署和深入調研適配過程所需的開發資源上，包括主應用程序的重寫需求評估等?；谀壳暗难芯?，該企業認為適配鴻蒙系統存在一定難度，部分功能可能需要完全重寫。4 20

14、232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 為應對開發過程中的挑戰，該企業的內部相關團隊已開始進行技術儲備。另一家商業銀行表示已完成其鴻蒙應用的第一版demo，該版本基本涵蓋了應用所需的功能，得益于采用了類似于H5的開發方式，使得大部分功能得以順暢實現。然而，正如28定律所言，剩余的20%難題往往占據了80%的時間和精力。在該案例中，最大的挑戰在于SDK適配，比如存在一些使用了不同企業的技術的SDK。該銀行接下來將專注于解決這一問題，對接SDK并對每個業務進行深度調試，以確保應用的穩定性和功能完整性。AI會取代前端開發嗎？會取代前端開發嗎？當然，今年的一切“之最”都

15、離不開2023年作為“生成式AI元年”帶來的顛覆性變革，前端也不例外。大家都在研究怎么把這個黑科技融入工作流，讓開發效率飛升。不過，也有不少人心里打鼓：“AI不會把我這份前端飯碗端走吧？”雖然今年還不用擔心失業危機，但不可否認，AI確實為前端打開了一扇大門，潛力巨大！一方面，前端工作流程中的諸多環節，包括PRD到代碼，從設計到代碼，或者是Github Copilot、Vercel的v0這樣的AI輔助開發，注定它會成為整個行業提效的重要手段。另一方面，AI也可以用來解決大前端面對的問題：前端本質上解決的是將信息映射為用戶可以理解和交互的表現形式的過程，它在傳統上非常依賴我們進行離線化和靜態化的分

16、析（比如產品經理的需求分析、交互與界面的設計、軟件的硬編碼等），而AI為這整個流程帶來了一種實時在線的、動態化的可能。另外，隨著大模型興起，也有了一些AI native獨立端開發，豆包、通義都有在做這種純UI的應用。5 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 截圖為“高級前端開發工程師-大模型應用崗位要求”雖然現在的大趨勢還是超級App，但移動互聯網進入一個后期階段后，就是朝著消費者的端智能的方向了。有有更好的架構方法了嗎更好的架構方法了嗎 去年3月，谷歌開源了一個名叫Service Weaver的框架。它能夠實現簡化本地開發，并將模塊化單體應用轉變為分布式微服務架構，在

17、部署時允許自由配置組件的分布式部署方式，從而應對應用演進過程中的不確定性，并輕松適應組件間交互模式的變化。Jeff Dean也曾發推稱這是他的許多同事，包括其長期合作者Sanjay Ghemaway開發的系統。谷歌描述了構建微服務架構的挑戰：“維護多個不同的微服務二進制文件的開銷顯著降低了開發速度”、“分布式系統的問題（故障處理、廣泛變化的延遲等）不會神奇地消失”。在去年6月份發布的論文中，谷歌稱基于新提出的結構，他們能夠將系統的延遲降低15倍，成本降低9倍。無獨有偶，同樣在去年3月，AWS也分享了一個案例，Prime Video團隊將他們的Server-less應用中的部分微服務調整成為了一

18、個單體，稱此舉節省了90%的運營成本。谷歌和AWS的這波操作，跟過去十年大部分應用的開發思路反著來的：利用微服務邊界進行快速本地開發；保證隔離，以便服務在運送到生產環境時可以組合；將微服務捆綁成大型二進制文件，以簡化生產管理和相關服務的并置。6 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 這究竟是架構方法的革新，還是對取舍空間的進一步探索？Service Weaver并不是微服務的“解”并不是微服務的“解”從2017年起，微服務進入成熟階段，微服務改造依然是當前趨勢。隨著互聯網業務需求的增長，覆蓋度和精細程度不斷提高，維護一個模塊需要數十人，協同合作出現巨大問題

19、，需要專人負責代碼合并，并選擇一天統一上線。線上運行中，功能流量差異大，一旦出現故障影響全局。解決這些問題的解法很簡單也很復雜。簡單說的是問題域大了，拆分成小的，問題自然就得到解決了。這就是微服務化。復雜說的是，拆分的原則沒那么簡單。原來的拆分從上而下，按產品按項目拆分即可，更多是組織決策就可以，技術架構的考量因素不多。但現在是要對一個相對比較原子的事物進行拆分，就必須對他所在的領域、公司業務所處的發展階段、未來發展的重點、團隊人員的能力等諸多因素綜合考慮，才能得出拆分的方案。這也是微服務架構的魅力所在，也是業務架構師的核心價值所在。這也是微服務架構的魅力所在，也是業務架構師的核心價值所在。微

20、服務改造是大勢所趨，但引入了新問題。在單體架構下，對服務治理體系的要求較低，通信簡單，服務感知和流量管控需求有限。然而，微服務模式中，每個請求會構建復雜的調用樹，樹上的節點幾十幾百起很正常。在這種模式下，再沒有服務治理體系的化，研發效率會極大幅度降低。服務治理的整個體系，甚至其子體系都開始蓬勃發展，也衍生出不少流派。以注冊發現為例，有基于客戶端負載的模式，也有基于中心負載的模式。各種組件也是層出不窮，如zookeeper、consul、etcd等。微服務引起的問題不僅限于上述，服務數量增加必然導致人員需求上升。雖然效率工具可能改變人員與服務的關系，但趨勢仍是增加。由于微服務拆分沒有統一解決方案

21、，每個企業和部門的架構師根據不同條件做決策，可能導致超前設計。一旦企業進入了降本增效的階段，就會打破原本人員數量和服務數量的平衡。這時候微服務就會成為企業的技術負擔。因此，一些企業選擇回歸單體架構，并取得顯著成果。對于常用而拆分過度的服務，需要考慮合并方案，但目前尚未出現一個統一的解決方案。Service Weaver提供了一種全新的開發與部署解決方案，其最大的特點就是提供了一種靈活性和可配置性，對于業務的演進非常友好，可以靈活調整部署模式，來實現成本優化 7 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 和價值最大化。但是，這種架構模式并不適應于已經落地了微服務架構的業務，也

22、不適應于已經比較穩定的業務，更不適應于對于性能要求極高的業務。反過來說，Service Weaver對于尚處于快速發展的互聯網在線業務比較友好，允許應用程序隨著時間的推移進行低成本演進。2023年架構領域的關鍵進展年架構領域的關鍵進展 架構領域一直在不斷演進和更新，在2023年，一些關鍵框架和組件經歷了重要的更新或者取得了進展：服務網格：更加成熟的實現和標準化。繼Proxyless Mesh，Istio今年推出Ambient Mesh模式，并正式從CNCF畢業，成為CNCF活躍度排名第三的項目。開發框架：更多適用生產環境微服務架構的開發框架。以Kitex/Hertz為例的微服務框架更加關注企業

23、用戶在生產環境的落地和使用反饋，關注易用性和降本增效成為框架選型的主流意見。編程語言與生態：Golang成為國內諸多大廠主流或最熱門的編程語言，Golang相關的開源中間件生態繁榮，競爭加??；Rust成為最有潛力的編程語言，諸多大廠紛紛投資入局，新的Rust微服務框架如Volo推動Rust在企業內部更廣泛落地。據觀察，前兩年比較火的云原生可移植性設計Dapr框架在國內并沒有得到廣泛的采用。與服務網格相比，Dapr架構更加復雜，Dapr的工作模式是能力抽象，需要業務應用程序遵從標準API進行請求開發與改造。服務網格主要設計目標是低侵入，采用原協議轉發的方式可以盡可能的降低對應用的侵入。Dapr的

24、主要設計目標是可移植性，即在跨云跨平臺的前提下實現無廠商綁定，采用的方式是在將分布式能力抽象為標準API，并在各種開源項目和云平臺上提供這套標準API的不同實現，從而達到在不同平臺上運行的目標。因此Dapr的代價是需要應用進行適配和改造，侵入性比較大。因此Dapr更適合新應用開發（Green Field），對于現有的老應用（Brown Field）則需要付出較高的改造代價。這也是Dapr當前并未獲得廣泛采用的主要原因。雖然Dapr和類似的框架提供了許多優勢和新穎的特性，未來仍需要更多時間、成熟度和社區的支持。在面對已有系統、組織慣例和技術選型方面，新框架的采用需要認真權衡 8 20232023

25、年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 其優勢與現有解決方案的差異，并選擇最適合的方案。AIGC來了，架構師崗位會受影響嗎來了，架構師崗位會受影響嗎 架構師就像是整個系統的設計大師，負責操刀整個系統架構的規劃。這個規劃不僅僅包括技術選型、架構模式、演進變化，還得考慮業務需求、團隊能力、可運維性、成本等一系列不那么技術的要素?，F在，架構決策很大程度上還依賴于人的經驗和直覺，但如果我們能把設計和變更都記錄得明明白白，把架構知識管理搞得井井有條，那么人工智能豈不是能搞定架構領域的一部分工作？這還是未知數。AI原生應用的發展現在還處于初級階段，雖然我們還沒看到AI在軟件架構和設計上

26、有多大的影響，但我們不能否認一點，AI肯定會給這個領域帶來各種有趣的變革。比方說，AI可以幫我們提高決策效率、優化設計、增強系統的自適應性和安全性，還能更好地適應系統的演化和變化。當然，AI技術在這方面的應用也需要考慮隱私以及技術成熟度等方面的問題。未來，我們可以期待AI在架構領域的應用逐漸增多：AI技術將更廣泛地用于架構設計，包括AI輔助設計、決策支持與建議、智能監控等方面，從而提高架構設計的智能水平?？磥?，未來架構師團隊里可能不只有人類，還可能有人工智能的！運運維困局，平臺工程能否破局？維困局，平臺工程能否破局？有些事情是我們預測不到的，Spotify的Backstage開發者門戶人氣激增

27、。此前被低估的舉措，例如開發者體驗，變得至關重要。云原生技術的加速采用，為軟件交付及運行態的保障持續產生著深刻的影響，比如開發與運維的邊界持續模糊，從而導致雙方對系統的控制權也同步持續拉扯。隨著大規模DevOps實踐所面臨的復雜度日趨提升，云原生時帶的平臺開發者們正在尋找新的解決思路、探索新的解決方案，平臺工程則成為其中冉冉升起的一顆未來之星！CNCF應用交付TAG在今年先后發布了平臺白皮書平臺白皮書和平臺工程成熟度模型平臺工程成熟度模型，加之咨詢公司對于平臺工程發展趨勢的樂觀預測，讓平臺工程連續兩年進入年度10大新興技術趨勢榜 9 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態

28、 單，并認為中國的平臺工程正在萌芽期。新新框架不斷涌現框架不斷涌現 Backstage正成為一股不可忽視的力量。從具體項目和實踐案例來看，以BackStage為代表的開源項目正趁著內部開發者平臺（IDP）等平臺工程最佳實踐快速發展，現已從CNCF沙箱項目進入孵化階段。Backstage集成了Git倉庫、構建管道、API和基礎設施自動化等關鍵資源，將其無縫整合進一個單一門戶，供所有開發者隨時調用。根據GitHub上的fork信息，梅賽德斯-奔馳、美國航空、愛立信等知名企業早已加入Backstage的行列。從趨勢上看，早期實踐者在組織內部明顯地分化出了應用開發團隊和平臺開發團隊，傳統的運維工程師也

29、經過了SRE實踐階段，分化成為通過運維平臺來工作的專職應用運維和平臺開發者，這在很大程度上驗證了團隊拓撲理論對于實踐的指導意義。從行業共識角度，目前已涌現出CNOE、BACK Stack、KAOPS等框架和實踐指南。其中，CNOE為AWS聯合Adobe、Salesforce等企業推出的一項用于構建內部開發人員平臺(IDP)的開源計劃。BACK Stack，代表Backstage、Argo、Crossplane和Kyverno這四個工具組成的一個強大的組合，可以實現安全且可擴展的自助服務工作流程。而KAOps則提供了一種集成DevOps持續交付和多云服務的創新方法。這些框架為更加系統化地實踐平臺

30、工程奠定了基礎共識度，也有效促進了技術生態的持續發展和相互融合。AI全面入侵：未來的運維工作模式如何進化？全面入侵：未來的運維工作模式如何進化？結合AIGC與AGI的發展趨勢來看，AIOps智能化運維方面的探索已過渡到參考自動駕駛的L0-L5成熟度模型來度量的階段，這使得行業開始從整個軟件的全生命周期來思考AI的賦能和提效。涉及的領域包括需求工程、設計開發、構建與集成、質量保障、持續發布與運行維護、故障分析定位等。業界甚至提出了一個面向未來的、由不同技術方向的AI Agent組成的開發團隊的構想。這些前期的探索和暢想仍然強調了開發過程的標準化和資源的平臺化，要求整個軟件研發過程都能夠友好地與A

31、I協同工作。在這方面，來自 10 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 Vercel的v0.dev是一個典型代表產品，它能夠根據自然語言指令生成即時可視的前端頁面，并自動部署到Vercel服務上。在接下來的2024年，我們預測平臺工程理念以及實踐將更進一步隨著云原生技術的加速采納而深刻影響軟件交付與運行保障，DevOps理念中的左移將進一步發展為左移結合下移，平臺的價值會得到更大程度的重視，認知負荷過重的現象對于開發和運維角色來說將會有一定緩解。同時，結合AIGC與AGI的發展趨勢，以AIOps、知識庫與問答機器人、流程機器人、代碼生成等為代表的應用場景將

32、進一步得到深化和拓展，為整個軟件工程行業帶來效率提升；至于軟件研發模式方面，短期內依然會保持現狀，但我們不得不在軟件設計方面考慮到面向AI的API。云云計算的新戰場計算的新戰場 今年，受益于AIGC的快速發展，云計算領域的主題基本都是圍繞助力AIGC來做能力提升。從用戶群體來看，云計算和大模型用戶沒有很大差異，但關注點會有不同。比如大模型廠商或創業公司最為關注資源的交付；而有的企業是希望在自有產品中快速部署已有的成熟模型，并快速驗證；更小眾的用戶則更關注LLM等生成式AI模型本身的發展，不僅要高效使用資源，還要借助云原生能力將模型能力轉化為自己的SaaS服務，繼而對外售賣或提供智能服務?？傊?，

33、除了傳統云原生客戶，這些新用戶的成熟度更高。他們目的是探索AI帶來加速業務創新的可能性。還有在支持大模型生產和落地方面進行的能力和需求沉淀，也促進了云計算自身的新一輪迭代。云云原生原生AI，更重資源效率和工程化交付效率，更重資源效率和工程化交付效率 云原生與AI結合領域被業內稱為云原生AI，目標是利用云原生的標準化、可擴展性、彈性等技術優勢，為AI模型生成加速，為AI服務交付提效。主要包括下面三部分：IaaS資源層，包括高性能存儲、計算、網絡等基礎設施。工程平臺，包括云原生和以容器化形式交付的云原生AI，提供基礎異構資源的調度和 11 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百

34、態 任務管理、對各種AI計算框架的支持、MLOps生命周期管理、模型開發，訓練和推理，以及后續服務化的運維等。AI PaaS平臺，用一站式的用戶體驗，構建、訓練，部署和管理數據，模型和服務。首先，對于IaaS層來說，AI為其帶來了規模、性能和效率方面的挑戰。為了訓練出一個對通用知識或專業領域知識有相當理解和推理能力的大模型，模型參數量往往會超過百億，甚至千億。這就需要高達萬卡GPU集群的算力管理規模；爆炸的數據量將存儲提高到了PB級、吞吐達到TB/s級；網絡進入到800Gbps，甚至達到單機3.2Tbps RDMA這樣的高性能要求。為此，在計算上，各家都在卷GPU芯片。一定程度上，對于像大模型

35、廠商這樣對算力要求極大的用戶來說，芯片儲備成為選擇云廠商的首要考慮因素。但是GPU的選擇很少，國外基本只有英偉達。但在新禁令情況下，國內各廠商基本很難拿到高性能卡，只能尋求性價比高的閹割版或國產化替代，這更加大了國內自研芯片方面的力度。但是，目前這些措施，對于高性能卡缺失帶來的市場彌補有限，很多自研芯片更多是廠商內部使用。網絡方面，廠商的做法更是簡單粗暴：資金充足就用InfiniBand（無限帶寬），不足就用RoCE（RDMA over Converged Ethernet）。國內外基本都是滿配單機從800G到3.2T的標配、集群彈性支持幾萬卡的規模。各家也有自研高性能網絡項目，在做產品化和商

36、業化的嘗試。存儲方面則是在傳統架構的分布式文件系統，或者并行文件系統上進行自研增強。但這種模式在大模型應用中，先前的高性能存儲還不太適用聚合帶寬壓力驟增的場景。傳統存儲是通過橫向容量擴展提升帶寬能力，這會帶來成本的增加。也有不少用戶在嘗試基于彈性更好，更廉價的對象存儲服務的方案。但仍需要大幅優化訓練場景下的數據訪問速度。因此在架構上，今年較為明顯的一個趨勢是各廠商尤為關注數據緩存層的構建。當然，根據模型的參數規模、數據量、預訓練還是微調等的不同，大模型對底層基礎設施的需求也不一樣。具體到預訓練來說，國內各廠的基本做法就是網絡帶寬、單機滿卡滿配形成萬卡乃至更大的十萬卡集群，而高精度的網絡拓撲則從

37、原先的三層壓縮至兩層，從而增加可擴展性并減少跳數。12 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 傳統的資源交付多以特定規格實例的形式進行，通過配置網絡、存儲、計算等資源方面的需求，在虛擬機或容器實例層面進行集群管理和任務編排調度。但目前AI的計算資源類型在性能與成本方面有很高提升，傳統交付形式意味著使用者需要自行把控資源的利用率，并且可能帶來較高的TCO(total cost of wonership)。因此，業界也在尋求更為極致的（以秒級)按需彈性交付和計量方式。目前，Serverless是業內較為推崇的資源交付形式。Serverless可以彈性優化資源利

38、用情況，根據資源的真正使用情況自動擴縮容，減輕使用者對集群管理、環境一致性、健康狀況檢查、錯誤處理等底層資源運維的負擔。但是，這種只購買資源的模式，意味著使用者可能會還需要承擔自建AI平臺所帶來的維護復雜度。因此，也有廠商還提供了軟硬一體，以serverless形態交付的AI平臺服務。比如阿里云的PAI靈駿智算服務。支支撐撐AI復雜任務，容器等云原生技術還有哪些短板？復雜任務，容器等云原生技術還有哪些短板？現在，云原生對人工智能的支持更多是利用其可擴展架構、標準化交付及彈性等自身優勢，加速AI能力的生產過程?；蛘哒f，AI是云原生平臺上的一種特殊類型的工作負載。實際上，深度學習、大數據處理等數據

39、計算密集型任務已經廣泛采用容器、Kubernetes、微服務等一系列云原生技術。比如，OpenAI為其大模型訓練提供可擴展的基礎設施，在2021年就已經將Kubernetes集群擴展到7500個節點。這些任務的計算規模和復雜度遠比 13 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 Web、微服務等互聯網應用要高。Web應用可能只需要簡單橫向擴展實例副本數，就可以提升服務性能和可用性。但數據計算密集型任務自身會有復雜的拓撲關系，一個任務又會細分多個子任務，子任務之間還有邏輯關聯，比如數據依賴、時序關系、執行順序等其他邏輯上的依賴。再加上任務的狀態轉化和對異構資源的高消耗，對CP

40、U、GPU、內存容量、內存帶寬、網絡、磁盤IO等資源的協同敏感，導致任務無法輕松地橫向擴展。Kubernetes或容器在支持這種復雜任務類工作負載方面還很欠缺。體現在對異構資源的協同優化管理，以及對Batch任務的調度和整體可擴展性上。為了支持AI、機器學習這樣的工作負載，Kubernetes就需要做很大的增強，包括核心調度、異構資源統一管理、利用率優化、可觀測性、故障診斷和自愈等，甚至整體的架構和生態都需要做很多增強。所有在容器和Kubernetes底座上進行的增強，被稱為云原生AI基礎服務層。云原生的優勢在于標準化交付，將業務應用中的運維、架構、DevOps統一化。企業IT可以將更為復雜的

41、數據計算型任務遷移到同一套技術堆棧上，用統一的標準交付模式和API來支撐不一樣的工作負載，通過彈性和混合調度等手段的綜合應用，從而達到整體降本增效的目標。這是一個比較長期且有遠見的架構演進上的訴求。上圖是一個非常典型的云原生AI系統分層架構。14 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 最底下的是高性異構資源管理，包括對高性能計算、存儲、網絡的統一管理和運維；上面是AI任務調度和流水線的構建。再往上就是為了運行各種各樣的計算框架或者訓練、推理的運行時，要做容器化支持；當運行時和框架跑起來后，就要關注如何不斷優化任務性能，優化方法除了算法和框架以外，還有非常多

42、手段相互配合；性能優化之上，要管理整個AI作業的生命周期；而所有這些能力都需要用統一的工具鏈和統一的標準API向上暴露給整個生態，既可以集成開源生態、私有業務系統，也可以跟第三方生態的集成。從支持系統看，彈性運維和安全始終貫穿其中，而廠商需要對客戶的數據和模型進行統一管理，并對效率之外的數據安全和隱私做好保護工作。MaaS發展未定，云廠商的“野心”能否實現？發展未定，云廠商的“野心”能否實現？很多產品都在用LLM進行增強甚至重構，其中包括智能診斷、AIOps等在云服務使用助手的場景。模型生態的繁榮會吸引更多新型業務應用圍繞AI模型關聯或集成，更快更廣地發展出更多新應用，間接幫云廠商接近了客戶的

43、應用需求，往上面向更多需求和機會，往下承接更大的資源消耗。IaaS層只是最基本的支持，AI PaaS、AI SaaS也成為云廠商們提供附加值的關鍵之一。在這方面，各家也有自己的平臺。AI PaaS包括數據，模型等資產管理平臺，模型開發平臺、模型訓練平臺、模型推理平臺，還有各行業解決方案。AI SaaS則更多關注個人工作效率和企業在流程化、規章制度和執行等方面的效率提升，這些都可以交給AI工具來完成。今年，很多云廠商也紛紛發布了自己的大模型，打造自己的MaaS（Model as a Service）服務。MaaS則包括了底層的基礎設施、模型相關能力及產品和場景應用等，主要就是以大模型為核心提供場

44、景化智能服務。出于安全問題或領域定制性較強而外部模型無法達到預期效果等考慮，進行知識庫的微調或增強等來自研模型是可以理解的，但效果如何可能要先打個問號，目前國內還沒有成熟案例出來。各家的大模型雖然分層差不多，但如果抽象力度夠高，那每層內容展開后也有很多：從下層智算IaaS到AI PaaS或面向云原生的AI，再到最上面服務生態的MaaS層以及垂直化領域的各類配置化模型。但對云廠商來說，MaaS商業模式可能只是間接的，但其影響力會 15 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 更大?，F階段還是會以規模為主，是否會引發新的商業模式還是個未知數。12月，科技市場分析公司Canal

45、ys的一份報告顯示，人工智能熱潮尚未推動中國云市場增長，“中國云服務市場仍然保守，嚴重依賴政府和國有企業?！蔽磥?，離業務更近的云原生技術與大模型會有更多集成，這對本身就有很多業務場景的企業來說更為有利。在多云和多集群等更為復雜的環境中，業內也在探索進行統一的AI能力交付。此外，在國產化背景和異構芯片現狀下，業內將在降低復雜度和提效上努力。采訪嘉賓簡介采訪嘉賓簡介 黃玄（黃玄（Hux），字節跨端與Web架構師，前React團隊核心成員 曹立成（蒜蓉）曹立成（蒜蓉），淘天集團1688終端架構負責人 羅廣明羅廣明，字節跳動服務框架團隊架構師，CloudWeGo開源負責人 董曉聰董曉聰，作業幫基礎架構

46、負責人 楊振濤楊振濤，vivo互聯網研發總監，PECommunity平臺工程社區發起人 張凱張凱，阿里云云原生應用平臺容器智算負責人 16 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 2023年度技術盤點年度技術盤點 17 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 爭議與熱度并存，越來越多開發者正在拋棄他爭議與熱度并存，越來越多開發者正在拋棄他們的舊語言轉向們的舊語言轉向RustRust 采訪嘉賓：王興、李原、侯培新 編輯：蔡芳芳 “用Rust重寫”的表情包廣為流傳，是Rust空前影響力的證明。如果要選出過去一年開發者群體關注度最高的編程語言

47、，可能非Rust莫屬。從正式發布1.0版本之后的2016年至今，Rust已經連續8年在Stack Overflow開發者年度調查報告中被評為“最受歡迎”編程語言。也有關注其他編程語言的社區專家向我們反饋，在微信群里經?？吹健笆褂肦ust重寫”的表情包，這也從一個側面反映了Rust的影響力。本次年度技術盤點與展望，InfoQ邀請了多位在華為從事Rust開發工作的技術專家，與我們一同回顧Rust編程語言過去一年在功能特性、應用場景、社區生態等方面取得的進展。18 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 1 爭議和沖突不斷，不妨礙爭議和沖突不斷，不妨礙Rust加速

48、“出圈”加速“出圈”如果要回顧2023年Rust編程語言的大事件，第一個被提起來的一定是5月份RustConf 2023 Keynote事件。當時，JeanHeyd Meneide在網站上發布了一篇文章I Am No Longer Speak-ing at RustConf 2023正式拒絕參加RustConf 2023并且不再演講，在社區中激起千層浪花（詳見InfoQ報道1）。由于JeanHeyd計劃演講的部分內容是得益于Rust基金會的贊助，Rust基金會也第一時間在官方Blog上對事件做出了回應，并開始討論是否未來由Rust基金會來主辦RustConf，以避免這類亂象。6月份Rust社區

49、宣布調整組織架構，成立新的頂級治理機構：領s導委員會（Rust Leadership Council）。由Rust各團隊成員合力創建一份新的、名為“Rust領導理事會”的RFC草案，并確立了以下內容：移除Rust核心團隊，由各團隊出一個代表，成立一個頂級的治理團隊“領導委員會”。Rust領導委員會將從Top-level的角度協調整個社區的工作，同時2023年由領導委員會選舉了5名社區專家進入到了Rust基金會的董事會、代表社區和董事會一起工作。此外Rust基金會引入了新的會員類型Associate Membership Tier，非盈利組織、高校和科研機構可以作為成員加入到基金會，進一步提升社

50、區成員的多樣性。雖然以上舉措旨在解決社區紛爭，但紛爭并沒有就此完全終結（詳見InfoQ報道2），不過這并不影響Rust社區以驚人的速度發展。據了解，作為Rust生態基礎工具包的聚集地，Crates.io網站上Rust第三方庫在2023年突破了500億下載次數。JetBrain發布的2023開發者生態系統現狀調研報告也證明了Rust的持續加速“出圈”：在今年最受歡迎的編程語言中，Rust創造了新的使用記錄，其用戶群在過去五年中穩步增長，有望憑借其嚴格的安全性和內存所有權機制取代C+；此外，Rust今年首次取代Go成為希望遷移到其他語言的開發者的首選，而Go用戶也是第一批準備采用Rust的人，Je

51、tBrains數據表明，有六分之一的Go用戶正在考慮采用Rust。多年來，Rust一直是最流行的學習語言之一，2023年Rust首次占據榜首，即有最多開發者計劃未來12個月內從原來使用的編程語言遷移到Rust編程語言。19 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 透過上述紛爭我們可以看到當前整個Rust生態的現狀：Rust編程語言由社區驅動前行，雖然有不同意見和爭吵，但同時也保持著強大的發展動力和潛力。候培新表示，Rust基金會會一直與Rust社區保持緊密合作，通過各種方式支持推動Rust生態繼續擴大，被更多的開發者使用。李原表示，在他個人的社區交流開發過程中，沒有人對紛

52、爭有過多的關注。他認為這和Rust社區以技術為根本、項目演進采取由下至上、以技術驅動為主的社區氛圍和傳統有著重要的關系。當然，社區也采取了動作，比如以各個團隊技術代表來重組領導小組，來避免日后再次出現類似的紛爭。在王興看來，每個社區都有適合自己的治理方式，雖然Rust社區遇到了一些問題，但只要社區的目標是持續解決開發者的問題，最終開發者還是會支持這門語言的發展。面對沖突不斷的Rust社區，曾有人向Rust的創造者Graydon Hoare提出這樣一個問題：“你有沒有想過在Rust項目中BDFL（終身扮演仁慈的獨裁者？）”而如果他真的這樣做了，Rust項目的發展會不會更好？Graydon Hoa

53、re在自己的博客文章和關聯的Reddit評論區回應了這個問題，他認為如果是由他來治理的話，方向肯定會很不一樣，但是Rust就不太可能像現在這樣“出圈”。同時，盡管如今的Rust跟Graydon Hoare最初想象中的Rust存在巨大差異，但他也對Rust語言如今獲得的成功抱有巨大的成就感和滿足感。20 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 2 Rust正在走進越來越多企業和場景正在走進越來越多企業和場景 作為Rust基金會創始成員和一以來編程語言潮流的引領者，谷歌和微軟在Rust的采用上先行一步。在2022年Linus接受Rust作為Linux Kerne

54、l的第二編程語言時，社區反饋褒貶不一，持各種意見的人都在觀望如何把Rust編寫的內核模塊運用到生產上。當2023年12月谷歌提交Android Binder進入內核，越來越多開發者相信Linus的決定是正確的。Android 13新增Na-tive代碼中Rust的比例已經接近20%，在Android 14中預計接近25%，谷歌不僅在Android中大量采用內存安全的Rust編程語言，也在Chromium中引入Rust，讓瀏覽器變得更加安全。而微軟不僅提供了windows-rs幫助開發者使用Rust開發Windows的程序，更在Windows 11 Insider Preview Build 2

55、5905版本中發布了用Rust編寫的Windows內核。當然這不是完全替代，而是部分用Rust開發，其中包含了一個GDI引擎的實現。相信未來微軟會越來越多地在Windows上使用Rust，以打造一個更加安全的操作系統。而在國內，華為內部也有了越來越多使用Rust的場景，比如在嵌入式、云服務、中間件等領域都有Rust的應用；又如由華為開源并捐贈給開放原子開源基金會的OpenHarmony項目實現了與Rust互相支持，并基于Rust重寫了上傳下載等模塊，性能顯著提升。在和國內很多頭部互聯網公司交流的過程中，王興也看到大家在積極擁抱Rust，并且很多公司已經有了不少Rust資產。比如Vivo就在近期

56、推出了基于Rust語言的BlueOS操作系統?？梢钥吹?，2023年Rust支持的操作系統和體系架構變得更加豐富，在musl、移動平臺等場景的支持上也取得了明顯的進步。采用“技術采用生命周期”來評估Rust的發展現狀，王興認為Rust目前處于早期大眾階段，而李原則略微保守一點，他認為處Rust在早期采用到早期大眾的過渡階段。在王興看來，大多數有一定技術能力的公司已經度過了試水階段，使用Rust作為一門主力開發語言是一件正在發生的事情。國外谷歌、微軟等公司在Rust發展上的聲量顯然比國內公司大不少，但國內公司的進展也超出了王興的想象，他認為或許差距并沒有想象中那么大。21 AIGCAIGC熱潮下的

57、行業與技術百態熱潮下的行業與技術百態 李原則認為，近年來Rust的使用者確實在快速增長，越來越多的公司開始采用Rust做開發。然而Rust本身還需要更加正規化以支持大規模開發的需求，比如語言需要規范文件，配套工具需要快速及安全的協議，項目構建效率需要提升等等。國內外的差異主要在使用人數和職業開發者數量上，但發展階段沒有明顯差距，都處于逐步成熟和擴張的階段。值得一提的是，2023年11月，對于任何一個編程語言都至關重要的廠商JetBrains加入Rust基金會成為銀牌成員。不僅僅是加入，JetBrains還帶來了為Rust編程語言打造的IDERust Rover，與此同時JetBrains的下一

58、代編輯器Fleet也是使用Rust編程語言開發的。這既是Rust生態擴大的一個體現，也預示著未來Rust生態和應用場景進一步擴大的可能。3 2023年語言本身值得關注的變化年語言本身值得關注的變化 從Rust編程語言本身的技術特性看，2023年有幾個變化值得關注。第一點是性能提升，除了通過完善編譯時常量表達式特性來獲得更多運行時性能優化，Rust在編譯性能、三方庫獲取性能方面也取得了明顯進步。尤為重要的一點是，Rust Nightly版本中引入了并行編譯的技術，開始著手解決編譯速度的問題。在侯培新看來，這標志著Rust編程語言更多進入到生產環境進行大型項目的開發，編譯速度已經成為影響開發效率的

59、關鍵問題。第二點是Rust語言規范化。2023年，Rust社區Language Team下成立了Specification Team，由Mara Bos和Felix Klock任Team Leader，開始了Rust編程語言規范的編寫工作。侯培新認為，這是一個標志著Rust逐漸成熟的里程碑事件，且不提一個規范對于語言本身的重要性，它對于商業發展也起到了至關重要的作用。2023年11月，德國公司Ferrous Systems宣布使用了Rust編譯器的一個子集通過了ISO 26262和IEC 61508的認證，打開了Rust編程語言進入汽車和工業自動化領域的大門?？深A見Rust社區官方的Speci

60、fication將大力推動Rust進入更多的商業領域，為Rust的大規模應用鋪平道路。第三點是安全性補齊短板，Rust 2023年通過支持更多安全編譯場景如異步trait方法、優化編譯告警如默認關閉debug信息等，優化了用戶的體驗，使用戶得以更好地獲取Rust安全性的優點。上述變化實際上反映出了Rust的主要演進方向：首先是降低整體學習曲線，使語言的學 22 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 習和使用更為簡單方便；其次是配套工具更加成熟及正規化。而這兩個演進方向背后的根本原因，正是因為Rust的主要用戶已經從較少數的技術愛好者變成了諸多企業規模開發中

61、的開發者。為了讓更多人學習和使用Rust，Rust基金會在2023年11月啟動了Developer Training和Cer-tification Program，以幫助開發者跨過學習曲線成為合格的Rust開發者。李原表示，降低學習曲線、適配更廣泛的場景以優化開發者體驗仍將是Rust社區未來重點投入的方向。2024年最值得期待或者說最有可能出現重大突破的方向包括：語言規范化RFC將會逐步成型；嵌入式場景的支持將會快速成熟；諸多提升構建效率的方法如并行編譯前端、默認LLD鏈接器支持等將會取得重大進展，等等。4 大模型時代大模型時代Rust的機會的機會 提及Rust在大模型時代的發展趨勢，王興和李

62、原都認為，大模型時代的到來對于Rust的推廣會起到正向作用。在王興看來，Rust在大模型本身的訓練和使用中的應用還有待觀察，但在大模型時代，學習Rust的開發者能夠借助大模型更容易地理解Rust（比如幫你指出為啥編譯不過？：），這對Rust來說是一個好消息。同時大模型也有助于熟練的Rust開發者提高生產力，王興進一步解釋道：“當前大模型的能力來講，AI對高水平編程開發者來講是更好的武器，他們具備更好的能力從AI中得到更好的結果，也具備能力判斷結果的正確性。編程的過程可能比以往會更貼進核心的邏輯和抽象，細節和體力活AI可能要和語言的語法糖來競賽來看誰更適合解決?！崩钤瑯诱J為大模型的出現對于Ru

63、st的推廣來說意義重大，他表示：“初學者可以通過將需求告知大模型、將其他語言交給大模型翻譯等途徑快速獲得較高質量的Rust代碼，這很大程度上降低了Rust的學習曲線。而未來場景化的大模型軟件的大量涌現，此時也是使用Rust代碼替代傳統C/C+語言的重要機會?！闭绾蚺嘈滤f，在2024年，可以期待Rust生態系統會繼續蓬勃發展，隨著企業和開源社區對Rust的持續興趣和投資，Rust應用領域可能會進一步擴大，覆蓋更多技術領域，吸引更廣泛的開發者群體，期待Rust重塑軟件生態。23 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 采訪嘉賓介紹采訪嘉賓介紹 李原李原，Rust編譯器co

64、mmitter 王興王興，華為OpenHarmony Rust技術專家 侯培新侯培新，Rust基金會董事 24 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 你當初被誰“忽悠”上了云，現在又在被誰你當初被誰“忽悠”上了云，現在又在被誰“忽悠”下云？“忽悠”下云？作者：褚杏娟 “當前的機會在于現有的服務品質不夠好，而我們專注于客戶體驗的能力，能帶給市場差異化的服務?！?006年，Amazon創始人杰夫貝佐斯在第10封股東信中說道。就在那一年，Amazon Web Services成立，并用Simple Storage Service（S3）給了市場一個不小的震撼：憑

65、借低廉的成本與便捷的配置，真正拉開了企業使用云計算的序幕。第一批吃螃蟹的總是互聯網公司，其中最典型的當屬Netflix。從2008年因數據庫損壞決定上云，Netflix用了7年的時間完成了上云遷移，并關閉所有的流媒體服務數據中心。如果沒有云服務，隨著業務規模的不斷擴大，Netflix就需要投入龐大的運維和研發團隊來處理與其核心業務不直接相關的事務。這個案例每年都會被Amazon拿出來對外宣講。25 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 到了2016年，美國聯邦調查局（Federal Bureau of Investigation，FBI）在結構會議上解釋了自己如何利用云

66、計算來管理安全。雖然并沒有直接鼓勵大家用云，但帶來影響就是互聯網之外的企業之后也開始嘗試上云。國內上云情況與國外基本相似，只是晚了幾年。2009年，阿里云成立；次年，騰訊云正式對外提供云服務；百度智能云更是到了2015年才正式對外開放運營；華為云雖然2005年就已經成立，但當時也主要做政務云和私有云，規模很有限。出來賣云但自己不用的話，國內用戶不會買賬。因此，頭部互聯網企業引領的國內上云潮逐步開啟，走在前頭的依然是互聯網企業。經過云廠商多年“市場教育”，國內對上云似乎已經達成了共識，現在甚至政企成為發展主力。但在2023年，隨著推特和Ruby on Rails之父David Heinemeie

67、r Hansson（DDH）聯合創建的37Signals宣告“下云”，業內展開了一場關于上云還是下云的討論。但是縱觀國內，其實還沒有企業公開宣告自己要完全下云，這場討論在國內最后實際上變成了一場對云廠商聲勢浩大的聲討。云云廠商帶來的各種“坎兒”廠商帶來的各種“坎兒”一定程度上，企業遇到的大多數用云問題都是云廠商帶來的。磐吉云數CEO馮若航在直播節目里分享了自己15年時的經歷：上云之前，部門自己擁有的幾百臺服務器的機房，一年成本大概1000萬，上了阿里云大數據全家桶后，每年計算花掉3000萬、存儲4000萬，效能沒有出現變化的情況下，成本卻翻了七倍。雖然他沒有詳細解釋花費項目，但已經說明了在很多

68、人眼里，云廠商毫無“性價比”。云廠商到底做錯了什么？被被誤解的彈性誤解的彈性 彈性本來就是一件不容易做到的事情，不管是對用戶、企業，還是云廠商來說。而云廠商手握巨大的資源池，可以為不同的用戶調度資源，這讓彈性成為可能。但要把彈性真正用起來還差很多。26 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 事實上，現在并不是所有產品都是彈性的，大多數云產品還處于云托管階段，即把傳統軟件架構通過再部署的方式上云，只有少數產品是按量付費的，比如S3按照存儲量和請求API次數收費。這里面有一定的技術原因。當前階段，業務重度依賴的開源產品大多數還是10年前誕生的成熟開源產品，這些

69、產品對云計算模式不友好。比如，很多開源軟件并不是面向多租戶設計的，而是從大企業內部孵化出來的、面向內部業務的，并沒有多租戶需求。如果把這些軟件搬到云上就要對其架構進行重構或者改變其接口行為，但一般云廠商不會這么做，因為后續還有兼容性等問題。但重構這些產品對云廠商來說，研發成本、運維成本，甚至后續迭代的成本都會很高。結果就是，每個用戶獨占一套集群，成本很高，也做不到按資源使用粒度計費。在云上部署一個開源軟件要三臺機器起步，如果真正按請求付費，云廠商大概率要賠錢。第一天就誕生在云上的產品就沒有這種問題。產品經理清楚地知道這個產品要服務數萬個、甚至幾十萬用戶，他第一天就會考慮接入成本優化問題。因此，

70、這類產品基本都是按量付費的模式，比如Amazon的SQS、S3、Lambda。近兩年面向云原生設計的開源產品，商業化模式也比較友好。云托管的技術架構也限制了云廠商的定價策略。絕大多數云產品按實例或規格售賣，特別是以開源產品為內核的云產品。云廠商把這些開源產品（甚至包括數據庫）拿去做云托管然后包裝成一個云產品去售賣，這些產品的“按量付費”是按小時粒度進行按量付費，比如4核8G每個月1000元，然后再按照小時計費，如果下個小時釋放了就不收費。云廠商追求的是超賣率，通常用戶選擇包年包月方案能獲得更低的折扣。但實際上，用戶不可能在不用的時候就把這個實例或者規格釋放掉，即使沒用也會把資源保留在那里，這就

71、帶來了更多的消耗。所以，用戶實際上并沒有享受到這種按量計算方式帶來的彈性好處。當然，這對廠商來說也并非好事。除了短暫的流量高峰，其他時候的資源閑置會造成巨大浪費。此外，云廠商還要為“按需使用”預留出大量的資源。27 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 另一方面，對于真正按量付費的云服務，用戶也要付出一定的使用成本。比如以前的軟件架構不可能是基于S3設計的，所以傳統架構直接搬到云上，S3的API肯定用不起來?？傮w說來，只有相對成熟、規模較大、已經形成事實標準的產品價格才更為便宜，只是這樣的產品數量有限，還集中在IaaS和數據庫范疇，大量云產品并不是真正的按量付費。這也表

72、明了，云計算還處于不成熟的階段，未來云廠商還是需要通過技術架構去降本，比如把更多云產品優化成真正的Serverless或彈性架構，真正規?；瘍瀯葆尫沤o用戶。畢竟，“貴肯定不是云計算?！钡壳皣鴥仍朴嬎闶袌龈窬诌€在不斷變化，整個價格體系仍有一定的不確定性。今年4月，阿里云宣布核心產品價格全線下調15至50，存儲產品最高降幅達50%，被稱為是“阿里云史上最大規模降價”。之后，騰訊云，京東云、移動云、天翼云等紛紛跟進。同樣的降價策略到了雙十一時再次上演。相對地，國外廠商已經過了大規?！皟r格混戰”。2014年左右，國外云廠商經歷了一場激烈的價格戰，數百家云廠商競爭激烈，最終剩下主要的三四家。但種種因素

73、疊加，云廠商其實也很難盈利。頭部的Amazon用了9年才首次公布盈利，阿里云則用了11年。多多而雜的云產品而雜的云產品 另一個事實是，國內大部分云產品缺乏競爭力，基于開源軟件做商業化和產品化的做法就決定了這點?，F在的云產品數量非常多，大的云廠商有上百個。雖然一定程度上，這么多產品確實是云廠商為滿足用戶真實需求而研發的，尤其是那些研發運維能力較弱的團隊很依賴云托管產品，但這也是國內廠商一味“參照”國外產品的后果。國內云廠商基本都是“先做起來再說”，并沒有考慮產品的頂層設計。國內廠商還喜歡“一站式”包攬所有問題的解決，后果就是各種產品自成一體，能力同質和重復，甚至會出現內部競爭。28 202320

74、23年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 一方面，上百個產品很多是在重復研發、運維、部署等，最終讓整個投入變得特別大。另一方面，每個云產品都特別做得很重、有完整的生命周期，這需要專業團隊負責到底，現實卻是一個產品可能只有幾個人負責，這幾個人能把商業化做好就已經不錯了，很難兼顧到接入成本、使用體驗等。更重要的是，上百個產品里，真正能夠承擔起營收規模的可能只有少數十幾個，大部分產品規模小、做得一般，卻消耗了大量的人力。當然，云廠商們近兩年也在進行調整策略，淘汰了一些需要維護卻難以帶來效益的產品，更加聚焦在自己的“拳頭”產品上。反觀國外云廠商，他們更注重通過標準化或提供更多自定

75、義能力來服務企業。其次，國外云廠商的生態位是就緒的，當整個生態就缺這么一款產品時，放進去就能形成級聯優勢。比如Amazon每個產品的體驗、UI、文檔、交互做得幾乎一模一樣，功能也做得比較克制，更傾向通過多個云產品的組合實現相關功能。國內云廠商為適應快節奏的市場需求，產品從研發到推出和運營的周期通常較短。但在追求速度和追求質量之間需要取得平衡，不能過于偏向速度。尤其ToB業務從第一天就面向企業，用戶對服務的質量要求很高。在這方面，很多云廠商還有很大的改進空間，但肯定不是要求客戶妥協，也不是通過降低服務質量、以低價策略來取勝。29 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 20

76、23年中國云計算行業企業競爭狀態總結，圖源：前瞻產業研究院 成成本，終歸是企業的事本，終歸是企業的事“我們相信了市場營銷。之前各種營銷宣傳的亮點均在于它將更便宜、更簡單、更快速。事實上，只有最后一個承諾真正實現了?！盌HH很多次解釋自己公司選擇下云的原因時這樣說道。為了拿到訂單，銷售人員可能會向客戶推銷一些他們實際上并不需要或是過度設計的產品，比如不是所有業務都需要異地雙活、兩地三中心等高可用架構。云廠商的過度承諾提高了用戶的期望，讓用戶有了錯誤的期待，但上云的種種問題卻沒有及時被告知。很多在云廠商工作過的人都提到，許多公司在首次上云后只是簡單地將資源放上去，但對資源的創建和用途并不了解。這導

77、致企業只有在月底云廠商給出賬單時才發現一些資源使用存在問題，但已無法追溯和挽回。用云的時候一定要非常保守、非?？酥?，但實際上企業太相信“按需付費”了。過去幾年的高速發展，讓企業更關注云到底能不能幫助解決問題，對成本反而沒那么上心。云廠商跟著互聯網一起快速增長的同時，很多東西也沒做好，犧牲了質量換速率。如今在“降本增效”大背景下，大家要去看成本了，才發現要考慮這么多問題，實際上是增長掩蓋了這些問題。大多數互聯網公司的主要成本通常集中在CPU、存儲和帶寬，其中CPU占30%40%，剩下的多數是各種各樣的存儲，包括對象存儲、云盤存儲、文件存儲等，還有使用云產品的費用。近幾年，GPU和GPU所需的高性

78、能設備成本也逐漸上漲，此外還有一些像安全產品、專線費用等更細致的項目。實際上這些項目成本多達幾十項，甚至上百項。企業要想梳理清楚這些成本并不容易。在2021年之前，云廠商只是事后生成賬單，并沒有考慮到讓企業更加可控地管理成本。而且這個賬單也很難對應到具體業務。每個產品至少有四、五個計費項，如果用幾十個產品，就是數百個計費項，假設公司有幾十個業務，則很難判斷每個業務花多少錢?，F實中，企業存在相當大的資源浪費。比如業務變化對CPU的使用情況是不同的，但不 30 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 及時調整策略就會產生很大的浪費；又如后端并非必須要記錄大數據，

79、長期保存這些日志對公司收益無益反而會增加成本。為了適應降本增效的大趨勢，各家云廠商，甚至獨立的第三方、開源社區等，都陸續推出了一些FinOps工具。但現在的FinOps工具主要針對CPU等主要成本項目，其他科目的計費工具比較少，并不能滿足企業對網絡、存儲及更深層次PaaS等不同產品成本的分析需求。幾幾個建議個建議 現在的降本更多還是要依靠企業自己。作業幫基礎架構負責人董曉聰介紹，他們現在一方面給產生成本的項目“瘦身”，比如基礎研發與業務線共同定期梳理計算、存儲等開銷，只保留有價值的部分；另一方面，利用每年硬件廠商釋放的一些紅利，周期性的進行主力機型替換。更重要的是，他們建立了更全面的FinOp

80、s成本管理體系，主要包括成本洞察、成本優化和成本運營三方面：清晰地記錄成本賬單，像各產品科目、業務之間是否共享服務等都要明確。他們會生成多種類型的賬單，包括云廠商支付賬單以及內部研發部門的實際使用賬單，這些賬單會被歸結到具體業務線，計算其使用回報率（ROI）；通過容器增加集群負載、離線混部等提升利用率和使用效率，引入了各種新技術進行成本優化；通過年度預算機制和每月審查，找出浪費或與預算不匹配的地方，并進行優化等。這些措施幫助企業許多業務線的成本節省了40%，預計未來每年會有千萬級別優化。AutoMQ聯合創始人兼CTO周新宇則借助FinOps思想，強制作出一些資源創建前置管理的規定，比如用S3時

81、不能用公網、用EC2時必須用Spot實例等，還有其他的節省規劃。同時，借助開源工具Infracost進行成本實時監控，他們可以在PR里面清晰地了解到一旦某代碼合并到主干后，云賬單會增加或會減少多少，這樣企業可以在每一次代碼提交時候就能量化云資源成本，而不是季度結束后才收到一個賬單。另外，用戶使用云產品要養成一個習慣，就是先去看它的計費項，即什么地方會收錢，31 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 其次要看這個產品的限制和邊界是什么。由于技術不夠完備，很多云產品都有用戶想象不到的限制，比如資源數量或單個資源帶寬等。因此，用戶不僅要算錢，還要看自己的需求在不在產品服務范圍

82、內。Datastrato創始人兼CEO堵俊平則建議，企業要制定更為有效的產品采購策略和選擇策略，避免盲目地被銷售人員引導。企業選產品時候不要只看廣告，也不能完全依賴第三方報告，而要關注實際場景，找出適合自己工作負載情況的產品。企業可以利用產品推廣期提供的免費試用，按需使用一段時間，發現產品不合適時可以迅速切換或回退。有有完美方案嗎？完美方案嗎？不能否認的是，用好云本來就是一件很有難度的事情，除了本身的技術問題，更難的是與千變萬化的業務結合。云廠商做云產品時，要面對數十萬用戶和各種各樣的場景，一個能滿足所有流量模型的體系化產品肯定是非常復雜的，云廠商的職責之一就是抹平這些差異，當然這方面云廠商做

83、得并不好。對企業來說，只做基本操作、處理簡單的業務場景還可以應付，一旦涉及到大規模應用，企業在以K8s為基礎的云架構在運維和管理方面就會遇到相當復雜的問題，一些原有調度器組件可能無法滿足需求，需要企業做自定義組件的開發，甚至包括對K8s底層結構做深度調整。完完全自建，不是普通玩家的游戲全自建，不是普通玩家的游戲 但完全下云、自建IDC這種方式也并不能解決問題。國外比國內更早提下云，是因為國外的IDC和云的價格差異較大，國內云廠商比傳統IDC更有價格優勢。國外的IDC服務運營機構通常也提供更為全面的服務，企業可以將很多ToB的云管理能力外包。此外，國外做ToB云端軟件企業更加成熟、工具鏈相對更為

84、完備，企業自建可以獲得更好的體驗。但是，自建IDC是有門檻的：對于百萬級機器規模以內的企業，無論從擴展性、更高效 32 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 運維，還是更先進的基礎設施角度，云計算是成本效益最優的選擇。一旦企業規模超過百萬級，尤其是在擁有相對完善的機房設施和系統運維團隊情況下，有的大型企業，如快手和拼多多，就會逐步考慮從云上遷移到自建IDC，這個階段的企業在采購和供應鏈方面也擁有了一定的優勢。AutoMQ聯合創始人兼首席戰略官章文嵩在直播節目里就算過這樣一筆賬：考慮到硬件、托管和網絡帶寬資源等成本，每臺機器年均花費約2萬元，5萬臺服務器的話

85、就要花費約10億元。此外，自建還有構建分布式系統、操作系統和數據庫等的額外投入，而維護一個六七百人的研發團隊的成本就高達5億。其實，在使用云的基礎能力方面，IDC和云沒有太大區別。IDC的基本構建包括租用機房、購買機器、搭建交換設備、申請公網IP、引導流量到負載設備以及在機器上部署服務等。IDC可以看作是一個基礎建設的雛形，云計算大大簡化了這個過程，用戶只需點擊即可創建一個高性能的VPC網絡，無需處理排線等問題。上云和自建IDC的關鍵區別在于，像操作系統內核這樣的基礎設施，云廠商通常有規模龐大的內核團隊來不斷升級穩定性，而自建IDC可能使用開源內核，企業需要自己承擔內核維護的各種成本。但自建I

86、DC最大的問題可能是沒人。一個完整的自建系統通常需要三個團隊：研發、測試和運維。這意味著企業通常需要基于開源軟件從零開始構建技術棧，這要求工程師熟悉開源軟件技術棧的使用和運維，并不斷跟蹤社區的動態。要找到勝任下云工作的運維人員相當有挑戰，這一領域的人才需要長期積累的經驗和技能，優秀的SRE人才更是難得一見。而硬件工程師的稀缺性更不用說。因此，除非企業是為了核心業務、愿意且能夠投入足夠的資源（包括招聘高水平的工程師、購置硬件和維護系統等），以及具有成本效益時選擇自建才是合適的?，F在業內基本共識是剛成立的創業公司或新開展的業務一定是上云。對于存量業務上云還是自建，當業務和團隊在相當一段時間里都比較

87、穩定、并滿足上述條件時，自建機房未嘗不可。當團隊不穩定或者業務有增長機會時，考慮分階段增量式上云更為穩妥。33 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 多多云、混合云可以嗎？云、混合云可以嗎？相對于完全下云，另一種中庸的方式是多云和混合云。在多云和混合云的情況下，業界通常提供了相應的解決方案，甚至逐漸形成了標準化的方案。多云可以解決云廠商鎖定問題，并通過平衡云服務的采購來優化成本，獲取更多議價空間。不過，多云的選擇也沒有統一標準，企業需要考慮的因素有很多，比如要結合自己的業務特性和成本方面考慮選擇、要確保數據在不同云上不會形成孤島、仔細評估和選擇產品等。有的企業可能一開始

88、使用某個云廠商的產品，但后來發現其他云廠商有更好、更穩定的產品，這種情況下，企業可能會調整其多云策略來獲取更好的服務。還有企業并購后做業務整合時，可能考慮多云策略來協同工作；另外在國際化和出海業務中，企業需要根據不同地區的情況選擇云服務。另外根據IDC最新報告，混合云已經成為市場中主流的云基礎架構部署形態?；旌显萍軜嬍潜镜?、私有云和第三方公有云平臺的統籌安排，對多云協同管理和跨云一致性進行了更多的優化，從而得到更多大型政企的青睞。當然，混合云架構帶來的復雜度、安全等問題也需要引起重視。多云、混合云都是一個漸進的過程，像今日頭條盡管采用了火山引擎，但仍有一部分業務會在阿里云上運行。云云廠商的“下

89、云費”廠商的“下云費”但是，無論選擇下云還是多云，云廠商都設置了門檻，比如數據出口費。數據出口費針對的就是企業上傳數據的云存儲位置移動或轉移，與云存儲和計算費是分開的。也就是說企業上云暢通無阻，轉移或離開云還要最后被“砍一刀”。有數據顯示據，數據出口費用已經影響到34%的云存儲使用企業。DHH就表示，他們下云的“出口費”在30萬至40萬美元之間。34 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 谷歌云日前率先宣布取消了這筆費用，并抨擊了這種做法：某些傳統廠商利用本地軟件壟斷來創造云壟斷，使用限制性許可的做法來鎖定客戶并扭曲競爭。具體方式包括限制客戶的合作對象和合

90、作方式；如果客戶決定使用某競爭對手的云服務，則收取5倍的費用；并限制必備軟件與競爭對手云基礎設施的互操作性等?！斑@些限制并沒有什么技術基礎，但可能會讓客戶的支出增加300%?！惫雀柙破脚_主管Amit Zavery坦承，取消這些收費最終會讓用戶更容易轉向競爭對手，但不公平的許可對市場競爭構成了更大的威脅。雖然谷歌這一決定背后肯定有其他利益考慮，但就像DHH說的：誰在乎！用戶想要的只是自由上下云而已。結結束語束語 如今，上云進程最快的就是互聯網或者泛互聯網的企業、國內有出海業務的企業、一些新的制造業如汽車。這些企業有一些特征：數據量大、業務創新快、高增長、有典型的互聯網企業特征。云計算對這些企業來

91、說價值巨大，因為他們能用非常低的資源保有成本應對未來高增長的業務預期。但根據受訪專家估算，國內上云的進度應該是小于10%的，因為對很多企業，尤其傳統企業來說，上云不會帶來更多的價值?？梢钥慈缦碌摹皟r值公式”：新技術決策帶來的價值新技術決策帶來的價值=新價值新價值-舊價值舊價值-遷移成本遷移成本 很明顯，IT設施的決策成本和遷移成本是巨大的，這種情況下要吸引這類型企業上云就要價值足夠大，并且是數量級優勢，否則打動不了企業作出重大的架構改變。只有精準命中痛點，企業才會義無反顧地上云。但現在云計算的種種問題確實還沒有一個完美的解決方案，企業更多還是選擇各種方式并存的策略。云技術還需要不斷進行持續的迭

92、代，這種迭代是多方面的，包括產品功能的不斷完善、通過規?；瘍瀯輧灮杀镜?。未來，云廠商欠下的種種技術債勢必是要還上的，而企業要做的上云功課也必須得補上。35 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 采訪嘉賓（按姓名首字母排序）采訪嘉賓（按姓名首字母排序）堵俊平堵俊平，Datastrato公司創始人兼CEO，Apache軟件基金會Member，LF AI&DATA基金會前主席，前華為云與計算開源總經理，前騰訊開源聯盟主席。在云計算、大數據與人工智能、開源等領域有超過15年的研發和管理經驗。董曉聰董曉聰，作業幫基礎架構負責人，阿里云MVP、騰訊云TVP。曾在百度、滴滴等公司負

93、責架構和技術管理工作，擅長業務中臺、技術中臺、研發中臺的搭建和迭代。2019年加入作業幫，主要負責架構研發、運維、DBA、安全等工作。主導完成作業幫技術體系的云原生重塑，全面推動公司在質量、效率、安全、成本等方面的建設。周新宇周新宇，AutoMQ聯合創始人&CTO，是Apache軟件基會成員，Apache RocketMQ聯合創始&PMC成員。目前致力于引領消息和流存儲走向云原生時代，利用云的能力為Kafka帶來十倍的成本優勢，是云原生上云理念的倡導者。36 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 挑戰挑戰SparkSpark和和FlinkFlink？大數據

94、技術棧的突圍和？大數據技術棧的突圍和戰爭戰爭 作者：Tina 十年的輪回，正如大數據的發展一般，它既是一個輪回的結束，也是嶄新的起點。大數據在過去的二十年中蓬勃發展，從無到有，崛起為最具爆炸性的技術領域之一，逐漸演變成為每個企業不可或缺的基礎設施。然而，在這個時刻，我們不禁要問：當前的大數據架構是否已經趨于完美？2023年，伴隨著人工智能的躍變式爆發，數據平臺將如何演進，以適應未來的數據使用場景？這并非簡單的問題，更是一個關乎企業生存與發展的命題。在過去的十年中，我們目睹了Spark、Flink和Kafka等系統的崛起，它們成為大數據領域的支柱。然而，現在是否有新的力量嶄露頭角，希望挑戰它們的

95、地位？2023年，大數據領域有哪些實質性進步嗎？37 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 在2023年年終盤點之際，InfoQ有幸采訪了大數據領域的資深專家，包括關濤、李瀟、王關濤、李瀟、王峰（莫問）、吳英駿、張迎（按姓名拼音排序）峰（莫問）、吳英駿、張迎（按姓名拼音排序）。他們共同探討了數據堆棧技術的演變過程，深入剖析了技術快速演變所帶來的挑戰。在這次專訪中，我們將揭示技術變革的背后原因和邏輯，為大家呈現大數據領域的現狀以及未來可能的發展方向。突突如其來的革新和質疑？如其來的革新和質疑？流存儲Kafka誕生在2011年，而流計算Flink到今年也剛好滿了十年。十年前

96、，軟件范式是利用虛擬化技術來發揮硬件性能。此外，云服務也只是剛剛興起，存算分離等云原生概念尚未普及。如今時過境遷，一切都在快速變化。當今的應用程序每天可以處理多達數萬億個事件，維護數TB的數據。硬件的迭代速度飛快，相對十年前的SSD，NVMe速度提升十倍，價格也降至原來的20%。S3越來越多地被用作基礎設施服務的核心持久層，而不僅僅是作為備份或分層存儲層，例如Snowflake、Databricks等。對象存儲是云時代的產物，支持原始數據存儲、分布式可擴展、高靈活性、低價，都是對象存儲之所以被選擇的原因?？梢灶A計在未來會有更多的數據業務完全基于對象存儲而構建。-2021年，滕昱使用對象存儲，數

97、據湖才能重獲新生 能否跟上硬件迭代速度，這是Kafka這樣的成熟且架構已經定型的軟件所面臨的最大挑戰：擁有眾多用戶，因此每個改動都需要花費更多的時間和精力去驗證合理性，大大拖慢了迭代速度。這也給一些初創公司帶來了巨大的機會：不需要用分層架構去實現存算分離，而是干脆用更加極端點方式去做存算分離，即直接建立在S3對象存儲之上?；趯ο蟠鎯Φ臉嫿ㄒ泊蟠蠼档土藰嫿ㄐ聰祿到y的門檻，催生了一系列這樣的“垂直”基礎設施初創公司：今年誕生的兼容Kafka的WarpStream、AutoMQ，去年拿到A輪融資的Neon Database、流數據庫RisingWave，等等。然而S3雖然價格便宜，能省成本，但高

98、延遲是一個問題，數據系統構建者需要費點周折 38 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 才能處理好需要低延遲的工作任務。恰好在今年底，AWS發布了S3 Express One Zone，一種新的低延遲S3存儲類別，可以說是在正確的時間提供了正確的技術（目前價錢昂貴）。推動數據庫和數據產品發展的主要因素主要有兩方面。一方面是數據本身，另一方面是硬件的發展。S3是硬件層面的變化，這勢必會給大數據領域帶來巨大的變革。眾所周知，在數據庫的歷史上，每次存儲介質的變化都會引發軟件的變革。-2023年，曹偉數據庫的下一場革命：進入對象存儲時代“低延遲S3的發布，對于我們

99、這些從事數據基礎設施業務的人來說，這是今年最大的一這是今年最大的一個新聞。個新聞?！盧isingWave（）創始人&CEO吳英駿認為。如如今的大數據技術棧是真的難用嗎？今的大數據技術棧是真的難用嗎？站在當前的時間點，對于大數據系統的易用性問題，采訪嘉賓給出了“不夠好”、“不夠便宜”，“太過復雜”的評價，可以說當今的大數據技術棧是公認的“難用”。大數據架構在過去漫長的20年里經歷了從場景到系統的完整迭代。大數據的起源可以追溯到谷歌的MapReduce框架，這標志著大數據的最初階段。在此之前，數據庫方面主要有一些頂級產品，如Oracle、SQL Server和IBM DB2。Google提出了一個

100、通用的、折中的方案，即不必購買Oracle、DB2或Microsoft Server，使用簡單的模型讓大規模并行計算在擁有大量普通計算機的科技企業中變得可行：利用MapReduce，不使用數據庫，就能完成大數據計算，只不過用戶需要去承擔這些復雜性。這里還有個大家可能忘卻的典故：數據庫專家David DeWitt與Michael Stonebraker（同樣是圖靈獎獲得者）在2008年發表了MapReduce:A major step backwards，對MapRe-duce進行了批評，稱其為開歷史倒車。要充分利用這些資源，MapReduce提出的方法是，將底層編程接口封裝成Map和Reduc

101、e函數之后，便直接暴露給有編程經驗的用戶，讓用戶自己實現具體業務邏輯，并自己可以操控程序并行度等細節。用戶不再是使用SQL，而是使用C或Java等編程語言，需要承擔編寫底層代碼的復雜性，處理更多的編碼工作，這也意味著很高的學習壁壘，讓許多人望而卻步。39 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 在這期間，批處理和流處理在Spark和Flink的引領下率先成熟。截圖來源：https:/ 近幾年，交互分析，也稱直接在線服務能力（Operational Analytics）隨Clickhouse等通用實時數倉流行，并已是事實上完成主流客戶的部署。隨流、批、交互三類計算場景成為標

102、配，Lambda架構也成為（國內的）事實標準。Lambda架構能夠滿足客戶場景上的訴求，最大的缺陷就是復雜：數據開發、組件運維、數據管理均復雜。畢竟并不是所有公司都跟Google、Facebook或Twitter這樣的大型科技公司一樣，擁有強大的工程團隊，能夠管理復雜的流處理系統來實現他們的需求。也并不是所有用戶都像阿里和拼多多這樣有著非常大的數據量，復雜的分布式系統阻礙了十幾或幾十個人的小公司或一些傳統企業的采用，對它們來說，這是一件成本高、挑戰大的事情。吳英駿認為，大數據架構里，如流處理，應該回歸第一性原理了回歸第一性原理了?！艾F在的系統，誕生于十年前，與當下云時代設計的系統相比，從本質上

103、來說肯定是不同的，這表明大數據生態在這十年間并沒有取得實質性進步?！薄霸诋斍皶r刻，我們再設計這個系統時，肯定會思考能否基于現有系統實現性能提升?！闭Z言層面，新系統需要提供一個更高層次的語言，比如SQL或Python。另外，云上最核心的一個點在于“存算分離”，站在現在這個時間節點上，新一代的系統從設計上的第一天開始就應該是“存算分離”的。跟分級存儲架構不一樣，現在的系統可以將所有數 40 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 據直接放到S3，而不僅僅是將歷史數據放到S3，那么這樣就可以更加極端的去實現存算分離，設計、實現和運維自然都會更加簡單。RisingW

104、ave于2023年6月發布了1.0穩定版本，并通過數月的大量性能測試，得出了“比Flink快10倍”的結論?！靶阅鼙容^不是關鍵，易用才是關鍵?；趯ο蟠鎯Σ⒛茉谛阅芎托史矫嫒〉锰嵘?，那肯定是因為整體基礎架構正在發生變化整體基礎架構正在發生變化，這是一個核心點?！币砸許park社區為例看易用性進展：從社區為例看易用性進展：從Python到到AI“簡單易用”同樣是Spark社區的主要發力重點。在Databricks今年的Data and AI Summit主題演講中，Reynold Xin談及了三個Spark社區在易用性的最新進展。首先，需要提供一套簡單好用的API。Python和SQL已經成為

105、了整個數據處理行業的主流語言。在過去幾年，Python已成為TIOBE指數顯示的排名第一的編程語言，這種受歡迎的原因來自于它的簡單性和易學性，使其成為初學者和專家的首選語言。Python的廣泛庫和框架簡化了數據分析和機器學習中的復雜任務。各大數據系統都提供了它自己的Python DataFrame APIs。PySpark的PyPI下載量（https:/pypistats.org/packages/pyspark）僅在2023年最后一個月就達到了來自169個國家的2800萬次下載。為了方便pandas用戶，PySpark也提供了pandas API的支持?？梢哉f，API的簡單易用已是大勢所趨。

106、特別值得一提的是，即將發布的Spark 4.0版本中，一個全新的Python的數據源接口被特別設計來強調易用性。這一更新將使Python用戶更加輕松地創建和管理自己的數據源，進一步增強Spark平臺的用戶友好度和靈活性。Spark社區在這方面繼續發力，過去一年的一個主要項目，Spark Connect，引入了一種分離的客戶端-服務器架構，允許從任何地方運行的任何應用程序遠程連接到Spark集群。這種架構的改進涉及到了穩定性、升級、調試和可觀測性多個方面。Spark Connect使得用戶可以在他們喜愛的集成開發環境（IDE）中直接進行交互式的調試，并且可以使用應用程序自身的指標和日志庫進行監控

107、。其次，一個穩定成熟的數據系統必須具備一套穩定的API，這也是Spark社區對API行為和語義的變更制定嚴格規范的原因，目的是讓用戶更順暢地升級至最新版本。在上個月，41 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 最流行的PySpark版本就是最新的Spark 3.5，這體現了用戶始終傾向于使用最新版本的趨勢。為了迎合這一趨勢，Spark社區努力保證向后兼容。此外，錯誤信息的標準化也是Spark社區過去一兩年里的努力方向。盡管這看似技術復雜度不高，但這實際上是使系統更加簡單易用的基本需求。今年的Spark 4.0 release還會進一步標準化日志，以使用戶能夠更好地進行系

108、統調優和代碼調試。而隨著生成式AI的發展，未來API將變得更加簡單易用，自ChatGPT大流行到現在，我們發現它已經對PySpark有了深入的了解。這得益于Spark社區在過去十年里提供了豐富的API文檔、開源項目和教學資源。Spark社區開發了一個叫做English SDK的項目，將Spark專家的知識融入到LLM中。這樣一來，用戶就可以通過簡單的自然語言指令來操作PySpark，而不需要自己寫復雜的代碼。這種方法讓編程變得更容易上手，學習過程也更簡單。流流處理的演進處理的演進 從2014年誕生之后，Flink已經確立了其在全球實時流計算領域的地位。阿里、Amazon、Azure、Cloud

109、era、Confluence等眾多企業都提供了支持和托管服務。樹大招風，實際上今年不止一家企業宣稱在流處理技術上實現了10-1000倍的效率提升，如果這些技術確實可以在生產環境得到驗證，像阿里、騰訊、抖音這樣的大型公司每年可能會節省數十億的機器成本。盡管目前還沒有看到哪家公司在真正的生產環境中實現了這一效果，但這一趨勢表明流處理技術的不斷創新將在未來帶來更多的機遇和成果。與此同時，Flink的發展現狀和未來演進則更加引人關注。流流處理領域是否有留給創業公司的機會窗處理領域是否有留給創業公司的機會窗口？口？事實上，Flink一直在不斷完善和創新。Kafka已經在商業版中實現了一個“分級存儲”架構

110、來實現了存算分離的改造。同Kafka一樣，Flink也會從存算耦合轉為存算分離的架構。據莫問介紹，目前Flink也在不斷學習和自我革新，2024年將是Flink項目的第一個十周年，Flink社區也會發布社區也會發布Flink 2.0新的里程碑，徹底的云原生存算分離架構新的里程碑，徹底的云原生存算分離架構、業界一流的批處理能力、完整的流批融合能力都會是全新的亮點。42 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 莫問認為，隨著云原生概念的逐步普及，未來主流的計算負載一定是運行在Cloud上，全球范圍內都是這個趨勢，因此大數據架構也需要更好地適配云底座，利用好云的彈

111、性優勢。存算分離將會是未來大數據架構的標配，不過存算分離在帶來了諸多好處的同時也帶來了額外的性能挑戰，目前看來在對latency敏感的場景下，多級緩存和冷熱分層將是對存算分離架構的有益補充，2024年將發布的Flink 2.0也會采用這套最新的架構。分級存儲側重于在計算節點上進行緩存，遠端存儲主要存儲歷史記錄。相較之下，新的直接建立在S3上的系統將所有數據完全存儲遠端，但也會造成性能的下降，這需要在產品設計方面去做一個權衡。在存算分離上，Flink會有一個迭代的過程，吳英駿認為，“大家的最終思想都是統一的。如果我們將時間拉長，放到五年之后，我們可能會看到這兩種系統實際上非常相似。在未來發展中，

112、雙方都會在自己的短板上進行彌補。比如說，RisingWave從第一天起就將內部狀態放在對象存儲上，而這意味著RisingWave需要思考如何降低對象存儲所帶來的高延遲問題。而對于Flink來說，面臨著使用本地磁盤存儲狀態而導致的大狀態管理困難的問題。它可能需要引入一個分級存儲的架構，來降低處理大狀態計算時的資源消耗，同時避免系統直接掛掉?！薄暗谀壳耙粌赡昀?，這兩種系統在架構上仍然會有相當大的區別。架構的調整不是一朝一夕能夠完成的?！毙屡d軟件和成熟軟件之間有了較量，那么用戶進行選型時，會關注哪些因素呢？作業幫于2019年底調研Flink 1.9版本，并在2020年內部搭建了實時計算平臺，現在流

113、和批都在幾千任務的規模。其大數據架構師張迎表示，選型時，主要根據業務訴求，結合多云融合能力、成熟度、已有技術積累、云廠商的支持力度、成本等綜合考慮。這幾年使用大數據技術棧時主要有兩點比較強的感受：生產環境的可用性、周邊系統的建設，這兩點一定要跟得上。一個用戶可以寫出來幾百個SQL任務，但是出了問題往往不知道如何追查和改進。后面的工作，例如調優、自動化測試、日志、監控報警、高可用也都是圍繞這類需求展開的。原來需要寫代碼的實時任務，很多可以通過SQL完成。（在2015年后，隨著流處理的成 43 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 熟，流計算引擎紛紛選擇了支持SQL通用編程

114、語言）。SQL越來越復雜，配置越來越多，一定程度上還是將復雜度留給了數據流的構建者?！皩τ诤唵蔚臄祿?，開發和運維都變得更簡單了。而對于復雜且重要的數據流，我們的態度也一直是謹慎保守為主，避免盲目求新?！绷髁魈幚砑夹g進化方向處理技術進化方向 關于SQL的說法，跟莫問預測流處理引擎未來進化方向之一是一致的，即：“全面SQL化，提升體驗，降低門檻”。大數據處理從離線向實時升級的趨勢已經確立，大量行業已經開始實時化升級，并取得非常好的業務收益。為了讓更多用戶能夠享受到實時流計算帶來的價值，流處理引擎需要進一步提升端到端的易用性，全面SQL化，提升用戶體驗，降低使用門檻，讓流計算能夠在更多場景和行業中

115、被生產使用起來。云原生架構的不斷發展，也同步推動了數據湖存儲方案的加速落地。數據湖具備的開放和成本優勢，必然使得越來越多的數據流入湖中，從而成為天然的數據中心，湖上建倉的Lakehouse架構正在成為主流，下一步客戶一定是希望數據在Lakehouse中能夠更加實時的流動起來。Apache Paimon是從是從Flink社區中孵化出來的新項目，定位就是流批一體實時數據湖格式，社區中孵化出來的新項目，定位就是流批一體實時數據湖格式，解決解決Lakehouse數據實時化的問題。數據實時化的問題?；贔link+Paimon可以構建出新一代的Streaming Lakehouse架構，讓Lakehou

116、se上的數據可以全鏈路實時流動起來。此外，基于計算和存儲端到端流批一體的特性，也更加方便用戶在Lakehouse架構上實現實時離線一體化的數據分析體驗?！癙aimon是一個好的嘗試，”關濤對此評論道。之前Flink流批一體缺乏對應的存儲系統配合：Flink自帶的狀態存儲無法滿足批處理通用數倉的需求，Paimon則是補全這個短板的關鍵。莫問指出，在實時流處理這條鏈路上，確實也存在一些新的機會和變化。眾所周知，Flink和Kafka目前已經分別成為流計算和流存儲的事實標準，但Kafka真的是最適合流分真的是最適合流分析的存儲方案嗎析的存儲方案嗎？44 20232023年度技術盤點與展望年度技術盤點

117、與展望|架構師特刊架構師特刊 Kafka和很多消息隊列類似，都是一種消息中間件，而非為大數據分析而生。例如：Kafka并未對數據提供結構化的Schema描述，也無法提供完整的Changelog語義，且Kafka中的數據時無法進行實時更新和探查分析的?！暗陨线@些缺陷，都是實時流分析需要的特性和能力，我們也正在思考這個問題，并探索新的解決方案，希望能夠在明年發布一款更加適合流分析的流存儲技術?！?023年，大數據技術棧的整體變化年，大數據技術棧的整體變化 近些年各種不同的大數據基礎設施雨后春筍般的涌出，一方面為用戶提供了多樣化的選擇，但另一方面也為用戶帶來了幸福的煩惱。通常情況下，用戶要搭建一套

118、大數據業務系統，需要非常多的核心技術組件才能完成，少則三到五種，多則五到十種，這主要帶來以下幾方面的問題：1.技術組件繁多，必然提升系統架構的復雜度。通常來講，系統穩定性風險和系統復雜度成正比，過于復雜的體系必然帶來更大的穩定性隱患；2.每一項技術組件都需要有對應的專家來運維管理以及客戶支持，對于中小企業來說，這必然帶來高昂的人力資源成本；3.過多的同質化組件存在，也會為用戶帶來選擇的困擾，并行保留多個同質化組件不僅給運維團隊帶來了額外的運維負擔，也給開發者帶來了額外的學習成本。因此，未來數據技術的演進會逐漸出現一些整合的趨勢，走向更加簡潔的架構，核心目標不僅是讓每個組件運行得更快，還需要考慮

119、為用戶提供更加簡單、一致性的開發體驗，以及全局最優的運維成本。從從Lambda架構到架構到Kappa架構的演進。架構的演進。當前數據分析平臺的典型架構是Lamdba架構（由三層系統組成：批處理BatchLayer，流處理層Speedlayer，服務層Servinglayer），隨批、流、交互三種引擎誕生和成熟組裝而成。這種架構的典型缺陷，包括復雜度高，數據冗余度高，學習成本/開發成本高等等。針對Lamdba架構的缺陷，Kappa架構應運而生。但多年過去了，Kappa架構仍然更像是參考架構，并沒有很多引擎/平臺做到Kappa架構的要求。2023年是個拐點，除了部分已有引擎開始拓展邊界相互滲透，還

120、有一些新的設計和計算模式被提出。例如云器科技提出“通用增量計算”的新計算范式統：Lambda架構到 45 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 SingleEninge，用一個引擎覆蓋流批交互三種模式。目前業界主流的幾款目前業界主流的幾款Streaming、Batch和和OLAP引擎都開始相互滲透引擎都開始相互滲透，例如：Flink在發力流批一體、流批融合計算能力，Databricks也基于Spark和Delta推動了Delta Live Table淡化流批的差異，StarRocks在提供OLAP極致查詢能力的同時，也開始通過物化視圖形態提供對數據湖上數據的ETL處理能

121、力。本質上各大主流計算引擎都在不斷擴展自己的能力邊界，淡化流、批、OLAP邊界，希望為用戶提供全場景一致性的數據分析體驗。這也是技術發展的必然趨勢，各家都會逐漸補齊短板，但也都有各自核心的優勢。在最近幾年的數據技術趨勢演進的路線中，我們可以清晰的看到兩個趨勢變化：一是數在最近幾年的數據技術趨勢演進的路線中，我們可以清晰的看到兩個趨勢變化：一是數據架構的云原生化。據架構的云原生化。幾乎所有的大數據公司都選擇了擁抱云原生，推出了基于多云的PaaS/SaaS計算服務，從Serverless到BYOC，為用戶提供了在云上不同類型的托管服務。二是數據分析的實時化。二是數據分析的實時化。在技術上，數據的“

122、實時化”包括了兩個因素：數據的新鮮度，以及數據的查詢速度。用戶也不再盲目地只追求速度，而是更注重新鮮度、性能和成本的平衡。在時效性上，Iceberg贏得了更多關注，數據湖存儲技術為我們提供了構建近實時（near-online）數倉的可能性，在成本不變的情況下可以支持更快、更多的流量數據。數據集成上，SeaTunnel成功畢業，Flink CDC 3.0演變成以Flink為基礎的端到端流式ELT數據集成框架。比如作業幫目前主要在使用SeaTunnel以降低異構數據源間數據處理的開發成本。社區希望能表格式能夠統一，但實際還有一段路要走。社區希望能表格式能夠統一，但實際還有一段路要走。Lakehou

123、se平臺在數據倉儲領域的使用正迅速增加。這反映了一個重要的趨勢：組織正從傳統的數據處理平臺過渡到更加靈活、集成和效率更高的現代數據架構。據2023年MIT Technology Review Insights報告，全球74%的首席信息官（CIOs）表示他們已經在使用Lakehouse架構。自Databricks在2020年推出此概念以來，Lakehouse作為一個新類別得到了廣泛的采納。幾乎所有還未使用Lakehouse的首席信息官都計劃在未來三年內部署此類平臺。有專家認為，Lakehouse（湖倉一體）和Iceberg表格式已成為事實標準。但是，當前根據Slack users、Github

124、Stars、Github PRs、Github Forks、Issues各個指標顯示，Delta、Hudi和 46 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 Iceberg還是三分天下。雖然Delta、Iceberg和Hudi起源地不同，但是各個社區都在努力地提升開源社區的活躍度，讓用戶社區和開發者社區更加健康的發展。隨著社區的競爭加速，基礎功能的差異在不斷減少。三種表格式（Table Format）均基于Apache Parquet數據格式，但這些格式各自會創建出相似、但又不盡相同的元數據，從而影響數據向應用程序和分析工作負載的表達方式。結果就是，Delta

125、、Hudi和Iceberg之間存在一定的不兼容性。表格式的最終統一還有難度，未來還得看哪種表格式能給出更好的性能、更好的易用性和更持續的創新能力，接下來的一年肯定更加精彩。頭部的云廠商的產品都或多或少地支持不同的表格式。Snowflake、BigQuery、Athena都已支持Iceberg，而微軟和Databricks都以Delta Lake為主要存儲格式。因為當前數據處理引擎的格式支持缺陷，用戶不得不將數據以不同格式存成多份。格式的兼容性讀寫會是未來一個值得關注的方向。比如10月份發布的Delta Lake 3.0增加了Delta UniForm通用格式，Delta Uniform自動為I

126、ceberg和Delta Lake生成元數據，提供了一個實時數據視圖，而底層它們共享的同一份Parquet數據，因此用戶可以避免額外的數據復制或轉換。另外，同時能支持Hudi、Iceberg和Delta Lake的元數據自動轉換和生成的XTable也于2023年底正在申請進入了Apache孵化器。GenAI來了來了 無論是大公司還是小公司，大家都渴望從生成式AI的熱潮中分到一杯羹。當然，作為大公司，無論是Databricks還是Snowflake，它們確實更有實力來進行生成式AI的開發。今年Databricks不僅率先發布了開源可商用的大模型Dolly，還于6月底宣布以13億美元的價格，收購生

127、成式AI公司MosaicML。在LLM服務方面，對數據棧的依賴主要集中在知識庫的構建和查詢上，包括但不限于向量數據庫。有人認為在短期內很難看到深層次AI對數據湖或數據倉庫方面帶來重大變革，但也有人認為數據是服務于AI的：大數據是燃料，大模型訓練已經涵蓋了大量已有的大數據技術，而數據湖則作為存儲系統在其中扮演重要角色。Databricks李瀟對此也進行了解釋，他認為數據湖倉（Lakehouse）的作用是為GenAI提供 47 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 了一個集中、高效和可擴展的數據存儲和管理環境。它結合了數據湖的靈活性和數據倉庫的高性能，支持結構化和非結構化數

128、據的存儲和處理，這是AI應用的數據需求的基石?！敖衲?，Databricks的最大進展主要體現在將人工智能集成到數據平臺中?！白鳛榇髷祿袠I里一個非常重要且典型的企業，Databricks在GenAI也反映了整個大數據行業的技術演進?，F在我們可以通過它在數據智能平臺投入來看看生成式AI將對數據和分析產生的影響。Databricks是由一群Apache Spark的原創者所創建。Spark的誕生階段，始于2010年，標志著Hadoop技術時代的結束。它的出現大幅降低了大數據處理的門檻，使得大數據開始與機器學習和人工智能結合，成為統一的分析引擎。2020年，Lakehouse架構的推出打破了傳統數據

129、湖和數據倉庫的界限。Lakehouse架構結合了數據湖和數據倉庫的最佳元素，旨在降低成本并加速數據及人工智能項目的實施。Lakehouse架構建立在開源和開放標準之上，它通過消除歷史上復雜化數據和AI的孤島，簡化了數據架構。而現在，則是到了生成式AI大潮下的Lakehouse階段。Databricks構建了一個基于數據湖倉（Lakehouse）的數據智能平臺數據智能平臺（Data Intelligence Platform），該平臺的目標是實現數據和AI的平民化，使用自然語言極大簡化了數據和AI的端到端體驗。它利用生成式AI模型來理解數據的語義，并在整個平臺中應用這種理解?？梢宰層脩艨梢栽诒３?/p>

130、隱私和控制的同時，從頭開始構建模型或調整現有模型。同時，Databricks還提供了Unity Catalog數據治理工具來確保數據的質量和安全。Data-bricks還于今年推出了Lakehouse Federation(聯邦查詢)的功能，用戶可以跨多個數據平臺（如MySQL、PostgreSQL、Snowflake等）發現、查詢和管理數據，而無需移動或復制數據。另外，Databricks SQL（Lakehouse上的無服務器數據倉庫）使用量也獲得了大幅增長。Databricks認為，在不久的未來，每個領域的贏家都是那些可以最有效利用數據和AI的，并堅信對數據和AI的深刻理解是每個贏家的必

131、備技能。未來的大數據架構將是一個高度集成、智能化和自動化的系統，它能夠有效地處理和分析大量數據，同時簡化數據管理和AI應用的開發過程，為企業提供競爭優勢。48 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 “未來的大數據架構，我們可以稱為數據智能平臺（Data Intelligence Platform）。它正是順應了兩個主要趨勢：數據湖倉（它正是順應了兩個主要趨勢：數據湖倉（Data Lakehouse）和生成式人工智能（）和生成式人工智能（AI）。）?！崩顬t表示。這一架構建立在數據湖倉的基礎上，它提供一個開放、統一的基礎，用于所有數據和治理，由一個理解用戶數據

132、獨特語義的數據智能引擎(Data Intelligence Engine)驅動。這是相對現有Lakehouse架構下的，最大的突破。智能化方面，這個引擎能理解客戶數據的獨特語義，使平臺能自動優化性能和管理基礎設施。操作簡化方面，自然語言大大簡化了用戶體驗。數據智能引擎理解客戶的語言，使搜索和發現新數據就像詢問同事一樣簡單。此外，自然語言還助力編寫代碼、糾錯和尋找答案，加速新數據和應用程序的開發。在隱私保護方面，數據和AI應用需要強大的治理和安全措施，尤其是在生成式AI的背景下。提供一個端到端的機器學習運維（MLOps）和AI開發解決方案，該方案基于統一的治理和安全方法。這允許在不妥協數據隱私和

133、知識產權控制的情況下，實現所有人工智能目標?？偟膩碚f，未來的大數據架構將更加重視智能化、操作簡化和數據隱私，為企業在數據和AI應用方面提供競爭優勢。這將使企業能更有效地利用數據，推動創新，同時保護數據安全和發展AI技術。采訪嘉賓簡介（按姓名拼音排序）采訪嘉賓簡介（按姓名拼音排序）關濤關濤，云器科技聯合創始人&CTO 李瀟李瀟，Databricks工程總監、Apache Spark Committer和PMC成員 王峰（莫問）王峰（莫問），Apache Flink中文社區發起人、阿里云開源大數據平臺負責人 吳英駿吳英駿，RisingWave（）創始人&CEO 張迎張迎，作業幫大數據架構師 49

134、AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 WebAssembly 2023WebAssembly 2023年回顧與年回顧與20242024年展年展望望 作者：黃文勇、何良、徐君 策劃：蔡芳芳 在剛剛過去的2023年，WebAssembly技術發展態勢喜人，多項關鍵性提議都進入了新階段，并且獲得了社區與工具鏈的廣泛深入支持。同時，其應用場景呈現出蓬勃擴展的態勢，吸引著越來越多組織和個人開發者群體投入WebAssembly的開發之中。下文我們將首先回溯WebAssembly在2023年各項關鍵技術特性的進展，繼而前瞻探討新的一年它有望展現的發展趨勢和前景。本文是“2023 In

135、foQ年度技術盤點與展望”系列文章之一，由InfoQ編輯部制作呈現。50 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 回回顧顧2023 GC、Func Ref和和String Ref WebAssembly GC（Garbage Collection，垃圾回收）特性引入的目的之一是為了更加高效地支持一些需要垃圾回收處理的高級語言，比如TypeScript、Java、Kotlin、Python、PHP和C#等。在沒有引入WebAssembly GC特性之前，如果要將這些語言移植到WebAssembly，一般的做法是將相應語言的虛擬機（如JavaScript run

136、time、Python runtime等）以及目標app一起編譯成WebAssembly目標代碼，由wasm runtime來執行該語言的虛擬機，然后再由該虛擬機來執行目標app。由于這種方式不容易將目標app轉成機器碼以AOT（Ahead of Time Compilation）或JIT（Just in Time Compilation）方式來執行，虛擬機一般只能以解釋器的方式執行目標app，所以性能受到很大的限制。另一方面，將虛擬機編譯到wasm目標代碼，也可能大大增加目標代碼的體積。引入了WebAssembly GC特性之后，人們可以開發出新的編譯器，將某種高級語言的app直接編譯成基于

137、WebAssembly GC操作的目標代碼，不需要將虛擬機一起編譯進來。這樣一方面目標app可以用AOT或JIT方式來執行，另一方面基于GC opcode的操作也非常高效（比如對結構成員的訪問、對數組元素的訪問等），因此可以極大提升性能，并減少目標代碼體積。WebAssembly GC依賴于Reference Types和Typed Function References（或簡稱Func Ref）兩個特性，在基本數據類型（i32、i64、f32、f64和v128）的基礎上引入了多種和引用相關的數據類型，包括structref、arrayref、i31ref、funcref、externref等

138、，規定了類型之間的繼承和等價關系，并且引入很多新的opcode來操作這些數據類型，從而滿足多種高級語言的需求。其中Reference Types已經在2021年正式寫入規范，而GC MVP提議和Func Ref提議在2023年也得到了較大的發展，在經過了大量討論和修改后趨于完善和穩定，目前都進入了階段四即標準化階段。另外開源項目WAMR（wasm-micro-runtime）、v8、Kotlin以及開源編譯框架Binaryen等都在持續跟進支持GC特性。WAMR已經基本實現了interpreter、AOT以及LLVM JIT幾種執行 51 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技

139、術百態 模式對絕大部分GC MVP特性的支持（注：開發分支），并被應用到了開源Wasmnizer-ts項目上面，后者旨在將TypeScript語言編譯成基于WebAssembly GC的目標代碼，以提升性能、減少模塊尺寸并方便移植到各個架構，有興趣可以參考https:/ of abstract wasm GC heap types Basic idea of Wasmnizer-ts compiler Func Ref允許把wasm函數作為一個對象來引用，并傳入函數參數來調用該引用指向的函數，例如通過ref.func opcode來創建一個函數引用然后使用call_ref opcode來調用該

140、函數。52 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 這樣可以更靈活地支持動態函數調用，相比之前的call_indirect opcode通過wasm table來間接的調用函數的方式，可以減少較多的運行時檢查以提升性能。另外通過函數引用也方便實現有些高級語言特性，比如閉包（Closure）。Reference-Typed Strings（或簡稱String Ref）則旨在改善WebAssembly中對字符串的處理方式。在該提議出現前，每個語言的編譯器需要自己設計string在WebAssembly中的表達方式、編碼處理等。這種方式導致生成的wasm模塊中有大

141、量的邏輯用來處理string，進而增大模塊體積。另一方面，WebAssembly往往運行在一個特定的宿主環境中，在WebAssembly中實現的string可能無法被宿主環境直接使用，因此在宿主和wasm之間進行string傳遞時往往涉及到內存拷貝，影響性能。String Ref提議引入了一種新的引用類型，直接將宿主環境的string以引用的形式提供給WebAssembly，并通過一系列opcode來進行操作。這一提議使得編譯器無需再設計自己的string表達方式，同時避免了大量用于處理編碼的opcode，在降低編譯器實現復雜度的同時，也減小了生成的wasm模塊體積。同時，WebAssembl

142、y和宿主直接傳遞string時無需拷貝，也提升了性能。雖然該提議還處在階段一，但很快引起關注，目前v8、WAMR和Binaryen都已經支持。wasi-threads wasi-threads是WebAssembly系統接口（WebAssembly System Interface，WASI）的一個擴展提議，它的目的是在WASI環境中引入對多線程的支持，使得WebAssembly應用程序能夠創建、同步和管理多個線程。它提供了一個標準化的API來創建線程：status wasi_thread_spawn（thread_start_arg*start_arg），該API要求wasm runtime

143、實現對應的名為“thread-spawn”的WASI接口來創建線程，并準備好相關上下文，在新創建的線程中實現對wasm app函數的回調。另外它也在WebAssembly threads提議的一些原語基礎上實現了對互斥鎖（mutex）、條件變量等的支持，以便協調和同步多個線程的執行?；诖?，該提議實現了對pthreads大部分API的支持，目前工具鏈wasi-sdk已經基本實現了上述支持，并發布了wasi-threads的二進制包。而開源社區wasmtime和WAMR也分別實現了該提議，有興趣可以參考https:/bytecodealliance.github.io/wamr.dev/blog

144、/introduction-to-wamr-wasi-threads。53 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 Memory model of WAMR wasi-threads Memory 64、Multi-Memories和和Memory Control WebAssembly的內存模型是基于線性內存的，目前MVP版本（最小可行版本）中線性內存只支持Memory32，其地址范圍是32位，即一個線性內存最多有65536（=216）個page，而每個page有65536（=216）個字節，所以最多可以有232=4G個字節。這對于許多應用如Web應用和嵌入式系統來說是

145、足夠的，但對于某些工作負載，特別是需要大量內存的應用程序，如云計算、人工智能、虛擬化和容器等，可能不夠。因此Memory64提議被提出，以支持64位地址范圍，而相應的和線性內存訪問相關的規范或提議也被擴展，包括基本的memory操作、Bulk Memory規范、Shared Memory的atomic內存操作、SIMD-128規范中有關內存的操作等。目前Memory64已經進入到了階段三即實現階段，wasm runtime方面v8、wasmtime、wasmer和wasm2c等均已經提供支持，工具鏈方面LLVM、Emscripten和Binaryen也提供了支持。而wasi-sdk所依賴的基礎

146、庫wasi-libc也有開發者提交了支持Memory64的patch，期待在不久的將來Memory64可以在wasi-sdk中得到支持。Multi-Memories提議則意在支持在一個wasm模塊中使用多個線性內存，這樣做可以提高隔離和安全性，提供更靈活的內存管理，并且方便多模塊之間共享數據，比如模塊將私有數據存在一個內存實例，而需要和其它模塊共享的數據則存在另一個內存實例。目前該提議已經進入階段四即標準化階段，v8和Binaryen已經支持。Memory Control提議則希望可以減少native和wasm模塊以及wasm模塊之間的內存拷貝，54 20232023年度技術盤點與展望年度技術

147、盤點與展望|架構師特刊架構師特刊 并提供基于host mmap的內存映射和訪問控制方式，比如在對內存初始化后將它設置成只讀模式。它提出了memory.map和memory.protect等opcode，可選方案之一是將host內存映射成一個wasm的內存引用，然后允許將該引用的句柄在共享的heap中傳遞到另一個wasm模塊，這樣目標模塊可以通過該引用句柄來訪問對應的內存，從而實現零拷貝數據傳遞。雖然該提議在2022年初就停止了更新，但是目前引起了較多興趣，有不少討論希望能繼續推進該提議。Possible memory data sharing based on memory control p

148、roposal Component Model Component Model（組件模型）是一個在多語言環境下實現多個wasm模塊相互協作的提議，它引入了一套抽象類型解決多語言的類型差異，并用序列化/反序列化來解決抽象類型到wasm基本類型的過渡。該提議目前得到了社區的廣泛支持，在2023年取得了顯著的進展，支持提議的wasm runtime數量在增長，基于Component model抽象類型重制的WASI-preview2正式上線。工具鏈方面，Wasm-tools完成對提議的支持。55 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 Component model share

149、d everything dynamic linking sample Core Module Dynamic Linking 這里所說的Dynamic Linking是指最早由Emscripten提出的動態鏈接模型，用來將C/C+應用程序的源代碼劃分成幾個部分進行編譯，并在執行時將它們鏈接在一起。相對Component Model而言，Core Module進行鏈接的模塊是WebAssembly模塊，而不是對WebAssembly模塊進行了封裝的組件（Component）。這種動態鏈接方式相對簡單，目前在llvm-17.0中已經支持，而最新的wasi-sdk release版本也提供了支持。

150、Emscripten規定編譯器可以編譯出兩類的共享模塊：Main modules（主模塊）和Side modules（暫稱為副模塊）。其中只有主模塊可以把系統庫（如libc）一起鏈接進來，并且一個項目中有且只有一個主模塊，主模塊的一些symbol如函數可能依賴于副模塊，它們在執行時當副模塊被加載后被進行鏈接。同時主模塊有自己的線性內存和wasm table，而副模塊則沒有自己的線性內存和wasm table，副模塊共享主模塊的線性內存和wasm table，并且需要從主模塊的線性內存和wasm table中預留一部分空間來存儲自己的數據。通過這種方式，可以實現主模塊和副模塊之間的數據共享。而如

151、何在主模塊的線性內存以及wasm table中預留出部分空間給副模塊，以及對副模塊的鏈接時機，是在主模塊加載時鏈接（Load-time dynamic linking），還是在主模塊執行 56 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 時加載（Runtime dynamic linking），可能是wasm runtime實現時需要考慮的問題。從目前來看，除了瀏覽器之外，似乎還沒有standalone runtime實現了該技術。相對于組件模型，這種鏈接方式可以實現模塊間零拷貝數據傳遞以提升性能，并且內存消耗較小，實現也相對比較容易，缺點是多語言支持較差，目前

152、來看似乎只能支持C/C+/Rust等使用clang來編譯的語言。Possible linking between Main module and Side module wasi-nn wasi-nn是WebAssembly系統接口（WebAssembly System Interface、WASI）的另一個擴展，主要用于支持深度學習硬件加速。它被提出的原因之一是由于機器學習框架（例如Tensorflow）不容易被移植到WebAssembly SIMD并且較好地支持一些硬件特性來保證性能。它主要針對機器學習應用場景，允許在wasm模塊中訪問host提供的機器學習功能，可以用于模型訓練和推理，適

153、用場景包括自然語言處理、圖像識別、語音識別等領域。其支持多種深度學習模型框架，其中包括TensorFlow和OpenVINO等業界主流框架；其目標執行環境涵蓋了從中央處理器（CPU）、圖形處理器（GPU）到專為機器學習設計的張量處理單元（TPU）等多種計算硬件架構。目前WAMR、wasmtime和WasmEdge都對wasi-nn提供了支持，其中WAMR主要支持Tensorflow模型，而wasmtime和WasmEdge主要支持OpenVINO模型。有興趣可以參考https:/ AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 Simple working flow of was

154、i-nn Exception Handling WebAssembly Exception Handling（異常處理）提議旨在為WebAssembly添加類似Java或C+中異常處理的機制，使開發者能夠更好地管理和處理程序執行過程中的錯誤情況。該提議引入了“tag”的概念，使用tag來標識異常類型，當拋出一個異常時，會附帶一個tag來告訴調用者異常的類型，然后調用者可以在catch語句中根據tag來決定如何處理異常。目前該提議已經進入到階段三即實現階段，v8、Firefox和wasm2c都已經支持，WAMR在classic interpreter模式下也提供了支持（注：開發分支），工具鏈方面

155、LLVM、Emscripten和Binaryen也都已經支持。展展望望2024 更更多多wasm提議被寫入規范提議被寫入規范 目前GC、Func Ref、Multi-memories、Threads和Tail call等提議都已經進入到了階段四，隨著提議的進一步完善和穩定，有望在新的一年里正式寫入規范。而基于這些提議之上的應用，也將得到更加廣泛的發展，比如基于GC提議的Wasmnizer-ts和Kotlin、基于Threads提議的wasi-threads提議及相關的應用等。58 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 更更好地解決好地解決wasm模塊間數據

156、共享和模塊鏈接問題模塊間數據共享和模塊鏈接問題 關于wasm模塊與本機環境（Native）之間、wasm模塊之間的數據共享問題，一直是社區廣泛討論的議題。業界普遍期待能夠解決模塊之間零拷貝數據傳遞的問題，籍此提升性能表現。隨著一系列創新方案的提出以及工具鏈的不斷完善，這一挑戰有望得到更為有效的解決。另一方面，針對wasm模塊之間的鏈接與代碼共享難題，隨著Component Model和Core Module Dynamic Linking的發展，更多的wasm runtime正在逐步實現對模塊間鏈接與代碼共享的支持，這將進一步推動WebAssembly生態系統的高效整合。更更多的應用場景多的應

157、用場景 目前WebAssembly已經被廣泛應用到各個領域中，比如Web應用，圖像處理、IoT、人工智能、邊緣計算、區塊鏈等等。隨著wasm技術進一步成熟和工具鏈生態進一步發展，其在更多專業領域和場景的潛力將得以釋放。展望未來，我們預期wasm將在汽車、云原生、PLC、Snapshot遷移等場景得到采用。更更好的用戶體驗好的用戶體驗 WebAssembly發展面臨的主要問題之一是工具支持，這可能影響了一些用戶體驗。預計在新的一年里會有更多更友好的工具出現，比如AOT/JIT調試工具、多線程調試支持、性能監測工具、內存監測工具等。小小結結 總之，在過去一年里，WebAssembly多項提案得到了

158、顯著的演進與發展，諸多前沿特性和功能逐步獲得了各個WebAssembly運行時與工具鏈的廣泛支持。同時，我們也目睹了越來越多的應用場景和實際案例涌現出來，充分展示了WebAssembly技術的潛力與價值。展望新的一年，我們期待WebAssembly能夠在技術成熟度及實用性層面實現更為堅實而有力的突破，更好地為相關的行業、組織以及開發人員服務。59 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 作者介紹作者介紹 黃文勇黃文勇，Intel Web Platform Engineering軟件工程師，Wasm Micro Runtime項目Technical Leader 何良何良，

159、Intel Web Platform Engineering軟件工程師，Wasm Micro Runtime項目主要貢獻者 徐君徐君，Intel Web Platform Engineering軟件工程師，Wasm Micro Runtime項目主要貢獻者 Wasm Micro Runtime(WAMR)是一個運行在瀏覽器之外的Standalone WebAssembly虛擬機，支持Interpreter、AOT、JIT等多種執行模式，支持多種OS和多種CPU架構，具有高性能、低內存消耗、功能高度可配置等特性，適用于從嵌入式、物聯網、邊緣計算到可信執行環境、智能合約、云原生等各種應用。參考ht

160、tps:/ 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 并發王座易主？并發王座易主？Java 21Java 21虛擬線程強勢崛起，虛擬線程強勢崛起，Go&KotlinGo&Kotlin還穩得住嗎還穩得住嗎 采訪嘉賓：李三紅 作者：張衛濱，蔡芳芳 過去一年，編程語言發生了不少新變化。據JetBrain前不久發布的2023開發者生態系統現狀調研報告，在開發者主要采用的編程語言中，最受歡迎的分別是Java、Python、JavaScript，Java在2023年重奪第一名寶座，JavaScript則在下降三個百分點后跌至第三；Rust在2023年最受歡迎的編程語言中，

161、創造了新的使用記錄，其用戶群在過去五年中穩步增長，有望憑借其嚴格的安全性和內存所有權機制取代C+；此外，Rust 2023年首次取代Go成為希望遷移到其他語言的開發者的首選，而且Go用戶也是第一批準備采用Rust的人，JetBrains數據表明，有六分之一的Go用戶正在考慮采用Rust。61 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 伴隨著火熱發展的大模型技術浪潮，也有一些編程語言新玩家涌現出來。比如由Swift之父Chris Lattner帶領團隊推出的Mojo，其目標是統一碎片化的AI技術棧；又比如由IDEA研究院基礎軟件中心負責人張宏波及其團隊打造的Moonbit，推

162、出之初其定位為專為云計算和邊緣計算設計的WebAssembly語言，但如今Moonbit的最新定位已經演進為云和大模型時代下的開發者平臺。那么，大模型時代我們應該關注編程語言的哪些變化？本次“InfoQ年度技術盤點與展望”專題中，InfoQ邀請了Java、MoonBit、Rust、WebAssembly等不同編程語言的代表性技術專家、團隊分享他們的觀察和思考。本文是“2023 InfoQ年度技術盤點與展望”系列文章之一，由InfoQ編輯部制作呈現，我們采訪了阿里云程序語言與編譯器團隊負責人、Java Champion李三紅老師，他也是國內Java編程語言最具代表性的技術專家之一。他帶我們一同回

163、顧了過去一年編程語言整體和Java本身的重要進展。在他看來，Rust確實在系統軟件有巨大的影響力，但在業務領域Java和Go仍會占據主導地位，因為業務快速迭代需要技術本身的平民化；而2023年隨著Java 21版本發布的虛擬線程特性，有助于在并發方面鞏固Java在業務處理領域的地位。他還提及，大模型和生成式AI的發展對AI算力的提升提出了很高的要求，編程語言或編程系統承載著釋放底層并行硬件算力的使命。以下為訪談實錄，經過不改變原意的編輯 Rust空前火爆，但空前火爆，但Java和和Go仍將在業務領域占主導地位仍將在業務領域占主導地位 InfoQ：李老師您好，歡迎參加：李老師您好，歡迎參加Inf

164、oQ年度技術盤點與展望編程語言專題的采訪。在年度技術盤點與展望編程語言專題的采訪。在2023年，我們感覺編程語言領域的變化其實挺大的，比如年，我們感覺編程語言領域的變化其實挺大的，比如Java，有新的版本，有新的版本和新的特性交付和新的特性交付出來；另一個就是出來；另一個就是Rust編程語言，得到了大家空前的關注，在我們的微信群里還經?？淳幊陶Z言，得到了大家空前的關注，在我們的微信群里還經?？吹健笆褂玫健笆褂肦ust重寫”的表情包，這也從一個側面反映了它的影響力。您認為在重寫”的表情包，這也從一個側面反映了它的影響力。您認為在2023年，年，編程語言領域有哪些亮點，或者說有哪些值得關注的方面呢

165、？編程語言領域有哪些亮點，或者說有哪些值得關注的方面呢？李三紅李三紅：我首先介紹一下我所負責部門的基本情況。我們屬于阿里云的基礎軟件部門，基本上都是在編寫系統軟件，不管是編譯器還是操作系統，還有一些云原生組件，其實都屬于系統軟件領域，所以我主要從系統軟件這個角度展開討論。就編程語言領域來講，我的感受也是一樣的，就是Rust確實比較火，而且隨之而來的是 62 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 大家對內存安全（memory safety）問題的重視。Rust的設計原則是優先考慮內存安全。使用C、C+這樣的編程語言，我們很容易會遇到因為不正確的內存訪問導致的

166、Security Vulnerability問題（據2020年早些時候的一篇報告，Google Chromium團隊發現C+編寫的Chrome代碼庫中70%的安全漏洞與內存管理和安全相關1）。Rust作為系統編程語言，解決了內存安全的問題，同時兼具了像C和C+這樣的良好性能。和Java相比的話，Java語言在設計之初，也充分考慮了內存安全的問題（比如ArrayIndexOutOfBoundsException運行時檢查），Java也被稱為Memory-safe的語言。但是，目前使用Java語言編寫系統軟件還是不太可行，主要還是性能問題。而Rust在編寫系統軟件方面，則具有非常獨特的優勢，當然它

167、的學習曲線可能高一些。在最近召開的日本開源峰會（Open Source Summit Japan），邀請到了Linux的作者Linus Torvalds，他表示今年Linux一些重要的子系統（major subsystems）可能會使用Rust重寫。所以，我認為在整在整個系統軟件領域，個系統軟件領域，Rust的確是討論比較多，影響也比較大的一門編程語言的確是討論比較多，影響也比較大的一門編程語言。InfoQ：從目前了解的一些情況來看，不管是技術社區的討論，還是在業界的實踐，還：從目前了解的一些情況來看，不管是技術社區的討論，還是在業界的實踐，還有圖書出版，有圖書出版，2023年年Rust語言的

168、確是非?；鸨?，也是關注度特別高的一門語言。您剛才語言的確是非?；鸨?，也是關注度特別高的一門語言。您剛才也提到了，它可能更加傾向于系統級編程，也就是偏底層的一些場景，那么在解決方案也提到了，它可能更加傾向于系統級編程，也就是偏底層的一些場景，那么在解決方案領域，您覺得領域，您覺得Rust語言有沒有比較合適的一些場景？語言有沒有比較合適的一些場景？李三紅李三紅：我覺得在業務領域，在業務領域，Java和和Go還是會占據主導地位還是會占據主導地位。原因在于Rust的學習成本的確比較高。如果語言本身的學習成本比較高，而業務又要快速發展的話，往往會導致一些問題，比如，公司的人員儲備以及對技術的學習理解和掌

169、握都會出現一些不匹配或者產生較大的矛盾。業務本身的迭代會非?？?，比如在阿里，一個Java應用每一星期可能會有三到四個版本的發布。這樣的快速業務迭代就需要技術本身的平民化快速業務迭代就需要技術本身的平民化。就像James Gosling在1997年發表的論文The Feel of Java所言，Java是一門藍領語言。它非常平民化，適合快速發展的業務，每門語言都有自己的定位。InfoQ：對的，在業務：對的，在業務領域，對生產率要求比較高，相對來講對代碼的性能不像系統軟領域，對生產率要求比較高，相對來講對代碼的性能不像系統軟件那么高，另外再考慮到人才儲備的因素，我們應該還是優先選擇一些工業級的語言

170、，件那么高，另外再考慮到人才儲備的因素，我們應該還是優先選擇一些工業級的語言，比如比如Java、Go、Node.js等比較流行的語言?？偠灾?，我們需要根據業務場景和技術需等比較流行的語言?？偠灾?，我們需要根據業務場景和技術需求，選擇合適的解決方案。求，選擇合適的解決方案。63 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 虛虛擬線程特性對擬線程特性對Java未來發展意義重大未來發展意義重大 InfoQ：那我們回到：那我們回到Java的話題，現在的話題，現在Java的演進速度比以前要快得多，從您的角度來看的演進速度比以前要快得多，從您的角度來看的話，在過去的一年間，您比較關注

171、的特性都有哪些呢？的話，在過去的一年間，您比較關注的特性都有哪些呢？李三紅李三紅：正如你所言，Java現在每年有兩個版本，發布速度是很快的，這確實推進了Java的創新速度，讓我們感覺Java添加新特性更快、更有活力了。2023年Java發布了兩個版本，分別是Java 20和Java 21，其中Java 21是兩年一次的LTS版本，也就是Long Term Sup-port版本。我個人認為，Java 21是一個非常重要的發布，一方面因為它是LTS版本，另一方面是因為在Java 21中包含了虛擬線程（中包含了虛擬線程（Virtual Threads）特性。我認為在整個）特性。我認為在整個Java演

172、進演進上這都是一個非常重要的特性上這都是一個非常重要的特性。其實Java 1.0版本就已經將線程作為一個Built-in特性來設計了，它就是Java語言的一部分。而在Java之前的C+，設計之初線程并不是C+標準的一部分。直到C+11，標準庫才擴展支持線程庫能力。Java在設計之初就把線程設計為Java語言的一部分，Java的開發者很容易編寫并發的多線程程序，開發和認知的代價都非常小。Go語言在2009年誕生，將并發（Concurrency）作為Go語言的一等公民（First-Class Citizen），通過輕量級的“Goroutines”為并發執行提供支持。在Go語言中使用Goroutin

173、e是非常自然和容易的。Kotlin（JVM生態語言）誕生于2011年，Kotlin也是在設計之初就在語言層面支持了協程。2005年，C+專家Herb Sutter在Dr.Dobbs Journal（DDJ）發表了著名的文章The Free Lunch Is Over:A Fundamental Turn Toward Concurrency in Software，談到隨著摩爾定律的終結，計算機軟件將不得不、或者說被迫處理好基于多核處理器的大規模并發程序的效率問題，這對軟件的并發性能提出了極致的要求，這也是Go、Kotlin等語言把Coroutine納入到語言標準支持的原動力。其實也是由于歷史

174、的原因（在Java 8之前Java的創新速度非常慢），Java社區直到大約2016年左右，開始重視輕量級線程。Java學習了很多前人的經驗，包括編程語言之間的互相借鑒和學習，在Java 19中首次引入虛擬線程，經過兩個版本的迭代，虛擬線程最終在Java 21成為了一個標準的特性。雖然還存在一些局限，在生產環境有一些限制，但是 64 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 這并不妨礙它未來的發展。虛擬線程特性有助于在并發方面鞏固虛擬線程特性有助于在并發方面鞏固Java在業務處理領域的在業務處理領域的地位。地位。InfoQ：作為開發人員，我們最：作為開發人員，我

175、們最關注的確實是虛擬線程這個特性。因為它能夠以一種對關注的確實是虛擬線程這個特性。因為它能夠以一種對開發人員非常友好的方式提升系統的并發性能，但是正如您所說，它還是有一定的局限開發人員非常友好的方式提升系統的并發性能，但是正如您所說，它還是有一定的局限性，比如在使用方式上不推薦池化性，比如在使用方式上不推薦池化virtual threads，使用，使用synchronized原語會帶來一定的原語會帶來一定的副作用。不知道您在實際的線上項目中有沒有嘗試使用虛擬線程？副作用。不知道您在實際的線上項目中有沒有嘗試使用虛擬線程？李三紅李三紅：阿里有自己的基于OpenJDK的發行版，也就是Alibaba

176、 Dragonwell。就協程來講，Alibaba Dragonwell擴展版（Extended Edition）有一個自己的協程實現叫Wisp，它2015年左右在阿里內部孵化，2017年就已經在阿里大規模使用了。Wisp解決了使用synchronized block導致協程無法切換的問題。阿里內部相對來講是一個封閉的Java生態系統，我們可以使用我們自己的Wisp協程解決線上的高并發性能問題。就目前看，在生產環境，現在還是不太可能去使用虛擬線程。由對象監視器鎖所導致的虛擬線程pinning的問題，如果要去做對應的代碼修改，工作量是很大的，這也是我覺得在生產環境大規模使用虛擬線程的一個阻礙因素

177、。當然，現在整個社區也在考慮如何去解決這個問題。InfoQ：對：對，我們也看到一些開源框架，比如，我們也看到一些開源框架，比如Spring、Quarkus，都在虛擬線程方面提供，都在虛擬線程方面提供了很多的支持，了很多的支持，Spring就提供了針對虛擬線程的就提供了針對虛擬線程的Executor，我們相信在這個方面會有更，我們相信在這個方面會有更多的進展。多的進展。阻阻礙礙Java升級的原因升級的原因 InfoQ：接下來，我們關注另外一個問題，雖然現在：接下來，我們關注另外一個問題，雖然現在Java已經演進到了已經演進到了Java 21，但是據我，但是據我們了解，很多人員開發人員還在用著們了

178、解，很多人員開發人員還在用著Java 11，甚至有的項目還在用，甚至有的項目還在用Java 8。您覺得阻礙。您覺得阻礙大家升級大家升級JDK版本的阻力在什么地方？未來的一段時間，隨著版本的阻力在什么地方？未來的一段時間，隨著Spring新版本最低要求新版本最低要求JDK 17，會不會對國內互聯網公司和解決方案公司升級，會不會對國內互聯網公司和解決方案公司升級JDK版本有一定的作用？版本有一定的作用？李三紅李三紅：這確實是一個老大難的問題。正如我們剛才所說，Java語言本身的創新越來越快了。就像InfoQ 2023年的Java趨勢報告2所示，目前主流市場采用的還是JDK 8和JDK 11，而最新

179、的JDK版本已經到了JDK 21，中間的差距是很大的。這對于企業來講，也是一個非 65 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 常大的矛盾，因為OpenJDK社區很多的參與者，像ARM、Intel這樣的芯片廠商，都會基于最新的JDK版本做優化和支持，如果企業內部使用比較舊的版本，就會導致我們難以享受這樣的性能紅利。至于阻礙升級的原因，從阿里這邊的經驗來看，從JDK 8到JDK 11、JDK 17和JDK 21這樣的一個躍進，本身有很多兼容性問題，我相信技術視角與業務視角是有些沖突的。比如，作為業務架構師，我可能最優先考慮的是升級之后，底線要保證業務的連續性，不能因為升級帶

180、來穩定性事故。但是這可能只是一種外在表現，本質其實在于，在業務迭代很快的情況下，我們很多的底層架構本身對版本升級的容忍度沒有設計得那么完整，比如是否有健全的單元測試，是否對開源庫依賴有很好的版本收斂管理，是否有健全的灰度和監控系統，這都決定了是否能夠很容易地進行升級。如果代碼有很好的單元測試覆蓋，開源庫版本得到了很好的收斂和控制，有很好的灰度系統，我相信業務部門也會很想去升級的。所以，本質因素還是在于底層架構做的夠不夠好。對于Java升級，這里也給大家推薦一個工具-Eclipse Migration Tool for Java(EMT4J)，由阿里開源，目前在Eclipse基金會Adoptiu

181、m下孵化。初衷是希望把Java版本升級的專家經驗沉淀到這個工具，幫助Java開發者可以更快地升級到新的Java版本。InfoQ：對的：對的，可能本質還是在于我們底層的一些工程實踐有沒有做好。其實在我們的，可能本質還是在于我們底層的一些工程實踐有沒有做好。其實在我們的業務實踐中，還有一種場景就是一些安全漏洞，像業務實踐中，還有一種場景就是一些安全漏洞，像Spring逐漸會在更新的版本上去解決，逐漸會在更新的版本上去解決，較舊的版本不再維護，這也促使重視安全漏洞的公司不得不去升級較舊的版本不再維護，這也促使重視安全漏洞的公司不得不去升級Spring版本，進而帶版本，進而帶動動JDK版本的升級。版本

182、的升級。Java面向云原生的挑戰和解法面向云原生的挑戰和解法 InfoQ：還有一個問題是這樣的，周志明老師之前在：還有一個問題是這樣的，周志明老師之前在QCon的演講中提到過的演講中提到過Java在云原生在云原生領域的一些挑戰。比如，領域的一些挑戰。比如，Java語言更傾向于是一種長時間運行的語言，按照設計，隨著語言更傾向于是一種長時間運行的語言，按照設計，隨著運行，它的性能會越來越好，因為它要經歷一個二次編譯的過程。但運行，它的性能會越來越好，因為它要經歷一個二次編譯的過程。但是，現在有一些技是，現在有一些技術逐漸流行起來，正在顛覆術逐漸流行起來，正在顛覆Java傳統的一些使用場景，比如傳統

183、的一些使用場景，比如Serverless，在這種模式下，在這種模式下，Java就有一定的局限性，比如啟動和達到峰值性能慢。就有一定的局限性，比如啟動和達到峰值性能慢。Java社區目前也在致力于解決這社區目前也在致力于解決這些問題，如些問題，如GraalVM這樣的技術方案，您如何看待這樣的技術方案，您如何看待Java在云原生領域所面臨的挑戰？在云原生領域所面臨的挑戰？66 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 李三紅李三紅：云計算里面有個非常關鍵的概念叫做彈性，即“現用現付”(pay-as-you-go)的商業模式，通過“按需”的原則來提供彈性的資源。在沒有

184、用戶請求的時候，不占用任何資源，而在請求到來的時候，再去啟動實例資源處理請求。這樣的場景對Java的冷啟動提出了很大的挑戰。針對Java冷啟動這個問題，我覺得可以從三個技術維度來闡述。第一個就是百分百兼容Java標準的技術，它對Java應用沒有侵入，使用之后就能對應用啟動進行加速。比如說AppCDS。它本質上需要將Java應用先運行一遍，跑完之后，我們把它使用了哪些class給dump出來，第一遍運行的過程叫做trace。在后續第二遍運行的時候，因為已經知道了要加載哪些類，只需replay即可。它的好處在于完全兼容Java，對業務代碼無侵入，但是對運維和DevOps侵入比較大。第二個方向就是原

185、生鏡像（native image），即GraalVM。它有一個封閉性假設（close word assumption），它會把用到的所有的類進行靜態編譯，就像C+一樣，這樣就可以提高啟動速度。它的問題在于，雖然Java是一個靜態類型語言，但是它有很多的動態特性，比如反射、類的動態加載等，它們與原生鏡像不兼容，如果使用GraalVM原生鏡像的話，會導致一些預料之外的行為，因此這種方式對Java應用會有一定的侵入性。第三個方向，叫做檢查點和恢復（checkpoint-restore），以OpenJDK CRaC（Coordi-nated Restore at Checkpoint）項目為代表。這種

186、方式就是預先生成一個快照，如果新的請求進來，快速拉起快照即可。這種方式的問題在于，我們一般的Java應用都是stateful style編寫的，它對狀態的處理會比較困難。比如在Java應用中，我們要生成隨機數或者遞增的計數器，在恢復之后就可能會出錯。Java業界大致就是這三個方向，目前都在各自的道路上演進。而在代表著Java標準方面的演進，OpenJDK社區提出了Leyden項目3。Leyden會從Java標準的層面（Java語言以及虛擬機標準）解決Java啟動的問題，在Java層面Leyden引入了“Static Image”概念。InfoQ：正如您所言，這個領域未來一兩年值得期待，可能會有

187、一些突破性的一些技術：正如您所言，這個領域未來一兩年值得期待，可能會有一些突破性的一些技術出來。另外一個問題，在出來。另外一個問題，在Java領域，不管是在國內還是在海外，大家用的最多的依然是領域，不管是在國內還是在海外，大家用的最多的依然是Spring框架。它依然是統治級別的方案，但是現在像紅帽、框架。它依然是統治級別的方案，但是現在像紅帽、Oracle等公司，其實也在推等公司，其實也在推廣其他的解決方案，比如廣其他的解決方案，比如Quarkus、Micronaut等。雖然這些框架目前還沒有得到廣泛的等。雖然這些框架目前還沒有得到廣泛的 67 AIGCAIGC熱潮下的行業與技術百態熱潮下的行

188、業與技術百態 應用，但是它們都有自己的宣傳點應用，但是它們都有自己的宣傳點，比如與，比如與K8s或或GraalVM的集成更好。您認為這些技術的集成更好。您認為這些技術有沒有可能在某些領域顛覆有沒有可能在某些領域顛覆Spring的支配性地位呢？的支配性地位呢？李三紅李三紅：的確，Spring現在基本處于主導的地位。目前也有其他的一些框架，比如Quarkus、Micronaut等。以Quarkus為例，它是紅帽推出的框架。阿里是GraalVM Project Advisory Board的成員，在GraalVM社區層面，我們也有一些關于Quarkus的交流。Quarkus明確提出了自己的設計哲學，

189、就是容器優先（Container First），針對Java的啟動時間和內存使用進行優化。Quarkus的很多設計原則，有助于讓我們思考如何去實現中間件，面向云原生解決Java的問題，所以，我們需要關注的是：一方面它致力于在框架層面解決云原生訴求的問題，比如它提供了fast-jar的概念，通過在構建期提前計算好索引，解決Java類加載比較慢的問題。另一面在底層它考慮如何更好地結合類似GraalVM/Native Image、CRaC這樣的技術。目前來看，Spring是一個老牌的框架，擁有很穩定的市場地位，而且也在不斷演進，比如它的Spring Native相關技術，很難說未來誰能顛覆它。但是，

190、不同的框架互相借鑒和學習，對Java開發者是一件好事，我們能夠擁有豐富的軟件生態支持。對對Java整體發展的觀察整體發展的觀察 InfoQ：相信這些框架確實也會給到：相信這些框架確實也會給到Spring一些壓力，反過來推動它的進步。那么，在一些壓力，反過來推動它的進步。那么，在Java領域，除了語言層面的變化，在領域，除了語言層面的變化，在JVM底層，比如垃圾回收、性能優化層面，有什么底層，比如垃圾回收、性能優化層面，有什么值得關注的變化呢？值得關注的變化呢？李三紅李三紅：我想講一下對Java整體發展的觀察。阿里作為Java標準委員會JCP-EC成員，2023年四月份在阿里新加坡辦公室組織了一

191、次JCP EC專家委員會線下的閉門會議，探討了Java的未來發展。談談我對這次會議的感受。從一個開發者的視角來看從一個開發者的視角來看Java發展可以分為兩個方向，一個叫發展可以分為兩個方向，一個叫Scaling Up，一個是，一個是Scaling Down，分別指的是，分別指的是Java技術在功能方面往上演進以及在普及易用方面往下演進，也就技術在功能方面往上演進以及在普及易用方面往下演進，也就是兼顧更廣的人群。是兼顧更廣的人群。我們先說第一點（Scaling Up）。大家都知道Java在處理大型的、復雜的、跨團隊合作的 68 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架

192、構師特刊 項目是有其獨特的優勢的。在軟件開發階段，借助以康威定律為理論基礎的微服務最佳實踐，Java可以幫助一個復雜的大型組織極大釋放各個團隊的并行研發效率。而在軟件生產階段，Java給開發者提供了豐富的技術手段，從基礎的JFR（low-overhead JVM profil-ing技術）、BCI（Bytecode Instrument）、JMX到上層的各種監控、探針技術，極大提高了線上Java應用，尤其是大規模部署集群的可觀測性。同時，大量的Java性能診斷、問題排查工具，都可以快速有效地幫助開發者解決生產環境碰到的問題。由Oracle主導的OpenJDK社區發起的四大項目（Four Big

193、 Initiatives），即：Loom、Valhalla、Panama和Amber。前三個項目就和Java技術的Scaling Up方向演進直接相關。Loom我們前面討論虛擬線程的時候涉及到了，我們再展開聊聊Valhalla。Valhalla的目標是為Java增加Value objects、Primitive classes，以及Specialized generics的支持。大家都知道，在Java中除了八種基礎的primitive data types，一切皆對象。Java對象除了增加了額外的footprint負擔（對象頭），還引入了通過對象指針（JVM內部表示）的數據間接訪問的性能代價。

194、這涉及到計算機體系結構領域被反復提到的一個概念，叫做內存墻（Memory Wall）。在80年代、90年代早期，CPU去訪問內存和在CPU內進行計算的代價是差不多一個數量級的。Java是90年代初設計出來的，Java對象內部實現依賴了大量的間接指針。就80、90年代的硬件而言，相比CPU內計算，訪問內存的代價也許是可以接受的。但是對于現代的硬件體系結構而言，CPU訪問內存相對于執行計算的代價，一次cache miss的相對代價是相當高的。如何更高效地訪問內存數據結構，就是Valhalla致力于解決的問題，包括它提出的原始類型以及如何對指針結構進行扁平化，避免層級查找。整體上在整體上在Scali

195、ng Up方面的發展，方面的發展，Java一直在致力于思考如何更好地服務面向企業級的計算，以及更好地服一直在致力于思考如何更好地服務面向企業級的計算，以及更好地服務于大規模分布式的場景。務于大規模分布式的場景。而第二個方面就是所謂的所謂的Scaling Down，Java也很關注像學生群體學習也很關注像學生群體學習Java語言本身的入語言本身的入門難度問題門難度問題。因為相對于Python這樣的語言，Java的學習門檻會比較高，需要先了解面向對象編程，要學會編寫一個static main函數，這對于初學者，尤其是面向低年齡段比如中小學生，它的學習曲線仍然比較高。Java目前比較關注這個問題，在

196、JDK21（JEP 445 4）和JDK 22（JEP 463 5）中做了一些改進，使得Java能夠像Python一樣，很簡單就能把入門程序寫出來。大大模型爆發后，編程語言哪些變化值得關注？模型爆發后，編程語言哪些變化值得關注？69 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 InfoQ：目前，在技術領域，大語言模型是非常熱門的話題，您認為在大模型和生成式：目前，在技術領域，大語言模型是非常熱門的話題，您認為在大模型和生成式AI的時代，編程語言的進展會有哪些變化？會不會出現一些像云原生時代的的時代，編程語言的進展會有哪些變化？會不會出現一些像云原生時代的Go語言那樣的語言那樣

197、的特別適合特定業務場景的一些編程語言。特別適合特定業務場景的一些編程語言。李三紅李三紅：今天AI確實是比較火，突然間就爆發了。其實，它本身對AI基礎設施的影響還是比較大的。鑒于GPU卡的價格還是比較昂貴，不管是推理還是訓練的成本都很高。這對整個AI基礎軟件的效率和性能優化提出了很大的挑戰，也就是如何更高效地利用底層的AI算力，實現最大的性價比?，F在，市場上主流的可能還是以英偉達的GPU卡為主，而軟件方面基本以CUDA生態為主導。CUDA在2007年發布，CUDA不僅是一種編程語言，也包含它背后的高性能編譯系統，以及近十幾年圍繞CUDA構建的軟件生態（一系列高性能函數庫等）。但對于開發者而言，使

198、用CUDA編程去釋放GPU潛力的學習門檻也是比較高的。AI領域還有一些AI編譯器（ML Compiler），它們的目標也是讓AI模型更高效，也更好地利用底層異構平臺的算力，降低手寫CUDA的代價。當然，很多有經驗的工程師手動編寫的CUDA代碼要比AI編譯器生成的代碼好得多，這也考驗AI編譯器的自動編譯能力編譯器的自動編譯能力，是否能夠更大化釋放底層的AI算力，這是它所面臨的挑戰。除此之外，AI領域的硬件架構碎片化領域的硬件架構碎片化也比較嚴重，是典型的昆蟲綱悖論問題。它不像通用編程語言Java、Go在數據中心使用的CPU架構，相對統一，主流的就是X86、Arm等這么幾種架構類型。2023年AI

199、爆發，像我們前面說的，對AI算力的提升提出了很高的要求。所以我們期望能我們期望能夠從編程語言或編程系統去釋放底層并行硬件的算力，這本身也是編程語言應該承載的夠從編程語言或編程系統去釋放底層并行硬件的算力，這本身也是編程語言應該承載的東西。東西。在2023年的編程語言層面，值得關注下Mojo，它是LLVM的作者Chris Lattner提出的，目前還處于一個很早期的開發階段。從公開的資料，我們能夠看到它想解決的問題：第一個問題就是所謂的“兩個世界的問題”（Two-world Problem），Python與高性能的C、C+代碼互操作帶來的系統復雜性。Mojo可以認為是Python的超集，具有Py

200、thon的易用性，同時又具備C/C+的高性能。70 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 第二問題就是CUDA是針對英偉達硬件的軟件生態系統，CUDA有自己的局限性，比如缺乏一致的debuggers、profilers工具支持，被綁定在特定的硬件廠商。Mojo以及背后的Modular公司有可能想去解決Three-world或N-world的問題。借助一門編程語言以及借助一門編程語言以及更加開放的生態，能夠安全地去釋放整個異構更加開放的生態，能夠安全地去釋放整個異構GPU的算力問題，這還是值得期待的。的算力問題，這還是值得期待的。InfoQ：正如李老師所言，

201、這是一個蓬勃發展的領域，可能會有一些顛覆性的技術出來，：正如李老師所言，這是一個蓬勃發展的領域，可能會有一些顛覆性的技術出來，或許能迅或許能迅速地占據統治性地位。如今速地占據統治性地位。如今OpenAI的的GPTs已經初步展現出自然語言編程能力，已經初步展現出自然語言編程能力，在您看來，自然語言編程目前還有哪些挑戰或限制？目前之所以還沒有真正去落地實現，在您看來，自然語言編程目前還有哪些挑戰或限制？目前之所以還沒有真正去落地實現，它的阻礙在于什么地方？它的阻礙在于什么地方？李三紅李三紅：這塊我也沒有太直觀的感受。目前，比較值得關注的是微軟Copilot的自動代碼生成功能。我認為，AI和自動代碼

202、生成在可預見的未來，有可能釋放程序員的開發性工和自動代碼生成在可預見的未來，有可能釋放程序員的開發性工作，大大提升開發人員的工作效率。作，大大提升開發人員的工作效率。InfoQ：是的，目前業內都在做一些相關的嘗試。使用自然語言直接編程也許還有一些：是的，目前業內都在做一些相關的嘗試。使用自然語言直接編程也許還有一些難度，但是業界的一些實踐確實會帶來我們開發人員工作效率的難度，但是業界的一些實踐確實會帶來我們開發人員工作效率的提升。非常感謝李老師提升。非常感謝李老師接受我們的采訪，并分享您對接受我們的采訪，并分享您對2023年編程語言領域的見解。年編程語言領域的見解。參考鏈接參考鏈接 1 htt

203、ps:/ https:/ https:/ https:/openjdk.org/jeps/445 5 https:/openjdk.org/jeps/463 71 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 AndyAndy教授教授20232023年數據庫回顧：向量數據庫年數據庫回顧：向量數據庫沒有技術護城河！沒人能靠技術大佬背書“假沒有技術護城河！沒人能靠技術大佬背書“假裝成功”裝成功”作者：Andy Pavlo 譯者：核子可樂 策劃：李冬梅 本文是由世界知名數據庫行業專家Andy Pavlo教授撰寫的2023年數據庫回顧文章。最近幾年，每一個歲末或年初，Andy教授都會撰

204、寫下關于過去一年他對數據庫領域的觀察和感悟，他的系列文章不僅整理和收納了數據庫領域的大事件和技術發展趨勢，更為數據庫領域從業者提供了寶貴的參考和啟示。在本文中，Andy教授首先回顧了2023年數據庫領域的重要里程碑，包括技術進步和業界動態。他還詳細闡述了在這一年中引起廣泛關注的幾個主題，如向量數據庫、自然 72 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 語言查詢和SQL之間的關系、人工智能崛起為數據庫領域帶來的機遇等。AI前線對本文進行了翻譯，以便廣大讀者能夠更好地理解相關內容，緊跟全球的數據庫動態。新年新氣象，盡管發生了很多糟心事，但我還是要對過去一年間的各

205、主要數據庫事件和趨勢進行回顧和盤點，畢竟2023確是數據庫發展歷程中的重要一年。我的目標是繼續保持犀利但公正的觀點，同時過濾掉那些言過其實的炒作言論。向向量數據庫的興起量數據庫的興起 2023年無疑是向量數據庫全面興起的一年。盡管其中一些系統幾年之前就已經誕生，但出于人們對大語言模型及相關服務應用（例如ChatGPT）的廣泛關注，向量數據庫終于在這一年中迎來全面爆發。向量數據庫能夠根據數據的語義、而不僅僅是內容，來對數據（特別是非結構化數據）進行深入搜索。換句話說，應用程序現在可以直接搜索關于特定主題的內容，而不是僵硬地查找具體關鍵字。這種“神奇”搜索的背后離不開transformers，這項

206、技術能夠將數據轉換成固定長度的一維浮點數向量，被稱為嵌入。人類無法直接理解這些嵌入中的值，但其內容卻編碼了參數和transformers訓練語料庫之間的某種關系。這些嵌入向量的大小范圍從簡單的數百維transformers，一路延伸到高端模型中的數千維。當我們使用transformers為數據庫內的所有記錄生成嵌入時，即可通過在高維空間中查找最接近搜索嵌入的記錄嵌入來找到特定輸入的相似記錄。但是，暴力比較所有向暴力比較所有向量來尋量來尋找最接近匹配項會帶來極高的成本找最接近匹配項會帶來極高的成本。這項操作的復雜度為O(N*d*k)，其中N代表嵌入數量，d是各個向量的大小，k是我們需要的匹配數量

207、看不懂也沒關系，這本身就是項艱深的技術，大家隨便聽聽就好。這時候就輪到向量DBMS發揮作用了。從本質上講，向量DBMS就是一種擁有專門索引數據結構的文檔數據庫，用于加快對嵌入相似性的搜索過程。這些系統可以使用近似搜索來生成結果，而不是傻傻對每項查詢的最相似向量執行精確匹配。如此一來，我們就能以“足夠好”的效果換取更快的返回速度。剛剛遭遇2022年區塊鏈數據庫的海量崩潰之后，沮喪的風險投資商們猛然嗅到了向量數 73 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 據庫中的商機，并再次興奮起來。他們開始為向量數據庫領域的幾乎每家主要廠商都注入了大筆種子資金。在2023年的種子輪融資當

208、中，Marqo拿到530萬美元，Qdrant斬獲750萬美元，Chroma則獲得1800萬美元。Weaviate在2023年4月的B輪融資成功籌得5000萬美元，而這一年中領跑全場的還得說Pinecone的1億美元B輪。這下可真是抄上了。小小結：向量數據庫沒什么技術壁壘結：向量數據庫沒什么技術壁壘 在2022年底大語言模型在ChatGPT的加持下進入“主流”視野后，多家DBMS廠商只用不到一年時間就推出了自己的向量搜索擴展，其中包括SingleStore、甲骨文、Rocket和Clickhouse。幾大PostgreSQL衍生系統也宣布將支持微量搜索，其中一些使用到pgvector-ryna(

209、Supabase、AlloyDB)，也有幾家使用其他開源ANN庫（Timescale、Neon等）。Mon-goDB和Cassandra等領先NoSQL DBMS也引入了向量索引。就在DBMS向量支持功能快速普及的同時，JSON數據類型也在迅猛崛起。采用原生存儲JSON的NoSQL系統是從2000年代末起開始流行的（包括MongoDB和CouchDB），但又過了好幾年，關系型DBMS才開始添加對JSON的支持（PostgreSQL、Oracle和MySQL的支持時間分別是在2012年、2014年和2015年）。SQL標準在SQL:2016中引入了對JSON靈氣進行操作的函數，但直到SQL:20

210、23才正式將JSON數據類型添加進來。鑒于許多關系DBMS早已支持具有相似概念的XML數據類型，這樣的滯后的確令人感到意外。向量搜索索引的快速增長有兩大潛在原因。首先，通過嵌入進行相似性搜索開始成為愈發重要的用例，迫使每家DBMS廠商都匆忙推出了自己的版本。其二是這種引入新型訪問方法和索引數據結構的工程量并不算大，所以DBMS廠商往往可以快速發布自己的向量搜索功能。大多數廠商根本不需要從頭開始編寫向量索引，而只需集成市面上可用的幾種高質量開源庫（例如微軟DiskANN和Meta Faiss等）。而從這個角度來看，向量搜索功能的實現工作量不高，導致向量導致向量DBMS廠商根本沒有足廠商根本沒有足

211、夠深的護城河來抵御老牌夠深的護城河來抵御老牌DBMS廠商的競爭壓力廠商的競爭壓力。我最近曾給Pinecone和Weaviate公司的聯合創始人提出忠告，建議他們的系統采取兩條發展路徑：其一是由客戶用這些向量DBMS作為“記錄數據庫”，而廠商則為操作工作負載提供更好的支持。這樣他們的產品就會越來越像目前流行的文檔型DBMS（例如 74 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 MongoDB），并在五年之內像之前的NoSQL系統那樣添加對SQL的支持。另一條路則是將向量DBMS作為上游主流DBMS的輔助性方案，目前其實已經有不少人在以這樣的方式使用Elastic

212、和Vespa等搜索引擎DBMS。如此一來，向量DBMS不能在不擴展自身查詢語言或者改變數據模型結構的前提下維持生存。旁注：我最近還專門錄制了一期向量與關系數據庫的問答節目，提到在未來五年內，每一種關系DBMS都將擁有自己的一套高性能向量索引實現。SQL正變得越來越好正變得越來越好 剛剛到來的2024年，也恰好是Don Chamberlain和Ray Boyce在IBM研究院發明SQL的五十周年。SQL最初被命名為SEQUEL（結構化英語查詢語言），自上世紀八十年代以來一直是數據庫交互領域的客觀標準編程語言。盡管SQL歷史悠久，但其用途和功能一直在不斷更新，并在過去十年間迎來了顛覆性變化。就在去

213、年，ISO/UEC 9075規范發布了最新版本，即SQL:2023。此次更新引入了大量“錦上添花”的功能，用以解決不同SQL方言（例如ANY_VALUE）中的不一致問題。值得一提的是，其中對SQL的兩項增強進一步削弱了對替代性數據模型和查詢語言的需求。但請注意，SQL新規范包含這些內容，并不代表大家常用的關系DBMS會立即支持這些新功能。截至2024年1月，據我了解唯一支持SQL/PGQ功能的DBMS就只有Oracle。DuckDB倒是提供一個支持SQL/PGQ的實驗性分支，但仍無法正常運行以上示例，因為其支持的語法仍略有區別。多維數組（多維數組（SQL/MDA）：自從SQL：1999引入有限

214、的一維、固定長度數組這種數據類型以來，SQL就正式開啟了自己的數組支持之旅。SQL:2023擴展了這項功能，可以支持未對最大基數進行預定義的嵌套數組。SQL:2023中的SQL/MDA更新能夠支持使用基于整數的坐標的任意維度多維數組。Rasdaman的RQL極大啟發了SQL/MDA語法，以提供與SQL兼容且符合其集合語義的結構及操作數組構造。這些增強功能使得應用程序可以完全在SQL之內對多維數組執行操作 75 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 和交互，而無需單獨導出（例如導出為Python notebook）。下表所示，為在CREATE TA-BLE語句中使用MDA

215、RRAY數據類型的幾種不同示例：盡管SQL.MDA規范自2019年就已經發布，但直到SQL:2023才被納入官方標準。據我了解，除了Rasdaman之外，還沒有哪種生產級DBMS能夠支持SQL/MDA擴展。我能找到的唯一其他原型就只有HSQLDB的一個分支，名為ASQLDB。小小結：自然語言查詢永遠取代不了結：自然語言查詢永遠取代不了SQL SQL：2023修訂版代表這種通用語言邁進了持續發展和改造的下一階段。當然，SQL仍不算完美、也不具備真正的可移植性，因為每種DBMS都有自己的怪癖、專有功能和非標擴展。我個人最喜歡PostgreSQL的:cast運算符快捷方式。SQL/PGQ雖然意義重大

216、，但我覺得它在短時間內還不足以對圖DBMS造成致命打擊。畢竟已經有多種方法可以將面向圖的查詢轉換為SQL，不少DBMS（包括SQL Server和Oracle）也提供內置的SQL擴展，能夠降低圖數據存儲和查詢的門檻。Amazon Neptune是亞馬遜云科技旗下Aurora MySQL產品上的圖數據庫方案。Apache AGE在PostgreSQL之上則提供 76 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 OpenCypher接口。預計諅 要OLAP系統（例如Snowflake、Redshift和BigQuery等）也將在不久的將來支持SQL/PGQ。在DBM

217、S中添加SQL/PGQ，絕不像添加新語法支持那么簡單。必須關注一系列工程要點，才能保證圖查詢操作擁有良好的性能。例如，圖查詢會執行多路連接來遍歷整個圖結構。但當這些連接的中間結果大于基表時，往往會引發問題。DBMS必須使用最壞情況最優連接（WCOJ）算法來改善表間常用的哈希連接方法。另一項重要技術，則是使用factorization來避免連接期間實現的冗余中間結果。這類壓縮方法能幫助DBMS避免一遍又一遍地用相同連接消耗內存。我這里提出的優化方法，并沒能在現有圖DBMS中全部得到實現。因為據我所知，Neo4j、TigerGraph等領先系統也還做不到。我聽說過的唯一面向圖系統就是滑鐵盧大學的嵌

218、入式Kuzu DBMS。此外，大多數關系DBMS也還沒有實現（至少那些開源數據庫還不行）。前文提到的DuckDB有個實驗分支實現了WCOJ和factorization優化，并在2023年的論文中提到，其在行業標準圖基準上的操作性能比Neo4j高出10倍。但正如前文提到，SQL在大多數讀者朋友出生前就已經存在，也將在我們故去后依舊堅挺?？傊?，我反對一切所謂自然語言查詢將徹底取代SQL的說法。旁注：兩年之前，我曾公開打賭說在2030年之前，圖DBMS還不可能在數據庫市場上取代關系DBMS。至少就目前看，我的結論仍然正確。MariaDB身陷困境身陷困境 去年，MariaDB開始在新聞報道中頻頻亮相，

219、而且大多不是什么好事。我們發現獨立于MariaDB基金會之外的MariaDB公司已經后院起火。2022年，該公司嘗試借殼上市，但股價在IPO后的三天內迅速下跌40%。而為了加快上市速度而搞的借殼操作也被公之于眾。截至2023年底，該公司股價較開盤以來已累計下跌超90%。面對一系列財務問題，該公司被迫宣布了兩輪裁員。第一輪是在2023年4月，并隨后在2023年10月進行了一輪更大規模的精簡。該公司還宣布將淘汰兩款產品：Xpand和Sky-SQL。MariaDB公司于2018年收購了當時名為Xlustrix的Xpand；2014年時我曾參觀過Clus-trix的辦公室，發現那里就像一座令人毛骨悚然

220、的鬼城（巨大的樓層中，有半數房間都 77 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 關著燈）。SkySQL的來歷則更為復雜，他們最初是一家提供MariaDB服務的獨立公司，后來在2013年與Monty Program AB合并。2014年，合并后的兩家公司共同成為我們如今熟知的MariaDB公司。但就在去年12月，該公司宣布SkySQL將會轉為一家獨立企業。MariaDB公司的情況如此糟糕，導致其基金會CEO專門撰文，抱怨自IPO以來基金會與公司間的關系如何快速惡化，并表達了“重啟”的意愿。其他壞消息還包括：微軟于2023年9月宣布，未來不會繼續在Azure上提供Maria

221、DB托管服務，轉而專注支持MySQL。有些朋友可能不太熟悉，MariaDB就是MySQL的一個分支，是MySQL締造者Monty Widenus在甲骨文于2009年宣布收購Sun Microsystems后開發而成?？偠灾?，當初被放棄的MySQL表現良好，而作為新興替代力量的MariaDB卻身陷困境。所以還看什么宮斗戲，多關注數據庫市場什么都有了！小小結：數據庫行業無法再用技術大佬的背書來“假裝成功”結：數據庫行業無法再用技術大佬的背書來“假裝成功”過去十年以來，數據庫客戶明顯變得越來越精明了。企業沒辦法再通過華而不實的基準數據、承諾取代SQL的新查詢語言或者技術大佬的背書來“假裝成功”。D

222、BMS的聲譽比以往任何時候都更加重要。也就是說，DBMS軟件本身及其背后的開發企業需要齊心協力，任何內斗都將直接削弱產品的市場生命力。而且也別指望著開源能讓項目長久存續，事實告訴我們，任何DBMS項目都很難在相應的營利性公司倒閉后繼續健康發展。少數反例就只有PostgreSQL；再加上為MySQL構建InfiniDB OLAP引擎的公司在2014年破產之后，其GPLv2源代碼被繼承下來并成為MariaDB中的ColumnStore。相反，更多例子表明一旦沒有營利企業來支撐項目開銷，DBMS將很快消失。感興趣的朋友可以去看看Apache基金會的庫存清單，了解到底有多少DBMS項目被這樣徹底廢棄。

223、純云DBaaS（數據庫即服務）方案的出現令形勢變得更加嚴峻。因為一旦公司失?。ɑ蛘哓攧諣顩r不佳），用于托管數據庫的服務器也將被快速關停。Xeround曾在2013年關閉數據庫時，給了客戶兩周時間來遷移數據庫。為了削減成本，InfluxDB雖在2023年7月下線整個服務區前給客戶預留了六個月過渡期，但此舉仍令人們感到震驚。MariaDB顯然比大多數普通數據庫初創企業的情況更好，畢竟Monty等成員還建立起了控 78 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 制這個開源項目的非營利基金會。但對于任何一個開源DBMS項目，只要負責賺錢的公司跟負責推進項目發展的基金會

224、發生了沖突，項目本身可就危險了！而且就在此時此刻，MySQL仍在不斷改進，且甲骨文用實際行動證明自己確實是非常優秀的企業業務管理者（至少在工程層面是這樣）。相信MariaDB公司的亂象，將進一步推動用戶群體轉向PostgreSQL。但作為Monty用自己女兒名字命名的數據庫，我也相信MariaDB仍會繼續存在下去。自自研數據庫崩潰導致美國航空業中斷研數據庫崩潰導致美國航空業中斷 2023年1月11日，受NOTAM系統中斷影響，美國聯邦航空管理局（FAA）被迫叫停了美國境內的所有航班。NOTAM系統負責向飛行員提供純文本編碼消息，并就飛行路徑上可能遇到的意外變化或潛在危險發出警告。1月11日上午

225、，NOTAM系統崩潰，導致全美約1.1萬個航班暫停起飛。但擁有獨立航空通報系統的其他國家未受此次系統故障的影響。根據FAA的解釋，此次中斷是由數據庫文件損壞所造成。第三方承包商的工程師嘗試用備份替換該文件，但發現操作過程導致備份文件也被損壞。類似的問題曾經在2008年導致FAA的原有基礎設施出現同樣的故障。目前并不清楚FAA在NOTAM系統中到底使用的是哪款DBMS。但有報道表明，該系統至今仍運行在兩臺1988年的飛利浦DS714/81大型機上。這些設備使用的根本就不是我們熟知的現代操作系統，而上世紀六十年代的老古董。也就是說，FAA明顯沒能在上世紀八十年代利用Oracle、Ingres和In

226、formix等能夠支持各種Unix平臺的DBMS完成現代化改造。我個的合理推測是，NOTAM系統使用的可能是普通文件（例如CSV）自托管數據庫。這些由非數據庫專家編寫的應用代碼負責從文件中讀取/寫入記錄，將結果復制到備用服務器并在崩潰時保障數據完整性。小小結：在老掉牙的內部自結：在老掉牙的內部自研數據庫上工作，是開發者的噩夢研數據庫上工作，是開發者的噩夢 在不可替代的遺留硬件上運行關鍵任務系統，并使用早已老掉牙的內部原研自定義數據庫，可以說是每一位數據庫從業者最恐怖的噩夢。我很驚訝NOTAM居然拖到現在才崩潰（或者說2008年搞出問題的也是同一套系統？），所以面對這樣一套能夠支持運行35年 7

227、9 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 的“出土文物”，我反倒有點肅然起敬了。有消息人士稱，NOTAM系統每秒只能處理20條消息。以現代標準來看，這確實少得可憐。但還是那句話，這套系統的部署是在上世紀八十年代。數據庫傳奇大佬、1998年圖靈獎獲得者Jim Gray曾在1985年專門撰文介紹“普通”DBMS如何每秒執行50項事務，而非常高端的DBMS每秒甚至能夠處理200項事務。作為參考，五年之前曾有人用八十年代的基準（即基于TPC-A的TPC-B）在Raspberry Pi 3上運行過PostgreSQL，最終性能也大致就是每秒200項事務。但如果不考慮跨數據中心間的

228、強一致系統（約束其性能的唯一瓶頸就是光速），現代單節點OLTP DBMS在某些工作負載上可以輕松實現每秒數百萬項事務。所以必須承認，NOTAM哪怕是以上世紀八十年代的標準看也沒達到頂尖水準，放在今天更是落后得嚇人。由于NOTAM沒有將數據庫跟應用程序邏輯區分開來，所以根本不可能對這些組件進行獨立升級?？紤]到當時人們已經很清楚關系模型的優勢所在，這樣的設計哪怕放在當年也該受到批判。我們并不能說SQL就一定可以阻止這次故障（畢竟這屬于人為錯誤），但至少組件間的獨立性可以讓系統更加靈活、也更易于管理。而且，美國政府當時已經開始使用商用關系型DBMS。例如，Stonebraker的RTI（Ingres

229、的開發商）就曾在1988年的上市文件中提到，其客戶包括國防部、財政部、多個軍事部門和研究實驗室。我相信美國政府的其他部門當時肯定也在使用IBM DB2和Oracle。所以，硬要選擇NOTAM并延續至今，在我看來是個不可理喻的決定。在聽說這事時，我正從阿姆斯特丹坐飛機返回美國。幸運的是，故障并沒有影響到入境航班，所以我們的飛機可以正常按時降落。但后來我還是被困在了紐瓦克機場，因為所有國內航班都被迫中止。聊聊聊數據庫融資聊數據庫融資 除了前文提到向量DBMS的風險投資熱潮之外，其他類型的數據庫系統在過去一年中也吸納了不少資金。但總體而言，這一年的數據庫融資熱度要比往年冷清得多。自動調優初創公司DB

230、Tune在歐洲籌集到260萬美元的種子輪資金；PostgresML的種子輪則融得450萬美元，這筆款項將用于構建自定義擴展DBaaS以通過SQL調用機器學習框架。80 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 TileDB在秋季宣布了3400萬美元的B輪融資，用于繼續構建其陣列DBMS。盡管已經成立13年有余，SQReam仍憑借其GPU加速型DBMS完成了4500萬美元的C輪融資。Neon于2023年8月拿下4600萬美元B輪融資，用以擴展其無服務器PostgreSQL平臺。這一年中最大的融資贏家當數Databricks，他們于2023年9月的I輪融資中獲得5

231、億美元巨資，但仍遠不及2021年H輪的16億美元。2024年1月5日更新：這里補充一下，MotherDuck（DuckDB的商業版本）于202年9月籌得5250萬美元B輪融資，而DBeaver則憑借其備受裝腔的DBMS管理工具拿到500萬美元種子輪融資。2023年數據庫領域還出現了不少收購。最大的一次發生在去年年初，Progress Software以3.55億美元現金直接買下了MarkLogic后者是歷史最悠久的XML DBMS之一（誕生于2001年前后）。Progress旗下還擁有OpenEdge，它的出現甚至早于MarkLogic（約1984年）。IBM收購了Meta的衍生公司Ahana

232、，后者嘗試對PrestoDB進行商業化改造（與現已更名為Trino的硬分叉PrestoSQL不同）。多云數據庫服務商Aiven收購了AI驅動型查詢重寫器初創公司EverSQL，EnterpriseDB則借用貝恩資本的資金收購了Seafowl團隊后者開發出基于DataFusion、能夠兼容PostgreSQL的OLAP引擎。Snowflake則分別收購了兩家初創公司：其一是由前斯坦福大學教授Peter Bailis創立的Sisu Data，其二是由伯克利大學教授Aditya Parameswaran創立的Ponder（基于Modin）。小小結：大模型相關產業，仍將受到資本青睞結：大模型相關產業，

233、仍將受到資本青睞 搞風投的朋友告訴我，跟往年相比，2023年市場上出現了更多新興企業，但資方卻謹慎地捂緊了錢袋子。這種趨勢其實在整個初創領域都有體現，只能說數據庫也未能幸免。當然，唯一的例外就是AI+大語言模型，對于這類有望開拓計算領域新疆土的項目，大資本們仍然慷慨而熱情。盡管2023年內，美國的一系列宏觀經濟指標開始轉好，但科技行業仍然心存疑慮并努力尋求降本增效。以OtterTune為例，客戶們希望我們能更積極地優化數據庫，幫助他們在2023年內降低數據庫基礎設施成本。與之對應，之前客戶們的主要訴求集中在提高DBMS的性能和穩定性上。我們計劃在2024年發布新功能，切實達成成本節約目標。而在

234、我自己帶的班里，大學生們紛紛請我幫他們推薦數據庫開發崗位。要知道，卡耐基梅卡耐基梅 81 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 隆大學的計算機科學系享有盛譽，如今這里的學生居然都很難靠自己找到理想的實習機隆大學的計算機科學系享有盛譽，如今這里的學生居然都很難靠自己找到理想的實習機會和全職崗位了會和全職崗位了，看來大環境的確不好。如果美國的科技市場繼續保持這樣的頹勢，那么多數數據庫初創企業在未來幾年內恐怕都很難有實質性發展。規模較小的DBMS廠商可能被科技巨頭或者私募股權公司吞并，甚至直接消亡。另一方面，那些憑借高估值籌得大量資金的公司也同樣身陷困境。正如前文提到，其中很

235、多可能根本無法成功上市，也沒有多少科技大廠會用這些DBMS，因為這是個人人都有自家DBMS的時代。對于這些體量很大、但還不夠大的初創公司來說，擺在面前的路有三條：要么繼續進行融資來維持公司運轉；要么通過Cloudera等私募股權機構尋求幫助；要么接受IT服務公司（例如Rocket、Actian）的收購，在維持原有系統穩定的同時，繼續從被鎖定的遺留客戶身上榨取許可費用。但對于一家有追求的數據庫公司來說，這三條路明顯都不理想，而且明顯不利于繼續擴大客戶受眾。最后我要提醒大家的是，Databricks的問題已經不是要不要上市，而是什么時候上市。有有史以來最貴的一次密碼修改史以來最貴的一次密碼修改 O

236、G數據庫專家Larry Ellison在2023年的事業可謂蒸蒸日上。對于他本就出色的職業生涯來說，這又是再創輝煌的一年。2023年6月，他重登全球第四大富豪的寶座。甲骨文股價在2023年內上漲了22%，幾乎追平標準普爾500指數的24%回報率。2023年9月，Larry生平第一次前往微軟總部，與軟件巨頭的CEO一道宣布Oracle DBMS將以托管服務的形式正式登陸Azure云。在2023年11月，股東們又以壓倒性的多數票，決定讓79歲的Larry繼續擔任甲骨文董事會主席。但2023年真正的大新聞，還和蠊馬斯克砸下10億美元收購社交媒體Twitter之后，親自幫助Larry重置了賬戶的密碼。

237、通過這次價值10億美元的密碼重置，Larry終于在2023年10月發出了自己的第二條、也是近十多年來的唯一一條推文。Larry表示自己即將動身前往牛津大學，隨后宣布將在牛津創建Ellison理工學院（EIT）。其實Larry具體發了什么并不重要，真正重要的是Larry重新回歸Twitter了。我還通過個人門路打聽到，Larry會偶爾閱讀Twitter消息，而且主要關注創業宣傳、熱情的生日祝福還有他自己靈光一現時的各種想法。82 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 通過Larry的推文，我們終于發現這位技術圈大佬原來也有日常生活，并不像人們想象中那么日理萬

238、機畢竟這家伙可是擁有自己的米格-29戰斗機外加一座夏威夷海島。而更讓人羨慕嫉妒恨的是，他還有位更有錢的好友，甚至愿意拿出10億美元（捎帶著）幫他重置賬戶密碼。感覺10億太多了？朋友們，當你身價1030億時，這真的不算多。新新的一年，更加精彩的一年，更加精彩 我滿心期待2024年，也會把更多時間和精力投入到數據庫領域。Dana、Bohan和我創立的OtterTune公司也即將迎來四周年生日。這段經歷教會了我很多，也讓我們的數據庫優化服務擴展到了最初的學術原型以外。面對新的一年，我們打算分享更多關于使用AI技術改進現有MySQL和PostgreSQL DBMS的亮點和成果。我們也將開發更多新的增強

239、功能，幫助更多用戶輕松維護起穩定可靠的自有數據庫。備注：別忘了在數據庫上多跑ANALYZE，你的DBMS查詢優化器會感謝你的。如果嫌麻煩，也可以選擇用OtterTune自動解決。原文鏈接原文鏈接 https:/ 往年文章鏈接往年文章鏈接 https:/ https:/ 83 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 顛覆軟件工程、“殺死”開發者？回溯大模型顛覆軟件工程、“殺死”開發者？回溯大模型落地應用這一年落地應用這一年 作者：凌敏 20世紀60年代末出現的“軟件危機”揭示了軟件開發中的諸多問題，也是在此時，軟件工程概念正式誕生。此后，軟件工程的發展經歷了多個階段。自去年

240、ChatGPT帶火大語言模型熱潮后，軟件工程的發展迎來了里程碑式的新跨越：大模型增強了自然語言處理能力，使得人機交互更直觀，并以協同者的形式參與到軟件開發的整個周期中，推動了編碼任務的自動化，加快了開發周期和提升軟件產品的質量。如今，大模型已經可以在軟件開發的多個環節（如功能設計、代碼開發、測試）中發揮作用，未來，大模型的能力邊界還將繼續擴大。越來越多的開發者擔心自己在某一天會被AI所取代，甚至有人用“OpenAI殺死了開發者”來形容當下的困局。一些技術專家也給出了悲觀的預測：84 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 Fixie聯合創始人兼CEO、前谷歌

241、Chrome移動團隊工程總監Matt Welsh：“程序員這個工作或許在三五年內不復存在，甚至編程這個學科都會被終結?！盨tability AI創始人兼CEO Emad Mostaque：“五年內，人類程序員將徹底消失?！瘪R斯克：“有一天，人們將告別艱苦的工作，人工智能將接管大部分任務?！币源竽Ｐ蜑榇淼腁I技術在過去一年以超乎想象的速度進化，不斷重塑我們的生活和工作方式?；厮荽竽Ｐ图夹g在軟件開發領域落地應用這一年，究竟帶來了哪些改變？開發者如何應對大模型帶來的沖擊？在大模型的驅動下，軟件開發又將走向怎樣的未來？大大模型已經成為軟件工程變革的最大推動力模型已經成為軟件工程變革的最大推動力 大大

242、模型浪潮下，編碼助手走向自動化模型浪潮下，編碼助手走向自動化 早在2020年，大模型就已經在技術領域得到應用，但在當時，大模型還局限在自然語言中。隨著2022年11月底ChatGPT的發布，以及GPT-4、LLaMA等大模型相繼亮相，大模型早已超越了自然語言范疇，發展到了編程語言。匯量科技Mobvista技術VP兼首席架構師蔡超認為，2023年AI領域的大事件除了包括GPT-4、LLaMA、Falcon等大模型的發布，以Copilot形式為代表的大模型技術在不同領域的應用同樣值得關注，如Microsoft 365 Copilot、GitHub Copilot等等，這些Copilot讓AI真正成

243、為了一個人類的虛擬助手或員工，并深刻地改變很多行業的工作模式。與傳統的機器學習方案相比，這波大模型浪潮在編碼助手領域的明顯趨勢是性能獲得顯著提升、且構建門檻大幅降低：基于大模型的自動編碼能力可以遵循設計指令，通過簡單的自然語言交互生成高質量代碼和程序。同時，項目研發過程中形成的數據、經驗和業務需求也可以被大模型掌握并轉化為通用的軟件工程能力，進而取代更多的流程和工具，解決復雜的開發難點和團隊協作問題。騰訊機器學習平臺技術總監、算法負責人康戰輝認為，大模型浪潮的興起推動了AI編碼助手邁向自動化，并存在以下三大發展趨勢：85 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 第一，過去

244、的AI編碼助手主要應用于軟件工程領域。但如今，所有通用的大模型都具備編碼功能，這是該領域的一項明顯變革。第二，盡管過去存在諸如啟發式規則和深度學習等方法，但現今的AI編碼助手展現出了更高的智能化水平。它們不僅處理代碼輔助輸入和續寫，還能通過自然語言與人類交互，這一特點尤為強大。第三，大家過去常談及低代碼或無代碼的趨勢，主要通過拖拽和積木式工具實現。而今，借助AI編碼助手，開發人員和技術人員只需用自然語言清晰地描述想法，便能輕松實現低代碼、無代碼開發。這意味著低代碼、無代碼的概念已發生變化。2023年，大模型正加速進化。最新發布的GPT-4顯著提升了代碼能力，也讓大家看到了其在多個公開代碼測試集

245、上的出色表現。同時，LLaMA等開源大模型也加速了AI編碼助手在業界的應用，不少企業基于開源大模型進行領域增訓，代碼版本表現卓越?！艾F如今，許多公司可以基于開源的代碼模型構建自己的Copilot，進一步加速AI代碼助手的實際應用。這不僅在閉源和開源領域產生了積極影響，還促使更多公司開發自己的代碼助手。隨著Copilot概念的普及，各公司正采取多種方式提升效能，深入整個研發鏈路。這可能標志著AI編碼助手領域的一個重要趨勢變化?！笨祽疠x提到，更加值得思考的是，代碼在從大模型中獲取大量世界知識和邏輯知識的同時，也在反哺大模型代碼在從大模型中獲取大量世界知識和邏輯知識的同時，也在反哺大模型。通用大語言

246、模型其邏輯能力的提升在很大程度上得益于代碼續寫。代碼作為一種類似于自然語言的表達方式，為模型提供了豐富的邏輯訓練數據。由于很多代碼是用英語編寫的，其中的保留詞與英語非常相似，這種以自然語言為基礎的代碼符號實際上表達了一種人類的邏輯。因此，代碼續寫和大語言模型之間存在著相輔相成的關系。通過代碼續寫，大語言模型能夠更好地理解和表達人類的邏輯，從而提升其邏輯推理能力。同時，大語言模型的發展也為代碼續寫提供了更強大的工具和平臺，使得代碼續寫更加高效和準確。這種相輔相成的關系不僅有助于提升大語言模型的邏輯能力，還能夠促進代碼續寫的進一步發展。未來，隨著技術的不斷進步和應用場景的不斷擴大，代碼續寫和大語言

247、模型將會在更多領域發揮其巨大的潛力。思碼逸創始人兼CEO任晶磊認為，從長期來看，大模型已經成為軟件工程變革的最大推從長期來看，大模型已經成為軟件工程變革的最大推 86 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 動力，并有望為軟件開發團隊提供新的人工智力資源和更高效的協作方式動力，并有望為軟件開發團隊提供新的人工智力資源和更高效的協作方式。但短期內，大模型的基礎能力未必能夠達到人們想象中的美好愿望?！八晕覀冊?023年也看到了GPT編程的冷熱交替。人們對大模型的認知被推上愚昧之巔，又走向絕望之谷親歷種種跌宕起伏，我們的心態也受到很多沖擊?！贝蟠竽Ｐ蜁r代下的編碼

248、工具及背后技術模型時代下的編碼工具及背后技術 不少受訪專家提到，在大模型技術的加持下，編碼工具能力邊界得到了進一步拓展。過去的編碼工具主要依賴于語法樹和部分統計機器學習技術，應用場景主要是針對函數級的續寫，例如在編寫代碼時，可以快速地利用某個代碼庫中的公共功能，但通常只能理解某個函數或API上下文，然后生成相關代碼片段，存在一定的局限性。據網易杭州研究院人工智能專家、AI算法團隊負責人劉東介紹，目前IT行業主要存在兩大類經過大模型改造過的工具：面向專業程序員，主要是專注于編程開發環節的編碼助手工具產品，包括代碼補全、函數生成、代碼糾錯、Chat咨詢開發相關問題，以及簡單的測試用例生成，典型工具

249、如在JetBrains、VSCode等主流IDE中提供智能編程助手插件等。面向數據消費人員，尤其是業務、產品、運營等非技術人員，過去主要是GUI形式的BI工具，涉及維度、指標等概念的理解，門檻比較高、操作復雜。目前已有基于大模型的對話式BI產品，如有數ChatBI等，能夠降低非技術人員取數門檻、提升數據分析效率。雖然當前主流的AI編碼工具與傳統編碼工具存在相似性都是在主流IDE中作為插件產品提供給開發者，但其背后的技術方案卻存在顯著的差異：在AIGC時代，主要的算法技術方案是大模型和檢索增強。背后具體又涉及到幾個關鍵技術，如以自然語言為代表的深度學習技術、強化學習技術等。此外，代碼模型需要處理

250、大量的代碼數據，同時還需要通用數據來學習背后的邏輯和知識，因此大模型技術還包括大數據處理能力，特別是處理代碼的能力?！澳壳霸贏IGC編程工具中，代碼領域大模型、項目代碼等檢索增強技術必不可少，對實際編程體驗都有顯著影響。代碼大模型是讓編程工具更聚焦到編程領域，檢索增強技術更能有效利用企業項目代碼或個人代碼倉庫、以實現個性化實時信息增強?！本W易數帆人工智能產品線總經理胡光龍總結道。87 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 代代碼模型開發有哪些關鍵點？碼模型開發有哪些關鍵點？隨著大模型熱潮持續升溫，越來越多的國內外科技公司參與其中，押注AI大模型及相關AI應用。其中，國內

251、的AI大模型包括百度“文心一言”、阿里云“通義千問”、騰訊“混元”、華為“盤古”、網易“玉言”、抖音“云雀”、智譜AI“ChatGLM”、中科院“紫東太初”、百川智能“百川”、浪潮信息“源”、商湯“日日新”、科大訊飛“星火”等等。值得一提的是，不少大模型都具備編程能力，大模型通過學習大量的代碼樣本，可以理解和生成代碼，甚至可以完成代碼修復和自動編程等任務。浪潮信息人工智能軟件研發總監吳韶華認為，大模型通常在語言相關任務上表現出色，在邏輯和計算方面相對較弱。但從GPT-4開始，編程能力逐漸受到開發者的重視，并成為評估大模型能力的重要標準。盡管編程能力不一定是大模型的“基本”能力，但當前許多大模型

252、確實具備了一定的編程能力。對于大模型來說，提升編程能力的關鍵在于建對于大模型來說，提升編程能力的關鍵在于建立代碼更改與人類指令之間的聯系。通過層次化的自然語言將算法任務分解，逐步引導立代碼更改與人類指令之間的聯系。通過層次化的自然語言將算法任務分解，逐步引導模型完成代碼生成。模型完成代碼生成。這種方法對訓練數據的質量要求極高。為了實現這一目標，開發者需要精心選擇和準備高質量的訓練數據，以確保模型能夠從中學習到有用的知識和技能。此外，還要不斷優化模型的架構和訓練過程，以提高模型的編程能力和泛化能力。據康戰輝介紹，在代碼模型的開發中，有幾個關鍵點不容忽視：首先，高質量的代碼數據是基礎高質量的代碼數

253、據是基礎。這不僅涉及到數據的收集，更重要的是數據的清洗。由于編程語言的多樣性，人工干預在代碼清洗過程中是必要的，團隊需要理解什么是高質量的代碼，這涉及到代碼的格式和實現質量。這就需要領域代碼的專業人員來進行高質量的代碼識別和清洗，他們能夠識別出優秀的代碼并進行整理。其次，如果代碼存在缺陷或錯誤，如何進行修正也是關鍵如果代碼存在缺陷或錯誤，如何進行修正也是關鍵。這相當于為代碼模型提供一些“老師”，以確保模型不僅能學習到數據，還能糾正錯誤。因此，高質量的數據標注對于模型的表現至關重要。這需要團隊投入大量的時間和精力在數據清洗和修正上。此外，安全性是另一個重要考慮因素安全性是另一個重要考慮因素。雖然

254、底層代碼可能是安全的，但如果涉及到與用戶界面的交互，如SQL查詢等，就可能存在SQL注入等安全風險，前端代碼也可能存在漏 88 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 洞。這需要團隊對領域代碼語言有深入理解，并關注安全性問題。因此，具備綜合能力的人才在解決這些問題上將發揮關鍵作用?！翱偟膩碚f，代碼模型的開發是一個多目標的過程，既要求對代碼本身有深刻理解，又要求對安全性等方面有專業知識。這意味著需要各領域的專家，并且需要具備多方面技能的人來處理這些問題?！笨祽疠x總結道。除了基礎大模型，2023年也涌現出了很多軟件開發垂直領域的專業模型，以及各種協助型AI編程工

255、具。比如在低代碼平臺領域，網易數帆自研玉言NL2NASL領域大模型，將低代碼平臺升級為CodeWave智能開發平臺，聚焦在以全棧低代碼、智能大模型為基座打造的軟件開發工具平臺；思碼逸基于ChatGPT開發了一款可以輔助研發效能提升的插件DevChat，支持VS Code和IntelliJ多種主流IDE，將大模型能力送到開發者手邊。劉東認為，大模型在落地應用方面有著巨大的想象空間，其中最重要的一個方向是利用自然語言進行人機交互（LUI），LUI相比傳統的命令行和GUI方式更為便捷和自然。在軟件工程領域，大模型的應用目前仍處于探索階段，“大模型在軟件研發工作流中最大的價值是輔助人工提效。業界期望能

256、夠在軟件工程全鏈路中使用大模型，包括項目管理、需求分析、編程開發、智能測試、部署運維等環節，期望能提升全鏈路效率，加速軟件開發?！盇I大模型在研發效能提升方面具有獨特的優勢和潛力大模型在研發效能提升方面具有獨特的優勢和潛力 那么，在軟件開發的過程中應用大模型或其他AI技術，實際體驗如何？真的可以提效嗎？分析公司OReilly日前發布的2023 Generative AI in the Enterprise報告指出，越來越多的開發者正積極在工作中應用AI技術：77%受訪者使用AI來輔助編程；54%受訪者預計，AI的最大好處是提高生產力；66%受訪者預計，利用AI編程是未來開發人員“最需要的技能”

257、；16%從事AI工作的受訪者表示正在使用開源模型。不少受訪專家在接受InfoQ采訪時也提到，個人及團隊會在內部研發中廣泛應用大模型，確實提升了研發效率?！拔覀冊?023年初，GPT3.5-Turbo發布之后就開始著手將大語言模型應用到我們軟件開發過程中，并且與公司的DevOps平臺MaxCloud結合，構建了DevOps Copilot，還開發了我們自己的VS Code插件?！辈坛岬?，隨著時間的推移，大 89 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 模型的應用范圍已經從最初的運維和部署環節擴展到了軟件開發的全過程，包括設計、編碼、測試、部署以及線上維護。從實際效果來看，

258、大語言模型在軟件開發中的應用取得了顯著成果?！案鶕覀兊慕y計數據，現在的使用頻率和代碼生成量都比最初翻了近10倍，線上系統的發布效率及穩定性都有很大提升?！睂τ谄髽I而言，研發效能的提升至關重要，甚至有觀點認為，研發效能高已經成為一家科技公司的核心競爭力。AI大模型通過自動學習和生成代碼，加快開發速度，減少開發時間和人力成本，并通過自動化的測試和優化來進一步提高開發效率，提高代碼質量和穩定性，其在研發效能提升方面具有獨特的優勢和潛力，能夠降低人們落實最佳工程實踐的阻礙和成本。任晶磊提到，實際上，許多開發者并不是不知道什么是最佳工程實踐，而是由于時間和精力的限制，或者是因為惰性，不愿意去做。僅僅依

259、靠管理者的口頭要求往往很難推動實施。例如，按照規范編寫提交信息、編寫單元測試等，需要開發者付出額外的精力。如果AI大模型能夠顯著減少人們在這些方面所需的精力消耗，降低成本和阻礙，那么它就能夠有效地推動開發者和團隊采取實際行動。因此，AI大模型的應用有望提高開發者的生產力和效率，推動軟件開發行業的持續發展。但一個事實是，當前大模型的產出還是需要人來把握和負責，類似于L1/L2級別的自動駕駛，人在其中扮演的角色至關重要。這也代表著，研發效能度量本身并沒有發生根本性變化，依然可以通過統計項目或團隊的需求吞吐、代碼當量、缺陷密度等指標度量研發效能?！皬膭諏嵉慕嵌瘸霭l，我們建議企業首先將大模型應用于效果

260、更加可見的場景中，否則這部分投入很快也會被管理層挑戰。例如，輔助寫好單元測試，可以提升單元測試覆蓋率（可見的結果），特別是覆蓋復雜度高、被依賴多的高危函數（也是可見的結果）；輔助寫好提交消息，項目獲得可讀性更高的提交歷史，效果直接可見，還能方便數據分析（比如可以呈現投入在新功能、bug修復、重構等不同類型工作中的代碼當量占比）；輔助重構代碼，可以直接估算AI替代人重復勞動的工作量。行勝于言，這三個場景正是我們打造DevChat過程中優先選擇的重點?！比尉Ю谡f道。90 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 OpenAI殺死了開發者？殺死了開發者？新技術的出現

261、往往會對傳統的工作方式和職業產生沖擊，大模型技術也是如此。大模型在為開發者帶來生產力提高等機遇的同時，也引發了大家對其“是否會取代開發者”的擔憂，甚至有一種更加極端的聲音認為“OpenAI殺死了開發者”。表面上看，OpenAI確實具備加速殺死大大小小AI開發者的能力：從企業層面來看，OpenAI的每次重磅發布、開發者大會都會顛覆原有的市場競爭格局，有開發者感嘆“OpenAI每發布一個功能，就消滅了一家初創公司”“OpenAI殺死了YC 2023年整個batch的項目”；從個人層面來看，自ChatGPT發布以來，關于AI取代開發者的討論甚囂塵上，更有聲音認為“程序員這個工作或許在三五年內不復存在

262、，甚至編程這個學科都會被終結”。不少專家在接受采訪時表示，“AI取代開發者”這個觀點過于偏激取代開發者”這個觀點過于偏激。吳韶華認為，AI在編程領域的能力還沒有達到完全取代開發者的水平，雖然AI編程助手可以提高程序員的效率，讓程序員的產出更高質更大量，但目前主要還是體現在效率方面?！败浖_發行業是拼效率的行業，同樣的產品，誰更高效更快速的推向市場，誰就能贏得市場的先機，而沒有大模型外掛加持的開發者和有大模型加持的開發者，其效率的差距會越來越大。因此，對于軟件開發行業來說，現在就應該毫不猶豫地引入大模型技術，以提高開發效率。同時也要考慮將大模型引入到目前的軟件中，給用戶帶來更高效流暢的體驗?！焙?/p>

263、光龍對此也有相同的觀點，當前，基于大模型的智能編程工具在實際業務中的應用，并沒有像外界所想象的那樣徹底顛覆現有的軟件開發流程，而是作為一種輔助工具，增強了開發者的能力。在軟件開發流程中，開發者需要承擔許多職責，包括需求溝通、評審、分析建模、架構與模塊設計、測試等。實際上，編碼只占整個開發流程的約30%，即使AI生成的代碼占比達到20%，全鏈路的效率提升也只有6%左右，效果并不顯著。對于開發者來說，這些智能編程工具是一種新的工具，掌握和使用這些工具可以提升項目開發效率，這是這些工具的最大價值。在AI時代，開發者需要掌握這些新式編程工具，并利用它們提升自身技能，更好地支持企業項目并創造價值。因此，

264、開發者需要積極擁抱這些新技術，不斷學習和適應新的開發方式，以保持自身的競爭力和適應未來的發展。91 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 從另一方面來看，大家對“OpenAI殺死了開發者”的擔憂實際上也在提醒我們：在AIGC時代，“開發者”角色正在被重新定義。AI技術正在軟件開發領域扮演越來越重要的角色，它通過自動化重復性任務和提供深入見解來改變軟件開發流程，并賦予了開發者新的涵義。蔡超認為，在AI時代，開發者不再只是編寫代碼的人，而是需要具備利用AI工具來提高生產效率和創造力的能力。這個時代的開發者應該是一個能夠與AI合作，利用AI的能力來解決更復雜問題的創新者?！八?/p>

265、以說，OpenAI并沒有殺死開發者，而是在推動開發者向更高層次的角色轉變?！迸c其擔心被AI取代，開發者真正的挑戰是如何更好地與AI合作，積極探索與AI的協作方式。在AI大模型的驅動下，軟件開發過程將變得更加自動化，因此在開發過程中，開發人員的角色也可能會發生變化。比如，測試人員將更加側重于驗證模型生成的代碼是否滿足需求和質量標準，研發人員還需要額外關注模型的持續學習和優化，以確保軟件能夠適應不斷變化的需求?！翱偟膩碚f，由大語言模型驅動的軟件開發可能會使一些角色變得不那么重要，而另一些角色變得更加關鍵。特別是，編碼工作可能會減少，而對于理解和指導模型的能力的需求可能會增加?！辈坛偨Y道。未未來，

266、大模型將如何改變軟件研發工作流？來，大模型將如何改變軟件研發工作流？盡管當前各式大模型及AI編碼工具百花齊放，但我們還需清晰地認知到，目前大模型還不能生成復雜項目級別的代碼。不少受訪專家提到，當前GPT-4依然是天花板，國內大模型仍在追趕中。預計2024年，基于大模型的編程能力的工具軟件將逐漸落地，越來越多的開發者將開始使用大模型進行輔助編程。隨著用戶基數的增加，大模型的編程能力將進一步提升，最終達到易用好用的目標。展望未來，下一代生產力工具應該是什么樣子的？不少專家表示，下一代生產力工具不下一代生產力工具不僅僅是一個知識庫，更是一個具備強大推理能力和多模態理解能力的伙伴僅僅是一個知識庫，更是

267、一個具備強大推理能力和多模態理解能力的伙伴。它能夠根據不同的外界輸入進行推理，并提供精準的答案和建議。這種伙伴關系可以幫助我們更好地應對各種挑戰，提高工作效率和創造力，并肩作戰，取長補短?！袄硐胫械木幊坦ぞ邞撌怯脩糁恍杳枋鲂枨?，軟件就能自動完成開發。這種工具需要具備自動完成需求分析、接口定義、編碼開發、自動測試和發布部署等功能。然而，根據目前的AIGC技術原理，實現這一目標可能還有一定難度。未來，我們可以關注低代碼 92 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 +AIGC、多模態和Agent等方向的發展?！焙恺執岬?。從短期和長期視角來看，康戰輝認為短期內

268、需要探索如何利用大模型來快速生成原型。例如，根據用戶的需求和設計，快速生成出相應的模塊框架圖和原型。這需要開發者克服一些技術挑戰，比如如何將設計轉化為模型可理解的形式，如何保證生成的原型的質量和功能等。從長期來看，我們有望實現更為遠大的目標。例如，給定一個原型圖，模型能夠自動構建出一個完整的原型，包括前端和后端的實現。這需要我們解決一些關鍵的技術問題，如如何將圖形信息轉化為代碼，如何處理底層邏輯和復雜的模塊組織等?！翱傊?，要讓大模型在軟件開發領域發揮更大的作用，我們需要不斷提升其多模態的能力、推理能力和復雜模塊組織能力。這將有助于提高開發者的效率和軟件的質量，進一步推動軟件開發行業的發展?！笨?/p>

269、戰輝總結道。采訪嘉賓（按姓名首字母排采訪嘉賓（按姓名首字母排序）序）蔡超蔡超，匯量科技Mobvista技術VP兼首席架構師 胡光龍胡光龍，網易數帆人工智能產品線總經理 康戰輝康戰輝，騰訊機器學習平臺技術總監、算法負責人 劉東劉東，網易杭州研究院人工智能專家、AI算法團隊負責人 任晶磊任晶磊，思碼逸創始人兼CEO 吳韶華吳韶華，浪潮信息人工智能軟件研發總監 93 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 今年向量數據庫“殺瘋了”，但純向量數據庫今年向量數據庫“殺瘋了”，但純向量數據庫“涼”了？“涼”了？作者：李冬梅 2023年，大模型爆火，也給數據庫領域帶來了一些新風向。過去

270、一年，中國數據庫行業發展迅速，隨著數據量與復雜度的提高，行業對分析和查詢特性提出了更高的要求，并行化、實時性、湖倉一體等特性成為主流需求。同時，隨著AI應用的普及，數據庫需要提高對向量分析和AI應用的支持能力，這一點也成為行業共識，而AI應用也帶來了庫內分析智能化的新機遇。與此同時，向量數據庫（Vector Database）“異軍突起”。向量數據庫，顧名思義，是一種以向量數據為基礎的數據庫。在傳統的關系型數據庫中，數據是以表格的形式存儲的，而在向量數據庫中，數據則是以向量的形式存儲的。這種新型的數據庫技術，能夠更有效地處理和分析大數據，因此在大數據時代中受到了廣泛的關注和應用。94 2023

271、2023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 在今年數據庫領域所有的技術趨勢中，向量數據庫無疑成為了最受矚目的一個。2023年數據庫領域大事件回顧年數據庫領域大事件回顧 1月10日，KaiwuDB（原：開務數據庫）發布了KaiwuDB 1.0時序數據庫，其運用到實時就地運算等核心專利技術，專為工業物聯網、數字能源、交通車聯網、智慧產業等場景設計。3月31日，openGauss 5.0.0里程碑版本發布。openGauss 5.0.0是openGauss發布的第三個LTS版本，版本生命周期為3年。openGauss 5.0.0版本與之前的版本功能特性保持兼容，在內核能力、工

272、具鏈、兼容性方面全面增強。4月4日，TiDB 7.0正式發布。新版本中累計引入新特性20余項，優化功能50余項。TiDB 7.0是TiDB 7系列首個DMR版本，適用于開發、測試和PoC等場景。4月21日，荷蘭AI原生向量數據庫廠商Weaviate獲得5000萬美元B輪融資。27日，美國明星向量數據庫廠商Pinecone宣布籌集了1億美元的B輪融資。6月15日，星環科技分布式向量數據庫Transwarp Hippo正式發布。6月30日，九章云極DataCanvas將DingoDB升級為多模向量數據庫，并已于去年開源。7月4日，騰訊云發布AI原生向量數據庫。9月19日，Fabarta正式發布Ar

273、cNeural多模態智能引擎，提供支持圖、向量和AI推理的一體化融合。10月17日，柏睿數據在北京證監局辦理輔導備案登記，擬首次公開發行股票并上市。11月15日，中國信通院聯合騰訊云計算（北京）有限責任公司、中移（蘇州）軟件技術有限公司、北京楓清科技有限公司（Fabarta）等多家企業共同編制的、國內首個向量數據庫標準正式發布。11月16日，OceanBase發布一體化數據庫的首個長期支持版本4.2.1 LTS。作為4.x的首個LTS版本，該版本的定位是支撐客戶關鍵業務穩定長久運行，可在關鍵業務負載中規?；?95 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 使用，已在生產環境

274、支撐上百個業務系統穩定運行。2023年度關鍵技術趨勢年度關鍵技術趨勢 向向量數據庫是當之無愧的“年度之星”量數據庫是當之無愧的“年度之星”人工智能是當前最熱門的技術之一，它與數據庫的融合將成為數據庫領域的一個重要趨勢。AI可以幫助數據庫更好地處理和分析數據，提高數據處理的效率和準確性。同時，AI也可以幫助數據庫更好地支持業務決策，提高企業的競爭力。隨著大模型的興起和向量計算的重要性日益突出，向量數據庫的發展也受到了廣泛的關注。向量數據庫專注于存儲和處理向量數據，并提供高效的向量搜索和相似性匹配功能。這種數據庫的出現是為了滿足越來越多應用場景對于高維度數據和向量計算的需求。在近年來，一些數據庫廠

275、商已經開始原生支持向量嵌入和向量搜索的功能，并提供了相應的向量索引和查詢優化技術。這使得開發人員能夠更方便地在數據庫中存儲和查詢向量數據，而無需依賴額外的工具或庫。除了大語言模型的推動外，向量數據庫在自身技術上也取得了重大突破，特別是在性能優化、數據處理能力和安全性方面。各數據庫廠商和研究機構都在致力于改進向量數據庫的算法和架構，以提高其處理大規模數據的能力。英偉達CEO為向量數據庫“站臺”更將向量數據庫的關注度推向了最高點。在今年的英偉達GTC大會上，英偉達CEO黃仁勛三次強調AI的“iPhone時刻”已經到來，他也提及了GPU加速的重要性。黃仁勛稱，“加速計算并非易事，需要從芯片、系統、網

276、絡、加速庫到重構應用的全棧發明，每個經過優化的堆棧都會加速對應應用領域?！薄凹铀儆嬎闶菧p少功耗、實現可持續發展和凈零排放的最好方式?！倍诩铀賻觳糠?，黃仁勛提到了向量數據庫的重要性?！跋蛄繑祿斓囊粋€新型重要用例是大型語言模型，在文本生成過程中可用于檢索領域特定事實或專有事實。英偉達將推出一個新的庫，即RAFT，用于加速索引、數據加載和近鄰檢索。我們正在將RAFT的加速引入到Meta的AI向量相似性搜索FAISS、Milvus開源向量數據庫以及Redis?！彼缡钦f。96 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 在資本市場，近一年來向量數據庫是當之無愧的“資

277、本寵兒”，Qdrant、Chroma、Weaviate先后獲得融資，成立短短幾年的Pinecone宣布1億美元B輪融資，估值達到7.5億美元。東北證券預測，到2030年，全球向量數據庫市場規模有望達到500億美元，國內向量數據庫市場規模有望超600億人民幣。無論從技術演進還是資本市場來看，向量數據庫都是2023年度最亮眼的“年度之星”。AI和數據庫間的關聯比以往任何時候都要緊密和數據庫間的關聯比以往任何時候都要緊密 在大模型興起之前，傳統數據庫已經在不斷嘗試與AI結合，主要涉及以下幾個方向：AI for DB、DB for AI和預測估算。隨著大模型的興起，可以看到在這些方向上，數據庫與AI間

278、的關聯比以往任何時候都要密切。首先是AI for DB，即將人工智能（AI）應用于數據庫。AI技術可以嵌入到傳統數據庫中，使其具備更智能的功能。例如，通過AI大模型，數據庫可以實現更高級的數據分析、智能搜索和推薦等功能。AI技術的應用使得數據庫能夠更好地理解和處理數據，提供更精確的查詢結果和分析報告。其次是DB for AI，即數據庫為AI提供支持和服務。傳統數據庫可以為AI大模型提供結構化數據和非結構化數據高效的存儲和查詢能力。由于AI大模型通常需要處理大規模的數據，傳統數據庫的可伸縮性和性能變得尤為重要。數據庫可以通過融合查詢和差異化存儲等技術，提供快速的數據訪問和處理能力，滿足AI模型對

279、數據的高效需求。此外，AI大模型的興起還為數據庫注入了預測估算的能力。AI模型可以通過學習歷史數據和模式，對未來的趨勢和結果進行預測和估算。傳統數據庫可以集成AI模型，實現對數據的預測分析。這使得數據庫可以不僅提供對歷史數據的查詢和分析，還能夠提供對未來數據的預測和估算結果，幫助用戶做出更準確的決策?？偟膩碚f，幾乎所有類型的數據庫都在積極向AI靠攏，比如在數據庫中添加向量索引，數據庫和AI已經密不可分。此外，AI也迫切地需要從非結構化數據中創造價值。97 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 各種調查表明，大多數非結構化數據沒有被使用或分析來支持業務決策。企業可能缺乏大

280、規模分析計劃的資金，但他們也可能缺乏正確的方法來更好地利用他們存儲和收集的所有數據。由于存儲和分析PB級數據或數百萬個文件的成本很高，因此利用AI技術挖掘數據在經濟上的價值至關重要。但為了推動使用AI技術從非結構化數據中提取價值，組織內部需要有一個數據管理框架，使AI技術更值得信賴、更易于使用。它需要提供自動化的工作流程，在處理數據時能夠自動查找、排序、標記數據以及將數據移入或移出AI系統和其他位置。另一個問題是，如今任何組織內部可能沒有能夠為AI提供正確的非結構化數據的完整數據清單，這就要求我們要保留所有數據的可搜索索引，并且無論數據采用何種技術，都能夠訪問該數據，這對大多數組織而言是個不小

281、的考驗。一一體化是大勢所趨體化是大勢所趨 一體化逐漸成為數據庫的主流技術方向。目前，出現了單機分布式一體化、在離線一體化、多模態一體化。一體化技術使得數據庫具備更強的適應性，并且能極大地降低用戶使用和運維管理的復雜度。此外還能極大降低數據在不同系統之間流轉的成本，并提高實時性，使得數據價值展現效率大幅度提升。尤其在多模態技術方向上，通過對非結構數據向量化，也實現了多樣性的數據檢索管理能力。數據庫的一體化更加符合當前國內和國際上“降本增效”的大環境。通過整合不同的數據庫技術，實現一體化管理，可以大大提高數據處理效率。在傳統的數據庫系統中，數據分散在不同的數據庫中，需要進行多次的查詢和轉換，耗費大

282、量時間和資源。而通過數據庫技術一體化，可以實現對數據的統一管理和處理，減少冗余操作，提高數據處理效率。此外，在傳統的數據庫系統中，需要投入大量的人力和物力進行維護和管理，而通過數據庫技術一體化，可以實現自動化的數據管理和維護，減少人力和物力的投入，降低成本。從技術角度而言，實現數據庫技術一體化需要掌握多種數據庫技術的知識和技能，同時還需要解決不同數據庫技術之間的兼容性問題。這需要投入大量的人力和物力進行研發和技術攻關。從安全角度而言，組織需要保證數據的安全性和隱私性。這需要對數據進 98 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 行加密和備份等措施，確保數據的

283、安全性和完整性。此外，在應用層出不窮的當下，數據庫只有與應用結合，才能帶來業務上的價值。但目前應用的開發與維護卻越來越復雜，這主要是因為應用架構的復雜度往往取決于于數據庫能提供的能力。應用希望數據庫在保證穩定可靠、極高性能、性價比的同時，提供應用所需的所有數據存儲和處理需求。這樣一方面可以簡化應用架構，提升整個業務系統的可靠性和性能，另一方面保持應用的靈活度，以應對業務的快速變化。一體化數據庫，就是在幫助應用解決上述挑戰：多模能力（包括向量檢索）讓應用可以把結構化數據和非結構化數據統一處理；HTAP能力讓應用可以把交易數據實時用于分析決策；原生多租戶解決大量數據庫實例管理難題；而單機分布式一體

284、化是其他能力融合一體的架構前提。值得一提的是，目前市場上缺乏具備多種數據庫技術知識和技能的復合型人才，需要加強人才培養和引進工作，提高人才素質和能力。年年底最具爭議話題：向量數據庫是剛需還是風口？底最具爭議話題：向量數據庫是剛需還是風口？傳傳統數據庫全部引入向量檢索只是時間問題統數據庫全部引入向量檢索只是時間問題 正如我們所知，大模型擅長理解和生成類人文本，它們將文本轉換為高維向量（也稱為嵌入）來捕獲文本的語義。這種轉換使得對文本執行復雜的操作成為可能，例如查找相似的單詞、句子或文檔，這些是聊天機器人、推薦引擎等許多應用程序不可或缺的一部分。這些向量表示的性質需要一個有效的存儲解決方案來處理索

285、引和查詢嵌入。隨著大數據和人工智能的快速發展，越來越多的應用和場景需要處理和分析向量數據，向量數據不僅僅要提供向量的檢索能力還要提供向量和關系型數據庫的混合檢索能力。全面提升結構化數據、以及非結構化向量編碼后的索引和查詢優化，能夠提供更高效的數據檢索和分析能力，這就是向量數據庫的用武之地。向量數據庫本質上有三種形態：第一種是純單機向量數據庫，它不是分布式的；第二種是在傳統數據庫上加上一個具備向量檢索能力的插件；第三種是獨立的、專業的企業級向量數據庫。那么，現階段我們真正需要的是哪種形態？99 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 在采訪了業內多位數據庫領域專家后Info

286、Q發現，國內許多在做大模型的企業并沒有采用專門的向量數據庫，而是在原來傳統數據庫上增加了一項向量檢索能力，也就是上述提到的第二種形態。從表面上看，獨立的、專業的向量數據庫看起來并不是那么剛需，但事實的確如此嗎？這可以從傳統數據庫和向量數據庫的區別來看，兩者的主要區別在于它們的數據存儲方式、數據規模、查詢方式和計算密集型。數據存儲方式：傳統數據庫存儲的是結構化數據，而向量數據庫存儲的是向量數據，即將非結構化數據（如圖片、音頻、文章等）轉換為向量方式來存儲。數據規模：傳統關系型數據庫的管理數據規模通常為千萬級，而向量數據庫的需求數據規模則以達到千億級。查詢方式：傳統數據庫的查詢通常是精確查詢，即查

287、詢結果要么符合條件要么不符合條件。而向量數據庫則使用相似性查找，即查找與查詢條件最相似的結果，這需要更高的計算能力。計算密集型：傳統數據庫的查詢主要是事務處理，而向量數據庫的查詢則是計算密集型，需要進行大量的向量計算和比較?？偠灾?，向量數據庫的主要特點是能夠高效地存儲和查詢大規模的向量數據。它通常采用基于向量相似度的查詢方式，即根據向量之間的相似度來檢索數據。這種查詢方式可以用于各種應用場景，例如圖像搜索、音樂推薦、文本分類等。維度越高、信息量越大，這些特性都是傳統數據庫很難做到的。這種專門用于存儲、索引和查詢嵌入向量的數據庫系統，可以讓大模型更高效率地存儲和讀取知識庫，并且以更低的成本進行

288、finetune（模型微調），還將進一步在AI Native應用的演進中扮演重要作用。AI應用的興起，無論對于拓寬數據庫的使用場景，還是提高數據庫本身的使用效率都帶來了新的機遇。數據庫產品在調整身位，以更好幫助構建AI應用的同時，自身也在變得越來越智能，傳統數據庫和向量數據庫二者之間的邊界越來越模糊。100 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 在采訪中，多位技術專家認為，向量數據庫會弱化為數據庫索引特性，通過一體化能力與其他數據庫系統集成。造成這種現象的原因有以下幾點：向量數據庫的核心是向量索引，其與傳統的數據庫索引管理能力是同質的。向量數據庫之所以是數

289、據庫，其需要解決向量檢索需求之外，也需要處理數據安全、權限、數據修改、擴縮容等，這些能力本身就是數據庫的特長。從數據自身來說，現實的數據范圍往往是要多源的，而數據過于分散地存儲于不同的系統，顯著地增加了成本、降低了效率。因此，從技術和需求來看，傳統數據庫會快速具備向量特性，從目前的行業發展上，也印證了這個觀點，大部分的數據庫均已經或者宣布支持向量檢索。RAG技術能替代向量數據庫嗎？技術能替代向量數據庫嗎？關于向量數據庫是否是剛需這個問題，業內不只有正向的聲音。在今年首屆OpenAI開發者大會上，OpenAI就出人意料地給向量數據庫潑上了一瓢冷水。OpenAI表示將提供一款Retrieval檢索

290、工具，用戶已無需創建或搜索向量。OpenAI這一舉動對行業來講意味著什么？RAG和業內專用向量數據庫有什么區別？應用場景有什么不一樣？本質來講，RAG和業內專用向量數據庫在數據規模和普適性上還是有差別的。Retrieval提供了完整的端到端的工具，在小規模項目上可以快速應用落地。但對大數據規模場景下的數據管理能力缺失，也缺乏細致的調優手段。并且Retrieval會受限于AI廠商，而向量數據庫類是一個獨立的底層產品，不會與某一個AI產品所綁定，可以同時適配多種AI引擎。與此同時，新技術的出現并不意味著舊技術就會立即被淘汰。向量數據庫和RAG技術各有其優勢和適用場景，時間會證明它們在不同應用場景下

291、的價值和效能。RAG、向量數據庫和中間件都可以視為AI工具箱中的重要工具，各有其適用的范圍和應用場景，而非互相替代的關系。一個真正強大的AI技術棧應該是多種工具和技術的集成，使得我們能夠根據具體需求選擇最適配的工具使用。此外，RAG技術是相對較新的，盡管在理論和實驗環境中表現出色，但在實際應用中可 101 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 能還面臨著一些挑戰，如數據集的質量、系統的可擴展性和可靠性等。已有一些公司和組織開始探索使用RAG技術，特別是在需要結合大量信息和生成響應的場景中，例如知識庫、智能對話等場景。綜合來講，RAG最主要的優勢是在生成文本或從大型文本數

292、據庫中提取信息時能夠提高效率和效果。它集成了信息檢索和機器學習生成模型的優勢，可以在生成文本的同時考慮其他大量文本信息。這使得RAG在前提推理、知識引用、解釋生成以及過濾離題信息等方面具有強大的能力。另一個優勢是RAG更直觀、易于使用，對于無需深入理解復雜機器學習算法背后原理的大眾用戶來說，RAG是一個理想選擇。而向量數據庫專注于向量數據的高效存儲和檢索，適用于大規模向量數據的管理和處理，對于相似性搜索、聚類等任務有著獨特優勢。RAG主要應用于自然語言處理領域，若處理其他類型的數據，如圖像和音頻等，其性能可能會變差。雖然RAG已經在很多應用領域表現出色，但它依然需要訓練數據，因此，深度和廣度的

293、知識獲取仍然受限于訓練數據。RAG最能解決的是自然語言處理中的問題，特別是需要理解和生成文本的問題，例如智能聊天機器人、自動問答系統以及文本摘要生成等，但對于音頻、視頻或其他非文本類數據處理的效果不如專門的向量數據庫。專專門去研發一款向量數據庫，有必要門去研發一款向量數據庫，有必要嗎嗎 最近一年里，向量數據庫技術以勢不可擋之姿迅猛發展，但想要研發一款向量數據庫產品依然面臨著諸多挑戰。首先要解決的挑戰是擴展性。隨著AIGC等應用的發展，特別是大模型的興起，對嵌入（embedding）和向量化這些能力的需求急劇增加。大模型的普及也讓向量數據的規模不斷增大，從百萬級別的數據體量已經變為千萬級別，甚至

294、更大。這就需要數據庫能夠有效地支持大規模向量數據的存儲和檢索，這對硬件資源提出了更高的要求，特別是在云上部署時成本可能成為一個重要問題。第二個挑戰是成本問題。在向量搜索中，索引的大小和存儲是關鍵因素，而向量索引的成本通常較高。以前在數據量較小的情況下，可能只需要幾臺機器就足夠了，成本并不是關鍵問題。但隨著數據規模的增大，需要更多的資源來支持，這就涉及到成本的考慮。102 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 第三個挑戰是易用性問題。與傳統的關系型數據庫不同，向量搜索涉及到更多維度的考量，包括性能和召回率等。為了平衡性能和召回率，需要調整各種參數，但這可能對

295、用戶來說不太友好。因此，簡化參數選擇，優化用戶體驗是一個重要的挑戰。最后一個挑戰是混合搜索中的路徑優化問題。與傳統的優化器相比，向量搜索的優化器更加復雜，因為它需要考慮多維度的因素。如何設計一個能夠描述向量搜索代價的模型，以實現性能和召回率的平衡，是一個需要解決的難題?？梢?，研發一款向量數據庫并不輕松，而對于那些對向量數據庫有需求的企業來講，從外購買一款成熟的向量數據庫產品遠比自己研發要省時省力。2024年數據庫發展趨勢展望年數據庫發展趨勢展望 向向量數據庫技術將打磨得更成熟量數據庫技術將打磨得更成熟 對于向量數據庫領域，要實現深度學習技術的最優應用，需要具備AI、數據庫和安全等多方面的能力。

296、數據庫內通常會儲存一些敏感數據，因此如何保證這些數據的安全性將成為一個極其重要的議題。尤其是隨著向量數據庫等領域逐漸引入深度學習技術，對AI能力和數據安全的需求將變得愈發迫切。在大模型企業層出不窮的當下，對于向量數據庫的需求成為了倒逼向量數據庫技術逐步完善的強烈的驅動力，這種驅動力能夠快速淘汰那些不合適的技術，同時也會促使新技術的不斷涌現，這是一個逐步篩選的過程。從長遠來看，向量數據庫將不斷成熟，同時也會為不同的應用場景提供更加精準的向量搜索結果。國國內外數據庫產品的差距進一步縮小內外數據庫產品的差距進一步縮小 2023年，全球主流數據庫在產業、軟硬件和人才生態方面繼續快速增長，但市場競爭也日

297、益激烈。國產數據庫在產品和技術上與國外頂尖產品仍存在一定差距，但差距正在迅速縮小。不少國產數據庫廠商在海外取得了一定的成果。比如人大金倉近年來積極拓展海外市場，已與多家海外企業合作，實現了在東南亞、歐洲等地區的成功部署和應用。另外，阿里云的分析型數據庫AnalyticDB、華為的 103 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 openGauss數據庫、酷克數據的HashData云數倉也在國際市場上取得了一定的進展。這些案例表明，國產數據庫產品在技術和市場上已經具備了與國際領先產品相媲美的能力。國產數據庫逐漸取代海外老牌數據庫不僅僅是國產化訴求，也是自身技術實力使然。整整

298、個數據庫市場將正向地“卷”個數據庫市場將正向地“卷”無論是傳統數據庫還是向量數據庫，隨著全社會數字化轉型進入深水區且大模型不斷涌現，未來整個數據庫市場的持續擴張是不可避免的，這主要是因為技術的迭代速度非?？?，同時技術門檻也在逐漸降低。當前兩個市場都存在著大量的需求，這將吸引越來越多的數據庫廠商加入競爭。然而，從業界角度看，這種市場擴張對于行業發展有積極的一面。它為用戶提供了更多的產品選項，也不斷促使數據庫廠商迭代研發新的技術與產品，從而在競爭中篩選出更優秀的技術和解決方案，以更好地滿足用戶需求?？梢钥隙ǖ氖?，所有數據庫采用者都希望這個行業有更多競爭者涌進來，同時也期待看到哪些技術能夠經受住應用

299、的考驗，證明自己在實踐中的可行性，從這個角度來講，這種市場擴張應當是良性的。隨著技術的成熟，貶損競爭對手、抹黑事實、哄搶客戶等惡性競爭行為將越來越少，良性競爭越來越多，這樣才能推動整個領域的進步。采訪嘉賓（按姓名首字母排序）采訪嘉賓（按姓名首字母排序）Fabarta技術團隊 胡宗星胡宗星，九章云極DataCanvas高級產品總監 簡麗榮簡麗榮，北京酷克數據科技有限公司聯合創始人兼CEO 李潔李潔，北京阿哇科技的創始人 楊志豐（竹翁）楊志豐（竹翁），OceanBase產品總經理&首席架構師 104 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 金融業采用大模型，是“

300、用大炮轟蚊子”嗎？金融業采用大模型，是“用大炮轟蚊子”嗎？作者：高玉嫻 本文是“2023 InfoQ年度技術盤點與展望”系列文章之一，由InfoQ編輯部制作呈現。今天，無人不談大模型。根據麥肯錫2023年年AI現狀：生成式現狀：生成式AI的爆發之年的爆發之年報告顯示，60%的組織機構正在使用生成式AI工具。而IDC日前發布的2023-2024年中國人工智能計算力發展評估報告年中國人工智能計算力發展評估報告中也有相似數據，67%的中國企業已經開始探索生成式的中國企業已經開始探索生成式AI在企業內的應用機會或進行相在企業內的應用機會或進行相關資金投入。關資金投入。金融行業是受影響最大的行業之一金融

301、行業是受影響最大的行業之一。知識密集、場景豐富、數據和技術基礎好、資源相對充足這些得天獨厚的條件為大模型在金融行業的落地應用培育了溫熱土壤。105 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 那么經過過去一年的探索與實踐，金融行業是否找到了大模型落地應用的最佳路徑？取得了哪些具體應用成果？又存在哪些難以逾越的挑戰與桎梏？本文是“2023 InfoQ年度年度盤點與展望盤點與展望”系列文章之一”系列文章之一，通過與金融領域各行業專家的交流，希望進一步明晰金融機構在大模型這一趨勢下的實踐思路和路徑。金金融大模型“搶灘”之戰融大模型“搶灘”之戰 放眼全球，摩根士丹利作為首家正式接入G

302、PT-4的金融機構，已經把相關技術應用到了投資策略分析領域；高盛更進一步，已經使用大語言模型輔助風險管理分析。聚焦國內，當前我國金融領域發布的大模型已經超過20個，并且數量還在不斷增加；在42家上市銀行中，也有9家銀行在2023年的半年報中明確提及正在探索大模型應用。比如工商銀行在年中財報中提及，已經完成人工智能AI大模型能力建設應用規劃，實現百億級基礎大模型在知識運營助手、金融市場投研助手等場景的應用。舉例來說，工商銀行將大模型應用到了客服全流程：在事前智能客服知識運營階段，利用大模型自動完成數據標注與知識維護，幫助提升傳統智能客服分流質效；在事中服務客戶階段，利用大模型打造前情摘要功能、知

303、識隨行功能、工單智能填寫功能，從而提升坐席運營效率，壓降通話時間；在事后質量檢查階段，生成傳統質檢AI模型數據，即模擬坐席及客戶問答，提升傳統質檢模型準確率。建設銀行旗下金融科技公司建信金科，實行的是更為全局化和體系化的大模型布局。具體而言，從通用能力、安全合規、金融需求三方面為出發點，設計了金融行業的大模型能力體系。該能力體系設定了7大一級能力和23項二級能力，用于幫助建信金科實現模型能力評估與生成式AI場景應用。此外，基于大模型的能力矩陣，建信金科還將金融大模型的表現評估細分為通用能力和金融領域能力。其中，通用能力主要考評金融大模型在信息總結、信息推斷、文本轉換、信息擴展、安全與價值觀、復

304、雜推理六個維度的能力；金融領域能力評估主要考評金融金融領域能力評估主要考評金融大模型在金融領域的任務處理能力大模型在金融領域的任務處理能力，即銀行業務基礎、保險業務基礎、證券業務基礎、信托業務基礎、基金業務基礎。從業務特性來看，保險能從大模型上借的力甚至可能比銀行更大，且速度更快。因為保 106 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 險產品和理賠流程的復雜度相當高，涉及大量的人與人溝通，并且整個過程非常依賴個人的溝通技巧。通過大模型的引入，對人效的提升和成本的節約效果更為明顯。平安人壽科技總監魏政剛告訴InfoQ，其內部在探討技術與業務應用結合點時主要聚焦

305、行業價值鏈，關注從營銷、銷售、新業務、核保到理賠的五大環節。比如，平安人壽推出平安人壽推出了基于大模型的數字人產品，主要用于協助代理人與客戶溝通。了基于大模型的數字人產品，主要用于協助代理人與客戶溝通。這對初入行業的代理人提供了極大幫助，可以指導他們與客戶交流、更好地理解客戶的需求、痛點及潛在風險，并設計有針對性的解決方案?！爱斎?，我們對大模型的探討會以應用為主，不會從縱向上扎到算法層面?！庇邢⒎Q，平安集團層面正在研發上千億參數的模型?？雌饋砑瘓F旗下類似平安人壽等機構將會基于集團的統一部署，直接采用其底層的模型能力。除了實力雄厚的傳統金融機構之外，新興金融科技公司同樣不會錯過這場金融大模型“

306、搶灘”之戰。2023年5月，度小滿率先推出國內首個開源的千億級中文金融大模型“軒轅”；8月，馬上消費發布首個零售金融大模型“天鏡”；9月，螞蟻集團AntFinGLM亮相?！拔浵伡瘓F的大模型策略分為三層：第一，訓練自己的金融大模型，配套推出評估集；第一，訓練自己的金融大模型，配套推出評估集；第二，推出金融智能體框架；第三，基于大模型和框架搭建產業應用（如面向第二，推出金融智能體框架；第三，基于大模型和框架搭建產業應用（如面向C端的支端的支小寶和面向小寶和面向B端的支小助），實現服務增強?！倍说闹≈?，實現服務增強?！蔽浵伡瘓F資深技術專家徐萬青表示?？偨Y下來，金融機構金融機構布局大模型主要是以下

307、三種方式布局大模型主要是以下三種方式：AI技術基礎好的企業投入自研行業大模型；資源、數據、場景基礎較好的企業引入通用大模型上，在此基礎上做微調，然后輸出給內部或同行；而更多中小企業最終會選擇直接調用大模型接口，落地一些相對成熟的大模型技術和應用。機機器學習時代的故事重演？大模型落地應用面臨器學習時代的故事重演？大模型落地應用面臨4大挑戰大挑戰“金融大模型要往縱向卷，不要再向水平卷，我們不需要那么多大模型，而要真正深入核心，解決金融業務的問題?！蔽赫傔@樣強調。然而，值得關注的是，現在的很多“智能化故事”，在機器學習時代已經講了一遍。107 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技

308、術百態 從應用角度看大模型，目前仍然主要集中在辦公、開發、營銷、客服等非核心業務場景辦公、開發、營銷、客服等非核心業務場景，對于投研、交易、風控等核心業務，多數金融機構的相關動作仍然相對保守。例如，即便是對大模型全局化投入的建信金科，目前在場景落地應用方面也是以對內為主、對外為輔。這與金融行業強監管的特殊屬性不無關系，而這種行業特性也在一定程度上制約了大模型在金融業的規?；瘧眠M程。從IDC中國人工智能行業滲透度排名來看，過去5年一直位列前三的金融行業，2023年已經被電信和政府反超，僅排名第四。這與最初業界的預判似乎有一定出入。太平金科保險科技實驗室副總經理葉俊鋒表示：在機器學習和深度學習的

309、人工智能時代，太平實際上做了大量的實踐并產生了成效，OCR、RPA、NLP等技術都得到了廣泛的應用，在NLP領域的場景包括客聯場景下的外呼機器人，面向內部的知識庫問答系統太平百科等等。面對大模型時代，我們在思想上積極擁抱，在場景上業不斷探索，但是投入時還是要考慮產出。太平針對大模型制定了一份內部研究報告，對于大模型應用場景和存在的風險進行了詳細的分析，并提出了分步推進的規劃的建議，目前開展了一些面向內部探索和試用，但在推動應用，尤其是面向客戶應用時還是很謹慎的?！笨梢?，那些在傳統AI應用方面已經有不錯基礎的企業和行業，對大模型的接納度和響應度也不一定要更好。令金融機構既充滿期待又望而生畏的因素

310、有很多，總結下來主要包括幾點：第一，大模型的可解釋性和穩定性不足；第二，數據的質量、規模和安全問題；第一，大模型的可解釋性和穩定性不足；第二，數據的質量、規模和安全問題；第三，算力焦慮；第四，人才缺失。第三，算力焦慮；第四，人才缺失?？煽山忉屝赃@道題如何解？解釋性這道題如何解？金融是經濟的“壓艙石”，其穩定性關乎民生，所以行業監管高要求是一道底線。這也是大模型的“黑盒”特性注定在其核心業務場景走不通的重要原因。以銀行最關鍵的風控場景為例，當某筆申請貸款審批通過或被拒絕，確定了某個貸款額度，背后的原因要能夠解釋，比如申請人的收入狀況、違約記錄等等，這些都是依據。但是，大模型在面對千億級的參數或特

311、征時，背后是沒有對這些風險特征進行定義的，其中間恰恰缺少了一層可解釋性。108 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 “在大模型興起之前，我們說服銀行內部使用AI模型進行審批貸款，就花了足足三年時間。大模型來了之后，一切又要從頭開始?！蹦炽y行機構技術負責人向InfoQ感嘆道。有業內人士舉了另一個例子：過去某國有銀行使用基于小模型的金融交易對話機器人進行銀行間的債務訂單意向確定，內部采納率已經高達99%以上。但是，在嘗試采用大模型做替代的過程中，他們發現機器人的回答變得特別發散，無法聚焦到具體的交易意向，最終導致效果極差無法替換。不過話說回來，在InfoQ與

312、多位業內從業人員交流的過程中發現，大家絕大多數都相信，大模型進入金融核心場景，也只是時間問題。光大信托信息技術部副總經理、數據中心總經理祝世虎博士針對可解釋性問題，提出了一種目前可行的解決思路：把大模型放在中央，小模型放在外圍，大模型驅動具有可解把大模型放在中央，小模型放在外圍，大模型驅動具有可解釋性的小模型去處理問題釋性的小模型去處理問題，進而解決可解釋性的難題。數數據是“背鍋俠”？據是“背鍋俠”？大模型本身只是一張“白紙”，上面會長出什么樣的一幅“畫”，由數據決定。對企業來說，首先是要“有數據”，其次要“有足夠的數據”，再者“數據質量要足夠高”。魏政剛指出，語料是制約金融業落地大模型的關鍵

313、桎梏?！耙环矫?，金融業務復雜性特一方面，金融業務復雜性特別高別高，很多業務知識和經驗實際上是在人腦里而不是在系統里，如何把這些信息從業務人員大腦里剝離出來是個非常大的挑戰；另一方面，監管制度不斷調整另一方面，監管制度不斷調整，這會頻繁對金融機構業務經營活動產生影響，數據會實時變化，這就對AI落地的工程性能力提出了非常高的要求?！敝嘘P村科金技術副總裁&TGO鯤鵬會學員張杰博士向InfoQ進一步介紹，數據問題中容易解決的是預訓練數據部分，但指令數據部分是比較難的，對數據質量要求更高。因為大模型時代仍然面臨一個法則好用的不通用，通用的不好用?！霸诰唧w場景下，如果想要把準確度調整到95，難度還是非常大

314、的，可能需要專門的指令對數據進行微調。對此，一方面企業需要有自己的場景來逐漸積累；另一方面，可 109 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 能需要考慮通過行業聯盟，共享數據?！币燥L控場景為例，上海華瑞銀行風控數據團隊負責人丁清華表示，目前某個金融機構自身說掌握的數據是特別有限的，可能是某一部分人群的數據特征，或者某個地域人群的數據特征。行業里還沒有任何一家機構可以掌握能夠達到如此龐大規模和覆蓋面的風險特征數據（比如全國所有個人的基本信息、違約記錄、消費習慣、交易流水等等），絕大部分全國性數據主要還是在政府機構、監管機構（人行、銀保監會等）部門?！八?，如果要實現風控領

315、域的大模型落地，我認為還是需要自上而下去推進?；谀硞€領域大模型，各個金融機構再按照自身的客群定位進行參數的微調?！倍∏迦A指出。然而，在祝世虎博士看來，“數據質量”問題可能只是一個“背鍋俠”?！笆聦嵣?，一是不存在沒有質量問題的完美數據；二是數據質量的提升，數據治理只是一方面；三是頂層的數據應用決定底層的數據質量。數據只有用起來，質量才會越來越高數據只有用起來，質量才會越來越高，只有形成閉環，數據才能治理好”。祝世虎博士表示，“大模型一方面需要高質量的數據，另一方面也從應用的角度推進了數據質量，并且在機器學習的樣本標注中大模型已經有了很好的落地實踐?！毕懔箲]必須從信創上下功夫除算力焦慮必

316、須從信創上下功夫 算力是一個基礎設施問題，更是一個成本問題。大模型意味著大算力，但“骨感”的現實是，我國市場面臨著嚴重的算力供給短缺。雖然有機構趕在限購之前囤了不少卡，但根本的自研能力一天不能補齊，“卡脖子”問題就會一直出現。因此，要從根本上消解算力焦慮，必須從信創上下功夫?？梢钥吹?，在國家層面，近期工業和信息化部聯合發布了關于算力技術的設置和高質量發展的指導意見，推進中國算力發展一個新時期；在市場層面，我國AI芯片行業近年來也在持續發展。比如，以海光信息為代表的開放路線，此前的深算一號已經具備大模型運行能力。但是，它的算力只相當于英偉達P100的水平。雖然海光在第三季度很快推出了深算二號，據

317、介紹已經具有全精度浮點數據和各種常見整型數據計算能力，性能在深算一號基礎上翻了 110 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 一番。不過，如果和英偉達產品相比，也仍然有很大差距。再比如，華為昇騰，被視為業界算力最強的AI處理器。但其走的是自生態路線，也就是說，它只適用于自身生態中的大模型業務。與此同時，算力部署不是一個單一問題，對于金融機構而言，還要考慮異構算力的融合、機房和網絡等其它基礎設施的統一建設等等。用建信金科基礎技術中心人工智能工程部總經理劉東東的話說這是一個短板效應比較明顯的系統工程這是一個短板效應比較明顯的系統工程?！耙簿褪钦f，如果算力要好，

318、那么網絡、存儲、機架密度所有的相關配置都要與之匹配，這樣才能把算力價值發揮出來，但這背后不但涉及的成本巨大，并且在落地中也非常復雜且具有挑戰。所以，算力問題可以一分為二來考慮。對于實力雄厚或者希望自建大模型的大型金融機構來說，有錢可以“任性”；但是，如果資源有限，那不妨考有錢可以“任性”；但是，如果資源有限，那不妨考慮“借力”慮“借力”。每個金融機構自己去建算力中心、自研大模型顯然并不明智，因此越來越多的企業開始采用混合部署方式。也就是說，從公有云調用大模型接口，然后采用私有化部署方式處理本地數據服務。一方面確保隱私敏感數據留在安全域，另一方面也可以節約大量的算力成本。供供需失衡，人才短缺問題

319、不斷疊加需失衡，人才短缺問題不斷疊加 無一例外，所有的技術革新都會帶來社會人才結構的改變。比如前不久大數據分析師還是企業的“香餑餑”，眼下卻成了一個“危機職業”。技術更迭之快“漸欲迷人眼”，行業的人才缺口卻越來越凸顯。那么，大模型時代下，企業究竟需要什么人才？張杰博士認為，大模型于金融機構而言關鍵在于場景落地，而具體場景對模型調校的經驗要求較高，不僅需要算法能力，還需要考慮如何實現算法工程化，結合具體業務進行落地。因此，需要既懂算法、又懂工程、產品和業務等知識的六邊形人才。由此來看，人才短缺問題是不斷在疊加的。企業在數字化轉型過程中所需的業務和技術復合型人才還未能補齊，企業對人才能力需求的邊界

320、卻還在不斷延展?！拔覈鴤鹘yIT人員做的多是交付式開發，這導致大家的產品設計能力和深度建模能力天產品設計能力和深度建模能力天然缺失然缺失。而反觀業務人員，同樣在邏輯思維、技術思維方面有所欠缺邏輯思維、技術思維方面有所欠缺?！蔽赫偙硎?，111 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 為了彌合二者之間的鴻溝，平安人壽采取了一系列手段。比如，把IT前置到業務部門，讓技術更深入地參與到業務中去；再比如，通過輪崗制度，讓業務和技術交叉學習。當然，在有限資源的前提下，人才培養也要有優先級。太保壽險首席架構師周建華表示，雖然算法人才必不可少，但在大模型的基建方面，由于門檻高、成本大、問

321、題復雜，金融行業自己可能并不需要過多涉足，更重要的是考慮大模型應用。在這方面，兩類人才至關重要：一類是智能化戰略規劃人才，他們能夠通過對其他領域的成功案例中的借鑒，對企業自身的戰略規劃做出部署；另一類是智能化應用人才，他們不需要成為頂尖的算法專家，需要的是智能化應用實戰能力。金金融融+大模型，可以但沒必要？大模型，可以但沒必要？面對這一系列嚴峻的挑戰，技術本身反倒成了最簡單的問題?！坝没蛘卟挥谩?、“如何用”才是現階段企業最關心的。有人發出這樣的“靈魂拷問”模型是不是越大越好？如果小模型就能解決的問題，是否還有必要使用大模型？“這本質上是一個經濟性問題?！比~俊鋒舉例，在大模型應用的成本中，有一項

322、特別容易被忽視但占比并不小的投入電費?！八?，當我們站在經濟性角度去考慮這個問題的時候，就不難得出這樣的結論，如果原有技術已經能夠符合業務預期，投產比更優，那就不要急著用大模型去替代。大模型能夠切實發揮作用，一定是因為基于大模型產生了新的業務模式，帶來新的業務收益，而非僅僅用大模型替代現有小模型?！弊Ｊ阑⒉┦窟M一步介紹，企業“用或者不用”大模型可以從以下兩個方面做考慮：第一，投入產出比。第一，投入產出比。雖然如今的大模型被標榜能夠降本增效，但效益的產生是依托于一定程度的規?；瘧玫?。有業內人士向InfoQ透露，他們內部曾經做過一個實驗，讓人和GPT4分別對一篇文章做總結，最終的結果是，GPT4

323、的投入成本要高得多。對此，張杰博士強調，金融機構在立項時要“算好賬”，設置好中間的業績指標、過程 112 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 指標等等。其中，過程指標的設置相對簡單，以文檔問答為例，主要看大模型對PDF文檔或圖片解析的準確度，以及解析完成后大模型問答的準確率，這些都可以用一些技術指標來衡量。而衡量業績指標最簡單的方法是與人工進行比較。例如與人工坐席或與后臺職能部門的人員效率進行比較，或者與軟硬件成本以及人員成本比較?！爱斎?，不同企業對投入產出比的衡量指標不太一樣。有的企業把大模型視為戰略性投入，所以試錯容忍度更高。有的企業則不一樣，他們會

324、非常關注周期，如短期、中期、長期等不同階段的成果。具體來說，可以先找到一個具體場景，設定一個破冰期（通常是半年左右的時間），讓公司內部人員看到大模型在降本增效方面的價值，然后再進一步推廣落地?！钡诙?，模型的效果表現。第二，模型的效果表現。目前大模型的應用落腳點主要還只是輔助人，而不是完全替代人；效率提升的同時，也許還會增加人的工作量?！皩Υ?，我們可以從幾個方面來評估為什么要用大模型替代小模型：一是同行在用，企業為了保持競爭力必須采納；二是需要解決小模型解決不了，而大模型可以解決的問題，比如效能；三是解決雖然小模型能做，但大模型表現更好的問題，比如一崗多能；四是把大模型視為新的生產力，雖然弓箭也

325、是武器，但和現代武器相比差距巨大?！弊Ｊ阑⒉┦恐赋?。在他看來，基于以上，資金實力比較雄厚的大公司會更多考慮效果問題，而中小型企業則更多考慮成本投入。在中短期內，大模型和小模型將會共存。那么，在具體落地過程中，大小模型如何有機搭配？徐萬青這樣比喻：大模型更像是一個文科生，小模型更像是一個理科生，在協同的過程中，可以把大模型作為認知與語言交互的中樞，把各類小模型當作各個領域和場景的專家，然后進行協調調用。當然，這個問題沒有標準答案。找到可結合的業務場景，從中進行突破，這可能比搞大 113 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 模型本身更重要?！霸谶^去的智能化應用中，很多公司

326、都因為未能找到業務流程上的痛點，導致創新停滯。解決這個問題并不容易，技術應用必須回到目標和業務價值，生產力的提升如何帶來生產關系的改變?！敝芙ㄈA表示。熱熱思考，冷啟動思考，冷啟動 所以，金融行業廣泛采用大模型是“用大炮轟蚊子”嗎？目前行業普遍共識是并不?！翱傮w上，技術投入與其帶來的收益是值得的。這不僅是基于我們的增長預期，也基于我們對技術，尤其是人工智能和大語言模型，能夠真正為業務賦能的信心。平安人壽的改革成果也印證了這一點，從中我們可以看到生產力和收入水平的提升?！蔽赫偙硎?。然而，如何精確計算這種技術投入與業務收益之間的平衡點仍然是個挑戰?！安豢煞裾J，企業必須積極擁抱大模型。但是，從投入角

327、度來看，我認為還是應該謹慎投入，不要腦子發熱，先小成本地去體驗和探索?！比~俊鋒認為，企業在這個過程中要做好兩個平衡：第一，平衡好短期利益和長期利益；第二，平衡好降本增效和創新?？梢婋m然大模型還沒有從根本上改變人們的生活，顛覆式的爆款應用還沒有出現。但沒有人會質疑，它將成為技術發展史上不亞于蒸汽機的偉大創新。那么，在那個“偉大時刻”到來之前，企業應該如何做好迎接它的準備？徐萬青強調，除了技術能力、數據基礎、人才儲備之外，思維的轉變也必不可少?！熬拖裎覀冊谝苿訒r代來臨時，如果只是想著把電腦上的功能和軟件照搬到手機上，那必定不會成功。在大模型時代，更要以智能原生的視角重新審視金融業務的運轉，所有金融

328、場景都值得被大模型重塑一遍?！?14 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 大模型時代，我們可以用大模型時代，我們可以用JuliaJulia做什么？做什么？作者：田俊 策劃：蔡芳芳 從ChatGPT發布以來，大家對大模型相關生態的關注急劇上升，本人也在過去的一段時間里深度參與了大模型相關的一些基礎工作。眾所周知，目前圍繞大模型相關的開發仍然以Python編程語言為主，作為一個Julia編程語言愛好者，我一直在思考的一個問題是，大模型時代我們可以用Julia做什么？本文是“2023 InfoQ年度技術盤點與展望”系列文章之一，筆者將結合自己在大模型領域的開發

329、經驗和對Julia生態的理解，嘗試從兩個不同的角度來回答上述問題。首先，我們將大模型研發的過程拆解開來，逐點分析目前已有的做法和面臨的挑戰，探討Julia在該方向上落地的潛在可能性；然后縱覽Julia以及一些其它編程語言中大模型相關開發的生態，試圖找出一條更適合Julia編程語言的發展道路。115 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 訓訓練基座模型練基座模型 基座模型的訓練所面臨的挑戰在于，超大規模的參數量。目前主流開源的模型參數量都在數十億、數百億乃至數千億的規模。想要高效地訓練如此大參數量的模型并非易事，目前開源界主流的訓練框架是+Megatron-LM+，在其之

330、上還有一些其它工具庫提供開箱即用的訓練腳本。Megatron的核心功能主要包括：Tensor Parallel（TP）、Data Parallel（DP）、Pipeline Parallel（PP）等。TensorParallel要解決的核心問題是，如何在單卡無法放入整個Tensor的情況下，高效地做Tensor之間的計算。來源：https:/colossalai.org/docs/concepts/paradigms_of_parallelism/#tensor-parallel 以矩陣相乘（A x B）為例，目前已有的做法是，將其中一個矩陣B拆分到不同的GPU卡上，然后執行分塊矩陣的計算，

331、最后合并計算結果。116 20232023年度技術盤點與展望年度技術盤點與展望|架構師特刊架構師特刊 在Julia語言中，類似的需求可以通過DistributedArrays.jl來實現，其封裝好了一個DArray類型的結構，底層不同worker可以獨立并行地做計算。julia using DistributedArrays A=rand(1:100,(100,100)DA=distribute(A,procs=1,2,dist=1,2)不過遺憾的是，該軟件包并不支持GPU上的操作。在Python這邊，GPU上的通信操作通常依賴于NCCL的實現，首先需要執行類似broadcast的操作將A矩陣

332、分配到各個節點上，完成計算后執行all-gather的操作將計算結果同步到每個節點。盡管目前在CUDA.jl的文檔中有提到，如果想要實現單機多卡或者多級多卡之間的通信，可以借助一些基于GPU的MPI的實現，但目前仍缺少一些相關的實踐。此外，另外一條可行的路徑是，借助Ygg-drasial中封裝的NCCL library，直接做多機多卡之間的通信，不論是基于Distributed.jl來實現還是獨立再封裝，具體實現上仍有不少工作，理想情況下，該工具庫可以提供類似torch.Distributed的功能。DP的核心是將多份數據同時應用到模型的多個副本上，從而提升訓練期間模型的吞吐量，縮短訓練周期。

333、該過程最核心的挑戰在于降低同步多個副本之間參數的通信量。在Megatron中，有一系列工作來優化該步驟，其中最核心的一個組件是DistributedOpti-mizer。簡單來講，將Optimizer本身的參數，以及模型本身的參數和梯度等切分到不同的節點，117 AIGCAIGC熱潮下的行業與技術百態熱潮下的行業與技術百態 再按需進行同步，可以大大降低模型優化過程中的通信成本。實現該優化器本身的難度并不大，但其前置條件（高效易用的NCCL實現）卻是最大的障礙點。值得一提的是，近來在Flux.jl之外，又多了一個Lux.jl選擇，相比之下，其宣稱的最大不同點在于“顯式參數化”，在分布式優化場景下，這種特性具有其特殊的現實意義，即將參數展開之后，可以很容易地實現分片操作以及多機多卡之間的高效通信。Fused Kernel 此外，在預訓練（以及推理階段），常見的一個優化手段是將幾個算子做聚合，降