Cloudera機器學習版本采用云原生路徑

在之前它的預期收盤的最后一份季度報告的高跟鞋合并與Hortonworks，Cloudera的已宣布獲得一個新的云天然對應其預覽接入的能力Cloudera的數據科學工作臺(DSW)即進入全速在Kubernetes。值得注意的是，它帶有不同的品牌 -Cloudera機器學習(Cloudera ML)。

建筑和品牌反映了市場的兩個轉變。首先是遷移到云端。雖然我們估計只有大約25-30%%的Cloudera安裝基礎在云中運行工作負載，但云采用的速度是明確無誤的。Ovum預測，明年將有一半的新大數據工作負載在云上運行。這決定了支持云中可能的自動縮放類型。

第二個趨勢是AI，或者更具體地說是機器學習。當Cloudera最初發布DSW時，活動的主要內容是建立更多關于構建靜態的傳統數據科學模型 - 它們被部署，然后對模型所做的任何更改都由人完成。

今天，要說人們對AI(主要是機器學習形式)感興趣將是輕描淡寫。采用人工智能的舉措反映了模型，框架和計算比以往更容易獲得的事實 - 這要歸功于專用云服務和GPU資源的可用性，通過云計算不會迫使企業在未來三年內實現人工智能計算的資本預算。

此外，考慮到Databricks(適用于Spark工作負載)，Amazon SageMaker，Azure機器學習和Google Cloud AutoML等專用服務的可用性，Hadoop還可以替代運行機器學習工作負載。

您當然可以將DSW用于AI問題，但挑戰在于經濟地管理計算。因此，Cloudera為DSW產品增加了一個：Cloudera ML。它通過基于Kubernetes的新架構來響應這些趨勢，該架構繞過了內部部署Hadoop集群的YARN資源調度。需要說明的是，這并不能取代在Hadoop和YARN上運行的現有DSW，但它提供了另一個在Kubernetes環境中運行的版本。

這不是Cloudera第一次支持數據科學或ML工作負載的容器;通過使用容器，Cloudera可以打包物理部署所需的相互依賴性。但鑒于最初的DSW針對運行Hadoop集群的Cloudera Enterprise客戶，它在YARN下運行Spark工作負載以適應同一部署。

云是一個不同的故事。首先，數據湖通常位于云對象存儲中，而不是HDFS。其次，Cloudera CDH(使用YARN)不支持開箱即用的自動縮放 - 增加和減少計算容量的能力 - 因為它被設計為在數據和計算在同一節點上的集群上運行。隨著Kubernetes成為云原生計算的事實上的標準(甚至AWS，它擁有自己的專有容器管理服務，已經點點頭，并開始提供托管的Kubernetes服務)，模具就是為Cloudera投下的。如果它想支持云中的客戶，DSW或其繼任者將不得不接受Kubernetes，而不是YARN。

Cloudera ML目前處于有限的私人預覽狀態，支持訪問云對象存儲，HDFS和外部數據庫中的數據，部署在公共云中，或最終通過OpenShift部署(在私有云中)。

更廣泛的問題

雖然Cloudera ML是該公司首次發布的100%%Kubernetes產品，但我們并不認為這是一次孤立的嘗試或異常情況。在后臺，Apache Hadoop社區已著手將Hadoop與HDFS分離，以便云對象存儲也將成為一流的公民。由于Hadoop不再是運行大數據或特別是ML工作負載的唯一場所，我們不會感到驚訝，如果在某些時候，Cloudera釋放Cloudera ML在任何Kubernetes集群，本地或公共云上運行。

這就是一些更廣泛的問題。

顯然，Cloudera將繼續支持內部部署，這是其當前安裝基礎的核心。作為一個向云計算擴展的內部部署供應商，它將通過其對混合的支持而日益突出自己。但支持混合意味著添加云原生選項，就像現在通過增加其與Cloudera ML的DSW產品線一樣。那么，數據工程或數據倉庫等其他工作負載呢?在云中，這些也可以從運行Kubernetes集群中受益。

而這再一次導致了Hadoop Hadoop的長期存在的問題。回想一下，正在努力使Hadoop平臺更加適合云，從分離存儲到容納容器化工作負載。這些是Apache社區正在進行的長期計劃。所以，一旦你用云對象存儲替代HDFS，用Spark替換MapReduce，你還剩下什么?這就是多種類型工作負載的治理，管理和支持將Hadoop與大數據點服務區分開來的地方。資源是否由YARN或Kubernetes決定將成為一個學術問題。它甚至還不到2019年，但我們仍然會做出這樣的預測：將來，你運行的Hadoop將基于你如何部署它。