IBM分析事業部

IBM分析事業部是在過去一兩年間逐步成型的，成立後分成了若干個小部門，如AnalyticsPlatform、CLOUDDATASERVICES。非關係型NoSQL的資料庫中，Cloudant用的CouchDB就是CLOUDDATASERVICES其中之一。

三種模式

過去幾年，關於大公司企業的轉型比較多，被新的一些業務模式衝擊得很厲害，比如Social、mobile。也不諱言IBM目前也在轉型中，可能未來會有一種新的模式支援上述第二種狀況。軟體的能力提交主要有軟體製造商銷售PerpetualLicense模式，或者軟體製造商提供以雲端服務的模式。這兩個模式外很可能還會有第三種模式，就是由技術廠商提供技術，由使用者自己構造它的雲的服務。目前大家就是處在用開源和自己寫的狀態上。

 

再談INSIGHTCLOUDSERVICES。Watson很具體化到某一個具體的行業裡面，到了INSIGHTCLOUDSERVICES這個有可能是屬於類似跨決行業，比如和Weather。去年IBM收購了TheWeatherCompany。傳統上，IBM是不碰資料的，給出的都是技術。給出資料庫，資料放到庫裡面，跟IBM沒有關係，也不去碰。現在IBM一定要去碰資料了，有些資料拿不到，就需要合作，比如Twitter，IBM要與它協同協作。統計顯示，Weather這種資料每天的查詢量非常大。像這一類的資料，它對各行各業的業務的影響都很大，IBM還會持續地去關注。

目前來看，IBM是朝著跟雲合在一起，跟分析、認知合在一起的方向在發展，這是一個大的背景。

Awash是一個很特殊的詞，這個世界被浸泡在資料裡面。我們在用程式碼重新構造這個世界。如果把現在的程式設計師角色想得比較高大上一點的話，就相當於上帝指導下的一批重構世界的人。比如，我們原來面對面說話用耳朵就能夠聽了，現在用手機進行，手機中間構建的這個框架，是讓傳統當面做的事情可以遠端做到，甚至手機可以理解人的對話，當成一個能夠理解人的實體。實際一定程度上，我們是在重新構造這個世界——通過程式的方式、通過程式設計的方式、通過認知學習的方式構建世界。未來的走勢在IBM看來是一個認知的過程，最終所有服務必須經過認知的技術來實現的。

IBM在過去三十年間看到的大趨勢基本上都兌現了，有理由相信，現在看到的大趨勢也會兌現。至於什麼時候兌現，還需要時間來驗證。

在未來的世界，資料就是礦藏。當然資料是原始的礦，相當於原油。如果原油不經過煉製，人類是沒有辦法使用的。現在每天有大量的資料，包括構建金融大資料庫，每天的交易資料、網際網路上的資料，社交媒體上的資料等。目前很難直觀地找到這些資料的關聯，必須要通過一些手段。我們就把這些手段類比成原油的煉製，用化學手段把它分離出有價值的東西，這樣資料就可以驅動整個世界。

就這些所有的資料來看，用得比較多的這些資料，最重要的是資料增長快、非常巨大，種類繁多。就如剛才提到的Watsoncuratorforfinancedata，雖然拿到的資料是別人做的，但最重要的應用的目標是分析。拿到一堆資料，重要的是怎樣拿到裡面的價值。挖這個價值的時候需要大量地使用分析引擎、分析工具。就像在一個湖裡撈魚，你要用很好的工具，是用炸藥炸還是用網子撈？撈一些小魚還是大魚？這個過程中間必須要有針對性的處理。要點是說看到了這些資料，在一個大湖裡面，要把有價值的東西取出來才能支撐你的業務。假如跟京東談，最終的目標是它要使得你下單買東西，這是最主要的核心業務。它一切的分析工作都是圍繞著，怎麼讓一個個體能夠更方便、更快捷、更不過腦子地做決定買一個東西。我們知道買東西大部分都是衝動性購物對商家是最有利的，最終都是圍繞這個目標進行的。這裡對於分析的Insight，把資料之間的關聯找到，這是一個大的趨勢。

眾所周知，資料並不像我們以為的那樣整齊，找起來非常不方便。大家都以為谷歌查詢的數量很大，實際上Weather每天的查詢量更大。谷歌是一個大的搜尋公司，未來可能會提供很多分析性相關的東西，把很多東西都放在裡面，每天在全球查詢量是3.5billion，而Weather是15billion。它除了查詢天氣預報以外，傳統查天氣是查北京市的，溫度是多少，Weather裡面有一些細節的東西，在北京朝陽區的小片裡面那個大概的溫度是多少，中國這邊沒有做到，但在美國做到了。這裡要求對資料的分析功能，比起在谷歌那邊要嚴格得多、分析要精細一些，所以在這裡，支撐這15billion的查詢後面有分析引擎，目前我們正在把這個分析引擎往開放的框架中引。

資料生成資料的量是非常大的，包括做一次網購。你是用資料生成了一堆資料，看到那些所有的產品是資料，看到資料決定要買，它就再生成進一步的資料，然後這些資料再往後逐漸放大，真正要做分析的時候，這個資料已經到1000倍了。所以在討論金融大資料時，不要只看到拿到的某一部分資料。這些只是其中最初級的原始部分，真正需要的是到最後的結果。我們考慮構建的是從1到1000倍增長的資料來看未來的資料的服務，所以當構建的時候，要想到的是現有資料庫的1000倍以上，在分析過程中還會產生新的資料，可能對進一步分析有很大的價值。

中間分析的結果很重要。IBM最近在跟很多國內大資料相關的一些產業，比如交通。交通常用的有幾類資料，一個是手機信令。對交通來說，這些人在城市裡的移動，從哪個點到哪個點，意味著他們的居住地、工作地。這一類人在一個城市大家都從A到B，從C到D，互相交叉，對城市交通產生很大的需求，好的城市交通規劃應該是平衡的，首先你要知道這個平不平衡，你得了解這個人到底在哪裡，於是手機信令成為一個很好的點。拿到手機信令以後，它不是很準確，存在誤差。這種情況下要描述一個人一天的軌跡，其實是模糊的狀態。描述這個軌跡下來以後才能進行分析，描述完這個軌跡，首先是對這些軌跡的資料，分析結果的資料要存起來，以便於下一步分析使用。隨後描述這個人的軌跡、停留時間，再通過各種分析的手法，區別每個地點的型別和這個人的職業等資訊。這些資料要存起來。把原始資料通過擴散關聯的方式找出後面，後面分析結果還要再進一步的考慮。

傳統上，資料通常是資料來源到結果，目前大家用的比較多的是這種。人們更關注把資料放在哪兒，查詢找到它是什麼，這是基本的模式。像萬得那樣的服務，目前基本就是查詢，重要的是它使查詢變得簡潔，做一些預分析，誰和誰的關係是怎樣的，把預分析做死，把它固化在其系統裡面，固化在其系統裡面，就形成關聯的固化關係，這個資訊被儲存起來，所以在萬得的系統裡使用、查詢就很方便。找到它，尤其是它關於整個跟金融相關的元資料模型的時候是非常好的。但據說萬得的元資料模型是從Bloomberg學習來的，中文化並加入中國特色，給投資人提供很好的介面。據說目前90%的市場都是萬得的，這個領域以萬得為例來講，雖然它的創新並不大，但可以把這裡的東西做得很精細適用。

Systemsofengagement。傳統認為，資訊系統本質上是交易系統。把資料提交給後臺的資料庫，資料庫進行交易處理，永久性儲存起來，用可備份的方式使得這個資料不會丟失，這筆資料的交易就完成了。資料系統關心的是資料被永久儲存且不會消失，這部分叫SystemsofRecord。Record是記錄，是交易型的、記錄型的。

社交媒體、移動、雲服務不斷髮展，比較有代表性的就是微信和銀行。微信不僅是提交一個數據儲存，而是它有很多關係的產生，人和人之間、資料和人之間、人和系統之間、系統和系統之間都產生大量的資料，這些資料的儲存、管理、後臺的支撐、經常性的變化，它可能對交易的完整性不那麼在意。相對來說，發一條微信丟了再發一條，可是在銀行存一筆錢，銀行說丟了，大家肯定不幹。銀行對資料交易的完整性要求非常之高。這個就是產生了Systemsofengagement。

Systemsofengagement接下來是分析洞察。當你有各種SystemInsight，就是分析洞察，像構建的資料庫，當有大量的交易資訊，股票交易資訊和大量的社交媒體資訊，這就屬於SystemEngagement。這兩類資訊融在一起，找出之間的關聯，發現隱藏的關係，這個時候就到了SystemInsight。這是IBM和若干公司都非常一致的看法，這是一個基本的概念。這是傳統到現在到未來的變革。未來變革大量使用的就是分析引擎。

未來，當我們構建金融大資料庫時，真正構建出來是以雲的方式提供服務，換句話說要選擇一個基礎的雲。從IBM來講是IBMSOFTLAYER，對大家來說是選擇本地的，選擇華為、浪潮、百度都可以，取決於IaaS這個層面怎麼處理。接下來有若干的分析型中介軟體、儲存等等，包括後來還有一大堆資料管理起來，要選擇合適的儲存方式，接下來再選擇下面的東西。

這裡涉及的東西很多，跟中介軟體和資料關係，虛機、虛擬化的環境等等都相關。要處理金融型的東西，比如證監會能夠以訊息的方式傳給你，每5秒鐘傳來一組資料，這組資料包含過去5秒鐘在上交所發生的交易的數量，誰下了多少單？或者大批次的怎麼樣的情況？收到了這個資料，如果沒有合理的一套系統去把它存起來，假如丟了，可系統又不知道，在後續使用系統分析時就會有大問題。這筆資料看不到，在做一個重要決策的時候，這筆很可能是非常關鍵的。系統不僅僅得考慮隨便拿一個數據放進去就可以，要考慮這個資料放上去是不是能夠不丟，考慮在分散式環境下面有備份、有副本的時候，副本之間是完全一致的。再上面才是要構建的Systemsofengagement，或者是Insight這些應用，當你建造這麼大的資料庫的時候，未來的應用要往哪方面走？

以上談的是從資料角度談未來的發展，講洞察體系是未來的一個方向。之後是從雲的角度來看，需要支援SystemsofInsight，它的資料工作的模式和Systemsofengagement並非完全一樣，所以未來需要的方向是朝著更多地使用記憶體，更多地使用CPU發展。CPU很便宜，當資料量大的時候，可以用壓縮，傳統壓縮以後，發現解壓很困難、很痛苦。現在新的做法，把傳統的資料全都壓縮，壓縮完了把它提到雲裡，在記憶體的叢集裡面進行解壓，或者把它進行加密，加密後提到記憶體裡進行解。因為CPU現在變得非常便宜，用CPU的代價替換掉儲存的代價。

回過頭來，為什麼現在這麼在意細節的這些點？說到底是構建的這個系統的投入產出是不是合理。如果投入產出不合理，很快就會垮臺。這個裡面到最後的結果，之所以有這麼一個趨勢存在，這些都會逐漸變得很經濟實用，而且從使用者角度來講，傳統的交易提交後，銀行保證說你只要提交這個錢不會丟，交易結束你不會在意它返還回來的東西。現在給你發一個微信，我期望你馬上就能回覆我，這個互動的趨勢是非常頻繁的，尤其當在全球化的範圍之內，和美國、歐洲的人在開一個什麼會的時候，實時交易的訊息系統，希望看到馬上能夠起來，馬上起來就得快。如果在這種情形下每個資料都要到硬碟上面讀，哪怕到Flash上面讀都是很慢的。這時大量使用記憶體是非常重要的。

Delivery。傳統Delivery的方式，用一個平臺開發應用，可以花一年時間開發這個應用，一年後上線。這個過程如果出了問題可以回頭再修改新的版本，而且這個通常是找幾臺機器部署在機器裡面，凡是有內網相連的都可以使用，裡面會有使用者控制等。但如果跟Facebook或百度比，會發現這樣一種模式每過若干天可能就有一個新的小版本出來了，後臺的人再做，小版本Delivery之後會做一些非常小的修改，這個修改可能把原來的東西弄壞了但沒關係。傳統上，做了一套系統得安裝到機器上，現在都不需要了，APP是自動的，更新也是，非常簡潔。在這種模式下，傳統的方式如果天天去做，就會出現一些大問題。所以目前大家方向是說，Delivery的模式最好像百度這樣的模式，有一個開發的環境和生存的環境基本是在同一個地方，這種模式，這種模式對大家來說也會同樣存在。開發一個數據庫，分析應用在上面構建，最開始是簡單的查詢，接下來要分析，再就是更深入的分析，再有更深入的應用在上面建造起來。開發人員工作的環境、生產環境是在哪裡呢？它的更新的版本、更新的週期是在哪裡？這個必須要考慮到，如果不考慮的話未來走這一步的時候會走不下去的。

DataLake是一個新的概念。十年前就說海量資料了，從英文來講沒有海量資料這個詞，對中國來說資料量大了這就是海量。

DataLake是我們經常講，外面有很多人也經常講。但是他講的時候，把所有東西都放在Hadoop裡面。IBM講的時候，你有很多東西是放在Hadoop裡面，你有很多是放在選擇關係資料庫裡面的，你有很多東西是放在你選擇的Graph資料庫裡面，你還有一些東西是選擇直接放在檔案系統，放在ObjectStore裡面。所以有很多不同的東西，不同的技術它適合處理儲存、分析等等特定的型別的資料，不是所有的資料都可以用Hadoop搞定，這時就會面對一個情況，有很多不同的資料“庫”，來之前我把這個“庫”去掉了。資料庫是非常固化的概念，裡面有亂七八糟的東西，英文裡面有相關的詞彙，中文也有很多相關方面的詞，只是行業裡面目前還沒有刻意的把它提取出來。有這麼一些資料儲存的地方，不同的技術實現的，當堆積在一起的時候，如果沒有很好的機制管理起來，好比現在要構建的大資料庫，一部分是交易資料，關於股票的，這裡面一定會有股票的號碼，交易的量等等，至少股票號碼本身是哪一支股是在的，但是誰參與交易是不在這裡面的，如果在裡面也是脫敏過的。但是這些資料拿過來，你最好存放的地方是在關係型資料庫裡面，但是要放在Hadoop裡面是不是可以的，是可以的，在上面可以構建新的查詢資料，目標是要根據某個具體條件拿到某個股或者某一些股的具體資訊，所以要有SQL查詢會非常的好。但是在網上收了很多關於這家公司的URL，這些URL是不是也要放到，如果僅僅是URL本身放到關係資料庫裡面沒有問題，但是如果這個URL裡面的內容也把它扒過來，那這個時候扒過來的東西放到哪裡？還放到關係資料庫嗎？假如裡面有大量的文件、大量的圖片，還放在關係資料庫就不同意了，放在Hadoop裡面是不是合適呢？也不一定完全合適，這時不得不考慮別的技術進來。換句話說，你是沒有辦法的，必須要很多很多資料的儲存技術、管理技術合在一起。然後當合在一起後會發現，這些資料來源不一樣，它們生成的方式不一樣，時間段不一樣、頻度不一樣。在這個過程中間，你會發現，要從交易資料庫裡面去找到相關的資料，得做很多思考才可能找到關鍵的地方進行差選，之後才能拿回來，對於一個分析資料大量手工在裡面，效率低也易出錯。於是不得不把這些資料之間的關聯以某種形式把它們組織起來。資料湖很重要的是，能不能有一個數據的目錄。這個目錄是以這家公司為組織的目錄，以交易量為組織的目錄，以發生時間為組織的目錄，以地點、形態，或者是以行業等等，所有這些組織的目錄要有，這個組織的目錄誰來構建？就是在構建資料湖的時候需要構建出來的。

換句話說，要構建未來的東西不再是一個庫，可能是一個湖。湖裡必須要有方式，魚在哪裡、水草在哪裡，要不然的話這就是一個數據沼澤，雖然資料都在裡面，但是撈很痛苦，撈一把有蝦、有魚、有泥巴、有水草，還要再進行過濾分析。所以，DataLake是我們必須要面對的。

分析，是層層遞進的。從分析到報表，到指引，做預測、做決策，再到指導你的行動。認知的過程，建構在DataLake的基礎上，再做一些基本的分析，可能會做一些預測的分析，這個過程中間還有自學習的機制，從資料的生成大資料的被分析，到資料用來做預測、做推斷，到資料用來做決定，再到資料自我學習，這是完整的迴圈。

這樣描述的過程，會使人覺得這聽起來像是“人”的過程。從馮諾依曼體系產生到現在，大家追求的就是怎麼讓機器做得像人，但比人做得更快，AlphaGo就是比人做得更快，它的心理不受時間限制，人還會受到限制。

從系統角度來講，就具體的某些單向指標來說，以暴力方式構建的系統已經遠遠超過人了，但整體上還比不過人，尤其是感知、學習、預測、適應、模式識別等等。在語意之間能夠來回翻轉，這個層面還遠遠趕不上。目前的方向是朝著認知，朝向構建人腦的模式。人可能走100步它要走10億步。

再往下更復雜的，在構建一種關係的時候。股票、公司和投資方，和它的下家行業，以及它的競爭對手等，這麼複雜的一個關係，如果不構建出來，這樣的金融大資料的服務肯定只能提供一個查詢，不超過萬得。接下來，認知公司進來以後你就會OUT了。要把這個關係建立起來，因為這些關係是很動態的，常常在我們回溯的時候是找不到，因為按照行和列描述資料的方式無法做到。GraphDatabase可能是一個很好的模式，GraphDatabase可以描述清楚大量複雜的關係。

舉個例子，某些資料中的一條，大家看這麼幾個資料，每天的掃描影像個數120個Million，是中國的某一個客戶，這個數量相當於Facebook一天的資料量，它的照片量，我們認為只有像Facebook這樣的或者百度這樣的才有大資料，其實企業裡面很多都有。不用管它怎麼產生的。把它放到峰值上去，會發現它每秒鐘是10萬個影像，10萬個影像不僅僅是10萬個交易。每個影像它有若干的描述性的資料，每個影像還有相關的東西結合在一起。這10萬個影像對後臺來說有資料庫存起來，交易是10倍的。換句話說每秒鐘是100萬，這個資料是非常大的。Facebook現在的峰值更大一些，當時也就是10萬到50萬的樣子，現在可能能做到100萬。

換句話說，我們看到在金融領域的大資料，如果放到峰值的角度來考慮，一定是非常龐大的資料。為什麼要考慮峰值？傳統分析的時候就會聽到說一天多少資料。治水跟治資料是有很相通的地方，最近武漢的大水，武漢大水過來武漢市三年前有一個投資計劃投了130億，說能夠處理15個東湖水的量，如果當初我來稽核這個專案的時候，我會問這15個東湖水的數量是一天過來？還是一個月過來？還是在十分鐘過來？這是不一樣的，在資料層面，現在金融伺服器上來了，全國的散戶都來找你了，1億散戶投資人要來找你，你能夠處理嗎？你怎麼處理？這相當於說15個東湖的水在十秒鐘之內經過武漢，你能夠處理嗎？這是非常簡單的我們需要面對的資料的問題。你有這樣的資料在那兒的時候，每秒鐘10萬，相當於100萬的資料每秒鐘要處理的時候，底下的平臺通過什麼方式建造？買IBM主機沒問題，任意擴充套件。但是這個成本付不起。如果用最便宜的機器，最便宜的機器一臺肯定處理不了，就得是非常龐雜的叢集，這個叢集是分散式的，每臺機器都有可能失敗，雅虎每天的硬碟都有數千個壞掉，硬碟要壞掉資料只有一份肯定死了，怎麼處理底下的東西，歸根到最後，最終的總量，這個資料要存15年，最終總量就是100多個PB。以前講PB是非常大的數了，Hadoop講說我們能夠做PB的資料那是大資料了，可是你看看像這樣一個機構，它可以達到幾百個PB，如果存15年它的總量能夠到達1.3個Trillion，這是萬億級的資料。最近幾年我們跟客戶溝通，把他的資料用峰值的方式進行分析以後，我們發現，包括它的總量，所以你構建一個系統，有很多具體的細節需要去不斷地考慮，也有一些現成的技術處理這個事情，但是首先得對所面對的這個資料要有深入、充分的瞭解，你一定得知道峰值是什麼情況，兩頭的峰值，資料進來的峰值以及資料出去的峰值，資料進來的峰值就是說你的資料來源從哪裡過來，它每秒鐘大概在什麼時候達到峰值，有可能最大的峰值是什麼？資料出去是說你的使用者在你這兒查詢，在你這兒做分析，它大概的使用情況是什麼？所以這兩頭你都要搞的清楚，資料總量準備存多久，存15年以上，你的硬碟壽命只有3年，之後你的硬碟是不停的換，還是量不斷增加，硬碟不停的換，還是會把一些冷資料放到特殊的地方去，類似這些問題你都在這個過程中間要進行考慮。

這裡有一個數據，這是10%的增量，這是按照15%的增量，都到了萬億級別，所以我們當時在考慮解決這個問題的時候，可能跟你們在考慮解決你們問題的時候類似。這是其中一類的資料量，另外還有的資料量，就是到網上大量爬一些資料，跟某些特定使用者關係的一些資料爬回來，還有大量的報表等等，它是一個金融機構，也要爬回來，所以這樣的話就意味著，我們當時面對這些資料的型別跟你們今天面對的資料型別非常接近，這是為什麼拿這個例子來講的原因。
 

這是我們當時用來處理設計的目標，這裡面有幾個點想提醒一下。

一、資料規模。未來整個資料庫最終會有多大規模。這個規模設計的目標是到幾十萬億條規模設計的。100以上的PB，我們心目中的目標是按照EB這個級別來設計的，可以設想一下，如果一個節點10個硬碟，1個硬碟按照在2TB，可以看到這裡要有多少個節點，如果再乘以3，或者再乘以1.75，就可以算出來。這是每一個物理的節點上面會有多少個數據，這是每一個系統裡面對這些資料進行索引有多少個元資料。

二、頻寬規模。在峰值的時候需要多大的頻寬。

三、效能。每秒鐘100K，10萬到100多萬的級別，同時它的響應必須在10個毫秒以內。這個地方是說，支撐的共識使用者數幾百萬人，現在像騰訊都是幾十個Million，已經是非常高的人數了。

四、高可用、彈性擴充套件、長期儲存。一個數據能夠在底下存多久，所以這個是我們當時對剛才那個需求的一個總結。

五、容錯。這個系統必須是容錯的。價效比要足夠的低，如果成本太高了是沒人用的。

剛才談到，如果用低端的機器降低了成本，但錯誤率提升，錯誤可能發生在硬碟、機器、網路、機器和機器的互動上面。容錯是必須面對的一個重要方面。用低成本的裝置必須是容錯的，無論是使用現存的雲服務還是自己做，這一點都逃不掉。

NoSPOF，講容錯是說一個數據進來，不管哪個環節出了問題，系統都能夠自動地恢復，恢復是有度的，如果我存了三份，分別把三份存在不同的盤、不同的機器節點上面，在三個不同的機器分佈在不同盤上面，同時出錯的概率是非常低的，這裡面很重要的節點，當我這個系統，如果我把一個提交給你在系統的每一個層次裡面任何一層上面都不能只有一個單點來應對，在第一版的Hadoop上面就是一個單點，它的NameNode就是一個單點，二版的把它改變了Active/Passive，也會有一些問題，這個是說我這個節點死了，馬上再啟動另外一個節點，這中間對於規模比較大的，頻度比較高的應用，這個中間啟動切換的1秒鐘或者0.5秒鐘就有大量的資料傳上來，就可能丟失了。

Facebook曾經做過一個，把HBase做成Active/Active，它專門有一支團隊做這個事情，兩邊同時在寫，對底下的儲存層來說必須要處理，這兩邊同時寫和原來系統裡面寫是什麼關係，是不是需要注意到分散式過程中間的資料是不是能保持一致？這個是非常複雜的。

這幾個資料大家一定要看。一次尋盤要10個毫秒，換句話說，如果資料在盤上，當你的請求是要來查這個資料的時候，假如一次讀盤能把這個資料找到至少需要10個毫秒，這是什麼意思呢？10毫秒×100就是1秒，假如這個盤上有你要的資料，每秒鐘能夠支撐的尋盤就只有100個，假如你的共識的併發是在每秒鐘10萬的話，資料分佈在N個盤裡面才能支援每秒鐘10萬。設想一下，在這種情形下，如果所有的東西都在盤裡面是不是很困難，或者目前的盤是不是做不到。這個10毫秒還是說這個盤是空的，隨著盤的資料存的越來越多，每次到盤上去讀的，找到資料的可能性就越低。換句話說，有的時候高達10次讀盤找不到你的資料，可能要多15次、20次，為什麼呢？現在資料量都是幾個T的，管理這個資料的檔案系統會把其中一部分快取起來，不會全部快取起來，沒有快取起來就到盤上讀，讀的是傾向於某個地方存這個資料的地方，相關的質證是在10個地方，才能找到資料。這些基本的東西在你們考慮的時候一定要考慮進去。

考慮資料從備份到M/S、MM、2PC、Paxos，是說資料的一致性。也是谷歌的例子，這是經驗性別東西在裡面。一致性交易。這個一致性在Backups就是Weak，在Backups裡面沒有交易，比如你要做M/S裡面，你只能做到EventualConsistency，這是什麼意思呢？最終一致性。最初的問題來源是同時往三個地方寫了三份資料，這個三份資料之間是不是一致的我們不知道，需要通過一些特殊的方式來保證。往往這種情況下，構建新的資料時，傳統要等三個一致的時候才能回過去說資料完整的寫好了。現在可以是兩個一致，或者是一個寫進去，就可以知道資料寫進去不會丟了，等到那兩個再返還回來時再確定它是一致的。還有若干的細節，包括分散式的討論。

這裡很重要的問題，兩階段的提交肯定是強意志的，不管是M/S還是MM都是Eventual的，這裡就會出現一個問題，像經典的購物車的問題，它就有可能出現數據丟失、資料不一致的情況出現。很多做傳統資料庫的專家，他們去挑戰Amazon的老大，它們是最早做Eventual，在學術界提出Eventual最終一致性，就去挑戰這個，最終一致性到最後的結果就是最終不一致。當然大家可以互相爭論，這裡確實有一些學術問題值得討論，包括微軟把一堆分散式資料專家請到微軟研究院。但是你看他做出來的Azure效率高，效能也沒它好，儘管沒聽說它資料丟失，但整體上來說並不見得比Amazon做得更好。理論上可能很成功，實際操作過程上不一定會做得很好。大家有機會可以把這個東西記住，有很多有價值的東西。我們設計了一套系統基本上是在Paxos這個領域。

底下有很多細節的東西不說了。比如說Peer-to-peer，這是在Cluster裡要設計三個並列點的時候，從個人的角度來講，不希望是Master/Slave模式——它支援的是Eventual。在處理這個資料裡面的時候，我們希望是既有Eventual，同時也有強一致性。所以在這裡，我們就採用了Peer-to-peer的模式，而沒有采用Master/Slave模式。

Meta-data，這個挑戰更大，是結構化的資料。結構化資料最好的方式是放在關係資料庫裡面，這是最簡潔，非常成熟，很穩定等等，但是關係資料庫不能很好地ScaleOut，它在分散式的環境下面做得不太好，它要麼就是效率非常的低，要麼就是隻有單獨的一臺機器，所以這裡面有很多矛盾，我們採用特殊的方法對它處理。我們剛才提到每秒鐘100萬個影像，每個影像是有元資料描述的，意味著每秒存100萬影像的同時必須每秒存100萬條元資料存到我的資料庫裡面，目前沒有已知的資料庫可以cost-effectively處理這個事。

你那裡面分出來，可能能分出三類資料。一類是放到關係型資料庫裡面。一類是物件類的資料，包括你的圖片、網頁、文字、PDF檔案等等。還有一類就是，你把這個裡面的資料和這個裡面文字的部分提取出來變成索引的，就是現在大家比較熟悉的，跟搜尋引擎相關的一些東西。這三類資料，你們未來建構裡面肯定都會碰到，所有我們碰到的挑戰你們也可能會碰到，取決於看你底下選擇什麼樣子的平臺來實現。物件這邊，我們採用的是OpenstackSwift，來做ObjectStore，但是光用這個還不夠，我們還對小檔案進行了特殊的優化，你們可能也會碰到同樣的事情，你可能不需要去管Swift底下做了什麼，或者你用Amazon、華為的物件伺服器都可以，你要求它給你的指標都可以了，不做研究，也沒有必要走到下面。

小檔案的Optimizer，這是一個技術，我們物理盤構建的結構，當年IBM做硬體盤的時候用了很多成熟的技術，有很多創新在裡面，過去很多年我們還在這個硬碟上生活著，我們現在構造的大多數資料都在這硬碟上面，隨著資料量越來越大它有一個限制，只有一個讀頭，這個讀頭每秒鐘最多能處理100個讀或者是寫，這是它基本的限制，由於資料量增加限制越來越多效能就直線下降，要解決的問題是用特殊的方式做成平的，這樣你的盤在三年生命週期當中是保持一致的，我們做的這樣一個東西。

當要用關係資料做這件事情的時候，金融的資料，尤其是股票交易的資料過來，一定要保證它參照的，換句話說它必須是Atomic，不能讓它變成Eventual，Base在這個資料上面是不合適的。那些其他的資料是可以用Base來做的，但是在這個底層儲存上必須要做到Atomic，這種情況底下要保證至少存三份，才能保證足夠的冗餘來處理這件事。這邊可能也要用到ObjectStore，這是我們當時做的東西。

這是Facebook的例子，Facebook來用HBase做Messaging，然後它發現單機是不行的，一旦單點失敗了Facebook使用者和使用者之間、使用者和系統之間的互動就會失效，於是做成了雙機版，雙活的版，到目前我還沒有聽說進到Hadoop裡面去，它底下的物件是Haystack，Haystack有一篇很著名的論文，你們可以讀一下，裡面做了很多優化。

谷歌的Spanner。谷歌是很有意思的一家公司，已經金蟬脫殼了，換了一個名字。它在資料的層面，十幾年前它跟大家說SQL死了，大家應該用NoSQL，於是一大批人跟著它走，三年前它說SQL還是很有用的，於是大家就不知道怎麼辦了，十年前跟著你跑，跑了半天又繞回來，不是在忽悠我們吧？本質上SQL還是有用的，它做的F1&Spanner本質上就是實現全球的SQL，它把它叫第一個全球化的SQL，這個稍許誇大了一點，從使用上來講是第一個使用的，別的有一些內部的祕密沒有公開。它裡面很重要的一個東西，它的資料是通過Paxos來維護它的高一致性的，Paxos是很著名的演算法，大家有機會可以專門討論。它的Paxos是在全球的大資料中應用，我們知道，資料一致性裡面，分資料管理裡面很重要的難題，根本上我們是用一個時間，以這個時間緯度作為資料到來的先後順序決定資料的一致性，換句話說，當你有N個數據分析的時候，每個資料時鐘有些微差異的時候，當你達到毫秒級、微秒級、納秒級的時候，你的時鐘和時鐘之間的同步就變得異常重要，精度也變得異常重要，谷歌做這個的時候，每個資料中心上面要支一根天線接到GPS衛星，用GPS衛星時間來衡量先後，這是分散式問題的一個本質。谷歌未來會走成什麼樣子，這個不清楚，目前它們內部在使用這個事情。

資料湖裡面有很多，這後面有很多資料“庫”，中間有原始資料，有一個目錄，這邊有很多資料和IT之間的互動，這邊有很多讀的互動，底下還有很多資料治理，資料治理是說你的資料進來什麼人可以以什麼方式把資料存進來？什麼方式把資料提走？以什麼方式使用這些資料？尤其金融資料很敏感，你們構建這個的時候必須要考慮。

其他跟資料進來，資料怎麼清理，還有分析的工具有關，這是架構在資料之上的，這個概念知道以後，用什麼樣的資料和技術，大家可以來考慮。

這個是在架構資料庫中間，中間要用大量Cloud或者HybridCloud方式提供服務，使用者可以自服務的，構建一些UI功能讓他在介面上自己編輯，就可以編輯出很多應用出來。從描述性分析到診斷性分析到預測性分析，再到指導性分析。指導性分析它的意思有點開藥方一樣，我已經知道你得什麼病了，告訴你該吃藥了。這一類分析是我已經80%、90%的確定。這個走勢是這樣的，於是你作為關注這個走勢的這些人應該做這些事情。

最後一個是自學習，最終你構建的金融大資料中心裡面，是在若干個方面提供服務的，如果僅僅是玩票，可以在某些領域玩得深一點就可以了，這個沒有問題。

這是未來可能發生的，DataLake和HybridCloud。有的人構建了一個企業內部的資料湖，有的人構建雲中的資料湖。從使用者角度來講，既需要雲中的，也需要某些企業內部的。這兩者之間對於後臺管理來說是一個蠻大的挑戰。資料的擁有人不一樣，資料和資料之間的標準，互動的標準、描述的標準都不一樣，互相之間怎麼協調，是一個很大的挑戰。從IBM角度來講，我們是站在這兩個後面來看怎麼支撐未來的服務。

現在所有的東西基本都變成開源了，開源以後商家怎麼掙錢成為一個很大的問題。比方說我們原來賣軟體license的，現在不太好賣了，或者未來越來越賣不動。我賣服務，假如我是IBM，做了一堆服務，放到IBM的雲裡面，舉個例子，中國的銀行就不會把它的資料放到IBM的雲裡面，美國銀行可能會，這樣IBM未來的商業模式在哪裡？這也是我們正在探討的一些方向。

這個資料本身，大量的Self-Service是被資料分析師需要的。那些投資人對大家來說是資料分析師，用大家的資料是指導它進行投資。分析師需要一些工具，要把這些工具做得簡單方便，自己配置就能用了，你也可以說，你使用我，找一個數據分析師，專業的，幫你天天做，這個可以，有可能是一個人，有可能是個小的機器人，你們朝這個方向做，建議可以做個小的機器人助手，可以做自學習、分析。從投資角度來講，這個分析越全面投資越準確。資料分析人有一個很大的悖論，很特定的觀點，資料看得越多、越全面，就越能夠把握住相關的規律。從我們的角度來講，到最後的結果，社交媒體裡面的資料，相關的新聞報道、正式媒體裡面的資料，相關的監管機構的資料、交易資料等，對大家來說都是非常重要的。

IBM有個WatsonExplorer，本質來說從功能上現了大家做的資料集，但不是針對金融做的。不同的資料來源，不同的資料分析報表，有大量不同的結構化、非結構化的資料，通過自服務的形式提供出去，這是IBM自己做到的一些東西，但不是特定針對金融行業做的。