盡管Hadoop、Spark和NoSQL數據庫現在正發展的如火如荼，但請不要忘記搜索是最原始，最有用的大數據技術之一。隨著很多非常棒的開源工具比如Solr，Lucidworks以及Elasticsearch的出現，你可以使用非常強大的方法優化I/O以及個性化用戶體驗，它會比以錯誤結束的紛繁復雜的新工具要好得多。

成都創新互聯自2013年創立以來，先為南宮等服務建站，南宮等地企業，進行企業商務咨詢服務。為南宮企業網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

Spark缺陷

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

當你在內存中處理意義明確的數據集時，Spark還是很有幫助的，不僅在于其強大的吸收能力，更是因為其在內存中的分析能力和轉移到內存中的能力一樣強大。我們仍然需要考慮存儲并且要知道如何做才能達到我們想要的快速簡潔的效果。對于某些客戶來說，數據進來之后可能會拉取出某個集合用于機器學習，把搜索工作留給搜索引擎完成。

搜索與機器學習

其實，在搜索，機器學習和其他相關技術之間，不存在明顯的界限。顯然，文本或語言信息往往可以很強烈的反映出搜索問題，不管是數值型還是二進制，非文本或語言都可以很自然的表明問題所在。在這方面，這些技術是重疊的。在某些方面，這些技術的處理方式甚至很類似，比如異常檢測，任何一個技術都可以有效地解決該問題。

關鍵的問題在于當你把部分內存作為標準進行檢索時，能否挑選出正確的數據，而不必瀏覽所有數據。對文本或定義明確的數值型數據來說是比較簡單的。其次，異常檢測機制可能也會自己進行搜索，當然這種方法也有其局限性，如果你不知道你需要什么，或不能明確定義規則，搜索顯然就不是合適的工具了。

搜索加大數據

在許多情況中，使用Spark加搜索或者機器學習的方法都不錯，之前也有講過在Hadoop中添加搜索的方法，但其實這也同樣適用于Spark或機器學習。

當Spark趨于穩定之后，用戶忽然意識到Spark并沒有那么神奇，實際在內存中運行時也存在很多問題，數據可以進行搜索，拉取工作集分析的速度遠比使用笨重的I/O去內存中尋找想要的數據要快得多。

搜索和上下文

搜索并不僅僅是解決工作集，內存或I/O問題，大多數大數據項目的弱點之一是缺少上下文環境，關于安全問題已經講過了，那用戶體驗如何呢?盡管你可以發現很多用戶數據，但你如何個性化用戶體驗呢?使用你所知道的一切用戶信息，可以提高呈現在用戶面前的數據質量，這可能意味著當你向用戶呈現個性化頁面時，前端的用戶交互和后端的搜索需要使用流分析搞定。搜索解決方案作為數據架構師，工程師，開發者或者是科學家，在搜索方案上，你至少需要一到兩個選擇。我最不喜歡的方法就是，內存搞得特別大，然后希望每次分類都可以使用它，一些供應商似乎非常喜歡這種方式。

使用索引和搜索技術可以構建更好的工作空間，還可以避免機器學習或分析以及簡單的從存儲中通過某種標準選擇數據——甚至通過某些標志，基于數據流對用戶數據進行個性化。從中可以看出，搜索是非常不錯的選擇，值得一用!

分享標題：大數據技術眾多的今天，不要忘記搜索！
分享路徑：http://vcdvsql.cn/article44/soieee.html

成都網站建設公司_創新互聯，為您提供品牌網站設計、全網營銷推廣、網站建設、營銷型網站建設、網站營銷、自適應網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯