×关闭背景

英特尔云创新中心程从超:并行计算与大数据

2015-08-26 15:36:14      来源:移动Labs       

2015中国国际大数据大会

【摘要】【移动LABS】8月26—27日,2015中国国际大数据大会在北京召开,移动LABS作为大会战略合作媒体受邀现场直播。英特尔云创新中心解决方案架构师程从超做了题为“并行计算与大数据”的主题演讲。

【移动LABS82627日,2015中国国际大数据大会在北京召开,移动LABS作为大会战略合作媒体受邀现场直播。英特尔云创新中心解决方案架构师程从超做了题为“并行计算与大数据”的主题演讲。

英特尔云创新中心解决方案架构师 程从超

以下为演讲速记:

大家下午好,先自我介绍一下。我叫程从超,来自于英特尔云创新中心。今天分享的题目是并行计算和大数据,并行计算是用于高性能计算,像国家的超算中心,像天河一号和二号。现在大数据hadoop起来,包括数据库这个概念提出来,其实并行计算和大数据之间的界限越来越模糊。今天我给大家分享第一个是对大数据计算未来趋势的理解,第二个我们认为一个大数据的典型的架构。几位运营商的同事可能跟我说的不一样,他们是大数据怎么创造价值,怎么应用。而英特尔提出来大数据作为一个已有的架构如何更好支持它,大家对英特尔理解我们是一个卖CPU的,其实英特尔也做一些转型,做大数据的解决方案,私有云、公有云的架构等等。

首先看整个的数据处理的分类,刚才移动的同事也提到,其实B类主要是交易数据,我们讲的话单,现在运营商包含了交互式数据,我们和运营商网络,我们的无线网的交互数据,把数据抓过来,我们的设备和网络之间的交互数据抓出来。再一类就是现在提的IOT的传感器的数据,包括上网的设备之间的数据,这几类一般是O域的数据,更适合叫做大数据。因为B域原则上一年的数据增量上T也不很多,但到O区一天几十个T可能都是正常的。

所以我们从三维角度来看,当然实际数据并不仅仅是三维,里面还有一些结构化,非结构化,很多的维度,我们只是从三维来分析。就是数据量、计算量和市值性,从三个角度对存储和计算做一个分类,第一个就是小计算量,实时性要求很高,这个基本上是我们的核心业务,我们叫EDA,事件驱动架构,前一段做架构的说的比较详细。还有流处理,事件一出来触发一个处理引擎,比如(英文)等等。都是解决这一块的,再往上数据量很大,计算量很小,这是准备好的数据,比如(英文)并不是数据量大计算量小,而是它的数据经过预处理了,比如谷歌百度帮我们建好了,我们查询的时候数据量很大,但是计算量并不大,都是算好直接查。下面是计算量很大,但是数据量不是特别大的这种适合什么?一般的数据挖掘,多次迭代。刚才运营商同志提到我把数据拿来计算很多的主题,我们叫主题分析也好,做很多挖掘也好,同一份数据做很多挖掘、计算、分析,这种更适合什么?内存数据库,内存数据网格。比如(英文)。最后一块大数据大计算量,计算量巨大,同时实时性要求很高,你可能建一个内存数据网格,数据放在里面,然后多机并存算出来。大的厂商可能有几千级的集群,每一个节点是64G的集群,跟前端的用户做实时分析。这种状况下就有点并行计算的味道了。

多台机器合在一起形成一个大的计算网格,对外提供交互式服务,同时要求系统的时延性要小。大数据不仅仅是这三个维度,我们中国的文化是一个六维的,但实际我们意识不到,意识不到不是不存在,而是我们的认识有限,我们一步一步在学习。

再往下我们看一下三维分析下来以后,我们看看英特尔的认识,我们看看数据市场成熟的数据的方向,就是大数据的几个走向。我们那么多业务,比如刚才讲到我们做信令分析,做网优,做CP和精准营销等等怎么来实现,因为有很多技术和很多要求,怎么实现?

第一种对时延要求比较小的,两个方向,内存数据库和内存数据网格,内存数据库我们知道比较多了,联动、移动、电信的实时计费等,在里面做了很多,他们对外的基本架构就是基于(英文)接口,大部分是基于单机,单机上利用一个机器的内存对外服务。好的地方是方便,不好的时候多节点只能做(英文),做分布只能通过运营商的分布做分割第一单破容很麻烦。

第二种是内存数据网格,典型的是(英文)。最简单的以前用的比较多的是(英文)好一点的会自动在数据各个节点做分布,就是多个节点,形成大的数据网格,对外接口是(英文)方式,而不是数据库。做交易没有原来的(英文)保证事物一致性,这里面事物一致性可能要在应用里控制,但是用在XP绝对性能比较高,而且扩展性比较好。第二块就是数据量变得更大,这个里面在国内两个流派,第一个是hadoop,第二个是数据库,这个方面做了很多了,像(英文),现在华为也在开发自己的分布式数据库。

第三类是基于小并列这种架构慢慢被X68加阵裂这种方式替代,是成本和效率的考虑。我不多讲,大家也都很清楚。另外就是一体机,便于我们部署,同时解决很多性能问题,因为运营商的最佳实践和软硬件结合起来,我们针对数据库也好,针对hadoop也好,这是一门很大的学问,怎么办?两个方向。第一如果不熟可以买调好的直接做,第二种可以向互联网学,不如调参数,我用的参数跑什么样算什么样,机器不够加机器,就不调,就用自己的参数,也是自己调,就看自己的基础能力和诉求。

大数据和并行计算的趋势,他们两个的架构其实很像,从底层的硬件配制,叫SDNSDS等等,就是软件定义网络,网络定义存储等等一大堆。在他们之上的操作系统,再往上资源管理,最后这些编程模型。其实这两个原来差很多,但是自打hadoop出来,越来越时髦之后两个逐步走向融合。大数据的(英文)也好,分布式计算就是把多个节点之前的计算能力用统一的资源框架管起来,统一调度。

当前大数据处理的业务类型我分成几类。下面的(英文)不用管,就是三类数据,交易、交互和(英文)数据。这三类出来之后有两种方式,第一种是P处理,比如(英文)。原来IBM部署的(英文)工具。在大数据时代用这个工具不是不行,因为数据量太大了,第一成本高,第二(英文)的特性,跟hadoop比不能说不好也能用,但是用传统的(英文)工具直接调hadoop也没关系。慢慢的会走向开源很明显,比如hadoop的(英文)原来做很多,上面挂一个(英文)直接用(英文)调用,当然用分布数据库你用(英文)来做也没问题。现在又出现一个新型的spark,就是针对(英文)来做,因为(英文)我们知道中间结果。同时对这个硬盘的(英文)也高,所以(英文)不适合迭代式爬行,比如我要做十个主题分析,(英文)每做一次弱一次盘,怎么办?用spark,在同一级可以计算多次,这样效率比较高。

作为英特尔来讲一般建议用两路服务器来做(英文)-横向扩展比较好,因为它的特性对CPU要求很高,这样正好和并行计算契合,效率比较高。英特尔建议是两路,CPU性能高的,建议你配英特尔两路CPU,然后网络尽量按照我给你说的办法,整个来讲有点亏了,因为效率用起来(英文)延迟比较低。磁盘(英文)刷入刷出,当然用(英文)更好。

再往上就是(英文)存储,如果你不做分析,只是拿来留备,就是要悲愤一份方式做合规性检查用的,就用(英文)压缩更好,如果做分析和挖掘,这里面还要给用户做画像,甚至跟第三方合作,可以考虑用hadoop,如果是分布数据库也没问题,也能支撑。

第二类就是历史分析,传统的(英文)分析。针对这种我个人建议从目前来讲除非前端应用都是自己开发,前端的在分析的时候全部用spark语言,否则还是用他的数据库比较好,因为这一块数据量不是特别大,而且可以分成我维度。现在传统的(英文)还基本上是(英文)接口,真正的hadoop还是偏入口,而且用户习惯很难改过来,分众级响应用户很难适应,并不是说不对,而是需要一个过程。你要说用spark,就像第一批用户一样,即使销售也会写C口,如果这样的话也可以考虑用spark,没问题。

最后针对实时分析、告警这一类可以直接放在数据库里,这个都有自己的特定场景,有兴趣的话大家可以下来讨论。

第二个是流失处理,比较流行的是(英文),他们的流失处理是刚刚开始的数据处理的趋势(英文)也在做,走向(英文),小P。原来我们知道一天数据集合起来,做交易数据,天为单位,把时间窗口留一晚上就够了,现在一个省几十个T,做一晚上都做不完,这样可以分成小批,端到端的数据时延也会越来越小。现在我不知道是不是又改过了。慢慢两个会往一起靠。

下面讲一个大概的部署方式,一般情况下有一个大云,有一个hadoop来讲,我建一个大云,有一个大的,无论非结构化还是结构化的,先存下来存完之后在里面起一大堆的(英文)任务,我会起很多任务,一天几十万个也有可能,按照集群大小,把汇总的数据按照业务需求分到前端,按照部门和地域发到数据集市,按照前面的需求你可能是hadoop或(英文),比如我就做(英文)最好,如果我就是随机选定用惯性数据库更好,当然还有适合内存数据库的场景。整个来讲是端到端,数据准备好了,后面的数据利用就是我们的业务专家、数据科学家的事情,去建模,然后根据业务把数据分析变成财富,我今天讲的主要是数据储备这一块。

从英特尔来讲,从目前来讲英特尔不仅仅卖CPC,第一做解决方案,第二除了CPU还有我们卖的网卡,前两天大家在微信包括媒体上看到英特尔最新出的基于内存槽的SND卡,传统的盘每秒钟访问次数在50100Saas100,一个Saas的每小时到7.5万,基于PCIE基本上可以到45万,读的话到45万,基于内存槽的SSD,像英特尔发布的叫(英文),这个技术出来之后到明年下半年拿来测可能比现在PCI的又快了几倍,只是内出这一块就有几百倍的性能提升,其他的什么都不改,底层一改就提升,这种状况下对数据处理市场会有一个颠覆性的操作。尤其现在我们用(英文)很多应用端做缓存的技术可能有一次洗牌,大家可以多了解这方面,存储这一块很快这个革命就要来了。

比如基于内存槽的SSD,我的内存的东西不丢,内存延时大一些,这时候在硬盘的处理,无论是算法还是什么都会有变化,我只是提一点存储方面。

作为英特尔来讲,针对我们的传统的数据架构,无论是(英文)共享数据存储,这种架构建议用(英文)四路服务器或者八路服务器去做,底层用(英文)盘,因为它们对(英文),建议与他们之间的连接,涉及到(英文),远程内存访问,你用ID去做互联更好。实际网络能做,但是延时比一般的要大一些,前面的性能就不要想了。

针对这种(英文)的两路的并行计算建议用两路的(英文),我们千万不要认为CPU随便拿一个就行,CPU越高,对性能计算要求结果越好,我建议我们无论做什么架构先把单机性能充分利用好,当单机不能扩展再横向扩展,这样可以保证机型达到最佳性能,一堆性能不好的机器结合在一起,互联的损耗大集群不一定比小集群性能好。

今天讲的最后一页是英特尔的总结,端到端无论从CPC还是什么我们作为基础架构的提供者,我们希望我们的同仁和运营商,其他的合作伙伴们在大数据上挖掘更多金矿出来,谢谢。

声明:所有会议记录均为现场速记整理,未经演讲者审阅,本站刊登此文出于传递更多信息之目的,并不表示赞同其观点或证实其描述。

更多会议精彩内容请参见专题:http://labs.chinamobile.com/bigdata_2015

(责任编辑:王源野)
共 1 页
分享到: 0

评论

全部评论我的评论

满栋梁2015-08-26 15:48

一直在关注此类话题。

王又新2015-08-26 15:45

点赞,欢迎跟帖!

李全欣2015-08-26 15:43

写的不错,赞一个