本文部分内容依据周昕毅老师和童光辉老师的〖deeplus直播：话题接力丨大数据上云，如何发挥出1 1＞2的优势？〗线上分享演讲内容整理而成。
近年来，通过融合大数据与云计算技术，利用云计算对资源的弹性管理能力，以破解大数据领域面临的资源管理粗放、资源利用率低等困境，已经成为业界发展趋势。进入云原生时代后，大数据和云计算进一步深度融合, 拥抱云计算走向云原生化。企业应该如何做好大数据平台的云原生改造和升级，让大数据上云发挥出1 1＞2的优势？
为此，dbaplus社群邀请到携程研发总监-周昕毅、腾讯PCG大数据平台部SRE负责人-童光辉两位老师，希望汇集两位大数据专家的研究成果和实践积累，给大家进一步明确大数据平台发展的方向，提供可参考、可落地的大数据上云实战经验。
Q1
如何理解“大数据上云”当中大数据与云原生的关系？目前大数据上云是否已成业界常态？
周昕毅
携程的大数据平台进行云原生改造已经大约有2年时间，关注点主要在于运维的标准化、提升系统的可观测性、提升容量管理的能力，这些方面都按照云原生的最佳实践作为指引。对于云原生几个核心的落地技术，比如容器化技术、服务网格、微服务、不可变基础设施，是作为我们设计架构的参考。但对于大数据平台存储的一些基座去进行云原生改造，其实也会遇到比较大的挑战，所以我们目前还是解决一些管理工具的微服务化。
是否上云，何时上云，与各家公司的数据规模、发展阶段、基础设施和工具选型有关，各家公司一般会从效率、成本等角度选择适合自己业务场景的上云方案。
童光辉
大数据和云原生在最开始的时候其实是两个话题，大数据远远早于k8s的流行，在Google著名的“三驾马车”之后，大数据开始发展起来。在k8s开始流行的时候，当时也不是大数据云原生，我们主要会做一些离在线的混合部署，从而提高我们的资源利用率。
下一个阶段是在硅谷以Snowflake为代表公司，他们会做简单的一站式以提高效率，把大数据进行一定的云原生改造，然后做相关的存算分离，这个模式被多数人所接受。因为从交付到部署再到使用，大数据被发现还存在着很多效率上的不足，通过结合云可以把它做得更好，而且硅谷已经有大量公司上市作为典范。国内则可能是在2019年之后，很多公司开始把大数据和云原生结合起来做大数据上云这件事，在近一两年里，大厂BAT、携程、美团等企业的大数据上云相对而言已经比较深入了。
所以今天讨论大数据上云，我希望可以回到大数据上云之后在效率和成本方面能够得到什么，在这个过程中其实还有很多坑和问题，并不是简单地将大数据与云原生叠加起来就可以得到1 1＞2的收益。
Q2
能否分享一下贵司围绕大数据上云做的相关实践？目前已取得了哪些成果？有哪些可参考、可落地的经验总结？
周昕毅
携程大数据平台目前还是以私有云自建主体，在公有云上也使用了部分产品，包括SaaS的产品、一些IaaS的基础设施，以及搭建的一些服务，可以说是比较初期的混合云架构。在海外的一些数据平台也有使用公有云实现大数据的SaaS服务等相关实践，但是主要的流量和数据量依然在私有云的平台上。
目前也在推进一些冷数据的项目，我们发现对象存储可以解决多数存算分离的场景，因此我们的私有云和公有云现在都大量在使用对象存储服务。私有云对象存储主要存放一些对延迟比较敏感的相对热的数据，而冷数据我们是通过控制带宽的方式分批传输到云的对象存储上，云上也可以使用一些价格比较低廉的归档型的存储以节省成本，基于对象存储服务构建云原生的数据湖。
我们认为对象存储能够解决一些实际问题，同时我们也在谋求落地的场景。比如用JuiceFS把对象存储的一些Bucket和桶通过POSIX协议挂载到服务器上，从而可以更灵活地让很多还没有来得及做云原生改造的应用用到云原生的数据存储，然后我们也在尝试把对象存储作为HDFS集群的存储基座，目前只是少部分的尝试。
我们在这几个方向上都有做一些探索性的实践，而我们大数据一些计算引擎相关的集群是比较适合做云原生改造的，因为我们先做计算的改造，后面存储暂时没有大的变动。比如Flink的实时计算，我们已经支持它能够提交到私有云的K8S集群或者Yarn集群，也可以提交到公有云的k8s集群，能够做灵活的资源调配。
童光辉
我们的团队围绕大数据上云的实践有以下几个方面：
首先在最大规模的HDFS存储这一块，我们还是采取裸金属的方式，因为它很重要，且体量大，短期收益不大，因此我们短期内不会进行大幅度改造。
然后我们在分布式计算这一层做得比较深入，最开始我们是做一定的在离线混部，在线和离线相对还是比较隔离的两套k8s环境，后来我们发现效率和质量方面还是存在一些问题。到现在我们已经把在线和离线通过内部的调度系统屏蔽成一层，相当于一个完整的资源点，能够充分地使用在离线的资源。同时如果在线的资源需要紧急扩容，它可以抢占一部分的离线资源，但是它会遵循相应的质量策略，比如哪些应该先被下线或者销毁，从而做到在离线资源的打通。
在其他领域我们做了更大胆的上云动作，比如在MQ这个领域，因为我们底层所用的机器很好，单个的程序无法把一台机器利用率跑得很满则比较浪费，所以我们把存算一体的kafka全部搬到k8s集群里，需要迁移时kafka调度先把数据进行迁移，再返回来去做k8s Pod的销毁，通过容器化提高机器的利用率实现了比较好的成本优化。
另外，在上层的应用组件方面，比如impala、presto查询，我们选择存算分离方案，因为底层的HDFS，包括对象存储，相对来说是比较稳的，在计算层我们就把impala、presto直接放到我们的容器里面。我们的查询有时候比较大，如果用传统物理去部署在资源扩容上效率有一些瓶颈，容器化后大的查询就扩容，不需要就销毁掉一部分容器缩容，实现效能的提高和成本的优化。
在这几个方面我们会做得比较多，在公有云上我们可能会做更大胆的尝试，把底层的所有环境都换成云原生。如果客户需要一整套的大数据环境，他可以勾选他想要的，我们则快速实现部署的能力，给他交付出他想要的私有云环境。
Q3
当企业大数据平台面临哪些场景需求和痛点的时候，可以考虑大数据平台上云？需要具备哪些上云条件？上云初期应当注意哪些问题避免踩坑？
周昕毅
我们遇到什么场景的时候可以考虑上云，其实也不局限于大数据的工具，可能上云的其他在线应用也有类似的情况。
第一个方向是快速尝试最新技术栈。云厂商在各技术领域都会适时推出新技术栈的SAAS服务，可以让企业快速上手，降低适用门槛。
第二个方向是云厂商的高性能硬件。例如新型号GPU、新一代CPU、高性能SSD硬盘、百GB网卡等高性能硬件，在AI/BI领域可以发挥极大作用。
第三个方向是弹性需求。大数据平台的写入需求和查询需求往往在一天内有明显的波峰波谷，通过云的弹性能力可以尝试进行计算资源的自动扩缩容，对数据存储进行冷热分离。
最后一个方向是高性价比的S3对象存储服务，这也是携程用的感触比较深的方向。主流云厂商都会提供兼容S3协议的Object Storage Service，适用场景众多，成本低廉，天然支持存算分离的应用架构。如果对于对象存储有需求，但是又缺乏部件，这也是一个不错的切入点。
童光辉
上云听着很美好，且是技术正确的一个选择。但我觉得需要回归到本质——我们想要什么，即企业的痛点是什么？到底是想解决人的问题，还是想解决购买资源的钱的问题。
我觉得在中小型企业可能优先考虑解决人效的问题，其实要做整个大数据上云，上云只是冰山上的东西，冰山下的服务器、带宽、基建等一切东西，需要一个完整的支撑团队去思考和解决，一般的小企业难以负担这个成本。所以我觉得中小型企业尽量考虑用各种比较成熟的云上组件，实现从自己小的私有云放到了云上的公有云，可能在资源上会略贵，但是人力成本和质量保障方面会更好。
对于中大型企业来说，可能既要解决人的问题，又要解决钱的问题。如果企业资源利用率特别高，且没有能够做得更高的手段，那么上云需要慎重考虑。如果企业资源利用率还有很多提升空间，那么需要考虑是不是在上云过程中可以解决。因为如果从省钱的角度，把服务器压榨到极致，同时团队有足够的人力和资源，可以考虑从供应链的角度出发，在服务器采购、机房选择、带宽的支撑能力上，需要做哪些能力才能把云上的服务器、应用程序利用率做到极致，最后为企业节省成本，同时借助上云过程各方面的改造，实现人效的优化。
其实我觉得上云本身是一个企业IT治理的过程，它不仅仅是把一个东西放到k8s就完成了的事情。既然是IT治理，那么其实是一个非常体系的思考，里面也有非常多的问题点，所以上云之前一定要思考清楚，我甚至了解到部分团队上云之后发现成本更高了。所以企业需要注意：不要为了上云而上云，而是需要明白自身到底想从上云过程中得到什么。
Q4
在具体实践中，云原生技术是如何对大数据平台进行改造和升级的？主要涉及哪些方面的实践？
童光辉
以我们的MQ为例，上云之后我们做的第一件事情就是把我们整个现有服务器的选型，包括上面的应用场景，以及后面我们设定的利用率提升目标提前规划好。
其次结合我们的整体架构能力、对质量上的需求，以及最终和k8s相关的调度方面的配合，也要做好规范，满足上云最基础的设计。
存算一体上云有一个很重要的地方，我们要适当降低它的迁移动作，那么Pod的规格设计要结合机型去做，在保障装箱率的情况下尽可能降低一些迁移导致的数据搬迁的频次。而且因为大数据我们的流量会比在线高很多，所以需要考虑清楚容器网络模式和机房带宽。
在实现上云的路径上，也要考虑到整个运维支撑能力的建设，因为在传统机器，如裸金属或IDC机器上的运维，服务器投放、机器初始化等和云上面还是会有所不同。此外，在Pod销毁或k8s遇到各种各样的故障时，我们的SOP、自动化工具也要提前做好准备。
最后就是要做好各方面的风险评估，并且做好演习，再谨慎地操作上云的节奏，以免出现比较大的问题。比如机器上可能磁盘满了某些自动运维工具会做一些日志数据删除，kafka数据落盘结尾就是.log的，被误删就会造成数据的丢失。
大数据上云过程里还会有很多细节性的问题，这里不一一列举了。总结起来就是：首先要做好整个架构评估和质量保障的风险评估，然后做相应的架构设计，工具的建设一定要先行，再逐步上云，而不是盲目追求速度，否则遇到重大的质量问题时可能会比较被动。
周昕毅
大数据平台其实是一个非常典型的有状态应用，而且是一个比较有历史的应用，比云原生的概念提出早很多，因此它的组件、运维模式和发布模式都相对偏传统，而且很难掉头，因为它的集群体量很大，且比较核心，很难像在线应用一般通过扩缩容的方式重建。所以我们就像要给一架运行中的飞机换零件一样，需要一点一点去做。
刚才童老师提出来的谨慎非常重要，就是工具先行，可以先完成日志收集、监控、演练、灾难恢复等部分的工作，在一些小的集群上先积累充分的经验，才能去动最核心的大集群，不能一步到位、一蹴而就。好的架构是演进出来的，并不是通过牛逼的架构师一开始就能够定出来的，所以对于团队而言也是一个不断学习和总结的过程。
核心的思路就是先把日志和监控两方面做好，那么我们就有了一个眼睛，然后通过灾备技术，我们有了救命的稻草，或者说救火的工具，确保出现问题时我们能够应对。有了这两个利器之后，我们开始设计部署的架构、发布的方案，选择应用使用本地存储还是网络存储，如何设计应用之间的调用关系，以及改造的先后顺序，这是涉及到发布流程和部署架构的工作。
我们也是选择先去动一些工具类的，比如把一些管理工具容器化部署进行云原生发布，以此积累一些经验。我们也定制出了大数据平台的容器基础镜像，以及镜像的发布和管理流程，使多个团队或多个研发同学之间能够得到一些经验和知识的共享。在大家都具备一定的实操经验之后，我们再分头改造自己的应用，最终实现整体的云原生化。
整体的改造完成需要长期的时间，目前我们也是在推进的过程中，但它带来的收益还是挺可观的。可能目前从成本角度看没有太直接的收益，但是云原生的理念能够令一个应用owner更好地管控自己的应用，提升应用的可伸缩能力、弹性能力和可运维性，因此长期收益是可以看到的。随着越来越多的应用通过云原生方式进行管理，我们可以在不远的将来看到发布效率和稳定性的提升，以及新的架构理念能够更快地在平台上落地，从而得到更好的收益。
Q5
将大数据系统从传统生态架构迁移到云原生架构会面临哪些挑战？大数据平台做云原生改造的技术难点是什么？
童光辉
我觉得最大的挑战是有状态服务上云，因为k8s在最开始设计的时候解决的是无状态服务云化的问题。故障处理主要是通过pod迁移来解决，但是大数据的情况不一样。大数据各系统都带数据状态，不管在传输还是在存储，甚至在计算过程中，要么是永久性的存储数据，要么是缓存数据，因此处理带状态服务上云是一个非常大的挑战。目前我们也只是把部分的组件，比如存算一体kafka上云或者impala存算分离上云，HDFS或者其他的组件未来是否要上云，这个问题其实我们内部还在讨论中，还在看如何实现我们收益的最大化。
第二个挑战是大数据在云原生过程中如何降本增效，在这个过程中我们要实现与DevOps、AIOps结合。举个例子，比如Hadoop DataNode或者NodeManager发布，在大规模集群、多个集群情况下，整个流程很耗时间，同时需要比较多人力投入，有时还会出现一些抖动或故障，我们在云原生升级中，需要把这里的质量、效率做好治理改造，甚至更近一步，CI、CD、CO、CE，把它们串联起来实现较好的自动化、智能化。
以我们团队为例，比如实时计算Flink场景，我们构建了混沌工程环境，可以做到用户编写Flink相关的代码，执行流程完成之后，我们会在一个真实流量的镜像环境里做到相关的发布，然后执行混沌工程的爆破，最后完成整个版本的定版，定版之后即可做适当的灰度。Release版本出来之后，我们开始执行全量版本发布，同时在发布过程中，结合指标监控、日志监控，有问题及时熔断。
大数据上云我们怎么巧妙规避或缓解有状态服务的管理，另一方面是在这个过程中，如何结合DevOps、AIOps实现整个研发运维体系的升级。
Q6
云原生体系和原来的大数据体系之间存在架构上的冲突应该如何解决？上云一定要改变大数据自身的架构吗？
周昕毅
云原生体系和原有大数据体系存在架构上的冲突，要看怎么理解这个冲突，因为云原生体系本身只是一个推荐的最佳实践，它并没有明确的步骤和计划，可能有推荐的落地场景，也有一些不容易计划的可以往云原生方向去靠，那么体系冲突可能更多是一个已经存在的架构如何做迁移的问题。
这个还是要看风险和收益，如果原有的体系比较成熟，要去做一些容器化改造，那么侵入性比较大的可以先放一放，可以考虑从一些新上线的工具和功能，以及新上线的系统先做一些云原生的尝试。如果确实整个交付速度、运维效率有所提升，看到收益之后再尝试解决之前现有体系的改造问题。
因为大数据体系是一个非常经典的分布式架构，它的理念一直是比较先进的，只是没有很早落地不可变基础设施等概念，但是它本身分布式的稳定性、代码质量和可运维性都比较高，所以冲突其实并不多，即使有也可以通过一些慢慢的迭代解决。
上云是否一定要改变大数据架构，这个要看原来是一个什么样的架构，如果原来是私有云，上云也可以用裸金属部署，不一定改变。回到刚才的话题，还是取决于你想解决效率还是成本的问题，如果这两个问题都能够解决，那么带着原有的自身架构去云上做部署是最好的，因为可能涉及到一些现有工具的对接。但是一般来说借着上云做架构的重构，也是一个很好的契机，如果没有上云这件事，你可能在现有的这套老系统里很难下定决心去做升级，因为需要带着业务去做升级，上云必然会带来一个搬迁的动作，借着搬迁再进行架构调整。一般都会选择稍微做一些调整，也不排除引用现有架构的案例。
Q7
上云的必要性大吗？
童光辉
我们从互联网的软硬件发展去看待这个问题。首先最开始我们做大数据时是以千兆网卡为主，k8s出来时大概是万兆网卡，这个时候我们做大数据上云会发现网络带宽不足的问题很严峻，所以当时虽然在做在、离线混部，但是我们也相对比较谨慎，优先调度重计算型去在、离线混部的环境，但重IO作业，因为带宽消耗过大，就需要很谨慎去做调度。最近我们的网络发展迅速，云上进入到25G、100G网络的时代，专线，同城的不同机房间的带宽成本也在快速降低，所以网络发展到现在已经不在是主要问题。
同时云厂商开始大规模地采购服务器，开始投入芯片，而且是做专用芯片，比如压缩、解压芯片、视频解码芯片等，那么我们会发现在云上，硬件成本比自购更划算。
因此，我觉得中小型企业未来一定要上云，因为不上云人力和机器会更贵。大中型企业由于人才储备、技术储备以及体量够大可以选择用云厂商或者自建私有云、混合云，上云之后再结合云存算分离的架构，在人效和成本上可能目前还做不到方方面面的领先，但我相信2～3年之后应该可以全面领先现在的裸金属架构，所以大数据上云是一个不可逆的技术发展趋势。
Q8
大数据上云的步骤是怎样的？主要会经历哪几个阶段？各个阶段具体该如何进行规划？
周昕毅
我这边会从以下角度做一些规划：
首先是需求明确的阶段，也就是前面反复提到的要明确你要解决什么问题。
第二步是进行选型，选型包括技术方案选型和云厂商的选型。用公有云还是私有云，选择哪个云厂商更合适，要根据自己实际情况而定。技术选型比如是直接购买产品，还是自己买IaaS服务进行搭建，这也是需要根据规模和体量，以及人力的投入进行决定。
第三步需要考虑实时性和稳定性要求。实时性要求高，可能选择的机型或架构不太一样。稳定性要求则是平台要提供一个什么样的SLA，那么也会涉及到整个方案应该怎么做，比如是否涉及迁移，业务是否接受停服务，或者数据延迟能够维持多久，这些都要提前明确，否则整个搭建好之后，发现设计没有达到之前的预期，或者成本过高超过了用户的预期，都会出现问题。
第四步则是应急预案，前面提到了稳定性和SLA承诺，那么我们针对承诺如何通过一些预案做响应，包括如果选择公有云厂商，我要考虑数据跨AD的高可用，还是就在单AD，它们的SLA其实是不同的。
Q9
有没有传统大数据平台与云原生大数据平台的对比案例，可以详细介绍一下吗？
童光辉
我在腾讯内，内部使用还是混合云的模式，对外部客户是以云原生为底座的大数据平台，在基础组件hadoop、kafka等可能有所区别，但在数仓开发工具、BI工具等产品上是内外一套代码，以插件方式适配不同环境，传统的大数据平台要交付大数据平台，会涉及到很多个团队和人力，最后耗费较多时间去落地它的整个体系，云原生的数据平台在小时级就可以交付出整套大数据的数仓体系环境，在效率上会有质的提升。
我们前面花了很多时间从成本优化和效益提升两方面探讨大数据上云的必要性，这其实要根据企业的规模和场景进行选择，所以说传统大数据/云原生大数据主要还是要看需求场景，所谓的传统大数据/云原生大数据如果一定要界定我们的不同，主要是本身研发、运维模式的不同，在大数据工具平台、BI产品这一层从用户角度看没有什么区别的。
Q10
通过存储计算分离实现计算弹性伸缩是在云上构建数据平台的重要特性之一，存算分离是否会成为大数据的主流架构？
周昕毅
存算分离的架构才具有弹性升缩的空间，存算一体的架构可以降低网络IO的消耗，但随着硬件基础设施的不断增强，网卡从1GB到10GB，25GB，再升级到100GB，对存算分离的架构已经非常友好。大数据领域也有很多高效的压缩算法，以及优化过的存储格式的不断演进，这两者让IO慢慢不再是一个瓶颈，那么压力来到了CPU这边，但是CPU其实是比较好做弹性的。在刚才提到的这两个背景下，存算分离的架构具有比较明显的优势。
Q11
大数据上云未来的发展趋势是什么？贵司未来在大数据上云方面有哪些规划？
周昕毅
关于我们团队的规划，首先在应用架构上，我们会遵循云原生的哲学去指引我们的架构设计。不管是使用公有云还是私有云，我们的整个架构会往云原生方向去靠，这是毋庸置疑的。至于使用公有云还是私有云，则更多是在追求效率和成本平衡过程中的一个选择。
童光辉
结合架构的发展，大数据云原生往下走有两个方面：
一方面我们要完全统一司内、云上的大数据技术、运维底座，并结合CI、CD、CO、CE打通DevOps的能力，总结下就是统一代码、统一运维，云化过程中落地研、运的治理提升效率和质量。
二是我们会更加坚定不移地把存算分离的能力，在离线混部能力做得更好，在保障SLA的基础上把在线空置、碎片的资源利用得更好降低计算成本。
大数据上云只是大数据发展的基建部分，也简单说下PCG数据中台这边的情况和规划，我们有三个数据域：
第一个数据域我们称为资产区，也就是从数据的埋点到上报，再到存储、计算、查询所有的过程，都是有血缘的、规范的、被监测的，数据质量问题可以被快速发现、自动修复，数据价值有初步的评估并持续做好数据治理。
第二个数据域是我们的安全区，整个联调都在在隔离的环境，原始数据不可不读取和出域，通过隐私计算进行加工出结果数据，安全区本身也是资产区。
第三个数据域是我们的原始数据区，是未经过彻底治理的，有结构化的表，也有非结构化的模型等数据，我们会逐步将这一部分变得越来越小，通过数据治理把这部分变为数据资产，这也是我们团队目前投入很多人力和物力在做的一件事情。
再往上我们会做整个数据产品的套件，类似于国外的一站式数据产品，数据只需要定义好埋点，相关的BI即可出来，不懂技术的人也能够做好数据使用。
特别鸣谢
关于我们
dbaplus社群是围绕Database、BigData、AIOps的企业级专业社群。资深大咖、技术干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙，每季度Gdevops&DAMS行业大会。
关注公众号【dbaplus社群】，获取更多原创技术文章和精选工具下载
,
