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

回首來看，大數(shù)據(jù)發(fā)展初期涌現(xiàn)了非常多開源和自研系統(tǒng)，并在同一個領域展開了相當長的一段“紅海”競爭期，例如Yarn VS Mesos、Hive VS Spark、Flink VS SparkStreaming VS Apex、Impala VS Presto VS Clickhouse等等。經(jīng)歷激烈競爭和淘汰后，勝出的產(chǎn)品逐漸規(guī)?；?，并開始占領市場和開發(fā)者。

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

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

值得一提的是，大數(shù)據(jù)領域仍然處于發(fā)展期，部分技術收斂，但新方向和新領域?qū)映霾桓F。本文內(nèi)容和個人經(jīng)歷相關，是個人的視角，難免有缺失或者偏頗，同時限于篇幅，也很難全面。僅作拋磚引玉，希望和同業(yè)共同探討。

一、當下的大數(shù)據(jù)體系熱點

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

海量的數(shù)據(jù)以及其蘊含的價值，吸引了大量投入，極大的推動大數(shù)據(jù)領域技術。云（Cloud）的興起又使得大數(shù)據(jù)技術對于中小企業(yè)唾手可得?？梢哉f，大數(shù)據(jù)技術發(fā)展正當時。

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

1.1 系統(tǒng)架構角度，平臺整體向Shared-Everything架構演進

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

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

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

（圖：三種大數(shù)據(jù)體系架構）

1.2 數(shù)據(jù)管理角度，數(shù)據(jù)湖與數(shù)據(jù)倉庫融合，形成湖倉一體

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

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

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

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

(圖：snowflake的云原生架構）

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

BI作為統(tǒng)計分析類計算，主要是面向過去的總結(jié)；AI類計算則具備越來越好的預測未來的能力。在過去五年中，算法類的負載從不到數(shù)據(jù)中心總?cè)萘康?%，提升到30%。AI已經(jīng)成為大數(shù)據(jù)領域的一等公民。

二、大數(shù)據(jù)體系的領域架構

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

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

經(jīng)過多年的發(fā)展，每個領域都有一定的進展和沉淀，下面各個章節(jié)將概述每個子領域的演進歷史、背后驅(qū)動力、以及發(fā)展方向。

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

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

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

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

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

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

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

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

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

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

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

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

存儲格式再向?qū)崟r更新支持方向演進，會與實時索引結(jié)合，不再單單作為文件存儲格式，而是與內(nèi)存結(jié)構融合形成整體方案。主流的是實時更新實現(xiàn)是基于LogStructuredMergeTree（幾乎所有的實時數(shù)倉）或者Lucene Index（Elastic Search的格式）的方式。

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

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

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

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

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

2.2 分布式調(diào)度，基于云原生，向統(tǒng)一框架和算法多元化發(fā)展

計算資源管理是分布式計算的核心能力，本質(zhì)是解決不同種類的負載與資源最優(yōu)匹配的問題。在“后紅海時代”，Google的Borg系統(tǒng)，開源Apache Yarn 依舊是這個領域的關鍵產(chǎn)品，K8S在大數(shù)據(jù)計算調(diào)度方向上仍在起步追趕。

常見的集群調(diào)度架構有：

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

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

無論大數(shù)據(jù)系統(tǒng)的調(diào)度系統(tǒng)是基于哪種架構，在海量數(shù)據(jù)處理流程中，都需要具備以下幾個維度的調(diào)度能力：

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

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

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

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

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

2.3 元數(shù)據(jù)服務統(tǒng)一化

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

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

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

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

第二代元數(shù)據(jù)系統(tǒng)的代表，有開源體系的Apache IceBerg，和云原生體系的阿里巴巴大數(shù)據(jù)平臺MaxCompute的元數(shù)據(jù)系統(tǒng)。

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

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

對比第一代與第二代元數(shù)據(jù)系統(tǒng)：

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

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

2.趨勢二：元數(shù)據(jù)的權限體系轉(zhuǎn)向企業(yè)租戶身份及權限體系，不再局限于單個引擎的限制。

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

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