多租的安全性怎麼保障？揭祕阿里雲大資料平臺MaxCompute在多租上的實現！

導讀： 公有云大資料平臺在多租戶的設計和實現方式上有所差異。本文主要介紹在公有云大資料平臺的多租實現方案中需要考慮的問題和挑戰，重點介紹了MaxCompute在計算和儲存多租實現上的特點。期望通過這些介紹來讓大家瞭解大資料雲平臺多租方案需要關注的技術點和MaxCompute在多租實現上的產品特色。

全文將按照以下四部分內容展開：

• 大資料平臺多租戶形態

• 強多租的優勢與挑戰

• MaxCompute多租實現

• Why & 後續演進

首先我們看下 多租戶形態 ，多租的概念大家可能有不同的理解，可以簡單分為 三類 ：

• 第一類，使用者獨享一個數據庫例項 ，支援基本的基於角色的許可權控制，比如雲上的傳統資料庫，通常就是這種模式。在這種場景下從雲平臺的角度來看是支援多個租戶的，但是每個租戶購買的是獨立的例項，在例項內部做角色劃分，但是例項之間的資料是完全獨立的。

• 第二類，是控制平面的多租 ，比如元資料和許可權管控是多租的，但是計算資源是相對獨立的，大資料的場景因為需要支援複雜的計算，通常會將計算資源單獨拿出來管理。

• 第三類，是更廣泛意義上的多租 ，share everything 。從管控、計算到儲存使用的都是多租的資源，也可以稱之為強多租。

隨著多租程度的提升，從使用者的角度來看，系統的可擴充套件性越好，可以很方便地進行資源的擴縮容。但是雲平臺自身的系統複雜度會更高，而系統複雜度更高，可能會帶來更多的穩定性問題。由於不同使用者的作業執行在一起，安全性上的要求也更高，特別是在公有云的場景。

今天我的分享更多關注的是計算和儲存的多租實現 。關於管控方面，基於RBAC或者基於許可權表的許可權管理，行級列級許可權也是大資料平臺多租實現的一部分，但不是今天分享的重點。回到計算和儲存的多租上，實現上會有不同的組合方式。

一種典型的形態是單租計算加開放儲存的模式 ，比如AWS EMR和Databricks等。 上圖右邊有一個databricks的架構圖，我們可以看到，管控層面是多租的，而不同使用者的計算資源是單租的，儲存則用 的類似AWS S3的開放儲存。 管控使用的是databricks的賬號，而計算是跑在使用者自己的vpc。

這種模式的優勢在於：

• 由於計算資源是單租的，所有可以支援複雜的UDF，而不用太考慮安全的問題。

• 同時因為儲存是開放的，可以很方便地將計算遷到其他雲上，支援多雲。

面臨的挑戰在於：

• 資源的粒度是租戶級別的，需要提前購買，彈性擴縮容的能力依賴雲平臺的彈性。

• 多租雲端儲存的讀寫效率問題，計算與儲存的物理位置相對較遠，可能還要經過閘道器，可能需要進行資料的預取和快取。

• 計算過程產生的中間資料，因為效能的考慮，不能完全依賴雲端儲存，需要考慮其他方式，比如記憶體或者本地儲存的方式來儲存。

BigQuery 和 MaxCompute 的實現比較類似，採用的是多租計算+內部儲存的模式。計算和儲存的資源都是多租的，計算和儲存可以位於同一個機房內，物理位置比較接近。 優勢在於：

• 極致彈性 ，使用者可以在不持有物理資源的情況下，執行大規模的任務，並且可以按照使用者作業實際使用的資源收費。

• 內部儲存的實現 ，計算和儲存之間可以有大容量的頻寬，可以充分利用底層儲存特性來做優化。

這種模式的挑戰在於：

• UDF的支援 ：UDF是大資料場景經常會提供的一個功能，利用自定義函式的形式來支援複雜的計算。我們需要避免一個惡意使用者的程式碼威脅到平臺和其他租戶的安全。這方面BigQuery和MaxCompute有不同的實現，BigQuery在udf的支援上相對比較剋制，提供了js的udf，但是對能力做了一些裁剪，而MaxCompute則藉助安全容器來支援了完整的udf能力。

• 雲主機限制 ：在雲平臺上來實現安全容器會有二次虛擬化的限制，所以我們需要裸金屬或者物理機這樣的資源形態。

02

強多租的優勢與挑戰

介紹了常見的多租模式之後，我們來總結一下多租的優勢和挑戰。

多租的優勢在於：

• 可以開箱即用，無需建立獨立的資源池。

• 可以實現秒級擴容，極致彈性，單租資源依賴雲主機的話，從資源的購買到軟體環境的準備，可能要到分鐘級別，而在多租的平臺上可能只是一個配置的引數變更。

• 計費上可以做到按照實際計算開銷付費，而單獨計算資源池的收費是按照資源池的規格來收費，無論到底有沒有使用。

• 在成本方面，多租資源池通過不同租戶作業之間的削峰填谷，可以帶來更高的資源利用率，而云平臺將這部分讓利給使用者，可以帶來成本上的優勢。

當然多租戶也面臨著一些挑戰：

• 首先儲存方面，雲端儲存需要解決遠端讀寫和中間檔案儲存的問題，內部儲存可以實現定製優化，但是儲存的開放性是一個問題。

• 在資源排程層面我們需要保證不同租戶，不同型別的作業在平臺上能夠得到公平合理的排程，支援超大規模的計算節點。

• 執行時方面，需要支援UDF或者三方引擎的場景，需要實現執行時的隔離，保證租戶之間不會出現資料的越權訪問，或者單租戶的惡意程式碼影響到平臺和其他租戶的安全性。

• 同時對於使用者定製化的網路需求，也需要在租戶層面實現打通，不能夠做叢集層面打通。

我們通過一張圖來直觀地看下多租在安全性方面的挑戰。單租的資源池通過iaas層來做隔離，雲上每個資源是在獨立的安全組中；而多租的平臺上，多租戶之間的隔離則需要大資料平臺自己來保證。在這些挑戰中，關於資源排程層面主要關注的是大規模場景下的效能和可擴充套件性，而安全則是方案是否可行的關鍵。如果無法保障多租的安全，對雲服務來說是不可接受的。

03

MaxCompute多租實現

接下來，我們看一下MaxCompute產品在強多租方面的實踐。

首先簡單介紹下 MaxCompute 產品。

MaxCompute是阿里雲提供的適用於大資料分析場景的，企業級的雲數倉，提供的是全託管serverless的服務，在多租的實現上是一個強多租的實現 。我們支援了SQL, java 和python的UDF，支援計算平臺內部pai機器學習，同時也支援開源spark的任務型別。這些都是在統一的計算和儲存資源上提供的。

儲存方面 ，我們依賴自研的飛天儲存引擎pangu；使用了基於capability的許可權模型，在不直接對外開放訪問的情況下，許可權模型是可以簡化的；由於是內部儲存，我們可以實現分散式訪問，避免中心化節點帶來的效能瓶頸。同時對於作業執行過程中的臨時資料，我們可以利用內部儲存實現更好的local化和管理。

一個多租的資源池離不開一個好的資源排程引擎。

在資源管控的排程層面 ，我們實現了一套高效可擴充套件的資源排程系統，可以支援大規模的計算節點，同時保證不同租戶不同型別的任務在平臺上能夠得到相對公平的排程，做了完善的failover的處理。資源的形態上我們提供了預付費和後付費的資源形態，預付費資源能夠得到更多的資源保障，後付費的使用者則按照資源的需求規格和時間的先後順序進行排程。

在資源管控的主機層面 ，我們通過cgroup的機制實現了作業級別的資源管控，來保證一個作業的異常不會影響到其他作業。支援作業的不同啟動方式，支援以程序方式或者容器方式拉起，也可以同時管理cpu或者gpu的資源形態。

基於靈活性和擴充套件性的考慮，MaxCompute 在 sql 語言裡面支援了使用者自定義函式即UDF的能力，方便使用者對計算行為進行擴充套件，同時也引入了對三方引擎，比如 spark 的支援。這些對平臺來說是不可信程式碼，可能觸發非預期的系統破壞，或者惡意使用者進行攻擊。

我們通過輕量級的安全容器，實現了程序級別的隔離，也就是將不可信程式碼執行在安全容器內部。

在安全性上對vm核心進行了裁剪，去掉了不必要的核心功能，減少攻擊面，並提供必要的防護機制；對網路上禁止了預設的外部網路訪問；在啟動速度上做了優化，雖然我們是一個離線資料計算平臺，使用者對時延沒有那麼敏感，但是對整個鏈路上的優化也是我們一直努力的方向；同時降低vm的資源使用量，提高單機的計算密度，同時能夠執行更多的任務。

計算資料的讀寫，需要在vm內外建立高效的資料通道。考慮到MaxCompute的叢集規模和大資料計算任務時間短的特點，對安全容器的穩定性和效能都有著比較高的要求。

我們有了隔離的安全容器之後，針對類似spark的任務，節點之間需要互相通訊，類似spark的driver和worker之間需要進行任務的分發和狀態的監控，而這些需求無法構建在主機網路之上，所以 我們基於安全容器構造了vxlan的虛擬網路，讓同一個任務的所有節點執行在同一個虛擬網路中，虛擬網路中的節點通過私網IP進行通訊，無法訪問主機網路 。對於使用者定製化的外部網路訪問需求，比如常見的使用者訪問公網上的一個介面或者vpc內部的其他資料服務，我們也做了任務級別的網路打通能力。使用者在作業啟動時宣告需要訪問的網路目標，在必要的許可權檢查後，在任務級別實現網路的打通。

同樣我們還要關注效能和穩定性的問題 。雲上vpc的建立通常也是基於vxlan的技術，但是vpc的建立是相對固定的，一個使用者通常只有一個vpc，購買主機則是往vpc中新增節點，操作相對低頻。但當我們面對一個大資料平臺時，任務啟停是非常頻繁的，並且在短時間內拉起任務內的成百上千個節點，對效能上會有比較大的挑戰。

在單一的資源池上通過強多租的實現，讓更多的業務形態成為可能。

基於以上安全容器和虛擬網路的隔離， 我們在一個多租的叢集上提供了強大的UDF的實現 ，相對於其他平臺提供的UDF，我們在UDF的能力上限制更少，允許訪問本地IO和網路，能夠訪問使用者vpc內部的資料。

比如湖倉一體的場景中，我們可以通過建立networklink的方式打通對使用者vpc的網路訪問，在建立外部資料來源的時候關聯networklink後，就可以在MaxCompute內部通過sql訪問外部資料，目前這些在MaxCompute的平臺上都已經做了產品化的實現。

任務級別的隔離，使得我們可以在單個叢集內提供混合的計算形態，除了sql和udf的實現外，我們還支援了內部的pai機器學習平臺和開源的spark引擎。

04

Why & 後續演進

最後分享一下我們對於多租實現的一些思考，以及後續的演進方向。

回到設計的初衷， 我們為什麼要在統一的計算儲存的資源上實現了強多租 。MaxCompute是一個內部孵化的產品，目前集團內部90%以上的離線資料都執行在Maxcompute的平臺上。在業務形態上，我們期望相容hive的udf生態和對開源引擎的支援，而源於集團內部對於資料安全的要求，所以我們一開始就是多租安全的。在面向公有云服務時，我們又期望在資源粒度，彈性和成本上提供優勢，促使我們最終堅持了強多租的形態。

未來的演進方向有三大方面：

• 開放儲存 ：我們是基於內部儲存，開放性上會有一些問題，因此我們會在儲存層面面對計算的場景進一步提升我們的開放性。

• 單租計算 ：多租的場景下，某個大客戶的臨時突發的大規模資源消耗對平臺來說相對是不友好的，可能會導致其他使用者的作業產生排隊，所以在面對這樣的客戶時提供單租的計算形態也是一個選擇。

• 多雲 ：開放儲存和單租計算將來也會向多雲方向發展，為多雲形態提供支撐，方便使用者有更多的選擇，用不同的組合去實現使用者個性化的需求。