盡量Hadoop、Spark和NoSQL數據庫此刻正成長的如火如荼，但請不要健忘搜索是最原始，最有用的大數據技能之一。跟著許多很是棒的開源東西好比Solr，Lucidworks以及Elasticsearch的呈現，你可以利用很是強大的要領優化I/O以及本性化用戶體驗，它會比以錯誤竣事的紛繁巨大的新東西要好得多。

Spark缺陷

不久前，一個客戶問我，如何利用spark查遍所有涌入NoSQL數據庫的大批量數據。問題在于，他們的搜索模式是單一的字符串搜索和向下查詢，這已經超出了數據庫的有效本領范疇。他們從存儲中拉取數據并在內存中理會。即便AWS上有DAG，但照舊很慢，更不消提昂貴的價值了。

當你在內存中處理懲罰意義明晰的數據集時，Spark照舊很有輔佐的，不只在于其強大的接收本領，更是因為其在內存中的闡明本領和轉移到內存中的本領一樣強大。我們仍然需要思量存儲而且要知道如何做才氣到達我們想要的快速簡捷的結果。對付某些客戶來說，數據進來之后大概會拉取出某個集適用于呆板進修，把搜索事情留給搜索引擎完成。

搜索與呆板進修

其實，在搜索，呆板進修和其他相關技能之間，不存在明明的邊界。顯然，文本或語言信息往往可以很強烈的反應出搜索問題，不管是數值型照舊二進制，非文本或語言都可以很自然的表白問題地址。在這方面，這些技能是重疊的。在某些方面，這些技能的處理懲罰方法甚至很雷同，好比異常檢測，任何一個技能都可以有效地辦理該問題。

要害的問題在于當你把部門內存作為尺度舉辦檢索時，可否挑選出正確的數據，而不必欣賞所有數據。對文本或界說明晰的數值型數據來說是較量簡樸的。其次，異常檢測機制大概也會本身舉辦搜索，雖然這種要領也有其范圍性，假如你不知道你需要什么，或不能明晰界說法則，搜索顯然就不是符合的東西了。

搜索加大數據

在很多環境中，，利用Spark加搜索可能呆板進修的要領都不錯，之前也有講過在Hadoop中添加搜索的要領，但其實這也同樣合用于Spark或呆板進修。

當Spark趨于不變之后，用戶突然意識到Spark并沒有那么神奇，實際在內存中運行時也存在許多問題，數據可以舉辦搜索，拉取事情集闡明的速度遠比利用粗笨的I/O去內存中尋找想要的數據要快得多。

搜索和上下文

搜索并不只僅是辦理事情集，內存或I/O問題，大大都大數據項目標弱點之一是缺少上下文情況，關于安詳問題已經講過了，那用戶體驗如何呢?盡量你可以發明許多用戶數據，但你如何本性化用戶體驗呢?利用你所知道的一切用戶信息，可以提跨越此刻用戶眼前的數據質量，這大概意味著當你向用戶泛起本性化頁面時，前端的用戶交互和后端的搜索需要利用流闡明搞定。搜索辦理方案作為數據架構師，工程師，開拓者可能是科學家，在搜索方案上，你至少需要一到兩個選擇。我最不喜歡的要領就是，內存搞得出格大，然后但愿每次分類都可以利用它，一些供給商好像很是喜歡這種方法。

利用索引和搜索技能可以構建更好的事情空間，還可以制止呆板進修或闡明以及簡樸的從存儲中通過某種尺度選擇數據——甚至通過某些符號，基于數據流對用戶數據舉辦本性化。從中可以看出，搜索長短常不錯的選擇，值得一用!