1
“戒備”與“偏見”
幾年前，我所在的一家傳統(tǒng)行業(yè)的頭部企業(yè)啟動了一系列數(shù)字化轉(zhuǎn)型項目，在配套的IT基礎設施建設上，“上云”已是大勢所趨。
在此前數(shù)年的工作中，我斷斷續(xù)續(xù)地使用著公有云產(chǎn)品，大多數(shù)情況下，我們只選擇IaaS層級的服務，也就是只使用虛擬實例，對PaaS和云平臺特定的Serverless服務敬而遠之。作為一名架構(gòu)師，我對公有云的此類產(chǎn)品一直懷有一種“戒備”心理。
一方面，從技術(shù)發(fā)展路線上，不管是個人還是團隊，我們都希望學習并使用行業(yè)主流且平臺中立的技術(shù)，這些技術(shù)大多數(shù)都是開源的，有著活躍的社區(qū)和良好的周邊生態(tài)，包括高質(zhì)量的文檔、豐富的技術(shù)專著，以及互聯(lián)網(wǎng)上大量的討論文章等等；另一方面，從公司角度出發(fā)，我們也不希望企業(yè)與某一朵云深度綁定，這似乎總讓人缺少一種“安全感”。
此外，對于還沒有準備好擁抱云計算的技術(shù)人員來說，上云會給他們帶來一種危機感：“既然你都已經(jīng)做得這么好了，那以后還要我做什么呢”？這一感受最初產(chǎn)生于IT的基礎設施團隊，之后系統(tǒng)架構(gòu)師也會有些許同感，這也是很多PaaS和Serverless服務“不受歡迎”的原因。但對于云廠商而言，由于這類服務的利潤率更高，他們會更加熱衷于推薦此類服務，這會讓本已十分敏感的用戶更加警惕，以至產(chǎn)生抗拒心理。
回到公司的數(shù)字化轉(zhuǎn)型項目，在聽取了多方意見之后，公司決定僅使用虛擬實例構(gòu)建應用系統(tǒng)和數(shù)據(jù)平臺，盡可能避免深度介入平臺特定服務，甚至連非?；A的對象存儲服務也沒有采用。我們數(shù)據(jù)團隊負責構(gòu)建大數(shù)據(jù)平臺，在一批虛擬實例上搭建了一個Hadoop/Spark集群后，就開始了長期的數(shù)倉建設工作。
之后，隨著數(shù)據(jù)規(guī)模的不斷上漲，集群也經(jīng)歷過幾次擴容，得益于Hadoop集群管理工具和自動化運維工具的支持，每次擴容倒也不算麻煩。當時，我們對基礎設施的總體狀況是滿意的：“你總得維護一堆機器，然后定期擴容，哪個系統(tǒng)不是這樣呢？”
2
“上云”改變了什么？
幾年后，機緣巧合，我去了一家業(yè)界知名的云計算公司。所謂“食君之祿、忠君之事”，入職后，我必須廣泛而深入地學習這家公司的云產(chǎn)品，這些產(chǎn)品既有基于開源產(chǎn)品封裝的“云化”版本，又有深度定制的PaaS和Serverless服務，這些產(chǎn)品都借助云平臺的虛擬化能力，將動態(tài)伸縮與可維護性做到了極致。
隨著對云平臺和云系統(tǒng)架構(gòu)的深入學習和應用，我開始越來越清晰地認識到，由于過去對云計算固有的偏見，阻礙了自己正確看待云計算對系統(tǒng)架構(gòu)和開發(fā)模式帶來的深刻影響，在走訪了大量公有云企業(yè)用戶之后，我真切地感受到了云之所以成功和必將成功的“關鍵”。
大多數(shù)用戶選擇上云的初衷是希望減輕在IT基礎設施上的負擔，避免在機房建設，網(wǎng)絡規(guī)劃和服務器采購上一次性投入大量資金，并且還將繼續(xù)在后期投入資源去管理和維護。
隨著對云計算的深度應用，很快我們就會發(fā)現(xiàn)，上云所影響的并不僅僅是基礎設施，上層應用系統(tǒng)的架構(gòu)在基礎設施“服務化”的影響下，也慢慢進化出了一些云上特有的架構(gòu)模式和最佳實踐，這些模式和實踐在自建（on-premises）場景下并不適用，或效果不夠顯著，但是在云上則顯示出了強大的威力。
本文，我想針對數(shù)據(jù)平臺的架構(gòu)設計，選擇最具實質(zhì)意義與深刻影響的幾個方面分享一些個人觀點。
存儲與計算分離
Snowflake的成功讓業(yè)界看到了“存儲與計算分離”架構(gòu)的巨大優(yōu)勢，這一架構(gòu)充分利用了云計算平臺靈活的伸縮能力，幾乎成為了當前在云上構(gòu)建數(shù)據(jù)平臺的事實標準。
過去，硬件資源的最小粒度是服務器，CPU、內(nèi)存和硬盤之間是緊密耦合的，系統(tǒng)基本是以服務器為單位進行伸縮的，這本是平常不過的事情，但是在云平臺上，當基礎設施被“服務化”之后，就出現(xiàn)了獨立的存儲服務（如AWS的S3和阿里云的OSS）和計算服務（如AWS的EMR和阿里云的EMR），這給數(shù)據(jù)平臺的架構(gòu)設計開辟了新的思路，“存儲與計算分離”就是最重要的一條架構(gòu)準則。
在存儲與計算分離架構(gòu)下，所有數(shù)據(jù)將統(tǒng)一存放在對象存儲服務上，所有計算服務與對象存儲服務無縫打通，可以像讀寫本地磁盤一樣讀寫上面的數(shù)據(jù)。如此一來，計算資源和存儲資源就可以在各自的維度上自由伸縮，不再受彼此的制約。
“無狀態(tài)”集群
存儲與計算分離之后，衍生出了一系列強大而先進的新架構(gòu)，無狀態(tài)集群就是其中最“酷”的一個，這種集群在過去自建（on-premises）模式下是無法想象的，“無狀態(tài)”意為著集群可以“即用即啟，用后釋放”，很多云上的高階用戶已經(jīng)在普遍使用這種模式處理他們的ETL作業(yè)了，他們每天會在零時過后的某個時刻拉起一個臨時集群，執(zhí)行所有的daily作業(yè)，待全部執(zhí)行完畢之后隨即釋放集群，從而將批處理的計算成本壓縮到了極致。
這里需要知道一個技術(shù)細節(jié)：多數(shù)云平臺都支持通過命令行或API啟動一個集群，所以創(chuàng)建集群的成本（工作量）幾乎可以忽略不計（這與本地化搭建一個Hadoop集群是完全不同的），研發(fā)團隊可以將命令行或API調(diào)用寫入到工作流中，作為批處理的前置任務，這樣就可以實現(xiàn)上述做法了。
特別地，數(shù)據(jù)平臺如果要實現(xiàn)集群“無狀態(tài)”，還需要解決一個問題：即需要將數(shù)據(jù)的表結(jié)構(gòu)等元數(shù)據(jù)以服務形式開放出來供計算服務使用，只有這樣，當集群下次重建時才能接續(xù)此前的狀態(tài)繼續(xù)處理。通常，云廠商都會提供與行業(yè)主流元數(shù)據(jù)接口（例如Hive的Metastore）兼容的元數(shù)據(jù)服務，如AWS的Glue Data Catalog，阿里云的DLA Meta等。
一些團隊也會在自建（on-premises）模式下嘗試存儲與計算分離，通常它們會選擇兼容某種對象存儲標準（如AWS的S3）的硬件設備作為統(tǒng)一的存儲層，將所有數(shù)據(jù)存放在此類設備上。客觀地說，這些嘗試是值得肯定的，但是在非云場景下，其“收益”并不明顯，就是說“看不出好在哪里”。因為在自建（on-premises）模式下，頻繁地啟停集群是非常罕見的，也毫無意義，暫停集群后釋放的資源并不能分配給其他系統(tǒng)，除非所有服務器被Kubenetes統(tǒng)一管理，但這就是另一個故事了。
“多集群”策略
通常，不同的應用場景對計算集群有不同的需求，例如批處理、實時處理以及Ad-Hoc/OLAP查詢所使用的組件和配置都各不相同，此外，不同部門、不同團隊在使用資源時經(jīng)常會發(fā)生沖突，導致作業(yè)阻塞。過去，在單一集群模式下，技術(shù)團隊只能依賴Yarn等資源配置工具針對不同應用場景、不同用戶制定資源分配策略，由于多場景疊加多租戶，使得資源分配策略異常復雜，集群資源的整體利用率很難達到較高水平。
在實現(xiàn)存儲與計算分離之后，“多集群”策略可以輕松解決上述問題，也就是面向特定應用場景和租戶創(chuàng)建專職集群，針對使用場景進行最佳配置，同時，租戶之間也實現(xiàn)了絕對的資源隔離。由于數(shù)據(jù)與元數(shù)據(jù)是共享的，且如前所述，創(chuàng)建集群可通過命令行一鍵完成，所以創(chuàng)建多集群的成本幾乎可以忽略不計。
多集群策略可以有效地分解企業(yè)級架構(gòu)上的復雜性，是應對復雜數(shù)據(jù)生態(tài)的強力措施。
“無服務器”架構(gòu)
Serverless服務是指那些在基礎設施之上進一步將程序運行環(huán)境也虛擬化的云產(chǎn)品，使用Serverless服務，用戶既不需要搭建服務器，也不需要構(gòu)建運行應用所需的系統(tǒng)環(huán)境，他們只需要做一件事：編寫代碼。
Serverless是一件美好的事嗎？不同的用戶態(tài)度可能會大相徑庭，這取決于團隊自身的背景和對云計算的擁抱程度。Serverless的哲學在于“把精力用到最核心的問題上”，喜歡Serverless的用戶會對其贊不絕口，因為它確實將團隊從基礎設施和運行環(huán)境的維護上徹底解放了出來，使得團隊可以集中精力交付更多的開發(fā)任務。但是也有技術(shù)人員會對Serverless持一種輕蔑態(tài)度，認為這種服務只適合開發(fā)簡單的應用，或者只有技術(shù)實力不強的團隊才會選擇。
對于后者我們不予置評，但是對“Serverless服務只適用于中小規(guī)模開發(fā)”的言論，需要謹慎看待，從我過去接觸到的大量企業(yè)用戶來看，得出該結(jié)論的原因很有可能是對所使用的Serverless服務了解不深造成的。大部分初級用戶是通過Serverless服務的控制臺頁面編寫和調(diào)試程序的，這種圖形化界面使用起來非常簡單，在很短時間內(nèi)就可以有所產(chǎn)出，這也是很多團隊喜歡Serverless的原因之一，但是基于圖形化界面進行開發(fā)有著無法克服的弊端，包括：代碼缺乏版本控制，無法多人協(xié)作開發(fā)，程序規(guī)模變大后難以維護等等，這些并不是Serverless本身的問題，而是基于Serverless的開發(fā)沒有進行“工程化”導致的。人們會將這些問題錯誤地歸結(jié)到了Serverless上，進而得出了“Serverless服務不適合大規(guī)模開發(fā)”的結(jié)論。
關于Serverless項目的工程化，我們有過很好的實踐經(jīng)驗，通常Serverless服務都會提供CLI與API用于部署和運行程序，這些CLI與API與用戶界面上的操作是等價的。一個非常好的做法是基于這些接口將部署和運行等操作編寫成自動化腳本，脫離對用戶界面的依賴，然后將這些腳本和程序代碼一起組織成一個工程項目，放到Git Repository上，這樣就可以對程序代碼進行版本控制了，然后再利用構(gòu)建工具打包，并通過DevOps工具自動化部署，這樣一個Serverless項目就轉(zhuǎn)換成了一個常規(guī)項目，可以復用所有常規(guī)項目的開發(fā)流程與規(guī)范，構(gòu)建大規(guī)模Serverless項目將不是問題。
3
云計算VS.開源生態(tài)
我們已經(jīng)說了很多云計算的“好”，最后回應一下對云計算與開源生態(tài)相左的“擔憂”，從目前的行業(yè)態(tài)勢來看，主流云廠商其實早已認識到這個問題，并在產(chǎn)品設計上努力向開源標準靠攏。只有使用行業(yè)廣泛認可的技術(shù)，云計算才有活力，也才能緩解用戶對云平臺綁定的擔憂，進而吸引更多的用戶向云上遷移。
在數(shù)據(jù)領域，各主流云廠商都有基于Hadoop、Spark等主流開源大數(shù)據(jù)產(chǎn)品封裝的“云化”版本，與Cloudera的CDH類似。同時，很多Serverless服務也大多基于主流開源產(chǎn)品封裝，或者保持一致的編程接口，例如AWS的Glue就是基于Spark的Serverless服務，編程接口與開源Spark一致。
總的來說，云計算與開源生態(tài)不是也不應該是對立的，一方面，云廠商有向開源生態(tài)靠攏的商業(yè)驅(qū)動力，另一方面，有能力的云廠商也應該積極回饋開源社區(qū)，一起營造更好的雙贏局面。
4
一點展望
由于過往的獨特經(jīng)歷，我先后經(jīng)歷過“半云”、“全云”以及“非云”等多種環(huán)境，真切地體會到了云計算對數(shù)據(jù)平臺的深刻影響。當今的數(shù)據(jù)平臺建設，“云上”和“云下”已經(jīng)幾乎是兩個賽道了，如果以個人的一點淺見展望一下的話，我認為上云是不可逆轉(zhuǎn)的趨勢，在云上構(gòu)筑數(shù)據(jù)平臺是未來絕大多數(shù)企業(yè)的首選。
作者介紹：
耿立超，架構(gòu)師，特斯拉中國數(shù)據(jù)團隊負責人，多年開發(fā)與架構(gòu)經(jīng)驗，對大數(shù)據(jù)、企業(yè)級應用架構(gòu)、SaaS、分布式存儲和領域驅(qū)動設計有豐富的實踐經(jīng)驗，著有《大數(shù)據(jù)平臺架構(gòu)與原型實現(xiàn)：數(shù)據(jù)中臺建設實戰(zhàn)》(https://item.jd.com/12677623.html)一書，個人技術(shù)博客：https://laurence.blog.csdn.net
