在講新一代大數據技術架構前，先講下大數據特徵與大數據技術要解決的問題。
1.大數據特徵：“大量化(Volume)、多樣化(Variety)、快速化(Velocity)、價值密度低（Value）”就是“大數據”顯著的4V特徵，或者說，只有具備這些特點的數據，纔是大數據。
本人對於大數據學習創建了一個小小的學習圈子，爲各位提供了一個平臺，大家一起來討論學習大數據。歡迎各位到來大數據學習羣：868847735 一起討論視頻分享學習。大數據是未來的發展方向，正在挑戰我們的分析能力及對世界的認知方式，因此，我們與時俱進，迎接變化，並不斷的成長，掌握大數據核心技術，纔是掌握真正的價值所在。
2.大數據技術要解決的問題：大數據技術被設計用於在成本可承受的條件下，通過非常快速（velocity）地採集、發現和分析，從大量（volumes）、多類別（variety）的數據中提取價值（value），將是IT領域新一代的技術與架構。
介紹了大數據的特性及大數據技術要解決的問題，我們先看看新一代大數據技術架構的數據流架構圖：
從這張圖中，可以瞭解到大數據處理過程可以分爲數據源、數據接入、數據清洗、數據緩存、存儲計算、數據服務、數據消費等環節，每個環節都有具有高可用性、可擴展性等特性，都爲下一個節點更好的服務打下基礎。整個數據流過程都被數據質量監控系統監控，數據異常自動預警、告警。
新一代大數據整體技術架構如圖：
將大數據計算分爲實時計算與離線計算，在整個集羣中，奔着能實時計算的，一定走實時計算流處理，通過實時計算流來提高數據的時效性及數據價值，同時減輕集羣的資源使用率集中現象。
整體架構從下往上解釋下每層的作用：
數據實時採集：
主要用於數據源採集服務，從數據流架構圖中，可以知道，數據源分爲前端日誌，服務端日誌，業務系統數據。下面講解數據是怎麼採集接入的。
a.前端日誌採集接入：
前端日誌採集要求實時，可靠性，高可用性等特性。技術選型時，對開源的數據採集工具flume,scribe,chukwa測試對比，發現基本滿足不了我們的業務場景需求。所以，選擇基於kafka開發一套數據採集網關，來完成數據採集需求。數據採集網關的開發過程中走了一些彎路，最後採用nginx+lua開發，基於lua實現了kafka生產者協議。有興趣同學可以去Github上看看，另一同事實現的，現在在github上比較活躍，被一些互聯網公司應用於線上環境了。
b.後端日誌採集接入：
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）。
1）數據緩衝層(DCL)：存儲業務系統或者客戶端上報的，經過解碼、清洗、轉換後的原始數據，爲數據過濾做準備。
2)數據明細層（DDL）：存儲接口緩衝層數據經過過濾後的明細數據。
3）公共數據層（Common）：主要存儲維表數據與外部業務系統數據。
4）數據彙總層（DSL）：存儲對明細數據，按業務主題，與公共數據層數據進行管理後的用戶行爲主題數據、用戶行爲寬表數據、輕量彙總數據等。爲數據應用層統計計算提供基礎數據。數據彙總層的數據永久保存在集羣中。
5）數據應用層（DAL）：存儲運營分析（Operations Analysis ）、指標體系（Metrics System）、線上服務（Online Service）與用戶分析（User Analysis）等。需要對外輸出的數據都存儲在這一層。主要基於熱數據部分對外提供服務，通過一定週期的數據還需要到DSL層裝載查詢。
6）數據分析層（Analysis）：存儲對數據明細層、公共數據層、數據彙總層關聯後經過算法計算的、爲推薦、廣告、榜單等數據挖掘需求提供中間結果的數據。
7）臨時提數層（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級別的監控，像這類監控指標就是另一大方向，這類的監控指標在實際的使用場景中特別重要，一旦你的集羣資源是開放給外面的用戶使用，用戶本身不瞭解你的這套機制原理，很容易會亂申請資源，造成嚴重拖垮集羣整體運作效率的事情，所以這類監控的指標就是爲了防止這樣的事情發生。目前我們主要實現了宏觀層面的監控。如：數據質量監控系統實現方案如下。
