# 接下來的大型聲音如何使用 Hadoop 數據版本控制系統跟蹤萬億首歌曲的播放，喜歡和更多內容 > 原文： [http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html](http://highscalability.com/blog/2014/1/28/how-next-big-sound-tracks-over-a-trillion-song-plays-likes-a.html)  *這是 Next Big Sound 的首席架構師 [Eric Czech](http://www.linkedin.com/profile/view?id=26317730) 的來賓帖子，討論了解決音樂分析中可伸縮性挑戰的一些獨特方法。* 跟蹤在線活動并不是什么新主意，但是要在整個音樂行業中做到這一點并不容易。 每天有五十億個音樂視頻流，曲目下載和藝術家頁面喜歡出現，并且衡量跨 Spotify，iTunes，YouTube，Facebook 等平臺的所有活動的可能性帶來了一些有趣的可擴展性挑戰。 Next Big Sound 從一百多個來源收集此類數據，將所有內容標準化，并通過基于 Web 的分析平臺提供該信息以記錄唱片公司，樂隊經理和藝術家。 盡管我們的許多應用程序都使用諸如 Hadoop，HBase，Cassandra，Mongo，RabbitMQ 和 MySQL 之類的開源系統，但是我們的用法是相當標準的，但是我們這樣做的一個方面是非常獨特的。 我們從 100 多個來源收集或接收信息，我們很早就努力尋找一種方法來處理這些來源的數據隨時間變化的方式，最終我們決定需要一個可以代表這些變化的數據存儲解決方案。 基本上，我們需要能夠以與使用修訂控制（通過 Git）控制創建數據的代碼幾乎相同的方式對這些源中的數據進行“版本化”或“分支化”。 為此，我們在 Cloudera 發行版中添加了一個邏輯層，并將該層集成到 Apache Pig，HBase，Hive 和 HDFS 中之后，我們現在有了一個基本的版本控制框架，可用于 Hadoop 集群中的大量數據。 作為一種 [Moneyball for Music，](http://www.forbes.com/sites/zackomalleygreenburg/2013/02/13/moneyball-for-music-the-rise-of-next-big-sound/)“ Next Big Sound 已經從 MySpace 上的一臺服務器 LAMP 站點跟蹤播放（開始之初很酷）發展為少數藝術家，從而發展了整個行業[ 廣告牌的流行度圖表[以及在 Spotify](http://www.digitaltrends.com/social-media/billboard-social-networking-music-chart-debuts/) 上播放的每首歌曲的[攝取記錄。 數據的增長速度已接近指數級，而分布式系統的早期采用對于保持數據的更新至關重要。 跟蹤了來自公共和私有提供商的 100 多個來源，處理音樂分析的異質性需要一些新穎的解決方案，這些解決方案超出了現代分布式數據庫免費提供的功能。](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) Next Big Sound 也已經在全云提供商（Slicehost），混合提供商（Rackspace）和托管（ [Zcolo](http://www.zayo.com/services/colocation) ）之間進行了過渡，而這些工作全部由小型工程人員使用，除了開放源碼系統外什么也沒有。 在這個過程中我們不乏經驗教訓，我們希望其他人可以從我們的成功和失敗中汲取教訓。 ## 統計信息 * 40 個節點 Hadoop 集群（150TB 容量），約 60 個 OpenStack 虛擬機 * 10TB 的未復制壓縮指標數據（原始 6TB，已索引 4TB） * 10 名工程師，共 22 人 * 5 年的發展 * 每天 30 萬次時序查詢 * 每天有 400G 新數據，處于峰值 * 為超過 100 萬名藝術家錄制了超過 1 萬億個事件，包括 YouTube 音樂視頻觀看次數（ [Kris Schroder 的 Google I / O 演講](http://commondatastorage.googleapis.com/io-2013/presentations/1122%20-%20Find%20the%20next%20big%20thing%20with%20the%20YouTube%20Analytics%20API.pdf) [ [GNIP](http://gnip.com/sources/twitter/) ），iTunes 購買和在線廣播流（通過[與 Spotify](http://www.spotifyartists.com/spotify-next-big-sound-artist-analytics/) 的合作伙伴關系） ## 平臺 * **托管**：通過 [ZColo](http://www.zcolo.com/) 托管 * **操作系統**：適用于 VM 和物理服務器的 Ubuntu 12.04 LTS * **虛擬化**：OpenStack（2 個 Dell R720 計算節點，96GB RAM，2 個 Intel 8 核 CPU，15K SAS 驅動器） * **服務器**：主要是 Dell R420、32GB RAM，4 個 1TB 7.2K SATA 數據驅動器，2 個 Intel 4 核 CPU * **部署**：詹金斯 * **Hadoop** ： [Cloudera（CDH 4.3.0）](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) * **配置**：廚師 * **監控**：Nagios，神經節，Statsd +石墨， [Zenoss](http://www.zenoss.com/) ，[立方體](http://square.github.io/cube/)，[口紅](http://techblog.netflix.com/2013/06/introducing-lipstick-on-apache-pig.html) * **數據庫**：HBase，MySQL，MongoDB，Cassandra（最近放棄使用 HBase） * **語言**：PigLatin + Java 用于數據收集/集成，Python + R + SQL 用于數據分析，PHP（ [Codeigniter](http://ellislab.com/codeigniter) + [Slim](http://www.slimframework.com/) ），JavaScript（ [AngularJS](http://angularjs.org/) + [Backbone.js](http://backbonejs.org/) + [D3](http://d3js.org/) ） * **處理**：黑斑羚，豬，蜂巢， [Oozie](http://oozie.apache.org/) ， [RStudio](http://www.rstudio.com/ide/docs/server/configuration) * **聯網**：瞻博網絡（10Gig，帶自動故障轉移功能的冗余核心層，機架上有 1 個 Gig 訪問交換機） ## 存儲體系結構 使用 Cassandra 和 HBase 等分布式系統存儲時間序列數據相對簡單，但是管理數據隨時間變化的方式則要簡單得多。 在 Next Big Sound，來自 100 多個源的數據聚合涉及某種傳統的 Hadoop [ETL](http://en.wikipedia.org/wiki/Extract,_transform,_load) 管道，其中原始數據通過 MapReduce 應用程序，Pig 或 Hive 處理，并將結果寫入 HBase，以便以后通過[進行檢索。 Finagle](http://twitter.github.io/finagle/) / [節儉](http://thrift.apache.org/)服務； 但有一個轉折。 Hadoop / HBase 中存儲的所有數據均由特殊的版本控制系統維護，該系統支持 ETL 結果隨時間的變化，從而允許定義處理管道的代碼中的變化與數據本身保持一致。 我們在 Hadoop 中管理數據的“版本”方法是對 [Linked.in 數據周期](http://data.linkedin.com/blog/2009/06/building-a-terabyte-scale-data-cycle-at-linkedin-with-hadoop-and-project-voldemort)中所用技術的擴展，其中 Hadoop 的結果將定期重復進行完全重新計算并自動替換 [Voldemort](http://www.project-voldemort.com/voldemort/) 中的舊結果集具有可恢復的版本控制。 我們系統的區別在于版本控制不僅發生在全局級別，還發生在許多可配置的更深層次上。 例如，這意味著，如果我們在 Twitter 上記錄藝術家所在國家/地區的轉推數，并且發現對推文位置進行地理編碼的邏輯在幾天內是錯誤的，那么我們只需創建新的數據版本即可 那些日子，而不是重建整個數據集。 現在，這些新版本中的每一個都將具有不同的值，并且可以將某些版本的訪問權限限制為某些用戶。 開發人員可能只會看到最新版本，而普通用戶將看到舊版本，直到確認新數據正確為止。 像這樣的“分支”數據對于跟上數據源和客戶請求的變化以及支持有效的增量數據管道至關重要。 有關該系統的更多詳細信息，此圖描繪了上述一些關鍵差異。 [](https://dl.dropboxusercontent.com/u/65158725/hadoop_arch.png) 有關更多詳細信息，請查看 [論文：HBlocks：用于迭代數據工程的 Hadoop 子系統](https://dl.dropboxusercontent.com/u/65158725/hblocks.pdf) 。 除了 Hadoop 基礎架構，我們還面臨許多其他挑戰。 跨社交網絡和內容分發站點映射音樂行業中實體的關系，構建 Web 應用程序以對數百萬個數據集進行排序/搜索，以及通過數百萬個 API 調用和 Web 爬網管理信息收集，都需要專門的解決方案。 我們僅使用開源工具來完成所有這些工作，下面簡要介紹了這些系統之間的相互關系。 [](https://dl.dropboxusercontent.com/u/65158725/nbs_arch.png) * **數據表示**：我們的指標儀表板的構建一直是一個正在進行的項目，大部分都是由我們的客戶指導的。 要在靈活性和學習曲線之間取得適當的平衡，是一個移動目標，其中有許多不同的數據集，并且維護一致的 JavaScript / PHP 代碼庫來管理這些代碼，這對每個新客戶和新功能都將變得更加困難。 以下是到目前為止我們如何處理的一些要點： 1. 從簡單的 Codeigniter 應用開始，嘗試盡可能多地整合 Backbone，現在（積極地）轉向 Angular 2. 大型靜態對象的內存緩存（例如國家/地區與州之間的映射） 3. 用于指標數據緩存和歷史記錄的本地存儲（即，當您重新加載頁面時，這就是我們之前所知道的方式） 4. 用以前使用過的[人力車](http://code.shutterstock.com/rickshaw/)進行的 D3 繪制圖形 同樣，我們對功能標志不做任何花哨的事情，但是我們不斷地使用它們的基本實現。 在一直被重寫的代碼庫中，它們一直是一個至關重要的（盡管有時是混亂的）常量，如果沒有它們，我們將無法完成許多工作。 * **查找**：我們已投入巨資開發產品，使我們的用戶能夠根據多種標準在我們的數據中搜索有趣的歌手或歌曲（我們稱其為“ “查找”產品）。 與音樂的股票篩選器類似，該產品可讓用戶按“在以前從未出現在某種流行度圖表上的 YouTube 視頻觀看次數的 30％-40％范圍內說唱藝術家”等條件過濾后對結果進行排序。 此基礎結構的大部分駐留在 MongoDB 中，該位置由 MapReduce 作業提供索引豐富的集合，并在數百萬個實體中提供近乎即時的搜索功能。 在 MongoDB 上構建這種類型的產品效果很好，但是索引限制一直是一個問題。 我們目前正在探索更適合這種用例的系統，特別是 ElasticSearch。 * **內部服務**：我們的產品和 API 使用的所有度量標準數據均從內部 Finagle 服務提供，該服務從 HBase 和 MySQL 讀取。 這項服務分為多個層（所有層都運行相同的代碼），在這些層中，我們的產品直接使用了更關鍵的低延遲層，而第二層則具有更高的吞吐量，但具有更高的 90％延遲 程序化客戶。 兩者中的后者往往更加突發和不可預測，因此使用這樣的單獨層有助于使客戶的響應時間盡可能短。 這也是一種方便的拆分方式，因為這意味著我們可以為關鍵層構建更小的虛擬機，然后將其他 Finagle 服務器陣列并置在我們的 Hadoop / HBase 計算機上。 * **下一個 Big Sound API** ：我們已經在對外公開以及在內部為產品提供動力的主要 API 上進行了許多迭代。 以下是一些我們發現最有影響力的最佳做法： 1. 不要構建僅公開方法的 API，不要構建對系統中的實體建模的 API，并讓 HTTP 動詞（例如 GET，PUT，POST，HEAD，PATCH，DELETE）暗示這些實體的行為。 這使得 API 的結構更容易推斷和試驗。 2. 對于需要實體*關系*的方法，請對主要實體使用類似“字段”參數的方法，并讓該參數中的字段存在暗示實際上需要查找什么關系。 對我們來說，這意味著我們的 API 公開了帶有“ fields”參數的“ artist”方法，該方法僅在將字段設置為“ id，name”時返回藝術家的姓名，但也可能返回有關 YouTube 藝術家的數據 頻道及其上的所有視頻（如果字段設置為“ id，名稱，個人資料，視頻”）。 獲取實體之間的關系可能很昂貴，因此這是保存數據庫查詢的好方法，而無需編寫一堆丑陋的組合方法，例如“ getArtistProfiles”或“ getArtistVideos”。 3. 使用外部公開的 API 來構建自己的產品始終是一個好主意，但是我們看到的另一個微妙的優勢是新加入 Web 開發人員。 過去，我們在 JS 代碼和 API 調用之間放置了很多 PHP 代碼，但現在試圖將交互作用嚴格地限制在 JavaScript 和 API 之間。 這意味著網絡開發人員可以將精力集中在他們熟知的瀏覽器代碼上，并且可以與他們喜歡的 Backbone 和 Angular 框架更好地協作。 * **警報和基準**：音樂世界中總是發生著很多事情，我們嘗試在所有噪聲中挖掘重大事件的一種方法是通過對整個平臺的數據進行基準測試（例如 確定每天發生的 Facebook 喜歡次數的總體趨勢），并在客戶關心的藝術家看到活躍的活動高峰時提醒我們的客戶。 我們在此方面存在一些早期的可伸縮性問題，但我們已經解決了大多數問題，致力于將僅 Pig / Hadoop 用于其結果存儲在 MongoDB 或 MySQL 中。 剩下的問題集中在如何為“重要”設置閾值上，到目前為止，我們最大的收獲是在線活動趨向于全球趨勢和峰值，因此基準必須考慮盡可能多的數據，而不能僅僅關注 在單個實體（或本例中的藝術家）上。 與這些更全面的基線的偏離是*實際*行為變化的良好指示。 * **Billboard Charts** ：我們向 Billboard 雜志授予了兩張圖表，一張用于在線藝術家的整體流行度（[社交 50 圖表](http://www.billboard.com/charts/social-50)），而另一張基本上是試圖預測哪些藝術家最有可能 以便將來列出該列表（[下一個大聲音圖表](http://www.billboard.com/charts/next-big-sound-25)）。 計算這些圖表不會帶來任何重大的縮放挑戰，因為它只是對所有藝術家的計算得分進行反向排序，但是生成經過精打細算，具有重復數據刪除功能且值得生產的列表是需要考慮的。 我們系統中的重復或幾乎重復的藝術家以及這些藝術家與他們的在線個人資料的關聯存在很多問題（例如，賈斯汀·比伯的 Twitter 用戶名是“ justinbieber”，“ bieber”還是“ bieberofficial”？）。 解決這樣的問題通常需要自動化和人機交互的結合，但是當在過濾例程中避免誤報非常重要（即，即使刪除一個合法的藝術家是一個大問題）時，手動管理也是必要的。 但是，我們發現，通過記住執行的動作然后具有重播這些動作的功能的系統來增加這種管理是非常有效且易于實現的。 * **預測性廣告牌得分**：我們產生的更有趣的分析結果之一是[專利算法](http://making.nextbigsound.com/post/68287169332/predicting-next-years-breakout-artists)，用于計算藝術家在下一次“突破”時的可能性 年。 此過程涉及[隨機梯度增強](http://astro.temple.edu/~msobel/courses_files/StochasticBoosting(gradient).pdf)技術的應用，以基于不同社交媒體號碼的“病毒性”來預測這種可能性。 除了數學之外，這很難做到，因為我們使用的許多工具都沒有 Hadoop 友好的實現，并且我們發現 [Mahout](http://mahout.apache.org/) 不能在基本應用程序之外運行。 然后，我們針對此類過程的體系結構包括通過 MapReduce 作業構建并寫入 MongoDB 或 Impala 的輸入數據集，然后通過 [R-Mongo](http://cran.r-project.org/web/packages/RMongo/index.html) 和 [R-Impala](http://cran.r-project.org/web/packages/RImpala/index.html) 引入 R 中，然后進行處理 在單個巨型服務器上使用 R 的一些并行處理庫，例如[多核](http://cran.r-project.org/web/packages/multicore/index.html)。 使用 Hadoop 進行大多數繁重的工作，并將其余的工作留給單個服務器存在一些明顯的局限性，目前尚不清楚我們最終將如何解決這些問題。 [RHadoop](https://github.com/RevolutionAnalytics/RHadoop/wiki) 可能是我們最大的希望。 ## 托管 * 推出自己的網絡解決方案很糟糕。 如果您要組成一個小型團隊，請確保您已經有人專心完成以前完成的任務，否則請找人。 這很容易成為我們托管的最大痛苦（也是一些令人恐懼的中斷的原因）。 * 在托管服務提供商之間移動總是很棘手，但如果您預算要在運行于兩種環境中的機器上不可避免地花費的額外資金，則不必冒險，它們或多或少地在做同一件事。 除了一些不可避免的例外，我們總是最終在關閉任何舊資源之前，在新的提供程序中完整地復制體系結構，并且通常會進行一些增強。 供應商之間的共享系統似乎永遠無法正常運行，通常節省下來的錢不值得缺少睡眠和正常運行時間。 * 由于我們約有 90％的容量專用于 Hadoop / HBase，并且工作負載真正穩定，因此很難超越擁有自己的服務器所帶來的價格。 由于用戶流量，我們的工作量并不是每天都突發，因為與正在進行的所有內部號碼處理相比，該流量很小。 我們確實必須定期增加容量，但是將其作為步進功能很好，因為這些增加通常與大客戶或數據合作伙伴的收購相吻合。 這就是為什么我們繼續使用自己的硬件每月可節省約 2 萬美元的原因。 ## 獲得的經驗教訓 * 如果您要匯總來自許多來源的數據并對其進行適度的轉換，那么您將犯錯誤。 在大多數情況下，這些錯誤可能很明顯，您可以在將它們投入生產之前將其修復，但是在其余時間中，一旦它們出現，您將需要適當的地方來對其進行處理。 這是我們在意識到這一點之前經歷了很多次的場景： 1. 為 Twitter 藝術家的追隨者收集 TB 級的數據集，在一兩天內將其加載到數據庫中。 2. 讓客戶知道數據已經準備好了，而讓我們知道這些數據真是太棒了。 3. （一個月后）等等，為什么所有追隨者中有 20％生活在堪薩斯州的大黃？ 4. 哦，將位置名稱轉換為坐標的代碼會將“ US”轉換為該國家中部的坐標。 5. 好的，既然客戶仍在使用數據集的正確部分，我們就不能刪除整個內容，而只能對其進行重新處理，將其寫入新表中，更新所有代碼以讀取兩個表中的所有代碼，僅從中獲取記錄 如果新表中不存在舊表，則在重新處理完成后刪除舊表（容易嗎？）。 6. 一百行駭人的意大利面條代碼（永不消失），幾天后，工作完成。 在某些情況下，可能有一種更聰明的處理方式，但是當您遇到足夠多的情況時，很顯然，您需要一種更新生產數據的好方法，而不僅僅是將其完全刪除和重建。 這就是為什么我們要為它構建系統的麻煩。 * 我們的大多數數據都是使用 Pig 生成和分析的。 它功能強大，幾乎我們所有的工程師都知道如何使用它，并且它作為我們存儲系統的中堅力量發揮了很好的作用。 搞清楚它到底在做什么，到底有什么進展，我們發現 Netflix 的 Lipstick 對此很有幫助。 我們還發現，用 Pig 來縮短開發迭代的時間很重要，而不是具有較高的可見性。 必須花時間在運行時間更長的腳本上智能地構建示例輸入數據集，這些腳本會生成 20 多個 Hadoop 作業，然后再嘗試對其進行測試。 * 從 0.4 版本開始，我們就使用了 Cassandra 多年，盡管初期經歷過恐怖的經歷，但是當我們離開它時，它確實很棒。 這一舉動與 Cassandra 并沒有多大關系，而實際上只是由于我們在重建存儲架構時希望使用 Cloudera 平臺的結果。 在廣泛使用 HBase 和 HBase 之后，我們吸取的教訓是，對于大多數人來說，爭論使用哪種可能只是浪費時間。 一旦我們了解如何對其進行調整，它們都可以可靠地工作并表現良好，并且專注于我們的數據模型（例如，鍵壓縮方案，行大小上限，使用可變長度整數，查詢訪問模式）產生的變化要大得多。 [下一個 Big Sound Blog](http://blog.nextbigsound.com/) 也有一些關于音樂行業數據挖掘的有趣帖子，如果您真的喜歡這種事情，我們總是[招聘](https://www.nextbigsound.com/about#join)！ 因此，這些算法將以博弈數據為基礎來制定自我強化的商業決策，而這將花費所有人類的技巧和投入。 知道了，商業音樂變得更加孤立和注重結果，而計算機會告訴我們我們想要什么，然后我們就會喜歡它。 明白了，音樂品味的天網。