第十七屆“二十一世紀的計算”學術研討會
圖靈獎得主Micheal Stonebraker的主題演講
（微軟亞洲研究院主頁君小田熱心提示：搭配文中的視訊和PPT閱讀，效果更佳！PPT下載請點選：http://vdisk.weibo.com/s/z7VKRh2itilfs）
今天，我要跟大家談談大資料。大資料這個詞其實是一些做營銷的人發明的，大概是幾年前的事情。然後我也非常高興，我終於知道過去四十年自己到底在做什麼，我原來是在做大資料。所以我想跟大家談談大資料對於我來說意味著什麼，以及我認為的大資料中什麼是重要的。
關於大資料，很多人說意味著三件事情，這三個單詞都是以字母V開頭的。
大資料的問題，第一個就是量（volume）很大。第二個是這些資料的產生速度（velocity）太快了，軟體跟不上。第三個問題是資料來自許多不同的地方（variety），你需要進行資料整合，但這些資料來源太多了，你想要整合這些資料就非常困難。所以在這三個“V”領域你要解決的問題是完全不一樣的，我分別給大家談談。
Big Volume大量資料
在量方面，第一種情況是你要想做一些非常愚蠢的分析，比如說SQL分析。第二種情況是，你想要做非常複雜的分析。前者是比較簡單的，如果你想做SQL分析的話，我知道你可能要在上百個節點，PB的資料上面執行二十到三十個生產實現，日以繼夜地進行分析。在這些資料倉儲產品中，有幾款已經做得還不錯了。所以，這個市場的需求其實已經被一些商業軟體很好地解決了，比如說Vertica，就是這樣的一家資料倉儲公司。他們最大的使用者叫做Zynga。Zynga開發了一個名叫FarmVille的遊戲。Zynga會實時記錄全世界每一個使用者在玩他們的遊戲時每一次的點選，這樣的話就可以利用他們的資料做人工智慧研究，看看如何能夠讓全世界的使用者購買更多虛擬商品。所以，我認為這個問題已經得到了解決，因為現在即使你從使用者身上獲得大量的資料，他們也不會感到不快。但我要提醒一下大家，在過去十年裡，我們已經經歷了一個非常巨大的變化。
大約十年以前，如果你去和一些賣資料倉儲產品的公司聊的話，他們基本上賣的都是一種叫做“行儲存”（row storage）的產品，這是指儲存的下一個物件是同條記錄的下一個屬性。他們在磁碟上用行的方式儲存資料。SQL伺服器以前就是這樣的。
其他的資料倉儲公司都是賣這樣的產品。當時我成立的這家公司叫做Vertica。我們從另外一個角度來看待這件事情，把行轉90度，變成列，用列的方式儲存資料。
於是儲存的下一個物件就從同一條記錄的下一個屬性，轉變為下一條記錄的同一屬性。這種方式比原來的行儲存方式要快很多。Vertica完全顛覆了這個市場。它的速度比行儲存產品要快50到100倍。這是顛覆性的。
而這是由一家創業公司帶來的。所以我認為，在這個市場上實現顛覆的一種常見方式就是成立一家公司，然後去挑戰那些大公司，讓他們感受到威脅。所以在過去的十年裡，整個市場都開始轉而採用列儲存。其中包括微軟的資料倉儲產品PDW，也是用的列儲存，不過是10年後才用的。為什麼列儲存的速度要比行儲存快很多呢？當然，這背後有很深層次的技術原因，不過我現在沒有時間去詳細解釋了。廠商要取得成功，他們必須做出轉變。於是，基本上除了Oracle外，所有其他廠商都開始採用多節點列儲存的方式，它的速度非常快。在過去的十年裡，正是由於這種顛覆性的轉變，資料倉儲產品的效能提升了50倍。但是在我看來，這已經是明日黃花了，就像PeterLee所說的，人們現在感興趣的是機器學習，機器翻譯，資料聚類，預測模型，這些才是接下來要做的重要事情。
借用華爾街的說法，我們已經進入了“股市分析員”的時代。這些分析員其實與火箭科學家無異。如果你是一名從事資料庫工作的人員，當你仔細去看他們的演算法和他們的工作，你會發現，其實大部分的演算法都是採用陣列形式的線性代數，而不是表格形式的SQL。這與現實世界毫無關係。如果你再仔細看這些演算法的話，你會發現，其實大部分的演算法都是內迴圈迭代，也就是執行幾次諸如矩陣乘法、奇異值分解之類的線性代數運算。為了說明這一點，我來舉一個非常簡單的例子。
這個例子就是人們為之瘋狂的股票市場。股票市場有漲有跌。假設有兩隻股票——A和B，讓我們來看一下它們在過去五年所有交易日的收盤價。如果你想的話，可以假設這兩隻股票是華為和阿里巴巴的股票。如果你在做電子交易，你可能想知道這兩隻股票的收盤價是否有關聯，它們的時間序列是否有關聯。如果有關聯，那麼如果一隻股票漲了，你是否應該購買另一隻股票？所以你能做的最簡單的事情就是計算一下這兩個時間序列之間的協方差。具體的做法我已從我的統計課本那裡抄了下來——如果我沒有抄錯的話——就是幻燈片最下面的紅色字。這就是你想要計算的東西。
其實並不難。你在手機上也可以做這種計算。但現在，假設你要對紐約證交所的所有股票進行這樣的計算，有差不多四千只股票。五年的資料大約有一千個交易日。假設你有這樣一個紅色的矩陣，其中你有一隻股票的一千個收盤價，然後一共有四千只股票。我要做的就是要計算每一對股票之間的協方差。
那會是怎樣的呢？請允許我自由發揮一下，忽略掉那些常量減去他們的平均數。這就是紅色的矩陣，矩陣乘以它的轉置矩陣。也就是我們想要做的內迴圈。所以，大多數演算法最終都要應用於這種超大規模的運算。
理想的大資料使用者是當你解決了這個問題後，他馬上就會想要更多的訓練資料。你為華爾街的股市分析員解決了問題後，他又會想要為全世界所有的股票做這種計算，而不是僅僅紐約證交所上的股票。這就是你想要做的事情，不過不是在SQL中做，甚至不是在表格中定義的。所以我認為，對於一個資料科學家來說，他必須要對他的資料進行清理，去粗取精。這是他現在大部分時間所做的事情。
待會我在談到多樣性問題的時候會再說一下這一點。所以，資料科學家退休前所從事的工作就是資料管理和股票分析員的那種分析工作。而且你必須不斷重複去做這種工作。這就是資料科學家所做的事情。目前我們有一些商業分析師，他們在資料倉儲上執行SQL，所有這些都要被資料科學家所取代，在他們的資料上執行這種操作。那麼我們應如何滿足這種使用者需求呢？你要做的就是陣列分析。目前有大量的陣列計算。你可能會說，我有一些問題是在圖表上定義的，比如說社交網路這種問題。可是我認為，圖表其實只是一種稀疏陣列。它跟陣列是類似的。然後你還要進行資料管理，不斷重複這種操作，還要擴大規模。因為只要滿足了使用者的一個需求，他就會讓你去處理另一個更復雜的問題。這個問題可能涉及更多的核心、節點和超出記憶體的資料。這就是真正的大資料，也是問題所在。
那麼應該如何解決這個問題呢？如果你現在要做這樣的工作的話，你很可能會成為R、SaaS或Matlab等統計軟體的忠實使用者。
當然，你可以選擇R。但它基本上沒有資料管理能力，因為它是基於檔案系統的。你可以用R來進行大量的陣列分析，但它無法擴充套件，實現不了真正的資料管理。所以它只是解決了問題的一部分。或者我們可以使用Oracle。Oracle的擴充套件性也不是很好。但是先不管這一點。那麼你應該如何在一個關係型資料庫中做矩陣乘法呢？這樣做的效果並不是很好。你們當中可能有些人會覺得自己很聰明，於是嘗試在SQL中寫矩陣乘法程式碼，這是一種不錯的練習方法。這是可以做到的。它要求用表格去模擬陣列的表現形式，但它的速度真的很慢。而且在SQL中也很難去做奇異值分解。所以單就SQL來說，那是有問題的。
當然你可以說，如今大多數的系統都支援使用者自定義功能，所以我們可以將矩陣運算的程式碼編寫為使用者自定義功能。這種想法已經開始實現。使用者現在可以用R或C++語言編寫自定義功能。但是這種方式很彆扭，做起來難度也很大。所以這並不是一個很好的想法。那麼現在人們是怎麼做的呢？他們對此一籌莫展嗎？他們把資料放在一個關係型資料庫系統裡，在上面執行資料管理，將他們感興趣的東西拷貝到R或Matlab，然後在上面進行統計分析。
這是一個很糟糕的解決方案，因為你得學會兩種完全不同的系統。而且要在兩個系統當中來回拷貝。這樣做的結果是讓網路銷售商大賺了一筆。而且R還無法擴充套件。所以研究的挑戰就在於找出一種更好的方法。很明顯這就是人們現在每天所做的，也是資料科學家在實現世界中所面臨的挑戰。我們應該可以做得更好。我傾向於將它視為陣列問題來看待。這並不是表格問題。我們為什麼不能用陣列型資料庫系統呢？所以，跳出你的思維條框，擺脫那些表格，用陣列去取代它們。所以幾年前我寫了一個名叫SciDB的系統。它支援在SQL上使用陣列，內建有分析方法，對於矩陣乘法的計算速度非常快，而且與現在許多其他軟體一樣，它是基於開源的Linux系統開發的。你可以試著去SciDB.org尋找一個顛覆性的解決方案，看看結果如何。
之所以說陣列是一個理想的解決方案，是因為如果你將一個表格模擬為陣列，那麼你會得到一個維度為I和J的陣列，而且被賦予了值。如果你想得到一個4x4的矩陣，那麼它的左邊就是表格的模擬。
注意剛才已經明確指定了維度。然後有大量的資料。右邊是陣列表達。你可以完全壓縮掉這些維度。很多時候你想要得到該陣列的一個子集，例如地理子集。它在右邊可以很容易地定位。但在左邊就很難做到。所以陣列型資料庫系統具有一些先天的優勢。我認為從長期來說，這種技術將成為最終的贏者。現在我必須向大家坦白，Hadoop曾經存在很嚴重的問題。讓我們來看看2012年前後的Hadoop。
Hadoop是一個真正的三層堆疊。位於底層的是檔案系統HDFS。中間層是由谷歌寫的Map-Reduce。雅虎寫了一個開源的版本。然後在頂層有各種不同的高階系統——Hive、Pig、Hahout等等。這就是Hadoop在大約三年前出售的堆疊。他們發現，當你試圖讓實現世界的使用者使用該產品時，Map-Reduce並不是一個特別吸引人的分散式計算平臺，這其中有許多技術上的原因。所以它在分散式計算上是失敗了。另外，Map-Reduce也不是一個很好的資料管理平臺。將SQL放在Map-Reduce頂層導致效能慘不忍睹。所以說Map-Reduce無論是在資料管理還是在分散式計算上都基本算得上完敗。那麼是誰放棄了Map-Reduce呢？
谷歌在寫Map-Reduce的時候，是專門針對他們的Web搜尋資料庫寫的。他們在大概2001年就放棄了Map-Reduce。而Map-Reduce當時設計所針對的應用，谷歌在五年後也將之放棄了。他們後來為其他專案開發了Dremmel、F1等不同系統。Map-Reduce已淡出谷歌的視線，他們對之失去了興趣，不想進一步去開發了。Cloudera是Hadoop的一個主要供應商，他們也基本上放棄了Map-Reduce。所以他們的新SQL資料庫管理系統——Impala並不是建立在Map-Reduce上的。HortonWorks和Facebook也有類似的專案。那麼，Hadoop堆疊的未來究竟在哪裡呢？
它可以用作底部的檔案系統。但由於HDFS存在非常糟糕的效能問題，因此先要將這些問題解決掉才行。未來SQL將位於頂層，類似於Impala的系統。大家知道，資料倉儲形式的資料庫系統都要執行在HDFS之上。所以Hadoop市場內的資料倉儲市場將會完全融合。在商業分析上也存在同樣的情況。所以Hadoop在他們最新的營銷演講上提到了“資料湖”這個概念，待會我就會大概說一下。現在我想說的是，資料倉儲市場和Hadoop市場基本上是同一個市場。
那麼Spark表現得怎樣呢？Spark我認為很有意思。
Spark的存在是為了以快於Map-Reduce的速度進行分散式計算。現在大家都不想要Map-Reduce了，Spark的設計初衷是要解決一個沒有人願意解決的問題。所以出售Spark的商業公司Databricks很快就瞭解到，人們想要用SQL。現在，Spark有70%的訪問量來自於SparkSQL。
Spark就是一個SQL市場。但不幸的是，Spark壓根兒不是一個SQL引擎。它沒有事務，沒有持久度，也沒有索引。現在所有這些問題都將得到修復。所以SparkSQL可能會越來越像Impala，像商業資料倉儲實現。而且他們可能在資料倉儲市場上與Impala以及現有的一些資料倉儲廠商競爭。希望最好的系統能夠笑到最後。Spark的市場有30%是分散式計算，它的主要客戶是Scala。而且它的功能比Map-Reduce更強大。但是，Spark資料的RDD格式並不是所有人都喜聞樂見的，所以很快Databricks就嘗試採用一種R形式的資料結構——資料幀。因此Spark內部將發生翻天覆地的變化，請繫好你的安全帶。這是下一代的明星產品。但明年會怎樣誰都不知道。Spark的確有這樣的意向。而且幾乎可以肯定的是，它一定會進軍資料倉儲市場。我認為在商業智慧領域的分析市場，其實有很多系統都做得非常好。而且Spark和Hadoop也將會進軍這個市場，為它帶來更多的產品。但最大的難題在於如何在資料管理的中心進行可擴充套件的分析。如果你決定要在這方面開展某項工作，你必須先解決好這個大難題。
Big Velocity很快的處理速度
下面馬上就到高速這個話題。現在的商業市場規則不斷變化，這是個不錯的現象。物聯網正在通過感測器記錄下所有有意義的東西。例如戴在你腕上的小腕帶，它可以記錄下你的生命特徵。不管是賽跑中的馬拉松選手，還是為數眾多的野生鳥類和動物，都能一一記錄下來。這些人或動物會將他們的狀態或其他資料實時傳送給我們。這就帶來了海量的資料。我們都在使用智慧手機作為移動平臺，它傳送資料的速度也是相當的快。物聯網持續衝擊著人們原有的基礎設施——我們必須提速了。而在人們說要提速的時候，他們會遇到兩種不同的問題。第一種問題我將之稱為“大模式、小狀態”。
當你要做電子交易時，華爾街的工作人員會在海量的資料中尋找一個模式。比如先找一隻草莓，然後0.1秒後再找一條香蕉。這就是複雜事件處理（CEP）技術。另外也有一些商業系統，他們可以比較好地解決這個市場的需求。所以這並不是一個交易資料庫市場，而只是開啟一條消防水管，然後從噴出的水中尋找模式。我對第二種有關高速的問題更感興趣，我將之稱為“大狀態、小模式”。
假設有一家電子交易公司，他們目前的交易量佔紐約證交所總交易量的10%。他們在紐約、倫敦、東京以及北京這裡都設有電子交易專櫃。這些電子交易專櫃可以進行實時證券交易。這家公司的CEO想要確定自己相對於全球任一股票的價位。如果價位相對較高，那麼他可以說，我的風險太高了。然後按下應急按鈕來降低風險。也就是說，在風險高於一定水平的時候提醒我。注意這一次就不是在消防水管噴出的水中尋找模式了，而是確切地記錄下世界各地每一次交易的影響。這是資料庫中一個有關我當前全球位置的例子。此時哪怕你只是遺漏了一條訊息，你的資料庫也會變得毫無價值。所以你不能遺漏任何資料。一定不要遺漏任何資料。而且要非常快速、準確地記錄我的狀態。這看起來像是一個有關超高效能交易處理的問題。這是一個我非常有興趣去研究的領域。
要解決這個問題，你可以執行任何一個商業關係型資料庫系統，我將之稱為老SQL。所以你可以執行微軟的SQLserver。它就是其中一款老SQL大型應用。你也可以執行NoSQL系統。目前有75到100家廠商可以賣給你NoSQL系統。而且他們主張放棄SQL和ACID。另外還有第三種解決方案，我將之稱為新SQL，那就是保留SQL和ACID，但放棄老SQL廠商遺留下來的實現，以編寫體積更小、速度更快的實現。待會我會分別解釋這些方案。
現有的大型應用速度很慢。除了慢還是慢。如果你要在一秒內執行100萬個交易，那麼我勸你不必費勁在任何這些遺留實現上去嘗試這樣做。SQL是可以的，但它對交易的實現實在是太慢了。我在2007年與其他人合作寫了一篇名叫"Throughthe OLTP Looking Glass"的論文，上面明確解釋了為什麼老SQL無法在這樣一個市場當中高效能執行。如需更多詳情，大家可以看一下這篇文章。所以為什麼不使用NoSQL系統呢？
關於NoSQL我想說兩件事情。第一件是，如果你主張放棄SQL，那麼你就是主張使用低階的表示法，因為這是SQL編譯後的結果。不要將賭注壓在編譯器上。我雖然白頭髮很多，但是我還記得我在剛入行的時候那些“白頭”前輩對我說，你必須用IBM彙編器來寫程式碼。這是因為，除非你能夠控制機器上的所有暫存器，否則提速根本是不可能的。現在我們都知道這是多麼的可笑。不要將賭注壓在編譯器上。高階語言是可以的。但低階表示法就不好了。40年的資料庫研究教會大家這個道理。而NoSQL那些人還沒有完全明白這個道理。我們應該放棄ACID。遺留廠商的傳統交易實現實在是太慢了。真的。一種選擇是放棄它們，但我並不是很支援這種做法。這是因為，如果你想將100美元從這裡挪到那裡，你必須要有交易才能做到。例如，比特幣就是一個很好的例子，不少人因為NoSQL系統受到攻擊而損失了很多錢。所以說，如果你需要交易但又沒有好的交易系統，那麼你很容易就會被一些非常嚴重的漏洞陷入危險的境地。你所能做的就是對著使用者程式碼抓狂。
所以我的預測是這樣的，SQL和NoSQL系統之後會合並在一起。NoSQL是指2012年版本的NoSQL。然後NoSQL廠商的營銷人員就改口說，我們不僅有SQL，還有SQL的替代方案，對於那些需要用SQL做的事情，我們還有其他的解決方案。在我看來，現在NoSQL就是尚未使用SQL的意思。因為NoSQL廠商已經瞭解到高階語言的好處，所以便開始在他們系統的上層編寫高階語言。尤其是Mongodb和Cassandra，它們基本上都實現了看起來與SQL幾乎一樣的高階語言。所以說如今NoSQL陣營已開始轉向SQL。而SQL人員也在他們的引擎中加入JSON，這是NoSQL廠商的其中一項重要功能——JSON資料型別的靈活性。所以我認為這兩個市場將最終融合在一起，不使用SQL的引擎不再叫做NoSQL。它們都是SQL的一種實現，只是使用了不同於其他廠商的特性而已。我個人對新SQL是非常喜歡的，因為交易對每個人來說都是非常有用的。現在的問題是，老廠商的交易實現存在很多問題，它們的速度實在是太慢了。但這並不表示你無法將速度提起來。
例如，VoltDB是一款名叫“H-Store”的MIT系統的商業化版本，它比TPC-C上的老系統要快將近100倍。而且它的交易系統非常輕型，執行緒優化得很好。它是一款速度超快的主記憶體開源SQL引擎。微軟的資料庫系統——Hekaton最近作為SQLServer 14的一部分捆綁推出，它就是新SQL的另一個實現。所以說，提升在目前來看是可能的，只要你不要使用那些三、四十年前的老系統。
接下來我要說的是資料流速快的問題。這個問題要麼是流處理問題，要麼就是高效能交易問題。對於高效能交易問題，已經開始有速度很快的實現了。但我認為，這裡面的關鍵是如何讓交易高速進行。在這方面我們有很多的想法，未來也有很大的改善空間。
Big Variety資料來源多樣性
好了，還有最後9分鐘，我來談談多樣性的問題。像聯邦快遞這樣的典型企業一般會有5000個運營資料系統。聯邦快遞現在有一個資料倉儲。但其中只有幾個系統的資料納入到了這個資料倉儲當中。也就是說，這個典型的資料倉儲只從10到20個系統那裡收集資料。那麼其餘剩下的4980個系統該怎麼辦呢？像Verizon這樣的大型電信公司擁有10萬個運營系統。大企業要有許多運營系統，主要是因為他們分成了許多獨立的業務部門，以便於業務的開展。而獨立的業務部門會產生大量的獨立資料。所以在大企業的內部有許多運營系統。當然，這其中還包括電子表格、網頁、資料庫等等。而且每個人都想從網際網路獲得天氣資訊，也要從各種公共資料來源獲取資料。所以他們需要擴充套件性，將大量運營資料系統進行整合。那麼該怎麼做呢？
在過去，市場的傳統做法是提取、轉換、載入資料，ETF系統就是這樣的。比如DataStage或Informatics，如果你聽說過的話，他們就是做這個的大廠商。那具體怎麼做呢？首先是提前建立一個全域性模式。讓你們當中最聰明的人去研究這個全域性模式應該是怎樣的。建立完成後，針對每一個你想要納入到該全域性模式的本地化資料來源，派一名程式設計師去諮詢資料系統的所有者，瞭解資料來源中包含了什麼內容，然後將這些內容對映到全域性模式當中，再編寫一個資料轉換指令碼，最後確定如何清理並刪除資料來源中的重複資料。如果有20個資料來源的話，應該沒問題。但由於這種做法需要提前建立一個全域性模式，如果資料來源太多的話就不好做了。你也需要一個受訓良好的程式設計師去單獨處理每個資料來源，其中涉及了太多的人力。如今的ETL人員在賣一種叫做“主資料管理”的產品。它其實只是一個新的術語，指的就是上面那種做法。這時候已經無法再擴充套件了。而且，現在有許多企業不只想整合20個資料來源這麼簡單，他們想要整合1000個或3000個資料來源。比如做團購優惠券的網站Groupon，他們正在建立一個全球小企業資料庫，這些企業就是他們的客戶。為此他們需要整合1萬個資料來源。所以他們實際上是以1萬倍的規模去處理這個問題。而ETL根本不可能完成這個任務。這就是對系統可擴充套件性的巨大需求，傳統的廠商無法解決這個問題。所以我認為，在這個關鍵的領域我們需要有新的想法，需要去做研究，看看怎麼去解決這個問題。
我加入過一家名為Data Tamer的初創公司，待會我會在另一張幻燈片裡面說明。他們有一種比較好的方式去做這種規模的資料。另外還有許多類似的初創企業，例如由來自Berkeley的JoeHellerstein創立的Trifacta。他們關注於每個資料科學家，注重資料策管問題。他們非常關心非程式設計師、視覺化以及每個資料科學家的需求。但不管怎樣，我都認為這是一個亟需創新想法的領域。
那麼Data Tamer究竟是做什麼的呢？他們是做資料策管的，對我來說，資料策管就是要在原處攝取資料，然後將資料轉換為某種不同的表示形式，例如歐元轉換為美元，或人民幣轉換為美元等。然後還要進行資料清理。基本上任何資料來源都會有10%到20%的錯誤率。有些情況下人們會拼錯人名或公司名字等等。然後你必須將多個資料來源放到一起，對它們的屬性進行對映對比。比如說你有一組員工的資料集。我也有一組員工資料集。你稱之為薪金。我稱之為工資。你填滿了一行資料。然後發現有重複的資料，於是你要進行資料整合。資料策管就是這樣的概念。在過去，資料策管的成本非常之高，是普通人無法逾越的大山。但如果你想做資料科學，你就必須翻過這座大山，完成所有的資料整理和勘誤工作。如果使用傳統的技術去做這項工作，所需的費用非常高。而且傳統技術無法擴充套件。所以說這是一個很大的問題。那麼DataTamer究竟是做什麼的呢？
我借用Peter Lee演講稿裡面的一段話。他們在統計學上應用機器學習，讓機器找出那些我們無法找到的東西。這類似於將掛在低處的蘋果全部摘掉。然後在需要人類幫助時，你必須去找這個領域的專家。你不能去問程式設計師。因為ETL的程式設計師不知道怎麼解答這方面的問題。比如說DataTamer有一個客戶是Novartis，是一家非常大的醫藥公司。他們對基因資料應用這項技術。ICE50和ICU50是兩個基因術語。他們是一樣的東西嗎？是否其中一個是另一個的筆誤？他們是兩個不同的基因術語嗎？程式設計師對此一無所知。你必須去問基因領域的專家。Tamer有一個專家搜尋系統。當需要人類回答問題時，比如說建立培訓資料，你必須去問這個領域的專家。你不能去問程式設計師。這樣才能獲得巨大的投資回報。這種方式比起使用傳統技術要省錢。這是解決資料來源多樣性問題的一個可行方法。但我的建議是，這一點非常重要。如果你想研究這個問題，你必須去找一個真實的使用者，例如阿里巴巴或華為。去拜訪真實的使用者，找出他們的資料策管問題在哪裡，然後解決這個問題。因為在現實世界中，很多人都會先寫一個演算法，然後再想這個演算法在現實世界中究竟好不好用。我覺得這個順序反了。你應該先找出現實世界的資料，然後再修復這些資料。好了，時間不多了。但我剛才說了，我會談一談資料湖。
Hadoop廠商現在的想法是，將所有資料放入一個基於HDFS的資料湖中，這樣就萬事大吉了。也就是說，將所有原始資料放入HDFS，這就是他們所說的資料湖。注意這只是資料策管所攝取的資料塊。其餘部分才是難點所在，你還必須解決這些難點。所以，如果你採用Hadoop廠商的建議，將所有原始資料放入HDFS當中，你並非建立一個資料湖，而只是建立了一個資料沼澤。然後你必須進行資料策管，才能建立出一個可供你使用的資料湖。所以說，資料湖只是一個新的營銷術語，它指的是資料策管所攝取的資料塊。
總結：工欲善其事，必先利其器
最後總結一下，如果你想做大資料，想做SQL分析，你應該採用列儲存。如果你想做智慧分析，最好不要用過時的產品。我強烈建議你使用陣列儲存。但可能也會有其他解決方案。如果你遇到資料速度的問題，你需要找一個流處理產品，或高效能的OLTP系統，這取決於你手頭上有什麼資源。NoSQL人員目前提供了一種不錯的上手體驗。他們的產品容易使用，而且他們正在轉向SQL。但你的公司現在已經有了大量類似的產品。一些遺留的廠商實現仍將存在，它們不會完全過時，但會逐漸被這些新技術所取代。與此同時，你仍然需要用到這些舊的技術。然後，你將擁有一個或多個資料策管系統，它們能夠最大限度地解決資料來源多樣性方面的可擴充套件性問題。所以，你公司內部的堆疊中將產生大量的資料。最後我的建議是：“工欲善其事，必先利其器”。謝謝大家！
