我们遇到什么场景的时候可以考虑上云，其实也不局限于大数据的工具，可能上云的其他在线应用也有类似的情况。

第一个方向是快速尝试最新技术栈。云厂商在各技术领域都会适时推出新技术栈的SAAS服务，可以让企业快速上手，降低适用门槛。

第二个方向是云厂商的高性能硬件。例如新型号GPU、新一代CPU、高性能SSD硬盘、百GB网卡等高性能硬件，在AI/BI领域可以发挥极大作用。

第三个方向是弹性需求。大数据平台的写入需求和查询需求往往在一天内有明显的波峰波谷，通过云的弹性能力可以尝试进行计算资源的自动扩缩容，对数据存储进行冷热分离。

最后一个方向是高性价比的S3对象存储服务，这也是携程用的感触比较深的方向。主流云厂商都会提供兼容S3协议的Object Storage Service，适用场景众多，成本低廉，天然支持存算分离的应用架构。如果对于对象存储有需求，但是又缺乏部件，这也是一个不错的切入点。

上云听着很美好，且是技术正确的一个选择。但我觉得需要回归到本质——我们想要什么，即企业的痛点是什么？到底是想解决人的问题，还是想解决购买资源的钱的问题。

我觉得在中小型企业可能优先考虑解决人效的问题，其实要做整个大数据上云，上云只是冰山上的东西，冰山下的服务器、带宽、基建等一切东西，需要一个完整的支撑团队去思考和解决，一般的小企业难以负担这个成本。所以我觉得中小型企业尽量考虑用各种比较成熟的云上组件，实现从自己小的私有云放到了云上的公有云，可能在资源上会略贵，但是人力成本和质量保障方面会更好。

对于中大型企业来说，可能既要解决人的问题，又要解决钱的问题。如果企业资源利用率特别高，且没有能够做得更高的手段，那么上云需要慎重考虑。如果企业资源利用率还有很多提升空间，那么需要考虑是不是在上云过程中可以解决。因为如果从省钱的角度，把服务器压榨到极致，同时团队有足够的人力和资源，可以考虑从供应链的角度出发，在服务器采购、机房选择、带宽的支撑能力上，需要做哪些能力才能把云上的服务器、应用程序利用率做到极致，最后为企业节省成本，同时借助上云过程各方面的改造，实现人效的优化。

其实我觉得上云本身是一个企业IT治理的过程，它不仅仅是把一个东西放到k8s就完成了的事情。既然是IT治理，那么其实是一个非常体系的思考，里面也有非常多的问题点，所以上云之前一定要思考清楚，我甚至了解到部分团队上云之后发现成本更高了。所以企业需要注意：不要为了上云而上云，而是需要明白自身到底想从上云过程中得到什么。

以我们的MQ为例，上云之后我们做的第一件事情就是把我们整个现有服务器的选型，包括上面的应用场景，以及后面我们设定的利用率提升目标提前规划好。

其次结合我们的整体架构能力、对质量上的需求，以及最终和k8s相关的调度方面的配合，也要做好规范，满足上云最基础的设计。

存算一体上云有一个很重要的地方，我们要适当降低它的迁移动作，那么Pod的规格设计要结合机型去做，在保障装箱率的情况下尽可能降低一些迁移导致的数据搬迁的频次。而且因为大数据我们的流量会比在线高很多，所以需要考虑清楚容器网络模式和机房带宽。

在实现上云的路径上，也要考虑到整个运维支撑能力的建设，因为在传统机器，如裸金属或IDC机器上的运维，服务器投放、机器初始化等和云上面还是会有所不同。此外，在Pod销毁或k8s遇到各种各样的故障时，我们的SOP、自动化工具也要提前做好准备。

最后就是要做好各方面的风险评估，并且做好演习，再谨慎地操作上云的节奏，以免出现比较大的问题。比如机器上可能磁盘满了某些自动运维工具会做一些日志数据删除，kafka数据落盘结尾就是.log的，被误删就会造成数据的丢失。

大数据上云过程里还会有很多细节性的问题，这里不一一列举了。总结起来就是：首先要做好整个架构评估和质量保障的风险评估，然后做相应的架构设计，工具的建设一定要先行，再逐步上云，而不是盲目追求速度，否则遇到重大的质量问题时可能会比较被动。

大数据平台其实是一个非常典型的有状态应用，而且是一个比较有历史的应用，比云原生的概念提出早很多，因此它的组件、运维模式和发布模式都相对偏传统，而且很难掉头，因为它的集群体量很大，且比较核心，很难像在线应用一般通过扩缩容的方式重建。所以我们就像要给一架运行中的飞机换零件一样，需要一点一点去做。

刚才童老师提出来的谨慎非常重要，就是工具先行，可以先完成日志收集、监控、演练、灾难恢复等部分的工作，在一些小的集群上先积累充分的经验，才能去动最核心的大集群，不能一步到位、一蹴而就。好的架构是演进出来的，并不是通过牛逼的架构师一开始就能够定出来的，所以对于团队而言也是一个不断学习和总结的过程。

核心的思路就是先把日志和监控两方面做好，那么我们就有了一个眼睛，然后通过灾备技术，我们有了救命的稻草，或者说救火的工具，确保出现问题时我们能够应对。有了这两个利器之后，我们开始设计部署的架构、发布的方案，选择应用使用本地存储还是网络存储，如何设计应用之间的调用关系，以及改造的先后顺序，这是涉及到发布流程和部署架构的工作。

我们也是选择先去动一些工具类的，比如把一些管理工具容器化部署进行云原生发布，以此积累一些经验。我们也定制出了大数据平台的容器基础镜像，以及镜像的发布和管理流程，使多个团队或多个研发同学之间能够得到一些经验和知识的共享。在大家都具备一定的实操经验之后，我们再分头改造自己的应用，最终实现整体的云原生化。

整体的改造完成需要长期的时间，目前我们也是在推进的过程中，但它带来的收益还是挺可观的。可能目前从成本角度看没有太直接的收益，但是云原生的理念能够令一个应用owner更好地管控自己的应用，提升应用的可伸缩能力、弹性能力和可运维性，因此长期收益是可以看到的。随着越来越多的应用通过云原生方式进行管理，我们可以在不远的将来看到发布效率和稳定性的提升，以及新的架构理念能够更快地在平台上落地，从而得到更好的收益。

大数据上云我们怎么巧妙规避或缓解有状态服务的管理，另一方面是在这个过程中，如何结合DevOps、AIOps实现整个研发运维体系的升级。

云原生体系和原有大数据体系存在架构上的冲突，要看怎么理解这个冲突，因为云原生体系本身只是一个推荐的最佳实践，它并没有明确的步骤和计划，可能有推荐的落地场景，也有一些不容易计划的可以往云原生方向去靠，那么体系冲突可能更多是一个已经存在的架构如何做迁移的问题。

这个还是要看风险和收益，如果原有的体系比较成熟，要去做一些容器化改造，那么侵入性比较大的可以先放一放，可以考虑从一些新上线的工具和功能，以及新上线的系统先做一些云原生的尝试。如果确实整个交付速度、运维效率有所提升，看到收益之后再尝试解决之前现有体系的改造问题。

因为大数据体系是一个非常经典的分布式架构，它的理念一直是比较先进的，只是没有很早落地不可变基础设施等概念，但是它本身分布式的稳定性、代码质量和可运维性都比较高，所以冲突其实并不多，即使有也可以通过一些慢慢的迭代解决。

上云是否一定要改变大数据架构，这个要看原来是一个什么样的架构，如果原来是私有云，上云也可以用裸金属部署，不一定改变。回到刚才的话题，还是取决于你想解决效率还是成本的问题，如果这两个问题都能够解决，那么带着原有的自身架构去云上做部署是最好的，因为可能涉及到一些现有工具的对接。但是一般来说借着上云做架构的重构，也是一个很好的契机，如果没有上云这件事，你可能在现有的这套老系统里很难下定决心去做升级，因为需要带着业务去做升级，上云必然会带来一个搬迁的动作，借着搬迁再进行架构调整。一般都会选择稍微做一些调整，也不排除引用现有架构的案例。

我们从互联网的软硬件发展去看待这个问题。首先最开始我们做大数据时是以千兆网卡为主，k8s出来时大概是万兆网卡，这个时候我们做大数据上云会发现网络带宽不足的问题很严峻，所以当时虽然在做在、离线混部，但是我们也相对比较谨慎，优先调度重计算型去在、离线混部的环境，但重IO作业，因为带宽消耗过大，就需要很谨慎去做调度。最近我们的网络发展迅速，云上进入到25G、100G网络的时代，专线，同城的不同机房间的带宽成本也在快速降低，所以网络发展到现在已经不在是主要问题。

同时云厂商开始大规模地采购服务器，开始投入芯片，而且是做专用芯片，比如压缩、解压芯片、视频解码芯片等，那么我们会发现在云上，硬件成本比自购更划算。

因此，我觉得中小型企业未来一定要上云，因为不上云人力和机器会更贵。大中型企业由于人才储备、技术储备以及体量够大可以选择用云厂商或者自建私有云、混合云，上云之后再结合云存算分离的架构，在人效和成本上可能目前还做不到方方面面的领先，但我相信2～3年之后应该可以全面领先现在的裸金属架构，所以大数据上云是一个不可逆的技术发展趋势。