00?編者按????

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

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

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

本文特邀阿里云計算平臺事業部的同學，以自己的視角，聊聊他們認為的當前“大數據體系”是什么？

01?當下的大數據體系的熱點

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

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

筆者有幸在微軟（互聯網/Azure云事業群）和阿里巴巴（阿里云）經歷了大數據發展20年過程中的后15年。受到編輯的邀請，并給了一個很大的題目來討論“當下的大數據體系和發展”。筆者目前負責阿里巴巴和阿里云大數據領域的部分工作，也接觸很多內部和外部的客戶/業務。本文試從系統架構的角度，就大數據架構熱點，每條技術線的發展脈絡，以及技術趨勢和未解問題等方面做一概述。

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

從體系架構的角度看，“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已經成為大數據領域的一等公民。

02?大數據體系的領域架構

在前文(#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）。兩個方向的技術在融合。

以阿里巴巴大數據體系為例：

阿里巴巴的大數據存儲系統，目前數萬臺存算一體/存算分離的服務器，總存儲容量超過5EB，支持阿里集團和阿里云的主線大數據業務。過去5年演進脈絡如下：

2017年文件格式全面升級為基于Apache?Orc的AliOrc格式：并將完整的C++ ORC writer實現和多個讀寫性能優化貢獻開源社區。團隊成員在開源社區影響力包括1位PMC、1位committer和2位contributor，共計40+提交，2w+行代碼。

2018年，AliOrc重點發展了智能編碼：通過異步預讀、高效的字典編碼實現、動態內存管理、zero-copy內存優化、浮點數和decimal類型編碼優化、自適應編碼等優化和改進，每個版本之間性能提升20%。

2018年，開始智能化分層存儲的探索。基于數據智能分析，將數據劃分為熱數據、溫數據、歸檔數據和冷數據。通過SSD、HDD、EC編碼和冷存機器等技術和硬件，將數據分布在不同的機器上。采用了智能分層存儲后，降低了15%+的存儲成本，熱數據的TableScan性能提升50%+。

2019年，開始近實時化的演進。基于AliOrc的block級別Zone Map，以及一種可以高效地將幾個不同字段的相鄰的數據聯合排布在一起的Z-Order Index，通過謂詞下推顯著提升過濾能力。

2020年，全面升級為AliOrc?v2.0。通過并行化編碼技術、異步化并行IO，以及高效的支持隨機讀的IO Manager，進一步提升了讀寫性能。同時，AliOrc與引擎深度定制，支持row group對齊、lazy read、lazy decoding，統一了實時和離線系統的列存文件存儲。

(圖：阿里大數據體系?- MaxCompute 存儲架構)

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

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

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

數據湖和數倉進一步融合，使得存儲不僅僅是文件系統。存儲層做的多厚，與計算的邊界是什么，仍然是個關鍵問題。阿里云給了一個答案，但仍然需要時間驗證。

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

計算資源管理是分布式計算的核心能力，本質是解決不同種類的負載與資源最優匹配的問題。在“后紅海時代”，Google的Borg系統，開源Apache Yarn 依舊是這個領域的關鍵產品，K8S在大數據計算調度方向上仍在起步追趕。阿里巴巴大數據體系中，有“伏羲”作為自研的高性能分布式度系統，在全區域數據排布、去中心化調度、在線離線混合部署、動態計算等方面滿足后紅海時代業務場景下的數據/資源/計算調度需求。

常見的集群調度架構有：

• 中心化調度架構：早期的Hadoop1.0的MapReduce、后續發展的Borg、和Kubernetes都是中心化設計的調度框架，由單一的調度器負責將任務指派給集群內的機器。特別的，中心調度器中，大多數系統采用兩級調度框架通過將資源調度和作業調度分開的方式，允許根據特定的應用來定做不同的作業調度邏輯，并同時保留了不同作業之間共享集群資源的特性。Yarn、Mesos都是這種架構。

• 共享狀態調度架構：半分布式的模式。?應用層的每個調度器都擁有一份集群狀態的副本，并且調度器會獨立地對集群狀態副本進行更新。如Google的Omega、Microsoft的Apollo，都是這種架構。

• 全分布式調度架構：從Sparrow論文開始提出的全分布式架構則更加去中心化。調度器之間沒有任何的協調，并且使用很多各自獨立的調度器來處理不同的負載。

• 混合式調度架構：這種架構結合了中心化調度和共享狀態的設計。一般有兩條調度路徑，分別為為部分負載設計的分布式調度，和來處理剩下的負載的中心式作業調度。

(圖?：The?evolution?of?cluster?scheduler?architecturesby?Malte?Schwarzkopf)

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

• 數據調度：多機房跨區域的系統服務帶來全域數據排布問題，需要最優化使用存儲空間與網絡帶寬。

• 資源調度：IT基礎設施整體云化的趨勢，對資源的調度和隔離都帶來更大的技術挑戰；同時物理集群規模的進一步擴大，去中心化的調度架構成為趨勢。

• 計算調度：經典的MapReduce計算框架逐漸演化到支持動態調整、數據Shuffle的全局優化、充分利用內存網絡等硬件資源的精細化調度時代。

• 單機調度：資源高壓力下的SLA保障一直以來是學術界和工業界發力的方向。Borg等開源探索都假設在資源沖突時無條件向在線業務傾斜；但是離線業務也有強SLA需求，不能隨意犧牲。

以阿里巴巴大數據體系為例：

阿里自研的調度框架就是 Fuxi(伏羲)。Fuxi 系統主要負責飛天里的調度服務，在系統設計上是一個通用的調度系統，上層業務既包括偏在線的用戶，也包括偏大數據計算的MaxCompute（ODPS），Blink，HoloGres，PAI，ADS，等用戶。

• 數據調度：Fuxi在業內第一次提出了多集群計算和數據調度的概念，并基于跨集群數據緩存策略、跨集群計算調度、多集群業務排布等技術實現了跨地域維度上存儲冗余／計算均衡／長傳帶寬／性能最優之間的最佳平衡。

• 資源調度：Fuxi近年來已升級到了去中心化資源調度架構，單集群支持10萬服務器*10萬并發job的高頻調度，具備動態彈性擴展能力。基于Fuxi的資源調度能力，此前在阿里已經已大規模落地應用了混部技術，隨著Fuxi對Kubernetes?等開源生態的進一步支持，統一資源池&統一調度的能力也使全局資源利用率進一步提升。

• 計算調度：隨著大數據業務的飛速增長和新計算模型的持續迭代，計算調度框架需要融合 AI 能力，以更好的動態自適應性應支持千萬量級甚至更高量級的超大規模計算。

• 單機調度：Fuxi 早年解決了作業快速啟動和結束、資源調度策略、資源利用率提升等基本需求；近年來又提出了基于優先級的精細化資源隔離策略，解決了資源保障和利用率提升的難題。基于精細化的資源管控能力，混部技術支撐了雙十一0點峰值的75%交易流量，在雙十一超大規模數據量的壓力下，保障了高優先級業務無一延時。?

阿里巴巴大數據平臺調度系統的發展，持續不變的一個重點是超大規模下對性能和成本的極致追求，如混部、跨集群調度、等；同時，系統AI能力的融合，通過提升系統自適應能力來大幅提升調度系統的性能。阿里巴巴調度系統，基于開源體系也在進一步加強發展托管化與云原生的能力，如基于 Kubernetes 對全局資源池的統一調度研發，對各類異構資源池做統一管理，提升全局資源池的利用率，降低成本。?

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

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服務，支持多引擎對湖和倉數據存儲層的訪問。

以阿里巴巴大數據體系為例：阿里巴巴的大數據體系，提供了統一的元數據服務：

（圖：阿里巴巴大數據體系下的統一元數據系統）

以阿里巴巴的大數據體系為例，對比第一代與第二代元數據系統：

	HMS（第一代）	IceBerg（第二代）	阿里巴巴?MaxCompute（第二代）
架構設計	早期作為Hive的內置服務，元數據存儲使用數據庫。	元數據存儲使用Table Format，獨立于HMS接口。	采用了微服務化?scale?out?架構，?元數據存儲使用云原生KV存儲引擎，同時服務化的接口封裝了KV存儲的細節，較好的兼容HMS接口。?
多計算模式支持(統一元數據)	基于HMS+HCatalog，支持Hadoop開源引擎生態	與HMS不兼容，引擎的adoption 成本較高，需要各引擎改造。支持Spark、Flink、Presto、Hive等引擎。	兼容HMS接口，低成本支持 MapReduce, MaxCompute, Spark等云原生和開源計算引擎。
大規模Schema管理能力	單集群，單租戶，沒有線性擴展能力	Schema?Evolution?定義清晰	基于元數據存儲及讀寫的線性可擴展性，具備多集群支持能力。
ACID	僅ACIDTable類型支持事務保證，依賴悲觀鎖方式， 其它數據表類型在異常情況下可能有臟數據。	依賴文件系統的原子性操作，版本切換依賴數據庫系統，樂觀鎖，支持批量和增量更新，適用于“slow changing”的場景。	具備多租戶，多引擎，大規模數倉平臺的ACID能力。基于樂觀鎖并發控制方式統一支持批量&增量數據更新、支持流批接口、支持備份恢復、Versioning，以及以上操作的數據強一致性。
數據訪問和權限控制的統一入口	基礎的管控能力，缺少企業級能力	未包含	支持統一的賬號系統，以及統一的鑒權服務，具備高qps，低latency，高可用的鑒權服務能力。
高可靠性& 高穩定性	并發和性能以及規模處理能力表現一般	在 qps 和 latency 以及微服務化的 scale out 表現不足。	基于分布式多節點架構、大規模任務調度和流控能力，提供高穩定性保障。基于跨集群多副本和在線多版本備份恢復能力提供數據高可靠性保障。

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

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

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

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

2.4?多種計算引擎并存

計算層是整個大數據計算生態的核心，是數據到價值轉換的關鍵。?大數據場景中有各類計算形態，如批、流、交互式、多模、圖、搜索、等多種計算模式。?

大數據領域發展了20年，在“后紅海”時代，主流計算模式已經基本固定，形成批處理、流處理、交互式、機器學習四個核心方向，以及一些小眾/專門場景的計算模式。在開源社區領域，經過百舸爭流式的競爭和沉淀，也基本形成了主流的社區形態。

除了機器學習，前三個方向有一定的overlapping，例如Spark同時支持流、批和部分交互能力。但最終形成廣泛影響力的引擎，都是在某一方向建立顯著的競爭門檻。

整體看，計算引擎的發展將會在存儲計算分離架構基礎上，以一套數據支持多種計算模式：?

• 存儲計算分離，以及隨后的1+N架構（即一套數據之上支持多種計算模式）

• 批處理?-?是大數據處理的基礎形態，以Bulk Synchronous Parallelism（BSP）為基礎原理，從Map-Reduce（MR）模式開始發展起來，所謂“批”指的就是Bulk（也譯作Batch）。Map-Reduce的運算框架逐步發展成Direct Acyclic Graph（DAG），上層語言也開始從MR的Java代碼向SQL轉型，第一版本集大成的批處理開源系統是Hive+Tez。因為Hive 2.0是嚴格BSP模式，每次數據交互均需要落盤，犧牲了延遲和性能。Spark抓住內存增長的趨勢，推出基于Resilient Distributed Dataset(RDD)的運算框架，展開與Hive的競爭。當前在開源領域，Hive/Spark是主流引擎，隨Spark穩定性和內存控制逐步完善，Spark逐步占領開源市場。目前批處理仍然是最主流的計算形態，整體的優化方向是更高吞吐/更低成本。最近兩年，隨近實時方向的興起（以開源Apache Delta/Hudi為代表），批處理數據從接入到計算的延遲得的顯著的降低，給用戶提供了一種成本/延遲的另一個平衡點。

• 交互式分析?-?通常是面向分析場景（人驅動，中小規模輸入數據/小規模輸出數據），在中小規模cook好的數據上（通常是批處理之后的數據），基于更快的存儲、更多的內存（bufferpool）、更實時的數據更新（通常是基于LSMTree的方案），也采用更多的OLAP優化技術（例如Plan Cache）。優化方向更偏延遲（而非成本和吞吐率）。技術棧發展上，有兩個脈絡，一個是從分布式數據庫角度發展起來，采用MPP架構，例如開源領域的Apache Impala和Clickhouse，自研領域的AWS Redshift。另一個是更偏云原生和大數據的架構，例如Apache Presto。

批處理和交互分析，有天然的統一需求，因此很多自研的分析引擎也包括一定的批處理能力，形成一體化，例如當前如日中天的snowflake。而Google BigQuery采用附加交互引擎（內置一個更快的BI Engine）的方式形成一體化。從細節看，交互分析的引擎優化更偏數據庫類優化方向，更強調用好Memory和Index，Plan相對簡單對QueryOptimizer要求低，不需要支持豐富的UDF，也不需要做Query中間的failover。批處理引擎更面向throughput優化，核心是更優化的Plan以及盡量降低IO，同時對failover要求高（因此部分數據要落盤）。這也是為什么BigQuery選擇雙引擎的原因。

• 流處理?-?采用Continuous Processing的計算模式，通過本地狀態保存（State）和CheckPoint（CP，用來做failover），形成分布式增量計算引擎。這種計算模式與BSP架構不同。主打的場景是實時大屏，監控報警以及最近流行的實時機器學習。系統面向低延遲優化，處理的是流式寫入的數據，一致性模型（Exact-Once VS Atleast-Once）、LateEvent處理方式、以及Window函數支持是不同流計算引擎設計的取舍。開源領域Spark Streaming、Apex、Heron和Flink經過競爭，Flink因具備完整Exact-Once語義保證和完善的LateEvent處理能力，最終獲得社區廣泛的關注。

• MachineLearning(ML)/DeepLearning(DL)?-?以統計為基礎理論的傳統機器學習有豐富的生態，包括Python系、Matlab等等。大數據領域Spark MLib以一套數據多種計算的優勢，一度成為大數據傳統算法的主流。隨AlphaGo引爆深度學習領域，TensorFlow和Pytorch成為業界標桿。目前DL領域仍然處于紅海期，模型并行化以及超大模型是近期的熱點。特別的，隨DL興起，Python作為標準語言開始流行，Spark推出Koalas用于連接大數據與AI開發，Python有取代Java成為命令式編程類（Imperitive）大數據開發語言的潛力（Decleritive類編程標準一直是SQL）。

• 其他小眾計算模式?-?因滿足不同細分場景，還有包括圖計算，文本檢索等引擎。圖領域細分成三個子場景：圖計算、圖分析和圖學習。分布式圖分析場景目前仍未有完善的方案，圖語言也在發展期，未形成統一標準。文本檢索領域，主要基于倒排索引技術，開源生態Elastic Search成為生態主流。限于篇幅，這部分不再做更細節的介紹。

以阿里巴巴大數據體系為例：

阿里巴巴大數據體系支持多類引擎，除了大數據計算平臺的引擎產品如 MaxCompute SQL Engine、EMR Jindo、Blink/Flink、 Hologres，也支持其他開源和阿里自研的引擎，如圖計算引擎MaxGraph、搜索引擎Elastic/OpenSearch、Hive、Spark、Tensorflow、Numpy等多種異構引擎。

（圖-阿里巴巴大數據體系，多計算模式支持）

• 批處理引擎?-?MaxCompute?SQL?Engine

在 MaxCompute 的作業中，有90%以上的作業是 SQL 作業，SQL 引擎的能力是 MaxCompute 的核心競爭力之一。SQL 引擎的3個模塊?-?編譯器、運行時、和優化器，在設計實現上做的優化主要有：

• 編譯器:?對 SQL 標準有友好支持，支持100% TPC-DS 語法；具備強大的錯誤恢復能力。

• 運行時:?基于LLVM優化代碼生產，支持列式處理與豐富的關系算符；基于 CPP 的運行時具有更高效率。

• 優化器:?支持HBO和基于 Calcite 的 CBO，?通過多種優化手段不斷提升 MaxCompute 性能。

(圖：MaxCompute SQL 引擎發展歷程)

• 交互式引擎?-?MaxCompute?交互式分析?(Hologres)

Hologres 與MaxCompute 天然無縫融合，全兼容訪問各種MaxCompute文件格式，充分利用異步模型和各種分析型查詢引擎的優化技術，實現對PB級離線數據的毫秒級交互式分析。

(圖：阿里巴巴大數據體系?- Hologres)

• 流處理引擎?-?實時計算Flink版

Apache Flink是目前業界最為流行和成熟的開源流計算技術，阿里云選擇圍繞Apache Flink技術打造了實時計算Flink版，并在集團內部有超大規模的驗證，支持阿里集團所有實時計算數據業務。Flink 社區在 2020?年持續繁榮，蟬聯最活躍的 Apache 項目；Flink 也成為了事實上的國內外實時計算標準。

(圖：阿里巴巴大數據體系?-?實時計算Flink版產品架構）

• MachineLearning/DeepLearning?-?PAI?Tensorflow?等?

阿里巴巴大數據體系下，有多個自研的機器學習和深度學習引擎，?其中主要有?PAI?Tensorflow：是 PAI 機器學習平臺深度定制的面向全集團的深度學習計算引擎。在數據處理、算力如全局異構計算、模型優化層面做了大量創新和優化。?

其他的機器學習和深度學習框架和引擎還有：

• X-DeepLearning：工業級深度學習框架，主要面向大規模廣告/推薦/搜索場景。

• MNN：一款輕量級深度學習端側推理引擎，主攻解決深度神經網絡模型在端側推理運行問題，目前已開源。

• xNN：螞蟻金服研發的端側機器學習引擎，致力于解決機器學習模型在以支付寶為代表的超級App以及IOT設備中部署所面臨的技術難題。

• ALPS：螞蟻的機器學習算法框架，目標是為螞蟻的算法及業務同學提供一個高性能、易用的機器學習算法研發框架，并在此基礎上沉淀螞蟻具有金融特色的算法庫（涵蓋CV/NLP/ML等方向）和解決方案。

• 圖計算引擎?-?Graph?Compute

圖計算服務（Graph Compute）支持圖數據建模、導入和修改、支持Apache TinkerPop標準Gremlin語言進行圖查詢，并支持常見圖分析算法，具有數據加載快、規模可擴展、查詢延時低（毫秒級）和離在線混合引擎與共享存儲等優勢，幫助用戶構建海量關系數據的圖應用服務。

(圖：阿里巴巴大數據體系?- Graph Compute)

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

近實時化成為主流?-?近實時化方案，是在分鐘級的延遲上做到數據的一致性，幾乎不用依賴大量內存的BTree系統和常駐的服務，將成本降低到幾乎和離線一致，在延遲和成本間找到一個新的平衡，會逐步取代部分離線的作業。

IoT領域興起?-?隨設備的智能化和5/6G網絡興起，面向IoT的分析會逐漸火熱。計算形態可能會發生變化，從云為中心演進到云邊端一體。

大數據平臺/引擎整體云原生化?-?新興的引擎均基于云的架構重新設計，充分利用云的優勢，降低復雜度的同時提供更多價值。隨云原生化，Shared-Everything 架構成為未來的演進趨勢。

Learned?based?優化?-?機器學習技術會充分融入大數據系統（甚至任何系統）的設計，優化器、調度系統、存儲格式、Index/MV設計等多個領域均會大量使用AI的技術來做優化。例如Cost based Optimization中的基于Statistics的Cost推導，會大量被Learn based Statistics取代。

2.5?框架與接入層

接入層和管控是一個子系統，主要用于服務背后的主系統。從架構和功能角度上看，與大多數服務的接入層差異不大，也不存在明確的演進和代差，因此簡要概述。唯一值得一提的是，隨越來越多的大數據平臺走向“托管化”或者說“服務化”，框架管控層越來越厚，大多數企業級能力增強來自管控部分。例如，計算引擎是數倉類產品的核心，但最終用戶需要的遠不止引擎本身而是好用的數據倉庫產品，就像發動機是汽車的核心部件，但用戶所需的是完整、好開的汽車。

接入和管控層，抽象下來，主要功能包括：

前端API接入-是系統對外的接口，通常提供HTTP協議接入，并具有認證、流控能力。部分系統提供Web接入能力。

服務層?-?包括更多的業務邏輯，例如用戶/租戶管理，提供服務層面的訪問控制，以及服務級別的流控。對于引擎來說，服務層很可能包括編譯與作業分發能力，異常作業的檢測與隔離等等。有些系統為了簡化將API接入與服務層合二為一個服務進程。

(圖：框架與接入層)

設計考慮：

服務于背后的主系統，功能隨后臺變化而變化，并沒有“一定之規”。

管控層直接決定系統的可用性，因此也需要完善的容災能力，無狀態的服務組件通常依托部署系統實現容災，對于有狀態服務，通常將狀態存儲在元數據系統或者底層存儲系統中。

很多獨立引擎，特別是開源類，接入和管控層通常比較簡單。對于企業級服務來說，很多額外的功能都在本服務擴展，也體現企業級服務的價值。例如：監控/運維能力、審計日志、計量計費、對計算系統熱切換的控制等。甚至包括自動化作業調優等高級功能（例如SparkCruise，來自微軟Azure托管版的基于歷史信息的自動作業調優子系統）。

當用戶選用多個系統組合搭建一套大數據平臺，不同系統都會有自己的管控層，造成服務的冗余和各系統的割裂。因此很多云平臺提供商，會致力于抽象統一規范和公共子模塊，例如統一認證協議/服務（Kerberos等）、統一權限管理，Terraform API標準等。

以阿里巴巴大數據體系為例：

阿里巴巴的大數據平臺（MaxCompute為主）完整的實現了上圖中所有的功能。限于篇幅展開兩個特色功能：

熱升級能力?-?是全托管服務必備的能力，但不同系統實現的難度不同，離線系統相對簡單，在線系統更難些。但基本的能力均包括：1）多版本平行部署執行能力，2）多版本間的切流控制。基于熱升級的多版本能力，可以擴展出更多的功能灰度能力，甚至做到對單一客戶/租戶的特別版本。

元倉系統?-?元倉系統有別于元數據系統（元數據系統是在線的核心元數據服務），它是擴展后更豐富的系統數據，包括數據訪問統計信息、歷史作業運行情況、數據血緣等等，大多數服務數據中臺的數據均來自元倉系統。元倉系統的數據呈現形式是數據表，部分可以開放給客戶，數據庫系統中的Information Schema是一種元倉系統對用戶的呈現。

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

托管化?-?框架與接入層是企業級能力增強的關鍵一層，隨托管化成為大趨勢，這一層會有大量的企業級能力加入，會逐步成為關鍵層。

2.6?數據開發與治理平臺

隨著大數據技術在眾多領域的廣泛應用，大量數據源需要接入大數據平臺，多種數據處理引擎和開發語言被各類技術/非技術人員人員使用，復雜業務催生了規模龐大、邏輯復雜的工作流程，數據成為業務的生命線需要重點保護，數據作為業務的原動力需要更加方便快捷的被分析和應用。

讓大數據計算平臺真正能夠服務于業務，還需要一系列數據研發和數據治理利器，以幫助數據工作者低成本和高效地獲取數據洞察，實現業務價值：

• 數據集成：支持關系型數據庫、大型數倉、NoSQL數據庫、非結構化數據、消息隊列等數據源之間的數據同步，包含批量數據同步、實時數據同步、整庫數據遷移等，解決云上、跨云、跨地域以及本地IDC機房等復雜網絡環境之間的數據同步問題。

• 元數據服務：支持不同數據源的元數據發現與元數據歸集，并構建數據目錄和數據血緣服務，同時為上層數據開發與數據治理提供元數據服務。

• 數據開發：提供在線數據開發IDE，支持多種計算存儲引擎，提供批計算、實時計算、交互式分析、以及機器學習等一體化數據開發服務，為各種技術/非技術人員提供高效極致的ETL/ELT研發體驗。

• 調度系統：支持大規模、高并發、高穩定性的細粒度周期性任務調度，支持流處理、批處理與AI一體化數據任務編排，保障數據生產的時效性、穩定性。

• 數據治理：提供數據資產管理、數據質量控制、數據安全管理、監控告警、數據標準、成本優化等服務，保障數據倉庫能夠規范、健康、合規和可持續發展。

• 數據服務：提供快速將數據表生成數據API服務的能力，連接數據倉庫與數據應用的“最后一公里”，實現靈活可控的數據共享交換服務。

以阿里巴巴大數據體系為例：

在阿里大數據體系中， DataWorks作為大數據平臺操作系統，歷經十二年發展，形成了涵蓋數據集成、數據開發、數據治理、數據服務的一站式大數據開發與治理平臺，每天穩定調度上千萬數據任務，支撐了阿里集團99%的數據業務。

(圖：阿里巴巴大數據體系?- Dataworks)

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

低代碼開發與分析：數據的獲取、分析與應用將逐步從專業開發人員覆蓋到更多的分析師和業務人員，因此數據開發與分析工具將逐步從專業代碼開發工具向低代碼化、可視化工具演進。甚至是基于NLP和知識圖譜技術，實現通過自然語言執行數據查詢。低代碼化開發與分析工具讓非技術人員也能輕松獲取數據洞察，實現數據價值的普惠，實現“人人都是分析師”。

智能編程：在傳統的ETL開發過程中，存在著大量重復的或相似的編碼工作，未來將在AI的加持下，通過語義分析、數據血緣探測、輸入意圖預測等技術，以智能編程助手的形式幫助開發人員實現更高效的編程。

開發即治理：過去我們大多習慣于先開發后治理，最終則讓數據治理成為了負擔。隨著數據規模的不斷增長、數據安全與隱私保護越來越受關注、數據業務化的持續發展，將不再允許數據治理僅僅是事后行為，數據治理將會融合到覆蓋事前、事中和事后的大數據生產與應用的全鏈路中，數據開發與治理將協同并進。

2.7?智能化

隨著大數據平臺及其所承載業務的發展，我們也面臨著新的挑戰：

• 10PB到EB級數據和百萬級別作業規模，已經成為主流，海量數據和作業靠人很難管理和。傳統的DBA模式或數據中臺團隊不再勝任。

• 多種數據融在一起，人無法在海量規模上理解數據的所有價值。

• 大數據系統經過多年發展，如果需要實現“躍遷”式的進步，需要體系結構層面的改造。

因此AI for System的概念興起，基于AI的能力做系統的優化，在數倉領域我們可以稱之為自動數倉（Auto Data Warehouse）。數據湖領域也可以有更多的自動化，但因為數倉方向的數據管理/調優能力發展更早，這個領域更領先。下圖是一個基本的自動數倉能力分類。

(圖：自動數倉能力建設)

自動化本身并不太可衡量，我們定義了一個“自動數倉”的能力分級，類比“自動駕駛”。分為L1-L5.

• L1級：運維能力白屏化和工具化。目前絕大多數系統都可以做到這個層次。

• L2級：更好的系統托管化，底層系統對用戶透明。例如小文件Merge自動化、軟硬件升級透明、自動loadbalance等。很多全托管系統都可以做到這個層次（例如Snowflake、MaxCompute）。

• L3級：中臺能力的自動化，輔助數據關聯與理解，建模與調優。包括數據血緣，相似度，冗余度，使用情況與自動評分。輔助標簽系統，輔助中臺建設。市面上的很多數據中臺產品聚焦在這一層。

• L4級：系統具備自學習能力。基于歷史信息的性能調優（自動Parallelism，自動冷熱數據分層等等），資源與優先級的動態調配，自適應的監控和報警能力，自動數據異常識別。目前大多數系統的能力邊界在此，有巨大的發揮空間。

• L5級：自動化建模。包含更高階的數據理解，能夠自動發現數據的內在關聯與冗余度，根據數據訪問情況，自動維護數倉體系。

（圖：自動駕駛/數倉能力分級）

最近1-2年，自動化資源管理和自動化作業調優成為熱點，有非常多的研究性論文。幾個核心元產品也推出新能力，例如AWS Redshift的自動workload mgmt、自動key sorting和table sorting，微軟Azure的SparkCruise（@VLDB2021）用來抽象公共子查詢做Materialized View。

以阿里巴巴大數據體系為例，整個領域都是新興方向，限于篇幅，只展開介紹下面三個方面:

History?Based?Optimization?(HBO)?-?根據作業歷史執行情況做調優，目前阿里的生產系統主要優化資源使用的方向，例如memory、cpu以及worker并行度等等，自動Index和自動MV抽取等能力在實驗中。HBO體系是一個典型Learn based系統，具備“任務執行歷史?+?集群狀態信息?+?優化規則?->?更優的執行”的特點，系統基于一套信息收集和優化的框架，具有很好的擴展性，方便添加多種新優化能力。從架構看，HBO包含兩部分：

Online：是個在線系統，用于查找是否存在相應的hbo optimization 規則，如果命中，則按照規則進行。這個規則可以是資源分配優化，可以是物理執行計劃的并發度，也可以是優化器里面的Optimization；

Offline：獲取任務的歷史執行記錄，按照一定的策略生成hbo optimization 規則；

基于學習的智能跨域調度?-?本質上也是基于歷史信息的的優化過程，但更聚焦于跨數據中心的數據排布和調度帶寬優化。通過精細化的數據訪問統計，做更優的數據規劃，并持續根據訪問調優。具體算法和架構可以參考Yugong@VLDB 2019

數據異常的自動發現和報警?-?大數據的數據異常發現是個關鍵問題，當前主流的做法是基于規則的質量檢測，這些檢測通常覆蓋在作業工作流的各個地方。當前阿里大數據平臺有超過2000萬作業，數百萬的質量檢測規則，因此面臨規則很難匹配動態變化的數據的問題。因此我們特別開發了動態閾值智能預測與算法匹配周期性波動的能力。具體算法見RobustPeriod@Sigmo2020。

智能化作為大數據體系的發展趨勢之一，上述內容即為我們對這個子領域的未來展望。

2.8?安全與隱私保護

隨著大數據的發展，數據在多方數據融合場景下能發揮更大的價值。然而在這種場景下用戶的隱私保護以及數據的合規問題成為了嚴重的問題。問題的本質是數據的開放性與使用安全性的平衡。安全能力，包括數據安全/隱私保護能力，是大數據體系中的重要能力基線之一。

信息的可用性、信息的完整性、以及信息的保密性是信息安全的三個基本要素。我們將企業級大數據中臺要面臨的安全風險, 根據其所涉及的系統及技術領域的不同, 分為三個層次。

最基礎的層次是數據中心的物理安全與網絡安全，數據中心是構建大數據中臺的基礎，數據中心自身安全性和網絡接入安全性直接影響到企業大數據中臺的可用性。主要包括數據中心保障設施、數據中心安全管控、數據中心的網絡安全等幾個維度的建設。當云架構成為主流，物理安全方面通常由云廠商承擔。

在這之上是企業大數據平臺的系統安全，由大數據平臺內部的多個安全子系統構成，如訪問控制、應用程序隔離、平臺可信、風控和審計等子系統。這些子系統共同保障大數據平臺的完整性。

最上層是數據應用安全，貼近于用戶的應用場景。通過在這一層提供豐富多樣的數據安全產品，大數據中臺為用戶應用數據的各類業務場景提供切實可靠的數據安全能力。

(圖：安全能力的三個層次)

以阿里巴巴大數據體系為例：

阿里巴巴的大數據體系，依托阿里云底座完成數據中心物理安全，平臺和數據安全方面也做了非常多的工作，下圖給出了一個基于數據生命周期的數據安全管理體系。里面有非常多的子領域，比較存儲加密、敏感數據發現和保護、數字水印等等。

（圖：阿里巴巴大數據體系的安全能力建設）

展望未來，我們看到可能的發展方向/趨勢主要有：數據安全共享

隨數據被認知為資產，數據變現成為一個熱門話題，它背后的技術：數據安全共享和多方安全計算也成為熱點方向。總體看，數據變現（也稱為數據安全共享），有兩種典型場景：一方數據對外售賣，多方數據交互計算。

• 域內多租的方案，通常需要細粒度的接入/訪問控制、計算隔離、下載保護等技術配合。主流數倉產品均提供這類方案（比如Snowflake的DataSharing）。

• 另外，這個領域的一個研究方向是基于差分隱私（Differential Privacy）加密的密態計算（例如 DPSAaS@Sigmod2019）。

• 多方數據交互計算方案，通常基于聯邦學習技術（Federated Learning）。

2.9?運維

運維是伴隨著任何一家公司的產品，在整個產品生命周期中一直是存在的。運維負責公司產品業務的正常運轉，處理緊急故障響應，保障業務連續性，產品可用性改進，性能&效率優化，變更管理，監控，容量規劃與管理等相關工作：這些是運維核心的定義所在。

隨著大數據行業的發展，運維走過了傳統Ops到專業化、工具平臺化、再到云化數據化、甚至是到了智能化的階段，從云計算SaaS/PaaS/IaaS三層的演進趨勢我們可以看到，IaaS與PaaS之間的分界線越來越往上走，基礎設施越來越統一，云化虛擬化的趨勢抹平了基礎設施層；同時SaaS與PaaS層的分界線也沒有那么清晰，在SaaS層快速構筑應用的成本越來越低，越來越多的SaaS層能力抽象后下沉到PaaS層，拿來即用，也可以說是PaaS層在往上層演進。結合云計算SPI三層的發展，我們也可以將運維粗略劃分為面向SaaS層的應用型運維、面向PaaS和IaaS層的平臺型運維。

大數據運維業務圍繞穩定性（質量）、成本及效率主要關注如下：

• 針對日常業務穩定性可以分為日常事件管理、問題管理、變更管理及發布管理的標準化ITIL流程；

• 針對成本管理包含了從資源預算、資源采購、預算執行、財務賬單、過保替換等圍繞資源生命周期管理的相關事項；

• 針對效率包含了如何開發一體化的運維平臺以高效支撐業務監控、服務管理、系統管理、應急/安全管理等。

以阿里巴巴大數據體系為例：

阿里大數據運維屬于既包含應用型運維，又包含平臺型運維的運維體系。?為支撐阿里大數據海量規模產品及業務的運維，我們需要建設一套分層的運維體系，借用SPI三層思想來劃分，可以將這套運維體系稱之為運維垂直PaaS體系：

• 運維IaaS層：映射基礎設施的運維層，為上層運維平臺及業務提供管控能力；

• 運維PaaS層：面向運維領域功能的服務層，比如流程編排、作業調度、配置管理、運維分析服務、審批/通知、腳本/命令通道服務等；

• 運維SaaS層：面向具體大數據平臺業務的定制化智能運維運營應用，跟隨所運維對象系統一起向前迭代發展的運營站點。

在垂直運維體系之上，運維業務也可以劃分為SRE大中臺及SRE小前臺：“大中臺”強調運維資源整合、運維能力沉淀的平臺體系，為前臺運維業務開展提供可快速復用的底層技術、數據等資源和能力；“小前臺”就是貼近最終運維所服務對象的相關運維業務，基于中臺整合的數據和產品技術能力，對各前臺業務形成強力支撐，快速試錯，快速行動。

大數據體系發展至今，服務器規模已發展到數萬、數十萬、甚至百萬臺規模。隨著基礎設施規模的發展，運維系統也經歷了一個從人工、到平臺化、再到智能化的自然的演進過程，運維的演進需要能支撐起大數據基礎設施的高復雜、高安全、高可靠、高效率要求。

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

產品化：運維的產品化，本周上是指讓各類運維動作的更標準，更可控。產品化是把對本身服務客戶的產品的運維需求、和運維產品本身的需求、集成到產品功能上，并迭代傳承。同時通過這些標準化的動作，逐步把底層的一些運維數據統一起來。

數據化：?隨著產品規模的擴大以及系統的復雜多產品依賴，在整個過程中會產生大量的系統數據，隨之數據化能力會凸顯的非常重要。數據的收集存儲，計算處理，運維數倉建設，數據分層，實時性，運營分析等相關數據化能力會逐步成為必須基本能力。重點需要關注運維數據的工程，集成，安全和質量。?

智能化：在超大業務規模下，逐步按以前的傳統的運維操作方式不能更高效的支持好業務，一個例子對線上復雜問題的快速定位和修復。但這類人腦的規則級隨著復雜度增長以及產品周期發展不會是一個線性提升，這個時候是需要通過一些智能化算法能力去幫助處理這些海量數據，從中找到一定的結果規則，輔助加快專業人士的判斷。但這塊的技術挑戰非常巨大，同時對資源也有一定的消耗。但這個方向是應該持續發展。

03?大數據體系未來演進的4大技術趨勢

趨勢1：近實時架構興起

在離線batch計算和純流式實時計算之間，以開源Apache Delta/Hudi為代表的近實時架構成為熱點。近實時架構避免了流計算龐大的狀態存儲與管理，在成本和延遲上找到了另一個平衡。隨近實時架構的形成，計算架構最終完成從離線到實時全頻譜支持。

趨勢2：數據共享與隱私保護成為熱點

數據成為資產，開始具備可變現和可交易的能力。可保護隱私的數據交換/共享能力成為強勁的需求。基于Differential Privacy的數據編碼交易，以及基于Federated Learning的多方面安全計算是該領域的熱點技術。

趨勢3：IoT成為新熱點

目前人的行為數據（日志）是大數據計算的主要來源，超過80%的數據都來源于行為日志（例如瀏覽、點擊）。隨5G+智能化設備的興起，設備日志會成為更大的數據源增長點，面向海量低價值設備數據的處理和優化，需要得到更多的關注。

趨勢4：AI for System

AI for System，即上文中提到的大數據自動駕駛。AI作為工具，成為優化的常用手段。在大數據領域，隨數據量/系統復雜度的增長，DBA模式已經不再試用。利用算法優化系統成為主流方向，大數據的“自動駕駛”會越來越自動。

04?大數據體系內待探索的3個疑問

大數據技術收斂，并進入普惠和業務大規模應用的階段，滲透到各行各業。超大規模數據計算和基于數據的智能決策，已經是企業業務數據化運營的重要基礎。不過，在后紅海時代，大數據體系發展有3個疑問值得我們關注：

疑問1:引擎發展呈現跨界的趨勢，但最終是否能夠誕生一套引擎滿足多樣的計算需求，并兼顧通用性和效率？

隨大數據系統整體架構的穩定，各種引擎的發展逐漸進入收斂期，批計算、流計算、交互分析、機器學習收斂成為四個核心計算模式，每個模式均有主線開源引擎成為事實標準。

過去3年沒有再誕生主流的開源計算引擎（每個模式中，引擎的發展脈絡詳見第二章節）。同時，引擎邊界開始變得模糊，HTAP等Hybrid模式成為探索的新趨勢，計算模式是否進一步收斂，收斂的終態會是什么樣子，是個熱點話題。

疑問2:關系模型之外，是否會發展出其他主流計算范式？?

大數據領域整體還是以二維關系表達和計算為基礎（Relational DB的理論基礎），是否有新的計算范式在數據庫領域也持續討論了多年，盡管有包括圖計算在內的其他計算范式，但過去的40年，關系運算持續成為主流。

其中核心原因，筆者個人的判斷是二維關系表達更貼近人的理解能力，或者說高維表達和處理很難被人理解和處理。但關系表達有顯著的短板，它無法處理半結構化和非結構化的數據（比如音視圖類的數據）。

近幾年興起的深度學習技術，帶來了一種全新的處理方式，海量正交化的高維特征作為輸入，由深度神經網絡理解數據，以模型作為產出的引擎計算出結果。這種方式避免人腦對數據處理的局限性，可以在更高維度更復雜數據上做處理，給未來提供了一種新的處理方式的可能性。

但深度學習核心仍然在尋找“最好”的co-relation，可解釋性，推導邏輯以及對結果正確性保證都不夠好。

疑問3:基于開源自建與直接選購企業級產品，誰更能獲得用戶的認可？?

開源軟件是大數據發展的關鍵推手，助力大數據系統的普及化。但面臨如下挑戰：開源系統的軟件交付模式，也給很多客戶帶來高維護成本。

以一個典型的腰部互聯網企業為例，一個100臺規模的大數據平臺硬件投入大約200萬/年，同時需要維持一個3-5人的研發/運維團隊，年成本200-300萬/年。綜合TCO高達450萬/年。

這也是為什么像Snowflake這樣的自研企業級產品流行的原因，大多數不具備深度研發能力的公司，愿意為更豐富的企業級能力和更低的綜合TCO買單；大數據系統開發進入深水區，投資巨大，需要高商業利潤才能支持。

事實上，云計算四巨頭均有自己的自研產品提升利潤率的同時也提升差異化競爭力（例如AWS Redshift，Google BigQuery，阿里云飛天MaxCompute）。

而每個開源社區背后無一例外均有商業公司推出企業版（例如Databricks之于Spark，VVP之于Flink、Elastic之于ElasticSearch）。

因此，長期看，大多數用戶（特別是中小型）進入“技術冷靜期”后，開始審慎考慮綜合投資收益，考慮上云、以及直接采購企業級產品+服務（放棄自建平臺）。

總結

以上是生活随笔為你收集整理的“后红海”时代，大数据体系到底是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。