眨眼就是新的一年了,時間過的真快,趁這段時間一直在寫總結的機會,也總結下上一年的工做經驗,避免重複踩坑。酷狗音樂大數據平臺重構整整經歷了一年時間,大頭的行爲流水數據遷移到新平臺穩定運行,在這過程當中填過坑,挖過坑,爲後續業務的實時計算需求打下了很好的基礎。在此感謝酷狗團隊成員的不懈努力,大部分從開始只知道大數據這個概念,到如今成爲團隊的技術支柱,感到很欣慰。前端
從重構緣由,技術架構,踩過的坑,後續持續改進四個方面來描述酷狗音樂大數據平臺重構的過程,在此拋磚引玉,此次的內容與 6 月份在高可用架構羣分享的大數據技術實踐的有點不一樣,技術架構作了些調整。nginx
其實大數據平臺是一個龐大的系統工程,整個建設週期很長,涉及的生態鏈很長 (包括:數據採集、接入,清洗、存儲計算、數據挖掘,可視化等環節,每一個環節都當作一個複雜的系統來建設),風險也很大。git
重構緣由github
在講重構緣由前,先介紹下原有的大數據平臺架構,以下圖:算法
從上圖可知,主要基於 Hadoop1.x+hive 作離線計算 (T+1),基於大數據平臺的數據採集、數據接入、數據清洗、做業調度、平臺監控幾個環節存在的一些問題來列舉下。後端
數據採集:api
數據收集接口衆多,且數據格式混亂,基本每一個業務都有本身的上報接口緩存
存在較大的重複開發成本安全
不能彙總上報,消耗客戶端資源,以及網絡流量微信
每一個接口收集數據項和格式不統一,加大後期數據統計分析難度
各個接口實現質量並不高,存在被刷,泄密等風險
數據接入:
經過 rsync 同步文件,很難知足實時流計算的需求
接入數據出現異常後,很難排查及定位問題,須要很高的人力成本排查
業務系統數據經過 Kettle 天天全量同步到數據中心,同步時間長,致使依賴的做業常常會有延時現象
數據清洗:
ETL 集中在做業計算前進行處理
存在重複清洗
做業調度:
大部分做業經過 crontab 調度,做業多了後不利於管理
常常出現做業調度衝突
平臺監控:
只有硬件與操做系統級監控
數據平臺方面的監控等於空白
基於以上問題,結合在大數據中,數據的時效性越高,數據越有價值 (如:實時個性化推薦系統,RTB 系統,實時預警系統等) 的理念,所以,開始大重構數據平臺架構。
新一代大數據技術架構
在講新一代大數據技術架構前,先講下大數據特徵與大數據技術要解決的問題。
1. 大數據特徵:「大量化 (Volume)、多樣化 (Variety)、快速化 (Velocity)、價值密度低(Value)」就是「大數據」顯著的 4V 特徵,或者說,只有具有這些特色的數據,纔是大數據。
2. 大數據技術要解決的問題:大數據技術被設計用於在成本可承受的條件下,經過很是快速(velocity)地採集、發現和分析,從大量(volumes)、多類別(variety)的數據中提取價值(value),將是 IT 領域新一代的技術與架構。
介紹了大數據的特性及大數據技術要解決的問題,咱們先看看新一代大數據技術架構的數據流架構圖:
從這張圖中,能夠了解到大數據處理過程能夠分爲數據源、數據接入、數據清洗、數據緩存、存儲計算、數據服務、數據消費等環節,每一個環節都有具備高可用性、可擴展性等特性,都爲下一個節點更好的服務打下基礎。整個數據流過程都被數據質量監控系統監控,數據異常自動預警、告警。
新一代大數據總體技術架構如圖:
將大數據計算分爲實時計算與離線計算,在整個集羣中,奔着能實時計算的,必定走實時計算流處理,經過實時計算流來提升數據的時效性及數據價值,同時減輕集羣的資源使用率集中現象。
總體架構從下往上解釋下每層的做用:
數據實時採集:
主要用於數據源採集服務,從數據流架構圖中,能夠知道,數據源分爲前端日誌,服務端日誌,業務系統數據。下面講解數據是怎麼採集接入的。
a. 前端日誌採集接入:
前端日誌採集要求實時,可靠性,高可用性等特性。技術選型時,對開源的數據採集工具 flume,scribe,chukwa 測試對比,發現基本知足不了咱們的業務場景需求。因此,選擇基於 kafka 開發一套數據採集網關,來完成數據採集需求。數據採集網關的開發過程當中走了一些彎路,最後採用 nginx+lua 開發,基於 lua 實現了 kafka 生產者協議。有興趣同窗能夠去 Github 上看看,另外一同事實現的,如今在 github 上比較活躍,被一些互聯網公司應用於線上環境了。
FileCollect, 考慮到不少線上環境的環境變量不能改動,爲減小侵入式,目前是採用 Go 語言實現文件採集,年後也準備重構這塊。
前端,服務端的數據採集總體架構以下圖:
c. 業務數據接入
利用 Canal 經過 MySQL 的 binlog 機制實時同步業務增量數據。
數據統一接入:爲了後面數據流環節的處理規範,全部的數據接入數據中心,必須經過數據採集網關轉換統一上報給 Kafka 集羣,避免後端多種接入方式的處理問題。
數據實時清洗 (ETL):爲了減輕存儲計算集羣的資源壓力及數據可重用性角度考慮,把數據解壓、解密、轉義,部分簡單的補全,異常數據處理等工做前移到數據流中處理,爲後面環節的數據重用打下紮實的基礎 (實時計算與離線計算)。
數據緩存重用:爲了不大量數據流 (400+ 億條 / 天) 寫入 HDFS,致使 HDFS 客戶端不穩定現象及數據實時性考慮,把通過數據實時清洗後的數據從新寫入 Kafka 並保留必定週期,離線計算 (批處理) 經過 KG-Camus 拉到 HDFS(經過做業調度系統配置相應的做業計劃),實時計算基於 Storm/JStorm 直接從 Kafka 消費,有很完美的解決方案 storm-kafka 組件。
離線計算 (批處理):經過 spark,spark SQL 實現,總體性能比 hive 提升 5—10 倍,hive 腳本都在轉換爲 Spark/Spark SQL;部分複雜的做業仍是經過 Hive/Spark 的方式實現。在離線計算中大部分公司都會涉及到數據倉庫的問題,酷狗音樂也不例外,也有數據倉庫的概念,只是咱們在作存儲分層設計時弱化了數據倉庫概念。數據存儲分層模型以下圖:
大數據平臺數據存儲模型分爲:數據緩衝層 Data Cache Layer(DCL)、數據明細層 Data Detail Layer(DDL)、公共數據層(Common)、數據彙總層 Data Summary Layer(DSL)、數據應用層 Data Application Layer(DAL)、數據分析層(Analysis)、臨時提數層(Temp)。
數據緩衝層 (DCL):存儲業務系統或者客戶端上報的,通過解碼、清洗、轉換後的原始數據,爲數據過濾作準備。
數據明細層(DDL):存儲接口緩衝層數據通過過濾後的明細數據。
公共數據層(Common):主要存儲維表數據與外部業務系統數據。
數據彙總層(DSL):存儲對明細數據,按業務主題,與公共數據層數據進行管理後的用戶行爲主題數據、用戶行爲寬表數據、輕量彙總數據等。爲數據應用層統計計算提供基礎數據。數據彙總層的數據永久保存在集羣中。
數據應用層(DAL):存儲運營分析(Operations Analysis )、指標體系(Metrics System)、線上服務(Online Service)與用戶分析(User Analysis)等。須要對外輸出的數據都存儲在這一層。主要基於熱數據部分對外提供服務,經過必定週期的數據還須要到 DSL 層裝載查詢。
數據分析層(Analysis):存儲對數據明細層、公共數據層、數據彙總層關聯後通過算法計算的、爲推薦、廣告、榜單等數據挖掘需求提供中間結果的數據。
臨時提數層(Temp):存儲臨時提數、數據質量校驗等生產的臨時數據。
** 實時計算:** 基於 Storm/JStorm,Drools,Esper。主要應用於實時監控系統、APM、數據實時清洗平臺、實時 DAU 統計等。
HBase/MySQL:用於實時計算,離線計算結果存儲服務。
**Redis:** 用於中間計算結果存儲或字典數據等。
**Elasticsearch:** 用於明細數據實時查詢及 HBase 的二級索引存儲 (這塊目前在數據中心尚未大規模使用,有興趣的同窗能夠加入咱們一塊兒玩 ES)。
**Druid:** 目前用於支持大數據集的快速即席查詢 (ad-hoc)。
數據平臺監控系統:數據平臺監控系統包括基礎平臺監控系統與數據質量監控系統,數據平臺監控系統分爲 2 大方向,宏觀層面和微觀層面。宏觀角度的理解就是進程級別, 拓撲結構級別, 拿 Hadoop 舉例,如:DataNode,NameNode,JournalNode,ResourceManager,NodeManager,主要就是這 5 大組件,經過分析這些節點上的監控數據,通常你可以定位到慢節點,可能某臺機器的網絡出問題了,或者說某臺機器執行的時間老是大於正常機器等等這樣相似的問題。剛剛說的另外一個監控方向,就是微觀層面,就是細粒度化的監控,基於 user 用戶級別,基於單個 job,單個 task 級別的監控,像這類監控指標就是另外一大方向,這類的監控指標在實際的使用場景中特別重要,一旦你的集羣資源是開放給外面的用戶使用,用戶自己不瞭解你的這套機制原理,很容易會亂申請資源,形成嚴重拖垮集羣總體運做效率的事情,因此這類監控的指標就是爲了防止這樣的事情發生。目前咱們主要實現了宏觀層面的監控。如:數據質量監控系統實現方案以下。
大數據平臺重構過程當中踩過的坑
咱們在大數據平臺重構過程當中踩過的坑,大體能夠分爲操做系統、架構設計、開源組件三類,下面主要列舉些比較典型的,花時間比較長的問題。
1. 操做系統級的坑
Hadoop 的 I/O 性能很大程度上依賴於 Linux 本地文件系統的讀寫性能。Linux 中有多種文件系統可供選擇,好比 ext3 和 ext4,不一樣的文件系統性能有必定的差異。咱們主要想利用 ext4 文件系統的特性,因爲以前的操做系統都是 CentOS5.9 不支持 ext4 文件格式,因此考慮操做系統升級爲 CentOS6.3 版本,部署 Hadoop 集羣后,做業一啓動,就出現 CPU 內核太高的問題。以下圖:
通過很長時間的測試驗證,發現 CentOS6 優化了內存申請的效率,引入了 THP 的特性,而 Hadoop 是高密集型內存運算系統,這個改動給 hadoop 帶來了反作用。經過如下內核參數優化關閉系統 THP 特性,CPU 內核使用率立刻降低,以下圖:
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
2. 架構設計的坑
最初的數據流架構是數據採集網關把數據上報給 Kafka,再由數據實時清洗平臺 (ETL) 作預處理後直接實時寫入 HDFS,以下圖:
此架構,須要維持 HDFS Client 的長鏈接,因爲網絡等各類緣由致使 Storm 實時寫入 HDFS 常常不穩定,隔三差五的出現數據異常,使後面的計算結果異常不斷,當時嘗試過不少種手段去優化,如:保證長鏈接、鏈接斷後重試機制、調整 HDFS 服務端參數等,都解決的不是完全。
天天異常不斷,舊異常沒解決,新異常又來了,在壓力山大的狀況下,考慮從架構角度調整,不能只從具體的技術點去優化了,在作架構調整時,考慮到咱們架構重構的初衷,提升數據的實時性,儘可能讓計算任務實時化,但重構過程當中要考慮現有業務的過渡,因此架構必須支持實時與離線的需求,結合這些需求,在數據實時清洗平臺 (ETL) 後加了一層數據緩存重用層(kafka),也就是通過數據實時清洗平臺後的數據仍是寫入 kafka 集羣,因爲 kafka 支持重複消費,因此同一份數據能夠既知足實時計算也知足離線計算,從上面的總體技術架構也能夠看出,以下圖:
KG-Camus 組件也是基於架構調整後,從新實現了一套離線消費 Kafka 集羣數據的組件,此組件是參考 LinkedIn 的 Camus 實現的。此方式,使數據消費模式由原來的推方式改成拉模式了,不用維持 HDFS Client 的長鏈接等功能了,直接由做業調度系統每隔時間去拉一次數據,不一樣的業務能夠設置不一樣的時間間隔,今後架構調整上線後,基本沒有相似的異常出現了。
這個坑,是我本身給本身挖的,致使咱們的重構計劃延期 2 個月,主要緣由是由最初技術預研究測試不充分所致使。
3. 開源組件的坑
因爲整個數據平臺涉及到的開源組件不少,踩過的坑也是十個手指數不過來。
1)、當咱們的行爲數據全量接入到 Kafka 集羣 (幾百億 / 天),數據採集網卡出現大量鏈接超時現象,但萬兆網卡進出流量使用率並非很高,只有幾百 Mbit/s,通過大量的測試排查後,調整如下參數,就是順利解決了此問題。調整參數後網卡流量以下圖:
a)、num.network.threads( 網絡處理線程數) 值應該比 cpu 數略大
b)、num.io.threads( 接收網絡線程請求並處理線程數) 值提升爲 cpu 數兩倍
2)、在 hive0.14 版本中,利用函數 ROW_NUMBER() OVER 對數據進行數據處理後,致使大量的做業出現延時很大的現象,經異常排查後,發如今數據記錄數沒變的狀況,數據的存儲容量擴大到原來的 5 倍左右,致使 MapReduce 執行很慢形成的。改成本身實現相似的函數後,解決了容量擴大爲原來幾倍的現象。說到這裏,也在此請教讀到此處的讀者一個問題,在海量數據去重中採用什麼算法或組件進行比較合適,既能高性能又能高準確性,有好的建議或解決方案能夠加 happyjim2010 微信私我。
3)、在業務實時監控系統中,用 OpenTSDB 與實時計算系統(storm)結合,用於聚合並存儲實時 metric 數據。在這種實現中,一般須要在實時計算部分使用一個時間窗口(window),用於聚合實時數據,而後將聚合結果寫入 tsdb。可是,因爲在實際狀況中,實時數據在採集、上報階段可能會存在延時,而致使 tsdb 寫入的數據不許確。針對這個問題,咱們作了一個改進,在原有 tsdb 寫入 api 的基礎上,增長了一個原子加的 api。這樣,延遲到來的數據會被疊加到以前寫入的數據之上,實時的準確性因爲不可避免的緣由(採集、上報階段)產生了延遲,到最終的準確性也能夠獲得保證。另外,添加了這個改進以後,實時計算端的時間窗口就不須要由於考慮延遲問題設置得比較大,這樣既節省了內存的消耗,也提升了實時性。
後續持續改進
數據存儲 (分佈式內存文件系統 (Tachyon)、數據多介質分層存儲、數據列式存儲 )、即席查詢 (OLAP)、資源隔離、數據安全、平臺微觀層面監控、數據對外服務等。
文章出處:InfoQ