卷首語：“上雲”到底改變了什麼？
作者：耿立超
隨着對雲計算的深度應用，很快我們就會發現，上雲所影響的並不僅僅是基礎設施，上層應用系統的架構在基礎設施“服務化”的影響下，也慢慢進化出了一些雲上特有的架構模式和最佳實踐，這些模式和實踐在自建（on-premises）場景下並不適用，或效果不夠顯著，但是在雲上則顯示出了強大的威力。
本文，我想針對數據平臺的架構設計，選擇最具實質意義與深刻影響的幾個方面分享一些個人觀點。
存儲與計算分離
Snowflake 的成功讓業界看到了“存儲與計算分離”架構的巨大優勢，這一架構充分利用了雲計算平臺靈活的伸縮能力，幾乎成爲了當前在雲上構建數據平臺的事實標準。
過去，硬件資源的最小粒度是服務器，CPU、內存和硬盤之間是緊密耦合的，系統基本是以服務器爲單位進行伸縮的，這本是平常不過的事情，但是在雲平臺上，當基礎設施被“服務化”之後，就出現了獨立的存儲服務（如 AWS 的 S3 和阿里雲的 OSS）和計算服務（如 AWS 的 EMR 和阿里雲的 EMR），這給數據平臺的架構設計開闢了新的思路，“存儲與計算分離”就是最重要的一條架構準則。
在存儲與計算分離架構下，所有數據將統一存放在對象存儲服務上，所有計算服務與對象存儲服務無縫打通，可以像讀寫本地磁盤一樣讀寫上面的數據。如此一來，計算資源和存儲資源就可以在各自的維度上自由伸縮，不再受彼此的制約。
“無狀態”集羣
存儲與計算分離之後，衍生出了一系列強大而先進的新架構，無狀態集羣就是其中最“酷”的一個，這種集羣在過去自建（on-premises）模式下是無法想象的，“無狀態”意爲着集羣可以“即用即啓，用後釋放”，很多雲上的高階用戶已經在普遍使用這種模式處理他們的 ETL 作業了，他們每天會在零時過後的某個時刻拉起一個臨時集羣，執行所有的 daily 作業，待全部執行完畢之後隨即釋放集羣，從而將批處理的計算成本壓縮到了極致。
這裏需要知道一個技術細節：多數雲平臺都支持通過命令行或 API 啓動一個集羣，所以創建集羣的成本（工作量）幾乎可以忽略不計（這與本地化搭建一個 Hadoop 集羣是完全不同的），研發團隊可以將命令行或 API 調用寫入到工作流中，作爲批處理的前置任務，這樣就可以實現上述做法了。
特別地，數據平臺如果要實現集羣“無狀態”，還需要解決一個問題：即需要將數據的表結構等元數據以服務形式開放出來供計算服務使用，只有這樣，當集羣下次重建時才能接續此前的狀態繼續處理。通常，雲廠商都會提供與行業主流元數據接口（例如 Hive 的 Metastore）兼容的元數據服務，如 AWS 的 Glue Data Catalog，阿里雲的 DLA Meta 等。
一些團隊也會在自建（on-premises）模式下嘗試存儲與計算分離，通常它們會選擇兼容某種對象存儲標準（如 AWS 的 S3）的硬件設備作爲統一的存儲層，將所有數據存放在此類設備上。客觀地說，這些嘗試是值得肯定的，但是在非雲場景下，其“收益”並不明顯，就是說“看不出好在哪裏”。因爲在自建（on-premises）模式下，頻繁地啓停集羣是非常罕見的，也毫無意義，暫停集羣后釋放的資源並不能分配給其他系統，除非所有服務器被 Kubenetes 統一管理，但這就是另一個故事了。
“多集羣”策略
通常，不同的應用場景對計算集羣有不同的需求，例如批處理、實時處理以及 Ad-Hoc/OLAP 查詢所使用的組件和配置都各不相同，此外，不同部門、不同團隊在使用資源時經常會發生衝突，導致作業阻塞。過去，在單一集羣模式下，技術團隊只能依賴 Yarn 等資源配置工具針對不同應用場景、不同用戶制定資源分配策略，由於多場景疊加多租戶，使得資源分配策略異常複雜，集羣資源的整體利用率很難達到較高水平。
在實現存儲與計算分離之後，“多集羣”策略可以輕鬆解決上述問題，也就是面向特定應用場景和租戶創建專職集羣，針對使用場景進行最佳配置，同時，租戶之間也實現了絕對的資源隔離。由於數據與元數據是共享的，且如前所述，創建集羣可通過命令行一鍵完成，所以創建多集羣的成本幾乎可以忽略不計。
多集羣策略可以有效地分解企業級架構上的複雜性，是應對複雜數據生態的強力措施。
“無服務器”架構
Serverless 服務是指那些在基礎設施之上進一步將程序運行環境也虛擬化的雲產品，使用 Serverless 服務，用戶既不需要搭建服務器，也不需要構建運行應用所需的系統環境，他們只需要做一件事：編寫代碼。
Serverless 是一件美好的事嗎？不同的用戶態度可能會大相徑庭，這取決於團隊自身的背景和對雲計算的擁抱程度。Serverless 的哲學在於“把精力用到最核心的問題上”，喜歡 Serverless 的用戶會對其讚不絕口，因爲它確實將團隊從基礎設施和運行環境的維護上徹底解放了出來，使得團隊可以集中精力交付更多的開發任務。但是也有技術人員會對 Serverless 持一種輕蔑態度，認爲這種服務只適合開發簡單的應用，或者只有技術實力不強的團隊纔會選擇。
對於後者我們不予置評，但是對“Serverless 服務只適用於中小規模開發”的言論，需要謹慎看待，從我過去接觸到的大量企業用戶來看，得出該結論的原因很有可能是對所使用的 Serverless 服務瞭解不深造成的。大部分初級用戶是通過 Serverless 服務的控制檯頁面編寫和調試程序的，這種圖形化界面使用起來非常簡單，在很短時間內就可以有所產出，這也是很多團隊喜歡 Serverless 的原因之一，但是基於圖形化界面進行開發有着無法克服的弊端，包括：代碼缺乏版本控制，無法多人協作開發，程序規模變大後難以維護等等，這些並不是 Serverless 本身的問題，而是基於 Serverless 的開發沒有進行“工程化”導致的。人們會將這些問題錯誤地歸結到了 Serverless 上，進而得出了“Serverless 服務不適合大規模開發”的結論。
關於 Serverless 項目的工程化，我們有過很好的實踐經驗，通常 Serverless 服務都會提供 CLI 與 API 用於部署和運行程序，這些 CLI 與 API 與用戶界面上的操作是等價的。一個非常好的做法是基於這些接口將部署和運行等操作編寫成自動化腳本，脫離對用戶界面的依賴，然後將這些腳本和程序代碼一起組織成一個工程項目，放到 Git Repository 上，這樣就可以對程序代碼進行版本控制了，然後再利用構建工具打包，並通過 DevOps 工具自動化部署，這樣一個 Serverless 項目就轉換成了一個常規項目，可以複用所有常規項目的開發流程與規範，構建大規模 Serverless 項目將不是問題。
目錄
熱點 | Hot
Databricks與Snowflake創始人開撕：“未來十年數據倉庫要麼不存在要麼大變樣”
理論派 | Theory
Service Mesh 終極指南（第二版）：次世代微服務開發
推薦文章 | Article
爲什麼Netflix“永不宕機”？
從軟件歷史看架構的未來：編程不再是精英們的遊戲
觀點 | Opinion
Rethink：爲什麼微服務沒有sidecar不行？
拋棄Hadoop，數據湖才能重獲新生