2023 云棲大會在杭州如期舉行，前身是阿里云開發(fā)者大會，作為阿里的主場，國內公有云計算份額最大廠商，今年的主題是：計算，為了無法計算的價值。大會主場兩大主題:大模型和云計算。大模型的火熱和未來可預見的應用場景充分了引起了大家的重視，上午場以人工智能在阿里云的發(fā)展為主，同時闡述了云計算為人工智能算力提供了堅實的支持。下午場，云產品線負責人各自從容器、存儲、網絡、數(shù)據(jù)庫、Severless、大數(shù)據(jù)這幾個主題介紹了這一年開發(fā)和提升的成果。作為一個大數(shù)據(jù)從業(yè)者，在公有云和容器化發(fā)展的大趨勢下，我們關注的重點已經不僅僅是大模型，大數(shù)據(jù)在未來幾年發(fā)展的重點方向是什么，大數(shù)據(jù)的技術演進路線會如何。

一、從技術主論壇上看云技術的主要進展

云棲大會上午場，阿里云創(chuàng)始人王堅做了一場演說，說到了云計算的第三次浪潮的到來。同時，闡述了自己對云計算第一次浪潮的理解，并用 Netflix 和米哈游兩家企業(yè)的案例來表達對云計算浪潮到來所帶來的效益。第二次浪潮以傳動企業(yè)上云，比如銀行上云為代表。第三次浪潮的標志事件是北京冬奧會核心系統(tǒng)上云。未來，企業(yè)上云是大部分的首選，公有云擁有的規(guī)模化和云計算的人才是根本原因。這點如同傳統(tǒng)分散的手工作坊向集中式規(guī)模化的大型工廠演進。我們來具體看看，下午場的技術主論壇，在技術干貨或者核心產品上都有哪些提升，在大數(shù)據(jù)領域會有哪些影響。下面我會將主要產品技術演講進行摘要。

彈性計算/容器方面：核心點在于擁抱云原生，發(fā)布了基于 CIPU+ 飛天操作系統(tǒng)構建第三階段彈性計算。ECS 的計算從支持 Intel 到自研的倚天 710 和 AMD 芯片，各款芯片的主打方向不同。同時，對不同的 ECS 實例，做了針對價格的細分。經濟型實例主打學生、中小企業(yè)開發(fā)者、測試環(huán)境。HPC 實例、高性能高穩(wěn)定實例，主打一些特殊要求行業(yè)。介紹了 ECI 容器能力，舉例某頭部公司，基于 ECI 容器的能力，構建自己的彈性大數(shù)據(jù)系統(tǒng)，感覺很意外的，日累計可以創(chuàng)建 200W 個 ECI 的實例。

存儲方面：重點是阿里云的對象存儲 OSS，也是大數(shù)據(jù)領域如果上云使用的基礎服務。提供 OSS 的標準、低頻、歸檔三種存儲類型和歸檔直讀。提升 OSS 帶寬到 100Gbps，舉例 270GB 的模型，大約 20 秒讀完。OSS 的協(xié)議兼容支持，OSS-Posix 本地文件，OSS-HDFS 兼容 Hadoop 協(xié)議。

網絡方面：阿里的飛天洛神云網絡，提升了高性能網絡接入和轉發(fā)，主要是軟硬協(xié)同、互補。云原生對網絡的挑戰(zhàn)，以前的網絡是為虛擬機提供的，現(xiàn)在要為容器 Pod 提供，兩者的數(shù)量級不同帶來的挑戰(zhàn)。一是容器對網卡的創(chuàng)建速度要求高，從原來的幾百的彈性提升到幾千，二是基于 K8s 的無縫融合，優(yōu)化了各種網絡層查表和內存管理。介紹了主動重路由技術，來解決多區(qū)域網絡突然閃斷問題，以及模型訓練對大網絡帶寬的需求。

托管的K8s：主要闡述了一些使用數(shù)據(jù)，64% 用戶生產環(huán)境使用 K8s，云上 K8s 增速達到 127%。云托管的 K8s 超過本地部署，占比 73% 等。將托管的 K8s 集群產品定價重新規(guī)劃了一下。

數(shù)據(jù)庫方面：介紹了瑤池 Rds、Polardb 以及 Adb，基于開源的有 Selectdb、Mongodb、Clickhouse。其中，闡述了拳頭產品 Polardb 的性能優(yōu)化。在產品方面，Rds+Redis、Polardb+Tair，內置緩存和無需人工關注讀寫一致性。同時，介紹了Adb 和 Lindorm，Lindorm 作為 Nosql 數(shù)據(jù)庫的能力和支持多模態(tài)。

大數(shù)據(jù)方面：介紹了 Pai 平臺，Maxcomputor 支持 Python 處理，F(xiàn)link+Paimon 新一代實時湖倉方案，Dataworks 智能化升級，比如支持自然語言，全托管向量檢索服務 Dashvector，最后介紹將要全面 Serverless 化的產品，比如 ES、Spark、StarRocks 等。

二、大數(shù)據(jù)技術發(fā)展和應用現(xiàn)狀

大數(shù)據(jù)的技術發(fā)展起步于 Google 的 2003 年三篇論文，GFS、Bigtable、MapReduce，愿稱之為大數(shù)據(jù) 1.0 階段，分別闡述了海量數(shù)據(jù)存儲、快速點查、通用計算。后來基于三篇論文原型實現(xiàn)的大數(shù)據(jù)開源組件，Hadoop 技術體系，包含 HDFS、Hbase、Yarn、MapReduce，分別解決在廉價機器構建分布式存儲、快速點查、資源調度、海量數(shù)據(jù)計算問題。

隨著技術的發(fā)展，大數(shù)據(jù)組件的推陳推新，以 Hive、Spark、Storm 為代表，大數(shù)據(jù)邁入了 2.0 階段，同時像ELK解決特定場景的輕量化的鏈路也有了發(fā)展空間。過程中，OLAP 分析領域迎來了新的發(fā)展，如 Clickhouse、Kylin、Druid 等 OLAP 引擎。數(shù)據(jù)的主要構建方式過渡到了以類 SQL 為主。

在后面的 2.0 階段，實時計算方面，2015 年谷歌發(fā)表《Google-DataFlow》介紹了流式計算的概念，后來有了開源的 Flink 實時計算，大數(shù)據(jù)處理步入了 2.5 階段。近年來，企業(yè)迎來了上云浪潮，帶來了阿里云的迅猛發(fā)展。K8s 體系在業(yè)務系統(tǒng)逐漸普及。在 OLAP 領域，迎來了新一批成員，如 StarRocks、Doris 等 MPP 數(shù)據(jù)庫引擎。同時，數(shù)據(jù)湖的快速發(fā)展，Hudi、Iceberg、Delta、Paimon，在存儲層和表之間構建了一層，基于云上對象存儲近乎無限的特點，數(shù)據(jù)倉庫的概念步入了數(shù)據(jù)湖的概念。

那么我們是不是可以算進入了大數(shù)據(jù) 3.0 階段呢？我認為還有一塊需要補足。雖然大數(shù)據(jù)跟隨所在公司上云，應用了云上的基礎設置，但是大數(shù)據(jù)技術的構建，本質還是基于傳統(tǒng)的 ECS 來實施，從公有云的發(fā)展來看，K8s 天然提供的資源調度和編排體系能夠替代 Yarn 資源調度。基于 HDFS 的存儲，能夠使用 OSS 來構建數(shù)據(jù)湖系統(tǒng)。網絡方面，公有云看到了大數(shù)據(jù)云原生的趨勢，網絡方面已經做了升級改造。K8s 的彈性能力在成本的天然優(yōu)勢是眾多企業(yè)的首選。那么，需要解決的問題在于計算組件如何契合K8s體系，形成云原生。

我們可以看到主要大數(shù)據(jù)組件的發(fā)展趨勢，Spark、Flink、Clickhouse、StarRocks 等，正在快速發(fā)展自身基于K8s構建應用的能力。在這個過程中，避免不了會碰到一些問題，下面我們來具體看一看。

三、大數(shù)據(jù)云原生的重難點

大數(shù)據(jù)上云和大數(shù)據(jù)云原生化是兩個不同的概念。大數(shù)據(jù)上云，一般可以理解為，企業(yè)不需要去自建機房，使用公有云作為 IDC，大數(shù)據(jù)基于公有云的基礎設施（虛擬機、存儲、網絡）來構建大數(shù)據(jù)技術體系。大數(shù)據(jù)的云原生化，則是指將大數(shù)據(jù)技術與應用部署在云原生環(huán)境中，利用云原生的優(yōu)勢，如容器化、彈性伸縮、存算分離等，以實現(xiàn)更高效、更靈活、更可靠的大數(shù)據(jù)處理和分析。

需要注意的是，大數(shù)據(jù)云原生化的實現(xiàn)需要解決一些技術和生態(tài)問題，如兼容性、資源管理、計算性能和生態(tài)融合等。因此，在實現(xiàn)大數(shù)據(jù)云原生化時，需要進行全面的架構設計和實施方法選擇，以確保最終的解決方案能夠滿足實際需求。將大數(shù)據(jù)組件進行云原生化的升級改造，具體來說需要從存儲、計算以及調度這三個基礎維度來入手。

存儲方面相對來說，比較容易進行改造和替換，企業(yè)可以選擇市面上多種云存儲，且這種云儲存除了具備高容錯、高可靠性以外，還需要具備冷熱數(shù)據(jù)分層管理，以及與主流大數(shù)據(jù)計算引擎 Hive、Spark、Trino 等無縫兼容適配能力，如阿里云近年推出的 OSS-HDFS 云存儲。除了上述所說的云儲存以外，將大數(shù)據(jù)進行云原生化改造，重難點問題在于計算和調度這兩個維度。

K8s 之于大數(shù)據(jù)體系有幾點問題相對突出：第一是大數(shù)據(jù)離線計算對于瞬時容器的突發(fā)需求，以 Spark 任務為例，一個較大規(guī)模的 Spark 任務短時需要的 Container 可能是幾千到萬級別，K8s 的 Pod 能否快速彈出，短時超大規(guī)模鏡像拉取是否會有瓶頸。第二是隨之而來容器基礎網絡問題，如 Pod 上網絡的創(chuàng)建和釋放能否滿足，容器間網絡帶寬性能能否滿足。第三是容器的掛載盤普遍較小，Spark 或 Flink 都存在Shuffle數(shù)據(jù)落盤的問題。大數(shù)據(jù)云原生在計算和調度兩個維度，上述三個問題是需要解決的。

四、大數(shù)據(jù)云原生的可行性

從主論壇技術上看，大數(shù)據(jù)相關的核心基礎設施在容器上都有較大提升，如 Serverless 彈性容器和底層網絡的性能提升、OSS 帶寬的提升以及 OSS-HDFS 協(xié)議的支持。同時，開源社區(qū)中出現(xiàn)了各種用于大數(shù)據(jù)中間結果的 Remote Shuffle 組件，如 Celeborn 等。我認為大數(shù)據(jù)云原生化是可行的，相信很多公司的大數(shù)據(jù)發(fā)展方向會朝著云原生路線演進。在云棲大會的參會單位中，無意中看到了一家公司關于大數(shù)據(jù)云原生的案例：《米哈游大數(shù)據(jù)云原生實踐》，分享者是這家公司大數(shù)據(jù)技術專家杜安明。他們的實踐和我的想法不謀而合，下面我們來看一下他們是怎么做的。

他們主要分享了米哈游大數(shù)據(jù)架構向云原生化升級過程中的目標、探索和實踐，以及如何通過以阿里云容器服務 ACK 為底座的 Spark 云原生架構，獲得在彈性計算、成本節(jié)約以及存算分離方面的價值。

一是彈性計算。由于游戲業(yè)務會進行周期版本更新、開啟活動以及新游戲的上線等，對離線計算資源的需求與消耗波動巨大，可能是平時水位的幾十上百倍。利用K8s集群天然的彈性能力，將 Spark 計算任務調度到 K8s 上運行，可以比較輕松的解決這類場景下資源消耗洪峰問題。

二是成本節(jié)約。依托阿里云容器服務 Kubernetes 版 ACK 集群自身強大的彈性能力，所有計算資源按量申請、用完釋放，再加上我們對 Spark 組件的定制改造，以及充分利用 ECI Spot 實例，在承載同等計算任務和資源消耗下，成本節(jié)約達 50%。

三是存算分離。Spark 運行在 K8s 之上，完全使用 K8s 集群的計算資源，而訪問的數(shù)據(jù)也由 HDFS、OSS 逐步切換到 OSS-HDFS 上，中間 Shuffle 數(shù)據(jù)的讀寫采用 Celeborn，整套架構實現(xiàn)了計算和存儲的解耦，易于維護和擴展。

整個分享看下來，米哈游大數(shù)據(jù)攻克了很多重難點問題，已經實現(xiàn)了大數(shù)據(jù)計算的云原生化，并且取得了很不錯的收益。

附錄：

2023 云棲大會技術主論壇：https://yunqi.aliyun.com/2023/techkeynotesession。

開源大數(shù)據(jù)平臺 3.0 技術解讀: https://mp.weixin.qq.com/s/iEAl4qk2pkabCi-vfOBRyA。

米哈游大數(shù)據(jù)云原生實踐：https://mp.weixin.qq.com/s/VTV9J6J1J-KZlYO79M_J4g。