【数据湖计算篇】云原生计算引擎挑战与解决方案

云原生背景介绍与思考

图一是基于ECS底座的EMR架构，这是一套非常完整的开源大数据生态，也是近10年来每个数字化企业必不可少的开源大数据解决方案。主要分为以下几层：

• ECS物理资源层，也就是Iaas层
• 数据接入层，例如实时的Kafka，离线的Sqoop
  存储层，包括HDFS和OSS，以及EMR自研的缓存加速JindoFS
• 计算引擎层，包括熟知的Spark，Presto、Flink等这些计算引擎
• 数据应用层，如阿里自研的Dataworks、PAI以及开源的Zeppelin，Jupyter

每一层都有比较多的开源组件与之对应，这些层级组成了最经典的大数据解决方案，也就是EMR的架构。我们对此有以下思考：

• 是否能够做到更好用的弹性，也就是客户可以完全按照自己业务实际的峰值和低谷进行弹性扩容和缩容，保证速度足够快，资源足够充足
• 不考虑现有状况，看未来几年的发展方向，是否还需要支持所有的计算引擎和存储引擎。这个问题也非常实际，一方面是客户是否有能力维护这么多的引擎，另一方面是是否某些场景下用一种通用的引擎即可解决所有问题。举个例子说Hive和Mapreduce，诚然现有的一些客户还在用Hive on Mapreduce，而且规模也确实不小，但是未来Spark会是一个很好的替代品。
• 存储与计算分离架构，这是公认的未来大方向，存算分离提供了独立的扩展性，客户可以做到数据入湖，计算引擎按需扩容，这样的解耦方式会得到更高的性价比。

(图1 基于ECS的开源大数据解决方案)

基于以上这些思考，我们考虑一下云原生的这个概念，云原生比较有前景的实现就是Kubernetes，所以有时候我们一提到云原生，几乎就等价于是Kubernetes。随着Kubernetes的概念越来越火，客户也对该技术充满了兴趣，很多客户已经把在线的业务搬到了Kubernetes之上。并且希望在这种类似操作系统上，建设一套统一的、完整的大数据基础架构。所以我们总结为以下几个特征：

• 希望能够基于Kubernetes来包容在线服务、大数据、AI等基础架构，做到运维体系统一化
• 存算分离架构，这个是大数据引擎可以在Kubernetes部署的前提，未来的趋势也都在向这个方向走
• 通过