谷歌發布Cloud Dataproc on K8s，撬動大數據格局
谷歌今天宣布其託管的Spark和Hadoop發行版：Cloud Dataproc如今可以在Kubernetes上運行，至少alpha測試版是這樣。它聽起來可能不是特具開創性，但如果你考慮為了把YARN換成Kubernetes on Cloud Datarpoc所做的工作，以及谷歌承諾會將昔日Hadoop架構的其他組件引入到Kubernetes領域，你就會意識到谷歌在做出多大的投入來更新改造整個大數據架構。但社區會跟上來嗎？
YARN有什麼問題？它是一種相當笨重的架構。一段時間以來，人們一直試圖更換YARN。YARN最初是為了在裸機上運行而設計的，後經過改動可在虛擬機上運行，但YARN管理層的前進步伐不如K8s來得快，這促使許多客戶對K8s頗有興趣。
客戶在YARN方面存在幾個痛點，眼下使用YARN中的容器雖好，但不是很好。它不是從頭開始針對容器化工作負載設計的。
直到今天，Cloud Dataproc像其他所有Hadoop發行版一樣運行，無論在雲端還是在本地。也就是說，Cloud Dataproc依賴YARN作為底層的工作負載和集群管理器。谷歌在該服務中提供的所有數據處理引擎：從Spark和MapReduce到Pig和Flink都依賴YARN來分發計算資源，防止工作負載發生衝突，就像其他雲和本地Hadoop集群一樣。
谷歌客戶依賴YARN，這可能令人驚訝，尤其是鑒於Kubernetes備受炒作，幾乎每個人似乎都一致認為Kubernetes是YARN的繼承人。畢竟，Kubernetes是在谷歌開發的，源自這個互聯網巨頭用來在自己的數據中心確保工作負載「循規蹈矩」的軟體。
你可能忍不住以為Kubernetes已經滲入到谷歌雲中，谷歌公布的所有雲服務都可以以Kubernetes承諾的精細化、永久可擴展的理想方式來運行。不過你那樣想就錯了。直到2019年初谷歌才宣布Kubernetes operator for Spark。這讓客戶得以在使用Kubernetes管理的谷歌雲平台集群上運行Spark。但Cloud Dataproc不一樣。
與Cloudera的Hadoop發行版一樣，Cloud Dataproc由眾多開源組件組成，與Apache BigTop捆綁在一起。客戶可以在GCP上隨意運行幾乎任何任務。但如果他們想要一款擁有集中安全、日誌記錄、服務級別協議（SLA）和出色管理控制台的大數據平台，那麼就要關注像Cloud Dataproc或其他Hadoop產品這樣的託管系列，比如AWS的Elastic MapReduce（EMR）或微軟Azure的HDInsight。
Apache Spark是一種集群計算框架，旨在用作面向ETL（提取、轉換和載入）或數據科學應用的處理引擎。它常與Apache Hadoop結合使用，後者提供了用於管理資源的YARN（另一種資源協調者）和面向分散式數據存儲的HDFS。
Hadoop沒有死，它只是移到了雲端。
平台大整改
採用Kuberentes需要在大數據架構的許多層面編寫和測試大量的新代碼，包括底層數據平台層面和單個引擎層面。
但是改用Kubernetes的好處將體現在處理引擎之間更充分的隔離、Hadoop架構中互相依賴性減弱以及可擴展性加強。
谷歌Cloud Dataproc及其他雲產品的高級產品經理James Malone表示，谷歌有能力在各個層面予以幫助，包括單個開源項目。
Malone說：「這從某種意義上來說是涉及兩條戰線的較量，我們在努力實現目標。對於託管服務來說，這是重大變化，但也在開源界帶來了巨大變化，我們在積極開展開源工作。每個開源項目內部都需要大有作為。這就是為什麼我們努力開這個頭。」
谷歌聘請Apache Spark項目的代碼提交者，開始開發Kubernetes for Spark operator，即將發布的Spark版本會隨帶該產品的正式版。谷歌今天還宣布了Kubernetes operator for Flink，並與Presto和Druid背後的人合作，開發針對這些開源項目的Kubernetes operator。
Malone告訴IT外媒Datanami：「我們選擇這四個項目的原因之一是，它們不太依賴其他項目，因此它們的獨立性強一點。它們先遷移到Kubernetes更容易一點。另外它們的人氣超旺，這也很不錯。我想，隨著時間的推移，我們會開始關注如何讓像Hive這樣的技術在Kubernetes上也可以運行。」
在平台層面，谷歌剛在Cloud Dataproc上完成了支持Kubernetes的第一次迭代。但Malone表示，這不是大規模的改變，因為谷歌承諾無限期支持YARN版本。
他說：「我們仍會在可預見的未來很長時間內提供YARN版本的Dataproc。我們期望到時候許多客戶會開始在Kubnerntes上進行更多的開發測試工作，到時會迎來一個拐點，即許多新的開發工作會在Kubernetes上進行。」
Malone表示，事實上，谷歌正在努力確保YARN版本的Dataproc和Kubernetes版本的Dataproc在代碼和兼容性方面儘可能接近，好讓客戶能夠在兩者之間來回切換。
更廣泛的混合環境
谷歌很重視讓大數據社區採用Kubernetes，這引出了第三個因素：Anthos，這是它的本地運行時環境。Anthos基於Kubernetes，計劃將來某個時候推出可以在Anthos上運行的Cloud Dataproc版本。
Malone說：「Anthos是我們針對混合雲和多雲的長期戰略中至關重要的一部分，而Anthos基於Kubernetes。因此我們讓Dataproc正常工作、讓所有開源組件在Dataproc上正常工作，這還為將來Dataproc在Anthos上運行鋪平了道路，這一點對我們來說很重要，可為客戶提供隨地使用我們服務的那種靈活性。」
按照Malone的說法，谷歌致力於通過支持讓客戶能夠隨意遷移的開放標準來幫助社區。這可能會削弱谷歌雲的鎖定，並減少收入，不過給整個社區帶來了降低依賴性和複雜性的好處，這麼做完全值得。
他說：「我是Spark開發人員。假設我拿來我的Spark代碼後，要在本地環境中的Dataproc、EMR或Cloudera上運行。我得考慮Hadoop架構中的所有組件是什麼版本。我使用什麼版本的操作系統？這個環境是什麼樣子的？我如何調整該集群以應對資源約束或可用性？」
「如果我們改用Kubernetes，就會容易得多，因為我作為開發人員可以拿來我的代碼，用需要的任何依賴項來打包代碼，不用再操心老實講對我來說其實不增值的東西。這為客戶大大提高了靈活性。」
谷歌將Apache Spark實施到Kubernetes上。
通過結合Cloud Dataproc和Kubernetes，谷歌使數據科學家能夠跨任何環境統一資源管理、隔離作業並構建彈性基礎設施。開源工作負載的可移植性也大大加強。
此外，Cloud Dataproc on Kubernetes提供了谷歌所說的「自癒合環境」；在這個環境中，基礎設施管理任務都實現了自動化，比如集群的選型和搭建、Docker文件處理和網路配置。
