作者 | 阿裡雲計算平台研究員關濤、阿裡巴巴項目管理專家王璀
任何一種技術都會經曆從陽春白雪到下裡巴人的過程，就像我們對計算機的了解從“戴着鞋套才能進的機房”變成了随處可見的智能手機。在前面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需求，不能随意犧牲。
- K8S統一排程架構：Google Borg很早就證明了統一的資源管理有利于最優比對和削峰填谷，盡管K8S在“非線上服務”排程上仍然有挑戰，K8S準确的定位和靈活的插件式設計應該可以成為最終的赢家。大資料排程器（比如KubeBatch）是目前投資的一個熱點。
- 排程算法多元化和智能化：随各種資源的解耦（例如，存儲計算分離），排程算法可以在單一次元做更深度的優化，AI優化是關鍵方向（實際上，很多年前Google Borg就已經采用蒙特卡洛Simulation做新任務資源需求的預測了）。
- 面向異構硬體的排程支援：衆核架構的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服務，支援多引擎對湖和倉資料存儲層的通路。
對比第一代與第二代中繼資料系統：
- 趨勢一：湖倉一體進一步發展下，中繼資料的統一化，以及對湖上中繼資料和資料的通路能力建設。如基于一套賬号體系的統一的中繼資料接口，支援湖和倉的中繼資料的通路能力。以及多種表格式的ACID的能力的融合，這個在湖上資料寫入場景越來越豐富時，支援Delta，Hudi，IceBerg表格式會是平台型産品的一個挑戰。
- 趨勢二：中繼資料的權限體系轉向企業租戶身份及權限體系，不再局限于單個引擎的限制。
- 趨勢三：中繼資料模型開始突破關系範式的結構化模型，提供更豐富的中繼資料模型，支援标簽，分類以及自定義類型和中繼資料格式的表達能力，支援AI計算引擎等等。
本文詳細闡述了後紅海時代，當下大資料體系的演進熱點是什麼，以及大資料體系下部分子領域架構的技術解讀。
限于篇幅原因，更多大資料體系子領域的技術解讀将在下篇文章繼續展開，并闡述大資料體系未來演進的技術趨勢，以及仍待探索的未解問題。