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

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）首先要考量的是雲化模式，模式的不一樣如共享模式、獨享模式等，將直接影響雲化部署架構。

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

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

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的對接須要根據具體雲化環境定製，改形成本高；其次系統上雲後的彈性能力並無獲得提高，勉強能夠在線擴容，沒法實現閒時縮容。基於這兩個缺點的考慮，咱們嘗試了第二個雲化架構。

二、第二套雲化架構

爲實現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這些能夠提供對象存儲服務的開源軟件架構已經在生產實踐了多年;
• 開源生態的計算框架兼容對象存儲服務；
• 兼顧數據湖存儲選型，而後咱們嘗試了第三種雲化架構。

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

三、第三套雲化架構

爲知足存儲的彈性和海量存儲的需求，咱們引入對象存儲，爲兼容公有云、私有云和現有其餘成熟的對象存儲服務，同時儘量提升讀寫性能，在計算和底層存儲之間咱們加上一層緩存（選型參考JuiceFS、Alluxio）。其中存儲層，在公有云環境上直接選型公有云的對象存儲，在私有云環境下選型OpenStack Swift、Ceph、MinIO等成熟的開源方案。

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

總結和展望

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

利用容器化、服務網格、微服務、聲明式API等雲原生技術，實如今公有云、私有云和混合雲等雲化環境下構建和運行彈性可擴展的大數據系統，這是咱們對大數據雲原生的理解，也是咱們擁抱大數據系統雲原生的方式。

今天經過三個具體的大數系統雲化架構，給你們呈現一個完整的架構過程，但願能給你們帶去思考和幫助。而後咱們再回到開頭那個問題，雲原生大數據技術是不是新一代大數據處理技術，相信你們已經有了本身的答案。

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

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

數棧是雲原生—站式數據中臺PaaS，咱們在github和gitee上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，也能夠採集實時變化的數據，是全域、異構、批流一體的數據同步引擎。你們喜歡的話請給咱們點個star！star！star！

github開源項目：https://github.com/DTStack/flinkx

gitee開源項目：https://gitee.com/dtstack_dev_0/flinkx