如今，企業(yè)都面臨著日益增長的數(shù)據(jù)量、各種類型數(shù)據(jù)的實時化和智能化處理的需求。此時，云原生大數(shù)據(jù)平臺的高彈性擴展、多租戶資源管理、海量存儲、異構數(shù)據(jù)類型處理及低成本計算分析的能力，受到了大家的歡迎。但企業(yè)應該如何做好大數(shù)據(jù)平臺的云原生改造和升級呢？

為此，我們連線了智領云聯(lián)合創(chuàng)始人兼 CEO 彭鋒博士，一起來探討大數(shù)據(jù)平臺如何進行云原生改造。以下根據(jù)直播內容整理，有不改變原意的刪減，完整內容可點擊查看回放視頻。

InfoQ：云原生技術體系具體都包括哪些技術類別？像 IaaS、PaaS 和 SaaS 跟云原生有什么關系？

A：雖然“云原生”近幾年才火起來，但是業(yè)界在 2000 年初就開始做了。我 2005 年博士畢業(yè)加入 ask.com 后也是做云平臺，當時的團隊叫中間件團隊（middleware）。Amzone 最開始做 IaaS 的時候還沒有云原生的概念，先行者是制定了云原生 12 原則的 Heroku，它當時允許 APP 直接發(fā)到網(wǎng)上而不需要管理服務器，這也是早期的云原生應用。當時也沒有現(xiàn)在很火的 K8s，所以云原生絕對不只是 K8s。容器的概念也是在 Docker 之前就已經(jīng)出現(xiàn)，所以容器也不僅僅是 Docker。

云原生以前的門檻很高。我們在 Ask 的時候，幾乎都是博士學歷的人在做云平臺，在 Twitter 的時候，基本上也沒幾個人會用。云原生概念從開始到現(xiàn)在的普及，大概用了 20 多的時間。其中最關鍵的是容器、微服務和聲明式 API， 大家常說的 CI/CD 其實并不是云原生架構獨有的。云原生關鍵的是面向資源編程，向系統(tǒng)申請需要的資源后就不需要管調度的細節(jié)了，應用的自動發(fā)布、容錯，遷移等都是系統(tǒng)負責。面向資源編程，對整個分布式系統(tǒng)的開發(fā)、管理和易用性都有很大的好處。

InfoQ：大數(shù)據(jù)平臺的云原生改造會把這些技術都運用起來嗎？

A：一定是的。實際上，阿里做飛天的時候用的就是云原生技術。Hadoop 有三大組件：文件系統(tǒng) HDFS、計算引擎 MapReduce、資源管理器 Yarn?，F(xiàn)在 MapReduce 基本被 Spark 取代，作為存儲的 HDFS 還有不少的應用，Yarn 的地位比較尷尬，因為它跟 K8s 做的都是資源管理的事兒。所以我覺得 MapReduce 和 Yarn 馬上就要被淘汰了，像 Spark 以及大部分的數(shù)據(jù)應用現(xiàn)在都可以直接在 Kubernetes 上跑，所以大數(shù)據(jù)系統(tǒng)就并不再需要 Yarn 了。對于 HDFS，則會有一個云原生改造的升級。

Hadoop 本來有個對象存儲系統(tǒng) Ozone，現(xiàn)在 Ozone 被單獨挪出去，不在 Hadoop 體系了。Hadoop 原來的這一套體系，大概率在三到五年后就會被完全被淘汰。這個改造是不可避免的，基于原來 Hadoop 生態(tài)體系的大數(shù)據(jù)平臺一定會遷移到云原生平臺。

InfoQ：Twitter 什么時候開始做云原生大數(shù)據(jù)平臺的？當時為什么要做？效果如何？這為國內大數(shù)據(jù)平臺帶來哪些思考？

A：很早，大概 2011 年的時候。Mesos 上生產(chǎn)后，除了 Hadoop，其他所有應用都在 Mesos 上跑。當時，Mesos 就能支持 Twitter 內部八千多臺機器的集群。Mesos 有自己的管理器，其實是走在 K8s 前面的。

我們當時為什么覺得這個很厲害？因為以前要發(fā)布一個系統(tǒng)，先得去申請機器、買機器，機器買回來后安裝，裝完后還要去測試。即使測試好了，也還要擔心幾個系統(tǒng)之間的第三方庫有沒有沖突。

大數(shù)據(jù)系統(tǒng)都是開源的。開源有個好處，就是便宜。開源不好的地方就是各個系統(tǒng)之間沒有控制，兩個開源系統(tǒng)依賴的第三方庫有沖突。比如開源項目 A 用的是第三方庫 C，另外一個開源項目 B 也用第三方庫 C，但是兩個項目依賴的 C 版本不一樣，安裝在同一個機器上就經(jīng)常出問題，這是一個技術性的問題，困擾了大家很多年。

有了云原生功能后，每個應用都是自己的容器。我們當時用的還不是 Docker，是 universal container。這是 Mesos 自己做的一個容器，好處就是容器化、隔離，不會擔心大家互相影響，應用可以實現(xiàn)秒級發(fā)布，對生產(chǎn)力的解放是革命性的。所以云化是必然趨勢，大數(shù)據(jù)平臺也遵從這樣的趨勢。

以后做的軟件如果不是云原生的，百分之百不會有人用。因為，現(xiàn)在所有的新軟件都用云原生的方式運行，老的軟件就慢慢地跟不上了，不能說再單獨搞個集群。所以，不能在云平臺上跑的應用一定會被淘汰。

InfoQ：現(xiàn)在使用云原生大數(shù)據(jù)平臺的主要是哪些類型的企業(yè)？企業(yè)數(shù)量有怎樣的變化？

A：主要是互聯(lián)網(wǎng)和大廠?，F(xiàn)在的云原生大數(shù)據(jù)平臺還不成熟。相比之下，企業(yè)更容易招到熟悉 Hadoop 技能的人。其次，這些大數(shù)據(jù)組件的云原生成熟度還不是特別高。Spark 今年 3 月份才具有一般可用性(General availability，GA) ，并發(fā)布了 3.1 版本。Kafka 在今年 5 月份宣布 Kubernetes GA 但還沒有開源。這兩件事說明了現(xiàn)在主流的大數(shù)據(jù)組件廠商都在往 Kubernetes 上靠。這里就涉及到的 Spark、Hive 等核心組件以及他們依賴的相關組件都要升級，系統(tǒng)層面的升級對一般企業(yè)來講是比較麻煩的。

國外的像 Twitter、Uber、Airbnb 等都在做這個事情，但他們的解決方案有的不是很理想。比如 Uber 是把整個 Yarn 挪到了 Kubernetes 上，這個有點不是特別好，我覺得應該把 Yarn 去掉，其他組件直接云原生化，比如類似于 MongoDB 的組件已經(jīng)逐漸有 Kubernetes 發(fā)布版本出來。

綜合起來的情況是， 現(xiàn)在大家都在推進，但還沒有到特別成熟的階段。

InfoQ：大數(shù)據(jù)平臺目前存在的哪些問題？為什么云原生技術可以解決這些問題？

A：現(xiàn)在的大數(shù)據(jù)平臺能解決基本的數(shù)據(jù)需求問題，但還有兩個很大的問題需要解決。首先是資源管理。Yarn 的資源管理的粒度做得不是特別好，在多租戶隔離和資源搶占上都能力有限，類似于 Spark 的應用沒法混排，沒法像云原生那樣做到存算分離，計算和存儲不能夠充分利用每個節(jié)點的資源。最關鍵的是現(xiàn)在其他應用慢慢都不會為 Yarn 去做升級了，后續(xù)運維和升級會是問題。

其次，并不是說現(xiàn)在的大數(shù)據(jù)平臺解決不了現(xiàn)在的問題，但是社區(qū)和生態(tài)的遷移已經(jīng)是很明確的了。例如剛才說到的，像 MongoDB 都可以在 Kubernetes 跑，以后可能為了 Hadoop 就得單獨搞一個集群。但如果用云原生的存儲，就不需要單獨一個集群了。所以，任務混排、資源隔離以及對新應用的支持等都是 Hadoop 體系現(xiàn)在比較大的硬傷。

InfoQ：具體實踐中，云原生技術是如何針對這些問題進行改造和升級的？開發(fā)人員應該如何做技術選型？

A：現(xiàn)在所有的資源管理和編排可以依賴于 Kubernetes，企業(yè)可以專注在自己的業(yè)務邏輯和管理上。比如，現(xiàn)在容器存儲接口（Container storage interface，CSI）越來越成熟，只要存儲系統(tǒng)滿足接口要求，那么無論是哪家提供商的應用就都可以訪問。動態(tài)的依賴、發(fā)布和容錯都可以依賴 Kubernetes 來做，這比要同時運行兩個不同的集群要好很多。

另外，原來的 Hadoop 應用大概率不需要重寫，因為它現(xiàn)在有專門兼容原來 HDFS 的存儲，將兼容數(shù)據(jù)拷貝到 HDFS 兼容的存儲上后，應用同樣可以運行?，F(xiàn)在我們要做的是，讓 Hive 直接運行在 Spark 上、Spark 運行在 K8s 上，如此 Hive 的程序也不需要做大量的遷移就可以直接挪到 K8s 上，這樣就能實現(xiàn) K8s 集群的平穩(wěn)遷移。

InfoQ：大數(shù)據(jù)平臺做云原生改造的技術難點是什么？

A：技術難點還是不少的，主要還是現(xiàn)在的大數(shù)據(jù)組件對 K8s 的支持還不是特別成熟，這是開源組件的問題。我舉個例子。Spark 本身也依賴于很多別的開源組件，這些組件有的還沒有支持 K8s，支持 K8s 組件中的版本也不一樣。每個開源組件都號稱自己支持 K8s，但把所有這些支持 K8s 的組件放到一起時，就會發(fā)現(xiàn)各種各樣的版本存在沖突。還有一個問題就是 K8s 的升級太快。K8s 現(xiàn)在基本上每個季度升級一次，著也導致底下每個大數(shù)據(jù)組件支持的 K8s 版本不一樣。總之，當前整個生態(tài)還不能協(xié)調地支持 K8s。

雖然很多大數(shù)據(jù)產(chǎn)品廠商都在做 K8s 支持，但在生產(chǎn)中還屬于實驗階段。大家都還是處于剛剛起步的狀態(tài)。從 K8s 自身來說，K8s 對有狀態(tài)應用的支持和 CSI 存儲方面的支持這兩年也才完善起來，這兩點是最大的技術難點，這也是大家最近一兩年開始往 K8s 上遷移的原因。

InfoQ：開發(fā)人員怎么做技術選型？

A：我覺得，如果企業(yè)現(xiàn)在已經(jīng)有 Hadoop 了，如果想未雨綢繆做遷移，那么可以開始嘗試。一些不重要的業(yè)務可以先在云原生體系里跑起來，逐漸完善其穩(wěn)定性，然后再逐漸擴展云原生集群。這個過程中，企業(yè)可以借用 K8s 管理體系不斷完善流程。我不建議馬上把 Hadoop 全搞過來，但是至少有一個測試集群，做好業(yè)務流程的驗證。

如果是新的企業(yè)，我強烈建議直接在 K8s 上搭建集群。因為新企業(yè)集群一般規(guī)模不會太大，使用云原生支持的大數(shù)據(jù)組件一般不會有太多問題，而且會很好用。如果先用 Hadoop 以后再遷移的話就會很麻煩。現(xiàn)在用云廠商的產(chǎn)品搭建一個云原生的大數(shù)據(jù)平臺是很快的。

InfoQ：除了技術之外還有哪些挑戰(zhàn)？

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

以前 DevOps 有專門的運維工程師，開發(fā)人員要自己掌控從開發(fā)、測試、發(fā)布的整個流程。以后，數(shù)據(jù)科學家和數(shù)據(jù)分析師大概率可以自己掌控數(shù)據(jù)探索、數(shù)據(jù)分析和數(shù)據(jù)展示的這一整套流程。以前的 ETL 工程師可能就會更加局限，企業(yè)對他們的需求量變得更小。企業(yè)招人可能會更多地傾向數(shù)據(jù)分析師、數(shù)據(jù)科學家，因為底層已經(jīng)標準化了。

從客戶那里也感覺到：數(shù)據(jù)分析師缺，懂業(yè)務的分析師也缺，既懂業(yè)務又懂技術的數(shù)據(jù)分析師更缺?，F(xiàn)在很多公司還處在建設大數(shù)據(jù)平臺的過程中，可能體現(xiàn)的不明顯。但隨著越來越標準化，大數(shù)據(jù)運維的使用門檻會越來越低，企業(yè)會更愿意使用云原生的大數(shù)據(jù)平臺。

InfoQ：大數(shù)據(jù)平臺的云原生改造，主要涉及哪些方面？

A：云原生改造中，組件是一部分，但還有其他工作，如 CI/CD、日志管理、用戶管理、監(jiān)控等。大數(shù)據(jù)領域里還有數(shù)據(jù)質量、元數(shù)據(jù)等都需要 K8s 環(huán)境下的管理系統(tǒng)。K8s 帶來的好處就是現(xiàn)在所有應用都以同樣的模式發(fā)布，使用同一套資源管理體系。但像元數(shù)據(jù)管理、數(shù)據(jù)質量管理、工作流調度等就不是 K8s 提供的了。

之前，Spark 在 Yarn 上面跑，ETL 要到 Hive 上跑，SQL 要在 MySQL 里跑，現(xiàn)在這些都要在 K8s 上，K8s 變得非常重要，這也需要聲明式 API 做整個集群管理。

現(xiàn)在，很多硅谷公司把 ETL 改成了代碼管理，Airflow 把調度管理也變成了代碼管理。所以，現(xiàn)在的一個趨勢就是 K8s 是把集群管理全部變成了代碼管理，大數(shù)據(jù)平臺遷移到 K8s 以后也可以做代碼及流水級代碼的管理，也可以用 Git 來管理。所以，大數(shù)據(jù)平臺的云原生改造不僅是組件，開發(fā)和管理形式也會發(fā)生很大的改變。

InfoQ：有沒有傳統(tǒng)大數(shù)據(jù)平臺與云原生大數(shù)據(jù)平臺的對比案例，可以詳細介紹下？

A：Snowflake 就是云原生大數(shù)據(jù)平臺最典型的例子。Snowflake 自己沒有存儲也沒有計算，它的計算能力用 K8s，存儲能力用各個云廠商的，它在中間是動態(tài)的，通過 K8s 給用戶發(fā)送一個專有的 MPP。

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

InfoQ：DataOps 做云原生改造的必要性在哪？

A：DataOps 做云原生改造主要是因為兩個方面。首先是剛才說的標準化，DataOps 需要管理所有組件，但如果組件不是標準化的，那么這個事就很難做。其次，云原生帶來了各種產(chǎn)品，如 Spark，F(xiàn)link 等標準的統(tǒng)一。DataOps 包括五個方面：數(shù)據(jù)開發(fā)及 CI/CD、自動化調度、數(shù)據(jù)質量、數(shù)據(jù)門戶、安全和審計合規(guī)，這些都要在云原生標準化基礎上才能實現(xiàn)。