本文部分内容依據周昕毅老師和童光輝老師的〖deeplus直播：話題接力丨大數據上雲，如何發揮出1 1＞2的優勢？〗線上分享演講内容整理而成。

近年來，通過融合大數據與雲計算技術，利用雲計算對資源的彈性管理能力，以破解大數據領域面臨的資源管理粗放、資源利用率低等困境，已經成為業界發展趨勢。進入雲原生時代後，大數據和雲計算進一步深度融合, 擁抱雲計算走向雲原生化。企業應該如何做好大數據平台的雲原生改造和升級，讓大數據上雲發揮出1 1＞2的優勢？

為此，dbaplus社群邀請到攜程研發總監-周昕毅、騰訊PCG大數據平台部SRE負責人-童光輝兩位老師，希望彙集兩位大數據專家的研究成果和實踐積累，給大家進一步明确大數據平台發展的方向，提供可參考、可落地的大數據上雲實戰經驗。

Q1

如何理解“大數據上雲”當中大數據與雲原生的關系？目前大數據上雲是否已成業界常态？

周昕毅

攜程的大數據平台進行雲原生改造已經大約有2年時間，關注點主要在于運維的标準化、提升系統的可觀測性、提升容量管理的能力，這些方面都按照雲原生的最佳實踐作為指引。對于雲原生幾個核心的落地技術，比如容器化技術、服務網格、微服務、不可變基礎設施，是作為我們設計架構的參考。但對于大數據平台存儲的一些基座去進行雲原生改造，其實也會遇到比較大的挑戰，所以我們目前還是解決一些管理工具的微服務化。

是否上雲，何時上雲，與各家公司的數據規模、發展階段、基礎設施和工具選型有關，各家公司一般會從效率、成本等角度選擇适合自己業務場景的上雲方案。

童光輝

大數據和雲原生在最開始的時候其實是兩個話題，大數據遠遠早于k8s的流行，在Google著名的“三駕馬車”之後，大數據開始發展起來。在k8s開始流行的時候，當時也不是大數據雲原生，我們主要會做一些離在線的混合部署，從而提高我們的資源利用率。

下一個階段是在矽谷以Snowflake為代表公司，他們會做簡單的一站式以提高效率，把大數據進行一定的雲原生改造，然後做相關的存算分離，這個模式被多數人所接受。因為從交付到部署再到使用，大數據被發現還存在着很多效率上的不足，通過結合雲可以把它做得更好，而且矽谷已經有大量公司上市作為典範。國内則可能是在2019年之後，很多公司開始把大數據和雲原生結合起來做大數據上雲這件事，在近一兩年裡，大廠BAT、攜程、美團等企業的大數據上雲相對而言已經比較深入了。

所以今天讨論大數據上雲，我希望可以回到大數據上雲之後在效率和成本方面能夠得到什麼，在這個過程中其實還有很多坑和問題，并不是簡單地将大數據與雲原生疊加起來就可以得到1 1＞2的收益。

Q2

能否分享一下貴司圍繞大數據上雲做的相關實踐？目前已取得了哪些成果？有哪些可參考、可落地的經驗總結？

周昕毅

攜程大數據平台目前還是以私有雲自建主體，在公有雲上也使用了部分産品，包括SaaS的産品、一些IaaS的基礎設施，以及搭建的一些服務，可以說是比較初期的混合雲架構。在海外的一些數據平台也有使用公有雲實現大數據的SaaS服務等相關實踐，但是主要的流量和數據量依然在私有雲的平台上。

目前也在推進一些冷數據的項目，我們發現對象存儲可以解決多數存算分離的場景，因此我們的私有雲和公有雲現在都大量在使用對象存儲服務。私有雲對象存儲主要存放一些對延遲比較敏感的相對熱的數據，而冷數據我們是通過控制帶寬的方式分批傳輸到雲的對象存儲上，雲上也可以使用一些價格比較低廉的歸檔型的存儲以節省成本，基于對象存儲服務構建雲原生的數據湖。

我們認為對象存儲能夠解決一些實際問題，同時我們也在謀求落地的場景。比如用JuiceFS把對象存儲的一些Bucket和桶通過POSIX協議挂載到服務器上，從而可以更靈活地讓很多還沒有來得及做雲原生改造的應用用到雲原生的數據存儲，然後我們也在嘗試把對象存儲作為HDFS集群的存儲基座，目前隻是少部分的嘗試。

我們在這幾個方向上都有做一些探索性的實踐，而我們大數據一些計算引擎相關的集群是比較适合做雲原生改造的，因為我們先做計算的改造，後面存儲暫時沒有大的變動。比如Flink的實時計算，我們已經支持它能夠提交到私有雲的K8S集群或者Yarn集群，也可以提交到公有雲的k8s集群，能夠做靈活的資源調配。

童光輝

我們的團隊圍繞大數據上雲的實踐有以下幾個方面：

首先在最大規模的HDFS存儲這一塊，我們還是采取裸金屬的方式，因為它很重要，且體量大，短期收益不大，因此我們短期内不會進行大幅度改造。

然後我們在分布式計算這一層做得比較深入，最開始我們是做一定的在離線混部，在線和離線相對還是比較隔離的兩套k8s環境，後來我們發現效率和質量方面還是存在一些問題。到現在我們已經把在線和離線通過内部的調度系統屏蔽成一層，相當于一個完整的資源點，能夠充分地使用在離線的資源。同時如果在線的資源需要緊急擴容，它可以搶占一部分的離線資源，但是它會遵循相應的質量策略，比如哪些應該先被下線或者銷毀，從而做到在離線資源的打通。

在其他領域我們做了更大膽的上雲動作，比如在MQ這個領域，因為我們底層所用的機器很好，單個的程序無法把一台機器利用率跑得很滿則比較浪費，所以我們把存算一體的kafka全部搬到k8s集群裡，需要遷移時kafka調度先把數據進行遷移，再返回來去做k8s Pod的銷毀，通過容器化提高機器的利用率實現了比較好的成本優化。

另外，在上層的應用組件方面，比如impala、presto查詢，我們選擇存算分離方案，因為底層的HDFS，包括對象存儲，相對來說是比較穩的，在計算層我們就把impala、presto直接放到我們的容器裡面。我們的查詢有時候比較大，如果用傳統物理去部署在資源擴容上效率有一些瓶頸，容器化後大的查詢就擴容，不需要就銷毀掉一部分容器縮容，實現效能的提高和成本的優化。

在這幾個方面我們會做得比較多，在公有雲上我們可能會做更大膽的嘗試，把底層的所有環境都換成雲原生。如果客戶需要一整套的大數據環境，他可以勾選他想要的，我們則快速實現部署的能力，給他交付出他想要的私有雲環境。

Q3

當企業大數據平台面臨哪些場景需求和痛點的時候，可以考慮大數據平台上雲？需要具備哪些上雲條件？上雲初期應當注意哪些問題避免踩坑？

周昕毅

我們遇到什麼場景的時候可以考慮上雲，其實也不局限于大數據的工具，可能上雲的其他在線應用也有類似的情況。

第一個方向是快速嘗試最新技術棧。雲廠商在各技術領域都會适時推出新技術棧的SAAS服務，可以讓企業快速上手，降低适用門檻。

第二個方向是雲廠商的高性能硬件。例如新型号GPU、新一代CPU、高性能SSD硬盤、百GB網卡等高性能硬件，在AI/BI領域可以發揮極大作用。

第三個方向是彈性需求。大數據平台的寫入需求和查詢需求往往在一天内有明顯的波峰波谷，通過雲的彈性能力可以嘗試進行計算資源的自動擴縮容，對數據存儲進行冷熱分離。

最後一個方向是高性價比的S3對象存儲服務，這也是攜程用的感觸比較深的方向。主流雲廠商都會提供兼容S3協議的Object Storage Service，适用場景衆多，成本低廉，天然支持存算分離的應用架構。如果對于對象存儲有需求，但是又缺乏部件，這也是一個不錯的切入點。

童光輝

上雲聽着很美好，且是技術正确的一個選擇。但我覺得需要回歸到本質——我們想要什麼，即企業的痛點是什麼？到底是想解決人的問題，還是想解決購買資源的錢的問題。

我覺得在中小型企業可能優先考慮解決人效的問題，其實要做整個大數據上雲，上雲隻是冰山上的東西，冰山下的服務器、帶寬、基建等一切東西，需要一個完整的支撐團隊去思考和解決，一般的小企業難以負擔這個成本。所以我覺得中小型企業盡量考慮用各種比較成熟的雲上組件，實現從自己小的私有雲放到了雲上的公有雲，可能在資源上會略貴，但是人力成本和質量保障方面會更好。

對于中大型企業來說，可能既要解決人的問題，又要解決錢的問題。如果企業資源利用率特别高，且沒有能夠做得更高的手段，那麼上雲需要慎重考慮。如果企業資源利用率還有很多提升空間，那麼需要考慮是不是在上雲過程中可以解決。因為如果從省錢的角度，把服務器壓榨到極緻，同時團隊有足夠的人力和資源，可以考慮從供應鍊的角度出發，在服務器采購、機房選擇、帶寬的支撐能力上，需要做哪些能力才能把雲上的服務器、應用程序利用率做到極緻，最後為企業節省成本，同時借助上雲過程各方面的改造，實現人效的優化。

其實我覺得上雲本身是一個企業IT治理的過程，它不僅僅是把一個東西放到k8s就完成了的事情。既然是IT治理，那麼其實是一個非常體系的思考，裡面也有非常多的問題點，所以上雲之前一定要思考清楚，我甚至了解到部分團隊上雲之後發現成本更高了。所以企業需要注意：不要為了上雲而上雲，而是需要明白自身到底想從上雲過程中得到什麼。

Q4

在具體實踐中，雲原生技術是如何對大數據平台進行改造和升級的？主要涉及哪些方面的實踐？

童光輝

以我們的MQ為例，上雲之後我們做的第一件事情就是把我們整個現有服務器的選型，包括上面的應用場景，以及後面我們設定的利用率提升目标提前規劃好。

其次結合我們的整體架構能力、對質量上的需求，以及最終和k8s相關的調度方面的配合，也要做好規範，滿足上雲最基礎的設計。

存算一體上雲有一個很重要的地方，我們要适當降低它的遷移動作，那麼Pod的規格設計要結合機型去做，在保障裝箱率的情況下盡可能降低一些遷移導緻的數據搬遷的頻次。而且因為大數據我們的流量會比在線高很多，所以需要考慮清楚容器網絡模式和機房帶寬。

在實現上雲的路徑上，也要考慮到整個運維支撐能力的建設，因為在傳統機器，如裸金屬或IDC機器上的運維，服務器投放、機器初始化等和雲上面還是會有所不同。此外，在Pod銷毀或k8s遇到各種各樣的故障時，我們的SOP、自動化工具也要提前做好準備。

最後就是要做好各方面的風險評估，并且做好演習，再謹慎地操作上雲的節奏，以免出現比較大的問題。比如機器上可能磁盤滿了某些自動運維工具會做一些日志數據删除，kafka數據落盤結尾就是.log的，被誤删就會造成數據的丢失。

大數據上雲過程裡還會有很多細節性的問題，這裡不一一列舉了。總結起來就是：首先要做好整個架構評估和質量保障的風險評估，然後做相應的架構設計，工具的建設一定要先行，再逐步上雲，而不是盲目追求速度，否則遇到重大的質量問題時可能會比較被動。

周昕毅

大數據平台其實是一個非常典型的有狀态應用，而且是一個比較有曆史的應用，比雲原生的概念提出早很多，因此它的組件、運維模式和發布模式都相對偏傳統，而且很難掉頭，因為它的集群體量很大，且比較核心，很難像在線應用一般通過擴縮容的方式重建。所以我們就像要給一架運行中的飛機換零件一樣，需要一點一點去做。

剛才童老師提出來的謹慎非常重要，就是工具先行，可以先完成日志收集、監控、演練、災難恢複等部分的工作，在一些小的集群上先積累充分的經驗，才能去動最核心的大集群，不能一步到位、一蹴而就。好的架構是演進出來的，并不是通過牛逼的架構師一開始就能夠定出來的，所以對于團隊而言也是一個不斷學習和總結的過程。

核心的思路就是先把日志和監控兩方面做好，那麼我們就有了一個眼睛，然後通過災備技術，我們有了救命的稻草，或者說救火的工具，确保出現問題時我們能夠應對。有了這兩個利器之後，我們開始設計部署的架構、發布的方案，選擇應用使用本地存儲還是網絡存儲，如何設計應用之間的調用關系，以及改造的先後順序，這是涉及到發布流程和部署架構的工作。

我們也是選擇先去動一些工具類的，比如把一些管理工具容器化部署進行雲原生發布，以此積累一些經驗。我們也定制出了大數據平台的容器基礎鏡像，以及鏡像的發布和管理流程，使多個團隊或多個研發同學之間能夠得到一些經驗和知識的共享。在大家都具備一定的實操經驗之後，我們再分頭改造自己的應用，最終實現整體的雲原生化。

整體的改造完成需要長期的時間，目前我們也是在推進的過程中，但它帶來的收益還是挺可觀的。可能目前從成本角度看沒有太直接的收益，但是雲原生的理念能夠令一個應用owner更好地管控自己的應用，提升應用的可伸縮能力、彈性能力和可運維性，因此長期收益是可以看到的。随着越來越多的應用通過雲原生方式進行管理，我們可以在不遠的将來看到發布效率和穩定性的提升，以及新的架構理念能夠更快地在平台上落地，從而得到更好的收益。

Q5

将大數據系統從傳統生态架構遷移到雲原生架構會面臨哪些挑戰？大數據平台做雲原生改造的技術難點是什麼？

童光輝

我覺得最大的挑戰是有狀态服務上雲，因為k8s在最開始設計的時候解決的是無狀态服務雲化的問題。故障處理主要是通過pod遷移來解決，但是大數據的情況不一樣。大數據各系統都帶數據狀态，不管在傳輸還是在存儲，甚至在計算過程中，要麼是永久性的存儲數據，要麼是緩存數據，因此處理帶狀态服務上雲是一個非常大的挑戰。目前我們也隻是把部分的組件，比如存算一體kafka上雲或者impala存算分離上雲，HDFS或者其他的組件未來是否要上雲，這個問題其實我們内部還在讨論中，還在看如何實現我們收益的最大化。

第二個挑戰是大數據在雲原生過程中如何降本增效，在這個過程中我們要實現與DevOps、AIOps結合。舉個例子，比如Hadoop DataNode或者NodeManager發布，在大規模集群、多個集群情況下，整個流程很耗時間，同時需要比較多人力投入，有時還會出現一些抖動或故障，我們在雲原生升級中，需要把這裡的質量、效率做好治理改造，甚至更近一步，CI、CD、CO、CE，把它們串聯起來實現較好的自動化、智能化。

以我們團隊為例，比如實時計算Flink場景，我們構建了混沌工程環境，可以做到用戶編寫Flink相關的代碼，執行流程完成之後，我們會在一個真實流量的鏡像環境裡做到相關的發布，然後執行混沌工程的爆破，最後完成整個版本的定版，定版之後即可做适當的灰度。Release版本出來之後，我們開始執行全量版本發布，同時在發布過程中，結合指标監控、日志監控，有問題及時熔斷。

大數據上雲我們怎麼巧妙規避或緩解有狀态服務的管理，另一方面是在這個過程中，如何結合DevOps、AIOps實現整個研發運維體系的升級。

Q6

雲原生體系和原來的大數據體系之間存在架構上的沖突應該如何解決？上雲一定要改變大數據自身的架構嗎？

周昕毅

雲原生體系和原有大數據體系存在架構上的沖突，要看怎麼理解這個沖突，因為雲原生體系本身隻是一個推薦的最佳實踐，它并沒有明确的步驟和計劃，可能有推薦的落地場景，也有一些不容易計劃的可以往雲原生方向去靠，那麼體系沖突可能更多是一個已經存在的架構如何做遷移的問題。

這個還是要看風險和收益，如果原有的體系比較成熟，要去做一些容器化改造，那麼侵入性比較大的可以先放一放，可以考慮從一些新上線的工具和功能，以及新上線的系統先做一些雲原生的嘗試。如果确實整個交付速度、運維效率有所提升，看到收益之後再嘗試解決之前現有體系的改造問題。

因為大數據體系是一個非常經典的分布式架構，它的理念一直是比較先進的，隻是沒有很早落地不可變基礎設施等概念，但是它本身分布式的穩定性、代碼質量和可運維性都比較高，所以沖突其實并不多，即使有也可以通過一些慢慢的疊代解決。

上雲是否一定要改變大數據架構，這個要看原來是一個什麼樣的架構，如果原來是私有雲，上雲也可以用裸金屬部署，不一定改變。回到剛才的話題，還是取決于你想解決效率還是成本的問題，如果這兩個問題都能夠解決，那麼帶着原有的自身架構去雲上做部署是最好的，因為可能涉及到一些現有工具的對接。但是一般來說借着上雲做架構的重構，也是一個很好的契機，如果沒有上雲這件事，你可能在現有的這套老系統裡很難下定決心去做升級，因為需要帶着業務去做升級，上雲必然會帶來一個搬遷的動作，借着搬遷再進行架構調整。一般都會選擇稍微做一些調整，也不排除引用現有架構的案例。

Q7

上雲的必要性大嗎？

童光輝

我們從互聯網的軟硬件發展去看待這個問題。首先最開始我們做大數據時是以千兆網卡為主，k8s出來時大概是萬兆網卡，這個時候我們做大數據上雲會發現網絡帶寬不足的問題很嚴峻，所以當時雖然在做在、離線混部，但是我們也相對比較謹慎，優先調度重計算型去在、離線混部的環境，但重IO作業，因為帶寬消耗過大，就需要很謹慎去做調度。最近我們的網絡發展迅速，雲上進入到25G、100G網絡的時代，專線，同城的不同機房間的帶寬成本也在快速降低，所以網絡發展到現在已經不在是主要問題。

同時雲廠商開始大規模地采購服務器，開始投入芯片，而且是做專用芯片，比如壓縮、解壓芯片、視頻解碼芯片等，那麼我們會發現在雲上，硬件成本比自購更劃算。

因此，我覺得中小型企業未來一定要上雲，因為不上雲人力和機器會更貴。大中型企業由于人才儲備、技術儲備以及體量夠大可以選擇用雲廠商或者自建私有雲、混合雲，上雲之後再結合雲存算分離的架構，在人效和成本上可能目前還做不到方方面面的領先，但我相信2～3年之後應該可以全面領先現在的裸金屬架構，所以大數據上雲是一個不可逆的技術發展趨勢。

Q8

大數據上雲的步驟是怎樣的？主要會經曆哪幾個階段？各個階段具體該如何進行規劃？

周昕毅

我這邊會從以下角度做一些規劃：

首先是需求明确的階段，也就是前面反複提到的要明确你要解決什麼問題。

第二步是進行選型，選型包括技術方案選型和雲廠商的選型。用公有雲還是私有雲，選擇哪個雲廠商更合适，要根據自己實際情況而定。技術選型比如是直接購買産品，還是自己買IaaS服務進行搭建，這也是需要根據規模和體量，以及人力的投入進行決定。

第三步需要考慮實時性和穩定性要求。實時性要求高，可能選擇的機型或架構不太一樣。穩定性要求則是平台要提供一個什麼樣的SLA，那麼也會涉及到整個方案應該怎麼做，比如是否涉及遷移，業務是否接受停服務，或者數據延遲能夠維持多久，這些都要提前明确，否則整個搭建好之後，發現設計沒有達到之前的預期，或者成本過高超過了用戶的預期，都會出現問題。

第四步則是應急預案，前面提到了穩定性和SLA承諾，那麼我們針對承諾如何通過一些預案做響應，包括如果選擇公有雲廠商，我要考慮數據跨AD的高可用，還是就在單AD，它們的SLA其實是不同的。

Q9

有沒有傳統大數據平台與雲原生大數據平台的對比案例，可以詳細介紹一下嗎？

童光輝

我在騰訊内，内部使用還是混合雲的模式，對外部客戶是以雲原生為底座的大數據平台，在基礎組件hadoop、kafka等可能有所區别，但在數倉開發工具、BI工具等産品上是内外一套代碼，以插件方式适配不同環境，傳統的大數據平台要交付大數據平台，會涉及到很多個團隊和人力，最後耗費較多時間去落地它的整個體系，雲原生的數據平台在小時級就可以交付出整套大數據的數倉體系環境，在效率上會有質的提升。

我們前面花了很多時間從成本優化和效益提升兩方面探讨大數據上雲的必要性，這其實要根據企業的規模和場景進行選擇，所以說傳統大數據/雲原生大數據主要還是要看需求場景，所謂的傳統大數據/雲原生大數據如果一定要界定我們的不同，主要是本身研發、運維模式的不同，在大數據工具平台、BI産品這一層從用戶角度看沒有什麼區别的。

Q10

通過存儲計算分離實現計算彈性伸縮是在雲上構建數據平台的重要特性之一，存算分離是否會成為大數據的主流架構？

周昕毅

存算分離的架構才具有彈性升縮的空間，存算一體的架構可以降低網絡IO的消耗，但随着硬件基礎設施的不斷增強，網卡從1GB到10GB，25GB，再升級到100GB，對存算分離的架構已經非常友好。大數據領域也有很多高效的壓縮算法，以及優化過的存儲格式的不斷演進，這兩者讓IO慢慢不再是一個瓶頸，那麼壓力來到了CPU這邊，但是CPU其實是比較好做彈性的。在剛才提到的這兩個背景下，存算分離的架構具有比較明顯的優勢。

Q11

大數據上雲未來的發展趨勢是什麼？貴司未來在大數據上雲方面有哪些規劃？

周昕毅

關于我們團隊的規劃，首先在應用架構上，我們會遵循雲原生的哲學去指引我們的架構設計。不管是使用公有雲還是私有雲，我們的整個架構會往雲原生方向去靠，這是毋庸置疑的。至于使用公有雲還是私有雲，則更多是在追求效率和成本平衡過程中的一個選擇。

童光輝

結合架構的發展，大數據雲原生往下走有兩個方面：

一方面我們要完全統一司内、雲上的大數據技術、運維底座，并結合CI、CD、CO、CE打通DevOps的能力，總結下就是統一代碼、統一運維，雲化過程中落地研、運的治理提升效率和質量。

二是我們會更加堅定不移地把存算分離的能力，在離線混部能力做得更好，在保障SLA的基礎上把在線空置、碎片的資源利用得更好降低計算成本。

大數據上雲隻是大數據發展的基建部分，也簡單說下PCG數據中台這邊的情況和規劃，我們有三個數據域：

第一個數據域我們稱為資産區，也就是從數據的埋點到上報，再到存儲、計算、查詢所有的過程，都是有血緣的、規範的、被監測的，數據質量問題可以被快速發現、自動修複，數據價值有初步的評估并持續做好數據治理。

第二個數據域是我們的安全區，整個聯調都在在隔離的環境，原始數據不可不讀取和出域，通過隐私計算進行加工出結果數據，安全區本身也是資産區。

第三個數據域是我們的原始數據區，是未經過徹底治理的，有結構化的表，也有非結構化的模型等數據，我們會逐步将這一部分變得越來越小，通過數據治理把這部分變為數據資産，這也是我們團隊目前投入很多人力和物力在做的一件事情。

再往上我們會做整個數據産品的套件，類似于國外的一站式數據産品，數據隻需要定義好埋點，相關的BI即可出來，不懂技術的人也能夠做好數據使用。

特别鳴謝

關于我們

dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。

關注公衆号【dbaplus社群】，獲取更多原創技術文章和精選工具下載

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!