# 在 Yelp 上利用云計算-每月訪問量為 1.02 億，評論量為 3900 萬 > 原文： [http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html](http://highscalability.com/blog/2013/6/26/leveraging-cloud-computing-at-yelp-102-million-monthly-visto.html)  *這是 Yelp 的， [Jim Blomo](https://twitter.com/jimblomo) 的來賓帖子。 Jim 管理著一個不斷發展的數據挖掘團隊，該團隊使用 Hadoop ， mrjob 和奇數作業處理 TB 數據。 在 Yelp 之前，他為初創公司和亞馬遜建立了基礎架構。* *在即將舉行的 [OSCON 2013 上發表演講，內容涉及在 Yelp](http://www.oscon.com/oscon2013/public/schedule/detail/29387) 建立云文化。* 在 2013 年第一季度，Yelp 的**唯一身份訪問者為[1.05 億]** （來源：Google Analytics（分析）），其中每月平均有大約 1000 萬使用 Yelp 應用程序的獨特移動設備。 Yelpers 甚至 ve 撰寫的內容超過 **3,900 萬篇豐富的本地評論**，這使 Yelp 成為了從精品店，技工到餐廳和牙醫等各個領域的領先本地指南 。 關于數據，關于 Yelp 的最獨特的事情之一就是數據的多樣性：評論，用戶個人資料，業務描述，菜單，簽到，食物照片……清單還在繼續。 我們有很多處理數據的方法，但是今天我將重點介紹如何處理離線數據處理和分析。 在 2009 年底，Yelp 使用亞馬遜的 Elastic MapReduce （ EMR ）作為備用計算機構建的內部集群的替代和進行了調查。 到 2010 年中，我們已經將生產處理完全轉移到 EMR ，并關閉了 Hadoop 集群。 今天，我們從集成測試到廣告指標，每天要處理 **500 個工作** 。 ve 在此過程中吸取了一些教訓，希望對您有所幫助，因為我們 ll 。 ## 工作流池 EMR 的最大優勢之一是即時可伸縮性：每個作業流可以配置有任務所需的多個實例。 但是可伸縮性并不是免費的。 主要缺點是 1）分解群集可能需要 5 至 20 分鐘，2）每小時需要支付**或不足一小時**的費用。 這意味著，如果您的工作在 2 小時 10 分鐘內完成，則將向您收取整整三個小時的費用。  在您開始運行數百個作業并且作業流程結束時所浪費的時間開始累積之前，這似乎并不重要。 為了減少浪費的計費時間， mrjob 實現了“作業流池”。 mrjob 而不是在工作結束時關閉工作流，以防其他工作想要使用它，而保持工作流 ve 的狀態。 如果隨之而來的另一個作業具有相似的群集要求，則 mrjob wi ll 將重用作業流程。  實施此操作有一些微妙之處：1）具有“相似的集群要求”是什么意思，2）如何避免多個作業之間的競爭狀況，以及 3）集群何時最終關閉？ 定義了滿足以下條件的類似工作流程： * 相同的 Amazon Machine Image（AMI）版本 * 相同的 Hadoop 版本 * 相同的 mrjob 版本 * 相同的引導步驟（引導步驟可以設置 Hadoop 或群集選項） * 每種節點類型具有相同或更大的 RAM 和計算單元（例如。 Hadoop 主服務器與工人） * 接受新作業（作業流程最多可處理 256 個步驟） 通過使用鎖定避免了競爭情況。 默認情況下，在支持一致性的區域（美國西部）中使用 S3 **實施鎖定。 作業使用有關作業名稱和群集類型的信息寫入特定的 S3 密鑰。 如果發生故障，鎖定可能會超時，從而使其他作業或作業終止者可以收回作業流。** 作業流終止由 cron 作業處理，該作業每 5 分鐘運行一次，檢查是否有閑置的作業流即將達到 **每小時的費用，并終止它們** 。 這樣可以確保從不共享工作流的最壞情況不會比默認情況下代價高。 為了進一步提高作業流的利用率，作業可以等待預定時間，以找到可以重用的作業流。 例如，對于開發作業， mrjobs wi ll 嘗試在開始新作業之前先尋找 30 秒鐘的空閑作業流。 在生產中，沒有到嚴格期限的工作可能會將等待時間設置為幾個小時。 我們估計通過使用工作流池 可以節省大約 **10％的成本。 從開發人員的角度來看到，這種節省成本幾乎是免費的：通過設置一些配置設置，這些更改無需開發人員的任何操作即可生效。 實際上，我們看到了一個附帶好處：迭代 ve 作業的開發速度大大加快，因為修改后的 MapReduce 作業的后續運行可以重用集群，并且消除了集群啟動時間。** ## 預留實例 默認情況下， AWS 每機器小時收費，但它提供了其他一些可以降低成本的購買選項。 [預留實例](http://aws.amazon.com/ec2/reserved-instances/) 是更直接的選擇之一：先付錢，再收取每小時較低的每小時費用。 在將 AWS 價格與購買服務器進行比較時，我鼓勵人們研究此選項：與購買服務器的資本成本和承諾相比，這是一個更為公平的比較。  什么時候比保留實例便宜一些 ll ？ 這取決于實例在一年中使用多少小時。 ve 上的圖顯示了使用不同的 reser ve 實例定價選項運行大型標準實例的成本：輕，中或重度使用。 您可以按需支付價格，即$ 0.26 /小時，但在大約 3000 小時（4 個月）后，支付$ 243 的 Reser ve 價格會變得更加便宜，僅需為預留的臨時使用量支付$ 0.17 / hour 實例。 每年使用 3000 多個小時？ 然后是時候研究增加的使用計劃了，“重載”是最大的前期，但每小時計劃最低。 您的公司應購買多少個預留實例？ 這取決于您的用法。 與其試圖預測我們將要使用的 **wi ll** 多少，我們而是編寫了一個工具來分析**過去的**使用情況并建議購買計劃 **會 ve** 為我們節省最多的錢。 假設我們的未來使用率 ll 看起來與我們過去的使用情況相似，并且額外的工作和預測風險不值得相對多的支出。 ve 。 該工具的名稱為 ll [EMRio](https://github.com/Yelp/EMRio) ，我們去年開放了來源。 它分析 EMR 的用法，并建議購買多少個預留實例，因為我們 ll 會生成一些漂亮的圖形。  請務必注意，預留實例定價是一種計費方式。 也就是說，您并不是在物理上預訂機器。 在月底，Amazon 僅查看您使用了多少實例小時，并將保留的實例費率應用于正在運行的任何實例，直到購買的實例數量為止。 ## 得到教訓 **了解遷移到云解決方案** 時的權衡。 對于 Yelp，使用 AWS 的主要好處是通過降低協調成本和功能延遲來提高開發人員的生產力。 協調成本來自要求產品團隊預測和請求系統團隊的資源。 購買資源（無論是服務器機架還是網絡容量）可能要花費數周的時間，并增加了功能啟動的延遲。 延遲有其自身的相關成本，這些成本降低了道德水平（偉大的開發商（HTG5）至運輸產品）以及項目之間的上下文切換。 AWS 的美元成本可能高于完全利用的，定制的內部解決方案的成本，但是您的想法是 ve 購買了更多的生產力。 **專注于大贏家** ：可以逐步采用云技術-我們正在這樣做！ Yelp 從 EMR 開始，因為這是我們最大的勝利。 離線處理具有尖峰的負載特性，通常不需要團隊之間的協調，并且通過為開發人員提供實驗的杠桿作用，可以使開發人員獲得更高的生產率和。 為了更好地使用云，請集中精力一次解決最嚴重的瓶頸。 **建立在抽象** 之上：不要在 ll 上讓所有人都了解云服務的細節，就像您不要在[數據中心。 記住您的權衡：目標是使開發人員的工作效率更高，而不是與流行語兼容。 如果開發人員不能像本地腳本那樣輕松地使用它，那么擁有可擴展的，適應性強的或基礎架構并不重要。 我們最喜歡的抽象是 [mrjob](https://github.com/Yelp/mrjob) ，它使我們可以在 Python 中編寫和運行 MapReduce 作業。 在與 EMR 群集的本地計算機上運行作業是更改兩個命令行參數的問題。 **建立策略和集成計劃** ：旋轉單個實例很容易，但是什么時候旋轉機器？ 每天處理的日志很簡單，但是如何可靠地將日志傳輸到 S3？ 已對 ll 的支持工程計劃，使系統正常工作：數據集成，測試，備份，監視和警報。 Yelp 圍繞 PII 制定了政策，將生產環境與開發區分開來，并使用 mrjob 軟件包中的工具來監視失控的集群。 **穩定后優化** 。 有許多削減成本的方法，但是大多數方法都需要一定的復雜性和未來的靈活性。 在執行之前，請確保已使用了有效的抽象解決方案，以便評估的投資回報率。 Yelp 寫了 EMRio 的數據，這是我們有 EMR 與 mrjob 結合使用的幾個月的數據。 在看到我們實際使用 EMR 之前先進行優化，可能會甚至在黑暗中拍攝。 **評估 ROI** ：通過一些優化，成本評估非常簡單：如果兩個月前我們都保留實例，我們將節省多少？ 有些更困難：開發過程中的瓶頸是什么？云解決方案能否消除它們？ 容易或困難，但是在執行之前對其進行評估很重要。 優化之前的配置文件代碼我想你是說什么？ 如果不是的話，我不希望您使用此分析器:) ## 未來發展方向 隨著 Yelp 面向服務架構的發展，我們在脫機批處理中遇到了類似的瓶頸：資源協調，測試思路，在啟動新功能之前預測使用情況。 因此，我們再次將目光投向了云，以為廣告選擇，搜索和數據提取等服務帶來巨大的成功。 [期待 Yelp 工程博客上有關](http://engineeringblog.yelp.com/) [Asgard](http://netflix.github.io/asgard/) 未來的帖子用于構建和部署服務，評估 Python 框架 服務器到 RESTful API ，并構建抽象使其易于使用 ll 。 當然，如果您想幫助建立這個未來，請 [告訴我們！](http://www.yelp.com/careers)