當下，在線行為分析已并不罕見，但對整個音樂產業進行分析仍然不是一件容易的事情——你需要橫跨Spotify、iTunes、YouTube、 Facebook等眾多流行平臺進行相關跟蹤，其中包括近5億的音樂視頻流、下載、藝術家頁面上產生的大量likes（每日）等，這將給分析系統擴展性帶 來巨大的挑戰。Next Big Sound每天從100多個源中收集這些數據，進行分析，并通過基于網絡的分析平臺將這些信息提供給唱片公司、樂隊經理及藝術家。

時至今日，類似Hadoop、 HBase、Cassandra、MongoDB、RabbitMQ及MySQL這樣的開源系統已在生產環境中得到了廣泛應用，Next Big Sound正是基于開源構建，然而Next Big Sound的規模顯然更大了一些——從超過100個源接收或收集數據。Eric團隊首先面臨的問題就是如何處理這些不停變化的數據源，最終他們不得不自主 研發了一個存儲系統，從根本上說是個可以“version”或者“branch”化從這些數據源上收集的數據，類似GitHub上的代碼版本控制。 Next Big Sound通過給Cloudera發布版增加邏輯層來實現這個需求，隨后將這個層與Apache Pig、 HBase、Hive、HDFS等組件整合，形成一個在Hadoop集群上海量數據的版本控制框架。

作為 “Moneyball for Music”一 員，Next Big Sound開始只是個運行在單服務器上的LAMP網站，為少量藝術家追蹤MySpace上的播放記錄，用以建立Billboard人氣排行榜，以及收集 Spotify上每首歌曲上產生的數據。隨著數據以近指數級速度的增長，他們不得不選用了分布式系統。同時，為了跟蹤來自公共及私有提供者的100多個數 據源和不同性質音樂的分析處理，Next Big Sound需要比當下開源數據庫更優秀的解決方案。

Next Big Sound一直保持著非常小的工程團隊，使用開源技術搭建整個系統，采用過完全云架構（Slicehost）、混合云架構（Rackspace）、主機托管（Zcolo）等不同架構形式。

統計

• 40個節點的Hadoop集群（150TB容量），約60個OpenStack虛擬機
• 10TB的非重復、已壓縮的數值型數據（6TB原始、4TB索引）
• 10個工程師，總計22人
• 5年的開發
• 每天30萬時間序列查詢
• 峰值期間每天400GB新數據
• 記錄百萬藝術家超過萬億的事件，包括了YouTube音樂視頻訪問數、Twitter上轉發和@藝術家的數量、iTunes購買數以及在線廣播流。

平臺

• 托管：使用ZColo進行托管
• 操作系統：虛擬和實體服務器都使用 Ubuntu 12.04 LTS
• 虛擬化：OpenStack（2x Dell R720計算節點、96GB RAM、2x Intel 8-core CPU、5K SAS磁盤驅動器）
• 服務器：Dell R420、 32GB RAM、4x 1TB 7.2K SATA數據磁盤, 2x Intel 4-core CPU
• 部署：Jenkins
• Hadoop： Cloudera (CDH 4.3.0)
• 配置：Chef
• 監視：Nagios、Ganglia、Statsd + Graphite、 Zenoss、 Cube、 Lipstick
• 數據庫：HBase、MySQL、MongoDB、Cassandra（正在逐步使用HBase替代）
• 語言：數據收集和集成用PigLatin + Java、數據分析使用Python + R + SQL、PHP ( Codeigniter +  Slim)、JavaScript ( AngularJS +  Backbone.js +  D3)
• 處理：Impala、Pig、Hive、 Oozie、 RStudio
• 網絡：Juniper（10Gig、冗余核心層W/自動故障轉移、機架上配備1 Gig接入交換機）

存儲架構

使用類似Cassandra 及HBase這類分布式系統存儲時間序列是很容易的，然而，隨著數據和數據源的暴增，數據管理變得不再容易。傳統情況下，整合從100+數據源中搜集數據 的工作包含以下兩個步驟：首先，在Hadoop ETL管道對原始數據進行處理（使用MapReduce應用、Pig或者Hive）；其次，將結果存儲到HBase以便后續Finagle/Thrift 服務的檢索。但是在Next Big Sound，情況有了些不同，所有存儲在Hadoop/HBase中的數據通過一個特殊的版本控制系統維護，它支持ETL結果上的改動，允許根據需求來修 改定義處理管道的代碼。

在對Hadoop數據進行再計算時，使用“版本化”管理Hadoop數據提供了一個可恢 復及版本化途徑，擴展了許多數據處理周期技術（比如LinkedIn）。而Next Big Sound系統的區別在于可以配置版本化的等級，而不是必須在全局運行，舉個例子：在記錄一個藝術家某個地理區域上tweet轉發次數的用例中，忽然發現 在某個時間段內基于地理位置編碼的邏輯是錯誤的，只需建立這個時間段的新數據集就可以了，從而避免了對整個數據集進行重建。不同的數據通過版本進行關聯， 也可以為某些用戶指定所訪問數據的版本，從而實現只有在數據精確時才對用戶釋放新的版本。類似這樣的“Branching”數據可以應對數據源和客戶需求 的變化，同時也可以讓數據管道更高效。更多詳情查看下圖（點擊查看大圖）：

在Hadoop 基礎設施方面，同樣面臨了很多難題：1，跨整個音樂產業的社交網絡和內容發布網站的實體關系映射；2，貫穿上千萬數據集建立用于排序和搜索的Web應 用；3，管理數百萬API調用的信息以及網絡爬蟲。這些操作都產生了特定的需求，而在Next Big Sound，系統完全建立在開源技術之上，下面是一個概況圖（點擊查看大圖）：

數據顯示

測量儀表盤一直都是個進行中的項目，這個工作大部分由用戶需求主導。由于數據源太多，這里的長期目標是做靈活性和學習曲線之間的平衡；同時，由于新客戶和特性的增加，維持一個連續的JavaScript/PHP代碼庫進行管理也變得愈加困難。Next Big Sound操作如下：

• 開始使用簡單的Codeigniter應用，盡可能的嘗試添加Backbone，當下已戰略性的轉向Angular。
• 使用Memcache緩存大型靜態對象。
• 度量數據的緩存和歷史記錄使用本地存儲。
• 使用D3做圖，之前使用的是Rickshaw。

沒有做功能標志，但是使用了自己的方法。如果某個代碼庫經常被重寫，這點將非常重要，沒有它，很多事情我們都完成不了。

FIND

投 入大量精力做用戶基于給定條件的數據集搜索，這個功能被定義為“FIND”項目的預覽版本。類似股票篩選器，用戶可以做類似的查詢。比如：Rap藝術家， 占YouTube視頻播放數的30-40百分位，同時之前從未出現在任何流行排行榜上。這個功能主要依賴于MongoDB，在MapReduce作業提供 了大量索引集的情況下，系統完全有能力以近實時速度完成數百萬實體上的查詢。

MongoDB在這個用例上表現的非常好，然而其中一直存在索引限制問題。Next Big Sound一直在挑戰這個瓶頸，ElasticSearch得到了重點關注。

內部服務

產品使用了所有度量數據，API 由1個內部Finagle服務支撐，從HBase和MySQL中讀取數據。這個服務被分為多個層（同一個代碼運行），關鍵、低延時層通常直接被產品使用， 一個具備更高吞吐量、高延時的二級層則被用作編程客戶端。后兩個方向一般具有更多的突發性和不可知性，因此使用這樣的分離層可以給客戶交付更低的延時。這 樣的分層同樣有利于為核心層建立更小的虛擬機，將Finagle剩余的服務器共至于Hadoop/HBase機器上。

Next Big Sound API

支撐Next Big Sound內外共同使用的主API已經過多次迭代，下面是一些重點建議：

1. 不要建立一個只體現方法的API，建立一個模型化系統實體的API，使用HTTP（GET、PUT、POST、HEAD、PATCH、DELETE）處理這些實體行為，這樣會讓API更容易預測和實驗。
2. 對 于依賴實體關系的方法，為主實體使用類似“字段”里的參數，讓它提供重點關注的實體關系。在Next Big Sound，這就意味著API將提供一個帶有“字段”參數的“藝術家”方法，如果這個字段被設置成“id、name”，那么將允許返回這個藝術家的姓名； 如果將這個字段設置成“id、name、profiles、videos”，那么將允許返回藝術家在YouTube頻道上的信息以及所有視頻。讀取實體之 間的關系可能有很大的開銷，這種方法可以適當的避免數據庫查詢，并拋棄一些丑陋的組合方法，比如“getArtistProfiles”或者 “getArtistVideos”。
3. 使用外部API來建立應用程序的好處已眾所周知，但是在實踐的過程中還發現一些比較隱晦的益處， 比如給項目添加新Web工程師。Next Big Sound之前在API調用和JS代碼之間添加了一些PHP代碼，而現在則嚴格限制JavaScript和API之間的交互。這就意味著Web開發者可以 專注于瀏覽器代碼，而在使用Backbone及Angular框架后更是如虎添翼。

提醒和基準

在音樂的世界里隨時都有事情發生，為了獲得“有意義”的事情，Next Big Sound必須在所有平臺建立基準數據（比如Facebook 每天產生like的數量），并提醒客戶。開始時也遇到過許多擴展性問題，但是在使用Pig/Hadoop做處理并將結果儲存在MongoDB或MySQL 后，事情簡單了起來。Next Big Sound所做的工作就是發現趨勢，那么給“有意義”設立臨界值就變得至關重要，因此在做基準時必須使用盡可能多的數據，而不是只從某個數據上入手，與基 準線的偏離量將代表了一切。

Billboard Charts

Next Big Sound被授權做兩個Billboard 雜志排行榜，一個是藝術家在線流行指數總排行，另一個是哪個藝術家可能會在未來排行榜上占據一席之地。這個功能并未造成任何擴展性問題，因為只是做所有藝 術家得分的一個反向排行，但是制造一個無重復、有價值的列表顯然需要考慮更多因素。非實名給系統帶來了大量麻煩（比如Justin Bieber的Twitter用戶名到底是"justinbieber"、"bieber"及"bieberofficial"中的哪一個），通常情況 下，會采用機器和人工組合來解決這個問題?；?個人名的選錯會產生重大影響，手動完成則必不可少。隨后發現，為在系統上增加這個“功能”，即讓它記住類 似的處理方法并有能力重現將變得非常有效，幸運的是，這個系統實現難度并不大。

預測Billboard得分

在 哪個藝術家將會在下一個年度爆發的預測上曾開發了一個專利算法，這個過程應用了Stochastic Gradient Boosting技術，分析基于不同社交媒體成員的傳播能力。在數學方面，實現難度比較大，因為許多使用的工具都非Hadoop友好實現，同時也發現 Mahout表現非常一般。這里的處理過程包括輸入數據集、通過MapReduce作業寫入MongoDB或者是Impala，通過R-MongoDB或 者R-Impala來兼容R，然后使用R的并行處理庫在大型機上處理，比如multicore。讓Hadoop承擔大部分負載和大型機承擔剩余負載帶來了 很多局限性，不幸的是，暫時未發現更好的解決辦法，或許RHadoop是最好的期望。

托管

1. 必須擁有自己的網絡解決方案。如果你想從小的團隊開始，確保你團隊中有人精通這個，如果沒有的話必須立刻雇傭。這曾是Next Big Sound最大的痛點，也是導致一些重大宕機的原因。

2. 在 不同的主機托管提供商之間轉移總是很棘手，但是如果你有充足的額外預算去支付兩個環境運行主機的開銷，那么風險將不會存在。拋開一些不可避免的異常，在關 閉舊供應商的服務之前，將架構完全復制到新服務供應商，并做一些改進。使用提供商服務往往伴隨著各種各樣的問題，對比因此耗費的工作及宕機時間來說，資金 節省根本不值一提。

3. Next Big Sound有90%的工作負載都運行在 Hadoop/HBase上，鑒于大部分的工作都是數據分析而非用戶帶訪問網站產生，因此峰值出現的很少，也就造成了使用提供商服務開銷很難比自己托管服 務器低的局面。Next Big Sound周期性的購買容量，但是容量增加更意味著獲得了更大的客戶或者是數據合作伙伴，這也是為什么使用自己硬件可以每個月節省2萬美元的原因。

經驗

1. 如果你從很多的數據源中收集數據，同時還需要做適度的轉換，錯誤不可避免會發生。大多數情況下，這些錯誤都非常明顯，在投入生產之前給予解決；但是也有一些時候，你需要做充足的準備以應對生產過程中發生的錯誤。下面是一些生產過程中發現的錯誤：

• Twitter上藝術家TB級數據集的收集，并在1到2天內加載到數據庫。
• 為了證明自己應對交期，告訴客戶數據已經可用。
• （1個月的）等待，為什么有20%的追隨者都在Kansas，Bumblefuck？
• 地理名稱轉換代碼將“US”譯為國家的中部。
• 因為客戶仍然在使用數據集正確的部分導致無法刪除，只能對之再加工，并重新寫入數據庫，修改所有代碼讓之讀取兩個表格，只在新表格中沒有這條記錄時才讀取舊表格，只在所有再處理結束后才可以刪除舊表格。
• 近百行的套管程序，直至幾天后，作業完成。

在這些情景下可能存在更明智的做法，直到出現的次數足夠多，你才會明確需要修改這些不能被完全刪除的生產數據并重建，這也是為什么Next Big Sound為之專門建立系統的原因。

2. 多數的數據都使用Pig 建立并處理，幾乎所有的工程師都會使用它。因此，工程師們一直在致力研究Pig，這里不得不提到Netflix的Lipstick，非常有效。這個過程中 還發現，取代可見性，降低Pig上開發迭代的時間也非常重要。同時，在測試之前，花時間為產生20+ Hadoop作業的長期運行腳本建立樣本輸入數據集也非常重要。

3. 關于HBase和Cassandra，在使用之前討論這兩個技術的優劣純粹是浪費時間，只要弄懂這兩個技術，它們都會提供一個穩健且高效的平臺。當然，你必須基于自己的數據模型和使用場景在這兩個技術之間做選擇。