唯真数据CEO邢刚：大数据产业架构、发展趋势及企业应对战略

主讲嘉宾：邢刚

主持人：中关村大数据产业联盟 副秘书长 陈新河

承 办：中关村大数据产业联盟

嘉宾介绍：

邢刚：广州唯真数据服务公司 CEO，二十年IT从业，十多年数据仓库建设和管理经验，现从事大数据方面的工作。多次参与中国移动集团经营分析系统技术规范的编写，主管了8省经分建设和DW产品开发，在数据仓库及商业智能的架构规划和最佳实践有丰富经验。熟悉MPPDB、hadoop、Spark、流处理和机器学习等大数据的架构规划、应用规划和新技术发展。在第一届Spark中国峰会和多次全国的开源会议上演讲，在移动行业和保险行业做过多次的数据分析、数据挖掘、大数据管理的培训和咨询。

以下为分享实景全文：

邢刚：从实际应用的角度来介绍一些Hadoop和Spark情况，主要从计算、流处理、交互式查询三个方面来对比。

介绍一下，我们在运营商测试的效果

酝酿期主要是创我在做BI，创我当时是在做网络优化的时候，引入GIS，并实现了B/S架构，市场部提出来要做一个类似的分析，并将客户分群做为一个功能要求放进来。当时利用这个功能发现一个特殊群体，以大学生居多，特点是通话少，短信多。广东移动就搞了一个青青校园的资费，一年就发展到百万级，之后集团找奥美公司包装和推广，形成“动感地带”。经分1.0建设，是以创我MASA为蓝本写的规范，全国建设。1.5重点是挖掘模型，之后数据业务建设了专门的分析系统--VGOP、建设了营销管理，再到集团客户建设专门的分析系统-ESOP，至此经分的发展就比较平淡，IOE架构已经完全发挥，网络数据太大无法处理。直到大数据技术的引入，支撑系统带来颠覆式的发展。所有的移动公司开始建设大数据平台，一家集成商投入200人在hadoop基础上重新搭建BOSS架构。。。

广东移动的第一个数据集市。

Hadoop1.0推出后，开源的大数据方案，08年开始流行，但仅仅Map/Reduce两种算法，在不同行业的应用中，不太方便，到2013年推出2.0，将资源管理和计算分开，开发资源管理产品YARN，架构上开发，各种流处理、图计算、交互式查询产品都能接入Hadoop生态。各种MapReduce的替代品发展起来，而且形成了自己的特色，其中Spark是最全也是最开放的一个。

2.0包括Hadoop Common/HadoopDistributed File System (HDFS)/Hadoop YARN/Hadoop MapReduce，不同于1.0的是MapReduce分为YARN和MapReduce两个部分。解决单节点、算法少和资源管理。

任务调度：

1、RM不断的搜集Node的情况（从NM得到）。

2、Client向RM提交计算任务。

3、RM在一个Node上产生一个AM。

4、AM向RM申请计算资源，RM根据资源状况以及分配策略，分配合适的资源（container）给AM。

5、AM得到资源后，管理这些资源，完成计算任务。

Spark目前有5个产品，spark扩展了MapReduce，Shark基于Hive的元数据，是一种SQL On Hadoop的很好产品，spark streaming是流处理产品，和Storm类似，Mesos是和YARN同样目标的产品，Tachyon是内存文件系统，解决数据共享和Java内存垃圾收集带来的速度问题。GraphX和Mlbase是图计算和挖掘算法，R语言支持是Spark最近重点发展。

现在有一种趋势，Hadoop生态在大数据领域主要是用HDFS,计算采用spark架构。

Spark网络采用主从架构，1、第一次都是从HDFS读取数据，之后就会在内存中读取数据，这个是Spark速度快的主要原因。2、执行动作(count)的时候，才正式执行，之前的处理都没有做。这样的处理能够减少中间环节，合并处理，加快数据处理的速度和智能。采用的Scala语言，支持函数式编程，精简高效。

这张原理图有动画，可能不太清晰。

这个是淘宝公开的架构，也是目前实际使用的Spark架构。存储层：HDFS存放各种格式的原始数据，HBASE存放宽表(多用于挖掘和查询)，目前已经支持包括各种云存储，如阿里云。资源管理除YARN和Mesos外，也支持云存储的资源管理。计算层就是Spark，基于兼容的目的其它也可以保留。应用层：流处理、交互式处理、机器学习算法和图计算。

以上是简单介绍Hadoop2.0和spark的原理

大家可能都有些了解

下面介绍产品对比效果。

同样的数据、相同的配置，同样的应用，一样的统计口径，Spark采用Scala编写。在较少重复使用内存数据的情况下，经过反复测试，Spark比Hadoop快大概一个数量级。这样的效果，已经值得大家去尝试迁移到Spark上，可惜很多公司在转向Scala方面不太积极。

scala语言面试函数编程，学习AI的同学会比较熟悉。

Spark 部分采用java 开发，效果不及Scala

Streaming和Storm是两种不同的流处理机制。Storm也可以做批量消息处理，但机制不同。Streaming是对一个小RDD处理，Storm还是一条条处理。一般来说，Storm的处理及时性高，Streaming的吞吐量大，系统设计上Streaming要考虑更多的带宽、处理能力和缓存，避免出现处理不及时而覆盖的隐患。

完整的流处理架构分为采集、消息处理、流计算、缓存和DB五个部分。根据实际的应用情况，有些部分可以省略。如果采集的数据比较均匀或者较慢，消息处理不必作为缓存存在，就可以省掉。省略掉某个环节，不一定能够提高系统的处理速度。DB环节往往是瓶颈，不少公司直接采用MySQL，磁盘操作会将整个流处理的速度拖慢一个数量级。

为测试，没有使用消息处理环节，采集完直接送过来做处理。如果数据放入HDFS，Streaming的处理速度非常快，比Storm快。直接采集生成DS数据集来处理，速度很慢。Storm在批量和单条速度都比较快。Streaming的一个最小的处理间隔是0.1秒。

这个测试化了一周时间，storm的开发不太方便。

另外流处理偶尔会出现丢数据的情况。

校对也花了较多时间。

Shark是Spark中的SQL On Hadoop产品，支持SQL语句跑在HDFS之上。为保持一致性，采用Hive的元数据，再将SQL本来对DB文件的处理，转换为Map/Reduce计算，读取HDFS文件。

Impala是Cloudera公司开发的一个SQL On Hadoop产品，目前还没有开源。实现原理和MPP非常类似，client端发送请求到一个节点，请求NameNode，得到数据分布，在将计算发布到另外两台有数据的节点，三个节点在HDFS上计算，另外2个节点计算结果传回发起的节点，该节点汇总数据，传回客户端。完成一次SQL查询。

顺便做了SQL On Hadoop和MPP DB之间的速度比较，如果要取代MPPDB在性能上，还是要继续提升才行。

何鸿凌-中国移动：数据库还是更牛，特别是在关联的时候。

邢刚浩微数据 B：对，同样的配置。

何鸿凌-中国移动：这个测试在多大规模集群上做的？

邢刚浩微数据 B：8台pc

何鸿凌-中国移动：规模小了点啊

邢刚浩微数据 B：嗯，数据也不大。

何鸿凌-中国移动：流处理能实现10万/秒的处理速度

邢刚浩微数据 B：目前能够满足一个中等省公司的实时营销的要求。

三个产品对比之后，再介绍一下spark应用到运营商。

一个是采用Lambda架构，简化系统架构

Lambda架构由FaceBook提出来，采用Hadoop和Storm为主体搭建，在Spark上可以做到融合。在2014年的Spark全球峰会上，有咨询公司提出，采用以上架构，来实现容灾的方法，将增量数据放入Streaming实时处理，定期将全量数据传入到批量处理，2者之前互备，以防出错。

运营商已经基于传统DB建设了EDW，也采纳了MPP方案，实现不少系统，这些资产组成了大数据平台，Spark最后还是要落实到这个架构上。目前可以做的有以下几个点，1、架构监控，能够从业务层次监控和调整这三个平台的运行情况，实现SLA。2、流处理的优化，从每秒10万次处理，提升到50万次的操作，主要是解决Streaming的单点读取问题。3、结合SparkR实现实时算法处理，改变之前的6个月的数据挖掘周期。

以上是我的分享，比较偏技术。

交流互动

阮彤_联盟学术委员会主任委员：@Felix 感谢分享，除了计算，流处理，交互式查询，数据挖掘有需求吗？

邢刚浩微数据 B：比较少，现在标签系统有些挖掘，还是传统的方式。实时营销有点简单算法，不需要挖掘。

沈备军@上海交通大学：请问，你在spark上跑应用时遇到spark出错，计算不出来的情况？

邢刚浩微数据 B：有，次数不多,主要是代码写的有问题。

沈备军@上海交通大学：@Felix 你们的数据有多大量？我们在处理4T数据时遇到内存溢出，通过设置参数好了，但速度慢。有什么好的建议？

李正海万卷科技CEO：大数据可视化：@沈备军@上海交通大学请重点研究可视化还比较传统。

邢刚浩微数据 B：我们主要做的测试，最大的数据量2T，存储4T。没有什么好办法，不断测试，寻找速度和内存的平衡点。

沈备军@上海交通大学：@Felix 嗯，我们也是这么做的，但数据增长速度太快了。

邢刚浩微数据 B：spark对内存量要求教高，改变处理的算法。我们当时有一个百兆的表，cache内存中马上速度下来了，分片才行。

邢刚浩微数据 B：百G。

沈备军@上海交通大学：我们用的是聚类等算法，表倒不大。

沈备军@上海交通大学@李正海万卷科技CEO 你建议我研究可视化？具体讲来。

李正海万卷科技CEO：大数据可视化：讲个案例吧一企业上信息化企业信息中心主任把所有物料数据打印出来给厂长，40多页，厂长很不高兴，厂长说法，把累加库存80%物料，安全件，特殊件（例如采购周期特别长）挑出来给我，结果从2000 多条降到不到200条。

查礼：Spark做迭代计算比M R效率高。@Felix 流式计算在运营商的应用场景多吗？吞吐量和延迟两者好像不可兼得啊。

邢刚浩微数据 B：场景比较多，一个省大概有20多个。准实时，一般都有几分钟时间来处理。@Felix 我只知道日志收集，还有啥有意思的场景吗？如客户到机场十分钟之内，按照五六个条件筛选出来。

邢刚浩微数据 B：很多是流量经营、4G手机方面的场景。流处理的延迟受什么因素影响最大？以前都是攒一堆数据一起处理，比如要求1小时必须处理完什么的。现在流处理模式中，这个指标肯定发生了巨大变化。

邢刚浩微数据 B：流处理流传的是消息。

刘强—乐蜂：spark最适用迭代场景，如果纯替代mr的话，从业务上的驱动力必须定位清楚，只能说批处理是可选方案之一，但迭代是唯一选择。

邢刚浩微数据 B：一个消息2k左右。

查礼：没想明白这两者间的换算关系。@Felix 嗯，消息传输开销叠加。

刘强—乐蜂：而且现在最新版本已经没有shark了，是sparj.sql。

查礼：@刘强是的！

邢刚浩微数据 B：批量的吞吐量大，速度较慢。实时的吞吐量小，速度较快。实际的计算量差不多。

刘江：（spark）现在啥局势？

邢刚浩微数据 B：在国内很少人关注。

邢刚浩微数据 B：spark sql现在主要对手是Impala吗？

刘江：查询这块你们感觉下一步谁会更有希望？Impala好像最近也很受挫 @Felix @宝宝公

查礼：我认为开源的劲敌是impala，Fb的还离的太远。Impala的对标是G P, Vertica，还有HAWK。

邢刚浩微数据 B：我们代理Vertica两年，经过多次比较，要超过Vertica，还比较难。

查礼：V的国内市场做得不好。

大数据厂商联盟--李永：@Felix impala50个结点下也免费吧？

邢刚浩微数据 B：市场不好，主要是HP的渠道有问题。

邢刚浩微数据 B：V这个产品还是不错。

大数据厂商联盟--李永：同类产品太多。

邢刚浩微数据 B：Impala了解不多。

查礼：@大数据厂商联盟--李永国内有不少类似产品，但想超越很难。@Felix Impala不久前放出测评，跟Shark杠上了。

大数据厂商联盟--李永：HANA、 N、 GP、 paracel。

查礼：这个@何鸿凌更有发言权。

何鸿凌-中国移动：我们在做一个大规模测试。

大数据厂商联盟--李永：华为做遍了测试、结果好像很有意思。