Pb 级大数据集群云化与迁移

  2017 CCS企业云计算高峰论坛(ccs.d1net.com)于4月26日在北京新世纪日航饭店盛大举行，这是国内面向政企客户的最重要的一个云计算会展。CCS企业云计算高峰论坛的主题为云计算的生态链。

以下是现场速递。(声明：本稿件来源为现场速记，可能有笔误和别字，仅供参考)

易观 首席技术官 郭炜

主持人：尊敬的各位嘉宾，各位用户代表，渠道代表，厂商代表，媒体朋友们，上午好! 2017 CCS云计算渠道伙伴合作高峰论坛现在开始!我是本次大会主持人企业网D1net的金颉。我谨代表本次会议的主办方企业网D1net，对各位来宾的光临表示热烈的欢迎!

冬去春来，花落花开，云计算也早已从概念落地到了人间，无论是私有云，混合云，公有云，都如雨后春笋，遍地开花。而作为关注实战的企业网D1net，我们最关心的还是实战案例，今天的大会，我们安排了多场干货分享，请大家共享盛宴。

由于易观的发言人郭炜总中午临时要出差，所以把他的发言调到第一场，郭炜最的发言与云和大数据相关，云和大数据说得很多了。大数据上云的案例见过吗?上云后又想从云上迁移出来的案例呢?这中间的坑和注意事项你造吗?接下来是一个干货满满的案例分享。由易观首席技术官郭炜为我们带来：PB级大数据集群云化与迁移，掌声欢迎!

郭炜：大家早上好!先替老范欢迎一下在座的各位，因为我抢了老范的开场发言，感谢大家今天到我们这个云计算渠道合作伙伴峰会。今天我其实会给大家讲讲云迁移的事情。开场之前，我想问一个问题，大家都在说大数据好，究竟大数据能做什么，如果你是一个企业的管理者，你会第一件事情拿什么东西去证明一个大数据?

我这儿正好有两个图。左边是一个实时计算分析的展示大屏幕，它能做到任何目前无论是APP，还是一个网站，能够五秒钟把你的上百亿条的数据马上计算出来，这个数字会实时变化。这是看上去一个非常酷的技术的展示。右边这个是一个我们叫做在企业里边常见的一个数据分析的界面，它是做什么的?是做漏斗转化，所谓漏斗转化就是大家经常知道做互联网的会知道，有人要从渠道过来，会花一些推广，会浏览你的网页，可能会看商品，看完商品会下订单，下完订单可能去做结算，会告诉你每一步中间的转化率和流失率有多大。这其实是两个不同的界面，这个如果你是一个企业大数据的负责人，或者一个企业的CIO，或者CTO，同样的两个方案放在你面前，在座的各位会选哪个?选左边的这个大家举手?谁会选企业自己内部数据分析的?没有。选右边这个呢?有一些。

今天我说云迁移之前，先给大家说一个概念，就是以“精益创业”的理念修建大数据平台。什么意思呢?把我刚才的自我介绍跳过去了，我其实是易观的CTO，我以前在IBM做过，去中经做了一段副总监，然后去万达做大数据平台的总经理，然后去联想做大数据平台的总监，现在在易观负责它的整个技术和产品，是去年的月份加入的。

刚才说的“精益创业”这个理念，大家都在说做大数据好，其实大部分企业都在喊一个口号，说我们要建设大数据平台，或者要建设大数据平台项目。其实从我的观点来看，《精益创业》这本书我非常推荐在座的各位无论做哪行哪也都应该看一下，里面有一个MVP，说叫最小的可行化产品。这个意思是说，如果建一个大数据平台的时候，你应该是有一个业务闭环在里面，而不是只是一个展示，或者是一个数据上的一个平台的建设。所以，这个意思是说，如果你要建一个大数据平台，一定要端到端的解决一个业务问题。所以，如果从这个理念来看，大家再看这两个图片是怎么来做的。

第二个是说，你要和你最终的客户业务保持同步。其实经常也能听见一些话，我们先建平台，有了平台再建业务，大数据平台都是这么建的，其实不是，是先有业务，再有平台，这也是“精益创业”的理念。

第三，业务闭环，一定要端到端的解决一个问题，否则将来你真的让业务用起来，推广大数据的时候发现这个事情会非常难，可能最高层看到一些报表，其实大数据的魅力在于真的能够驱动你的业务的闭环和业务的优化。

第四，增速、转型、创新，它其实不是一个技术的事情，而是业务的一个闭环，结合这四个理念，再回头看这两个比较炫的屏幕，大家会发现做真的业务转化的数据分析要比我们要建一个真正看上去非常炫的Dashboard好的多，能得到相关的业务的数据魅力和数据分析。所以，我讲的“精益创业”贯穿在我所有的演讲和发言当中，今天云的迁移当中，其实也可以看到，是这样一个基本的理念，就是MVP的产品，从它逐步的迭代，实现云迁移，大数据建设到最后。

先说说PB级的大数据云化迁移的一些难点。首先，这是我刚去的时候遇到的现状，每天处理量大概10T，历史数据基本是PB级别，现在采集接口大概几十万的这样一个并发的整合，如果大家知道QBS达到几十万是非常大的一个量，非常高，还有一些数据流的实时计算。我们在架构上面是要大概率，过去是一个纯云化的东西，我们后来把它迁成了混合云，它的数据模型也会发生变化，数据本身存储的方式也发生变化。而且从我们的业务部门和我们的整个公司来讲，要求无缝切换，要求两个东西要并行，这两个东西每天10T的数据，PB级，还要并存，这个非常难。

怎么干呢?先说说早期的我刚去的时候大数据平台的架构。其实我是一个坚持推广云化的技术决策人，我在几年前就说大数据云化，但是为什么在这个时候我说公有云不能让这样一个大数据规模的集群，大家看到有一些技术细节，它有MQ，然后放在HDFS上面，这是每一个公有云上面的流程，但是当数据量级在PB量级的时候目前咱们国内的公有云的支持力度还是有限的，比如数据量QBS是几十万次，会把我这个东西直接当成DDoS做一些清洗，这是第一个问题。第二个问题，因为公有云大家知道是为了分享，而不是去独占，对这个大数据处理的时候会发现它的IO和CPU已经几乎会独占某一台物理机了，所以我们物理隔离其实做的并不是特别好，就是同样一个数据量发生变化，我的脚本没有发生变化。有一天可能头一天数据量级在4个小时，第二天可能同样的脚本要运作8个小时，这样对我来讲，我无法承诺我的用户能看到的一些数据分析的指标的时间。大家很难想象说，今天有的时候早上9点钟我就能把这个东西跑出来，有时候12点。所以，在这个量级的时候我们发现在公有云没有办法支撑我现有的这样一个数据量级计算的时候我们会选择混合云。

这个时候大家说为什么不自己自建IDC，为什么不自己做存储，为什么选混合云?其实这里面和各位企业决策者一样，会有一个为什么上云的问题，究竟什么时候上云，为什么要去上，上什么样的云?从我个人理解来讲，云化其实是一个大的趋势，但是你的业务不是一步就全部上云了，基本上你是看到自己的业务的发展，如果你的业务发展是一个新的业务，可能会出现指数级增长的时候，那么你一定是要云化的。

为什么这么讲?是因为很多的这些企业，现在有传统企业，有互联网企业，会发现自己的业务如果真的增长的时候它是爆发性的。比如说，现在我以这个例子来讲，去年我们的日货在百万量级，今年此时此刻已经接近四千万，月活过去可能不到一个亿，现在月活已经到4.4亿，会发现每天它的数据量，如果有新的合作伙伴的渠道接入，可能日活就会翻番。所以，去年我一年经历了整个它的数据从1倍到10倍的增长。如果没有这样一个好的云化的平台，我很难去完成这样一个弹性增长。

为什么云混合云呢?第一，接受端公用云弹性扩展，网络带宽、接收性能、安全防控，可以帮我防住第一波安全相关的问题。第二，对于处理平台来讲，我的数据量一直在增加，每天有十几T，几十T的数据资源，如果是云化的，如果不是独占性没法满足我很多的业务需求，后面我会讲到实时计算，是耗高CPU，高内存。技术逮逮迅速，我们这个大的屏幕版本的增加，Hadoop这些版本的提升，会用到很多新的东西，这些公有云是没有办法让我满足我的这些需求，我的速度是快于公有云。投入TCO可控，真正做实体机的大数据集群的时候，它的没有你真正云上的投入那么大，所以我选择混合云会选择大数据这块的存储在底下线下我们的实体机集群。每天接近200亿条的数据，现在已经200多亿条，然后大概三四千万的用户，600多个合作伙伴的数据源源不断的接入是非常稳定的。所以当时可能也是去年1月份我第一个提的这个混合云真的把它实现了，然后包括公有云到私有云的带宽打通，我当时找了很多供应商，找的很多都没有实现，好不容易找到一家，真的打通了公有云和我们自己IDC之间的带宽的问题。

当然，现在很多公有云厂商已经提供了，今年开始提供混合云的这些实质的服务了，去年在我用的时候可能还没有。

我刚才说的那个架构，简单的再重复一下。我们在Acloud做数据接收，在大数据集群通过了大数据的处理，然后我会在公有云的Bcloud提供我对外的服务，中间有一个比较大的问题是这个数据怎么从我的公有云上传到IDC上，这个我会有一页去讲，是我做的一个开源的“四分卫”的项目，“四分卫”就是橄榄球的传球手。这个是目标混合云的架构。

先说迁移这件事，迁移真正做起来我觉得是原始数据压缩同步比较难，我们一开始通过互联网对传效果还好，基本上我们传了接近200多T的一些数据，后来我发现有一些数据量比较大，但是传的时候速度不够理想的时候其实也没有什么办法。大家看到亚马逊的迁移，拿卡车运，拉了那么多机柜，我是通过硬盘拷过去的，通过物理的方法可能比通过网络方法更快。

另一个在做了一些数据的验证，这个其实没有什么难点。难点就是每天200亿条的数据，怎么让它并行，就是我不但要原有集群能够接收这样的数据，新集群也能接收这样的数据，大家想200亿条数据等于实时的拷贝出来，拷贝完以后，一方面给原有集群，另一方面给现有集群，这个东西其实当时是难度很久的一段时间。包括无缝切换，因为要平滑过渡，切的时候肯定不能一刀切过去，其实真正切的时候比两边可能更长，这个肯定是所有业务部门和所有我们的客户是不能忍受的，我怎么无缝，怎么去做，这件事当时我们想了很久。

其实当时做数据迁移的时候我们想了很多方案，接收端说能不能通过nginx在里面做一些东西，为什么不行?不行的原因其实很简单，就是它是一个转发的服务器只负责转发，但是如果这条线路断掉，或者慢，这个数据可能就会在传输当中发现丢失，丢失的时候就会发现这两边的数据将来你的新的集群和老集群里的数据会对不上，这样迁移并行就失败了。所以，通过nginx的方式只是做一个简单转发这件事情是肯定不行的，这个东西会丢包，丢包完以后是没有办法弥补的。Kafka也是，200亿条数据量级的时候通过互联网同步，第一，占用带宽非常大，第二，很容易丢包，这个数据就对不上了，这样没有办法做到很好的数据同步。所以，这个肯定不能通过这种方式来做。

后来我们做了“四分卫”的开源项目，大家知道在云迁移，通过互联网互传的时候小包去传是非常没有效率的，所以我们会在“四分卫”这个项目里面把它做了一个压缩，这样可以把一个可能每个包都是几十的，可能有一百万的包括，或者两三百万这样的一个包压缩成一个档案，当然中间也用了一些压缩算法和一些排序把它做好以后，通过互联网传到两个接收端，然后在那里边再去解包，然后按照它的顺序再进入到Kafka里面，进入Kafka，然后通过互传同步的机制，保证不丢，丢完以后可以续传，然后那边是一个阵列，然后再把那边放进Kafka。当然，中间有为什么断链续传，很多人问我为什么会排序，因为经常会断，断的时候要保证先进的这些数据优先去处理，而不是乱序排，这样可能数据量的方式计算会有问题。所以，在这里面也用了很多的一些小的trip和踩过一些坑。做大数据云迁移的时候肯定遇到数据并行的问题，遇到这个问题可以通过开源的项目去看。

说完云迁移中间互传的问题，其实还有另外一个问题存在，就是各种的大数据做完以后持续的很多的挑战。

挑战一，可能左边那个图如果做CIO和做CTO的管理者可能都会熟悉，这个图是在那时候每年东部全部断网，其实仔细想一下，现在如果我们做大数据的数据接收端，当我的活跃已经到月活4.4亿的时候，当每天有4亿多台给我传这个数据，其实结果搞不好和它是一样的。这样一旦做不好，结果其实跟美国那边是一样的。所以，这里面当我的数据到某一个量级的时候会由量变到质变，这时候就会让数据的并发，像交易系统一样，就是你的并发非常高，后面会不停的再往上传输，这时候它的数据量像雪球一样越滚越大，这个数据可能就完全处理不完了，真的成为DDoS了。

所以，这里有两个观点：第一，要良好的扩展网络架构，刚才我讲到混合云为什么采用混合云，不采用私有机房。第二，云+端的控制策略。云+端是什么意思?其实就是大家真的在做大数据，在做处理的时候，不是说你这个数据从底下一下就到云端这个事就完了，不是。是因为你需要在你的端的这个地方，就是你在数据上传这个端是要有策略的，当你云端出现了无法处理完成的时候，你要回来说，这个东西先别传了，4个小时以后，或者2个小时以后再传，或者我发现这个设备本身是恶意的一个设备，不停的在传一些设备，我会下一个策略说，这个设备现在不要传了，进入黑名单静默，这样我在启动的时候，有心跳的时候你再传，这些策略会在这个里面设。在云端有一些策略，比如时间间隔是5秒传还是5个小时传。清洗策略，就是这些数据哪些是你来的时候我接收，哪些我接收都不接受了。包括像分流，我们现在在传的时候，你肯定不能单点传到某一个地方，你的云端一个策略，云告诉底下端的策略到底传到哪里去，下一步不要往里传了，这个混合云的接收端不行了，换一个公有云再传，这些其实都是云端的一些策略。

设备端的策略，主要是看有一些失败的策略，更新的策略，包括保活，就是一直有心跳，这些也是验证了很多合作伙伴，现在目前来讲，我这个策略会从5秒到6个小时，而且可以屏蔽和分流一些历史设备，这些都是大家在做云化大数据处理的时候都会遇到的一些问题。

挑战二，其实这个事也是，数据都上来了，大家已经在混合云上面使用了。经常遇到企业的一些需求是什么?就是说，我想看到某一些特征的用户，这些标签它的某一些的统计值是什么，这里举了一个例子，右边各种各样的标签，做完标签之后，马上说具有这些标签的这些用户统计值是什么样的，最难的是要求30秒给我算出来，但是其实背后是一个几百亿条的数据，然后用户是一个十几亿的用户，标签可能几千个。如果通过标签+用户+设备数一乘起来上万亿了，所以这个事是不行的。最终我们的解决方案还是两件事，一个是解决方案中另一个除了Hadoop之外的一个开源的大的APP架构的一个解决方案，前年年底开源的，我去年年初的时候用了它，它是在数据并行计算方面比较快的。即使用了它还是不行，所以中间我们会做一些分层抽样，就是对你的这些人群，根据抽样策略有一个小的模型，抽样完了，目前能体验到20秒把这个东西算出来。这是其中像大数据常见的问题之一了。

问题之二，刚才说查这个数现在好了，现在也经常有企业有另外一个场景，就是漏斗查询，我想看这些人究竟谁浏览了网页，浏览网页的人有多少人浏览了商品，浏览商品的人有多少人真的下单了，下单完了之后有多少人支付了，很简单这样一个问题，就看一个月内7日的转化率是多少，但是目前来讲，整个互联网圈子都没有特别好的解答，大部分人会避开这个问题，所以这个东西是非常难的。它难在是在对一个有序行为序列的转化漏斗，因为过去咱们熟悉的这些SQL，包括常见的处理方式，都是针对无序的，针对有序的查询是很麻烦的。我后来也是在这里边写了一个东西，先写成一个函数，再作为一个转化率的时候，这件事情我后来也是会把它开源掉，因为这一堆问题，业界大家都在问这个问题，很常见，我打算也把它开源掉，给大家一个参考，如果有做的更好的，也希望持续开源。

其实针对每个点的布点优化，云+端，端的SDK会不停的做优化，做每一个点的优化，把整个原来的系统去重新构建，重构去变成新的一个系统才能满足你将来几个亿的月活的这样一个大数据集群的满足。

所以，回到我这个现在看到我的整个的一个易观的混合云的一个大数据这样一个平台，你会发现其实底下是各种各样的数据采集，然后通过我们的公有云的接收端，上面有很多技术的大数据的平台模块，有Hadoop，那边有一些我们自己自建的平台，看上去很简单，但是每一个模块画上去背后都有它的故事。我今天主要给大家讲讲刚才迁移上面遇到的一些问题，这是最后迁移完的一个结果。

浴火重生以后，现在我们看到混合云大数据平台4.42亿月活，累计装机量1.8个，18.2亿，现在3000多万的日活，这个基本上在互联网是前十，确切说是前五。这是全公有云的平台，现在基本上我们的存储达到5.8PB，这是目前整个存储的量级。因为大的集群底下全部是私有化的，所以还会不停的扩集群，然后有公有云的这种非常健壮的接收能力，能够让我一直不停的扩大初级接收端。

总结一下，其实简单的几件事。第一，要做基础建设，混合云的建设，混合云的验证。第二，做历史数据，原始数据的同步，包括MR研发与追数，数据比对与校准。第三，并行验证，并行程序研发，并行试运行，并行运行，产品切换准备，两边数据都有了，然后进行无缝的切换，其实没有感觉到产品是由原来的集群迁移到另外一个新的集群，从用户端和产品端看不到这个事。最后，处理过程当中有很多数据治理的问题，数据口径的问题，元数据治理的问题，这些都是大家在大数据云迁移的时候遇到的这样一个问题。

基本上用几个话总结一下今天跟大家分享的。第一，分享了几个简单的方法论，怎么做大数据云的迁移。然后，讲了一个最佳实践。第三，赋予了一些开源的一些工具，希望今天我的分享给大家有所帮助，非常感谢各位!

标签： 云计算 私有云 混合云 公有云 大数据 云迁移 

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。