如今，企業(yè)都面臨著日益增長的數(shù)據(jù)量、各種類型數(shù)據(jù)的實(shí)時化和智能化處理的需求。此時，云原生大數(shù)據(jù)平臺的高彈性擴(kuò)展、多租戶資源管理、海量存儲、異構(gòu)數(shù)據(jù)類型處理及低成本計(jì)算分析的能力，受到了大家的歡迎。但企業(yè)應(yīng)該如何做好大數(shù)據(jù)平臺的云原生改造和升級呢？
為此，我們連線了智領(lǐng)云聯(lián)合創(chuàng)始人兼 CEO 彭鋒博士，一起來探討大數(shù)據(jù)平臺如何進(jìn)行云原生改造。以下根據(jù)直播內(nèi)容整理，有不改變原意的刪減，完整內(nèi)容可點(diǎn)擊查看回放視頻。
InfoQ：云原生技術(shù)體系具體都包括哪些技術(shù)類別？像 IaaS、PaaS 和 SaaS 跟云原生有什么關(guān)系？
A：雖然“云原生”近幾年才火起來，但是業(yè)界在 2000 年初就開始做了。我 2005 年博士畢業(yè)加入 ask.com 后也是做云平臺，當(dāng)時的團(tuán)隊(duì)叫中間件團(tuán)隊(duì)（middleware）。Amzone 最開始做 IaaS 的時候還沒有云原生的概念，先行者是制定了云原生 12 原則的 Heroku，它當(dāng)時允許 APP 直接發(fā)到網(wǎng)上而不需要管理服務(wù)器，這也是早期的云原生應(yīng)用。當(dāng)時也沒有現(xiàn)在很火的 K8s，所以云原生絕對不只是 K8s。容器的概念也是在 Docker 之前就已經(jīng)出現(xiàn)，所以容器也不僅僅是 Docker。
云原生以前的門檻很高。我們在 Ask 的時候，幾乎都是博士學(xué)歷的人在做云平臺，在 Twitter 的時候，基本上也沒幾個人會用。云原生概念從開始到現(xiàn)在的普及，大概用了 20 多的時間。其中最關(guān)鍵的是容器、微服務(wù)和聲明式 API， 大家常說的 CI/CD 其實(shí)并不是云原生架構(gòu)獨(dú)有的。云原生關(guān)鍵的是面向資源編程，向系統(tǒng)申請需要的資源后就不需要管調(diào)度的細(xì)節(jié)了，應(yīng)用的自動發(fā)布、容錯，遷移等都是系統(tǒng)負(fù)責(zé)。面向資源編程，對整個分布式系統(tǒng)的開發(fā)、管理和易用性都有很大的好處。
InfoQ：大數(shù)據(jù)平臺的云原生改造會把這些技術(shù)都運(yùn)用起來嗎？
A：一定是的。實(shí)際上，阿里做飛天的時候用的就是云原生技術(shù)。Hadoop 有三大組件：文件系統(tǒng) HDFS、計(jì)算引擎 MapReduce、資源管理器 Yarn。現(xiàn)在 MapReduce 基本被 Spark 取代，作為存儲的 HDFS 還有不少的應(yīng)用，Yarn 的地位比較尷尬，因?yàn)樗?K8s 做的都是資源管理的事兒。所以我覺得 MapReduce 和 Yarn 馬上就要被淘汰了，像 Spark 以及大部分的數(shù)據(jù)應(yīng)用現(xiàn)在都可以直接在 Kubernetes 上跑，所以大數(shù)據(jù)系統(tǒng)就并不再需要 Yarn 了。對于 HDFS，則會有一個云原生改造的升級。
Hadoop 本來有個對象存儲系統(tǒng) Ozone，現(xiàn)在 Ozone 被單獨(dú)挪出去，不在 Hadoop 體系了。Hadoop 原來的這一套體系，大概率在三到五年后就會被完全被淘汰。這個改造是不可避免的，基于原來 Hadoop 生態(tài)體系的大數(shù)據(jù)平臺一定會遷移到云原生平臺。
InfoQ：Twitter 什么時候開始做云原生大數(shù)據(jù)平臺的？當(dāng)時為什么要做？效果如何？這為國內(nèi)大數(shù)據(jù)平臺帶來哪些思考？
A：很早，大概 2011 年的時候。Mesos 上生產(chǎn)后，除了 Hadoop，其他所有應(yīng)用都在 Mesos 上跑。當(dāng)時，Mesos 就能支持 Twitter 內(nèi)部八千多臺機(jī)器的集群。Mesos 有自己的管理器，其實(shí)是走在 K8s 前面的。
我們當(dāng)時為什么覺得這個很厲害？因?yàn)橐郧耙l(fā)布一個系統(tǒng)，先得去申請機(jī)器、買機(jī)器，機(jī)器買回來后安裝，裝完后還要去測試。即使測試好了，也還要擔(dān)心幾個系統(tǒng)之間的第三方庫有沒有沖突。
大數(shù)據(jù)系統(tǒng)都是開源的。開源有個好處，就是便宜。開源不好的地方就是各個系統(tǒng)之間沒有控制，兩個開源系統(tǒng)依賴的第三方庫有沖突。比如開源項(xiàng)目 A 用的是第三方庫 C，另外一個開源項(xiàng)目 B 也用第三方庫 C，但是兩個項(xiàng)目依賴的 C 版本不一樣，安裝在同一個機(jī)器上就經(jīng)常出問題，這是一個技術(shù)性的問題，困擾了大家很多年。
有了云原生功能后，每個應(yīng)用都是自己的容器。我們當(dāng)時用的還不是 Docker，是 universal container。這是 Mesos 自己做的一個容器，好處就是容器化、隔離，不會擔(dān)心大家互相影響，應(yīng)用可以實(shí)現(xiàn)秒級發(fā)布，對生產(chǎn)力的解放是革命性的。所以云化是必然趨勢，大數(shù)據(jù)平臺也遵從這樣的趨勢。
以后做的軟件如果不是云原生的，百分之百不會有人用。因?yàn)椋F(xiàn)在所有的新軟件都用云原生的方式運(yùn)行，老的軟件就慢慢地跟不上了，不能說再單獨(dú)搞個集群。所以，不能在云平臺上跑的應(yīng)用一定會被淘汰。
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 等核心組件以及他們依賴的相關(guān)組件都要升級，系統(tǒng)層面的升級對一般企業(yè)來講是比較麻煩的。
國外的像 Twitter、Uber、Airbnb 等都在做這個事情，但他們的解決方案有的不是很理想。比如 Uber 是把整個 Yarn 挪到了 Kubernetes 上，這個有點(diǎn)不是特別好，我覺得應(yīng)該把 Yarn 去掉，其他組件直接云原生化，比如類似于 MongoDB 的組件已經(jīng)逐漸有 Kubernetes 發(fā)布版本出來。
綜合起來的情況是， 現(xiàn)在大家都在推進(jìn)，但還沒有到特別成熟的階段。
InfoQ：大數(shù)據(jù)平臺目前存在的哪些問題？為什么云原生技術(shù)可以解決這些問題？
A：現(xiàn)在的大數(shù)據(jù)平臺能解決基本的數(shù)據(jù)需求問題，但還有兩個很大的問題需要解決。首先是資源管理。Yarn 的資源管理的粒度做得不是特別好，在多租戶隔離和資源搶占上都能力有限，類似于 Spark 的應(yīng)用沒法混排，沒法像云原生那樣做到存算分離，計(jì)算和存儲不能夠充分利用每個節(jié)點(diǎn)的資源。最關(guān)鍵的是現(xiàn)在其他應(yīng)用慢慢都不會為 Yarn 去做升級了，后續(xù)運(yùn)維和升級會是問題。
其次，并不是說現(xiàn)在的大數(shù)據(jù)平臺解決不了現(xiàn)在的問題，但是社區(qū)和生態(tài)的遷移已經(jīng)是很明確的了。例如剛才說到的，像 MongoDB 都可以在 Kubernetes 跑，以后可能為了 Hadoop 就得單獨(dú)搞一個集群。但如果用云原生的存儲，就不需要單獨(dú)一個集群了。所以，任務(wù)混排、資源隔離以及對新應(yīng)用的支持等都是 Hadoop 體系現(xiàn)在比較大的硬傷。
InfoQ：具體實(shí)踐中，云原生技術(shù)是如何針對這些問題進(jìn)行改造和升級的？開發(fā)人員應(yīng)該如何做技術(shù)選型？
A：現(xiàn)在所有的資源管理和編排可以依賴于 Kubernetes，企業(yè)可以專注在自己的業(yè)務(wù)邏輯和管理上。比如，現(xiàn)在容器存儲接口（Container storage interface，CSI）越來越成熟，只要存儲系統(tǒng)滿足接口要求，那么無論是哪家提供商的應(yīng)用就都可以訪問。動態(tài)的依賴、發(fā)布和容錯都可以依賴 Kubernetes 來做，這比要同時運(yùn)行兩個不同的集群要好很多。
另外，原來的 Hadoop 應(yīng)用大概率不需要重寫，因?yàn)樗F(xiàn)在有專門兼容原來 HDFS 的存儲，將兼容數(shù)據(jù)拷貝到 HDFS 兼容的存儲上后，應(yīng)用同樣可以運(yùn)行?，F(xiàn)在我們要做的是，讓 Hive 直接運(yùn)行在 Spark 上、Spark 運(yùn)行在 K8s 上，如此 Hive 的程序也不需要做大量的遷移就可以直接挪到 K8s 上，這樣就能實(shí)現(xiàn) K8s 集群的平穩(wěn)遷移。
InfoQ：大數(shù)據(jù)平臺做云原生改造的技術(shù)難點(diǎn)是什么？
A：技術(shù)難點(diǎn)還是不少的，主要還是現(xiàn)在的大數(shù)據(jù)組件對 K8s 的支持還不是特別成熟，這是開源組件的問題。我舉個例子。Spark 本身也依賴于很多別的開源組件，這些組件有的還沒有支持 K8s，支持 K8s 組件中的版本也不一樣。每個開源組件都號稱自己支持 K8s，但把所有這些支持 K8s 的組件放到一起時，就會發(fā)現(xiàn)各種各樣的版本存在沖突。還有一個問題就是 K8s 的升級太快。K8s 現(xiàn)在基本上每個季度升級一次，著也導(dǎo)致底下每個大數(shù)據(jù)組件支持的 K8s 版本不一樣?？傊?，當(dāng)前整個生態(tài)還不能協(xié)調(diào)地支持 K8s。
雖然很多大數(shù)據(jù)產(chǎn)品廠商都在做 K8s 支持，但在生產(chǎn)中還屬于實(shí)驗(yàn)階段。大家都還是處于剛剛起步的狀態(tài)。從 K8s 自身來說，K8s 對有狀態(tài)應(yīng)用的支持和 CSI 存儲方面的支持這兩年也才完善起來，這兩點(diǎn)是最大的技術(shù)難點(diǎn)，這也是大家最近一兩年開始往 K8s 上遷移的原因。
InfoQ：開發(fā)人員怎么做技術(shù)選型？
A：我覺得，如果企業(yè)現(xiàn)在已經(jīng)有 Hadoop 了，如果想未雨綢繆做遷移，那么可以開始嘗試。一些不重要的業(yè)務(wù)可以先在云原生體系里跑起來，逐漸完善其穩(wěn)定性，然后再逐漸擴(kuò)展云原生集群。這個過程中，企業(yè)可以借用 K8s 管理體系不斷完善流程。我不建議馬上把 Hadoop 全搞過來，但是至少有一個測試集群，做好業(yè)務(wù)流程的驗(yàn)證。
如果是新的企業(yè)，我強(qiáng)烈建議直接在 K8s 上搭建集群。因?yàn)樾缕髽I(yè)集群一般規(guī)模不會太大，使用云原生支持的大數(shù)據(jù)組件一般不會有太多問題，而且會很好用。如果先用 Hadoop 以后再遷移的話就會很麻煩。現(xiàn)在用云廠商的產(chǎn)品搭建一個云原生的大數(shù)據(jù)平臺是很快的。
InfoQ：除了技術(shù)之外還有哪些挑戰(zhàn)？
A：我覺得主要還是人才方面的挑戰(zhàn)。作為一個技術(shù)人員要能發(fā)現(xiàn)行業(yè)趨勢。倒不是說要追逐最新的技術(shù)，但是如何選擇在合適的時間選擇合適的技術(shù)很重要。我前兩天也提到，如果面試中公司還在問 Hadoop 的問題，那么基本可以認(rèn)為這個公司的技術(shù)有點(diǎn)過時了。
以前 DevOps 有專門的運(yùn)維工程師，開發(fā)人員要自己掌控從開發(fā)、測試、發(fā)布的整個流程。以后，數(shù)據(jù)科學(xué)家和數(shù)據(jù)分析師大概率可以自己掌控?cái)?shù)據(jù)探索、數(shù)據(jù)分析和數(shù)據(jù)展示的這一整套流程。以前的 ETL 工程師可能就會更加局限，企業(yè)對他們的需求量變得更小。企業(yè)招人可能會更多地傾向數(shù)據(jù)分析師、數(shù)據(jù)科學(xué)家，因?yàn)榈讓右呀?jīng)標(biāo)準(zhǔn)化了。
從客戶那里也感覺到：數(shù)據(jù)分析師缺，懂業(yè)務(wù)的分析師也缺，既懂業(yè)務(wù)又懂技術(shù)的數(shù)據(jù)分析師更缺?，F(xiàn)在很多公司還處在建設(shè)大數(shù)據(jù)平臺的過程中，可能體現(xiàn)的不明顯。但隨著越來越標(biāo)準(zhǔn)化，大數(shù)據(jù)運(yùn)維的使用門檻會越來越低，企業(yè)會更愿意使用云原生的大數(shù)據(jù)平臺。
InfoQ：大數(shù)據(jù)平臺的云原生改造，主要涉及哪些方面？
A：云原生改造中，組件是一部分，但還有其他工作，如 CI/CD、日志管理、用戶管理、監(jiān)控等。大數(shù)據(jù)領(lǐng)域里還有數(shù)據(jù)質(zhì)量、元數(shù)據(jù)等都需要 K8s 環(huán)境下的管理系統(tǒng)。K8s 帶來的好處就是現(xiàn)在所有應(yīng)用都以同樣的模式發(fā)布，使用同一套資源管理體系。但像元數(shù)據(jù)管理、數(shù)據(jù)質(zhì)量管理、工作流調(diào)度等就不是 K8s 提供的了。
之前，Spark 在 Yarn 上面跑，ETL 要到 Hive 上跑，SQL 要在 MySQL 里跑，現(xiàn)在這些都要在 K8s 上，K8s 變得非常重要，這也需要聲明式 API 做整個集群管理。
現(xiàn)在，很多硅谷公司把 ETL 改成了代碼管理，Airflow 把調(diào)度管理也變成了代碼管理。所以，現(xiàn)在的一個趨勢就是 K8s 是把集群管理全部變成了代碼管理，大數(shù)據(jù)平臺遷移到 K8s 以后也可以做代碼及流水級代碼的管理，也可以用 Git 來管理。所以，大數(shù)據(jù)平臺的云原生改造不僅是組件，開發(fā)和管理形式也會發(fā)生很大的改變。
InfoQ：有沒有傳統(tǒng)大數(shù)據(jù)平臺與云原生大數(shù)據(jù)平臺的對比案例，可以詳細(xì)介紹下？
A：Snowflake 就是云原生大數(shù)據(jù)平臺最典型的例子。Snowflake 自己沒有存儲也沒有計(jì)算，它的計(jì)算能力用 K8s，存儲能力用各個云廠商的，它在中間是動態(tài)的，通過 K8s 給用戶發(fā)送一個專有的 MPP。
絕大部分云原生系統(tǒng)都可以做到存算分離，像 CSI，我在上面的應(yīng)用可以殺掉，CSI 存儲還在那，天然地就做到存算分離。應(yīng)用沒有訪問量時就叫停，有用戶使用時再分配資源，這樣做到錯峰資源、彈性擴(kuò)容。一個資源池可以統(tǒng)一分配資源，提高了資源利用率、管理效率和整個運(yùn)維效率，讓系統(tǒng)運(yùn)行更合理。十幾年前，一個略大的集群要幾十個博士才能搞定，現(xiàn)在一個本科生就可以，所以生產(chǎn)力的提高要靠標(biāo)準(zhǔn)化。
InfoQ：DataOps 做云原生改造的必要性在哪？
A：DataOps 做云原生改造主要是因?yàn)閮蓚€方面。首先是剛才說的標(biāo)準(zhǔn)化，DataOps 需要管理所有組件，但如果組件不是標(biāo)準(zhǔn)化的，那么這個事就很難做。其次，云原生帶來了各種產(chǎn)品，如 Spark，F(xiàn)link 等標(biāo)準(zhǔn)的統(tǒng)一。DataOps 包括五個方面：數(shù)據(jù)開發(fā)及 CI/CD、自動化調(diào)度、數(shù)據(jù)質(zhì)量、數(shù)據(jù)門戶、安全和審計(jì)合規(guī)，這些都要在云原生標(biāo)準(zhǔn)化基礎(chǔ)上才能實(shí)現(xiàn)。
