對(duì)大數(shù)據(jù)來講最主要的是在模型中做計(jì)算的約束是非常大的。我們看BSP模型，為什么在過去用到高性能計(jì)算上，今天在大數(shù)據(jù)不能用。之后再做并行計(jì)算，之后再做篡數(shù)，過去做的所有的高性能計(jì)算都是圍繞這個(gè)模型來的。

如果我們有了硬件、有了軟件，22年前它就總結(jié)了高性能計(jì)算，它畫了一個(gè)圈，我們所有的努力都在這里面。

BSP模型有數(shù)據(jù)嗎？因?yàn)楦咝阅苡?jì)算數(shù)據(jù)并不是重要的，主要是以計(jì)算為主的。大數(shù)據(jù)更不在里面了。今天做大數(shù)據(jù)計(jì)算的時(shí)候，是不能與硬件相關(guān)的我不能說找到英特爾說要造一個(gè)大數(shù)據(jù)。

所以我們現(xiàn)在用的。我們的模型是今天高性能計(jì)算是不能保證的。
   

今天為什么要做并行計(jì)算，并行計(jì)算給我們帶來了什么樣的障礙？scale-out是什么概念？張曉東認(rèn)為給大家舉一個(gè)例子，2008年的時(shí)候Google用processed算法計(jì)算一個(gè)PB的計(jì)算量，用了1個(gè)小時(shí)2分鐘。2011年10PB的數(shù)據(jù)用了6小時(shí)27分鐘。我們比較要有非常高的并行度。我們?cè)诟卟⑿卸认旅嬗龅降牡谝粋€(gè)困難是，沒有特殊的通信硬件來給我們支持。這不像高性能計(jì)算。第二Hadoop的模型非常簡(jiǎn)單。第三，沒有軟件的工具來幫助我們做。另外，當(dāng)你放下了數(shù)據(jù)以后是不能傳輸?shù)?，基本上是不能?dòng)的。今天這個(gè)會(huì)議是為了Hadoop。我們對(duì)引擎本身是沒有抱怨的，問題是如何利用引擎處理大數(shù)據(jù)。如果我們只永遠(yuǎn)是的引擎只能做簡(jiǎn)單的分析。這個(gè)引擎有非常好的優(yōu)點(diǎn)，第一它的dependency是非常小的。另外一個(gè)工作是非常簡(jiǎn)單的。我們必須要有高可用性的大數(shù)據(jù)。
   
如果一個(gè)數(shù)據(jù)在做負(fù)載的時(shí)候，我們要注意，如果用不好也是費(fèi)用很高的。看到了當(dāng)application，你想做一個(gè)的話，現(xiàn)在的是不支持的。如果是在不同的系統(tǒng)上，他們兩個(gè)想做一個(gè)communication也是不支持的。

第二個(gè)問題，如果一個(gè)使用者想換個(gè)思路。如果你有一個(gè)MP可以直接翻譯過去，通過機(jī)器提高了各種各樣的計(jì)算。人在實(shí)際中用手來寫是不一樣的，75%是又機(jī)器來生成的。他在做項(xiàng)目的時(shí)候可以節(jié)省4倍的時(shí)間。

最后一個(gè)問題，在現(xiàn)有的Hadoop沒有給你任何的信息，用戶是不知道的，你怎么放進(jìn)去的時(shí)候取這個(gè)數(shù)據(jù)的時(shí)候要非常地低。你做這樣的設(shè)計(jì)是不是也改變了Hadoop的引擎。最后我們發(fā)現(xiàn)考了三個(gè)方面都是很基本的話，那么也是它廣泛應(yīng)用的原因。他們現(xiàn)在在整個(gè)的關(guān)鍵信息在什么地方？從Facebook的角度來講，這個(gè)是一個(gè)Hadoop，用它的時(shí)候第一要存到高的數(shù)據(jù)中，如果一個(gè)用戶首先用的是YSmart做示范。一個(gè)Hadoop是一個(gè)大數(shù)據(jù)中心的引擎。本身它就可以做分析，我們一個(gè)引擎只能完成一個(gè)轉(zhuǎn)的操作問題是我們?nèi)绾螌⒁孀钤嫉膭?dòng)力化為今天的支撐。因?yàn)槲覀兿嘈臜adoop是一個(gè)引擎并且起了很重要的作用。
 

renxinbo