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

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

Spark不擅長的

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

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

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

搜索vs機器學習

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

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

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

搜索+大數據

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

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

搜索和上下文

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

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

搜索解決方案

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

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