大数据平台是否更应该容器化?

大数据的发展历史

大数据技术起源于Google在2004年前后发表的三篇论文，分布式文件系统GFS、分布式计算框架MapReduce和NoSQL数据库系统BigTable，熟称"三驾马车"。在论文发表后，Lucene开源项目的创始人Doug Cutting根据论文原理初步实现了类似GFS和MapReduce的功能。并在2006年，将该部分功能设置成独立的项目即大名鼎鼎的Hadoop项目。Hadoop项目中主要包括分布式文件系统HDFS和大数据计算引擎MapReduce两个组件。

图片来源于网络

在早期，MapReduce既是一个执行引擎，又是一个资源调度框架，集群的资源调度管理由MapReduce自己完成。但是这样不利于资源复用，也使得MapReduce非常臃肿。于是一个新项目启动了，将MapReduce执行引擎和资源调度分离开来，这就是Yarn。2012年，Yarn成为一个独立的项目开始运营，随后被各种大数据产品支持，成为大数据平台上最主流的资源调度系统。伴随着时代的发展，大数据场景下的计算引擎层出不穷，主要的有内存式计算引擎Spark,分布式实时计算Storm,流计算框架Flink等。这些计算引擎都使用Yarn进行资源管理和调度。

大数据平台目前存在的问题

目前绝大多数大数据平台都是基于Hadoop生态，使用Yarn作为核心组件来进行资源管理和调度。但这样的平台普遍存在如下问题：

(1) **资源弹性不足，无法按需自动扩容。**大数据系统资源的高峰往往具有明显的周期性。例如实时计算资源消耗主要在白天。离线分析中，日报型的计算任务资源的高峰一般在22:00以后。周报和月报型的计算任务业务高峰往往也是在一个固定的时间点。并且离线计算有时还有突发的计算任务，例如需要对历史数据做一个统计。目前的大数据系统普遍缺乏资源的弹性，无法按需进行快速扩容，为了应对业务高峰和突发的计算任务只能预留出足够多的资源来保证任务能够正常响应。

(2) **资源利用率低。**日志留存和流量清单等存储密集型的业务CPU使用率长期小于30%。而计算类的业务虽然CPU消耗很高，但是存储的资源使用率小于20%。大量资源闲置。并且考虑在线业务往往在低峰期会有大量的资源闲置。这些资源其实离线计算业务是完全可以利用的，但目前大数据的系统架构这部分资源完全没有被利用。导致资源利用率进一步降低。

(3) **资源隔离性差。**从Hadoop2.2.0版本开始，Yarn开始使用cgroup实现了CPU资源隔离，通过JVM提供的内存隔离机制来实现内存资源隔离。对于磁盘IO和网络IO的隔离目前社区还在讨论中YARN-2139，YARN-2140。对于文件系统环境的隔离，社区在Hadoop 3.0版本中支持通过Classpath isolation HADOOP-11656来避免不同版本的jar包冲突，但无法做到完整的文件系统隔离。整体上看Yarn的资源隔离做的并不完善，这就造成了，多个任务运行到同一个工作节点上时，不同任务之间会存在资源抢占的问题，不同任务之间相互影响。

(4) **系统管理困难。**在大数据系统中缺少统一的管理接口，也缺少路由管理，网络管理，磁盘管理等能力。这就造成大数据平台的开发往往需要对管理系统进行深度定制。开发工作量大，系统管理困难，并且平台迁移困难。例如大数据平台中需要提供对大数据组件UI页面的访问能力。在大数据平台构建中，为了能够访问组件的UI页面往往需要单独进行网络的打通，进行额外的路由的配置。并且很多时候这些配置都缺少标准的接口，无法做到自动化，管理起来十分困难。

(5) **管理方式不统一。**在线业务和大数据业务虽然属于不同的业务类型，但就管理平台来说提供的功能是类似的。主要提供资源管理，业务(任务)管理，权限管理，可视化展示与操作等方面的功能。但