大資料平臺如何進行雲原生改造

語言: CN / TW / HK

如今,企業都面臨著日益增長的資料量、各種型別資料的實時化和智慧化處理的需求。此時,雲原生大資料平臺的高彈性擴充套件、多租戶資源管理、海量儲存、異構資料型別處理及低成本計算分析的能力,受到了大家的歡迎。但企業應該如何做好大資料平臺的雲原生改造和升級呢?

為此,我們連線了智領雲聯合創始人兼 CEO 彭鋒博士,一起來探討大資料平臺如何進行雲原生改造。以下根據直播內容整理,有不改變原意的刪減,完整內容可點選查看回放影片。

InfoQ:雲原生技術體系具體都包括哪些技術類別?像 IaaS、PaaS 和 SaaS 跟雲原生有什麼關係?

A:雖然“雲原生”近幾年才火起來,但是業界在 2000 年初就開始做了。我 2005 年博士畢業加入 ask.com 後也是做雲平臺,當時的團隊叫中介軟體團隊(middleware)。Amzone 最開始做 IaaS 的時候還沒有云原生的概念,先行者是制定了雲原生 12 原則的 Heroku,它當時允許 APP 直接發到網上而不需要管理伺服器,這也是早期的雲原生應用。當時也沒有現在很火的 K8s,所以雲原生絕對不只是 K8s。容器的概念也是在 Docker 之前就已經出現,所以容器也不僅僅是 Docker。

雲原生以前的門檻很高。我們在 Ask 的時候,幾乎都是博士學歷的人在做雲平臺,在 Twitter 的時候,基本上也沒幾個人會用。雲原生概念從開始到現在的普及,大概用了 20 多的時間。其中最關鍵的是容器、微服務和宣告式 API, 大家常說的 CI/CD 其實並不是雲原生架構獨有的。雲原生關鍵的是面向資源程式設計,向系統申請需要的資源後就不需要管排程的細節了,應用的自動釋出、容錯,遷移等都是系統負責。面向資源程式設計,對整個分散式系統的開發、管理和易用性都有很大的好處。

InfoQ:大資料平臺的雲原生改造會把這些技術都運用起來嗎?

A:一定是的。實際上,阿里做飛天的時候用的就是雲原生技術。Hadoop 有三大元件:檔案系統 HDFS、計算引擎 MapReduce、資源管理器 Yarn。現在 MapReduce 基本被 Spark 取代,作為儲存的 HDFS 還有不少的應用,Yarn 的地位比較尷尬,因為它跟 K8s 做的都是資源管理的事兒。所以我覺得 MapReduce 和 Yarn 馬上就要被淘汰了,像 Spark 以及大部分的資料應用現在都可以直接在 Kubernetes 上跑,所以大資料系統就並不再需要 Yarn 了。對於 HDFS,則會有一個雲原生改造的升級。

Hadoop 本來有個物件儲存系統 Ozone,現在 Ozone 被單獨挪出去,不在 Hadoop 體系了。Hadoop 原來的這一套體系,大概率在三到五年後就會被完全被淘汰。這個改造是不可避免的,基於原來 Hadoop 生態體系的大資料平臺一定會遷移到雲原生平臺。

InfoQ: Twitte r 什麼時候開始做 雲原生大資料平臺的?當時為什麼要做?效果如何?這為國內大資料平臺帶來哪些思考?

A:很早,大概 2011 年的時候。Mesos 上生產後,除了 Hadoop,其他所有應用都在 Mesos 上跑。當時,Mesos 就能支援 Twitter 內部八千多臺機器的叢集。Mesos 有自己的管理器,其實是走在 K8s 前面的。

我們當時為什麼覺得這個很厲害?因為以前要釋出一個系統,先得去申請機器、買機器,機器買回來後安裝,裝完後還要去測試。即使測試好了,也還要擔心幾個系統之間的第三方庫有沒有衝突。

大資料系統都是開源的。開源有個好處,就是便宜。開源不好的地方就是各個系統之間沒有控制,兩個開源系統依賴的第三方庫有衝突。比如開源專案 A 用的是第三方庫 C,另外一個開源專案 B 也用第三方庫 C,但是兩個專案依賴的 C 版本不一樣,安裝在同一個機器上就經常出問題,這是一個技術性的問題,困擾了大家很多年。

有了雲原生功能後,每個應用都是自己的容器。我們當時用的還不是 Docker,是 universal container。這是 Mesos 自己做的一個容器,好處就是容器化、隔離,不會擔心大家互相影響,應用可以實現秒級釋出,對生產力的解放是革命性的。所以雲化是必然趨勢,大資料平臺也遵從這樣的趨勢。

以後做的軟體如果不是雲原生的,百分之百不會有人用。因為,現在所有的新軟體都用雲原生的方式執行,老的軟體就慢慢地跟不上了,不能說再單獨搞個叢集。所以,不能在雲平臺上跑的應用一定會被淘汰。

InfoQ:現在使用雲原生大資料平臺的主要是哪些型別的企業?企業數量有怎樣的變化?

A:主要是網際網路和大廠。現在的雲原生大資料平臺還不成熟。相比之下,企業更容易招到熟悉 Hadoop 技能的人。其次,這些大資料元件的雲原生成熟度還不是特別高。Spark 今年 3 月份才具有一般可用性(General availability,GA) ,併發布了 3.1 版本。Kafka 在今年 5 月份宣佈 Kubernetes  GA 但還沒有開源。這兩件事說明了現在主流的大資料元件廠商都在往 Kubernetes 上靠。這裡就涉及到的 Spark、Hive 等核心元件以及他們依賴的相關元件都要升級,系統層面的升級對一般企業來講是比較麻煩的。

國外的像 Twitter、Uber、Airbnb 等都在做這個事情,但他們的解決方案有的不是很理想。比如 Uber 是把整個 Yarn 挪到了 Kubernetes 上,這個有點不是特別好,我覺得應該把 Yarn 去掉,其他元件直接雲原生化,比如類似於 MongoDB 的元件已經逐漸有 Kubernetes 釋出版本出來。

綜合起來的情況是, 現在大家都在推進,但還沒有到特別成熟的階段。

InfoQ:大資料平臺目前存在的哪些問題?為什麼雲原生技術可以解決這些問題?

A:現在的大資料平臺能解決基本的資料需求問題,但還有兩個很大的問題需要解決。首先是資源管理。Yarn 的資源管理的粒度做得不是特別好,在多租戶隔離和資源搶佔上都能力有限,類似於 Spark 的應用沒法混排,沒法像雲原生那樣做到存算分離,計算和儲存不能夠充分利用每個節點的資源。最關鍵的是現在其他應用慢慢都不會為 Yarn 去做升級了,後續運維和升級會是問題。

其次,並不是說現在的大資料平臺解決不了現在的問題,但是社群和生態的遷移已經是很明確的了。例如剛才說到的,像 MongoDB 都可以在 Kubernetes 跑,以後可能為了 Hadoop 就得單獨搞一個叢集。但如果用雲原生的儲存,就不需要單獨一個叢集了。所以,任務混排、資源隔離以及對新應用的支援等都是 Hadoop 體系現在比較大的硬傷。

InfoQ:具體實踐中,雲原生技術是如何針對這些問題進行改造和升級的?開發人員應該如何做技術選型?

A:現在所有的資源管理和編排可以依賴於 Kubernetes,企業可以專注在自己的業務邏輯和管理上。比如,現在容器儲存介面(Container  storage  interface,CSI)越來越成熟,只要儲存系統滿足介面要求,那麼無論是哪家提供商的應用就都可以訪問。動態的依賴、釋出和容錯都可以依賴 Kubernetes 來做,這比要同時執行兩個不同的叢集要好很多。

另外,原來的 Hadoop 應用大概率不需要重寫,因為它現在有專門相容原來 HDFS 的儲存,將相容資料拷貝到 HDFS 相容的儲存上後,應用同樣可以執行。現在我們要做的是,讓 Hive 直接執行在 Spark 上、Spark 執行在 K8s 上,如此 Hive 的程式也不需要做大量的遷移就可以直接挪到 K8s 上,這樣就能實現 K8s 叢集的平穩遷移。

InfoQ:大資料平臺做雲原生改造的技術難點是什麼?

A:技術難點還是不少的,主要還是現在的大資料元件對 K8s 的支援還不是特別成熟,這是開源元件的問題。我舉個例子。Spark 本身也依賴於很多別的開源元件,這些元件有的還沒有支援 K8s,支援 K8s 元件中的版本也不一樣。每個開源元件都號稱自己支援 K8s,但把所有這些支援 K8s 的元件放到一起時,就會發現各種各樣的版本存在衝突。還有一個問題就是 K8s 的升級太快。K8s 現在基本上每個季度升級一次,著也導致底下每個大資料元件支援的 K8s 版本不一樣。總之,當前整個生態還不能協調地支援 K8s。

雖然很多大資料產品廠商都在做 K8s 支援,但在生產中還屬於實驗階段。大家都還是處於剛剛起步的狀態。從 K8s 自身來說,K8s 對有狀態應用的支援和 CSI 儲存方面的支援這兩年也才完善起來,這兩點是最大的技術難點,這也是大家最近一兩年開始往 K8s 上遷移的原因。

InfoQ:開發人員怎麼做技術選型?

A:我覺得,如果企業現在已經有 Hadoop 了,如果想未雨綢繆做遷移,那麼可以開始嘗試。一些不重要的業務可以先在雲原生體系裡跑起來,逐漸完善其穩定性,然後再逐漸擴充套件雲原生叢集。這個過程中,企業可以借用 K8s 管理體系不斷完善流程。我不建議馬上把 Hadoop 全搞過來,但是至少有一個測試叢集,做好業務流程的驗證。

如果是新的企業,我強烈建議直接在 K8s 上搭建叢集。因為新企業叢集一般規模不會太大,使用雲原生支援的大資料元件一般不會有太多問題,而且會很好用。如果先用 Hadoop 以後再遷移的話就會很麻煩。現在用雲廠商的產品搭建一個雲原生的大資料平臺是很快的。

InfoQ:除了技術之外還有哪些挑戰?

A:我覺得主要還是人才方面的挑戰。作為一個技術人員要能發現行業趨勢。倒不是說要追逐最新的技術,但是如何選擇在合適的時間選擇合適的技術很重要。我前兩天也提到,如果面試中公司還在問 Hadoop 的問題,那麼基本可以認為這個公司的技術有點過時了。

以前 DevOps 有專門的運維工程師,開發人員要自己掌控從開發、測試、釋出的整個流程。以後,資料科學家和資料分析師大概率可以自己掌控資料探索、資料分析和資料展示的這一整套流程。以前的 ETL 工程師可能就會更加侷限,企業對他們的需求量變得更小。企業招人可能會更多地傾向資料分析師、資料科學家,因為底層已經標準化了。

從客戶那裡也感覺到:資料分析師缺,懂業務的分析師也缺,既懂業務又懂技術的資料分析師更缺。現在很多公司還處在建設大資料平臺的過程中,可能體現的不明顯。但隨著越來越標準化,大資料運維的使用門檻會越來越低,企業會更願意使用雲原生的大資料平臺。

InfoQ:大資料平臺的雲原生改造,主要涉及哪些方面?

A:雲原生改造中,元件是一部分,但還有其他工作,如 CI/CD、日誌管理、使用者管理、監控等。大資料領域裡還有資料質量、元資料等都需要 K8s 環境下的管理系統。K8s 帶來的好處就是現在所有應用都以同樣的模式釋出,使用同一套資源管理體系。但像元資料管理、資料質量管理、工作流排程等就不是 K8s 提供的了。

之前,Spark 在 Yarn 上面跑,ETL 要到 Hive 上跑,SQL 要在 MySQL 裡跑,現在這些都要在 K8s 上,K8s 變得非常重要,這也需要宣告式 API 做整個叢集管理。

現在,很多矽谷公司把 ETL 改成了程式碼管理,Airflow 把排程管理也變成了程式碼管理。所以,現在的一個趨勢就是 K8s 是把叢集管理全部變成了程式碼管理,大資料平臺遷移到 K8s 以後也可以做程式碼及流水級程式碼的管理,也可以用 Git 來管理。所以,大資料平臺的雲原生改造不僅是元件,開發和管理形式也會發生很大的改變。

InfoQ:有沒有傳統大資料平臺與雲原生大資料平臺的對比案例,可以詳細介紹下?

A:Snowflake 就是雲原生大資料平臺最典型的例子。Snowflake 自己沒有儲存也沒有計算,它的計算能力用 K8s,儲存能力用各個雲廠商的,它在中間是動態的,通過 K8s 給使用者傳送一個專有的 MPP。

絕大部分雲原生系統都可以做到存算分離,像 CSI,我在上面的應用可以殺掉,CSI 儲存還在那,天然地就做到存算分離。應用沒有訪問量時就叫停,有使用者使用時再分配資源,這樣做到錯峰資源、彈性擴容。一個資源池可以統一分配資源,提高了資源利用率、管理效率和整個運維效率,讓系統執行更合理。十幾年前,一個略大的叢集要幾十個博士才能搞定,現在一個本科生就可以,所以生產力的提高要靠標準化。

InfoQ:DataOps 做雲原生改造的必要性在哪?

A:DataOps 做雲原生改造主要是因為兩個方面。首先是剛才說的標準化,DataOps 需要管理所有元件,但如果元件不是標準化的,那麼這個事就很難做。其次,雲原生帶來了各種產品,如 Spark,Flink 等標準的統一。DataOps 包括五個方面:資料開發及 CI/CD、自動化排程、資料質量、資料門戶、安全和審計合規,這些都要在雲原生標準化基礎上才能實現。