您的位置:首页 > 大数据

大数据时代的万象变化

2017-06-06 10:33 99 查看

大数据时代的万象变化

作者:廖恒

近来多次和百度、阿里、腾讯、中移动数据中心的架构师进行交流,同一时候也在网上的论坛/社区主导大数据分析范例的一些讨论,与互联网/云开发者进行沟通。

由此,我愉快地发现。大数据分析在中国很普遍:不光是星巴克、纸牌屋等美国文化元素在中国广受追捧。Hadoop也受到广泛接纳。而且在中国的云开发者的讨论中占领了主导地位。可是,和其它流行事物一样,人们在追捧讨论的同一时候也会考虑它当前的热度是否合理。“假设我讲Hadoop有些名不副实,会不会有人来踢馆?”——可能全世界的主管和开发者都在考虑这个问题。眼下公司介绍中夹杂“大数据”等词汇,冀图借此提升公司形象的情况随处可见。还有一方面。开发者购买Hadoop类书籍来自我提升也屡见不鲜。

然而更加理性的架构师则应该至少还记得最初採纳Hadoop的实际考量:

a) 免费。

b) 仅仅须要便宜(通用的)硬件——一个通用server的机群仍然比一台高性能、专用的机器要便宜。

c) 开发便利。有了庞大的使用群体,代码基的增长速度惊人,自学成才的开发者也随处可见——从BBS版块或个人的微信朋友圈就能方便找到。

这些长处非常难抗拒。

可是要实现一个可以进行自己主动任务追踪、数据复制、文件共享的并行处理平台,须要开发和维护千百万行平台软件代码,光是想一想就足以让不论什么公司的project师头大不已。

此外。为了实现这个系统,还要专门定制硬件,又会额外添加数年的时间。此后才干真正開始开发分析应用。那么,是否除了Hadoop。我们就别无选择?

让我们再来聆听硬件架构师的声音:Hadoop对于某些任务而言可能十分低效:

1) 面向文件——Hadoop的输入来自文件。并用文件来存储中间结果。因此对于每一次Map-Reduce。其性能都取决于文件I/O。

2) 无共享——每一个节点都全然拥有自己的本地资源(CPU、DRAM、本地SSD、本地HDD),并全然依赖于本地资源。除非是通过分布式文件系统(HDFS)请求远端数据的情况。

因此,Hadoop对于其最初的设计目标而言过于理想,即採用一群廉价的机器来并行处理很庞大的数据文件。并以批处理的模式将结果信息浓缩到小得多的文件里。

而今,我们在微软、Yahoo和Facebook的友人揭示了一些惊人的统计数据:除非你是在进行全网规模的keyword索引,否则大数据通常根本就不那么“大”(能存放到个人笔记本电脑上)!

还能够非常方便地切割成小块进行消化处理(也就是说,不要对一整年的历史记录进行数据挖掘。而是按天来做处理)。

a) 微软和Yahoo的中等大小的Map-Reduce文件仅仅有14GB。

b) 90%的Facebook Map-Reduce任务小于100GB。

绝大多数这些分析任务能够放在单个server的主存储其中。假设有某种方式能够共享单个机架中server的存储。可能有99%的任务都能够就此完毕。那么我们还有必要去捣腾文件么?何必还费事去把HDD升级成SSD?不论什么软件project师都会讲:要是我的所有数据都能存放在主存储其中….那我的速度就能快上100倍!

眼下这个梦想正在变为现实。我在BBS版块上发贴时,正看见“Spark峰会——4月19日。北京——100倍于Hadoop的大数据分析”的闪动宣传条幅。

Spark改变了什么,能号称比Hadoop快上100倍呢?

a) 存储内数据分析——能够不再须要通过文件系统和磁盘IO来訪问数据,对多次反复处理很有利(Map却无需Reduce)

b) 无共享——数据共享还是由远端节点提出并予以满足的一项业务请求

看来。光是去除HDFS就带来了100倍的提升?那么,假设硬件同意节点之间直接共享存储中的数据结构呢?是否能带来额外的100倍提升?

就此,再进一步和大家分享一下硬件架构师有关大数据的梦想:

a) 构建带有快速互联的机架

b) 在机架里堆放一组CPU(CPU池)

c) 添加共享的DRAM以及/或者非易失性存储池

d) 以及共享的SSD/HDDs池

关于这一梦想。我们PMC“P星人”为其冠名为FDIO。Intel 称之为RSA;Facebook以此为OpenCompute的未来。Baidu则命名为天蝎3.0。通过它。全世界99%的大数据问题或许都能在单个机架之内得到处理。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: