提高60%基礎資源利用率！中國聯通的容器化大數據平臺實踐

中國聯通數據中心總經理王志軍在Rancher舉辦的ECIC大會上的演講實錄，分享了中國聯通爲什麼開始進行平臺容器化並如何運用Kubernetes對9000臺的服務器數據節點進行最大化利用和合理調度，進而提高了60%的基礎資源利用率。

---

2019年6月20日，由Rancher Labs（如下簡稱Rancher）主辦的第三屆企業容器創新大會（Enterprise Container Innovation Conference, 如下簡稱ECIC）在北京喜來登大酒店盛大舉行。本屆ECIC規模宏大，全天共設置了17場主題演講，吸引了近千名容器技術愛好者參加，超過10000名觀衆在線上直播平臺觀看了本次盛會。

來自Rancher、阿里雲、百度雲、平安科技、中國聯通、飛貸金融科技、中國人壽、SmartX、華泰保險、廈門航空、JFrog、新東方、Cisco等十多家企業的技術負責人出席了本屆ECIC，現場帶來關於企業容器項目實踐經驗的精彩分享，爲參會的容器技術愛好者帶來企業容器化的經驗分享。

大會現場，中國聯通數據中心總經理王志軍爲現場容器愛好者帶來了主題爲《中國聯通容器化大數據雲平臺探索與實踐》 的內容分享。

中國聯通是國內三大運營商之一，同時也是國內首批將大數據平臺部署在容器雲上的企業。關於中國聯通在容器化大數據雲平臺上的發展和探索，王志軍分享道：「經過研究、探索和實踐，咱們發現Kubernetes+Docker的技術路線更契合聯通的實際需求，它幾乎支持了全部的容器業務類型，也正是基於聯通的技術選型，咱們引入了Rancher的產品部署和Kubernetes集羣管理功能，爲聯通的容器化大數據雲平臺提供更強而有力的容器技術及容器服務支撐。」

如下是中國聯通集團數據中心總經理王志軍的演講實錄：

你們好，很是感謝Rancher邀請咱們在企業容器創新大會上進行演講，我今天演講的題目是《中國聯通容器化大數據雲平臺探索和實踐》，內容是中國聯通是怎樣將大數據和容器化雲平臺相鏈接的。

建設背景

咱們一塊兒來簡單回顧一下中國聯通大數據和雲計算的發展歷程。大數據和雲計算分屬於兩個不一樣的領域，大數據主要關注怎麼將數據集中起來，挖掘數據的價值。雲計算主要關注怎麼更高效地使用資源，提高資源的利用效率。當大數據發展到必定階段的時候，它就會和雲計算不期而遇。

在大數據的方面，存在有幾個標誌性的事件和歷程，一是2006年Hadoop的出現，二是2009年CDH發行版的出現，到2012年，大數據出現了新的資源調度管理方式，流式計算技術好比Spark和Flink等。

雲計算的標誌性事件是從2006年亞馬遜提出EC2開始的，EC2的出現標誌着雲計算時代的開啓，2010年出現了OpenStack，這是咱們在部署私有云中很是普遍使用的一個技術，2013年是Docker的元年，讓容器技術風靡了雲計算領域。2014年Kubernetes的出現則將Container as a Service變成了被業界普遍接受的全新理念。大量的咱們原先在虛擬機上部署單體應用或者分佈式應用的架構逐漸變成了基於容器的微服務加工方式。

咱們所提出的ABC融合指的是AI+Bigdate+Cloud的融合。

在Bigdate 2.0時代，Hadoop商業版出現爲你們利用Hadoop進行大數據的處理提供了更好的方式。另外一方面，SQL on Hadoop逐漸成熟了起來。在咱們看來，SQL on Hadoop是一種更爲接近人類天然來進行數據處理的語言，它和咱們的關係數據庫並非一個很是緊密的耦合關係，咱們大量的實時處理是基於SQL on Hadoop去處理的。第三點是最開始咱們作大數據的時候，大量採用的是批處理的處理方式，如今咱們更多的是採用流失處理和批處理相結合以及交互是分析相結合的方式來進行的。

在Bigdate 3.0時代，大數據雲和AI已經融爲一體了，客戶但願能在一個統一的平臺上提供AI、Bigdate和Cloud。

中國聯通是整個運營商行業當中實現數據集中的企業，咱們擁有企業級全域數據的存儲中心、計算中心、能力中心和孵化中心。在運營商行業，他們的系統架構模式基本上都是分省來進行建設的，可是中國聯通在建設大數據平臺的第一天咱們就把數據集中聚集到總部的一個節點，咱們堅信數據只有匯聚才能發生化學反應，才能產生最大化的價值。

中國聯通擁有百PB級的數據吞吐能力和統一的數據服務能力。咱們數據中心的數據量超過100個PB。固然，數據量並非越大越好，數據自己是有成本的，咱們但願數據的成本和數據的價值能達到一個平衡點。另外，咱們有超過6500臺對內服務的服務器數據節點，以及超過2000臺對外服務的服務器數據節點，加起來有9000臺左右的節點數量。除此以外，從中國聯通的存儲能力上看，咱們目前的存儲能力可能接近200個PB。

全域數據匯聚和管理中心沉澱了海量的計算能力、存儲能力和數據能力，致使了中國聯通面臨着資源智能調度、最大化利用和能力共享的難題。

中國聯通有總體的數據中心節點，而在總部底下是中國聯通的省分公司和子公司，他們但願利用總部的大數據平臺去進行各自的數據處理和數據分析，所以產生了雲計算的需求。他們但願總部的節點可以爲它提供一個數據處理的平臺，省分公司和子公司在平臺上進行自身的數據加工和處理。

這是咱們自身優化的源動力，就是中國聯通自身的節點如何避免計算、存儲資源不均衡的調度，創新地爲租戶提供一樣的能力。這時候，中國聯通的大數據和雲計算就天然而然地走到了一塊兒。

探索歷程

咱們從2016年開始在中國聯通大數據雲平臺建設上投入很大的力量，也經歷了幾個不一樣的發展階段。

在最初的建設階段，咱們的資源是物理部署、人工劃配、系統運維，咱們經歷了大數據的總體發展歷程，在最開始的時候，你要作大數據，必需要經過物理機器來實現，你要部署一個Hadoop機器，若是你須要kafka，你還須要用物理的機器部署一個kafka，這是大數據平臺建設必然的發展階段。

下一個階段屬於優化提高階段，咱們但願經過一個集中工做組統一管理資源，在其餘人有資源需求的時候，咱們去作半自動化的部署、半人工的劃配，還有就是系統運維的簡單監控。

第三個階段就是經過大數據雲平臺提供一鍵部署，你須要一個大數據平臺，經過一鍵部署，我爲你提供一個大數據平臺，你能夠在上面去作自身數據的加工和處理。而你的數據能夠來源於總部的數據平臺，也能夠來源於自身的數據。這樣就實現了按需自動分配、彈縮，統一監控和統一運維。咱們目前已經在第三個階段了。

在中國聯通進行技術路線選型的時候，咱們面臨着Kubernetes和Mesos兩者之間的選擇。

咱們爲何選擇Kubernetes？由於Kubernetes幾乎支持全部的容器業務類型，包括長期伺服、批處理、node-deamon以及狀態應用等。咱們最開始在作容器應用或者是微服務應用的時候，更多的是無狀態的應用。但咱們提供大數據服務的時候，不少應用是有狀態的。

對Kubernetes和Mesos咱們進行了很是深刻的分析，尤爲是生態活躍度，Kubernetes的生態活躍度和社區關注度在急劇上升。咱們在進行技術選型的時候，包括它的使用場景、外部應用、中間節點和數據庫、有服務狀態等都進行了分析。另外，技術的成熟度是否有業界廠商的普遍加持，好比谷歌、亞馬遜、Rancher、IBM、阿里、百度等。Kubernetes有很是好的生態，因此咱們選擇了Kubernetes來解決聯通的實際需求。

談及Kubernetes時，無可避免地必定會說起中國聯通和Rancher的合做。

中國聯通在搭建Kubernetes和Docker容器化平臺的過程中，咱們引入了Rancher的產品去部署和管理多個Kubernetes集羣。咱們使用Rancher Server，經過圖形化和RKE兩種方式對多租戶的Kubernetes集羣進行部署和管理。

另外一方面，從咱們的角度來看，Rancher有豐富的容器化實施案例經驗，這塊正好彌補了中國聯通的一些不足之處，成爲咱們在處理和解決問題中的一個堅強後盾。咱們更加關注於怎樣把服務變成雲，而後開放給省分公司和子公司使用，咱們怎樣才能把數據處理的更好。而針對底層的服務，咱們但願藉助業界的合做夥伴和咱們共同解決。

除此以外，開源的產品常常會有重大安全漏洞，在這一方面Rancher能爲中國聯通提供一個很好的技術支持，爲中國聯通的雲平臺安全保駕護航。

平臺實踐

中國聯通提供幾個方面的服務，一是大數據即服務，好比咱們的省分公司或者子公司須要一個大數據平臺，咱們就爲它一鍵提供一個大數據平臺，包括Hadoop、Spark、Storm、impala等，一旦我能爲省分公司及子公司提供大數據平臺，他們就無需本身從新構建大數據平臺了。

二是中間件和數據庫即服務。對於省分公司和子公司而言，光有大數據平臺來進行數據處理是遠遠不夠的，這當中必然要用到不少中間件，因此咱們要爲他們提供中間件和數據庫即服務，這裏包括kafka數據庫即服務、Redis分佈式緩存服務、MySQL關係數據庫的服務。

有了以上兩者以後，咱們還能夠提供數據集成工具即服務，好比雲化ETL，我能夠去作數據抽取轉化，來爲省分公司和子公司提供調度。

咱們前面提到了ABC，進一步擴展，咱們能夠提供深度學習即服務，好比TensorFlow、Caffe等。

最後一個就是容器雲服務，咱們能夠提供應用託管的環境。

有了以上幾個服務以後，對於租戶來說，涵蓋了數據的加工、處理，流轉以及應用的提供，基本上就具有了PaaS平臺的框架了。咱們的省分公司或者是子公司就沒必要再去建設作本身的大數據平臺，若是他們要作大數據應用，就能夠放到總部平臺去作，至關於部署了一個任務在總部平臺上，對於他們而言，他們有本身的數據，也有本身的空間來作一個處理，咱們經過大數據平臺的方式知足了他們的這種需求。

以上還列舉了一些PaaS能力如Hadoop、Spark、Hive、HBase、ZooKeeper、Storm、Implpa等，另外包括分佈式數據倉庫、數據集市、實時計算、數據挖掘的引擎、信息檢索引擎等等。

還有，中間件及數據庫服務組件如kafka、MySQL，數據集成工具包括元數據管理、數據治理的服務，雲化ETL服務、數據集合管理的服務等等。

咱們目前還有不少其餘的服務，好比數據安全的服務、脫敏的服務、溯源的服務，這些咱們都經過雲的方式提供給省分公司和子公司。

不管是中國聯通的大數據基礎服務、深度學習框架、中間件及數據庫服務，仍是微服務的開發部署、數據集成工具等，這些內容不可能由單一的團隊完成，咱們有很是多的團隊，有些團隊專一於大數據基礎服務，有些團隊專一於將深度學習的框架部署在Kubernetes上，有些團隊專一於將中間件即服務的放到Kubernetes容器雲平臺上進行部署管理，這些都是由不一樣的團隊完成的，因此咱們須要有一個統一的管理平臺。

在這上面咱們使用的是Kubernetes Service Catalog和Open Service Broker。統一的集成框架像Kubernetes Service Catalog實現異構組件的統一納管，經過業界標準的Open Service Broker實現第三方組件的接入和擴展。當咱們底下有新服務的時候，咱們經過總體開放的架構接入新服務，開放給咱們的客戶使用。

咱們有四大類支持場景。第一種場景就是你須要一個大數據平臺，我爲你提供一個大數據平臺，這是最基礎的一個場景，也是最難實現的一個場景。第二種場景就是爲你提供大數據的服務組件，你進行數據加工和處理，好比提供一個分佈式的數據倉儲，你將數據拿進來處理以後帶走或者是拿來作其餘的應用。第三種場景是應用微服務化的容器化部署。最後一種場景是假設我爲你提供一個孵化平臺，提供樣本數據，提供數據處理組件，你本身去進行一些模型的訓練。

從租戶總體應用場景上看，最大的是進行模型訓練的，比例爲34%。省分大數據平臺構建佔比17%，容器化應用和服務開發部署佔比爲27%，大數據加工處理佔比爲22%。這是咱們目前的應用狀況。

咱們以前還有采用一種邏輯多租的方式，由於咱們有大數據平臺，有資源的調度和管理，咱們能夠採用邏輯多租的方式來爲你提供服務，但這具備必定的侷限性。而基於容器雲的大數據平臺更多采用的是物理多租的方式，能對資源進行有效隔離，能對數據進行有效隔離，服務進行有效隔離，業務進行有效隔離。我申請的這個東西是個人，和邏輯多組不同，邏輯多租總感受我和別人共享一個空間，而物理多租這個空間就是你的，你在裏面作什麼事情咱們無論，咱們只但願你講這個事情作得更加容易。

在這當中咱們確定會面臨一些技術挑戰。包括多種PaaS能力的集成。其二就是多個Kubernetes集羣的互通，由於咱們剛纔分享了中國聯通下面是有N個團隊的，大數據平臺服務可能分佈在一個Kubernetes集羣上，也有可能不止分佈在一個Kubernetes集羣上，是由多個Kubernetes集羣組成的。其三是大數據服務的容器化，好比Hadoop怎麼放到容器雲平臺上，Hadoop的部署方式是須要高度來進行規劃的，須要作到計算和數據的親和性，那這一問題咱們應該怎麼解決。最後是計算資源的本地化。

關於以上幾種技術挑戰，咱們有一些解決方法。多樣化PaaS能力的集成咱們會用Open Service Broker來解決這一問題。

Kubernetes集羣間網絡互通咱們會經過多機型的互通來解決，咱們有多個集羣，在大數據雲平臺上，咱們的應用能夠訪問你的Datanote，你的應用經過直接訪問Datanote寫入和讀取數據，API調用的問題經過定製Flannel網絡插件來解決，兩個集羣共用一個Flannel網絡，實現跨集羣pod IP直接鏈接。

對於Hadoop容器化如何完成部署的問題，這裏麪包括若是將Hadoop的服務進行拆分，如何完成角色規劃？將Hadoop按照組件進行最小單位拆分，經過親和的調度算法實現一個集羣的合理部署。拆分完以後怎麼解決服務之間依賴和發現的問題？集羣內部咱們使用Headless Service的方式來解決，咱們直接調用底層pod提供的服務。服務之間會經過DNS和配置注入的方式來進行發現。

面對Hadoop容器化計算本地化的挑戰，咱們採用k8s親和的調度策略，確保統一集羣的計算服務調度到相同的列表，第二步，咱們更改了Yarn和Spark的調度邏輯，判斷到對應的計算是否在同一個主機至上。第三步，多個pad咱們共享Domain Socket，並且每一個租戶的Domain Socket相互獨立。

中國聯通大數據雲平臺提供的PaaS能力有6大類30多種，咱們的集羣數量有437個。在大數據雲平臺，咱們開放給租戶來使用這一平臺，每個月執行MR/Spark任務16萬多個，實行的數據調度任務一萬五千多個。

咱們目前還在逐漸拓展使用的範疇，先前咱們不少小的省份公司已經將大數據平臺放到中國聯通大數據雲平臺上進行部署。下一步中國聯通會進一步擴大規模，將來絕大部分的省分公司、子公司都將大數據平臺放到這一平臺上進行部署。

後續咱們但願中國聯通大數據雲平臺不斷地進行演進，將Kubernetes自己當作一個服務提供給咱們的租戶，另外一方面咱們但願能夠提供FaaS，採用Serviceless的方式爲客戶提供更加方便的服務，它只需提供一個函數就能夠了，後臺服務能夠根據函數調動的狀況進行彈縮和縮放。

另外一個探索方向是支持物聯網的雲平臺。如今5G炒得很熱，不管是運營商行業仍是總體的社會，你們都在關注5G。5G主要解決三大問題，一是大帶寬，二是高密度鏈接，三是低延遲。高密度鏈接和低延遲這兩個問題都是屬於物聯網應用的問題。而咱們構建大數據雲平臺爲物聯網提供新服務，萬物互聯將產生更多的數據，數據如何進行實時處理？怎樣進行後續的分析和處理？咱們但願經過公共雲平臺的方式解決這一問題。

總結與展望

以上是中國聯通基於容器雲的大數據平臺建設狀況，目前看來咱們取得了很是不錯的一個成果。在將來，咱們將集成更多的能力，賦能前臺，實現智能管理，提高總體利用效率。