DBOS: A DBMS-oriented Operating System

語言: CN / TW / HK

背景

該論文介紹了一種作業系統的全新實現方法。作者認為,全新的叢集OS底層應該基於具備分散式事務能力的DBMS,並將這種新的系統明命名為DBOS(Data Base Operating System)。作者並在論文中展示瞭如何利用DBMS構建作業系統必備原語,如Scheduler、IPC、Filesystem。

現有OS問題

Paper的作者們注意到了近些年的技術發展趨勢:

  1. Scale:單機/叢集的資源越來越多,從數十年前的單核發展到現在單機都能輕鬆上百核、數TB記憶體、數百TB外存。OS所管理的硬體資源呈指數級增長
  2. Clouds:這是近些年來最火熱的技術方向。雲的出現,尤其是公有云進一步增加了資源管理的複雜度
  3. Parallel computation:這不是什麼新概念,但是隨著大資料技術的引入,這個規模進一步擴大,作者在Paper中列舉了一個數字:大型雲廠商同時管理10^8個Spark Task已經很常見
  4. 異構硬體:除CPU外,TPU、GPU、FPGA等新硬體層出不窮
  5. 新應用:以ML、IoT、Big Data等作為代表
  6. 新程式設計模型:Serverless為典型代表,應用只關注邏輯本身,不再care硬體資源
  7. Age:Linux太老了(我相信Linus不同意)
  8. Provenance

Paper的提出者們注意到現有的Linux等OS在處理這些問題上顯得有些力不從心。例如,在Scale問題上,Linux花了數十年時間才在單節點上支援多核排程,而還沒法做到多節點排程。即使能將傳統OS與叢集管理系統如Kubernetes等強行糅合在一起,效果也不是很好。

另外,Linux核心對新硬體支援不夠好,這些新硬體更多的是通過非OS來管理,即使是很常見的網絡卡、儲存裝置等也越來越多通過kernel by-pass的方式來操作以追求更好效能。

最後,對於Serverless這類應用來說,Linux的某些機制顯得太過複雜(複雜在哪?)

最為關鍵的,類Unix OS的設計哲學:Everything is file,對當下的應用來說,抽象層次太低。作者認為,急需一種更高階的抽象來取代:Everything is table。將所有的資源以及管理抽象為DBMS的關係表。

Rethinking The OS

作者認為,當前OS的很多資源問題最終可以歸結為Big Data問題,需要按照Big Data的思路來解決,因而提出了新的OS架構:基於DBMS的OS,這完全區別於傳統的OS架構體系。

Level 4:應用層。DBOS的應用主要針對分散式應用,如平行計算、Mache Learning等。DBOS支援Serverless程式設計模型,使用者需要將其應用分解為sub task,每個子任務將被DBOS按照資源使用情況排程至底層計算節點上。這些子任務之間的通訊是通過IPC,最終也是構建在Level 2層的DBMS之上。

Level 3:OS功能層。該層提供了OS的基本原語,如Scheduler、FileSystem、IPC等。這些能力都是構建在Leve 2的DBMS之上的,也享受了DBMS帶來的好處。例如 高可用、事務、安全等能力,這些都是當前資源管理的痛點。在DBOS中,所有的OS基本功能都會被對映為DBMS中的Table,所有的排程等管理任務最終都被轉化為SQL + UDF來操縱這些表,寫一個OS就是在寫SQL,是不是很酷。後面還會提到典型的OS模組怎麼轉化為SQL。

Level 2:Distributed DBMS。主要是利用當前成熟的分散式記憶體資料庫來儲存狀態,提升可用性。同時,因為是全記憶體設計,效能應該也能滿足OS的需求。典型的又VoltDB、Hana、MemSQL等。

Level 1:Microkernel services。DBMS執行環境,可以直接執行在Linux上,也可以執行在基於硬體構建的runtime,相當於直接將DBMS跑在Raw Device之上,效率自然更高。

DBOS三部曲

作者提出了構建DBOS的三部曲: DBOS-straw、DBOS-wood、DBOS-brick。

DBOS-straw

屬於原型驗證階段。在該階段,Level 1直接使用Linux,Level 2選擇一個成熟的RDBMS(VoltDB),實現Level 3部分最小功能並在Level 4上建立一些測試驗證應用來跑通整個流程。

DBOS-wood

在該階段會將DBOS執行在真實環境的Linux叢集中。作者期望構建一個Serverless執行環境來支援Task執行。該階段的目的是基於DBMS構建的DBOS基礎功能能執行實際應用並且表現的不錯。

DBOS-brick

該階段的主要工作是構建Level 1,但不會考慮重新構建Level 2。

DBOS實現

作者在論文中也提出了基於DBMS構建DBOS的具體方法以及效能評測,主要是OS三大元件:Scheduler、IPC、Filesystem。

Scheduler

要實現排程功能,在DBMS中建立兩張表:Task和Worker。其中Task儲存應用的子任務資訊,而Worker儲存計算資源。

Task (p_key, task_id, worker_id, other_fields)
Worker (p_key, worker_id, unused_capacity)

Task中的worker_id記錄了該Task被排程至哪個Worker,other_fields則記錄Task排程相關資訊,如優先順序、建立時間、執行時間等。

Worker則代表可以執行Task的數量。unused_capacity記錄了當前Worker還可以排程多少Task來執行。

有了上述兩張表,一個最簡單的Scheduler就呼之欲出了:

據作者測試,這種最簡單的排程器可以達到每秒排程1M個Task,且排程延遲平均為200us。

基於這種最簡單排程器可以演變為locality-aware scheduler,即將Task排程至其資料所在的Worker上,如下:

相比於第一種排程策略,這裡只是傳入引數變成了Task Home Directory,而這個資訊也是從FileSystem相關Table中查詢獲得。

最後,把第一種排程策略再改吧改吧就可以實現資源最少優先排程:

可以發現,在DBOS中,該表排程策略只需簡單調整下SQL。

IPC

典型的跨節點的IPC包括TCP/IP、gRPC等,他們都提供諸如可靠傳遞、按序傳遞、exactly-once等語義以及流控等機制。在DBOS中要實現類似機制,只需定義一張Message表:

Message(sender_id, receiver_id, message_id, data)

其中data記錄訊息內容。

傳送訊息時,Sender向該表中寫入一條記錄,Receiver只需要讀該表即可獲得訊息。DBMS本身提供了訊息的可靠儲存,只要我們通過保證message_id順序就能實現按序傳遞,只要接受者在處理完訊息後使用一個delete就能實現exactly-once,最後,由於DBMS的大容量和高吞吐,流控就顯得不再必要了。

作者還將DBOS的IPC同TCP/IP、gRPC實現作了效能對比。下圖是最簡單的Ping-Pong測試:

File System

File System在DBOS中涉及到的Table比較多,這裡暫時不作詳細描述,感興趣的讀者可以自行移步原始paper,作者同樣與Ext4作了效能對比,並顯示了相當有競爭力的結果。

寫在最後

這幫資料庫的前輩們已經將注意力放在資料庫的應用之上,而不僅僅侷限在資料庫內部技術優化,這給我們也提供了一個開闊的思路。另外,根據內部人士瞭解到,該專案野心非常大,參與方有MIT、StanFord、Google、Vmware等,在github上看到過他們的專案(自行搜尋dbos-project),但目前已經轉為private,希望有朝一日能重新開源,一睹芳容。

參考