“戒備”與“偏見”

幾年前，我所在的一家傳統(tǒng)行業(yè)的頭部企業(yè)啟動了一系列數(shù)字化轉(zhuǎn)型項目，在配套的 IT 基礎(chǔ)設(shè)施建設(shè)上，“上云”已是大勢所趨。

在此前數(shù)年的工作中，我斷斷續(xù)續(xù)地使用著公有云產(chǎn)品，大多數(shù)情況下，我們只選擇 IaaS 層級的服務(wù)，也就是只使用虛擬實例，對 PaaS 和云平臺特定的 Serverless 服務(wù)敬而遠(yuǎn)之。作為一名架構(gòu)師，我對公有云的此類產(chǎn)品一直懷有一種“戒備”心理。

一方面，從技術(shù)發(fā)展路線上，不管是個人還是團隊，我們都希望學(xué)習(xí)并使用行業(yè)主流且平臺中立的技術(shù)，這些技術(shù)大多數(shù)都是開源的，有著活躍的社區(qū)和良好的周邊生態(tài)，包括高質(zhì)量的文檔、豐富的技術(shù)專著，以及互聯(lián)網(wǎng)上大量的討論文章等等；另一方面，從公司角度出發(fā)，我們也不希望企業(yè)與某一朵云深度綁定，這似乎總讓人缺少一種“安全感”。

此外，對于還沒有準(zhǔn)備好擁抱云計算的技術(shù)人員來說，上云會給他們帶來一種危機感：“既然你都已經(jīng)做得這么好了，那以后還要我做什么呢”？這一感受最初產(chǎn)生于 IT 的基礎(chǔ)設(shè)施團隊，之后系統(tǒng)架構(gòu)師也會有些許同感，這也是很多 PaaS 和 Serverless 服務(wù)“不受歡迎”的原因。但對于云廠商而言，由于這類服務(wù)的利潤率更高，他們會更加熱衷于推薦此類服務(wù)，這會讓本已十分敏感的用戶更加警惕，以至產(chǎn)生抗拒心理。

回到公司的數(shù)字化轉(zhuǎn)型項目，在聽取了多方意見之后，公司決定僅使用虛擬實例構(gòu)建應(yīng)用系統(tǒng)和數(shù)據(jù)平臺，盡可能避免深度介入平臺特定服務(wù)，甚至連非?；A(chǔ)的對象存儲服務(wù)也沒有采用。我們數(shù)據(jù)團隊負(fù)責(zé)構(gòu)建大數(shù)據(jù)平臺，在一批虛擬實例上搭建了一個 Hadoop/Spark 集群后，就開始了長期的數(shù)倉建設(shè)工作。

之后，隨著數(shù)據(jù)規(guī)模的不斷上漲，集群也經(jīng)歷過幾次擴容，得益于 Hadoop 集群管理工具和自動化運維工具的支持，每次擴容倒也不算麻煩。當(dāng)時，我們對基礎(chǔ)設(shè)施的總體狀況是滿意的：“你總得維護一堆機器，然后定期擴容，哪個系統(tǒng)不是這樣呢？”

“上云”改變了什么？

幾年后，機緣巧合，我去了一家業(yè)界知名的云計算公司。所謂“食君之祿、忠君之事”，入職后，我必須廣泛而深入地學(xué)習(xí)這家公司的云產(chǎn)品，這些產(chǎn)品既有基于開源產(chǎn)品封裝的“云化”版本，又有深度定制的 PaaS 和 Serverless 服務(wù)，這些產(chǎn)品都借助云平臺的虛擬化能力，將動態(tài)伸縮與可維護性做到了極致。

隨著對云平臺和云系統(tǒng)架構(gòu)的深入學(xué)習(xí)和應(yīng)用，我開始越來越清晰地認(rèn)識到，由于過去對云計算固有的偏見，阻礙了自己正確看待云計算對系統(tǒng)架構(gòu)和開發(fā)模式帶來的深刻影響，在走訪了大量公有云企業(yè)用戶之后，我真切地感受到了云之所以成功和必將成功的“關(guān)鍵”。

大多數(shù)用戶選擇上云的初衷是希望減輕在 IT 基礎(chǔ)設(shè)施上的負(fù)擔(dān)，避免在機房建設(shè)，網(wǎng)絡(luò)規(guī)劃和服務(wù)器采購上一次性投入大量資金，并且還將繼續(xù)在后期投入資源去管理和維護。

隨著對云計算的深度應(yīng)用，很快我們就會發(fā)現(xiàn)，上云所影響的并不僅僅是基礎(chǔ)設(shè)施，上層應(yīng)用系統(tǒng)的架構(gòu)在基礎(chǔ)設(shè)施“服務(wù)化”的影響下，也慢慢進化出了一些云上特有的架構(gòu)模式和最佳實踐，這些模式和實踐在自建（on-premises）場景下并不適用，或效果不夠顯著，但是在云上則顯示出了強大的威力。

本文，我想針對數(shù)據(jù)平臺的架構(gòu)設(shè)計，選擇最具實質(zhì)意義與深刻影響的幾個方面分享一些個人觀點。

存儲與計算分離

Snowflake 的成功讓業(yè)界看到了“存儲與計算分離”架構(gòu)的巨大優(yōu)勢，這一架構(gòu)充分利用了云計算平臺靈活的伸縮能力，幾乎成為了當(dāng)前在云上構(gòu)建數(shù)據(jù)平臺的事實標(biāo)準(zhǔn)。

過去，硬件資源的最小粒度是服務(wù)器，CPU、內(nèi)存和硬盤之間是緊密耦合的，系統(tǒng)基本是以服務(wù)器為單位進行伸縮的，這本是平常不過的事情，但是在云平臺上，當(dāng)基礎(chǔ)設(shè)施被“服務(wù)化”之后，就出現(xiàn)了獨立的存儲服務(wù)（如 AWS 的 S3 和阿里云的 OSS）和計算服務(wù)（如 AWS 的 EMR 和阿里云的 EMR），這給數(shù)據(jù)平臺的架構(gòu)設(shè)計開辟了新的思路，“存儲與計算分離”就是最重要的一條架構(gòu)準(zhǔn)則。

在存儲與計算分離架構(gòu)下，所有數(shù)據(jù)將統(tǒng)一存放在對象存儲服務(wù)上，所有計算服務(wù)與對象存儲服務(wù)無縫打通，可以像讀寫本地磁盤一樣讀寫上面的數(shù)據(jù)。如此一來，計算資源和存儲資源就可以在各自的維度上自由伸縮，不再受彼此的制約。

“無狀態(tài)”集群

存儲與計算分離之后，衍生出了一系列強大而先進的新架構(gòu)，無狀態(tài)集群就是其中最“酷”的一個，這種集群在過去自建（on-premises）模式下是無法想象的，“無狀態(tài)”意為著集群可以“即用即啟，用后釋放”，很多云上的高階用戶已經(jīng)在普遍使用這種模式處理他們的 ETL 作業(yè)了，他們每天會在零時過后的某個時刻拉起一個臨時集群，執(zhí)行所有的 daily 作業(yè)，待全部執(zhí)行完畢之后隨即釋放集群，從而將批處理的計算成本壓縮到了極致。

這里需要知道一個技術(shù)細(xì)節(jié)：多數(shù)云平臺都支持通過命令行或 API 啟動一個集群，所以創(chuàng)建集群的成本（工作量）幾乎可以忽略不計（這與本地化搭建一個 Hadoop 集群是完全不同的），研發(fā)團隊可以將命令行或 API 調(diào)用寫入到工作流中，作為批處理的前置任務(wù)，這樣就可以實現(xiàn)上述做法了。

特別地，數(shù)據(jù)平臺如果要實現(xiàn)集群“無狀態(tài)”，還需要解決一個問題：即需要將數(shù)據(jù)的表結(jié)構(gòu)等元數(shù)據(jù)以服務(wù)形式開放出來供計算服務(wù)使用，只有這樣，當(dāng)集群下次重建時才能接續(xù)此前的狀態(tài)繼續(xù)處理。通常，云廠商都會提供與行業(yè)主流元數(shù)據(jù)接口（例如 Hive 的 Metastore）兼容的元數(shù)據(jù)服務(wù)，如 AWS 的 Glue Data Catalog，阿里云的 DLA Meta 等。

一些團隊也會在自建（on-premises）模式下嘗試存儲與計算分離，通常它們會選擇兼容某種對象存儲標(biāo)準(zhǔn)（如 AWS 的 S3）的硬件設(shè)備作為統(tǒng)一的存儲層，將所有數(shù)據(jù)存放在此類設(shè)備上。客觀地說，這些嘗試是值得肯定的，但是在非云場景下，其“收益”并不明顯，就是說“看不出好在哪里”。因為在自建（on-premises）模式下，頻繁地啟停集群是非常罕見的，也毫無意義，暫停集群后釋放的資源并不能分配給其他系統(tǒng)，除非所有服務(wù)器被 Kubenetes 統(tǒng)一管理，但這就是另一個故事了。

“多集群”策略

通常，不同的應(yīng)用場景對計算集群有不同的需求，例如批處理、實時處理以及 Ad-Hoc/OLAP 查詢所使用的組件和配置都各不相同，此外，不同部門、不同團隊在使用資源時經(jīng)常會發(fā)生沖突，導(dǎo)致作業(yè)阻塞。過去，在單一集群模式下，技術(shù)團隊只能依賴 Yarn 等資源配置工具針對不同應(yīng)用場景、不同用戶制定資源分配策略，由于多場景疊加多租戶，使得資源分配策略異常復(fù)雜，集群資源的整體利用率很難達(dá)到較高水平。

在實現(xiàn)存儲與計算分離之后，“多集群”策略可以輕松解決上述問題，也就是面向特定應(yīng)用場景和租戶創(chuàng)建專職集群，針對使用場景進行最佳配置，同時，租戶之間也實現(xiàn)了絕對的資源隔離。由于數(shù)據(jù)與元數(shù)據(jù)是共享的，且如前所述，創(chuàng)建集群可通過命令行一鍵完成，所以創(chuàng)建多集群的成本幾乎可以忽略不計。

多集群策略可以有效地分解企業(yè)級架構(gòu)上的復(fù)雜性，是應(yīng)對復(fù)雜數(shù)據(jù)生態(tài)的強力措施。

“無服務(wù)器”架構(gòu)

Serverless 服務(wù)是指那些在基礎(chǔ)設(shè)施之上進一步將程序運行環(huán)境也虛擬化的云產(chǎn)品，使用 Serverless 服務(wù)，用戶既不需要搭建服務(wù)器，也不需要構(gòu)建運行應(yīng)用所需的系統(tǒng)環(huán)境，他們只需要做一件事：編寫代碼。

Serverless 是一件美好的事嗎？不同的用戶態(tài)度可能會大相徑庭，這取決于團隊自身的背景和對云計算的擁抱程度。Serverless 的哲學(xué)在于“把精力用到最核心的問題上”，喜歡 Serverless 的用戶會對其贊不絕口，因為它確實將團隊從基礎(chǔ)設(shè)施和運行環(huán)境的維護上徹底解放了出來，使得團隊可以集中精力交付更多的開發(fā)任務(wù)。但是也有技術(shù)人員會對 Serverless 持一種輕蔑態(tài)度，認(rèn)為這種服務(wù)只適合開發(fā)簡單的應(yīng)用，或者只有技術(shù)實力不強的團隊才會選擇。

對于后者我們不予置評，但是對“Serverless 服務(wù)只適用于中小規(guī)模開發(fā)”的言論，需要謹(jǐn)慎看待，從我過去接觸到的大量企業(yè)用戶來看，得出該結(jié)論的原因很有可能是對所使用的 Serverless 服務(wù)了解不深造成的。大部分初級用戶是通過 Serverless 服務(wù)的控制臺頁面編寫和調(diào)試程序的，這種圖形化界面使用起來非常簡單，在很短時間內(nèi)就可以有所產(chǎn)出，這也是很多團隊喜歡 Serverless 的原因之一，但是基于圖形化界面進行開發(fā)有著無法克服的弊端，包括：代碼缺乏版本控制，無法多人協(xié)作開發(fā)，程序規(guī)模變大后難以維護等等，這些并不是 Serverless 本身的問題，而是基于 Serverless 的開發(fā)沒有進行“工程化”導(dǎo)致的。人們會將這些問題錯誤地歸結(jié)到了 Serverless 上，進而得出了“Serverless 服務(wù)不適合大規(guī)模開發(fā)”的結(jié)論。

關(guān)于 Serverless 項目的工程化，我們有過很好的實踐經(jīng)驗，通常 Serverless 服務(wù)都會提供 CLI 與 API 用于部署和運行程序，這些 CLI 與 API 與用戶界面上的操作是等價的。一個非常好的做法是基于這些接口將部署和運行等操作編寫成自動化腳本，脫離對用戶界面的依賴，然后將這些腳本和程序代碼一起組織成一個工程項目，放到 Git Repository 上，這樣就可以對程序代碼進行版本控制了，然后再利用構(gòu)建工具打包，并通過 DevOps 工具自動化部署，這樣一個 Serverless 項目就轉(zhuǎn)換成了一個常規(guī)項目，可以復(fù)用所有常規(guī)項目的開發(fā)流程與規(guī)范，構(gòu)建大規(guī)模 Serverless 項目將不是問題。

云計算 VS. 開源生態(tài)

我們已經(jīng)說了很多云計算的“好”，最后回應(yīng)一下對云計算與開源生態(tài)相左的“擔(dān)憂”，從目前的行業(yè)態(tài)勢來看，主流云廠商其實早已認(rèn)識到這個問題，并在產(chǎn)品設(shè)計上努力向開源標(biāo)準(zhǔn)靠攏。只有使用行業(yè)廣泛認(rèn)可的技術(shù)，云計算才有活力，也才能緩解用戶對云平臺綁定的擔(dān)憂，進而吸引更多的用戶向云上遷移。

在數(shù)據(jù)領(lǐng)域，各主流云廠商都有基于 Hadoop、Spark 等主流開源大數(shù)據(jù)產(chǎn)品封裝的“云化”版本，與 Cloudera 的 CDH 類似。同時，很多 Serverless 服務(wù)也大多基于主流開源產(chǎn)品封裝，或者保持一致的編程接口，例如 AWS 的 Glue 就是基于 Spark 的 Serverless 服務(wù)，編程接口與開源 Spark 一致。

總的來說，云計算與開源生態(tài)不是也不應(yīng)該是對立的，一方面，云廠商有向開源生態(tài)靠攏的商業(yè)驅(qū)動力，另一方面，有能力的云廠商也應(yīng)該積極回饋開源社區(qū)，一起營造更好的雙贏局面。

一點展望

由于過往的獨特經(jīng)歷，我先后經(jīng)歷過“半云”、“全云”以及“非云”等多種環(huán)境，真切地體會到了云計算對數(shù)據(jù)平臺的深刻影響。當(dāng)今的數(shù)據(jù)平臺建設(shè)，“云上”和“云下”已經(jīng)幾乎是兩個賽道了，如果以個人的一點淺見展望一下的話，我認(rèn)為上云是不可逆轉(zhuǎn)的趨勢，在云上構(gòu)筑數(shù)據(jù)平臺是未來絕大多數(shù)企業(yè)的首選。

本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：耿立超，36氪經(jīng)授權(quán)發(fā)布。

關(guān)鍵詞： 遠(yuǎn)比 深刻 數(shù)據(jù)