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将基于你如何部署它。