2017 CIOC全国CIO大会7月20日在青海·西宁盛大举办，来自全国的300余位CIO共聚一堂，最接地气的观点、最实用的实战经验、最前沿的技术、最新的产品在此汇聚，碰撞出属于CIO的精彩火花。

以下为现场速记。

主持人：感谢唐总的分享!公有云的故事大家听了不少，但是哪些应用适合上云，哪些不适合呢?上云后发现不适合迁移又会怎么样呢?具有哪些坑呢?可能绝大部分的CIO还是不太了解，我们今天请到一位先行者--易观CIO(原万达电商大数据总经理)郭炜先生，给我们分享《大数据应用云迁移之战》，大家掌声有请!

易观CTO (原万达电商大数据总经理) 郭炜

郭炜：我以前在万达工作，各位今天在万达登录酒店WIFI的时候，我还很熟悉，因为对接的时候是我在做的。后来在联想做了大数据总监，负责联想全球的大数据平台，现在加盟了易观，负责易观相关技术产品的工作。

为什么我们要做云迁移?首先说明一个观点，我是强烈的云的支持者，但是我今天跟大家讲的是，在座的CIO一定不要为了云而云，所有的云的背后都是需要业务需求驱动来做的。我举易观的例子，其实易观是一个在技术上非常激进的公司。在我加盟易观之前，易观所有的业务已经是全部云化的，而且是公有云化的。在中间随着我们的业务发展，我们当时上公有云的时候，也上了公有云各种各样的雷河、各种各样的坑，后来我们才从公有云迁移到混合云。

如果真的要做公有云，在座的CIO一定要想这样的几个问题，一路走来，这几个问题是需要大家考虑的。第一，你的业务是稳定的还是变化的。其实如果你的业务是比较稳定的，不是突增或者突涨或者业务规模不够大的时候，其实你可以先不用云化。这里我举一个业内经常用的例子，现在用云化最多的公司是游戏公司，为什么呢?因为他是和他的业务紧密相关的，大家知道一个游戏火爆起来以后，可能瞬间几天或者几周的注册量一下子就上去了，如果用传统业务支持的方法是没法支持这样的业务规模的。如果一个游戏没有做好，可能几周之内就没有人玩了，变化峰值是非常快速和剧烈的，所以游戏公司用云是最适合的。但是同样可能对于我们来讲，有一些比较传统的业务，可能业务量差不多，一定要强烈云化吗?我个人觉得不一样，要看业务规模的情况。

第二，企业的硬件规模以及核心业务，我们的核心业务是否真的要云化，中小型企业刚开始的时候可以不做运作。

第三，云的性能和服务器的性能，这一点是我们在数据量级达到右下角的数据量级的时候遇到的一个坑。我们的数据在云端一开始跑得挺好的，随着数据量的增加，开销逐渐增多，公有云无法满足我们的性能，于是我们被迫从公有云上面迁移到混合云。

第四，人员的储备和管理。从这一点来讲，如果一个公司刚刚起步，还是小型企业的时候，其实大家可以考虑用公有云外包自己的一些云的服务，减轻自己人员的增加。如果从小型企业到中型企业的时候，这是一个十字路口，一方面要重新评估前面三个问题，我们究竟要做公有云还是要做混合云，这个是每个CIO自己要面临决策的问题。如果要做公有云，可能后续我们的人员不会增加那么多，但是外面CTO的成本会更多一些。大家要算一笔账，如果要做混合云的时候，我们要看自己的混合云是否适合自己的业务，这是我们为什么一开始从公有云迁移到混合云的背景。

从业务背景上来看，我们现在整个的数据量是非常大，这些数据来自于大家自己手中使用的手机，大家看到手机会使用各种各样的APP，但是APP背后有一个东西叫SDK。我的SDK会嵌在各种各样的APP背后，采集大家打开和关闭的信息，这样的数据是非常庞大的。目前我大概每天的数据接近242亿条，每天大概有5千万的活跃用户在我的大数据平台上面，每个月会有4.4个亿的用户都会把他的数据传到我的大数据平台上面。所以我们遇到了一个很大的问题，就是原来的公有云的处理方式和并发效果没有办法处理我当前的情况。这就是我为什么要做一个云迁移的动作。怎么做云迁移呢?我后面给大家详细的说一下云迁移怎么干。

首先我们的数据量是非常大的，大家知道每次做云上的迁移，对于系统的产品和稳定性来讲，对于整个技术和产品团队都是非常大的挑战。有几个比较难的难点，第一是数据量大，日数据有10个T，历史数据是BP的级别，每天光有数据量就是200多亿条的数据，我必须要平滑的做迁移。第二是采集并发接口并发程度高，因为每天数据在不停的上传下来，还有很多数据的流式计算，我要保证实时性。第三是我们的系统架构要大改，原来的公有云是依赖组件，我们现在要做混合云的时候，线下的组件使我们自己做的，数据模型也会发生变化。其实我遇到最难的是最后一点，系统要并行，因为大家知道如果要保证一个业务的稳定运转，它不可能先把前面的业务停两天，我做两天的割接，这是不可能的。我们必须要同时在运行，运行完之后再做相关的割接。这是我们做云迁移的时候遇到的比较大的挑战。

这是早期的数据架构，如果是中小型企业也可以参考这个架构，最开始可能只有一两个人、两三个人做大数据的平台，这样的架构所有的结构都是在公有云上面的。我们采用了Facebook开源的查询数据库，好处是可以把这些做一个非常快的关联，对于中小企业来讲，一开始这样的架构是非常适合的，因为开发成本比较低，人员比较好招。这是最早的大数据架构。

为什么要用混合云?一开始公有云的时候，我们遇到最大的瓶颈就在于我们的数据量大了以后，公有云的IO性能没有办法非常好的保证，同样的东西在计算的时候，可能第一天是4小时，第二天就变成6小时或者8小时，这些问题都给我们的系统稳定性带来问题。对于混合云来讲，我们有这样几个考量会用到混合云。第一是混合云的弹性扩展，首先我用了公有云接收大数据，每天有200多亿条的大数据在上传，而且我们接入合作伙伴，就是APP，可能一个APP就是非常大的APP。一旦接入，可能我一天的数据又增了几十亿。如果我用传统过去的方法再买机器或者扩带宽，我是很难满足业务部门的需求的。每隔几个月或者一个月都有一个合作伙伴接进来，我们要弹性扩展接收数据，我们接收的性能是非常好的。

第二是安全防控也不用我太去操心，同时我们的产品端也在公有云上，就是最上面这一端。大家看到所有的互联网产品、APP、网站都是通过公有云做的，好处是在于我的产品线增加的时候，我不用很快的还要申请一批机器，如果生产线败了，我不要做各种迁移，直接从公有云把相关业务线关掉就可以了。同时它的安全性也是有所保障的，比如说最近我知道5、6月份有一批黑产在做各种各样的攻击，我相信各位都遇到了。如果我用公有云的方法，我就不用太大费周章的迁移。对于我来讲，我可以用公有云的产品上的安全接收端的弹性，这就是公有云。

对于私有云来讲，我们的大数据平台是在线下自己的传统机房实体机来做，有几个好处，第一是性能比较好，不用跟别人分享相关的IO。第二技术迭代也比较迅速，现在数据量大以后，我们很多开源组件的更新速度远高于现在市面上用的公有云的更新速度，我要很快的做相关的更新。第三是投入TCO可控，像我刚才讲到的，我每年数据的增量是有预期的，不一定是要弹性的，是逐步递增的过程。如果按三年或五年折旧，其实TCO还是比我购买公有云的服务的TCO更加划算。对于这种比较稳定的服务器的投入成本，我就会用混合云的实体服务器来替代原来纯云的服务器。刚才说的结构，其实也验证了一年多，整个架构还是非常稳定的。

接着说为什么要做混合云，其实混合云的时候，真的说要做混合云也挺复杂的。当时我们在做混合云的时候，还没有现在这么多人有混合云的解决方案，我们当时是自己组造了一套混合云。我们跟最大的两家公有云厂商进行对接，我们有一个SDK机房，找到一个供应商，把大数据通过公有云连接到这两个供应厂商里面。我们通过数据的同步，把每天大概十几个T、几亿条数据，通过光纤的方式打到集群上面，再打到BCloud做公有云的服务。

刚才提到那是原来的一个大数据的结构，其实我们的目标大数据结构是这样的。整个的大数据集群是中间这一块，产品展现是上面这一块，大数据接收也是在公有云上面。最底下就是大家使用的手机，无论是安卓手机、还是IOS手机、还是微信的小程序，都有一些SDK嵌入到里面，存到公有云上面。这些是我们的流转平台，包括分布式的队列组件、实时队列。再往上有几块，一个是分布式存储查询平台，这个平台的结构还是推荐给大家，用起来比较方便，也是开源的。再往下是相关的一些分布式的查询平台，包括订阅，右边是实时计算的一些东西。对于元数据的管理，数据口径的管理、数据检测、数据调度资源，中间这些所有的平台都是在线下我们的SDK机房里面做相关处理的，再往上两部分全都是在公有云上做的。

刚才说了几个难点，第一个难点我们的数据量很大，怎么办?我们现在采用的方式，其实当时在呵迁移的时候，第一不是同步所有数据，因为你会发现，同步所有数据的成本和时间远远超过把这些数据拿过来重新计算一遍的时间，我们只迁移原有的数据，其它数据是同步以后重新计算一遍，迁移原始数据压缩做同步。第二是数据大改，难点是并发比较高，因为这么高的并发，两边数据还要同时进行，这个事不好做。第二个难点是无法切换，这么高的并发，两边同时并行在走，也比较困难。

为什么用NGINX不行?第一，因为这么多数据，你拷贝一份是非常难的。同时你的数据丢了，你也没办法验证这个数据到底丢还是没有丢，因为你根本不知道原来的数据是怎样的。第二，我们通过互联网做小包转发，但是效率非常低，几乎没有什么好的办法能够让数据拷贝出来两份，会丢数据。这是我们当时在验证的一些坑。后来怎么办呢?没办法，我们开发了一套程序，我们把两个队列之间做了一个程序，叫做“四分卫”的程序，小包打包成一个大的文件，传到我们的机房，再按顺序做核查，最后再把数据导出来。最后我也把这个东西开源出来了，主要是用于大数据互联网级别的传输，如果大家感兴趣或者遇到这个场景的，可以到这里面下载我们的程序用就行了。

做完这件事还发现有新的挑战，当我们的数据量级已经到百亿级以上的时候，我们觉得过去数据接收的量变到质变，它是否及时处理这个事无关紧要。但是如果你的数据量级到达百亿级以上的时候，你会发现它越来越接近并发的交易系统。为什么呢?这个我用了右边这个图，这个图可能很多CIO知道，这个图是去年美国在被病毒攻击导致东部的很多互联网全部断掉的一个图。这个图代表什么呢?如果我们把像百亿级别的数据很好的做出来，你很有可能会把自己公司的数据形成一个大的病毒，让你自己公司无论是公有云还是私有云都没有办法处理。

当这个数据处理不好的时候，我们使用互联网的带宽会从1到2个GB变成10个GB以上，量级到了10GB以上，基本上跟病毒没有什么区别了。这个时候，我们就要很快的处理相关的数据。我们对于大的数据流的东西，要疏导大于处理，当出现这种问题的时候，你处理是处理不完的，只是怎么去疏导它。关键两个技术比较重要的地方，第一是要良性可扩展的网络架构，第二是云+端的控制策略。我们通过混合云和多机房的方式把这个做起来，可以用公有云的方式解决网络架构的问题。

第二个问题，云+端的控制，所有的数据采集和处理都要有这样的几层，一个是交互层，比如我今天早上看到钢厂采集自己的传感器数据的时候，这是有交付的。存在本地有一个小的数据库，是嵌入式的数据库。同时还有策略层、网络层、协议层。云端策略就是你上传的时间，如果你上传不了，你还要有清洗的策略、分流的策略，比如直接让我每天几千万的设备分散在比如200到400个不同域名，或者发现某一些设备出现问题的时候，我直接下一个指令，不上传数据，保证云端的处理性能和处理速度。设备端就是IOT或者APP端，我们也有一些策略，如果A网站传上去了，我们换下一个域名，我的数据就不传了。更新策略是多长时间和云端通一次信，包括保活策略，就是活多长时间。我们整个云+端的策略设计来看，我们现在能看到数据端从秒到6个小时，你都可以去传，告诉他说我什么时间多长的频次把你的数据传送上来，跟你的业务相关的东西保证不丢失，同时也能让你处理得过来。

持续挑战又来了，第二个挑战，在做大数据的时候，我发现一个问题，大家都在想大数据可能会在哪个地方出现技术问题。很多人过去都想，可能是并行的数据计算或者数据的实时计算会出问题，反而在我们真正实践问题当中不是的，最终出现的问题是用户画像，我现在要基于用户画像看到他的行为明细是什么。比如说举个例子，我就想看到今天在青海早上9点到10点之间，我们在万达酒店区域这些人最高频使用的APP前10是什么，这样的问题挺难回答的，因为他带了很多标签，通过标签找行为明细，如果用传统数据库的方式是没法做的。我现在又四千多个标签，5.4个亿的装机量，APP58万个，这样你会一下子发现上亿级的数据，查询不过来。我们最终的解决方案是两部分，第一个是用开源的方法，第二是用抽样的方式，只要看最后的结果，我们大概抽样10%多的用户，最后发现准确率能达到90%多，通过这个方式来做。

后面还有更复杂的挑战，前面是无序的查询，后面还有有序的查询，我们也会遇到各种各样的挑战，大家要让自己的团队不断深耕。而且每个地方你还会遇到各种各样的挑战，比如说我们要在数据的传输端做事件防火墙技术、云端互动旋钮技术、预计算技术，这些技术不是我们自己想出来的，而是业务走到这里，是业务驱动技术做出来的东西。回到刚才的整个架构，这是目前易观的大数据平台的组件架构，我想也可以和各位CIO分享，这个结构在每个公司里面还是一个比较通用的结构。如果对大数据比较感兴趣或者跟数据相关的感兴趣的，也可以随时在现场跟我沟通。我刚才说的整个大数据平台，现在存了18个亿的手机终端数量，每个月大概有4.4亿的活跃用户，就是这个大数据平台来支撑我们当前的数据的一些查询和进展的。

简单总结一下。整个大数据迁移分了几部分，第一是基础建设，想要做混合云的建设、混合云的验证，要同步历史原来的数据，通过MR研发与追数，要开发程序去追溯，追溯以后要做相关的比较和校准。之后要试运行，同时运行完以后是无缝切换的，只是改了一个IP，用户是没有体验的，中间有很多数据治理的工作，其实这些都是每个企业在迁移过程中做的东西。

今天主要分享的就是这些，非常感谢各位!