陳超：我是負責(zé)大數(shù)據(jù)這一塊的負責(zé)人我叫陳超，可能大家對我社區(qū)的ID比較熟悉，我們這次是數(shù)據(jù)為峰，引領(lǐng)技術(shù)先鋒。我的名字是大數(shù)據(jù)生態(tài)的概覽，由于時間的原因，我會在我覺得比較重要的地方，會多講一些，可能大家不是那么關(guān)注的地方我可能會跳過，但是我希望能把需要講的都給大家介紹一下。
在大數(shù)據(jù)這一塊，我們最主要的基礎(chǔ)就是我們分布式文件系統(tǒng)，我們的HDFS大家都已經(jīng)熟悉了，下面Tachyon，它也是一個文件系統(tǒng)，只不過它是基于內(nèi)存的一個文件，它由出品，引用了以后，可以把數(shù)據(jù)全部存在里面，直接從內(nèi)存出去，讓你的效率成倍提高，有些人想說，內(nèi)存丟失了怎么辦，事實上面，現(xiàn)在業(yè)內(nèi)幾乎所有基于內(nèi)存的文件系統(tǒng)，幾乎都有。在我們Tachyon可以放入數(shù)據(jù)，是到你用的時候才有。
在分布式計算這一塊，我們最早接受的批量計算，大家用的最多是MapReduce，效率比較低。我在2003年的時候在國內(nèi)推廣Spark2004年慢慢大規(guī)模采用，Spark基于內(nèi)存的基本框架，但是大家現(xiàn)在對Spark有一個誤解，完全基于內(nèi)存，事實上不是，它做了很多改變。另外它還做了一些額外的優(yōu)化，來保證我們更好的數(shù)據(jù)穩(wěn)定性。第三個Flink，現(xiàn)場有多少人知道這個框架，它跟Spark的定位是比較像的，它們都希望走的是爐子，跟Spark有興趣的朋友，我們可以會下單獨討論。
接下來，我相信大家對第四個，Impala更熟悉一些，但是它有去編譯，做了一些代碼生成提高效率。事實上面，在Facebook也做了一個類似的，它對知識是非常好的。另外方面，還支持查一些，你可以認為它是一個插電的設(shè)施，你有什么都可以查，只要有數(shù)據(jù)，原始數(shù)據(jù)確實在某個地方，也可以查。這一塊，我相信這邊也有不少人在用，首先它使用非常方便速度也比較快，另一方面，更關(guān)鍵的一點，它已經(jīng)從不同的框架里面來學(xué)習(xí)很多的優(yōu)點，吸收進來，所以說大家這邊如果有人學(xué)習(xí)的話，或者想用的話，我建議你們可以從Spark SQL入手，以后大家不會獲得原始行業(yè)進行一個計算，而是說，我們對它進行一個控制，明顯我能做更多的優(yōu)化。Drill這塊我就不展開講。
流式計算，這一塊大家非常熟悉，我想提醒一下，你用個的延時在幾秒左右，很多人拿這個說事，數(shù)據(jù)出來再到我們Spark Streaming已經(jīng)有不少飲飭了，所以在處理上面，給你帶來并不是特別大的事。當(dāng)然如果延時真的非常重要，我必須要考量，那你可以用。還有一個好處就是說，它可以用你的批量計算和時時計算，做批量的時候，你使用，你用換成其他代碼都是這樣的都不用動，所以說也非常方便。只不過它是一個完全基于設(shè)置的方向，它的思路是我的就是為它設(shè)計的，但是，它認為，批量計算只是時時計算的特例，這是一個思路。
其實雅虎出的比較早，代碼更新也非常慢，對它表現(xiàn)尊敬，出來也比較早，它主要是針對于，既然已經(jīng)成為事實上的標(biāo)準，那用的人，在國內(nèi)并不是特別多，如果你們有興趣并且說你們也是的話，我建議你們可以去看一下。
數(shù)據(jù)收集這塊，是這樣子，F(xiàn)lume用得比較多。第二個Flunetd做了很多類似于統(tǒng)一的數(shù)據(jù)平臺，消息平臺，它可以支持不同的一些插電化的接口，但是這塊，前兩年還可以，這兩天，至少在國內(nèi)交流起來并沒有特別多。Sqoop是一個很尷尬的處境，它的愿景很美好，類似觀點，但事實上面，大多數(shù)的公司，自己更喜歡從去重寫這樣一套的框架。Scribe不多講，你也可以跟Sqoop比較。有一個事我不知道有沒有公布，用語言，重新寫了一套，性能提升了很多，有一天有一篇文章介紹，如果你們用了這套框架，可以查一下文章。Camus一個用法是，用到我們這上面去是非常方便的。
我說了Kafka是一個概念，概念也非常簡單，中間是數(shù)據(jù)，多數(shù)據(jù)可以讓數(shù)據(jù)進行處理，概念比較簡單。在介紹的時候，也介紹了，本身是一個優(yōu)秀的框架，但它可以支持概念，我這邊不多介紹，有興趣可以看一下。最下面NSQ是一個比較酷的，以前講的時候，看不到，這種玩意?，F(xiàn)在混的比較多了，總要去看看這個，但是如果對這個比較感興趣的話，可以去看看，如果NSQ比較好玩的話，可以聯(lián)系我。我們這邊有很多空間有NSQ。
我們在兩年前的標(biāo)準，就是Mahout，我不知道有沒有人民關(guān)注我的微信賬號，去年4月份，我也寫了，Mahout已經(jīng)停止接受任何新的算法，投到上去。我現(xiàn)在主要用的是，里面的算法也比較豐富，并且我們有新的，是一個非?？岬臇|西。大大簡化你從數(shù)據(jù)進來，到我們整個流程結(jié)束。畢竟它也結(jié)合了一些理念在里面。PredictionIO是基于我們的服務(wù)器。最后一個scikit learn朋友們非常了解，scikit learn本身用的也非常清楚。
圖處理，我先重點講一下第一個和最后一個，我認為到現(xiàn)在為止有三個產(chǎn)品非常重要，或者其他一些挖掘，事實上有三個可以看得了，整個網(wǎng)絡(luò)非常復(fù)雜，節(jié)點非常多，我要找任意兩個節(jié)點的最短路徑，第三個我認為也是目前用得最多的。大家想一下，你們這邊咱們會場里面有這么多人，如果說微博我關(guān)注了你，我到你那邊指向了，你你關(guān)注了我可以指向我，想想看如果我們這些互相關(guān)注的人里面，是不是三角形越多，我們社區(qū)就越緊密，三角形越少我們社區(qū)就越松散。我關(guān)注你你關(guān)注我，還是一樣的。像我剛剛講的三個場景，都需要一個領(lǐng)導(dǎo)力，所以我認為一個優(yōu)秀的框架不需要讓大家，我認為應(yīng)該幫你搞定。
最后一個你可以把邊、點存在那里，非常簡單。如果說你有圖需求，可以看一下。MongoDB我不講了。Redis也不講了，微博非常好用。對比一下我相信這里面肯定有這個的支持者，所以我前端時間參加回答問題的時候，也是冒著很大的風(fēng)險，萬一得罪了也不好。所以說看自己的品位，是一個P2P的構(gòu)造。你們不要去過于執(zhí)著兩者的區(qū)別上面，他們的數(shù)據(jù)都是基于。你可以認為最后是一個，其實是一樣的，沒有大家想的差別那么大。
NewSQL不知道這里面有多少人了解曾經(jīng)開源過，被某一個公司收購了，直接就再也看不到了。公司大多數(shù)人都在用它的手機、蘋果。所以說現(xiàn)在注意力就轉(zhuǎn)移了，它不讓我玩，我不能就坐以待斃我得找一個新的替代品。所以在國內(nèi)我更喜歡小強DB，打不死的DB。現(xiàn)在還有一個比較酷的產(chǎn)品叫做HyperDex，大家了解也非常少，也可以去看一下。
搜索這塊，是這樣，Lucene這不需要講，這本身沒有什么對錯。ElasticSearch現(xiàn)在生態(tài)圈，支持會更多一些。到搜索、到展示都是一體化的。所以說你讓我個人建議，我會建議用ElasticSearch。
OLAP，大家沒有看到，支持超高圍度。它才開展兩、三個月，還是有些問題，用的過程中，還自己去避免。Zeppelin，在業(yè)內(nèi)上面寫一段，下面把結(jié)果呈現(xiàn)出來，包括圖表。
數(shù)據(jù)可視化，這些就看前端你們更喜歡哪個。
容器在大數(shù)據(jù)領(lǐng)域也避不開這個話題，現(xiàn)在在做Spark，我指的是容器，在座大多數(shù)朋友也需要去關(guān)注一下容器市場。它可能會對我們架構(gòu)方式個思維方式有一定的改變。
調(diào)度不多講，Mesos、YARN、Sparrow，不展開，你們對調(diào)度參考一下Sparrow。
幕后英雄，ZooKeeper，第一想法上這個，沒什么好講的。Praquet存得更少拿得更快。
Lambda架構(gòu)就是這樣，把它們兩個數(shù)據(jù)結(jié)合起來去訪問。
這個是我整個PPT最重要的一頁，其他不多講了，謝謝各位！
