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

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

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

Next Big Sound一直保持著非常小的工程團(tuán)隊(duì)，使用開(kāi)源技術(shù)搭建整個(gè)系統(tǒng)，采用過(guò)完全云架構(gòu)（Slicehost）、混合云架構(gòu)（Rackspace）、主機(jī)托管（Zcolo）等不同架構(gòu)形式。

統(tǒng)計(jì)

• 40個(gè)節(jié)點(diǎn)的Hadoop集群（150TB容量），約60個(gè)OpenStack虛擬機(jī)
• 10TB的非重復(fù)、已壓縮的數(shù)值型數(shù)據(jù)（6TB原始、4TB索引）
• 10個(gè)工程師，總計(jì)22人
• 5年的開(kāi)發(fā)
• 每天30萬(wàn)時(shí)間序列查詢
• 峰值期間每天400GB新數(shù)據(jù)
• 記錄百萬(wàn)藝術(shù)家超過(guò)萬(wàn)億的事件，包括了YouTube音樂(lè)視頻訪問(wèn)數(shù)、Twitter上轉(zhuǎn)發(fā)和@藝術(shù)家的數(shù)量、iTunes購(gòu)買數(shù)以及在線廣播流。

平臺(tái)

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

存儲(chǔ)架構(gòu)

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

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

在Hadoop 基礎(chǔ)設(shè)施方面，同樣面臨了很多難題：1，跨整個(gè)音樂(lè)產(chǎn)業(yè)的社交網(wǎng)絡(luò)和內(nèi)容發(fā)布網(wǎng)站的實(shí)體關(guān)系映射；2，貫穿上千萬(wàn)數(shù)據(jù)集建立用于排序和搜索的Web應(yīng) 用；3，管理數(shù)百萬(wàn)API調(diào)用的信息以及網(wǎng)絡(luò)爬蟲。這些操作都產(chǎn)生了特定的需求，而在Next Big Sound，系統(tǒng)完全建立在開(kāi)源技術(shù)之上，下面是一個(gè)概況圖（點(diǎn)擊查看大圖）：

數(shù)據(jù)顯示

測(cè)量?jī)x表盤一直都是個(gè)進(jìn)行中的項(xiàng)目，這個(gè)工作大部分由用戶需求主導(dǎo)。由于數(shù)據(jù)源太多，這里的長(zhǎng)期目標(biāo)是做靈活性和學(xué)習(xí)曲線之間的平衡；同時(shí)，由于新客戶和特性的增加，維持一個(gè)連續(xù)的JavaScript/PHP代碼庫(kù)進(jìn)行管理也變得愈加困難。Next Big Sound操作如下：

• 開(kāi)始使用簡(jiǎn)單的Codeigniter應(yīng)用，盡可能的嘗試添加Backbone，當(dāng)下已戰(zhàn)略性的轉(zhuǎn)向Angular。
• 使用Memcache緩存大型靜態(tài)對(duì)象。
• 度量數(shù)據(jù)的緩存和歷史記錄使用本地存儲(chǔ)。
• 使用D3做圖，之前使用的是Rickshaw。

沒(méi)有做功能標(biāo)志，但是使用了自己的方法。如果某個(gè)代碼庫(kù)經(jīng)常被重寫，這點(diǎn)將非常重要，沒(méi)有它，很多事情我們都完成不了。

FIND

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

MongoDB在這個(gè)用例上表現(xiàn)的非常好，然而其中一直存在索引限制問(wèn)題。Next Big Sound一直在挑戰(zhàn)這個(gè)瓶頸，ElasticSearch得到了重點(diǎn)關(guān)注。

內(nèi)部服務(wù)

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

Next Big Sound API

支撐Next Big Sound內(nèi)外共同使用的主API已經(jīng)過(guò)多次迭代，下面是一些重點(diǎn)建議：

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

提醒和基準(zhǔn)

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

Billboard Charts

Next Big Sound被授權(quán)做兩個(gè)Billboard 雜志排行榜，一個(gè)是藝術(shù)家在線流行指數(shù)總排行，另一個(gè)是哪個(gè)藝術(shù)家可能會(huì)在未來(lái)排行榜上占據(jù)一席之地。這個(gè)功能并未造成任何擴(kuò)展性問(wèn)題，因?yàn)橹皇亲鏊兴? 術(shù)家得分的一個(gè)反向排行，但是制造一個(gè)無(wú)重復(fù)、有價(jià)值的列表顯然需要考慮更多因素。非實(shí)名給系統(tǒng)帶來(lái)了大量麻煩（比如Justin Bieber的Twitter用戶名到底是"justinbieber"、"bieber"及"bieberofficial"中的哪一個(gè)），通常情況 下，會(huì)采用機(jī)器和人工組合來(lái)解決這個(gè)問(wèn)題。基于1個(gè)人名的選錯(cuò)會(huì)產(chǎn)生重大影響，手動(dòng)完成則必不可少。隨后發(fā)現(xiàn)，為在系統(tǒng)上增加這個(gè)“功能”，即讓它記住類 似的處理方法并有能力重現(xiàn)將變得非常有效，幸運(yùn)的是，這個(gè)系統(tǒng)實(shí)現(xiàn)難度并不大。

預(yù)測(cè)Billboard得分

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

托管

1. 必須擁有自己的網(wǎng)絡(luò)解決方案。如果你想從小的團(tuán)隊(duì)開(kāi)始，確保你團(tuán)隊(duì)中有人精通這個(gè)，如果沒(méi)有的話必須立刻雇傭。這曾是Next Big Sound最大的痛點(diǎn)，也是導(dǎo)致一些重大宕機(jī)的原因。

2. 在 不同的主機(jī)托管提供商之間轉(zhuǎn)移總是很棘手，但是如果你有充足的額外預(yù)算去支付兩個(gè)環(huán)境運(yùn)行主機(jī)的開(kāi)銷，那么風(fēng)險(xiǎn)將不會(huì)存在。拋開(kāi)一些不可避免的異常，在關(guān) 閉舊供應(yīng)商的服務(wù)之前，將架構(gòu)完全復(fù)制到新服務(wù)供應(yīng)商，并做一些改進(jìn)。使用提供商服務(wù)往往伴隨著各種各樣的問(wèn)題，對(duì)比因此耗費(fèi)的工作及宕機(jī)時(shí)間來(lái)說(shuō)，資金 節(jié)省根本不值一提。

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

經(jīng)驗(yàn)

1. 如果你從很多的數(shù)據(jù)源中收集數(shù)據(jù)，同時(shí)還需要做適度的轉(zhuǎn)換，錯(cuò)誤不可避免會(huì)發(fā)生。大多數(shù)情況下，這些錯(cuò)誤都非常明顯，在投入生產(chǎn)之前給予解決；但是也有一些時(shí)候，你需要做充足的準(zhǔn)備以應(yīng)對(duì)生產(chǎn)過(guò)程中發(fā)生的錯(cuò)誤。下面是一些生產(chǎn)過(guò)程中發(fā)現(xiàn)的錯(cuò)誤：

• Twitter上藝術(shù)家TB級(jí)數(shù)據(jù)集的收集，并在1到2天內(nèi)加載到數(shù)據(jù)庫(kù)。
• 為了證明自己應(yīng)對(duì)交期，告訴客戶數(shù)據(jù)已經(jīng)可用。
• （1個(gè)月的）等待，為什么有20%的追隨者都在Kansas，Bumblefuck？
• 地理名稱轉(zhuǎn)換代碼將“US”譯為國(guó)家的中部。
• 因?yàn)榭蛻羧匀辉谑褂脭?shù)據(jù)集正確的部分導(dǎo)致無(wú)法刪除，只能對(duì)之再加工，并重新寫入數(shù)據(jù)庫(kù)，修改所有代碼讓之讀取兩個(gè)表格，只在新表格中沒(méi)有這條記錄時(shí)才讀取舊表格，只在所有再處理結(jié)束后才可以刪除舊表格。
• 近百行的套管程序，直至幾天后，作業(yè)完成。

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

2. 多數(shù)的數(shù)據(jù)都使用Pig 建立并處理，幾乎所有的工程師都會(huì)使用它。因此，工程師們一直在致力研究Pig，這里不得不提到Netflix的Lipstick，非常有效。這個(gè)過(guò)程中 還發(fā)現(xiàn)，取代可見(jiàn)性，降低Pig上開(kāi)發(fā)迭代的時(shí)間也非常重要。同時(shí)，在測(cè)試之前，花時(shí)間為產(chǎn)生20+ Hadoop作業(yè)的長(zhǎng)期運(yùn)行腳本建立樣本輸入數(shù)據(jù)集也非常重要。

3. 關(guān)于HBase和Cassandra，在使用之前討論這兩個(gè)技術(shù)的優(yōu)劣純粹是浪費(fèi)時(shí)間，只要弄懂這兩個(gè)技術(shù)，它們都會(huì)提供一個(gè)穩(wěn)健且高效的平臺(tái)。當(dāng)然，你必須基于自己的數(shù)據(jù)模型和使用場(chǎng)景在這兩個(gè)技術(shù)之間做選擇。