大數據教父Micheal Stonebraker告訴你大數據的秘密

jopen 8年前發布 | 35K 次閱讀大數據 SQL

——第十七屆“二十一世紀的計算”學術研討會

圖靈獎得主 Micheal Stonebraker 的主題演講

今天，我要跟大家談談大數據。大數據這個詞其實是一些做營銷的人發明的，大概是幾年前的事情。然后我也非常高興，我終于知道過去四十年自己到底在做什么，我原來是在做大數據。所以我想跟大家談談大數據對于我來說意味著什么，以及我認為的大數據中什么是重要的。

關于大數據，很多人說意味著三件事情，這三個單詞都是以字母 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 和非死book 也有類似的項目。那么， 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 年與其他人合作寫了一篇名叫 "Through the 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 最近作為 SQL Server 14 的一部分捆綁推出，它就是新 SQL 的另一個實現。所以說，提升在目前來看是可能的，只要你不要使用那些三、四十年前的老系統。

接下來我要說的是數據流速快的問題。這個問題要么是流處理問題，要么就是高性能交易問題。對于高性能交易問題，已經開始有速度很快的實現了。但我認為，這里面的關鍵是如何讓交易高速進行。在這方面我們有很多的想法，未來也有很大的改善空間。

Big Variety 數據來源多樣性

好了，還有最后 9 分鐘，我來談談多樣性的問題。像聯邦快遞這樣的典型企業一般會有 5000 個運營數據系統。聯邦快遞現在有一個數據倉庫。但其中只有幾個系統的數據納入到了這個數據倉庫當中。也就是說，這個典型的數據倉庫只從 10 到 20 個系統那里收集數據。那么其余剩下的 4980 個系統該怎么辦呢？像 Verizon 這樣的大型電信公司擁有 10 萬個運營系統。大企業要有許多運營系統，主要是因為他們分成了許多獨立的業務部門，以便于業務的開展。而獨立的業務部門會產生大量的獨立數據。所以在大企業的內部有許多運營系統。當然，這其中還包括電子表格、網頁、數據庫等等。而且每個人都想從互聯網獲得天氣信息，也要從各種公共數據源獲取數據。所以他們需要擴展性，將大量運營數據系統進行整合。那么該怎么做呢？

在過去，市場的傳統做法是提取、轉換、載入數據， ETF 系統就是這樣的。比如 Data Stage 或 Informatics ，如果你聽說過的話，他們就是做這個的大廠商。那具體怎么做呢？首先是提前創建一個全局模式。讓你們當中最聰明的人去研究這個全局模式應該是怎樣的。創建完成后，針對每一個你想要納入到該全局模式的本地化數據源，派一名程序員去咨詢數據系統的所有者，了解數據源中包含了什么內容，然后將這些內容映射到全局模式當中，再編寫一個數據轉換腳本，最后確定如何清理并刪除數據源中的重復數據。如果有 20 個數據源的話，應該沒問題。但由于這種做法需要提前創建一個全局模式，如果數據源太多的話就不好做了。你也需要一個受訓良好的程序員去單獨處理每個數據源，其中涉及了太多的人力。如今的 ETL 人員在賣一種叫做“主數據管理”的產品。它其實只是一個新的術語，指的就是上面那種做法。這時候已經無法再擴展了。而且，現在有許多企業不只想整合 20 個數據源這么簡單，他們想要整合 1000 個或 3000 個數據源。比如做團購優惠券的網站 Groupon ，他們正在建立一個全球小企業數據庫，這些企業就是他們的客戶。為此他們需要整合 1 萬個數據源。所以他們實際上是以 1 萬倍的規模去處理這個問題。而 ETL 根本不可能完成這個任務。這就是對系統可擴展性的巨大需求，傳統的廠商無法解決這個問題。所以我認為，在這個關鍵的領域我們需要有新的想法，需要去做研究，看看怎么去解決這個問題。

我加入過一家名為 Data Tamer 的初創公司，待會我會在另一張幻燈片里面說明。他們有一種比較好的方式去做這種規模的數據。另外還有許多類似的初創企業，例如由來自 Berkeley 的 Joe Hellerstein 創立的 Trifacta 。他們關注于每個數據科學家，注重數據策管問題。他們非常關心非程序員、可視化以及每個數據科學家的需求。但不管怎樣，我都認為這是一個亟需創新想法的領域。

那么 Data Tamer 究竟是做什么的呢？他們是做數據策管的，對我來說，數據策管就是要在原處攝取數據，然后將數據轉換為某種不同的表示形式，例如歐元轉換為美元，或人民幣轉換為美元等。然后還要進行數據清理。基本上任何數據源都會有 10% 到 20% 的錯誤率。有些情況下人們會拼錯人名或公司名字等等。然后你必須將多個數據源放到一起，對它們的屬性進行映射對比。比如說你有一組員工的數據集。我也有一組員工數據集。你稱之為薪金。我稱之為工資。你填滿了一行數據。然后發現有重復的數據，于是你要進行數據整合。數據策管就是這樣的概念。在過去，數據策管的成本非常之高，是普通人無法逾越的大山。但如果你想做數據科學，你就必須翻過這座大山，完成所有的數據整理和勘誤工作。如果使用傳統的技術去做這項工作，所需的費用非常高。而且傳統技術無法擴展。所以說這是一個很大的問題。那么 Data Tamer 究竟是做什么的呢？

我借用 Peter Lee 演講稿里面的一段話。他們在統計學上應用機器學習，讓機器找出那些我們無法找到的東西。這類似于將掛在低處的蘋果全部摘掉。然后在需要人類幫助時，你必須去找這個領域的專家。你不能去問程序員。因為 ETL 的程序員不知道怎么解答這方面的問題。比如說 Data Tamer 有一個客戶是 Novartis ，是一家非常大的醫藥公司。他們對基因數據應用這項技術。 ICE50 和 ICU50 是兩個基因術語。他們是一樣的東西嗎？是否其中一個是另一個的筆誤？他們是兩個不同的基因術語嗎？程序員對此一無所知。你必須去問基因領域的專家。 Tamer 有一個專家搜索系統。當需要人類回答問題時，比如說創建培訓數據，你必須去問這個領域的專家。你不能去問程序員。這樣才能獲得巨大的投資回報。這種方式比起使用傳統技術要省錢。這是解決數據源多樣性問題的一個可行方法。但我的建議是，這一點非常重要。如果你想研究這個問題，你必須去找一個真實的用戶，例如阿里巴巴或華為。去拜訪真實的用戶，找出他們的數據策管問題在哪里，然后解決這個問題。因為在現實世界中，很多人都會先寫一個算法，然后再想這個算法在現實世界中究竟好不好用。我覺得這個順序反了。你應該先找出現實世界的數據，然后再修復這些數據。好了，時間不多了。但我剛才說了，我會談一談數據湖。

Hadoop 廠商現在的想法是，將所有數據放入一個基于 HDFS 的數據湖中，這樣就萬事大吉了。也就是說，將所有原始數據放入 HDFS ，這就是他們所說的數據湖。注意這只是數據策管所攝取的數據塊。其余部分才是難點所在，你還必須解決這些難點。所以，如果你采用 Hadoop 廠商的建議，將所有原始數據放入 HDFS 當中，你并非創建一個數據湖，而只是創建了一個數據沼澤。然后你必須進行數據策管，才能創建出一個可供你使用的數據湖。所以說，數據湖只是一個新的營銷術語，它指的是數據策管所攝取的數據塊。

總結：工欲善其事，必先利其器

最后總結一下，如果你想做大數據，想做 SQL 分析，你應該采用列存儲。如果你想做智能分析，最好不要用過時的產品。我強烈建議你使用數組存儲。但可能也會有其他解決方案。如果你遇到數據速度的問題，你需要找一個流處理產品，或高性能的 OLTP 系統，這取決于你手頭上有什么資源。 NoSQL 人員目前提供了一種不錯的上手體驗。他們的產品容易使用，而且他們正在轉向 SQL 。但你的公司現在已經有了大量類似的產品。一些遺留的廠商實現仍將存在，它們不會完全過時，但會逐漸被這些新技術所取代。與此同時，你仍然需要用到這些舊的技術。然后，你將擁有一個或多個數據策管系統，它們能夠最大限度地解決數據源多樣性方面的可擴展性問題。所以，你公司內部的堆棧中將產生大量的數據。最后我的建議是：“工欲善其事，必先利其器”。謝謝大家！