作者：王勁

本文是酷狗音樂的架構(gòu)師王勁對酷狗大數(shù)據(jù)架構(gòu)重構(gòu)的總結(jié)。酷狗音樂的大數(shù)據(jù)架構(gòu)本身很經(jīng)典，而這篇講解了對原來的架構(gòu)上進(jìn)行重構(gòu)的工作內(nèi)容，總共分為重構(gòu)的原因、新一代的大數(shù)據(jù)技術(shù)架構(gòu)、踩過的坑、后續(xù)持續(xù)改進(jìn)四個(gè)部分來給大家談酷狗音樂大數(shù)據(jù)平臺(tái)重構(gòu)的過程。

眨眼就是新的一年了，時(shí)間過的真快，趁這段時(shí)間一直在寫總結(jié)的機(jī)會(huì)，也總結(jié)下上一年的工作經(jīng)驗(yàn)，避免重復(fù)踩坑。酷狗音樂大數(shù)據(jù)平臺(tái)重構(gòu)整整經(jīng)歷了一年時(shí)間，大頭的行為流水?dāng)?shù)據(jù)遷移到新平臺(tái)穩(wěn)定運(yùn)行，在這過程中填過坑，挖過坑，為后續(xù)業(yè)務(wù)的實(shí)時(shí)計(jì)算需求打下了很好的基礎(chǔ)。在此感謝酷狗團(tuán)隊(duì)成員的不懈努力，大部分從開始只知道大數(shù)據(jù)這個(gè)概念，到現(xiàn)在成為團(tuán)隊(duì)的技術(shù)支柱，感到很欣慰。

從重構(gòu)原因，技術(shù)架構(gòu)，踩過的坑，后續(xù)持續(xù)改進(jìn)四個(gè)方面來描述酷狗音樂大數(shù)據(jù)平臺(tái)重構(gòu)的過程，在此拋磚引玉，這次的內(nèi)容與6月份在高可用架構(gòu)群分享的大數(shù)據(jù)技術(shù)實(shí)踐的有點(diǎn)不同，技術(shù)架構(gòu)做了些調(diào)整。

其實(shí)大數(shù)據(jù)平臺(tái)是一個(gè)龐大的系統(tǒng)工程，整個(gè)建設(shè)周期很長，涉及的生態(tài)鏈很長(包括：數(shù)據(jù)采集、接入，清洗、存儲(chǔ)計(jì)算、數(shù)據(jù)挖掘，可視化等環(huán)節(jié)，每個(gè)環(huán)節(jié)都當(dāng)做一個(gè)復(fù)雜的系統(tǒng)來建設(shè))，風(fēng)險(xiǎn)也很大。

重構(gòu)原因

在講重構(gòu)原因前，先介紹下原有的大數(shù)據(jù)平臺(tái)架構(gòu)，如下圖：

數(shù)據(jù)采集：

數(shù)據(jù)收集接口眾多，且數(shù)據(jù)格式混亂，基本每個(gè)業(yè)務(wù)都有自己的上報(bào)接口

存在較大的重復(fù)開發(fā)成本

不能匯總上報(bào)，消耗客戶端資源，以及網(wǎng)絡(luò)流量

每個(gè)接口收集數(shù)據(jù)項(xiàng)和格式不統(tǒng)一，加大后期數(shù)據(jù)統(tǒng)計(jì)分析難度

各個(gè)接口實(shí)現(xiàn)質(zhì)量并不高，存在被刷，泄密等風(fēng)險(xiǎn)

數(shù)據(jù)接入:

通過rsync同步文件，很難滿足實(shí)時(shí)流計(jì)算的需求

接入數(shù)據(jù)出現(xiàn)異常后，很難排查及定位問題，需要很高的人力成本排查

業(yè)務(wù)系統(tǒng)數(shù)據(jù)通過Kettle每天全量同步到數(shù)據(jù)中心，同步時(shí)間長，導(dǎo)致依賴的作業(yè)經(jīng)常會(huì)有延時(shí)現(xiàn)象

數(shù)據(jù)清洗：

ETL集中在作業(yè)計(jì)算前進(jìn)行處理

存在重復(fù)清洗

作業(yè)調(diào)度：

大部分作業(yè)通過crontab調(diào)度，作業(yè)多了后不利于管理

經(jīng)常出現(xiàn)作業(yè)調(diào)度沖突

平臺(tái)監(jiān)控：

只有硬件與操作系統(tǒng)級(jí)監(jiān)控

數(shù)據(jù)平臺(tái)方面的監(jiān)控等于空白

基于以上問題，結(jié)合在大數(shù)據(jù)中，數(shù)據(jù)的時(shí)效性越高，數(shù)據(jù)越有價(jià)值(如：實(shí)時(shí)個(gè)性化推薦系統(tǒng)，RTB系統(tǒng)，實(shí)時(shí)預(yù)警系統(tǒng)等)的理念，因此，開始大重構(gòu)數(shù)據(jù)平臺(tái)架構(gòu)。

新一代大數(shù)據(jù)技術(shù)架構(gòu)

在講新一代大數(shù)據(jù)技術(shù)架構(gòu)前，先講下大數(shù)據(jù)特征與大數(shù)據(jù)技術(shù)要解決的問題。

1.大數(shù)據(jù)特征：“大量化(Volume)、多樣化(Variety)、快速化(Velocity)、價(jià)值密度低(Value)”就是“大數(shù)據(jù)”顯著的4V特征，或者說，只有具備這些特點(diǎn)的數(shù)據(jù)，才是大數(shù)據(jù)。

新一代大數(shù)據(jù)整體技術(shù)架構(gòu)如圖：

整體架構(gòu)從下往上解釋下每層的作用：

數(shù)據(jù)實(shí)時(shí)采集：

主要用于數(shù)據(jù)源采集服務(wù)，從數(shù)據(jù)流架構(gòu)圖中，可以知道，數(shù)據(jù)源分為前端日志，服務(wù)端日志，業(yè)務(wù)系統(tǒng)數(shù)據(jù)。下面講解數(shù)據(jù)是怎么采集接入的。

a.前端日志采集接入：

前端日志采集要求實(shí)時(shí)，可靠性，高可用性等特性。技術(shù)選型時(shí)，對開源的數(shù)據(jù)采集工具flume,scribe,chukwa測試對比，發(fā)現(xiàn)基本滿足不了我們的業(yè)務(wù)場景需求。所以，選擇基于kafka開發(fā)一套數(shù)據(jù)采集網(wǎng)關(guān)，來完成數(shù)據(jù)采集需求。數(shù)據(jù)采集網(wǎng)關(guān)的開發(fā)過程中走了一些彎路，最后采用nginx lua開發(fā)，基于lua實(shí)現(xiàn)了kafka生產(chǎn)者協(xié)議。有興趣同學(xué)可以去Github上看看，另一同事實(shí)現(xiàn)的，現(xiàn)在在github上比較活躍，被一些互聯(lián)網(wǎng)公司應(yīng)用于線上環(huán)境了。

b.后端日志采集接入：

FileCollect,考慮到很多線上環(huán)境的環(huán)境變量不能改動(dòng)，為減少侵入式，目前是采用Go語言實(shí)現(xiàn)文件采集，年后也準(zhǔn)備重構(gòu)這塊。

前端，服務(wù)端的數(shù)據(jù)采集整體架構(gòu)如下圖：

利用Canal通過MySQL的binlog機(jī)制實(shí)時(shí)同步業(yè)務(wù)增量數(shù)據(jù)。

數(shù)據(jù)統(tǒng)一接入：為了后面數(shù)據(jù)流環(huán)節(jié)的處理規(guī)范，所有的數(shù)據(jù)接入數(shù)據(jù)中心，必須通過數(shù)據(jù)采集網(wǎng)關(guān)轉(zhuǎn)換統(tǒng)一上報(bào)給Kafka集群，避免后端多種接入方式的處理問題。

數(shù)據(jù)實(shí)時(shí)清洗(ETL)：為了減輕存儲(chǔ)計(jì)算集群的資源壓力及數(shù)據(jù)可重用性角度考慮，把數(shù)據(jù)解壓、解密、轉(zhuǎn)義，部分簡單的補(bǔ)全，異常數(shù)據(jù)處理等工作前移到數(shù)據(jù)流中處理，為后面環(huán)節(jié)的數(shù)據(jù)重用打下扎實(shí)的基礎(chǔ)(實(shí)時(shí)計(jì)算與離線計(jì)算)。

數(shù)據(jù)緩存重用：為了避免大量數(shù)據(jù)流(400 億條/天)寫入HDFS，導(dǎo)致HDFS客戶端不穩(wěn)定現(xiàn)象及數(shù)據(jù)實(shí)時(shí)性考慮，把經(jīng)過數(shù)據(jù)實(shí)時(shí)清洗后的數(shù)據(jù)重新寫入Kafka并保留一定周期，離線計(jì)算(批處理)通過KG-Camus拉到HDFS(通過作業(yè)調(diào)度系統(tǒng)配置相應(yīng)的作業(yè)計(jì)劃)，實(shí)時(shí)計(jì)算基于Storm/JStorm直接從Kafka消費(fèi)，有很完美的解決方案storm-kafka組件。

離線計(jì)算(批處理)：通過spark，spark SQL實(shí)現(xiàn)，整體性能比hive提高5—10倍，hive腳本都在轉(zhuǎn)換為Spark/Spark SQL;部分復(fù)雜的作業(yè)還是通過Hive/Spark的方式實(shí)現(xiàn)。在離線計(jì)算中大部分公司都會(huì)涉及到數(shù)據(jù)倉庫的問題，酷狗音樂也不例外，也有數(shù)據(jù)倉庫的概念，只是我們在做存儲(chǔ)分層設(shè)計(jì)時(shí)弱化了數(shù)據(jù)倉庫概念。數(shù)據(jù)存儲(chǔ)分層模型如下圖：

數(shù)據(jù)緩沖層(DCL)：存儲(chǔ)業(yè)務(wù)系統(tǒng)或者客戶端上報(bào)的，經(jīng)過解碼、清洗、轉(zhuǎn)換后的原始數(shù)據(jù)，為數(shù)據(jù)過濾做準(zhǔn)備。

數(shù)據(jù)明細(xì)層(DDL)：存儲(chǔ)接口緩沖層數(shù)據(jù)經(jīng)過過濾后的明細(xì)數(shù)據(jù)。

公共數(shù)據(jù)層(Common)：主要存儲(chǔ)維表數(shù)據(jù)與外部業(yè)務(wù)系統(tǒng)數(shù)據(jù)。

數(shù)據(jù)匯總層(DSL)：存儲(chǔ)對明細(xì)數(shù)據(jù)，按業(yè)務(wù)主題，與公共數(shù)據(jù)層數(shù)據(jù)進(jìn)行管理后的用戶行為主題數(shù)據(jù)、用戶行為寬表數(shù)據(jù)、輕量匯總數(shù)據(jù)等。為數(shù)據(jù)應(yīng)用層統(tǒng)計(jì)計(jì)算提供基礎(chǔ)數(shù)據(jù)。數(shù)據(jù)匯總層的數(shù)據(jù)永久保存在集群中。

數(shù)據(jù)應(yīng)用層(DAL)：存儲(chǔ)運(yùn)營分析(Operations Analysis )、指標(biāo)體系(Metrics System)、線上服務(wù)(Online Service)與用戶分析(User Analysis)等。需要對外輸出的數(shù)據(jù)都存儲(chǔ)在這一層。主要基于熱數(shù)據(jù)部分對外提供服務(wù)，通過一定周期的數(shù)據(jù)還需要到DSL層裝載查詢。

數(shù)據(jù)分析層(Analysis)：存儲(chǔ)對數(shù)據(jù)明細(xì)層、公共數(shù)據(jù)層、數(shù)據(jù)匯總層關(guān)聯(lián)后經(jīng)過算法計(jì)算的、為推薦、廣告、榜單等數(shù)據(jù)挖掘需求提供中間結(jié)果的數(shù)據(jù)。

臨時(shí)提數(shù)層(Temp)：存儲(chǔ)臨時(shí)提數(shù)、數(shù)據(jù)質(zhì)量校驗(yàn)等生產(chǎn)的臨時(shí)數(shù)據(jù)。

實(shí)時(shí)計(jì)算：基于Storm/JStorm，Drools,Esper。主要應(yīng)用于實(shí)時(shí)監(jiān)控系統(tǒng)、APM、數(shù)據(jù)實(shí)時(shí)清洗平臺(tái)、實(shí)時(shí)DAU統(tǒng)計(jì)等。

HBase/MySQL：用于實(shí)時(shí)計(jì)算，離線計(jì)算結(jié)果存儲(chǔ)服務(wù)。

Redis：用于中間計(jì)算結(jié)果存儲(chǔ)或字典數(shù)據(jù)等。

Elasticsearch：用于明細(xì)數(shù)據(jù)實(shí)時(shí)查詢及HBase的二級(jí)索引存儲(chǔ)(這塊目前在數(shù)據(jù)中心還沒有大規(guī)模使用，有興趣的同學(xué)可以加入我們一起玩ES)。

Druid：目前用于支持大數(shù)據(jù)集的快速即席查詢(ad-hoc)。

數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)：數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)包括基礎(chǔ)平臺(tái)監(jiān)控系統(tǒng)與數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，數(shù)據(jù)平臺(tái)監(jiān)控系統(tǒng)分為2大方向，宏觀層面和微觀層面。宏觀角度的理解就是進(jìn)程級(jí)別,拓?fù)浣Y(jié)構(gòu)級(jí)別,拿Hadoop舉例，如：DataNode，NameNode，JournalNode，ResourceManager，NodeManager，主要就是這5大組件，通過分析這些節(jié)點(diǎn)上的監(jiān)控?cái)?shù)據(jù)，一般你能夠定位到慢節(jié)點(diǎn)，可能某臺(tái)機(jī)器的網(wǎng)絡(luò)出問題了，或者說某臺(tái)機(jī)器執(zhí)行的時(shí)間總是大于正常機(jī)器等等這樣類似的問題。剛剛說的另一個(gè)監(jiān)控方向，就是微觀層面，就是細(xì)粒度化的監(jiān)控，基于user用戶級(jí)別，基于單個(gè)job，單個(gè)task級(jí)別的監(jiān)控，像這類監(jiān)控指標(biāo)就是另一大方向，這類的監(jiān)控指標(biāo)在實(shí)際的使用場景中特別重要，一旦你的集群資源是開放給外面的用戶使用，用戶本身不了解你的這套機(jī)制原理，很容易會(huì)亂申請資源，造成嚴(yán)重拖垮集群整體運(yùn)作效率的事情，所以這類監(jiān)控的指標(biāo)就是為了防止這樣的事情發(fā)生。目前我們主要實(shí)現(xiàn)了宏觀層面的監(jiān)控。如：數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)實(shí)現(xiàn)方案如下。

大數(shù)據(jù)平臺(tái)重構(gòu)過程中踩過的坑

我們在大數(shù)據(jù)平臺(tái)重構(gòu)過程中踩過的坑，大致可以分為操作系統(tǒng)、架構(gòu)設(shè)計(jì)、開源組件三類，下面主要列舉些比較典型的，花時(shí)間比較長的問題。

1. 操作系統(tǒng)級(jí)的坑

Hadoop的I/O性能很大程度上依賴于Linux本地文件系統(tǒng)的讀寫性能。Linux中有多種文件系統(tǒng)可供選擇，比如ext3和ext4，不同的文件系統(tǒng)性能有一定的差別。我們主要想利用ext4文件系統(tǒng)的特性，由于之前的操作系統(tǒng)都是CentOS5.9不支持ext4文件格式，所以考慮操作系統(tǒng)升級(jí)為CentOS6.3版本，部署Hadoop集群后，作業(yè)一啟動(dòng)，就出現(xiàn)CPU內(nèi)核過高的問題。如下圖：

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

最初的數(shù)據(jù)流架構(gòu)是數(shù)據(jù)采集網(wǎng)關(guān)把數(shù)據(jù)上報(bào)給Kafka，再由數(shù)據(jù)實(shí)時(shí)清洗平臺(tái)(ETL)做預(yù)處理后直接實(shí)時(shí)寫入HDFS，如下圖：

每天異常不斷，舊異常沒解決，新異常又來了，在壓力山大的情況下，考慮從架構(gòu)角度調(diào)整，不能只從具體的技術(shù)點(diǎn)去優(yōu)化了，在做架構(gòu)調(diào)整時(shí)，考慮到我們架構(gòu)重構(gòu)的初衷，提高數(shù)據(jù)的實(shí)時(shí)性，盡量讓計(jì)算任務(wù)實(shí)時(shí)化，但重構(gòu)過程中要考慮現(xiàn)有業(yè)務(wù)的過渡，所以架構(gòu)必須支持實(shí)時(shí)與離線的需求，結(jié)合這些需求，在數(shù)據(jù)實(shí)時(shí)清洗平臺(tái)(ETL)后加了一層數(shù)據(jù)緩存重用層(kafka)，也就是經(jīng)過數(shù)據(jù)實(shí)時(shí)清洗平臺(tái)后的數(shù)據(jù)還是寫入kafka集群，由于kafka支持重復(fù)消費(fèi)，所以同一份數(shù)據(jù)可以既滿足實(shí)時(shí)計(jì)算也滿足離線計(jì)算，從上面的整體技術(shù)架構(gòu)也可以看出，如下圖：

這個(gè)坑，是我自己給自己挖的，導(dǎo)致我們的重構(gòu)計(jì)劃延期2個(gè)月，主要原因是由最初技術(shù)預(yù)研究測試不充分所導(dǎo)致。

3.開源組件的坑

由于整個(gè)數(shù)據(jù)平臺(tái)涉及到的開源組件很多，踩過的坑也是十個(gè)手指數(shù)不過來。

1)、當(dāng)我們的行為數(shù)據(jù)全量接入到Kafka集群(幾百億/天)，數(shù)據(jù)采集網(wǎng)卡出現(xiàn)大量連接超時(shí)現(xiàn)象，但萬兆網(wǎng)卡進(jìn)出流量使用率并不是很高，只有幾百M(fèi)bit/s，經(jīng)過大量的測試排查后，調(diào)整以下參數(shù)，就是順利解決了此問題。調(diào)整參數(shù)后網(wǎng)卡流量如下圖：

a)、num.network.threads(網(wǎng)絡(luò)處理線程數(shù))值應(yīng)該比cpu數(shù)略大

b)、num.io.threads(接收網(wǎng)絡(luò)線程請求并處理線程數(shù))值提高為cpu數(shù)兩倍

3)、在業(yè)務(wù)實(shí)時(shí)監(jiān)控系統(tǒng)中，用OpenTSDB與實(shí)時(shí)計(jì)算系統(tǒng)(storm)結(jié)合，用于聚合并存儲(chǔ)實(shí)時(shí)metric數(shù)據(jù)。在這種實(shí)現(xiàn)中，通常需要在實(shí)時(shí)計(jì)算部分使用一個(gè)時(shí)間窗口(window)，用于聚合實(shí)時(shí)數(shù)據(jù)，然后將聚合結(jié)果寫入tsdb。但是，由于在實(shí)際情況中，實(shí)時(shí)數(shù)據(jù)在采集、上報(bào)階段可能會(huì)存在延時(shí)，而導(dǎo)致tsdb寫入的數(shù)據(jù)不準(zhǔn)確。針對這個(gè)問題，我們做了一個(gè)改進(jìn)，在原有tsdb寫入api的基礎(chǔ)上，增加了一個(gè)原子加的api。這樣，延遲到來的數(shù)據(jù)會(huì)被疊加到之前寫入的數(shù)據(jù)之上，實(shí)時(shí)的準(zhǔn)確性由于不可避免的原因(采集、上報(bào)階段)產(chǎn)生了延遲，到最終的準(zhǔn)確性也可以得到保證。另外，添加了這個(gè)改進(jìn)之后，實(shí)時(shí)計(jì)算端的時(shí)間窗口就不需要因?yàn)榭紤]延遲問題設(shè)置得比較大，這樣既節(jié)省了內(nèi)存的消耗，也提高了實(shí)時(shí)性。

后續(xù)持續(xù)改進(jìn)

數(shù)據(jù)存儲(chǔ)(分布式內(nèi)存文件系統(tǒng)(Tachyon)、數(shù)據(jù)多介質(zhì)分層存儲(chǔ)、數(shù)據(jù)列式存儲(chǔ))、即席查詢(OLAP)、資源隔離、數(shù)據(jù)安全、平臺(tái)微觀層面監(jiān)控、數(shù)據(jù)對外服務(wù)等。

作者介紹：王勁：目前就職酷狗音樂，大數(shù)據(jù)架構(gòu)師，負(fù)責(zé)酷狗大數(shù)據(jù)技術(shù)規(guī)劃、建設(shè)、應(yīng)用。 11年的IT從業(yè)經(jīng)驗(yàn)，2年分布式應(yīng)用開發(fā)，3年大數(shù)據(jù)技術(shù)實(shí)踐經(jīng)驗(yàn)，主要研究方向流式計(jì)算、大數(shù)據(jù)存儲(chǔ)計(jì)算、分布式存儲(chǔ)系統(tǒng)、NoSQL、搜索引擎等。

End.

轉(zhuǎn)載請注明來自36大數(shù)據(jù)（)：36大數(shù)據(jù) ? 經(jīng)典大數(shù)據(jù)架構(gòu)案例：酷狗音樂的大數(shù)據(jù)平臺(tái)重構(gòu)(長文)