數棧技術大牛分享：雲原生大資料系統架構的實踐和思考

ArchSummit2021年全球架構師峰會於4月25日-26日在上海舉辦，袋鼠雲運維開發技術專家沙章利（花名：浣熊）應邀出席此次峰會，並在4月26日下午的《彈性架構實踐》專題會場上為大家帶來《彈性雲原生大資料系統架構實踐》的演講。本次演講主要介紹袋鼠雲基於數棧、結合數年大資料基礎設施建設經驗，打造雲環境下的大資料基礎設施的實踐和案例，部分架構細節首次對外公佈，以下內容整理自本次架構峰會。

大家好，我是來自袋鼠雲的浣熊，感謝這次會議的講師們給我們帶來了雲原生技術應用的分享，感覺又開啟了幾個新脈門，解鎖了新的武魂。在接下來的分享中，希望大家跟著我們的實踐案例做一些探索性的思考。

首先我們快速回顧下大資料技術的發展，然後重點給大家分享我們最近幾年做的一些系統雲化架構，最後再做個迴歸總結，希望能給大家帶去有價值的思考。

大資料技術的發展

大資料技術的發展史也是大資料架構的發展史。

雲原生大資料技術是否是新一代大資料處理技術？

1964年，IBM釋出了System360，這是計算機發展史上的里程碑事件，System360上配備的磁碟驅動器(DASD)加速了資料庫管理系統（DBMS）和關係型資料庫的發展，DBMS和關係型資料庫的出現使資料處理的效率大大提升，一些規模較大的銀行、航空公司開始引入資料庫軟體處理業務資料，這可以追溯為第一代(大)資料處理技術。

隨著全球經濟的快速發展，需要處理的資料量也越來越大，單處理架構已經無法滿足資料處理需求，有問題就有解決方案，針對這個問題美國Teradata公司推出了平行計算的架構，就是我們今天常說的MPP架構，在MPP架構的技術基礎上，Teradata的資料倉儲建設技術不斷髮展，在與當時的巨頭IBM的激烈競爭之下，Teradata依託沃爾瑪建設了當時世界上最大規模的數倉。這一代技術的關鍵詞我們總結為MPP+資料倉儲。

Hadoop生態的出現多少有點意外（眼前一亮），Hadoop、HDFS及其開源生態圈可以使用更低廉的X86機器，透過快速橫向擴容的方式就能滿足PB級別資料處理的需求。十多年的時間，從Hadoop（MapReduce）到Spark、Flink等，開源生態的計算框架不斷演進，基於記憶體的Spark、Flink計算架構已經與具體的儲存解耦，奠定了開源生態大資料系統計算與儲存分離架構的基礎，我們把開源生態這一系列看作是新一代大資料技術。

在雲端計算紅利的推動下，大資料系統上雲是必然的趨勢，Teradata在2016年把自己的資料倉儲搬到了公有云上，AWS也在2014年上架了資料倉儲型產品Redshift，阿里雲上的MaxCompute（早期叫ODPS）是國內雲上高效能並行大資料處理技術的里程碑。

去年9月份Snowflake的上市，把雲原生資料倉儲的話題推上了風口，公有云廠商開始從自家雲產品的角度做出對雲原生資料庫、資料倉儲、大資料平臺等的解答。相比較前幾代大資料處理技術，雲原生大資料處理技術是否能稱為新一代大資料處理技術呢？帶著這個問題，我們來看下在大資料系統雲化方面我們的一些架構實踐。

大資料系統雲化實踐

公有云上的大資料產品已經發展成熟，由於社群發展成熟、技術自主可控等特點，開源生態大資料體系已經在國內外頭部公有云平臺上先後上架，各家公有云廠商配套上架了成熟的資料開發套件。

經過了數年大大小小生產級實踐檢驗，直接選型公有云大資料產品，即可享受按需建立、秒級彈擴、運維託管和海量的大資料處理能力。然而由於種種限制，一些傳統大型企業、金融行業等的核心業務並沒有到公有云上。各行業在追求雲端計算紅利的程式中，又希望把更多的業務系統上雲。在這種衝突下，私有云和混合雲得到不斷髮展，這類雲上的產品形態也日漸豐富，已經由早期的ECS自由逐漸發展成中介軟體自由。

大資料時代，大資料處理和分析是企業的共性需求，以批處理和流處理為代表的資料處理平臺逐漸下沉為企業的大資料基礎設施，若能實現大資料基礎設施自由，即實現大數系統的按需建立、按需擴縮、運維託管，即可為企業內和行業客戶提供快速可複製的大資料處理能力。

開源大資料處理系統以複雜著稱，以數棧為例，底層的存算層相容主流的Hadoop發行版，中間的的計算層可開放整合主流的批流、演算法、圖計算框架，既支援傳統的MapReduce計算框架，也支援存算解耦的記憶體計算框架，上層應用層建立在資料共享、資料資產管理、資料視覺化管理等核心資料應用之上。

在VM/PM環境下，部署和運維這樣一套大資料基礎設施系統，也不是一件容易的事情，早期需要我們1-2名中高階實施工程師，連續1-2周時間，才能完成這樣一套系統的部署和除錯。如何實現整套系統的雲上自動化交付，成為我們系統雲化架構的第一個目標，即實現大數系統的雲上體驗、按需建立。

1、第一套雲化架構

第一目標達成關鍵是雲化部署架構和自動化部署技術。

1）首先要考量的是雲化模式，模式的不同如共享模式、獨享模式等，將直接影響雲化部署架構。

共享模式下一般以多租戶的方式支援，一個機構共享一套基礎設施，套內共享儲存、計算和資料應用，資源之間以多租戶的方式進行邏輯隔離，共享模式的優點是部署簡單，缺點是租戶間資源會相互搶佔。

獨享模式的隔離性會更好，但是按需建立的自動化部署技術是個難點。

2）第二個要考量的是公共系統對接，例如對接IaaS獲取動態IaaS資源，對接使用者、升級、監控、計費等公共模組，這部分不多說。

3）第三要考慮雲環境下的網路環境，比如管理網（underlay）和VPC（overlay）網路劃分情況，網路訪問策略在制定部署架構前需要清晰。

4）最後也是最重要的，在環境準備好之後，如何高效的完成系統的自動化部署、服務發現、健康檢查、監控資料接入等就比較關鍵了。

為完成系統的自動化部署和監控運維，從2018年開始，我們自研了部署運維管家EasyManager（以下簡稱EM），EM的核心能力之一是實現對資源的管理和服務的編排、管控。

把EM的Agent和服務編排模版打進系統映象是自動化部署的最佳實踐，VM啟動的過程就是服務啟動的過程，服務啟動後自動註冊至EM-Agent-Server，上層管理網路透過Agent-Server以服務的粒度實現對系統服務的管控，同時基於自動的服務發現機制，配套實施監控資料自動採集彙總、供查。

系統自動部署起來後，在獨享模式下，為實現動態叢集（例項系統）的訪問，我們引入Traefik來解決動態代理問題，Traefik是一個不錯的免開候選，Traefik支援從Zookeeper、Redis等配置中心動態載入路由配置，自動化部署模組拿到叢集（例項系統）地址資訊後寫入配置中心，Traefik熱載入配置並根據路由規則進行請求轉發。結合Traefik動態路由的能力，訪問請求可以透過統一的IP或域名進入，經由Traefik根據全域性唯一的叢集（例項系統）ID進行請求轉發。

解決了以上幾個關鍵問題之後，第一目標基本可以達成，配套上訂購（建立）頁、例項控制檯，就完成了大數系統雲化架構的第一個實踐探索。這個實踐的結果是可以實現5-10分鐘快速建立一套獨享的（雲化）大資料系統，且支援線上擴容，基本實現了上雲體驗、按需建立的系統雲化目標。

這套雲化架構沒有動業務系統本身的架構，容易落地是優點。當然缺點也很明顯，首先不是標準化的雲化方案，各個依賴系統如IaaS的對接需要根據具體雲化環境定製，改造成本高；其次系統上雲後的彈效能力並沒有得到提升，勉強可以線上擴容，無法實現閒時縮容。基於這兩個缺點的考慮，我們嘗試了第二個雲化架構。

2、第二套雲化架構

為實現IaaS層對接標準化，我們做了系統的容器化改造和Kubernetes部署對接，並自研了無狀態應用和有狀態應用部署Operator。在系統元件全面容器化的基礎上，結合一套自定義的Schema，構建面向Kubernetes的製品包，這個製品包可以透過EM一鍵部署到Kubernetes叢集。

為實現系統彈效能力的提升，依託開源社群計算框架對Kubernetes的適配，我們做了產品層的封裝，實現了把Spark和Flink的計算任務提交到Kubernetes執行。利用Kubernetes強大的資源管理能力，實現計算資源的彈性擴縮。

這套架構的另一個特點是相容On Yarn模式，這個點很受企業的歡迎，原因是即能擁抱Kubernetes大/法，又能繼續使用已有的Hadoop基礎設施進行生產，相容幷蓄，領導開心。

這套雲化架構可以解決上一套遺留的問題，透過整合Kubernetes，實現對底層IaaS資源對接的標準化，同時提升了計算資源的擴縮能力，理論上是秒級的。當然也產生了新的問題：

• 計算任務提交至Kubernetes後，計算資源的彈性得到保障，但同時計算真正意義上的遠離了資料，這對計算效能是否有不良影響？
• 計算的彈性解決了，那儲存的彈性怎麼辦？

第二套雲化架構上，架構調整的角度已經從部署架構轉移到系統架構層面，我們開始調整系統的計算架構，即用Kubernetes代替Yarn作為計算資源管理者，這是在面向雲環境做系統架構適配。

在我們進一步考慮儲存架構調整的時候，我們重新審視系統雲化實踐的過程，我們發現我們的實踐思路發生了改變，總結下來就是從構建雲（雲化）到基於雲構建的思路轉變。大資料系統的彈效能力也是資料的處理能力，從彈性的訴求出發 ，利用雲化或者雲原生技術統一管理資源池，實現大數系統產品、計算、儲存資源池化，實現全域性化、集約化的排程資源, 從而實現降本增效。

我們再回到大數系統雲化架構上，產品和計算資源已經可以透過Kubernetes實現資源池化管理，考慮雲化環境下實現儲存能力的彈性訴求，依託計算框架對底層儲存的解耦合，參考物件儲存在公有云上的實踐經驗，我們把底層儲存切換成分散式物件儲存，這個架構選型上主要考量以下三點：

• 在私有云環境下，基於OpenStack、Swift、Ceph這些可以提供物件儲存服務的開源軟體架構已經在生產實踐了多年;
• 開源生態的計算框架相容物件儲存服務；
• 兼顧資料湖儲存選型，然後我們嘗試了第三種雲化架構。

雲原生技術驅動下的大數系統雲化架構演進‍

3、第三套雲化架構

為滿足儲存的彈性和海量儲存的需求，我們引入物件儲存，為相容公有云、私有云和現有其他成熟的物件儲存服務，同時儘可能提高讀寫效能，在計算和底層儲存之間我們加上一層快取（選型參考JuiceFS、Alluxio）。其中儲存層，在公有云環境上直接選型公有云的物件儲存，在私有云環境下選型OpenStack Swift、Ceph、MinIO等成熟的開源方案。

這套架構重點是從儲存的角度，嘗試改造系統的儲存架構，同時相容現有的HDFS儲存，相比之下更適合在動態的雲環境中落地，實現應用、計算、儲存三層彈性可擴縮。目前這套架構還在內部效能測試中，如下是們其中一組效能測試資料（大檔案詞頻統計），加上效能和快取最佳化後的儲存效能符合預期。

總結和展望

參考雲原生基金會（CNCF）對雲原生的定義，“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和執行可彈性擴充套件的應用”，從定義上看跟我們大數系統雲化的需求不謀而合。

利用容器化、服務網格、微服務、宣告式API等雲原生技術，實現在公有云、私有云和混合雲等雲化環境下構建和執行彈性可擴充套件的大資料系統，這是我們對大資料雲原生的理解，也是我們擁抱大資料系統雲原生的方式。

今天透過三個具體的大數系統雲化架構，給大家呈現一個完整的架構過程，希望能給大家帶去思考和幫助。然後我們再回到開頭那個問題，雲原生大資料技術是否是新一代大資料處理技術，相信大家已經有了自己的答案。

每一代大資料技術基本都是為了解決上一代技術存在的問題，雲原生的方法論和技術路線契合了大資料系統雲化過程中求彈性、求擴充套件的訴求，對大資料系統雲化具有指導和實踐意義。當然雲原生不是銀彈，只有結合自身業務系統的發展訴求，才能更好的享受其帶來的紅利。

最後做一點展望，由於種種限制和雲化技術積累不均衡（公有云的技術積累大於私有云、混合雲）等原因，公有云和私有云混合架構場景有待進一步探索和實踐。資料湖和大資料雲原生的架構呈現一種架構融合的趨勢，我們會在雲原生的湖倉一體的新型融合架構上做更多的嘗試，謝謝大家。