面對每一種酷斃的新技術(shù)，人們很容易過于迷戀其中，開始把它用在不當?shù)牡胤健１热缯f：從頭到尾瀏覽數(shù)百億條記錄，從中找出幾百萬條標以一組標準的記錄，這是MapReduce或你最喜歡實施的有向無環(huán)圖(DAG，想一想Spark)相當愚蠢的一種用法。

對于諸如此類的任務(wù)，別忘了那項最初的大數(shù)據(jù)技術(shù)：搜索。借助像Solr、Lucidworks和Elasticsearch這些出色的開源工具，你就有了一種有效的方法來優(yōu)化輸入/輸出，并實現(xiàn)用戶體驗個性化。這么做的效果比使用花哨的新工具不當好得多。

Spark不擅長的

不久前，有個客戶問我如何使用Spark對他們流式傳輸?shù)絅oSQL數(shù)據(jù)庫的數(shù)據(jù)進行搜索。問題在于，該客戶的使用模式是簡單的字符串搜索和向下鉆取(drill-down)。這超出了數(shù)據(jù)庫高效處理的能力：他們將不得不從存儲系統(tǒng)獲取所有數(shù)據(jù)，然后在內(nèi)存中加以分析。就算擁有DAG，在AWS上也有點慢(更不用說成本高昂了)。

如果你可以把一個定義的數(shù)據(jù)集放入內(nèi)存，Spark是很出色。Spark并不擅長獲取全世界的數(shù)據(jù)，一方面在于在內(nèi)存中，數(shù)據(jù)分析的效果完全取決于你將所有數(shù)據(jù)傳輸?shù)絻?nèi)存以及購買這種內(nèi)存的能力。我們?nèi)孕枰紤]存儲，考慮如何組織管理存儲，以便能夠迅速、利落地獲得我們所需的數(shù)據(jù)。

對于這個特定的客戶而言，答案就是為進入的數(shù)據(jù)編制索引，然后拉回數(shù)據(jù)子集，用于更高級的機器學習，但是將搜索任務(wù)交給搜索索引。

搜索vs機器學習

搜索、機器學習和某些相關(guān)技術(shù)之間并不存在清晰的界線。很顯然，文本或語言信息往往強烈地表明這是搜索問題。數(shù)字、二進制或其性質(zhì)根本不是文本或語言的信息表明這是機器學習(或其他)問題。是存在重疊。甚至在一些情況下，任何一種方法都可以使用，比如異常檢測。

一個關(guān)鍵問題是，你從存儲系統(tǒng)檢索數(shù)據(jù)時能不能選擇合適的數(shù)據(jù)，以此作為你的一個標準，而不是非得處理大量數(shù)據(jù)。對于文本或定義的數(shù)字數(shù)據(jù)而言，這可能很簡單。同樣，人們用于異常檢測的那種類型的規(guī)則可能同樣很適合搜索。

當然，這種方法有其局限性。如果你不知道自己在找什么數(shù)據(jù)，又無法輕而易舉地定義規(guī)則，那么很顯然搜索并不是合適的工具。

搜索+大數(shù)據(jù)

在許多情況下，結(jié)合使用搜索和Spark或你最喜歡的機器庫可能是秘訣。我之前談?wù)撨^將搜索添加到Hadoop的方法，不過也有將Spark、Hadoop或機器學習添加到搜索的方法。

Spark方面明朗化之后，使用它的人認識到，它并不是什么靈丹妙藥，內(nèi)存中處理起來確實存在大問題。至于你可以索引的數(shù)據(jù)，能夠迅速拉回工作集來分析，遠比使用又大又粗的輸入/輸出、拉入到內(nèi)存中找到你要找的數(shù)據(jù)好得多。

搜索和上下文

但是，搜索不僅僅是你如何解決“找到我的工作集”、內(nèi)存或輸入/輸出問題。大多數(shù)大數(shù)據(jù)項目的軟肋之一在于缺乏上下文。我之前從安全方面談?wù)撨^這個話題，但是用戶體驗方面又如何?雖然你流式傳輸你能找到的關(guān)于用戶的每一個數(shù)據(jù)，但是如何處理這些數(shù)據(jù)，以便實現(xiàn)用戶體驗個性化?

使用你對用戶了解的信息(即信號)，就能改善放到用戶面前的信息。這可能意味著，你在向用戶展示結(jié)果或個性化網(wǎng)頁時，在用戶交互的前端使用流式分析，而在后端使用分面搜索(faceted search)。

搜索解決方案

作為一名數(shù)據(jù)架構(gòu)師、工程師、開發(fā)者或科學家，你需要的不僅僅是工具庫中的一兩種工具。我對于這種方法很惱火：“讓我們存儲一個很大的blog，希望得到***的結(jié)果，同時每當我們使用它，就要花錢搜尋。”一些廠商實際上似乎支持這種方法。

使用索引和搜索技術(shù)，你就能構(gòu)成一個更好的工作集。你還可以避免實施基于你的數(shù)據(jù)流，為提供給用戶的數(shù)據(jù)實現(xiàn)個性化。搜索很好，請使用它。