Everything On Kubernetes。

12月7日~10日，科技智庫甲子光年在線上舉辦2022甲子引力大會。在12月9日下午的“新一代數字基礎設施”專場上，智領雲聯合創始人&CEO彭鋒就《Data on Kubernetes雲原生資料平臺最佳實踐》發表了主題演講。

以下為彭鋒的演講實錄：

首先介紹一下我自己，我是彭鋒，武漢大學碩士，2000年左右去美國讀的博士，我和我的Cofounder宋文欣在讀完博士之後，先後入職Ask。com、Twitter、EA三個公司，都是從無到有地搭建了它們的大資料平臺，我們希望能夠把我們在矽谷的工作經驗形成產品，服務國內企業。

為什麼資料平臺會有云原生的訴求？這是Twitter十多年前的資料架構圖，最近馬斯克買了Twitter，開除了大概75%的員工，世界盃期間Twitter好像也沒有什麼事，系統都正常地執行，其實背後並不在於員工沒有價值，關鍵在於雲原生。

Twitter從2011年就開始建設自己內部私有云平臺，所有業務系統和大資料平臺全部在這個私有云上釋出，實現了業務開發效率和運營效率指數級增長，系統穩定性和系統資源使用率也不斷提升。Twitter大資料叢集從2011年左右只有80臺機器的Hadoop叢集，到上市大概8000臺機器全部是雲原生平臺，Kafka、Hadoop、Spark系統都在上面，以雲原生的方式為整個公司各個部門提供資料能力矩陣，而且絕大部分都已經自動化，所以機器死掉、系統宕掉全部可以自動恢復，這麼多年系統穩定性不斷提高。

與雲原生的資料平臺相比，傳統大資料平臺有什麼痛點？因為傳統大資料平臺比如Hadoop、HBase、Hive每一個都是獨立安裝流程，沒法共享這個資源池，每一個都有自己運維的機制，每一個都有自己分散式管理的機制，所以系統在執行的時候不僅安裝複雜，運維複雜，系統效率還特別低，而且對運維人員要求高。我們經常看到很多大企業即使叢集很大，但是系統各個元件都是各自為戰，沒法形成統一的體系，資源效率特別低，造成特別大的問題。

原來K8s還沒有那麼成熟的時候，對大資料支援比較差，大家沒辦法在K8s上跑大資料應用。但是一旦K8s相對成熟之後，各種各樣的系統都可以在K8s上執行，大家都想我能不能不要Hadoop，實現Cloud Native Data Platform without Hadoop，能夠把業務系統、資料系統、應用系統一塊跑。Hadoop的三架馬車，HDFS、Yarn和MapReduce，都會有Kubernetes上的方案來解決對應的任務，特別最近兩年K8s對有狀態服務的支援越來越好。所以，大家都想現在所有的業務系統在K8s跑了，可以一起管了，可以共享資源、可以共享工具、可以一起統計它的各種使用了，為什麼大資料系統還要單獨去搞一套呢？

去年有兩個標誌性事件，一個是Apache Spark從3。1開始官方支援K8s，第二Kafka去年5月也開始官方支援K8s，這兩個事件就標誌著最核心的大資料元件現在都支援K8s。據Gartner預測，部署在雲原生平臺上的資料應用將由2021年30%增長到2025年95%，就是說基本上到2025年95%的資料應用都跑在雲原生平臺上，這個雲原生平臺大機率就是K8s。

有這個趨勢之後，就出來一個名詞叫做Data on Kubernetes，也是今天我們介紹一個主題，這個詞還比較新，今年10月份北美的KubeCon剛剛結束，第一次組織了Data on Kubernetes專場，講如何在Kubernetes跑這個資料應用。在這個DoK社群組織的行業報告中，右圖展示的是這些使用Data on Kubernetes的企業，為什麼要把這些應用遷移到Kubernetes上，基於頭兩位的就是保證管理的統一性以及簡化管理。

在國內實踐中我們碰到的主要場景有下面四個。第一個是標準化管理，如何將釋出運維標準化，怎麼能夠讓大資料平臺和業務系統同時使用K8s一套基礎架構和運維工具；第二個是專案部署。有很多系統整合商和軟體開發的客戶，在專案實施和運維中他們想使用統一的叢集釋出，提升部署的速度，提升系統的穩定性，降低系統對硬體的要求，簡化運維要求。第三是有些大企業裡面，資源效率特別低，買了幾百臺機器，平時每個機器大概10%到15%的利用率，這個Hadoop Data node不能去跑AI的應用，它的任務完全沒法去混排，所以資源使用效率特別低，系統資源得不到有效利用，部門計算能力要求的時候必須購買新的硬體，效率很低。第四個場景就是所謂的DPaaS

（Data Platform as a Service）

。有很多大集團企業希望能夠在完善的多租戶管理體系下，為各個部門和團隊提供各自資料元件安裝整合，讓他們自助去完成資料應用開發。

這個解決方案就是Everything On Kubernetes，核心的變化就是把大資料元件和大資料應用的釋出與運維，用Kubernetes來標準化，解決剛才所提到的問題。這個裡面有個問題，Data on Kubernetes是不是之後把大資料元件容器化裝到K8s上就可以了？畢竟現在像Spark、Kafka都已經官方支援了，像MySQL、Redis也有一些官方和社群提供的容器化的解決方案，甚至K8s雲原生方案，除了把它們裝起來還需要幹嘛呢？

但是容器化只是雲原生資料架構六大特徵之一，僅僅容器化並不代表雲原生，雲原生還需要提供可觀測性，支援流水線即程式碼，還要支援多租戶和名稱空間的完善管理，需要應用都是面向服務的釋出，需要提供基礎架構的無關性，可以隨時在混合雲上釋出，可以在一個新的叢集上完整發布以前的架構，這種都是雲原生資料架構的特徵，不光是容器化一個工作就解決的。

所以在社群所做的容器化工作之上，還需要以雲原生的方式來執行現在大資料元件，並讓他們在統一平臺上能夠高效地執行。比如說，原來有很多大資料元件他們只能使用主機網路，不能用雲原生網路棧；比如說儲存只能在本機上，不能使用雲原生的PV，這些都需要做一些改造；比如說原來很多元件像kerberos釋出，有很多隻能使用NFS釋出，無法做彈性的擴容。把這些大資料元件完整地整合到一起，能夠以一個雲原生的整合方式工作，這是我們需要做的工作。

第一我們需要有個整合框架，讓所有元件以標準化的方式整合進來；第二整合進來之後需要把它們以一種標準化方式釋出到K8s平臺上，他們之間有依賴的時候我們怎麼處理，一個元件配置發生改變，他依賴的元件如何來進行相應的改變，如何在一個系統實現自動擴容和加容，如何實現系統發現問題的時候能夠自動遷移，這都是釋出服務需要解決問題；我們還要提供可觀測性服務，一個系統元件接進來之後，它所有資源使用情況，它的監控報警必須自動來接入，我們還需要把所有元件透過統一的排程來共享這個資源池，如果你這個所有元件都是自己來排程，就達不到雲原生這種排程支援的要求，所以說我們必須在存算分離基礎上能夠統一排程。

這些工作都不是各個元件自己能做的，需要在各個元件的基礎上來做。但我們認為這個工作不需要每個企業自己來做，所以我們就提供了Kubernetes Data Platform，簡稱KDP。給大家簡單介紹一下KDP大致的思路，KDP是完全基於Kubernetes釋出的雲原生大資料平臺，它所有元件都是K8s上釋出，實現剛才所說的所有功能，也對大資料元件進行了需要的雲原生改造。簡單來講，如果你有一個K8s Account，我就可以給你一個大資料平臺。我們已經與各種的公有云、私有云上的Kubernetes的版本成功對接，阿里雲、AWS、騰訊雲、華為雲、天翼雲、金山雲都可以快速釋出使用。

這裡面還是有很多工作要做，並不是簡單把這些元件裝起來就可以了。首先我們對很多現代大資料核心元件進行程式碼級別的改造，以支援K8s資源排程、網路、儲存，保證他們雲原生的方式來進行。第二我們以這種Operator / Helm chart方式來實現釋出和運維的標準化、自動化，擴容、降容都可以自動完成，絕大部分操作都不需要人工干預；第三是我們擴充套件並強化了這種多租戶環境，提供了各種安全認證鑑權機制，採用統一雲原生的Kerberos方式和Ranger的方式來進行授權和鑑權，讓我們用K8s的名稱空間實現了多租戶的管理，資源隔離，實現了按區域動態資源分配，並實現計費和審計。

我們基於OAM統一標準釋出各種應用以及管理流程，打通了各個元件之間的配置管理，應用配置變化的時候其他相應的配置全部自動發生調整，實現Infra as Code；我們對計算引擎在雲原生形態下進行最佳化，比如Volcano批處理的排程，解決了Spark on HDFS的Data Locality，保證所有的元件在一個系統中能夠在雲原生環境下高效實現資料的計算。此外，我們把日誌、監控、報警、異常檢測、計費、審計都做成統一的框架，所有的元件一旦接入都可以明確地在可觀測性服務中監控，在統一介面來進行管理。

最後簡單總結一下，我們認為KDP是面向未來的資料基礎架構，提供標準化大資料元件的部署和執行。我們在實踐中看到部署效率之前按天計，現在變成按小時計，以前資源效率10%、20%，現在我們可以達到50%、60%，運維效率得到極大提高，絕大多數運維操作是高度自動化，我們在各個專案看到整體效率得到非常大的提升。

所以我們這次推出的Kubernetes Data Platform，希望能夠為大家從傳統大資料平臺到雲原生的架構的大資料平臺轉換提供一些幫助。我們KDP正式在全國招募合作伙伴，以及客戶，如果有需要在K8s執行你的大資料平臺，或者是需要在K8s上服務客戶的大資料需求，可以聯絡我們，最後也非常感謝甲子光年給我們提供這個機會，給大家介紹我們一些進展，祝大會圓滿成功，謝謝大家！