未來，當我們構(gòu)建金融大數(shù)據(jù)庫時，真正構(gòu)建出來是以云的方式提供服務(wù)，換句話說要選擇一個基礎(chǔ)的云。從IBM來講是IBM SOFTLAYER，對大家來說是選擇本地的，選擇華為、浪潮、百度都可以，取決于IaaS這個層面怎么處理。接下來有若干的分析型中間件、存儲等等，包括后來還有一大堆數(shù)據(jù)管理起來，要選擇合適的存儲方式，接下來再選擇下面的東西。
這里涉及的東西很多，跟中間件和數(shù)據(jù)關(guān)系，虛機、虛擬化的環(huán)境等等都相關(guān)。要處理金融型的東西，比如證監(jiān)會能夠以消息的方式傳給你，每5秒鐘傳來一組數(shù)據(jù)，這組數(shù)據(jù)包含過去5秒鐘在上交所發(fā)生的交易的數(shù)量，誰下了多少單？或者大批次的怎么樣的情況？收到了這個數(shù)據(jù)，如果沒有合理的一套系統(tǒng)去把它存起來，假如丟了，可系統(tǒng)又不知道，在后續(xù)使用系統(tǒng)分析時就會有大問題。這筆數(shù)據(jù)看不到，在做一個重要決策的時候，這筆很可能是非常關(guān)鍵的。系統(tǒng)不僅僅得考慮隨便拿一個數(shù)據(jù)放進去就可以，要考慮這個數(shù)據(jù)放上去是不是能夠不丟，考慮在分布式環(huán)境下面有備份、有副本的時候，副本之間是完全一致的。再上面才是要構(gòu)建的Systems of engagement，或者是Insight這些應(yīng)用，當你建造這么大的數(shù)據(jù)庫的時候，未來的應(yīng)用要往哪方面走？
以上談的是從數(shù)據(jù)角度談未來的發(fā)展，講洞察體系是未來的一個方向。之后是從云的角度來看，需要支持Systems of Insight，它的數(shù)據(jù)工作的模式和Systems of engagement并非完全一樣，所以未來需要的方向是朝著更多地使用內(nèi)存，更多地使用CPU發(fā)展。CPU很便宜，當數(shù)據(jù)量大的時候，可以用壓縮，傳統(tǒng)壓縮以后，發(fā)現(xiàn)解壓很困難、很痛苦?，F(xiàn)在新的做法，把傳統(tǒng)的數(shù)據(jù)全都壓縮，壓縮完了把它提到云里，在內(nèi)存的集群里面進行解壓，或者把它進行加密，加密后提到內(nèi)存里進行解。因為CPU現(xiàn)在變得非常便宜，用CPU的代價替換掉存儲的代價。
回過頭來，為什么現(xiàn)在這么在意細節(jié)的這些點？說到底是構(gòu)建的這個系統(tǒng)的投入產(chǎn)出是不是合理。如果投入產(chǎn)出不合理，很快就會垮臺。這個里面到最后的結(jié)果，之所以有這么一個趨勢存在，這些都會逐漸變得很經(jīng)濟實用，而且從使用者角度來講，傳統(tǒng)的交易提交后，銀行保證說你只要提交這個錢不會丟，交易結(jié)束你不會在意它返還回來的東西?，F(xiàn)在給你發(fā)一個微信，我期望你馬上就能回復(fù)我，這個互動的趨勢是非常頻繁的，尤其當在全球化的范圍之內(nèi)，和美國、歐洲的人在開一個什么會的時候，實時交易的消息系統(tǒng)，希望看到馬上能夠起來，馬上起來就得快。如果在這種情形下每個數(shù)據(jù)都要到硬盤上面讀，哪怕到Flash上面讀都是很慢的。這時大量使用內(nèi)存是非常重要的。
Delivery。傳統(tǒng)Delivery的方式，用一個平臺開發(fā)應(yīng)用，可以花一年時間開發(fā)這個應(yīng)用，一年后上線。這個過程如果出了問題可以回頭再修改新的版本，而且這個通常是找?guī)着_機器部署在機器里面，凡是有內(nèi)網(wǎng)相連的都可以使用，里面會有用戶控制等。但如果跟Facebook或百度比，會發(fā)現(xiàn)這樣一種模式每過若干天可能就有一個新的小版本出來了，后臺的人再做，小版本Delivery之后會做一些非常小的修改，這個修改可能把原來的東西弄壞了但沒關(guān)系。傳統(tǒng)上，做了一套系統(tǒng)得安裝到機器上，現(xiàn)在都不需要了，APP是自動的，更新也是，非常簡潔。在這種模式下，傳統(tǒng)的方式如果天天去做，就會出現(xiàn)一些大問題。所以目前大家方向是說，Delivery的模式最好像百度這樣的模式，有一個開發(fā)的環(huán)境和生存的環(huán)境基本是在同一個地方，這種模式，這種模式對大家來說也會同樣存在。開發(fā)一個數(shù)據(jù)庫，分析應(yīng)用在上面構(gòu)建，最開始是簡單的查詢，接下來要分析，再就是更深入的分析，再有更深入的應(yīng)用在上面建造起來。開發(fā)人員工作的環(huán)境、生產(chǎn)環(huán)境是在哪里呢？它的更新的版本、更新的周期是在哪里？這個必須要考慮到，如果不考慮的話未來走這一步的時候會走不下去的。
Data Lake是一個新的概念。十年前就說海量數(shù)據(jù)了，從英文來講沒有海量數(shù)據(jù)這個詞，對中國來說數(shù)據(jù)量大了這就是海量。
Data Lake是我們經(jīng)常講，外面有很多人也經(jīng)常講。但是他講的時候，把所有東西都放在Hadoop里面。IBM講的時候，你有很多東西是放在Hadoop里面，你有很多是放在選擇關(guān)系數(shù)據(jù)庫里面的，你有很多東西是放在你選擇的Graph數(shù)據(jù)庫里面，你還有一些東西是選擇直接放在文件系統(tǒng)，放在Object Store里面。所以有很多不同的東西，不同的技術(shù)它適合處理存儲、分析等等特定的類型的數(shù)據(jù)，不是所有的數(shù)據(jù)都可以用Hadoop搞定，這時就會面對一個情況，有很多不同的數(shù)據(jù)“庫”，來之前我把這個“庫”去掉了。數(shù)據(jù)庫是非常固化的概念，里面有亂七八糟的東西，英文里面有相關(guān)的詞匯，中文也有很多相關(guān)方面的詞，只是行業(yè)里面目前還沒有刻意的把它提取出來。有這么一些數(shù)據(jù)存儲的地方，不同的技術(shù)實現(xiàn)的，當堆積在一起的時候，如果沒有很好的機制管理起來，好比現(xiàn)在要構(gòu)建的大數(shù)據(jù)庫，一部分是交易數(shù)據(jù)，關(guān)于股票的，這里面一定會有股票的號碼，交易的量等等，至少股票號碼本身是哪一支股是在的，但是誰參與交易是不在這里面的，如果在里面也是脫敏過的。但是這些數(shù)據(jù)拿過來，你最好存放的地方是在關(guān)系型數(shù)據(jù)庫里面，但是要放在Hadoop里面是不是可以的，是可以的，在上面可以構(gòu)建新的查詢數(shù)據(jù)，目標是要根據(jù)某個具體條件拿到某個股或者某一些股的具體信息，所以要有SQL查詢會非常的好。但是在網(wǎng)上收了很多關(guān)于這家公司的URL，這些URL是不是也要放到，如果僅僅是URL本身放到關(guān)系數(shù)據(jù)庫里面沒有問題，但是如果這個URL里面的內(nèi)容也把它扒過來，那這個時候扒過來的東西放到哪里？還放到關(guān)系數(shù)據(jù)庫嗎？假如里面有大量的文檔、大量的圖片，還放在關(guān)系數(shù)據(jù)庫就不同意了，放在Hadoop里面是不是合適呢？也不一定完全合適，這時不得不考慮別的技術(shù)進來。換句話說，你是沒有辦法的，必須要很多很多數(shù)據(jù)的存儲技術(shù)、管理技術(shù)合在一起。然后當合在一起后會發(fā)現(xiàn)，這些數(shù)據(jù)來源不一樣，它們生成的方式不一樣，時間段不一樣、頻度不一樣。在這個過程中間，你會發(fā)現(xiàn)，要從交易數(shù)據(jù)庫里面去找到相關(guān)的資料，得做很多思考才可能找到關(guān)鍵的地方進行差選，之后才能拿回來，對于一個分析數(shù)據(jù)大量手工在里面，效率低也易出錯。于是不得不把這些數(shù)據(jù)之間的關(guān)聯(lián)以某種形式把它們組織起來。數(shù)據(jù)湖很重要的是，能不能有一個數(shù)據(jù)的目錄。這個目錄是以這家公司為組織的目錄，以交易量為組織的目錄，以發(fā)生時間為組織的目錄，以地點、形態(tài)，或者是以行業(yè)等等，所有這些組織的目錄要有，這個組織的目錄誰來構(gòu)建？就是在構(gòu)建數(shù)據(jù)湖的時候需要構(gòu)建出來的。