00?編者按????

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

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

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

本文特邀阿里云計(jì)算平臺事業(yè)部的同學(xué)，以自己的視角，聊聊他們認(rèn)為的當(dāng)前“大數(shù)據(jù)體系”是什么？

01?當(dāng)下的大數(shù)據(jù)體系的熱點(diǎn)

BigData 概念在上世紀(jì)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è)界進(jìn)入“數(shù)字化“和之后的“AI化”的時(shí)代。

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

筆者有幸在微軟（互聯(lián)網(wǎng)/Azure云事業(yè)群）和阿里巴巴（阿里云）經(jīng)歷了大數(shù)據(jù)發(fā)展20年過程中的后15年。受到編輯的邀請，并給了一個(gè)很大的題目來討論“當(dāng)下的大數(shù)據(jù)體系和發(fā)展”。筆者目前負(fù)責(zé)阿里巴巴和阿里云大數(shù)據(jù)領(lǐng)域的部分工作，也接觸很多內(nèi)部和外部的客戶/業(yè)務(wù)。本文試從系統(tǒng)架構(gòu)的角度，就大數(shù)據(jù)架構(gòu)熱點(diǎn)，每條技術(shù)線的發(fā)展脈絡(luò)，以及技術(shù)趨勢和未解問題等方面做一概述。

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

從體系架構(gòu)的角度看，“Shared-Everything”架構(gòu)演進(jìn)、湖倉技術(shù)的一體化融合、云原生帶來的基礎(chǔ)設(shè)計(jì)升級、以及更好的AI支持，是當(dāng)下平臺技術(shù)的四個(gè)熱點(diǎn)。

1.1?系統(tǒng)架構(gòu)角度，平臺整體向Shared-Everything架構(gòu)演進(jìn)

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

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

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

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

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

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

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

1.3?云架構(gòu)角度，云原生與托管化成為主流

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

(圖：snowflake的云原生架構(gòu)）

1.4?計(jì)算模式角度，AI逐漸成為主流，形成BI+AI雙模式

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

02?大數(shù)據(jù)體系的領(lǐng)域架構(gòu)

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

(圖：基于 Shared-Everything 大數(shù)據(jù)體系下的領(lǐng)域架構(gòu))

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

2.1?分布式存儲向多層智能化演進(jìn)

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

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

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

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

第四代，也是當(dāng)下的趨勢，隨存儲云托管化，底層實(shí)現(xiàn)對用戶透明，因此存儲系統(tǒng)有機(jī)會向更復(fù)雜的設(shè)計(jì)方向發(fā)展，從而開始向多層一體化存儲系統(tǒng)演進(jìn)。由單一的基于SATA磁盤的系統(tǒng)，向Mem/SSD+SATA (3X備份)+SATA (1.375X為代表的EC備份)+冰存儲（典型代表AWS Glacier）等多層系統(tǒng)演進(jìn)。如何智能/透明的將數(shù)據(jù)存儲分層，找到成本與性能的Trade-off，是多層存儲系統(tǒng)的關(guān)鍵挑戰(zhàn)。這領(lǐng)域起步不久，開源領(lǐng)域沒有顯著好的產(chǎn)品，最好的水平由幾個(gè)大廠的自研數(shù)倉存儲系統(tǒng)引領(lǐng)。

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

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

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

存儲格式第二代?-?以?Apache?Hudi/Delta?Lake?為代表的近實(shí)時(shí)化存儲格式。存儲格式早期，是大文件列存儲模式，面向吞吐率優(yōu)化（而非latency）。隨實(shí)時(shí)化的趨勢，上述主流的兩個(gè)存儲模式均向支持實(shí)時(shí)化演進(jìn)，Databricks推出了Delta Lake，支持Apache Spark進(jìn)行近實(shí)時(shí)的數(shù)據(jù)ACID操作；Uber推出了Apache Hudi，支持近實(shí)時(shí)的數(shù)據(jù)Upsert能力。盡管二者在細(xì)節(jié)處理上稍有不同（例如Merge on Read or Write），但整體方式都是通過支持增量文件的方式，將數(shù)據(jù)更新的周期降低到更短（避免傳統(tǒng)Parquet/ORC上的針對更新的無差別FullMerge操作），進(jìn)而實(shí)現(xiàn)近實(shí)時(shí)化存儲。因?yàn)榻鼘?shí)時(shí)方向，通常涉及更頻繁的文件Merge以及細(xì)粒度元數(shù)據(jù)支持，接口也更復(fù)雜，Delta/Hudi均不是單純的format、而是一套服務(wù)。?存儲格式再向?qū)崟r(shí)更新支持方向演進(jìn)，會與實(shí)時(shí)索引結(jié)合，不再單單作為文件存儲格式，而是與內(nèi)存結(jié)構(gòu)融合形成整體方案。主流的是實(shí)時(shí)更新實(shí)現(xiàn)是基于LogStructuredMergeTree（幾乎所有的實(shí)時(shí)數(shù)倉）或者Lucene Index（Elastic Search的格式）的方式。

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

以阿里巴巴大數(shù)據(jù)體系為例：

阿里巴巴的大數(shù)據(jù)存儲系統(tǒng)，目前數(shù)萬臺存算一體/存算分離的服務(wù)器，總存儲容量超過5EB，支持阿里集團(tuán)和阿里云的主線大數(shù)據(jù)業(yè)務(wù)。過去5年演進(jìn)脈絡(luò)如下：

2017年文件格式全面升級為基于Apache?Orc的AliOrc格式：并將完整的C++ ORC writer實(shí)現(xiàn)和多個(gè)讀寫性能優(yōu)化貢獻(xiàn)開源社區(qū)。團(tuán)隊(duì)成員在開源社區(qū)影響力包括1位PMC、1位committer和2位contributor，共計(jì)40+提交，2w+行代碼。

2018年，AliOrc重點(diǎn)發(fā)展了智能編碼：通過異步預(yù)讀、高效的字典編碼實(shí)現(xiàn)、動態(tài)內(nèi)存管理、zero-copy內(nèi)存優(yōu)化、浮點(diǎn)數(shù)和decimal類型編碼優(yōu)化、自適應(yīng)編碼等優(yōu)化和改進(jìn)，每個(gè)版本之間性能提升20%。

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

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

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

(圖：阿里大數(shù)據(jù)體系?- MaxCompute 存儲架構(gòu))

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

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

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

數(shù)據(jù)湖和數(shù)倉進(jìn)一步融合，使得存儲不僅僅是文件系統(tǒng)。存儲層做的多厚，與計(jì)算的邊界是什么，仍然是個(gè)關(guān)鍵問題。阿里云給了一個(gè)答案，但仍然需要時(shí)間驗(yàn)證。

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

計(jì)算資源管理是分布式計(jì)算的核心能力，本質(zhì)是解決不同種類的負(fù)載與資源最優(yōu)匹配的問題。在“后紅海時(shí)代”，Google的Borg系統(tǒng)，開源Apache Yarn 依舊是這個(gè)領(lǐng)域的關(guān)鍵產(chǎn)品，K8S在大數(shù)據(jù)計(jì)算調(diào)度方向上仍在起步追趕。阿里巴巴大數(shù)據(jù)體系中，有“伏羲”作為自研的高性能分布式度系統(tǒng)，在全區(qū)域數(shù)據(jù)排布、去中心化調(diào)度、在線離線混合部署、動態(tài)計(jì)算等方面滿足后紅海時(shí)代業(yè)務(wù)場景下的數(shù)據(jù)/資源/計(jì)算調(diào)度需求。

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

• 中心化調(diào)度架構(gòu)：早期的Hadoop1.0的MapReduce、后續(xù)發(fā)展的Borg、和Kubernetes都是中心化設(shè)計(jì)的調(diào)度框架，由單一的調(diào)度器負(fù)責(zé)將任務(wù)指派給集群內(nèi)的機(jī)器。特別的，中心調(diào)度器中，大多數(shù)系統(tǒng)采用兩級調(diào)度框架通過將資源調(diào)度和作業(yè)調(diào)度分開的方式，允許根據(jù)特定的應(yīng)用來定做不同的作業(yè)調(diào)度邏輯，并同時(shí)保留了不同作業(yè)之間共享集群資源的特性。Yarn、Mesos都是這種架構(gòu)。

• 共享狀態(tài)調(diào)度架構(gòu)：半分布式的模式。?應(yīng)用層的每個(gè)調(diào)度器都擁有一份集群狀態(tài)的副本，并且調(diào)度器會獨(dú)立地對集群狀態(tài)副本進(jìn)行更新。如Google的Omega、Microsoft的Apollo，都是這種架構(gòu)。

• 全分布式調(diào)度架構(gòu)：從Sparrow論文開始提出的全分布式架構(gòu)則更加去中心化。調(diào)度器之間沒有任何的協(xié)調(diào)，并且使用很多各自獨(dú)立的調(diào)度器來處理不同的負(fù)載。

• 混合式調(diào)度架構(gòu)：這種架構(gòu)結(jié)合了中心化調(diào)度和共享狀態(tài)的設(shè)計(jì)。一般有兩條調(diào)度路徑，分別為為部分負(fù)載設(shè)計(jì)的分布式調(diào)度，和來處理剩下的負(fù)載的中心式作業(yè)調(diào)度。

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

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

• 數(shù)據(jù)調(diào)度：多機(jī)房跨區(qū)域的系統(tǒng)服務(wù)帶來全域數(shù)據(jù)排布問題，需要最優(yōu)化使用存儲空間與網(wǎng)絡(luò)帶寬。

• 資源調(diào)度：IT基礎(chǔ)設(shè)施整體云化的趨勢，對資源的調(diào)度和隔離都帶來更大的技術(shù)挑戰(zhàn)；同時(shí)物理集群規(guī)模的進(jìn)一步擴(kuò)大，去中心化的調(diào)度架構(gòu)成為趨勢。

• 計(jì)算調(diào)度：經(jīng)典的MapReduce計(jì)算框架逐漸演化到支持動態(tài)調(diào)整、數(shù)據(jù)Shuffle的全局優(yōu)化、充分利用內(nèi)存網(wǎng)絡(luò)等硬件資源的精細(xì)化調(diào)度時(shí)代。

• 單機(jī)調(diào)度：資源高壓力下的SLA保障一直以來是學(xué)術(shù)界和工業(yè)界發(fā)力的方向。Borg等開源探索都假設(shè)在資源沖突時(shí)無條件向在線業(yè)務(wù)傾斜；但是離線業(yè)務(wù)也有強(qiáng)SLA需求，不能隨意犧牲。

以阿里巴巴大數(shù)據(jù)體系為例：

阿里自研的調(diào)度框架就是 Fuxi(伏羲)。Fuxi 系統(tǒng)主要負(fù)責(zé)飛天里的調(diào)度服務(wù)，在系統(tǒng)設(shè)計(jì)上是一個(gè)通用的調(diào)度系統(tǒng)，上層業(yè)務(wù)既包括偏在線的用戶，也包括偏大數(shù)據(jù)計(jì)算的MaxCompute（ODPS），Blink，HoloGres，PAI，ADS，等用戶。

• 數(shù)據(jù)調(diào)度：Fuxi在業(yè)內(nèi)第一次提出了多集群計(jì)算和數(shù)據(jù)調(diào)度的概念，并基于跨集群數(shù)據(jù)緩存策略、跨集群計(jì)算調(diào)度、多集群業(yè)務(wù)排布等技術(shù)實(shí)現(xiàn)了跨地域維度上存儲冗余／計(jì)算均衡／長傳帶寬／性能最優(yōu)之間的最佳平衡。

• 資源調(diào)度：Fuxi近年來已升級到了去中心化資源調(diào)度架構(gòu)，單集群支持10萬服務(wù)器*10萬并發(fā)job的高頻調(diào)度，具備動態(tài)彈性擴(kuò)展能力。基于Fuxi的資源調(diào)度能力，此前在阿里已經(jīng)已大規(guī)模落地應(yīng)用了混部技術(shù)，隨著Fuxi對Kubernetes?等開源生態(tài)的進(jìn)一步支持，統(tǒng)一資源池&統(tǒng)一調(diào)度的能力也使全局資源利用率進(jìn)一步提升。

• 計(jì)算調(diào)度：隨著大數(shù)據(jù)業(yè)務(wù)的飛速增長和新計(jì)算模型的持續(xù)迭代，計(jì)算調(diào)度框架需要融合 AI 能力，以更好的動態(tài)自適應(yīng)性應(yīng)支持千萬量級甚至更高量級的超大規(guī)模計(jì)算。

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

阿里巴巴大數(shù)據(jù)平臺調(diào)度系統(tǒng)的發(fā)展，持續(xù)不變的一個(gè)重點(diǎn)是超大規(guī)模下對性能和成本的極致追求，如混部、跨集群調(diào)度、等；同時(shí)，系統(tǒng)AI能力的融合，通過提升系統(tǒng)自適應(yīng)能力來大幅提升調(diào)度系統(tǒng)的性能。阿里巴巴調(diào)度系統(tǒng)，基于開源體系也在進(jìn)一步加強(qiáng)發(fā)展托管化與云原生的能力，如基于 Kubernetes 對全局資源池的統(tǒng)一調(diào)度研發(fā)，對各類異構(gòu)資源池做統(tǒng)一管理，提升全局資源池的利用率，降低成本。?

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

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

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

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

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

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

• DDL/DML的業(yè)務(wù)邏輯，保障ACID特性，保障數(shù)據(jù)完整性和一致性

• 授權(quán)與鑒權(quán)能力，保證數(shù)據(jù)訪問的安全性

• Meta(元數(shù)據(jù))?的高可用存儲和查詢能力，保障作業(yè)的穩(wěn)定性

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

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

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

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

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

以阿里巴巴大數(shù)據(jù)體系為例：阿里巴巴的大數(shù)據(jù)體系，提供了統(tǒng)一的元數(shù)據(jù)服務(wù)：

（圖：阿里巴巴大數(shù)據(jù)體系下的統(tǒng)一元數(shù)據(jù)系統(tǒng)）

以阿里巴巴的大數(shù)據(jù)體系為例，對比第一代與第二代元數(shù)據(jù)系統(tǒng)：

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

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

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

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

元數(shù)據(jù)模型開始突破關(guān)系范式的結(jié)構(gòu)化模型，提供更豐富的元數(shù)據(jù)模型，支持標(biāo)簽，分類以及自定義類型和元數(shù)據(jù)格式的表達(dá)能力，支持AI計(jì)算引擎等等。

2.4?多種計(jì)算引擎并存

計(jì)算層是整個(gè)大數(shù)據(jù)計(jì)算生態(tài)的核心，是數(shù)據(jù)到價(jià)值轉(zhuǎn)換的關(guān)鍵。?大數(shù)據(jù)場景中有各類計(jì)算形態(tài)，如批、流、交互式、多模、圖、搜索、等多種計(jì)算模式。?

大數(shù)據(jù)領(lǐng)域發(fā)展了20年，在“后紅海”時(shí)代，主流計(jì)算模式已經(jīng)基本固定，形成批處理、流處理、交互式、機(jī)器學(xué)習(xí)四個(gè)核心方向，以及一些小眾/專門場景的計(jì)算模式。在開源社區(qū)領(lǐng)域，經(jīng)過百舸爭流式的競爭和沉淀，也基本形成了主流的社區(qū)形態(tài)。

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

整體看，計(jì)算引擎的發(fā)展將會在存儲計(jì)算分離架構(gòu)基礎(chǔ)上，以一套數(shù)據(jù)支持多種計(jì)算模式：?

• 存儲計(jì)算分離，以及隨后的1+N架構(gòu)（即一套數(shù)據(jù)之上支持多種計(jì)算模式）

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

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

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

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

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

• 其他小眾計(jì)算模式?-?因滿足不同細(xì)分場景，還有包括圖計(jì)算，文本檢索等引擎。圖領(lǐng)域細(xì)分成三個(gè)子場景：圖計(jì)算、圖分析和圖學(xué)習(xí)。分布式圖分析場景目前仍未有完善的方案，圖語言也在發(fā)展期，未形成統(tǒng)一標(biāo)準(zhǔn)。文本檢索領(lǐng)域，主要基于倒排索引技術(shù)，開源生態(tài)Elastic Search成為生態(tài)主流。限于篇幅，這部分不再做更細(xì)節(jié)的介紹。

以阿里巴巴大數(shù)據(jù)體系為例：

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

（圖-阿里巴巴大數(shù)據(jù)體系，多計(jì)算模式支持）

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

在 MaxCompute 的作業(yè)中，有90%以上的作業(yè)是 SQL 作業(yè)，SQL 引擎的能力是 MaxCompute 的核心競爭力之一。SQL 引擎的3個(gè)模塊?-?編譯器、運(yùn)行時(shí)、和優(yōu)化器，在設(shè)計(jì)實(shí)現(xiàn)上做的優(yōu)化主要有：

• 編譯器:?對 SQL 標(biāo)準(zhǔn)有友好支持，支持100% TPC-DS 語法；具備強(qiáng)大的錯(cuò)誤恢復(fù)能力。

• 運(yùn)行時(shí):?基于LLVM優(yōu)化代碼生產(chǎn)，支持列式處理與豐富的關(guān)系算符；基于 CPP 的運(yùn)行時(shí)具有更高效率。

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

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

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

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

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

• 流處理引擎?-?實(shí)時(shí)計(jì)算Flink版

Apache Flink是目前業(yè)界最為流行和成熟的開源流計(jì)算技術(shù)，阿里云選擇圍繞Apache Flink技術(shù)打造了實(shí)時(shí)計(jì)算Flink版，并在集團(tuán)內(nèi)部有超大規(guī)模的驗(yàn)證，支持阿里集團(tuán)所有實(shí)時(shí)計(jì)算數(shù)據(jù)業(yè)務(wù)。Flink 社區(qū)在 2020?年持續(xù)繁榮，蟬聯(lián)最活躍的 Apache 項(xiàng)目；Flink 也成為了事實(shí)上的國內(nèi)外實(shí)時(shí)計(jì)算標(biāo)準(zhǔn)。

(圖：阿里巴巴大數(shù)據(jù)體系?-?實(shí)時(shí)計(jì)算Flink版產(chǎn)品架構(gòu)）

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

阿里巴巴大數(shù)據(jù)體系下，有多個(gè)自研的機(jī)器學(xué)習(xí)和深度學(xué)習(xí)引擎，?其中主要有?PAI?Tensorflow：是 PAI 機(jī)器學(xué)習(xí)平臺深度定制的面向全集團(tuán)的深度學(xué)習(xí)計(jì)算引擎。在數(shù)據(jù)處理、算力如全局異構(gòu)計(jì)算、模型優(yōu)化層面做了大量創(chuàng)新和優(yōu)化。?

其他的機(jī)器學(xué)習(xí)和深度學(xué)習(xí)框架和引擎還有：

• X-DeepLearning：工業(yè)級深度學(xué)習(xí)框架，主要面向大規(guī)模廣告/推薦/搜索場景。

• MNN：一款輕量級深度學(xué)習(xí)端側(cè)推理引擎，主攻解決深度神經(jīng)網(wǎng)絡(luò)模型在端側(cè)推理運(yùn)行問題，目前已開源。

• xNN：螞蟻金服研發(fā)的端側(cè)機(jī)器學(xué)習(xí)引擎，致力于解決機(jī)器學(xué)習(xí)模型在以支付寶為代表的超級App以及IOT設(shè)備中部署所面臨的技術(shù)難題。

• ALPS：螞蟻的機(jī)器學(xué)習(xí)算法框架，目標(biāo)是為螞蟻的算法及業(yè)務(wù)同學(xué)提供一個(gè)高性能、易用的機(jī)器學(xué)習(xí)算法研發(fā)框架，并在此基礎(chǔ)上沉淀螞蟻具有金融特色的算法庫（涵蓋CV/NLP/ML等方向）和解決方案。

• 圖計(jì)算引擎?-?Graph?Compute

圖計(jì)算服務(wù)（Graph Compute）支持圖數(shù)據(jù)建模、導(dǎo)入和修改、支持Apache TinkerPop標(biāo)準(zhǔn)Gremlin語言進(jìn)行圖查詢，并支持常見圖分析算法，具有數(shù)據(jù)加載快、規(guī)模可擴(kuò)展、查詢延時(shí)低（毫秒級）和離在線混合引擎與共享存儲等優(yōu)勢，幫助用戶構(gòu)建海量關(guān)系數(shù)據(jù)的圖應(yīng)用服務(wù)。

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

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

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

IoT領(lǐng)域興起?-?隨設(shè)備的智能化和5/6G網(wǎng)絡(luò)興起，面向IoT的分析會逐漸火熱。計(jì)算形態(tài)可能會發(fā)生變化，從云為中心演進(jìn)到云邊端一體。

大數(shù)據(jù)平臺/引擎整體云原生化?-?新興的引擎均基于云的架構(gòu)重新設(shè)計(jì)，充分利用云的優(yōu)勢，降低復(fù)雜度的同時(shí)提供更多價(jià)值。隨云原生化，Shared-Everything 架構(gòu)成為未來的演進(jìn)趨勢。

Learned?based?優(yōu)化?-?機(jī)器學(xué)習(xí)技術(shù)會充分融入大數(shù)據(jù)系統(tǒng)（甚至任何系統(tǒng)）的設(shè)計(jì)，優(yōu)化器、調(diào)度系統(tǒng)、存儲格式、Index/MV設(shè)計(jì)等多個(gè)領(lǐng)域均會大量使用AI的技術(shù)來做優(yōu)化。例如Cost based Optimization中的基于Statistics的Cost推導(dǎo)，會大量被Learn based Statistics取代。

2.5?框架與接入層

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

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

前端API接入-是系統(tǒng)對外的接口，通常提供HTTP協(xié)議接入，并具有認(rèn)證、流控能力。部分系統(tǒng)提供Web接入能力。

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

(圖：框架與接入層)

設(shè)計(jì)考慮：

服務(wù)于背后的主系統(tǒng)，功能隨后臺變化而變化，并沒有“一定之規(guī)”。

管控層直接決定系統(tǒng)的可用性，因此也需要完善的容災(zāi)能力，無狀態(tài)的服務(wù)組件通常依托部署系統(tǒng)實(shí)現(xiàn)容災(zāi)，對于有狀態(tài)服務(wù)，通常將狀態(tài)存儲在元數(shù)據(jù)系統(tǒng)或者底層存儲系統(tǒng)中。

很多獨(dú)立引擎，特別是開源類，接入和管控層通常比較簡單。對于企業(yè)級服務(wù)來說，很多額外的功能都在本服務(wù)擴(kuò)展，也體現(xiàn)企業(yè)級服務(wù)的價(jià)值。例如：監(jiān)控/運(yùn)維能力、審計(jì)日志、計(jì)量計(jì)費(fèi)、對計(jì)算系統(tǒng)熱切換的控制等。甚至包括自動化作業(yè)調(diào)優(yōu)等高級功能（例如SparkCruise，來自微軟Azure托管版的基于歷史信息的自動作業(yè)調(diào)優(yōu)子系統(tǒng)）。

當(dāng)用戶選用多個(gè)系統(tǒng)組合搭建一套大數(shù)據(jù)平臺，不同系統(tǒng)都會有自己的管控層，造成服務(wù)的冗余和各系統(tǒng)的割裂。因此很多云平臺提供商，會致力于抽象統(tǒng)一規(guī)范和公共子模塊，例如統(tǒng)一認(rèn)證協(xié)議/服務(wù)（Kerberos等）、統(tǒng)一權(quán)限管理，Terraform API標(biāo)準(zhǔn)等。

以阿里巴巴大數(shù)據(jù)體系為例：

阿里巴巴的大數(shù)據(jù)平臺（MaxCompute為主）完整的實(shí)現(xiàn)了上圖中所有的功能。限于篇幅展開兩個(gè)特色功能：

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

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

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

托管化?-?框架與接入層是企業(yè)級能力增強(qiáng)的關(guān)鍵一層，隨托管化成為大趨勢，這一層會有大量的企業(yè)級能力加入，會逐步成為關(guān)鍵層。

2.6?數(shù)據(jù)開發(fā)與治理平臺

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

讓大數(shù)據(jù)計(jì)算平臺真正能夠服務(wù)于業(yè)務(wù)，還需要一系列數(shù)據(jù)研發(fā)和數(shù)據(jù)治理利器，以幫助數(shù)據(jù)工作者低成本和高效地獲取數(shù)據(jù)洞察，實(shí)現(xiàn)業(yè)務(wù)價(jià)值：

• 數(shù)據(jù)集成：支持關(guān)系型數(shù)據(jù)庫、大型數(shù)倉、NoSQL數(shù)據(jù)庫、非結(jié)構(gòu)化數(shù)據(jù)、消息隊(duì)列等數(shù)據(jù)源之間的數(shù)據(jù)同步，包含批量數(shù)據(jù)同步、實(shí)時(shí)數(shù)據(jù)同步、整庫數(shù)據(jù)遷移等，解決云上、跨云、跨地域以及本地IDC機(jī)房等復(fù)雜網(wǎng)絡(luò)環(huán)境之間的數(shù)據(jù)同步問題。

• 元數(shù)據(jù)服務(wù)：支持不同數(shù)據(jù)源的元數(shù)據(jù)發(fā)現(xiàn)與元數(shù)據(jù)歸集，并構(gòu)建數(shù)據(jù)目錄和數(shù)據(jù)血緣服務(wù)，同時(shí)為上層數(shù)據(jù)開發(fā)與數(shù)據(jù)治理提供元數(shù)據(jù)服務(wù)。

• 數(shù)據(jù)開發(fā)：提供在線數(shù)據(jù)開發(fā)IDE，支持多種計(jì)算存儲引擎，提供批計(jì)算、實(shí)時(shí)計(jì)算、交互式分析、以及機(jī)器學(xué)習(xí)等一體化數(shù)據(jù)開發(fā)服務(wù)，為各種技術(shù)/非技術(shù)人員提供高效極致的ETL/ELT研發(fā)體驗(yàn)。

• 調(diào)度系統(tǒng)：支持大規(guī)模、高并發(fā)、高穩(wěn)定性的細(xì)粒度周期性任務(wù)調(diào)度，支持流處理、批處理與AI一體化數(shù)據(jù)任務(wù)編排，保障數(shù)據(jù)生產(chǎn)的時(shí)效性、穩(wěn)定性。

• 數(shù)據(jù)治理：提供數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)質(zhì)量控制、數(shù)據(jù)安全管理、監(jiān)控告警、數(shù)據(jù)標(biāo)準(zhǔn)、成本優(yōu)化等服務(wù)，保障數(shù)據(jù)倉庫能夠規(guī)范、健康、合規(guī)和可持續(xù)發(fā)展。

• 數(shù)據(jù)服務(wù)：提供快速將數(shù)據(jù)表生成數(shù)據(jù)API服務(wù)的能力，連接數(shù)據(jù)倉庫與數(shù)據(jù)應(yīng)用的“最后一公里”，實(shí)現(xiàn)靈活可控的數(shù)據(jù)共享交換服務(wù)。

以阿里巴巴大數(shù)據(jù)體系為例：

在阿里大數(shù)據(jù)體系中， DataWorks作為大數(shù)據(jù)平臺操作系統(tǒng)，歷經(jīng)十二年發(fā)展，形成了涵蓋數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、數(shù)據(jù)治理、數(shù)據(jù)服務(wù)的一站式大數(shù)據(jù)開發(fā)與治理平臺，每天穩(wěn)定調(diào)度上千萬數(shù)據(jù)任務(wù)，支撐了阿里集團(tuán)99%的數(shù)據(jù)業(yè)務(wù)。

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

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

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

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

開發(fā)即治理：過去我們大多習(xí)慣于先開發(fā)后治理，最終則讓數(shù)據(jù)治理成為了負(fù)擔(dān)。隨著數(shù)據(jù)規(guī)模的不斷增長、數(shù)據(jù)安全與隱私保護(hù)越來越受關(guān)注、數(shù)據(jù)業(yè)務(wù)化的持續(xù)發(fā)展，將不再允許數(shù)據(jù)治理僅僅是事后行為，數(shù)據(jù)治理將會融合到覆蓋事前、事中和事后的大數(shù)據(jù)生產(chǎn)與應(yīng)用的全鏈路中，數(shù)據(jù)開發(fā)與治理將協(xié)同并進(jìn)。

2.7?智能化

隨著大數(shù)據(jù)平臺及其所承載業(yè)務(wù)的發(fā)展，我們也面臨著新的挑戰(zhàn)：

• 10PB到EB級數(shù)據(jù)和百萬級別作業(yè)規(guī)模，已經(jīng)成為主流，海量數(shù)據(jù)和作業(yè)靠人很難管理和。傳統(tǒng)的DBA模式或數(shù)據(jù)中臺團(tuán)隊(duì)不再勝任。

• 多種數(shù)據(jù)融在一起，人無法在海量規(guī)模上理解數(shù)據(jù)的所有價(jià)值。

• 大數(shù)據(jù)系統(tǒng)經(jīng)過多年發(fā)展，如果需要實(shí)現(xiàn)“躍遷”式的進(jìn)步，需要體系結(jié)構(gòu)層面的改造。

因此AI for System的概念興起，基于AI的能力做系統(tǒng)的優(yōu)化，在數(shù)倉領(lǐng)域我們可以稱之為自動數(shù)倉（Auto Data Warehouse）。數(shù)據(jù)湖領(lǐng)域也可以有更多的自動化，但因?yàn)閿?shù)倉方向的數(shù)據(jù)管理/調(diào)優(yōu)能力發(fā)展更早，這個(gè)領(lǐng)域更領(lǐng)先。下圖是一個(gè)基本的自動數(shù)倉能力分類。

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

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

• L1級：運(yùn)維能力白屏化和工具化。目前絕大多數(shù)系統(tǒng)都可以做到這個(gè)層次。

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

• L3級：中臺能力的自動化，輔助數(shù)據(jù)關(guān)聯(lián)與理解，建模與調(diào)優(yōu)。包括數(shù)據(jù)血緣，相似度，冗余度，使用情況與自動評分。輔助標(biāo)簽系統(tǒng)，輔助中臺建設(shè)。市面上的很多數(shù)據(jù)中臺產(chǎn)品聚焦在這一層。

• L4級：系統(tǒng)具備自學(xué)習(xí)能力。基于歷史信息的性能調(diào)優(yōu)（自動Parallelism，自動冷熱數(shù)據(jù)分層等等），資源與優(yōu)先級的動態(tài)調(diào)配，自適應(yīng)的監(jiān)控和報(bào)警能力，自動數(shù)據(jù)異常識別。目前大多數(shù)系統(tǒng)的能力邊界在此，有巨大的發(fā)揮空間。

• L5級：自動化建模。包含更高階的數(shù)據(jù)理解，能夠自動發(fā)現(xiàn)數(shù)據(jù)的內(nèi)在關(guān)聯(lián)與冗余度，根據(jù)數(shù)據(jù)訪問情況，自動維護(hù)數(shù)倉體系。

（圖：自動駕駛/數(shù)倉能力分級）

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

以阿里巴巴大數(shù)據(jù)體系為例，整個(gè)領(lǐng)域都是新興方向，限于篇幅，只展開介紹下面三個(gè)方面:

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

Online：是個(gè)在線系統(tǒng)，用于查找是否存在相應(yīng)的hbo optimization 規(guī)則，如果命中，則按照規(guī)則進(jìn)行。這個(gè)規(guī)則可以是資源分配優(yōu)化，可以是物理執(zhí)行計(jì)劃的并發(fā)度，也可以是優(yōu)化器里面的Optimization；

Offline：獲取任務(wù)的歷史執(zhí)行記錄，按照一定的策略生成hbo optimization 規(guī)則；

基于學(xué)習(xí)的智能跨域調(diào)度?-?本質(zhì)上也是基于歷史信息的的優(yōu)化過程，但更聚焦于跨數(shù)據(jù)中心的數(shù)據(jù)排布和調(diào)度帶寬優(yōu)化。通過精細(xì)化的數(shù)據(jù)訪問統(tǒng)計(jì)，做更優(yōu)的數(shù)據(jù)規(guī)劃，并持續(xù)根據(jù)訪問調(diào)優(yōu)。具體算法和架構(gòu)可以參考Yugong@VLDB 2019

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

智能化作為大數(shù)據(jù)體系的發(fā)展趨勢之一，上述內(nèi)容即為我們對這個(gè)子領(lǐng)域的未來展望。

2.8?安全與隱私保護(hù)

隨著大數(shù)據(jù)的發(fā)展，數(shù)據(jù)在多方數(shù)據(jù)融合場景下能發(fā)揮更大的價(jià)值。然而在這種場景下用戶的隱私保護(hù)以及數(shù)據(jù)的合規(guī)問題成為了嚴(yán)重的問題。問題的本質(zhì)是數(shù)據(jù)的開放性與使用安全性的平衡。安全能力，包括數(shù)據(jù)安全/隱私保護(hù)能力，是大數(shù)據(jù)體系中的重要能力基線之一。

信息的可用性、信息的完整性、以及信息的保密性是信息安全的三個(gè)基本要素。我們將企業(yè)級大數(shù)據(jù)中臺要面臨的安全風(fēng)險(xiǎn), 根據(jù)其所涉及的系統(tǒng)及技術(shù)領(lǐng)域的不同, 分為三個(gè)層次。

最基礎(chǔ)的層次是數(shù)據(jù)中心的物理安全與網(wǎng)絡(luò)安全，數(shù)據(jù)中心是構(gòu)建大數(shù)據(jù)中臺的基礎(chǔ)，數(shù)據(jù)中心自身安全性和網(wǎng)絡(luò)接入安全性直接影響到企業(yè)大數(shù)據(jù)中臺的可用性。主要包括數(shù)據(jù)中心保障設(shè)施、數(shù)據(jù)中心安全管控、數(shù)據(jù)中心的網(wǎng)絡(luò)安全等幾個(gè)維度的建設(shè)。當(dāng)云架構(gòu)成為主流，物理安全方面通常由云廠商承擔(dān)。

在這之上是企業(yè)大數(shù)據(jù)平臺的系統(tǒng)安全，由大數(shù)據(jù)平臺內(nèi)部的多個(gè)安全子系統(tǒng)構(gòu)成，如訪問控制、應(yīng)用程序隔離、平臺可信、風(fēng)控和審計(jì)等子系統(tǒng)。這些子系統(tǒng)共同保障大數(shù)據(jù)平臺的完整性。

最上層是數(shù)據(jù)應(yīng)用安全，貼近于用戶的應(yīng)用場景。通過在這一層提供豐富多樣的數(shù)據(jù)安全產(chǎn)品，大數(shù)據(jù)中臺為用戶應(yīng)用數(shù)據(jù)的各類業(yè)務(wù)場景提供切實(shí)可靠的數(shù)據(jù)安全能力。

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

以阿里巴巴大數(shù)據(jù)體系為例：

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

（圖：阿里巴巴大數(shù)據(jù)體系的安全能力建設(shè)）

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

隨數(shù)據(jù)被認(rèn)知為資產(chǎn)，數(shù)據(jù)變現(xiàn)成為一個(gè)熱門話題，它背后的技術(shù)：數(shù)據(jù)安全共享和多方安全計(jì)算也成為熱點(diǎn)方向。總體看，數(shù)據(jù)變現(xiàn)（也稱為數(shù)據(jù)安全共享），有兩種典型場景：一方數(shù)據(jù)對外售賣，多方數(shù)據(jù)交互計(jì)算。

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

• 另外，這個(gè)領(lǐng)域的一個(gè)研究方向是基于差分隱私（Differential Privacy）加密的密態(tài)計(jì)算（例如 DPSAaS@Sigmod2019）。

• 多方數(shù)據(jù)交互計(jì)算方案，通常基于聯(lián)邦學(xué)習(xí)技術(shù)（Federated Learning）。

2.9?運(yùn)維

運(yùn)維是伴隨著任何一家公司的產(chǎn)品，在整個(gè)產(chǎn)品生命周期中一直是存在的。運(yùn)維負(fù)責(zé)公司產(chǎn)品業(yè)務(wù)的正常運(yùn)轉(zhuǎn)，處理緊急故障響應(yīng)，保障業(yè)務(wù)連續(xù)性，產(chǎn)品可用性改進(jìn)，性能&效率優(yōu)化，變更管理，監(jiān)控，容量規(guī)劃與管理等相關(guān)工作：這些是運(yùn)維核心的定義所在。

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

大數(shù)據(jù)運(yùn)維業(yè)務(wù)圍繞穩(wěn)定性（質(zhì)量）、成本及效率主要關(guān)注如下：

• 針對日常業(yè)務(wù)穩(wěn)定性可以分為日常事件管理、問題管理、變更管理及發(fā)布管理的標(biāo)準(zhǔn)化ITIL流程；

• 針對成本管理包含了從資源預(yù)算、資源采購、預(yù)算執(zhí)行、財(cái)務(wù)賬單、過保替換等圍繞資源生命周期管理的相關(guān)事項(xiàng)；

• 針對效率包含了如何開發(fā)一體化的運(yùn)維平臺以高效支撐業(yè)務(wù)監(jiān)控、服務(wù)管理、系統(tǒng)管理、應(yīng)急/安全管理等。

以阿里巴巴大數(shù)據(jù)體系為例：

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

• 運(yùn)維IaaS層：映射基礎(chǔ)設(shè)施的運(yùn)維層，為上層運(yùn)維平臺及業(yè)務(wù)提供管控能力；

• 運(yùn)維PaaS層：面向運(yùn)維領(lǐng)域功能的服務(wù)層，比如流程編排、作業(yè)調(diào)度、配置管理、運(yùn)維分析服務(wù)、審批/通知、腳本/命令通道服務(wù)等；

• 運(yùn)維SaaS層：面向具體大數(shù)據(jù)平臺業(yè)務(wù)的定制化智能運(yùn)維運(yùn)營應(yīng)用，跟隨所運(yùn)維對象系統(tǒng)一起向前迭代發(fā)展的運(yùn)營站點(diǎn)。

在垂直運(yùn)維體系之上，運(yùn)維業(yè)務(wù)也可以劃分為SRE大中臺及SRE小前臺：“大中臺”強(qiáng)調(diào)運(yùn)維資源整合、運(yùn)維能力沉淀的平臺體系，為前臺運(yùn)維業(yè)務(wù)開展提供可快速復(fù)用的底層技術(shù)、數(shù)據(jù)等資源和能力；“小前臺”就是貼近最終運(yùn)維所服務(wù)對象的相關(guān)運(yùn)維業(yè)務(wù)，基于中臺整合的數(shù)據(jù)和產(chǎn)品技術(shù)能力，對各前臺業(yè)務(wù)形成強(qiáng)力支撐，快速試錯(cuò)，快速行動。

大數(shù)據(jù)體系發(fā)展至今，服務(wù)器規(guī)模已發(fā)展到數(shù)萬、數(shù)十萬、甚至百萬臺規(guī)模。隨著基礎(chǔ)設(shè)施規(guī)模的發(fā)展，運(yùn)維系統(tǒng)也經(jīng)歷了一個(gè)從人工、到平臺化、再到智能化的自然的演進(jìn)過程，運(yùn)維的演進(jìn)需要能支撐起大數(shù)據(jù)基礎(chǔ)設(shè)施的高復(fù)雜、高安全、高可靠、高效率要求。

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

產(chǎn)品化：運(yùn)維的產(chǎn)品化，本周上是指讓各類運(yùn)維動作的更標(biāo)準(zhǔn)，更可控。產(chǎn)品化是把對本身服務(wù)客戶的產(chǎn)品的運(yùn)維需求、和運(yùn)維產(chǎn)品本身的需求、集成到產(chǎn)品功能上，并迭代傳承。同時(shí)通過這些標(biāo)準(zhǔn)化的動作，逐步把底層的一些運(yùn)維數(shù)據(jù)統(tǒng)一起來。

數(shù)據(jù)化：?隨著產(chǎn)品規(guī)模的擴(kuò)大以及系統(tǒng)的復(fù)雜多產(chǎn)品依賴，在整個(gè)過程中會產(chǎn)生大量的系統(tǒng)數(shù)據(jù)，隨之?dāng)?shù)據(jù)化能力會凸顯的非常重要。數(shù)據(jù)的收集存儲，計(jì)算處理，運(yùn)維數(shù)倉建設(shè)，數(shù)據(jù)分層，實(shí)時(shí)性，運(yùn)營分析等相關(guān)數(shù)據(jù)化能力會逐步成為必須基本能力。重點(diǎn)需要關(guān)注運(yùn)維數(shù)據(jù)的工程，集成，安全和質(zhì)量。?

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

03?大數(shù)據(jù)體系未來演進(jìn)的4大技術(shù)趨勢

趨勢1：近實(shí)時(shí)架構(gòu)興起

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

趨勢2：數(shù)據(jù)共享與隱私保護(hù)成為熱點(diǎn)

數(shù)據(jù)成為資產(chǎn)，開始具備可變現(xiàn)和可交易的能力。可保護(hù)隱私的數(shù)據(jù)交換/共享能力成為強(qiáng)勁的需求。基于Differential Privacy的數(shù)據(jù)編碼交易，以及基于Federated Learning的多方面安全計(jì)算是該領(lǐng)域的熱點(diǎn)技術(shù)。

趨勢3：IoT成為新熱點(diǎn)

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

趨勢4：AI for System

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

04?大數(shù)據(jù)體系內(nèi)待探索的3個(gè)疑問

大數(shù)據(jù)技術(shù)收斂，并進(jìn)入普惠和業(yè)務(wù)大規(guī)模應(yīng)用的階段，滲透到各行各業(yè)。超大規(guī)模數(shù)據(jù)計(jì)算和基于數(shù)據(jù)的智能決策，已經(jīng)是企業(yè)業(yè)務(wù)數(shù)據(jù)化運(yùn)營的重要基礎(chǔ)。不過，在后紅海時(shí)代，大數(shù)據(jù)體系發(fā)展有3個(gè)疑問值得我們關(guān)注：

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

隨大數(shù)據(jù)系統(tǒng)整體架構(gòu)的穩(wěn)定，各種引擎的發(fā)展逐漸進(jìn)入收斂期，批計(jì)算、流計(jì)算、交互分析、機(jī)器學(xué)習(xí)收斂成為四個(gè)核心計(jì)算模式，每個(gè)模式均有主線開源引擎成為事實(shí)標(biāo)準(zhǔn)。

過去3年沒有再誕生主流的開源計(jì)算引擎（每個(gè)模式中，引擎的發(fā)展脈絡(luò)詳見第二章節(jié)）。同時(shí)，引擎邊界開始變得模糊，HTAP等Hybrid模式成為探索的新趨勢，計(jì)算模式是否進(jìn)一步收斂，收斂的終態(tài)會是什么樣子，是個(gè)熱點(diǎn)話題。

疑問2:關(guān)系模型之外，是否會發(fā)展出其他主流計(jì)算范式？?

大數(shù)據(jù)領(lǐng)域整體還是以二維關(guān)系表達(dá)和計(jì)算為基礎(chǔ)（Relational DB的理論基礎(chǔ)），是否有新的計(jì)算范式在數(shù)據(jù)庫領(lǐng)域也持續(xù)討論了多年，盡管有包括圖計(jì)算在內(nèi)的其他計(jì)算范式，但過去的40年，關(guān)系運(yùn)算持續(xù)成為主流。

其中核心原因，筆者個(gè)人的判斷是二維關(guān)系表達(dá)更貼近人的理解能力，或者說高維表達(dá)和處理很難被人理解和處理。但關(guān)系表達(dá)有顯著的短板，它無法處理半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)（比如音視圖類的數(shù)據(jù)）。

近幾年興起的深度學(xué)習(xí)技術(shù)，帶來了一種全新的處理方式，海量正交化的高維特征作為輸入，由深度神經(jīng)網(wǎng)絡(luò)理解數(shù)據(jù)，以模型作為產(chǎn)出的引擎計(jì)算出結(jié)果。這種方式避免人腦對數(shù)據(jù)處理的局限性，可以在更高維度更復(fù)雜數(shù)據(jù)上做處理，給未來提供了一種新的處理方式的可能性。

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

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

開源軟件是大數(shù)據(jù)發(fā)展的關(guān)鍵推手，助力大數(shù)據(jù)系統(tǒng)的普及化。但面臨如下挑戰(zhàn)：開源系統(tǒng)的軟件交付模式，也給很多客戶帶來高維護(hù)成本。

以一個(gè)典型的腰部互聯(lián)網(wǎng)企業(yè)為例，一個(gè)100臺規(guī)模的大數(shù)據(jù)平臺硬件投入大約200萬/年，同時(shí)需要維持一個(gè)3-5人的研發(fā)/運(yùn)維團(tuán)隊(duì)，年成本200-300萬/年。綜合TCO高達(dá)450萬/年。

這也是為什么像Snowflake這樣的自研企業(yè)級產(chǎn)品流行的原因，大多數(shù)不具備深度研發(fā)能力的公司，愿意為更豐富的企業(yè)級能力和更低的綜合TCO買單；大數(shù)據(jù)系統(tǒng)開發(fā)進(jìn)入深水區(qū)，投資巨大，需要高商業(yè)利潤才能支持。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。