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

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

為此，我們連線了智領雲聯合創始人兼 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：Twitter 什麼時候開始做雲原生大資料平台的？當時為什麼要做？效果如何？這為國内大資料平台帶來哪些思考？

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、自動化排程、資料品質、資料門戶、安全和審計合規，這些都要在雲原生标準化基礎上才能實作。