一、Apache Spark和Apache Storm的區別

Apache Spark和Apache Store的區別是什么？他們各自適用于什么樣的應用場景？這是stackoverflow上的一個問題，這里整理簡要版回答如下：

Apache Spark是基于內存的分布式數據分析平臺，旨在解決快速批處理分析任務、迭代機器學習任務、交互查詢以及圖處理任務。其最主要的特點在于，Spark使用了RDD或者說彈性分布式數據集。 RDD非常適合用于計算的流水線式并行操作。RDD的不變性(immutable)保證，使其具有很好的容錯能力。如果您感興趣的是更快地執行Hadoop MapReduce作業，Spark是一個很好的選項（雖然必須考慮內存要求）。Spark相對于hadoop MR來說，除了性能優勢之外，還有大量豐富的API，這使得分布式編程更高效。

Spark架構圖如下，總體結構非常簡潔，沒什么需要多說的，這里對spark的幾個細節補充解讀如下：

每個spark應用程序有自己的執行進程，進程以多線程的方式執行同一個應用的不同任務(tasks)。

因為不同的spark應用是不同進程，所以無論是在driver端還是executor端，不同用程序都是互相隔離的，在沒有集群外存儲的情況下，應用之間不能共享數據。

Spark對底層集群管理器是不可知的。通常能做集群進程管理的容器，都可以管理spark程序。例如Mesos / YARN這樣的集群管理也可以用于spark。當前在各大互諒網公司比較常用的就是基于yarn的spark。

driver端必須在整個應用的生命周期內存在，并且是可尋址（固定在某個機器或者說IP上），因為executor都要跟driver建立連接并通訊。

由于是driver端來負責任務的調度(指應用具體操作的輸入輸出控制，區別于yarn的集群管理)，所以driver端最好跟executor端最好在同一個局域網（比如同一個機房），從而避免遠距離通信。實時上driver端即使不做大的返回集合collect的話，如果任務分片(partitions)很多，也會有大量通信開銷。

二、未來希望從事機器學習的方向，有必要學習linux嗎

可以把重點放在機器學習的模型和算法上，應用場景和申請專利也很重要。機器學習是一門交叉學科，可以解決許多實際中的問題，Linux是操作系統。一般機器學習的程序可以在windows、linux、mac等系統上，但是大規模并行的機器學習程序一般在基于linux的分布式系統中。

三、學習分布式系統需要怎樣的知識

1. 硬件&底層軟件的失效與高可用性高性能的矛盾。硬盤，交換機，進程，甚至OS本身都有失敗／崩潰的可能，在包含很多機器（比如>1000）的廉價（使用非企業級硬件）集群中，這個問題表現為“你的系統總有一部分處于故障狀態，如何保證高可用性？”，它的另一半是“如何在盡量少系統開銷的前提下，保證此可用性？”。一個簡單的例子是，為防止單點故障，數據通常都有備份。備份越多，可用性通常越好，但需要更多的磁盤空間和網絡帶寬，導致性能降低。那么多少備份合適？如何將這些備份分散到集群上（例如跨硬盤，跨機器，跨交換機，等等要求）？ 2. 編程模型與單機不同，如何克服習慣帶來的影響。一個最簡單的例子是關于“鎖”的。在單機上，如果進程A和進程B都想修改數據D（例如做一個D++操作），有很多種方法可以避免沖突。但分布式系統就要面臨選擇：要么用單機管理數據D（并忍受由此帶來的低可用性，因為單機失效將造成整個集群不可用），要么用多機共同管理數據D（并忍受復雜的協議，一大堆代碼，還有性能開銷）。Paxos就是以上問題的經典解決方案（分布式的），發明者即Leslie Lamport。 3. 工業級的分布式系統意味著一整套工具集，除了那些運行在生產系統上的集群軟件，還有龐大的部署、運維、診斷軟件群，數量巨大的硬件（服務器、交換機、機架、電源，這些都很可能是定制的），甚至包括建筑物（數據中心的規劃、設計、內部結構等）。已經超出我的經驗范圍，作為一個引子，題主可自行了解。

四、搜索引擎的 Query 分析有哪些小技術點

您好:

Query的數據分析

Query即用戶在搜索引擎輸入查詢條件。在通用搜索引擎中，一般是指輸入的關鍵詞。而在各類行業或者垂直搜索引擎，還可以輸入類目，如優酷網站中可以選擇“電影”、“電視劇”這樣的類目。在電子商務網站中，各種產品品牌、型號、款式、價格等也是常見的查詢條件。

要分析query中每個term的內容，分詞是必不可少的工具。分詞算法從最簡單的最大正向、最大反向分詞算法，到復雜的隱馬爾科夫、CRF模型。CRF模型是一種序列標注的機器學習方法。分詞算法最關鍵的是如何得到足夠的標注準確的語料庫，足夠的訓練語料是模型成功的基礎條件。

Query按照PV從高到低排序之后。橫坐標為query編號，縱坐標是query的PV。從下圖可以明顯看出，query的PV分布是一個長尾分布。

每種搜索引擎的query

都有自己的特點。根據query的特點來設計自己的算法和相應產品是非常必要的。例如：百度有很多查詢“從A到B怎么走”，“××怎么樣”。相信百度正是研究了這些查詢，才力推百度“貼吧”和“知道”，“百科”等產品的。通用搜索引擎和電子商務網站的query區別一定很大。例如joyo當當一定有大量書籍名稱的查詢。而在電子商務網站，有大量類目+屬性的查詢方式。如何組合的輸入條件，準確分析用戶意圖，保證搜索引擎結果的召回率和準確率是一個挑戰。

20-80定律：query 和cache

我們發現20%的top query，占據了80%的PV流量。如果解決了這20%的query的分析和排序問題，我們就解決了絕大多數流量的問題。

針對20%的query，我們可以優化搜索引擎的索引結構，盡量直接返回用戶需要的信息。在query分析的模塊，我們可以存儲query的分詞、詞性標注以及query分類等結果。總之高效利用內存，用內存換取性能的極大提升。

query的分類和“框計算”

query分類是目前通用搜索引擎必須解決的問題。當你在百度或者google上面輸入“××市天氣”，會顯示天氣狀態圖片、溫度等;輸入“中石油”直接顯示出中石油的股價;輸入“航班”直接從航班起點和終點的選擇。這也是百度所謂的“框計算”，也就是直接在搜索框完成解析，直達具體的應用。

如何做分類呢?

假設搜索引擎已經對網頁分類，那么統計每個query下點擊的頁面分類，把頁面類別的概率按照從高到低排列，也就是query的分類。也就可以知道這個query的分類。但是這種只能用在當query的點擊數量足夠的時候。

另外一種辦法是通過頁面分類，用貝葉斯的方法，反推每個query可能屬于那些類別。

query的導航

query的分類其實是導航的一個基本條件。只有當你對query的分類準確，對query中每個term的詞性理解準確的時候，導航才真正開始。

在電子商務網站，如Amazon、京東等網站。準確的導航是非常必要的。

而準確的導航是第一步。根據用戶輸入，在導航中體現相關熱門推薦，或者個性化推薦，是對導航的更進一步的要求。

在淘寶搜索產品上，當用戶輸入關鍵詞，會自動提示相應的類目和屬性，并且把熱門的類目屬性展示在前面，而把相對冷門的類目和屬性折疊起來。最大利用網頁有限的展示空間。

query suggestiong

query與個性化

說到個性化，必然涉及到對用戶數據的收集。根據用戶的行為或者設置，分析用戶的年齡、性別、偏好等。同樣是搜索“咖啡館”，你在北京和上海搜索得到結果可能差異很大。

而這些分析數據來源于對每個用戶在搜索引擎的行為日志。搜索引擎都會分析每個用戶的搜索和點擊等行為。存儲的時候存在在分布式key-value內存數據庫中。

用戶行為不僅僅對個別用戶本身有用。大量用戶的行為日志，被廣泛用于推薦系統的數據挖掘。例如用戶在當當joyo上面購買的書籍，就來自于大量用戶的購買和瀏覽記錄。推薦系統從常見的關聯規則分析，已經進化到各種復雜的圖關系分析算法。

詳情參考: