1、为什么用混合云?

目前大数据的高并发、高运维，特别跟大数据相关的应用，我们在各种国内公有云都试了一圈。易观的数据量非常大，来自于我们现在手机端各种APP，嵌入易观的SDK，设备数覆盖了7.5亿的设备月活1.5个亿，现在日活基本上过千万了。这些数据实时上传到云端。上传到云端的时候有一部分要做实时计算，有一部分做批量计算。

现在虽然不是QPS，我们其实是收数，平均现在80万次每秒。如果峰值达到100万次每秒，你会发现这个数据量非常大。我们在国内各种公有云上面，迁移来迁移去迁移了一圈。

最后没有办法，我们发现在现在这个阶段，在国内整个环境里面，在做大数据的高性能、高并发、高IO计算的时候，我们用的混合云是唯一一个比较好的出路。

一方面用了底下大数据平台，另一方面跟公有云打通，享受到公有云对我们的免维护，可以很快的延伸，加上相关的产品的好处。所以我们最终用混合云的架构处理大数据。

2、混合云大数据迁移几个难点：

这个时候面临一个问题，怎么做数据迁移。这里面有几个难点。我们现在设备数7.5亿了，月活1.5亿。过去易观做分析报告，现在易观的分析报告已经不用过去的抽样调查，而是加上了整个大数据易观SDK采集的数据。易观TOP500，移动排行榜都是基于SDK的数据算出来的，易观监管了66万款APP的情况，做出相关的分析报告，也是基于这些数据来做的。

第一，日处理已经超过10个T了，这些数据不停运转，怎么保证这两个东西不要断线了，不要影响整个生产环境的变迁。

第二，我们要做迁移，大数据迁移和普通的数据库迁移有什么不一样呢?因为过去数据库迁移，在一个机房里面表对表，或者旧系统对新系统，我们数据量几个T。过去的用户相关资料，是用户交易的东西。现在大数据迁移不一样了，历史的数据是PB级别的，把这个数据拿硬盘考出来是不太可能。怎么把这个PB级的数据做相关同步，从原来我们公有云上面迁到混合云上面，因为它不是一个IDC里边跨机器的迁移，它是跨互联网的迁移。准确地讲是从青岛某一个公有云迁到了北京某一个混合云的机房，跨互联网大数据的迁移过程。

第三，平均每秒钟70到100万次连接请求，如果两个系统做并行的话，怎么办?这个并发量这么大，怎么样让两个系统在做并行的时候，同时收到这些数据，而不是说在一个机房里面通过光纤连过去?通过异地互联网同时接收到大量数据的需求，当同样的需求数据最终达到生产环境的时候，公有云和混合云同时并行。但这样做挑战也非常大，因为它有非常大的请求量。

第四，数据流式计算，一些准数据的，流式计算在做相关统计的任务，不能在迁的时候断了。所以你得把它想象成平滑过渡的过程，把我们这个数据迁移做好。

第五，系统环境的改变，比如我们搭建了一套机器，线下集群用新的东西，原来在公有云应用端的WEB服务器没有变，底下大数据集群发生比较大的变化，同时它的模型也发生了一些变化。当这些数据混在一起的时候，对我们这个挑战就很大了。数据量超大，并发请求超大，业务并行难度很大，最终系统环境发生变化。

究竟怎么去迁，这个问题是我们一开始就要面临的很大的挑战。

3、早期的大数据架构：

这个架构其实是基于公有云，原来在公有云的一个架构，用Redis收数。我们在公有云原来用的presto，用到挺极致的水平。现在presto很好的特性是跨库查询，跨HDFS，最后形成一个存储链接。从云端下载相关查询的时候直接下到presto里面，分散到HDFS、MySQL里面做相关的查询工作。

最终就是Rabbit MQ，这里面会发现刚才提到性能的瓶颈，数据量大了以后，资源的隔离都会有一些问题。比如说，现在几个集群几十个结点，同时并行跑一个任务的时候，昨天跑的是40分钟，今天同样这个任务数据量差不多的时候，这个时间就无法预估了。

因为运行大批量高性能运算的时候，所有的这些都会放到CPU、磁盘上，会报警。这个时候对公有云来讲显得非常有挑战性，做一个公有云，易观只关注在公有云上面做，分析云这一块只做分析，底下这一块都不想做。

但是现在国内这一块还有点距离，没有办法变成了第二个架构，变成了混合云架构，放到Kafka里，这边把它放到DFS里，那一部分放在Spark。

在上面通过直联的方式，连到公有云上面，公有云就是我们所有的对外产品，大家看到的易观方舟，所有互联网产品都是基于这样的架构往上迁的，这是我们目标的一个结构。

4、目标大数据结构：

5、混合云大数据迁移方法：

第一，PB级的数据，因为要跨互联网的，我们采用方法是原始数据压缩同步。大家知道真正做大数据的时候分很多层，底层到中间的数据统一层，数据汇总层，数据的结果层，分好多层同步。

我们把原始的数据层，通过线下基层高性能的计算补这个数，往上追，通过互联网一点一点传。不论申请多大带宽都会非常大，互联网的带宽一会儿多一会儿少，这个东西传就会断掉了。这个数据通过压缩传原始文件，重新做计算。

第二，做数据验证。在不同层次里面设了一个指标，做了相关核心条数、DAU、MAU，设了100个指标核对每张表做的结果不一样，无论做大数据迁移还是小数据迁移，这件事儿都得这么干。

难点来了，怎么去把这个接口，在大并发情况下，做到并行收数，不是线下收数。我们新的集群收数或者原来公有云收数，需要拷贝一份同样大量数据转发给原来的公有云上面，同时还要发给线下新的集群下面。把这两件事儿同时并行接收，原来一份数据拷出一份做两件事儿。

我们那时候遇到巨大的考量，这么大量的数据并发，怎么把它复制出一份，给它分成两部分，同时两个系统并行的时候来接受，这是我们开始遇到挺大的难点。

5.1为什么说NIGIX不行?

在这里面可以开发一个服务，用它自己的代码，为什么不行呢?

我们的数据其实是百万次的请求，真正的数据请求比这个量还要大。每次APP传给我们数据的时候，都会回一条信息叫response。这个时候把本地缓存数据清空，如果没有返回response信息的话，一直把数据缓存在SDK里面。有response，才会清空缓存。回到这个问题来讲，NIGIX什么时候返回response，如果在这一层返回NIGIX，因为这并发量非常大，怎么确保同样的数据在这台NIGIX和这台NIGIX对大量并发请求，同时能拿到这样的数据呢?

如果拿不到会出现什么样的问题，这部分数据丢掉了。哪些数据保证我们原来混合云、公有云这两端数据一模一样呢?虽然它的转发效率很高，并行度很高，对于这个环境来来讲，没法满足我们的要求。

5.2 为什么Kafka不靠谱?

大家原来看到那个架构里边，我们把它升级变成Kafka。Kafka现在有一个工具叫mirror maker，运行大量数据的时候运转不起来。在我们的并发量上，大概十几分钟就报各种各样的错。后来请教别人，人家说得用Scala把头部和中部的原代码改一下，但是开发人员对Scala不太熟，所以不太可行。Kafka不能直接从这边把队列放上去，这是原因之一。哪怕我们用了这个，把这个代码重新改一遍。

为什么还不行呢?我们这些全都是小包两条线通过互联网传的，一个地方在青岛，一个地方在北京。大量传输的网络无法满足小包的转发请求。我们后来自己还真写了一个小的程序，利用Java多线程。同步的时候，要不这儿多，要不那儿多，而且这个积压情况，每百万次或者80万次的请求，不是说只是满足了五六十万次，它是十倍的差距。

因为网络带宽，这种大量的小包请求非常敏感。所以造成我们在这两边的时候，差距特别大，一边查，一边速度消费很快完了，一边积压三个小时的数据五个小时的数据还没有。每天的数据都增加，现在三个小时没有传过去，再过一天变成六个小时，怎么保证刚才说的流失计算和相关的同步，这件事儿也不靠谱。

当然也有人问，这个架构不好，干吗不单独设一个第三个地方接这个数据呢?现在就是直接通过接收端搞一个，最后我去做相关的Kafka的时候，从这边接收完了之后放下来，结果还是一样的。你会看到我的这个互联网传下来的时候，在里边积压了大量的数据，根本消费不完。一天过去以后，这儿数据都处理完了，这边积压了半天数据根本没刷下来，这么大量小包并发传的话一定有这个问题。

6、怎么办?

我们自己写了工具，我们叫做KICKER AA。我如果大家做跨互联网级别的或者类似做小包同步，基于Kafka同步的时候，可以用到我们相关的小工具，来感受感受我们用的目前的情况。后面讲一个架构，经过刚才说的大的请求也好，数据量非常多也好，通过的TB级，它基本上是一个非常稳定的架构。

6.1 KICKER AA架构介绍：

两边是两个Kafka的队列，一个是我们在原来公有云端，另一个是我们线下混合云端。中间有几个部件，把里面消费原来相关的数据形成一些文件。因为我们现在发现通过小包的传输，特别大量百万次的请求传输，无论通过NGIX还是通过Kafka也好，通过Java弄的小包也好，试了各种方法都不行。

所以我们干脆先落成文件，小的请求先压缩，压成一个中量型的文件，这样看到几个问题，你怎么样保证这个文件传输中间不丢，出现了什么问题。中间我们有一些若干的步骤来做，中间其实就有一个我们做同步的传输，传到这个文件的队列里面，然后发过去。

我们没有用大程序就可以转起来，各种各样并发的请求对Kafka的压力，对文件传输的压力，因为只要一个点有问题，整个队列全部出现问题，所以分了好几块。

6.1.1 CONSUMER 消费者：

用CONSUMER读Kafka的数据，把它写到文件里面，这里边主要对网络运营进行处理。所有通过互联网传输的大数据，最大的隐患就是互联网。有的时候从北京到青岛，我们购买的两边百兆，有时候10兆很难判断什么时间出现了什么问题，如果出现梗塞怎么办。

因为那边是Kafka，我们就停止，要不数据越积越多，我们数据量很快就爆满了，后面数据可能很快丢掉了，我们做了相应拥塞的处理。我们调了比较好的文件，500兆的文件，十分钟的时候能保证这个文件传下来，做了一个测试，如果有问题就稍微的停一停。

6.1.2 SYNCHRONIZE TRANSMISSION 同步模块：

File transfer就是做相关的传输，主要追加时间戳，如果消费端有问题，我们更新到临时文件里面，中间其实做一些简单的设置，传输的时候不是光传文件，因为传文件的时候不知道什么时候传完。我们加一些文件这样线下知道这件事情做完了，把数据再传到我们线下Kafka里面去。

6.1.3 FILEQUEUE 文件队列服务：

在线下文件队列，把刚才说的接收变成相关的数据文件，为消费者提供这样的东西，处理多个消费者的请求。因为消费的时候，我们肯定不能通过这么大数据的并发，我们想在十分钟到十五分钟，从原来的公有云在混合云传下来，进入消费状态，让整个数据流能转起来。这件得通过多个消费者来做，一起并行跑起来。

其实一开始也遇到了一些问题，我们刚开始的时候发现消费者数量控制多少。这个其实是挺重要的，如果多的话，文件服务器受不了，Kafka受不了，最后调了比较合适的数据量，把多个消费者做相关的消费，才把文件并发问题给搞定。

6.1.4 PRODUCER 消费者：

把我们的消费通过多个线程放到Kafka里面去，只要进了线下的Kafka了，我们认为这个事儿基本上没有太大问题了，包括文件的管理细节。传输的时候单个文件传输，不是并行文件传输。

我们强调带宽的问题、稳定性问题，但是每个文件传输速度非常快，只要下来以后两边的消费和生产，这两边全是并行，中间传输是文件传输，这样最终达到的效果。整个传输刚才说到的数量，10到15分钟，就完全可以同步到，从青岛一直到北京，可以把整个数据并行起来，转起来。

6.2 总结一下我们说的迁移步骤：

第一，大家先干，混合云搭建，为什么用混合云，刚才跟大家聊了一下，把基础建设先做下来，然后做验证，基础设施，不要转起来的时候出现一些问题。

第二，同步历史数据，只要同步原始的历史数据，这个时候其实背后就有一个开发工作，基于原始的历史数据，怎么生成原来的生产的数据。之前想用老的数据过来追，隔天追，这样肯定不行，PB级隔天追可能就死掉了，单独研发一套MR的数据，把原始的文件分发到汇总层、指标层等等这些数据都放上去，再做相关的数据比对，数据质量的比对这些工作。

第三，并行验证这一块，说到并行程序的研发，经过几经周转，通过Kafka也好，NGIX也好，Java相关程序也好，试了各种方案以后，发现简单的方法就是刚才说的这个情况，现在青岛和北京两个集群同时在转。

第四，我的产品其实在两边也都在展示，用我们产品经理、总监能够做到相关数据的核对比对，产品切换，数据两端大数据接收的时候，已经把它转发成备份出来一模一样的数据集群，对于新的产品集成来讲非常容易。和原来的数据一模一样，最终做切换的时候，大家只要把域名一改，这件事儿就搞定了。

第五，在这些风险的情况下，我们可以把我们的风险控制到最小，因为数据迁移当中经常遇到各种各样的问题，遇到各种各样的数据情况，我们怎么样在大数据的情况下做一些大数据的治理，把它做质量的优化，这是以后的话题。

7、大数据迁移成果——易观方舟：

因为易观过去都是在做分析报告检查，所以它把我们所有的移动客户端分析报告做了分析模型，做了易观方舟的东西，包括给移动开发者和相关的开发者提供大数据分析的云。

比如说，做运营分析，自己的月活、日活，做用户画像。应用评级也是让开发者来说，过去易观都是做各种分析报告，其中一部分变成了能够专门给开发者做分析的服务。

Q&A：

Q1：我简单问一下，我来自大卖网，原数据刚才列过了，现在是自动化的吗?因为数据量特别大，在做迁移的时候怎么去保证各层之间的关系?

A1：原数据刚才也提到了，它是易观SDK在源源不断的每个手机终端上面上传数据，所以我们原数据没有断的原因就是通过程序，原来只是一个接收点，复制出来一个接收点，变成并行的接收点，原数据怎么没有断其实通过程序，两边同时收了这样的一个数据在这里，而不是其中的一个点来收。

Q2：敏感数据或者说在传输过程中怎么控制它?

A2：其实原来SDK上传的时候我们加密打包，在转发的时候，原来那个包还没有解开，还是密钥的方式，原来在传数据时候，我接收完的数据还没有解开，从互联网怎么传到Kafka里面，从这个包传到Kafka集群里，解密的都是在Kafka以后，在上层做的解密，原来SDK传到云端接受器没有发生变化，原来小包在传，现在打成一个大文件，大文件里面还有小包的压缩，再传上来。

Q3：我是亚信数据的。如果是现在有一个企业里面有很多原始的数据，我想用易观分析云，我把我的数据放上来以后，因为我会担心数据是否能保密，怎么样保证这个数据不会传出去，因为你这个在公有云上。

A3：大家刚才也问到相关的问题，第一，我们刚才说的是混合云状态，所有的数据在线下是自己独立的物理集群;第二，现在我们目前对移动开发者的分析云的服务，企业这一级现在正在做，对于企业的敏感度怎么切分开，光从公有和私有云这件事儿，我的理解并不能够保证企业自己安全性的问题，无论公有云还是私有云，在里面究竟怎么保证企业的安全性，它还是有问题的，因为整个来讲还是公有云的，目前的一个方式逐步在做的是密钥的方式，这个事情目前还在做的，我们给APP开发者做相关的服务。特别像传统企业来讲，我觉得市场的接受程度还是会有一段距离，传统企业觉得针对公有云这件事情不是技术上的原因，而是他的理念和想法、市场接受程度有一个过程，这点还是需要等市场承受度再来做，我们面向移动互联网这个行业。

Q4：现在贵阳市也在做政府的数据开放，贵阳用的是底层IaaS平台是阿里云，政府还是担心阿里云毕竟是商业公司，我了解情况，之前还有专线接到杭州为了方便，后来把专线掐掉了。我们国家对于大数据的法律跟不上，马路非常拥堵，因为汽车发展太快了，我们也没有看到有一些公司在法律数据方面能够健全，政府也需要跟进的一方面内容。

A4：非常同意你的观点，因为对我们来说做大数据，大家都是做大的，原来老讲一个字叫“道”，这个时候说不清道不明，得道多助，失道寡助，过了这个道的线，发现将来很多合作伙伴都不会帮助你，我们那时候原来在其他地方，有公司卖数据，你看把手机号给你，家庭住址，买什么东西什么都有，再也没有给这个厂商合作过，过了这个线了，讲道这个事在大数据环节里一定是要坚持的。

Q5：您好，是中国人寿的，因为我们过去也做过类似的数据迁移或者数据库的转换，非常痛苦，因为像我们这种传统关系型数据库，即使数据中心下载下来传到北京，也是需要很长时间，非常理解您的痛苦。但是我也有一个问题，像您这么大的数据量，即使在带宽非常宽的情况下，您迁移的时间用了多长?

A5：整个项目是三个半月。

Q6：从青岛迁到北京?

A6：开展同步进行。

Q7：像这种情况，您当时怎么没有考虑，真的像最开始说的，直接把硬盘备份回来，坐飞机回来，这边装上都可以。

A7：数据同步这件事儿是其中的一步，因为我刚才提到，其实我们的数据格式也发生变化了，模型已经变化了，哪怕我把原来的那个PB级数据考过来，中间也就是100个T原始数据一样，再往上都不一样了。

Q8：我们的数据结构也变了?

A8：拿硬盘拷， 原来的数据在公有云上，公有云的硬盘是Openstack。

Q9：您的数据没办法备到某一台机器上。

A9：虽然有很多台机器，不知道这台机器其实存在哪个物理机，有可能分散在三个物理机上。

Q10：您那个工具，最终来讲应该通过数据文件传输的方式传到北京来的，我理解的是FTP也可以做这件事儿。

A10：我们也想过不靠谱， 协议可以FTP传，文件序列、中间的容错这些都不行，我忘了通过FTP还是通过什么传了，这块用哪个协议不重要，重要的在于咱们刚才的四层结构，协议其实我觉得无所谓。

Q11：我刚才看您技术架构里面有Spark里面，在您的技术架构里面起什么作用?

A11：因为做数据来讲，其实咱们会有底层的明细，有一些汇总，基于这些汇总，特别是易观这种给分析师做一些的查询，数据量非常大，如果做成在Hive上面查的话，特别慢，我们把这个数据已经做成基本结构化的数据了，它在做并行查询的时候又有关联，拿其他的工具现在目前看都不太方便。所以我们用的GP实现刚才说的这种查询，包括产品里面的用户画像，自定义画像这块的查询时限，通过GP来做的，通过Hive可能隔天了，或者反应速度不会说分钟级别了，我们原来也说怎么分钟到秒，模糊计算的事儿，其他分享里面有时间再交流，那个方法再加速这个计算。

来源：数据猿