大数据体系的4个热点，4个趋势和3个疑问
作者 | 阿里云計(jì)算平臺(tái)事業(yè)部??? ??
如今，大數(shù)據(jù)技術(shù)已進(jìn)入“后紅海”時(shí)代，成了“水電煤”一樣可以普惠人人的技術(shù)。同時(shí)，新領(lǐng)域仍在不斷演進(jìn)迭代。
本文的上篇 “Snowflake如日中天是否代表Hadoop已死？大數(shù)據(jù)體系到底是什么？”，闡述了后紅海時(shí)代下大數(shù)據(jù)體系的演進(jìn)熱點(diǎn)是什么，以及大數(shù)據(jù)體系3個(gè)子領(lǐng)域的技術(shù)解讀，包括多層智能化演進(jìn)的分布式存儲(chǔ)系統(tǒng)、統(tǒng)一框架和算法多元化發(fā)展的分布式調(diào)度系統(tǒng)，和統(tǒng)一化發(fā)展的元數(shù)據(jù)服務(wù)。
本文作為下篇，繼續(xù)對計(jì)算引擎、框架與接入、數(shù)據(jù)開發(fā)與治理、智能化、安全與隱私保護(hù)、運(yùn)維6個(gè)子領(lǐng)域做技術(shù)解讀，概述各領(lǐng)域的演進(jìn)歷史、背后驅(qū)動(dòng)力、以及發(fā)展方向，并希望和大家一起探討大數(shù)據(jù)體系未來演進(jìn)的技術(shù)趨勢，以及仍待探索的未解問題。
大數(shù)據(jù)體系的領(lǐng)域架構(gòu)
在Shared-Everything架構(gòu)角度下，大數(shù)據(jù)體系子領(lǐng)域劃分成9個(gè)領(lǐng)域：
注：這張圖上的前3個(gè)子領(lǐng)域：分布式存儲(chǔ)、分布式調(diào)度、元數(shù)據(jù)服務(wù)已在上篇完成，本文直接從第4個(gè)子領(lǐng)域開始分享。
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ā)展將會(huì)在存儲(chǔ)計(jì)算分離架構(gòu)基礎(chǔ)上，以一套數(shù)據(jù)支持多種計(jì)算模式：
（1）存儲(chǔ)計(jì)算分離，以及隨后的1+N架構(gòu)（即一套數(shù)據(jù)之上支持多種計(jì)算模式）
（2）批處理——是大數(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)镠ive2.0是嚴(yán)格BSP模式，每次數(shù)據(jù)交互均需要落盤，犧牲了延遲和性能。Spark抓住內(nèi)存增長的趨勢，推出基于ResilientDistributed 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í)方向的興起（以開源ApacheDelta/Hudi為代表），批處理數(shù)據(jù)從接入到計(jì)算的延遲得的顯著的降低，給用戶提供了一種成本/延遲的另一個(gè)平衡點(diǎn)。
（3）交互式分析——通常是面向分析場景（人驅(qū)動(dòng)，中小規(guī)模輸入數(shù)據(jù)/小規(guī)模輸出數(shù)據(jù)），在中小規(guī)模cook好的數(shù)據(jù)上（通常是批處理之后的數(shù)據(jù)），基于更快的存儲(chǔ)、更多的內(nèi)存（bufferpool）、更實(shí)時(shí)的數(shù)據(jù)更新（通常是基于LSMTree的方案），也采用更多的OLAP優(yōu)化技術(shù)（例如PlanCache）。優(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è)更快的BIEngine）的方式形成一體化。從細(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選擇雙引擎的原因。
（4）流處理——采用ContinuousProcessing的計(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-OnceVS Atleast-Once）、LateEvent處理方式、以及Window函數(shù)支持是不同流計(jì)算引擎設(shè)計(jì)的取舍。開源領(lǐng)域Spark Streaming、Apex、Heron和Flink經(jīng)過競爭，Flink因具備完整Exact-Once語義保證和完善的LateEvent處理能力，最終獲得社區(qū)廣泛的關(guān)注。
（5） 機(jī)器學(xué)習(xí)(ML)/深度學(xué)習(xí)(DL)——以統(tǒng)計(jì)為基礎(chǔ)理論的傳統(tǒng)機(jī)器學(xué)習(xí)有豐富的生態(tài)，包括Python系、Matlab等等。大數(shù)據(jù)領(lǐng)域SparkMLib以一套數(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）。
（6）其他小眾計(jì)算模式——因滿足不同細(xì)分場景，還有包括圖計(jì)算，文本檢索等引擎。圖領(lǐng)域細(xì)分成三個(gè)子場景：圖計(jì)算、圖分析和圖學(xué)習(xí)。分布式圖分析場景目前仍未有完善的方案，圖語言也在發(fā)展期，未形成統(tǒng)一標(biāo)準(zhǔn)。文本檢索領(lǐng)域，主要基于倒排索引技術(shù)，開源生態(tài)ElasticSearch成為生態(tài)主流。限于篇幅，這部分不再做更細(xì)節(jié)的介紹。
展望未來，我們看到可能的發(fā)展方向/趨勢主要有：
近實(shí)時(shí)化成為主流：近實(shí)時(shí)化方案，是在分鐘級(jí)的延遲上做到數(shù)據(jù)的一致性，幾乎不用依賴大量內(nèi)存的BTree系統(tǒng)和常駐的服務(wù)，將成本降低到幾乎和離線一致，在延遲和成本間找到一個(gè)新的平衡，會(huì)逐步取代部分離線的作業(yè)。
IoT領(lǐng)域興起：隨設(shè)備的智能化和5/6G網(wǎng)絡(luò)興起，面向IoT的分析會(huì)逐漸火熱。計(jì)算形態(tài)可能會(huì)發(fā)生變化，從云為中心演進(jìn)到云邊端一體。
大數(shù)據(jù)平臺(tái)/引擎整體云原生化：新興的引擎均基于云的架構(gòu)重新設(shè)計(jì)，充分利用云的優(yōu)勢，降低復(fù)雜度的同時(shí)提供更多價(jià)值。隨云原生化，Shared-Everything架構(gòu)成為未來的演進(jìn)趨勢。
Learned based優(yōu)化：機(jī)器學(xué)習(xí)技術(shù)會(huì)充分融入大數(shù)據(jù)系統(tǒng)（甚至任何系統(tǒng)）的設(shè)計(jì)，優(yōu)化器、調(diào)度系統(tǒng)、存儲(chǔ)格式、Index/MV設(shè)計(jì)等多個(gè)領(lǐng)域均會(huì)大量使用AI的技術(shù)來做優(yōu)化。例如Cost based Optimization中的基于Statistics的Cost推導(dǎo)，會(huì)大量被Learn based Statistics取代。
5.框架與接入層
接入層和管控是一個(gè)子系統(tǒng)，主要用于服務(wù)背后的主系統(tǒng)。從架構(gòu)和功能角度上看，與大多數(shù)服務(wù)的接入層差異不大，也不存在明確的演進(jìn)和代差，因此簡要概述。唯一值得一提的是，隨越來越多的大數(shù)據(jù)平臺(tái)走向“托管化”或者說“服務(wù)化”，框架管控層越來越厚，大多數(shù)企業(yè)級(jí)能力增強(qiáng)來自管控部分。例如，計(jì)算引擎是數(shù)倉類產(chǎn)品的核心，但最終用戶需要的遠(yuǎn)不止引擎本身而是好用的數(shù)據(jù)倉庫產(chǎn)品，就像發(fā)動(dòng)機(jī)是汽車的核心部件，但用戶所需的是完整、好開的汽車。
接入和管控層，抽象下來，主要功能包括：
a. 前端API接入：是系統(tǒng)對外的接口，通常提供HTTP協(xié)議接入，并具有認(rèn)證、流控能力。部分系統(tǒng)提供Web接入能力。
b. 服務(wù)層：包括更多的業(yè)務(wù)邏輯，例如用戶/租戶管理，提供服務(wù)層面的訪問控制，以及服務(wù)級(jí)別的流控。對于引擎來說，服務(wù)層很可能包括編譯與作業(yè)分發(fā)能力，異常作業(yè)的檢測與隔離等等。有些系統(tǒng)為了簡化將API接入與服務(wù)層合二為一個(gè)服務(wù)進(jìn)程。
設(shè)計(jì)考慮：
a.服務(wù)于背后的主系統(tǒng)，功能隨后臺(tái)變化而變化，并沒有“一定之規(guī)”。
b.管控層直接決定系統(tǒng)的可用性，因此也需要完善的容災(zāi)能力，無狀態(tài)的服務(wù)組件通常依托部署系統(tǒng)實(shí)現(xiàn)容災(zāi)，對于有狀態(tài)服務(wù)，通常將狀態(tài)存儲(chǔ)在元數(shù)據(jù)系統(tǒng)或者底層存儲(chǔ)系統(tǒng)中。
c.很多獨(dú)立引擎，特別是開源類，接入和管控層通常比較簡單。對于企業(yè)級(jí)服務(wù)來說，很多額外的功能都在本服務(wù)擴(kuò)展，也體現(xiàn)企業(yè)級(jí)服務(wù)的價(jià)值。例如：監(jiān)控/運(yùn)維能力、審計(jì)日志、計(jì)量計(jì)費(fèi)、對計(jì)算系統(tǒng)熱切換的控制等。甚至包括自動(dòng)化作業(yè)調(diào)優(yōu)等高級(jí)功能（例如SparkCruise，來自微軟Azure托管版的基于歷史信息的自動(dòng)作業(yè)調(diào)優(yōu)子系統(tǒng)）。
d.當(dāng)用戶選用多個(gè)系統(tǒng)組合搭建一套大數(shù)據(jù)平臺(tái)，不同系統(tǒng)都會(huì)有自己的管控層，造成服務(wù)的冗余和各系統(tǒng)的割裂。因此很多云平臺(tái)提供商，會(huì)致力于抽象統(tǒng)一規(guī)范和公共子模塊，例如統(tǒng)一認(rèn)證協(xié)議/服務(wù)（Kerberos等）、統(tǒng)一權(quán)限管理，TerraformAPI標(biāo)準(zhǔn)等。
展望未來，我們看到可能的發(fā)展方向/趨勢主要有：
托管化 - 框架與接入層是企業(yè)級(jí)能力增強(qiáng)的關(guān)鍵一層，隨托管化成為大趨勢，這一層會(huì)有大量的企業(yè)級(jí)能力加入，會(huì)逐步成為關(guān)鍵層。
6. 數(shù)據(jù)開發(fā)與治理平臺(tái)
隨著大數(shù)據(jù)技術(shù)在眾多領(lǐng)域的廣泛應(yīng)用，大量數(shù)據(jù)源需要接入大數(shù)據(jù)平臺(tái)，多種數(shù)據(jù)處理引擎和開發(fā)語言被各類技術(shù)/非技術(shù)人員人員使用，復(fù)雜業(yè)務(wù)催生了規(guī)模龐大、邏輯復(fù)雜的工作流程，數(shù)據(jù)成為業(yè)務(wù)的生命線需要重點(diǎn)保護(hù)，數(shù)據(jù)作為業(yè)務(wù)的原動(dòng)力需要更加方便快捷的被分析和應(yīng)用。
讓大數(shù)據(jù)計(jì)算平臺(tái)真正能夠服務(wù)于業(yè)務(wù)，還需要一系列數(shù)據(jù)研發(fā)和數(shù)據(jù)治理利器，以幫助數(shù)據(jù)工作者低成本和高效地獲取數(shù)據(jù)洞察，實(shí)現(xiàn)業(yè)務(wù)價(jià)值：
1. 數(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ù)同步問題。
2. 元數(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ù)。
3. 數(shù)據(jù)開發(fā)：提供在線數(shù)據(jù)開發(fā)IDE，支持多種計(jì)算存儲(chǔ)引擎，提供批計(jì)算、實(shí)時(shí)計(jì)算、交互式分析、以及機(jī)器學(xué)習(xí)等一體化數(shù)據(jù)開發(fā)服務(wù)，為各種技術(shù)/非技術(shù)人員提供高效極致的ETL/ELT研發(fā)體驗(yàn)。
4. 調(diào)度系統(tǒng)：支持大規(guī)模、高并發(fā)、高穩(wěn)定性的細(xì)粒度周期性任務(wù)調(diào)度，支持流處理、批處理與AI一體化數(shù)據(jù)任務(wù)編排，保障數(shù)據(jù)生產(chǎn)的時(shí)效性、穩(wěn)定性。
5. 數(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ā)展。
6. 數(shù)據(jù)服務(wù)：提供快速將數(shù)據(jù)表生成數(shù)據(jù)API服務(wù)的能力，連接數(shù)據(jù)倉庫與數(shù)據(jù)應(yīng)用的“最后一公里”，實(shí)現(xiàn)靈活可控的數(shù)據(jù)共享交換服務(wù)。
展望未來，我們看到可能的發(fā)展方向/趨勢主要有：
低代碼開發(fā)與分析：數(shù)據(jù)的獲取、分析與應(yīng)用將逐步從專業(yè)開發(fā)人員覆蓋到更多的分析師和業(yè)務(wù)人員，因此數(shù)據(jù)開發(fā)與分析工具將逐步從專業(yè)代碼開發(fā)工具向低代碼化、可視化工具演進(jìn)。甚至是基于NLP和知識(shí)圖譜技術(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ù)治理將會(huì)融合到覆蓋事前、事中和事后的大數(shù)據(jù)生產(chǎn)與應(yīng)用的全鏈路中，數(shù)據(jù)開發(fā)與治理將協(xié)同并進(jìn)。
7. 智能化
隨著大數(shù)據(jù)平臺(tái)及其所承載業(yè)務(wù)的發(fā)展，我們也面臨著新的挑戰(zhàn)：
1. 10PB到EB級(jí)數(shù)據(jù)和百萬級(jí)別作業(yè)規(guī)模，已經(jīng)成為主流，海量數(shù)據(jù)和作業(yè)靠人很難管理。傳統(tǒng)的DBA模式或數(shù)據(jù)中臺(tái)團(tuán)隊(duì)不再勝任。
2. 多種數(shù)據(jù)融在一起，人無法在海量規(guī)模上理解數(shù)據(jù)的所有價(jià)值。
3. 大數(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)域我們可以稱之為自動(dòng)數(shù)倉（AutoData Warehouse）。數(shù)據(jù)湖領(lǐng)域也可以有更多的自動(dòng)化，但因?yàn)閿?shù)倉方向的數(shù)據(jù)管理/調(diào)優(yōu)能力發(fā)展更早，這個(gè)領(lǐng)域更領(lǐng)先。下圖是一個(gè)基本的自動(dòng)數(shù)倉能力分類。
自動(dòng)化本身并不太可衡量，我們定義了一個(gè)“自動(dòng)數(shù)倉”的能力分級(jí)，類比“自動(dòng)駕駛”。分為L1-L5。
1. L1級(jí)：運(yùn)維能力白屏化和工具化。目前絕大多數(shù)系統(tǒng)都可以做到這個(gè)層次。
2. L2級(jí)：更好的系統(tǒng)托管化，底層系統(tǒng)對用戶透明。例如小文件Merge自動(dòng)化、軟硬件升級(jí)透明、自動(dòng)loadbalance等。很多全托管系統(tǒng)都可以做到這個(gè)層次（例如Snowflake、MaxCompute）。
3. L3級(jí)：中臺(tái)能力的自動(dòng)化，輔助數(shù)據(jù)關(guān)聯(lián)與理解，建模與調(diào)優(yōu)。包括數(shù)據(jù)血緣，相似度，冗余度，使用情況與自動(dòng)評分。輔助標(biāo)簽系統(tǒng)，輔助中臺(tái)建設(shè)。市面上的很多數(shù)據(jù)中臺(tái)產(chǎn)品聚焦在這一層。
4. L4級(jí)：系統(tǒng)具備自學(xué)習(xí)能力?；跉v史信息的性能調(diào)優(yōu)（自動(dòng)Parallelism，自動(dòng)冷熱數(shù)據(jù)分層等等），資源與優(yōu)先級(jí)的動(dòng)態(tài)調(diào)配，自適應(yīng)的監(jiān)控和報(bào)警能力，自動(dòng)數(shù)據(jù)異常識(shí)別。目前大多數(shù)系統(tǒng)的能力邊界在此，有巨大的發(fā)揮空間。
5. L5級(jí)：自動(dòng)化建模。包含更高階的數(shù)據(jù)理解，能夠自動(dòng)發(fā)現(xiàn)數(shù)據(jù)的內(nèi)在關(guān)聯(lián)與冗余度，根據(jù)數(shù)據(jù)訪問情況，自動(dòng)維護(hù)數(shù)倉體系。
最近1-2年，自動(dòng)化資源管理和自動(dòng)化作業(yè)調(diào)優(yōu)成為熱點(diǎn)，有非常多的研究性論文。幾個(gè)核心元產(chǎn)品也推出新能力，例如AWSRedshift的自動(dòng)workload mgmt、自動(dòng)key sorting和table sorting，微軟Azure的SparkCruise（@VLDB2021）用來抽象公共子查詢做MaterializedView。
智能化作為大數(shù)據(jù)體系的發(fā)展趨勢之一，上述內(nèi)容即為我們對這個(gè)子領(lǐng)域的未來展望。
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è)級(jí)大數(shù)據(jù)中臺(tái)要面臨的安全風(fēng)險(xiǎn), 根據(jù)其所涉及的系統(tǒng)及技術(shù)領(lǐng)域的不同,分為三個(gè)層次。
1. 最基礎(chǔ)的層次是數(shù)據(jù)中心的物理安全與網(wǎng)絡(luò)安全，數(shù)據(jù)中心是構(gòu)建大數(shù)據(jù)中臺(tái)的基礎(chǔ)，數(shù)據(jù)中心自身安全性和網(wǎng)絡(luò)接入安全性直接影響到企業(yè)大數(shù)據(jù)中臺(tái)的可用性。主要包括數(shù)據(jù)中心保障設(shè)施、數(shù)據(jù)中心安全管控、數(shù)據(jù)中心的網(wǎng)絡(luò)安全等幾個(gè)維度的建設(shè)。當(dāng)云架構(gòu)成為主流，物理安全方面通常由云廠商承擔(dān)。
2. 在這之上是企業(yè)大數(shù)據(jù)平臺(tái)的系統(tǒng)安全，由大數(shù)據(jù)平臺(tái)內(nèi)部的多個(gè)安全子系統(tǒng)構(gòu)成，如訪問控制、應(yīng)用程序隔離、平臺(tái)可信、風(fēng)控和審計(jì)等子系統(tǒng)。這些子系統(tǒng)共同保障大數(shù)據(jù)平臺(tái)的完整性。
3. 最上層是數(shù)據(jù)應(yīng)用安全，貼近于用戶的應(yīng)用場景。通過在這一層提供豐富多樣的數(shù)據(jù)安全產(chǎn)品，大數(shù)據(jù)中臺(tái)為用戶應(yīng)用數(shù)據(jù)的各類業(yè)務(wù)場景提供切實(shí)可靠的數(shù)據(jù)安全能力。
下圖給出了一個(gè)基于數(shù)據(jù)生命周期的數(shù)據(jù)安全管理體系。里面有非常多的子領(lǐng)域，比較存儲(chǔ)加密、敏感數(shù)據(jù)發(fā)現(xiàn)和保護(hù)、數(shù)字水印等等。
?
展望未來，我們看到可能的發(fā)展方向/趨勢主要有：
數(shù)據(jù)安全共享 —?隨數(shù)據(jù)被認(rèn)知為資產(chǎn)，數(shù)據(jù)變現(xiàn)成為一個(gè)熱門話題，它背后的技術(shù)：數(shù)據(jù)安全共享和多方安全計(jì)算也成為熱點(diǎn)方向?？傮w看，數(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è)研究方向是基于差分隱私（DifferentialPrivacy）加密的密態(tài)計(jì)算（例如 DPSAaS@Sigmod2019）。
多方數(shù)據(jù)交互計(jì)算方案，通常基于聯(lián)邦學(xué)習(xí)技術(shù)（FederatedLearning）。
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è)化、工具平臺(tái)化、再到云化數(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層的平臺(tái)型運(yùn)維。
大數(shù)據(jù)運(yùn)維業(yè)務(wù)圍繞穩(wěn)定性（質(zhì)量）、成本及效率主要關(guān)注如下：
1. 針對日常業(yè)務(wù)穩(wěn)定性可以分為日常事件管理、問題管理、變更管理及發(fā)布管理的標(biāo)準(zhǔn)化ITIL流程；
2. 針對成本管理包含了從資源預(yù)算、資源采購、預(yù)算執(zhí)行、財(cái)務(wù)賬單、過保替換等圍繞資源生命周期管理的相關(guān)事項(xiàng)；
3. 針對效率包含了如何開發(fā)一體化的運(yùn)維平臺(tái)以高效支撐業(yè)務(wù)監(jiān)控、服務(wù)管理、系統(tǒng)管理、應(yīng)急/安全管理等。
大數(shù)據(jù)體系發(fā)展至今，服務(wù)器規(guī)模已發(fā)展到數(shù)萬、數(shù)十萬、甚至百萬臺(tái)規(guī)模。隨著基礎(chǔ)設(shè)施規(guī)模的發(fā)展，運(yùn)維系統(tǒng)也經(jīng)歷了一個(gè)從人工、到平臺(tái)化、再到智能化的自然的演進(jìn)過程，運(yùn)維的演進(jìn)需要能支撐起大數(shù)據(jù)基礎(chǔ)設(shè)施的高復(fù)雜、高安全、高可靠、高效率要求。
展望未來，我們看到可能的發(fā)展方向/趨勢主要有：
產(chǎn)品化：運(yùn)維的產(chǎn)品化，本周上是指讓各類運(yùn)維動(dòng)作的更標(biāo)準(zhǔn)，更可控。產(chǎn)品化是把對本身服務(wù)客戶的產(chǎn)品的運(yùn)維需求、和運(yùn)維產(chǎn)品本身的需求、集成到產(chǎn)品功能上，并迭代傳承。同時(shí)通過這些標(biāo)準(zhǔn)化的動(dòng)作，逐步把底層的一些運(yùn)維數(shù)據(jù)統(tǒng)一起來。
數(shù)據(jù)化：隨著產(chǎn)品規(guī)模的擴(kuò)大以及系統(tǒng)的復(fù)雜多產(chǎn)品依賴，在整個(gè)過程中會(huì)產(chǎn)生大量的系統(tǒng)數(shù)據(jù)，隨之?dāng)?shù)據(jù)化能力會(huì)凸顯的非常重要。數(shù)據(jù)的收集存儲(chǔ)，計(jì)算處理，運(yùn)維數(shù)倉建設(shè)，數(shù)據(jù)分層，實(shí)時(shí)性，運(yùn)營分析等相關(guān)數(shù)據(jù)化能力會(huì)逐步成為必須基本能力。重點(diǎn)需要關(guān)注運(yùn)維數(shù)據(jù)的工程，集成，安全和質(zhì)量。
智能化：在超大業(yè)務(wù)規(guī)模下，逐步按以前的傳統(tǒng)的運(yùn)維操作方式不能更高效的支持好業(yè)務(wù)，一個(gè)例子對線上復(fù)雜問題的快速定位和修復(fù)。但這類人腦的規(guī)則級(jí)隨著復(fù)雜度增長以及產(chǎn)品周期發(fā)展不會(huì)是一個(gè)線性提升，這個(gè)時(shí)候是需要通過一些智能化算法能力去幫助處理這些海量數(shù)據(jù)，從中找到一定的結(jié)果規(guī)則，輔助加快專業(yè)人士的判斷。但這塊的技術(shù)挑戰(zhàn)非常巨大，同時(shí)對資源也有一定的消耗。但這個(gè)方向是應(yīng)該持續(xù)發(fā)展。
大數(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)存儲(chǔ)與管理，在成本和延遲上找到了另一個(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)勁的需求?；贒ifferentialPrivacy的數(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è)備日志會(huì)成為更大的數(shù)據(jù)源增長點(diǎn)，面向海量低價(jià)值設(shè)備數(shù)據(jù)的處理和優(yōu)化，需要得到更多的關(guān)注。
趨勢4：AI for System
AI for System，即上文中提到的大數(shù)據(jù)自動(dòng)駕駛。AI作為工具，成為優(yōu)化的常用手段。在大數(shù)據(jù)領(lǐng)域，隨數(shù)據(jù)量/系統(tǒng)復(fù)雜度的增長，DBA模式已經(jīng)不再試用。利用算法優(yōu)化系統(tǒng)成為主流方向，大數(shù)據(jù)的“自動(dòng)駕駛”會(huì)越來越自動(dòng)。
大數(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)會(huì)是什么樣子，是個(gè)熱點(diǎn)話題。
疑問2：關(guān)系模型之外，是否會(huì)發(fā)展出其他主流計(jì)算范式？
大數(shù)據(jù)領(lǐng)域整體還是以二維關(guān)系表達(dá)和計(jì)算為基礎(chǔ)（RelationalDB的理論基礎(chǔ)），是否有新的計(jì)算范式在數(shù)據(jù)庫領(lǐng)域也持續(xù)討論了多年，盡管有包括圖計(jì)算在內(nèi)的其他計(jì)算范式，但過去的40年，關(guān)系運(yùn)算持續(xù)成為主流。
其中核心原因是二維關(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è)級(jí)產(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臺(tái)規(guī)模的大數(shù)據(jù)平臺(tái)硬件投入大約200萬/年，同時(shí)需要維持一個(gè)3-5人的研發(fā)/運(yùn)維團(tuán)隊(duì)，年成本200-300萬/年。綜合TCO高達(dá)450萬/年。
這也是為什么像Snowflake這樣的自研企業(yè)級(jí)產(chǎn)品流行的原因，大多數(shù)不具備深度研發(fā)能力的公司，愿意為更豐富的企業(yè)級(jí)能力和更低的綜合TCO買單；大數(shù)據(jù)系統(tǒng)開發(fā)進(jìn)入深水區(qū)，投資巨大，需要高商業(yè)利潤才能支持。
事實(shí)上，云計(jì)算四巨頭均有自己的自研產(chǎn)品提升利潤率的同時(shí)也提升差異化競爭力（例如AWSRedshift，Google BigQuery，阿里云飛天MaxCompute）。
而每個(gè)開源社區(qū)背后無一例外均有商業(yè)公司推出企業(yè)版（例如Databricks之于Spark，VVP之于Flink、Elastic之于Elasticsearch）。
因此，長期看，大多數(shù)用戶（特別是中小型）進(jìn)入“技術(shù)冷靜期”后，開始審慎考慮綜合投資收益，考慮上云、以及直接采購企業(yè)級(jí)產(chǎn)品+服務(wù)（放棄自建平臺(tái)）。
本文試從系統(tǒng)架構(gòu)的角度，就大數(shù)據(jù)架構(gòu)熱點(diǎn)，每條技術(shù)線的發(fā)展脈絡(luò)，以及技術(shù)趨勢和未解問題等方面做了一個(gè)概述。特別的，大數(shù)據(jù)領(lǐng)域仍然處于發(fā)展期，部分技術(shù)收斂，但新方向和新領(lǐng)域?qū)映霾桓F。本文內(nèi)容和個(gè)人經(jīng)歷相關(guān)，是個(gè)人的視角，難免有缺失或者偏頗，同時(shí)限于篇幅，也很難全面。僅作拋磚引玉，希望和同業(yè)共同探討。
相關(guān)閱讀：Snowflake如日中天是否代表Hadoop已死？大數(shù)據(jù)體系到底是什么？
總結(jié)
以上是生活随笔為你收集整理的大数据体系的4个热点，4个趋势和3个疑问的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iOS GitHub上常用第三方框架与一
- 下一篇： win10和win11之间的数据共享