Nikita Shamgunov先生一生都在不斷地建立各種各樣的數據庫，8年時間在Facebook公司等建立了很多的數據庫，現在他在舊金山建立了一個下一代的分析的數據庫叫MemSQL。

他表示對于數據分析師來說現在的時代是一個很有意思的時代，首先Moore時代已經結束了，我們看到很多的速度是放緩了，但是摩爾定律依然可使用于大數據，數據每18個月翻一番，而且需要更多的技術允許我們來操作這么多的數據。Hadoop就是一個很好的技術幫助我們操作海量的數據。另外一個所發生的情況是十年前談到大數據的時候讓人非常地乏味?，F在有各種各樣的數據，有存儲數據、形象數據、JS數據和結構的數據。

關系型數據庫經常會出現問題。同時數據是成功的關鍵，如果我們看一下世界上最成功的公司比如說谷歌、Facebook、亞馬遜所有的這些公司都非常癡迷于數據，無論現在做什么，每個人五年之后可能都不再那么具有競爭性和競爭力了?他談及了數據的時效性，即是最近所搜集的數據會比一年前所搜集的數據更具有價值。Nikita在Facebook公司的時候也創造了很大的集群，當設置的時間是19天，19天之后人們所搜集的Hadoop的數據就沒有了，因為再沒有可用性了。所以Facebook很快改變了代碼，因為老的數據沒有用了，失去了相關性。所以這取決于你所處理的是哪種類型的數據。

實際上你所獲得的價值速度是很快的。我今天談的是半衰期很短的數據。處理這些數據的情境、實時的數據是什么樣的情境?也就是變化很快的數據。這可能會有一些業績上的評估。這是Facebook做的，每周二是重要的一天，我們會做這個工作，然后想捕獲所有關鍵的標準，在Facebook的網站上、潛在的趨勢，我們把整個Facebook的網站分成不同的功能，之后我們會測量每個功能所帶來的消耗量，可以很好地想象到Facebook是很知名的網站。所以把這些數據放入數據庫的時候是需要非常大的數據庫的。因此我們有一個數據庫可以把所有的數據都容納起來。

可是如果不管哪個地方發生變化你都是希望了解到的，比如說你有一個bug的話，整個的數據庫都會出現問題，這樣的情況下Facebook就會損失和 虧損。所以如果出現問題一定要快速的解決，同時找到哪個地方發生了問題。像ZYNGA這樣的公司有很多的網游他們會對數據進行實時追蹤，還有AB測試。比 如說你想運行各種各樣的測試看一下自己的網絡以及網絡上的廣告到底做得怎么樣，是不是有一些廣告比其他的廣告效果要好。這樣可以根據點擊率來進行計算。越 早發現哪個廣告表現越好，這樣你的錢就可以從廣告中得到更多的錢，因為不會浪費時間。但有一點很有趣，如果有實時的高效率系統，在CPU的應用上會很快地 用起來，因為機器是有學習能，所以你會很快地培訓機器的模型。所以說如果你的數據量比較小的話，可以把它放到一個比較小的領域，如果說是大數據的話可能這 個時候需要用Hadoop來進行處理了。所以得需要集群的方式來做數據處理。 有的時候用了Hadoop之后的速度會提到幾千倍或者是更快，因此你的速度會更快了。

再看一下，有越來越多的數據密集型實時的情況越來越多。比如說航空的飛機票和酒店的費用，如果你想到一個網站上購買機票，每次做搜索的時候只花5秒 鐘的時間就可以找到搜索的結果。如果要是給出一個更低的時間更減少的話效益就更高了，但這需要不斷的培訓或者說加強改善優化。比如說在股票交易上可以了解 之后進行追蹤看核心的數據和核心的衡量機制以及數據的遷移。有的時候數據量是非常大的，尤其是在股票交易上，有時候達到每秒6億運行，在紐交所有這樣的 量。所以我們都希望我們的速度更快，這一點是大家都希望的，尤其是當你有大數據技術來處理技術的時候，你希望它的處理會更快。

我們談到Latency的時候有兩種，一種是搜索或者是查詢Latency，你查詢了以后再回來這叫查詢的，但對數據Latency指的是時間差， 產出時間之后把它放入大數據系統中我們稱之為數據上的Latency。數據Latency只能在24小時之內處理。所以，上傳數據的時候等你喝咖啡回來之 后數據還沒有上來，再喝咖啡，之后等到了以后就可以分析數據了。對查詢的Latency來說要花很長的時間才能運行。所以說解決方案是什么呢?我們有大量 的研究來解決這個問題，尤其是在Hadoop的平臺上。所以有一個Storm，這個技術非常好，可以把這個數據通過節點來計算，這個數據在進入系統中的時 候就開始計算了。Storm有時候不會存儲數據只是計算數據，所以可以把它放到Hadoop。

另外還有Cloudera Impala，這是以前的系統允許你可以實時地處理Hadoop數據和HPC數據。另外他還提到了MemSQL，一個分布式的in-memory的數據庫，可以在成千上萬的節點上運行。

實際上它是能夠處理并分析全球最具有挑戰性的工作量的，主要是處理兩件事，第一是數據的Latency，它可以直接地用SQL來處理，同時我們也可 以進行任何時候的查詢，利用所有的核和處理器以及集群中的所有的節點來處理。所以怎么來處理數據上出現的Latency我們可以提供超快速的數據負荷，可 以把數據上載到系統中通過多個電腦、多個終端、多個節點，這樣在集群里面可以把數據完全地引入系統中。同時它也可以使你能實時地插入數據，不需要有一個特 殊的批上載，可以任何時候可以把數據直接地放入系統中。

另外對查詢的Latency來說我們有優化器，也就是說大家如果處理NPP系統，一旦查詢出現在系統中就可以看一下把它分解成次查詢，之后在這個階 段集群的節點中處理最后給你一個最終的答案。我我對工程師或者是在座的特別喜歡技術的我會告訴你它是怎么做的，我們有一個Lock-free data，一個電腦上有很多核，可以允許我讀寫但不對數據鎖定。所以如果一方面需要上載數據，另外一方面也需要上載查詢的話，這樣的結構可以很好地處理數 據。另外這個系統是分布的架構，這個架構是由集群器等的，這是存儲數據的地方，這個集存器有一個電腦的節點，用戶可以訪問集群器中間的部 分，Aggregator可以共享信息，比如說數據是怎樣分析的?？梢灾荒艿匮刂濣c來分布。另外可以通過節點來復制，之后處理之后再把信息反饋給用戶。 看起來就像一個數據庫一樣，有耐用性同時也可以復制。你可以關掉并且開放之后數據還是在數據庫里面。

再看一下復制性，高獲取性是非常重要，因此我們有兩個中心來進行復制。第二，在一個數據中心里也有安全性的數據的復制，所以你可以有各種各樣的數 據，有的時候有一些節點出現了問題這時候會有復制和副本出現，這樣不會出現數據的損失。還有是Facebook對我們產生很大的影響，就是SQL到C++ 編碼的生成，使得執行起來的速度非?？?。我們把SQL的聲明轉變成C++的編碼。如果在做的時候要考慮到例子，我們把它拿出來之后加上就可以形成SQL到 C++的編碼轉換。當然在進入不同的系統的時候可以在很短的時間進行實施和執行，這樣會使我們同時來進行很多的數據處理或者是查詢處理。

接下來我給大家做一個展示，因為DEMO總會讓大家看到真實的東西。每次做DEMO的時候有一些意外的情況還是比較有趣的。在這個DEMO中我給大 家看一下這32個節點還有8個Aggregator，之后我們把整個的程序從8個節點中泵入。這個集群是半個小時之前啟動的，也就是我進入這個會議廳之前 的半個小時，所以在系統中應該有一些數據了，之后會發出一些非常復雜的查詢之后看一下它是怎么表現的。接下來再看一下，這應該是48個集群，我是在亞馬遜 EC2上部署的，由于有公共云所以計算起來很簡單，你只需要編程之后點擊輸入，現在84個集群就可以開始運行了。這個集群的總內存是2.7TB，所以可以 把2.7TB的數據泵入，在系統中任何的記錄都會在很短的時間里處理完。好，接下來我們看一下。這是一個終端的窗口，這有一些數據我們看系統中是怎樣的， 在這兒有數據庫的協議，在做發言之前我們已經做了，已經有幾個表格了，看起來還不錯運行正常。所以，這里面都有很多的記錄。這有一個表格，這個表中間顯示 一下數字，把數據插入，在兩個查詢之間有這么一個數據輸入了。這實際上是占用CPU的，在集群的每個節點上都是占用CPU的。集群上的每個節點、每個核都 在工作。所以目前還沒有什么意外，我們最終看到有26億的記錄。因此可以看到速度是非?？於伊渴欠浅４蟮?。所以可以把東西進行修改和修訂。

我們有一個客戶，每天要輸入10億個記錄，而且同時還可以對數據進行匯總監測一下網站怎么樣。但是雖說它是非常簡單的查詢都可以，比如說用一些簡單 的索引或者說把數據存儲在某些地方我在這里還有其他的幾個查詢，這是其他的一些查詢。這里有一個匯總，有一點是必須有趣的，也就是你有一種直覺，可以看到 數據在整個的集群中布置的話是可以復制的，你選擇了之后就可以對它進行復制。在這兒我就把數據推到客戶這邊，所以數據運行得非?？?。最后看到這兒可以運行 一些非常復雜的東西，這些就是查詢的例子，基本上是數據庫的查詢，這是一個很大的查詢，我可以運行查詢程度一個客戶，有各種各樣的節點。但基本的一點是， 它是一個生態系統，可以表達復雜的東西，可以表達復雜的集合，大量的數據中可以有很重要的變化，這是一個重要的視角。

給大家一個信息是每個工作都需要的工具，如果你需要進行分析目前市場上可用的最好的技術就是這個。但是在大數據中有很多的情境，有非常不多的數據運 行的特點可能我覺得工程師需要像拿一個瑞士軍刀這樣的組合，對每個工具選擇適合的工具，SQL就是這樣的一個工具，對高速度的工具進行很好的處理，因為可 以大大地提高運行的效率，對數據的快速變化來說有很好的處理。