大数据平台如何进行云原生改造

如今，企业都面临着日益增长的数据量、各种类型数据的实时化和智能化处理的需求。此时，云原生大数据平台的高弹性扩展、多租户资源管理、海量存储、异构数据类型处理及低成本计算分析的能力，受到了大家的欢迎。但企业应该如何做好大数据平台的云原生改造和升级呢？

为此，我们连线了智领云联合创始人兼 CEO 彭锋博士，一起来探讨大数据平台如何进行云原生改造。以下根据直播内容整理，有不改变原意的删减，完整内容可点击查看回放视频。

InfoQ：云原生技术体系具体都包括哪些技术类别？像 IaaS、PaaS 和 SaaS 跟云原生有什么关系？

A：虽然“云原生”近几年才火起来，但是业界在 2000 年初就开始做了。我 2005 年博士毕业加入 ask.com 后也是做云平台，当时的团队叫中间件团队（middleware）。Amzone 最开始做 IaaS 的时候还没有云原生的概念，先行者是制定了云原生 12 原则的 Heroku，它当时允许 APP 直接发到网上而不需要管理服务器，这也是早期的云原生应用。当时也没有现在很火的 K8s，所以云原生绝对不只是 K8s。容器的概念也是在 Docker 之前就已经出现，所以容器也不仅仅是 Docker。

云原生以前的门槛很高。我们在 Ask 的时候，几乎都是博士学历的人在做云平台，在 Twitter 的时候，基本上也没几个人会用。云原生概念从开始到现在的普及，大概用了 20 多的时间。其中最关键的是容器、微服务和声明式 API， 大家常说的 CI/CD 其实并不是云原生架构独有的。云原生关键的是面向资源编程，向系统申请需要的资源后就不需要管调度的细节了，应用的自动发布、容错，迁移等都是系统负责。面向资源编程，对整个分布式系统的开发、管理和易用性都有很大的好处。

InfoQ：大数据平台的云原生改造会把这些技术都运用起来吗？

A：一定是的。实际上，阿里做飞天的时候用的就是云原生技术。Hadoop 有三大组件：文件系统 HDFS、计算引擎 MapReduce、资源管理器 Yarn。现在 MapReduce 基本被 Spark 取代，作为存储的 HDFS 还有不少的应用，Yarn 的地位比较尴尬，因为它跟 K8s 做的都是资源管理的事儿。所以我觉得 MapReduce 和 Yarn 马上就要被淘汰了，像 Spark 以及大部分的数据应用现在都可以直接在 Kubernetes 上跑，所以大数据系统就并不再需要 Yarn 了。对于 HDFS，则会有一个云原生改造的升级。

Hadoop 本来有个对象存储系统 Ozone，现在 Ozone 被单独挪出去，不在 Hadoop 体系了。Hadoop 原来的这一套体系，大概率在三到五年后就会被完全被淘汰。这个改造是不可避免的，基于原来 Hadoop 生态体系的大数据平台一定会迁移到云原生平台。

InfoQ：Twitter 什么时候开始做云原生大数据平台的？当时为什么要做？效果如何？这为国内大数据平台带来哪些思考？

A：很早，大概 2011 年的时候。Mesos 上生产后，除了 Hadoop，其他所有应用都在 Mesos 上跑。当时，Mesos 就能支持 Twitter 内部八千多台机器的集群。Mesos 有自己的管理器，其实是走在 K8s 前面的。

我们当时为什么觉得这个很厉害？因为以前要发布一个系统，先得去申请机器、买机器，机器买回来后安装，装完后还要去测试。即使测试好了，也还要担心几个系统之间的第三方库有没有冲突。

大数据系统都是开源的。开源有个好处，就是便宜。开源不好的地方就是各个系统之间没有控制，两个开源系统依赖的第三方库有冲突。比如开源项目 A 用的是第三方库 C，另外一个开源项目 B 也用第三方库 C，但是两个项目依赖的 C 版本不一样，安装在同一个机器上就经常出问题，这是一个技术性的问题，困扰了大家很多年。

有了云原生功能后，每个应用都是自己的容器。我们当时用的还不是 Docker，是 universal container。这是 Mesos 自己做的一个容器，好处就是容器化、隔离，不会担心大家互相影响，应用可以实现秒级发布，对生产力的解放是革命性的。所以云化是必然趋势，大数据平台也遵从这样的趋势。

以后做的软件如果不是云原生的，百分之百不会有人用。因为，现在所有的新软件都用云原生的方式运行，老的软件就慢慢地跟不上了，不能说再单独搞个集群。所以，不能在云平台上跑的应用一定会被淘汰。

InfoQ：现在使用云原生大数据平台的主要是哪些类型的企业？企业数量有怎样的变化？

A：主要是互联网和大厂。现在的云原生大数据平台还不成熟。相比之下，企业更容易招到熟悉 Hadoop 技能的人。其次，这些大数据组件的云原生成熟度还不是特别高。Spark 今年 3 月份才具有一般可用性(General availability，GA) ，并发布了 3.1 版本。Kafka 在今年 5 月份宣布 Kubernetes  GA 但还没有开源。这两件事说明了现在主流的大数据组件厂商都在往 Kubernetes 上靠。这里就涉及到的 Spark、Hive 等核心组件以及他们依赖的相关组件都要升级，系统层面的升级对一般企业来讲是比较麻烦的。

国外的像 Twitter、Uber、Airbnb 等都在做这个事情，但他们的解决方案有的不是很理想。比如 Uber 是把整个 Yarn 挪到了 Kubernetes 上，这个有点不是特别好，我觉得应该把 Yarn 去掉，其他组件直接云原生化，比如类似于 MongoDB 的组件已经逐渐有 Kubernetes 发布版本出来。

综合起来的情况是， 现在大家都在推进，但还没有到特别成熟的阶段。

InfoQ：大数据平台目前存在的哪些问题？为什么云原生技术可以解决这些问题？

A：现在的大数据平台能解决基本的数据需求问题，但还有两个很大的问题需要解决。首先是资源管理。Yarn 的资源管理的粒度做得不是特别好，在多租户隔离和资源抢占上都能力有限，类似于 Spark 的应用没法混排，没法像云原生那样做到存算分离，计算和存储不能够充分利用每个节点的资源。最关键的是现在其他应用慢慢都不会为 Yarn 去做升级了，后续运维和升级会是问题。

其次，并不是说现在的大数据平台解决不了现在的问题，但是社区和生态的迁移已经是很明确的了。例如刚才说到的，像 MongoDB 都可以在 Kubernetes 跑，以后可能为了 Hadoop 就得单独搞一个集群。但如果用云原生的存储，就不需要单独一个集群了。所以，任务混排、资源隔离以及对新应用的支持等都是 Hadoop 体系现在比较大的硬伤。

InfoQ：具体实践中，云原生技术是如何针对这些问题进行改造和升级的？开发人员应该如何做技术选型？

A：现在所有的资源管理和编排可以依赖于 Kubernetes，企业可以专注在自己的业务逻辑和管理上。比如，现在容器存储接口（Container  storage  interface，CSI）越来越成熟，只要存储系统满足接口要求，那么无论是哪家提供商的应用就都可以访问。动态的依赖、发布和容错都可以依赖 Kubernetes 来做，这比要同时运行两个不同的集群要好很多。

另外，原来的 Hadoop 应用大概率不需要重写，因为它现在有专门兼容原来 HDFS 的存储，将兼容数据拷贝到 HDFS 兼容的存储上后，应用同样可以运行。现在我们要做的是，让 Hive 直接运行在 Spark 上、Spark 运行在 K8s 上，如此 Hive 的程序也不需要做大量的迁移就可以直接挪到 K8s 上，这样就能实现 K8s 集群的平稳迁移。

InfoQ：大数据平台做云原生改造的技术难点是什么？

A：技术难点还是不少的，主要还是现在的大数据组件对 K8s 的支持还不是特别成熟，这是开源组件的问题。我举个例子。Spark 本身也依赖于很多别的开源组件，这些组件有的还没有支持 K8s，支持 K8s 组件中的版本也不一样。每个开源组件都号称自己支持 K8s，但把所有这些支持 K8s 的组件放到一起时，就会发现各种各样的版本存在冲突。还有一个问题就是 K8s 的升级太快。K8s 现在基本上每个季度升级一次，着也导致底下每个大数据组件支持的 K8s 版本不一样。总之，当前整个生态还不能协调地支持 K8s。

虽然很多大数据产品厂商都在做 K8s 支持，但在生产中还属于实验阶段。大家都还是处于刚刚起步的状态。从 K8s 自身来说，K8s 对有状态应用的支持和 CSI 存储方面的支持这两年也才完善起来，这两点是最大的技术难点，这也是大家最近一两年开始往 K8s 上迁移的原因。

InfoQ：开发人员怎么做技术选型？

A：我觉得，如果企业现在已经有 Hadoop 了，如果想未雨绸缪做迁移，那么可以开始尝试。一些不重要的业务可以先在云原生体系里跑起来，逐渐完善其稳定性，然后再逐渐扩展云原生集群。这个过程中，企业可以借用 K8s 管理体系不断完善流程。我不建议马上把 Hadoop 全搞过来，但是至少有一个测试集群，做好业务流程的验证。

如果是新的企业，我强烈建议直接在 K8s 上搭建集群。因为新企业集群一般规模不会太大，使用云原生支持的大数据组件一般不会有太多问题，而且会很好用。如果先用 Hadoop 以后再迁移的话就会很麻烦。现在用云厂商的产品搭建一个云原生的大数据平台是很快的。

InfoQ：除了技术之外还有哪些挑战？

A：我觉得主要还是人才方面的挑战。作为一个技术人员要能发现行业趋势。倒不是说要追逐最新的技术，但是如何选择在合适的时间选择合适的技术很重要。我前两天也提到，如果面试中公司还在问 Hadoop 的问题，那么基本可以认为这个公司的技术有点过时了。

以前 DevOps 有专门的运维工程师，开发人员要自己掌控从开发、测试、发布的整个流程。以后，数据科学家和数据分析师大概率可以自己掌控数据探索、数据分析和数据展示的这一整套流程。以前的 ETL 工程师可能就会更加局限，企业对他们的需求量变得更小。企业招人可能会更多地倾向数据分析师、数据科学家，因为底层已经标准化了。

从客户那里也感觉到：数据分析师缺，懂业务的分析师也缺，既懂业务又懂技术的数据分析师更缺。现在很多公司还处在建设大数据平台的过程中，可能体现的不明显。但随着越来越标准化，大数据运维的使用门槛会越来越低，企业会更愿意使用云原生的大数据平台。

InfoQ：大数据平台的云原生改造，主要涉及哪些方面？

A：云原生改造中，组件是一部分，但还有其他工作，如 CI/CD、日志管理、用户管理、监控等。大数据领域里还有数据质量、元数据等都需要 K8s 环境下的管理系统。K8s 带来的好处就是现在所有应用都以同样的模式发布，使用同一套资源管理体系。但像元数据管理、数据质量管理、工作流调度等就不是 K8s 提供的了。

之前，Spark 在 Yarn 上面跑，ETL 要到 Hive 上跑，SQL 要在 MySQL 里跑，现在这些都要在 K8s 上，K8s 变得非常重要，这也需要声明式 API 做整个集群管理。

现在，很多硅谷公司把 ETL 改成了代码管理，Airflow 把调度管理也变成了代码管理。所以，现在的一个趋势就是 K8s 是把集群管理全部变成了代码管理，大数据平台迁移到 K8s 以后也可以做代码及流水级代码的管理，也可以用 Git 来管理。所以，大数据平台的云原生改造不仅是组件，开发和管理形式也会发生很大的改变。

InfoQ：有没有传统大数据平台与云原生大数据平台的对比案例，可以详细介绍下？

A：Snowflake 就是云原生大数据平台最典型的例子。Snowflake 自己没有存储也没有计算，它的计算能力用 K8s，存储能力用各个云厂商的，它在中间是动态的，通过 K8s 给用户发送一个专有的 MPP。

绝大部分云原生系统都可以做到存算分离，像 CSI，我在上面的应用可以杀掉，CSI 存储还在那，天然地就做到存算分离。应用没有访问量时就叫停，有用户使用时再分配资源，这样做到错峰资源、弹性扩容。一个资源池可以统一分配资源，提高了资源利用率、管理效率和整个运维效率，让系统运行更合理。十几年前，一个略大的集群要几十个博士才能搞定，现在一个本科生就可以，所以生产力的提高要靠标准化。

InfoQ：DataOps 做云原生改造的必要性在哪？

A：DataOps 做云原生改造主要是因为两个方面。首先是刚才说的标准化，DataOps 需要管理所有组件，但如果组件不是标准化的，那么这个事就很难做。其次，云原生带来了各种产品，如 Spark，Flink 等标准的统一。DataOps 包括五个方面：数据开发及 CI/CD、自动化调度、数据质量、数据门户、安全和审计合规，这些都要在云原生标准化基础上才能实现。