任何一種技術都會經歷從陽春白雪到下里巴人的過程，就像我們對計算機的理解從“戴著鞋套才能進的機房”變成了隨處可見的智能手機。在前面20年中，大數據技術也經歷了這樣的過程，從曾經高高在上的 “火箭科技（rocket science）”，成為了人人普惠的技術。

回首來看，大數據發展初期涌現了非常多開源和自研系統，并在同一個領域展開了相當長的一段“紅海”競爭期，例如Yarn VS Mesos、Hive VS Spark、Flink VS SparkStreaming VS Apex、Impala VS Presto VS Clickhouse等等。經歷激烈競爭和淘汰后，勝出的產品逐漸規模化，并開始占領市場和開發者。

事實上，近幾年，大數據領域已經沒有再誕生新的明星開源引擎（Clickhouse@2016年開源，PyTorch@2018年開源），以Apache Mesos等項目停止維護為代表，大數據領域進入“后紅海”時代：技術開始逐步收斂，進入技術普惠和業務大規模應用的階段。

本文作者關濤是大數據系統領域的資深專家，在微軟（互聯網/Azure云事業群）和阿里巴巴（阿里云）經歷了大數據發展20年過程中的后15年。本文試從系統架構的角度，就大數據架構熱點，每條技術線的發展脈絡，以及技術趨勢和未解問題等方面做一概述。

值得一提的是，大數據領域仍然處于發展期，部分技術收斂，但新方向和新領域層出不窮。本文內容和個人經歷相關，是個人的視角，難免有缺失或者偏頗，同時限于篇幅，也很難全面。僅作拋磚引玉，希望和同業共同探討。

一、當下的大數據體系熱點

BigData概念在上世紀90年代被提出，隨Google的3篇經典論文（GFS，BigTable，MapReduce）奠基，已經發展了將近20年。這20年中，誕生了包括Google大數據體系，微軟Cosmos體系，阿里云的飛天系統，開源Hadoop體系等優秀的系統。這些系統一步步推動業界進入“數字化“和之后的“AI化”的時代。

海量的數據以及其蘊含的價值，吸引了大量投入，極大的推動大數據領域技術。云（Cloud）的興起又使得大數據技術對于中小企業唾手可得。可以說，大數據技術發展正當時。

從體系架構的角度看，“Shared-Everything”架構演進、湖倉技術的一體化融合、云原生帶來的基礎設計升級、以及更好的AI支持，是當下平臺技術的四個熱點。

1.1 系統架構角度，平臺整體向Shared-Everything架構演進

泛數據領域的系統架構，從傳統數據庫的Scale-up向大數據的Scale-out發展。從分布式系統的角度，整體架構可以按照Shared-Nothing（也稱MPP）, Shared-Data, Shared-Everything 三種架構。

大數據平臺的數倉體系最初由數據庫發展而來，Shared-Nothing（也稱MPP）架構在很長一段時間成為主流。隨云原生能力增強，Snowflake為代表的Shared-Data逐漸發展起來。而基于DFS和MapReduce原理的大數據體系，設計之初就是Shared-Everything架構。

Shared-Everything架構代表是GoogleBigQuery和阿里云MaxCompute。從架構角度，Shared-Everything架構具備更好的靈活性和潛力，會是未來發展的方向。

（圖：三種大數據體系架構）

1.2 數據管理角度，數據湖與數據倉庫融合，形成湖倉一體

數據倉庫的高性能與管理能力，與數據湖的靈活性，倉和湖的兩套體系在相互借鑒與融合。在2020年各個廠商分別提出湖倉一體架構，成為當下架構演進最熱的趨勢。但湖倉一體架構有多種形態，不同形態尚在演進和爭論中。

(圖：數據湖與數據倉庫借鑒融合)

1.3 云架構角度，云原生與托管化成為主流

隨著大數據平臺技術進入深水區，用戶也開始分流，越來越多的中小用戶不再自研或自建數據平臺，開始擁抱全托管型（通常也是云原生）的數據產品。Snowflake作為這一領域的典型產品，得到普遍認可。面向未來，后續僅會有少量超大規模頭部公司采用自建（開源+改進）的模式。

(圖：snowflake的云原生架構）

1.4 計算模式角度，AI逐漸成為主流，形成BI+AI雙模式

BI作為統計分析類計算，主要是面向過去的總結；AI類計算則具備越來越好的預測未來的能力。在過去五年中，算法類的負載從不到數據中心總容量的5%，提升到30%。AI已經成為大數據領域的一等公民。

二、大數據體系的領域架構

在前文(#1.1)介紹的Shared-Nothing、Shared-Data、Shared-Everything 三種架構中，筆者經歷過的兩套體系（微軟Cosmos/Scope體系，和阿里云MaxCompute）均為Shared-Everything架構，因此筆者主要從Shared-Everything架構角度，將大數據領域分成6個疊加的子領域、3個橫向領域，共9個領域，具體如下圖。

(圖：基于 Shared-Everything 大數據體系下的領域架構)

經過多年的發展，每個領域都有一定的進展和沉淀，下面各個章節將概述每個子領域的演進歷史、背后驅動力、以及發展方向。

2.1 分布式存儲向多層智能化演進

分布式存儲，本文特指通用大數據海量分布式存儲，是個典型的帶狀態（Stateful）分布式系統，高吞吐、低成本、容災、高可用是核心優化方向。（注：下述分代僅為了闡述方便，不代表嚴格的架構演進。）

第一代，分布式存儲的典型代表是谷歌的GFS和Apache Hadoop的HDFS，均為支持多備份的Append-only文件系統。因HDFS早期NameNode在擴展性和容災方面的短板不能充分滿足用戶對數據高可用的要求，很多大型公司都有自研的存儲系統，如微軟的Cosmos（后來演進成Azure Blob Storage），以及阿里巴巴的Pangu系統。HDFS作為開源存儲的奠基，其接口成為事實標準，同時HDFS又具備支持其他系統作為背后存儲系統的插件化能力。

第二代，基于上述底盤，隨海量對象存儲需求激增（例如海量的照片），通用的Append-only文件系統之上，封裝一層支持海量小對象的元數據服務層，形成對象存儲（Object-based Storage），典型的代表包括AWS S3，阿里云OSS。值得一提的是，S3與OSS均可作為標準插件，成為HDFS的事實存儲后端。

第三代，以數據湖為代表。隨云計算技術的發展，以及（2015年之后）網絡技術的進步，存儲計算一體的架構逐漸被云原生存儲（存儲托管化）+ 存儲計算分離的新架構取代。這也是數據湖體系的起點。同時因存儲計算分離帶來的帶寬性能問題并未完全解決，在這個細分領域誕生了Alluxio等緩存服務。

第四代，也是當下的趨勢，隨存儲云托管化，底層實現對用戶透明，因此存儲系統有機會向更復雜的設計方向發展，從而開始向多層一體化存儲系統演進。由單一的基于SATA磁盤的系統，向Mem/SSD+SATA (3X備份)+SATA (1.375X為代表的EC備份)+冰存儲（典型代表AWS Glacier）等多層系統演進。

如何智能/透明的將數據存儲分層，找到成本與性能的Trade-off，是多層存儲系統的關鍵挑戰。這領域起步不久，開源領域沒有顯著好的產品，最好的水平由幾個大廠的自研數倉存儲系統引領。

(圖：阿里巴巴 MaxCompute 的多層一體化存儲體系)

在上述系統之上，有一層文件存儲格式層（File Format layer），與存儲系統本身正交。

存儲格式第一代，包含文件格式、壓縮和編碼技術、以及Index支持等。目前主流兩類的存儲格式是Apache Parquet和Apache ORC，分別來自Spark和Hive生態。兩者均為適應大數據的列式存儲格式，ORC在壓縮編碼上有特長，Parquet在半結構支持上更優。此外另有一種內存格式Apache Arrow，設計體系也屬于format，但主要為內存交換優化。

存儲格式第二代 - 以 Apache Hudi/Delta Lake 為代表的近實時化存儲格式。存儲格式早期，是大文件列存儲模式，面向吞吐率優化（而非latency）。隨著實時化的趨勢，上述主流的兩個存儲模式均向支持實時化演進，Databricks推出了Delta Lake，支持Apache Spark進行近實時的數據ACID操作；Uber推出了Apache Hudi，支持近實時的數據Upsert能力。

盡管二者在細節處理上稍有不同（例如Merge on Read or Write），但整體方式都是通過支持增量文件的方式，將數據更新的周期降低到更短（避免傳統Parquet/ORC上的針對更新的無差別FullMerge操作），進而實現近實時化存儲。因為近實時方向，通常涉及更頻繁的文件Merge以及細粒度元數據支持，接口也更復雜，Delta/Hudi均不是單純的format、而是一套服務。

存儲格式再向實時更新支持方向演進，會與實時索引結合，不再單單作為文件存儲格式，而是與內存結構融合形成整體方案。主流的是實時更新實現是基于LogStructuredMergeTree（幾乎所有的實時數倉）或者Lucene Index（Elastic Search的格式）的方式。

從存儲系統的接口/內部功能看，越簡單的接口和功能對應更開放的能力（例如GFS/HDFS），更復雜更高效的功能通常意味著更封閉，并逐步退化成存算一體的系統（例如AWS當家數倉產品RedShift），兩個方向的技術在融合。

展望未來，我們看到可能的發展方向/趨勢主要有：

1）平臺層面，存儲計算分離會在兩三年內成為標準，平臺向托管化和云原生的方向發展。平臺內部，精細化的分層成為平衡性能和成本的關鍵手段（這方面，當前數據湖產品還做得遠遠不夠），AI在分層算法上發揮更大的作用。

2）Format層面，會繼續演進，但大的突破和換代很可能取決于新硬件的演進（編碼和壓縮在通用處理器上的優化空間有限）。

3）數據湖和數倉進一步融合，使得存儲不僅僅是文件系統。存儲層做的多厚，與計算的邊界是什么，仍然是個關鍵問題。

2.2 分布式調度，基于云原生，向統一框架和算法多元化發展

計算資源管理是分布式計算的核心能力，本質是解決不同種類的負載與資源最優匹配的問題。在“后紅海時代”，Google的Borg系統，開源Apache Yarn 依舊是這個領域的關鍵產品，K8S在大數據計算調度方向上仍在起步追趕。

常見的集群調度架構有：

中心化調度架構：早期的Hadoop1.0的MapReduce、后續發展的Borg、和Kubernetes都是中心化設計的調度框架，由單一的調度器負責將任務指派給集群內的機器。特別的，中心調度器中，大多數系統采用兩級調度框架通過將資源調度和作業調度分開的方式，允許根據特定的應用來定做不同的作業調度邏輯，并同時保留了不同作業之間共享集群資源的特性。Yarn、Mesos都是這種架構。
共享狀態調度架構：半分布式的模式。應用層的每個調度器都擁有一份集群狀態的副本，并且調度器會獨立地對集群狀態副本進行更新。如Google的Omega、Microsoft的Apollo，都是這種架構。
全分布式調度架構：從Sparrow論文開始提出的全分布式架構則更加去中心化。調度器之間沒有任何的協調，并且使用很多各自獨立的調度器來處理不同的負載。
混合式調度架構：這種架構結合了中心化調度和共享狀態的設計。一般有兩條調度路徑，分別為為部分負載設計的分布式調度，和來處理剩下的負載的中心式作業調度。

(圖 ：The evolution of cluster scheduler architectures by Malte Schwarzkopf)

無論大數據系統的調度系統是基于哪種架構，在海量數據處理流程中，都需要具備以下幾個維度的調度能力：

數據調度：多機房跨區域的系統服務帶來全域數據排布問題，需要最優化使用存儲空間與網絡帶寬。
資源調度：IT基礎設施整體云化的趨勢，對資源的調度和隔離都帶來更大的技術挑戰；同時物理集群規模的進一步擴大，去中心化的調度架構成為趨勢。
計算調度：經典的MapReduce計算框架逐漸演化到支持動態調整、數據Shuffle的全局優化、充分利用內存網絡等硬件資源的精細化調度時代。
單機調度：資源高壓力下的SLA保障一直以來是學術界和工業界發力的方向。Borg等開源探索都假設在資源沖突時無條件向在線業務傾斜；但是離線業務也有強SLA需求，不能隨意犧牲。

展望未來，我們看到可能的發展方向/趨勢主要有：

1.K8S統一調度框架：Google Borg很早就證明了統一的資源管理有利于最優匹配和削峰填谷，盡管K8S在“非在線服務”調度上仍然有挑戰，K8S準確的定位和靈活的插件式設計應該可以成為最終的贏家。大數據調度器（比如KubeBatch）是目前投資的一個熱點。

2.調度算法多元化和智能化：隨各種資源的解耦（例如，存儲計算分離），調度算法可以在單一維度做更深度的優化，AI優化是關鍵方向（實際上，很多年前Google Borg就已經采用蒙特卡洛Simulation做新任務資源需求的預測了）。

3.面向異構硬件的調度支持：眾核架構的ARM成為通用計算領域的熱點，GPU/TPU等AI加速芯片也成為主流，調度系統需要更好支持多種異構硬件，并抽象簡單的接口，這方面K8S插件式設計有明顯的優勢。

2.3 元數據服務統一化

元數據服務支撐了大數據平臺及其之上的各個計算引擎及框架的運行，元數據服務是在線服務，具有高頻、高吞吐的特性，需要具備提供高可用性、高穩定性的服務能力，需要具備持續兼容、熱升級、多集群（副本）管理等能力。主要包括以下三方面的功能：

DDL/DML的業務邏輯，保障ACID特性，保障數據完整性和一致性
授權與鑒權能力，保證數據訪問的安全性
Meta(元數據) 的高可用存儲和查詢能力，保障作業的穩定性

第一代數據平臺的元數據系統，是Hive的Hive MetaStore（HMS）。在早期版本中HMS元數據服務是Hive的內置服務，元數據更新（DDL)以及DML作業數據讀寫的一致性和Hive的引擎強耦合，元數據的存儲通常托管在MySQL等關系數據庫引擎。

隨著客戶對數據加工處理的一致性（ACID），開放性（多引擎，多數據源），實時性，以及大規模擴展能力的要求越來越高，傳統的HMS逐步局限于單集群，單租戶，Hive為主的單個企業內部使用，為保障數據的安全可靠，運維成本居高不下。這些缺點在大規模生產環境逐步暴露出來。

第二代元數據系統的代表，有開源體系的Apache IceBerg，和云原生體系的阿里巴巴大數據平臺MaxCompute的元數據系統。

IceBerg是開源大數據平臺最近兩年出現的獨立于引擎和存儲的“元數據系統”，其要解決的核心問題是大數據處理的ACID，以及表和分區的元數據的規模化之后性能瓶頸。在實現方法上IceBerg的ACID依托了文件系統POSIX的語義，分區的元數據采用了文件方式存儲，同時，IceBerg的Table Format獨立于Hive MetaStore的元數據接口，因此在引擎的adoption上成本很高，需要各個引擎改造。

基于未來的熱點和趨勢的分析，開放的，托管的統一元數據服務越來越重要，多家云廠商，都開始提供了DataCatalog服務，支持多引擎對湖和倉數據存儲層的訪問。

對比第一代與第二代元數據系統：

展望未來，我們看到可能的發展方向/趨勢主要有：

1.趨勢一：湖倉一體進一步發展下，元數據的統一化，以及對湖上元數據和數據的訪問能力建設。如基于一套賬號體系的統一的元數據接口，支持湖和倉的元數據的訪問能力。以及多種表格式的ACID的能力的融合，這個在湖上數據寫入場景越來越豐富時，支持Delta，Hudi，IceBerg表格式會是平臺型產品的一個挑戰。

2.趨勢二：元數據的權限體系轉向企業租戶身份及權限體系，不再局限于單個引擎的限制。

3.趨勢三：元數據模型開始突破關系范式的結構化模型，提供更豐富的元數據模型，支持標簽，分類以及自定義類型和元數據格式的表達能力，支持AI計算引擎等等。

本文詳細闡述了后紅海時代，當下大數據體系的演進熱點是什么，以及大數據體系下部分子領域架構的技術解讀。