+ Serverless，打造下一代智能數據湖

今年年初這場突如其來的疫情，讓我們早晨醒來打開手機的第一件事情，從刷朋友圈變成了刷每日最新的疫情數據。看看國內外新增確診人數/現存確診人數，看看國內外疫情分布的地圖。丁香醫生也因為快速上線疫情實時動態板塊，成為了大家了解疫情發展的首選陣地。

對于很多企業的管理人員而言，這就是個很熟悉的T+1計算T日的報表場景。管理人員通過報表查看前一天企業的經營情況、庫存情況、用戶新增/流失情況等，用數據提高決策的準確率，減少誤判。

支撐這個典型報表場景的背后，是一整套海量數據計算的大數據架構。根據筆者這幾年幾十家各行各業企業的交流經驗來看，大致都經歷了如下幾個階段：

關系型數據庫

最初，企業的技術人員通常都是在業務數據庫相對空閑的時候（比如：晚上或者凌晨），直接在業務數據庫備庫進行一些數據分析查詢。隨著數據量的增多，一份邏輯上相同的數據，通常需要通過分庫分表的方式分布在多個業務數據庫中。快速分析全量數據且不影響在線業務變成了一件極其復雜的事情。

線下自建Hadoop集群

2004年，Google發布MapReduce論文。2006年，Apache Hadoop項目發布。一些技術走在比較前沿的互聯網公司，開始使用Hadoop的分布式處理能力解決數據分析中常見的數據量激增、查詢出不了結果等問題。

隨后幾年，越來越多的公司開始在線下機房搭建開源Hadoop集群，Hadoop生態相關的Kafka、Hive、Spark、Flink等都開始百花齊放，懂這些開源組件的技術人員在職場上也變得越來越吃香。

Hadoop架構最本質的優勢就是高擴展性，理論上，解決好節點間的通信、引入多管理節點，就能根據數據量無限擴展集群規模。集群規模跟需要參與計算的數據量（如：最近30天的數據）強相關，尤其像互聯網APP，可能一把就火了，但火上半個月用戶熱情冷卻，又下降到最初的業務量。線下機房采購服務器走流程，周期基本都是以月為單位，根本無法滿足快速變化的業務場景。

云上自建Hadoop集群

當時，國外的亞馬遜已經誕生了幾年，國內的阿里也開始大刀闊斧進軍公有云。技術團隊開始考慮公有云上購買虛擬機部署Hadoop集群，云上虛擬機按需使用的特點很好地解決了Hadoop集群對于節點伸縮能力的訴求。

云上半托管大數據服務 & 云上Serverless大數據服務

云廠商也紛紛看到了企業對大數據分析的訴求，推出了云上半托管大數據服務（如：AWS、華為云的MRS等）。從單純虛擬機的性能競爭演變成了大數據管理軟件的易用性、大數據組件的性能等競爭。

云上半托管大數據服務對于用戶來說，最核心的優勢就是使得安裝、升級、運維變得簡單化、可視化。同時，因為組件都是開源 + 自研優化，所以在接口上和開源保持一致，減少了業務的改造成本。

但云上半托管大數據服務對于用戶還是有一定的使用門檻（懂大數據運維和調優），而且需要長期持有一部分固定節點資源，存在一定的資源浪費。

注意到這些問題，AWS在2016年推出了基于Serverless架構的Athena服務。最初是主打使用標準SQL分析Amazon S3 中的數據。Athena沒有服務器，無需管理任何基礎設施，且只需為運行的查詢付費。

華為云也在2017年推出了基于Serverless架構的數據湖探索DLI服務，完全兼容Apache Spark和Apache Flink生態，使用SQL就可輕松完成多個數據源的聯合分析。

2019年2月，加州大學伯克利分校發表了這篇名為《Cloud Programming Simplified: A Berkerley View on Serverless Computing》的論文，論文中認為Serverless模式主要有三個特點：

1.???? 弱化了儲存和計算之間的聯系。服務的儲存和計算被分開部署和收費，服務的儲存不再是它本身的一部分，而是演變成了獨立的云服務，這使得計算變得無狀態化，更容易調度和縮擴容，同時也降低了數據丟失的風險。

2.???? 代碼的執行不再需要手動分配資源。我們再也不需要為服務的運行指定需要的資源（比如使用幾臺機器、多大的帶寬、多大的磁盤...），只需要提供一份代碼，剩下的交由Serverless平臺去處理就行了

3.???? 按使用量計費。Serverless按照服務的使用量（調用次數、時長等）進行計費，而不是像傳統的半托管服務那樣，按照使用的資源（ECS實例、VM的規格等）計費。

在很長一段時間內，云上半托管大數據服務和Serverless大數據服務一定是長期并存的狀態。

有大數據技術團隊的大企業通常會選擇半托管服務，一是因為使用習慣和自由度更像是開源Hadoop集群，二是因為技術團隊自身也希望在大數據技術上有積累以便不時之需。

大數據技能較弱，且對成本敏感的中小型企業會考慮Serverless服務，吸引他們的是Serverless大數據服務即開即用免運維 + 標準SQL能力，用JDBC連上Serverless服務，體驗十分接近傳統關系型數據庫。

Serverless大數據服務的未來

Serverless大數據服務要真正被大眾接受，對外需要做好宣傳，對內需要練好內功。Serverless概念從2018年才開始真正火起來，很多用戶一提到大數據，直觀還是想到自建Hadoop集群或者云上半托管大數據服務。隨著K8S容器和微服務被更多的用戶接受和使用，Serverless大數據服務也在逐漸出現在技術人員選型的清單中。

內功修煉上，Serverless大數據服務必須要解決好“安全”、“彈性”、“智能”、“易用”四個核心問題

安全

大數據領域，無論是SQL中的UDF還是用戶自己開發的應用程序，都存在會攻擊其它租戶的風險。當前想要解決這類安全問題的方法，不外乎沙箱隔離、安全容器隔離、物理隔離等這幾個方法。每一個方法對架構和資源利用率的挑戰都非常大。

彈性

Serverless大數據服務最初誕生的初衷就是讓用戶提交應用時，無需感知和指定具體的運行資源數。彈性分為兩個方面：一是彈性的速度，二是彈性的預測。

彈性的速度取決于底層物理資源池的大小和擴容算法、資源預熱的程度以及不同租戶間的資源搶占機制。

彈性的預測可以從易到難分為幾類：最簡單的就是根據用戶定時規則進行彈性，優點是及時彈性，缺點也顯而易見用戶需要對業務比較了解；其次就是如果是周期性任務，服務可以通過收集歷史作業執行規律（作業數、資源利用率等），在下一次執行時根據歷史規律進行彈性；更進一步，通常大數據的任務都是拆分成多個邏輯相同的Task，根據資源量進行多輪調度。第一輪運行的時候，可以收集到單個Task的運行時長、CPU利用率等，第二輪就可以根據單個Task的信息，跟彈性的速度做個平衡，獲取最佳彈性策略。

智能

使用大數據組件，其實搭建、升級等都不算特別復雜的事情，真正復雜的是上百個參數的調優。Serverless大數據服務如果想要真正地吸引之前使用自建Hadoop集群的用戶，核心就是解決用戶最頭疼的調優問題。Serverless大數據服務根據用戶的業務及歷史執行情況，智能對服務參數及數據組織進行調優。最典型的幾個問題，比如：如何避免輸出過多小文件、如何切分合適的Reduce個數、如何根據查詢條件自動調整數據組織形式等。

易用

除了解決基本的部署、升級等運維相關的問題，真正做到免運維。在使用習慣上，相比云上半托管大數據服務，Serverless大數據服務一定會有一個適應過程，我們要做的就是讓這個適應過程變得潛移默化。

?? 基礎功能頁面的使用：如果跟微信一樣，做好界面易用性設計和功能的取舍，這個學習過程會在潛移默化中完成。

?? 運維相關頁面的使用：一定要盡可能保持和開源一樣或者類似的頁面邏輯，比如：Spark UI。

?? 作業操作腳本：包括作業的提交、作業的終止、狀態的查詢等，如果Serverless大數據服務是想搞定某個開源大數據框架的遷移場景，這一部分一定要全兼容開源習慣。

Serverless大數據服務有些是基于開源大數據框架深度優化，有些是純自研大數據框架。在應用開發的接口定義上，不管是哪種方式，對于從開源組件入門大數據的用戶來說，開源接口就是標準，保持和兼容開源接口是Serverless大數據服務的基礎。

總結

Serverless大數據服務是一種面向未來的形態。隨著逐個攻破當前存在的問題，它在大數據分析所占的比重一定會逐年增加。真正把大數據分析變成跟水和電一樣隨取隨用，每個企業都能用得起的工具。

大數據 Serverless 數據湖治理中心 DGC 智能數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。