随着互联网的不断发展，越来越多的企业都引入了大数据或者是云原生编程等互联网新兴技术，而本文我们就通过案例分析来简单了解一下，云原生技术如何解决大数据系统问题。

　　一、大数据系统主要问题

　　传统的大数据系统围绕着Hadoop生态快速的发展，百花齐放，各个企业也逐步建立了自己的大数据平台，甚至是数据中台。然而，在激烈的市场竞争和不断增加的消费期望的双重驱动下，一方面业务需要快速迭代以满足迅速的增长，另一方面需要在资源需求不断增长的同时控制高昂的成本以保持企业的竞争力。这就要求大数据系统能够及时、快速的扩容以满足生产需求，又能尽可能的提高资源的使用效率，降低资源的使用成本。具体的问题体现在以下几点：

　　弹性扩缩容能力无法满足快速增长的业务需求：随着业务的发展，流量和数据量突增，尤其对于实时计算，需要资源能够及时的扩容，以满足业务需求。尽管一些大数据管控平台尝试实现自动的扩缩容(如通过集群负载情况，进行扩容)，然而，在传统大数据平台架构下，通常需要资源申请、依赖软件安装、服务部署等一系列步骤，该过程通常比较慢，对于集群负载的缓解，不够及时。

　　在离线分离部署及粗粒度调度无法提高资源的利用率：在传统Hadoop架构下，离线作业和在线作业往往分属不同的集群，然而在线业务、流式作业具有明显的波峰波谷特性，在波谷时段，会有大量的资源处于闲置状态，造成资源的浪费和成本的提升。在离线混部集群，通过动态调度削峰填谷，当在线集群的使用率处于波谷时段，将离线任务调度到在线集群，可以显著的提高资源的利用率。然而，HadoopYarn目前只能通过NodeManager上报的静态资源情况进行分配，无法基于动态资源调度，无法很好的支持在线、离线业务混部的场景。

　　操作系统镜像及部署复杂性拖慢应用发布：虚拟机或裸金属设备所依赖的镜像，包含了诸多软件包，如HDFS、Spark、Flink、Hadoop等，系统的镜像远远大于10GB，通常存在镜像过大、制作繁琐、镜像跨地域分发周期长等问题。基于这些问题，有些大数据开发团队不得不将需求划分为镜像类和非镜像类需求，当需要修改镜像的需求积累到一定程度，才统一进行发布，迭代速度受限，当遇到用户紧急且需要修改镜像的需求时，势必面临很大的业务压力。同时，购买资源后，应用的部署涉及到依赖部署、服务部署等环节，进一步拖慢应用的发布。

　　二、云原生技术如何解决大数据系统问题

　　云原生技术如何解决弹性扩容问题:在云原生架构中，应用程序及其依赖环境已经提前构建在镜像中，应用程序运行在基于该镜像启动的容器中。在业务高峰期，随着业务量的上升，向云原生环境申请容器资源，只需等待镜像下载完成即可启动容器(一般镜像下载时间也是秒级的)，当容器启动后，业务应用将立即运行并提供算力，不存在虚拟机的创建、依赖软件安装和服务部署等耗时的环节。而在业务低峰期，删除闲置的容器，即可下线相应的应用程序，以节省资源使用的成本。借助云原生环境和容器技术，可以快速的获取容器资源，并基于应用镜像秒级启动应用程序，实现业务的快速启停，实时的扩缩容业务资源以满足生产需求。

　　云原生技术如何解决资源使用率低的问题:在传统架构中，大数据业务和在线业务往往部署在不同的资源集群中，这两部分业务相互独立。但大数据业务一般更多的是离线计算类业务，在夜间处于业务高峰，而在线业务恰恰相反夜间常常处于空载状态。云原生技术借助容器完整(CPU，内存，磁盘IO，网络IO等)的隔离能力，及kubernetes强大的编排调度能力，实现在线和离线业务混合部署，从而使在离线业务充分利用在线业务空闲时段的资源，以提高资源利用率。

　　另外，使用无服务器(serverless)技术，通过容器化的部署方式，做到有计算任务需求时才申请资源，资源按需使用和付费，使用完之后及时退还资源，极大的增加了资源使用的灵活性，提升资源使用的效率，有效的降低了资源使用的成本。

　　云原生技术如何解决发布周期长的问题:传统大数据系统中，所有环境基本上使用同一个镜像，依赖环境比较复杂，部署、发布周期往往比较长。有时基础组件需要更新，因为需要重新构建镜像，并上传到各个地域，耗时可能长达数天。而云原生架构使用容器进行部署，应用的发布和基础组件的更新都只需要拉取新的镜像，重新启动容器，具有更新速度快的天然优势，并且不会有环境一致性的问题，可以加快应用发布的节奏，解决应用发布周期长的问题。