在數據分析中，有超過90%數據都是來自于非結構化數據，其中大部分的是日志，如運維、安全審計、用戶訪問數據以及業務數據等，但隨著互聯網快速的發展，數據規模也是水漲船高，從早前的GB級到現在的TB級，甚至PB級也只是短短幾年光景。而移動互聯網的時代到來，可以說每個人無時無刻不在產生數據，幾乎成爆發式的增長。?

如此多的數據早已壓榨完單機的性能，在性價比的驅使下，轉向分布式也是多數互聯網企業早就未雨綢繆的事。2016年恰逢Hadoop十周年，可以說Hadoop改變了企業對數據的存儲、處理和分析的過程，并引燃了整個大數據生態圈，而構建企業級大數據分析平臺也必不可少從它開始。?

一、基石－Hadoop?
Hadoop2.0之后，資源管理被剝離了出來，變成了YARN。雖然在集群規模小于200臺的企業里，可能不能感受到YARN帶來的過多優勢，但是與MRv1相比，其已不再是單純的計算框架（Mapreduce），而是一個框架管理器，可以部署多個計算框架（如Spark，Storm，Impala等），NoSQL存儲（如HBase等）。?

HDFS是Hadoop的分布式文件系統，多數的計算框架都支持直接從HDFS上讀取數據，且可以無障礙的部署在低廉的服務器上，Replication機制也保證了數據容災性。但有些場景也不適合使用，如低延遲數據訪問、大量小文件存儲等，但可以依賴其他框架解決，如HBase、Alluxio解決低延遲訪問、FastDFS解決大量小文件存儲的問題，mmTrix的真機監測就是通過FastDFS來解決存儲真機客戶端大量回傳的幾KB小文件。?

二、快刀－Spark、Mapreduce、Storm、Spark Streaming?
很多人覺得Spark的出現，可以完全替代Mapreduce，盡管Mapreduce很優秀，編程模型簡單，但是真的太慢了（前公司的BI人員多次吐槽，敲完一條連表HiveSQL，他可以看一集火影）。Spark目前正朝著2.0大步邁進，從目前最新的1.6版本來看，上千個補丁完全可以看出Spark正如其名一般的火爆。Spark 1.6引入新的內存管理器，自動調整不同內存區域大小，根據程序運行時自動地增加或縮小相應內存區域大小，這意味著對許多應用程序來說，在無需手動調整的情況下，在進行join和aggregation等操作時，其可用的內存將大大增加。?

盡管Spark如此優秀，但是在日級別、部分業務小時級的數據計算時，我們依舊選擇Mapreduce，但對于分鐘級的計算已經將這光榮的任務移交給Spark。?

Storm作為開源實時框架的先驅，在提到實時計算的時候，會第一反應想到它，盡管twitter公司已經宣布棄用，改用Heron。從Twitter在SIGMOD 2015上發布的論文來看，Heron可以說有非常不錯的提升，Twitter也表示在將來會開源。而阿里的JStorm在2015年10月份也加入了Storm的豪華午餐，應該會出現在下個大版本里。我們部署了JStorm2.1.0進行了測試，發現JStorm表現出非常不錯的性能，僅從監控UI就能看出阿里對于JStorm的誠意，但最重要的是JStorm解決了Storm的幾個問題，如過度依賴Zookeeper（頻繁交互Zookeeper）、HA、多集群監控、資源硬隔離等。?

而Spark Streaming則是目前我們正在過渡到的一個實時計算框架，Spark Streaming與Storm在處理數據的本質上有著很大的不同，Storm是逐個處理tuple，而Spark Streaming則可看成細粒度批處理（micro batch）的spark任務，但這也決定了其高吞吐量和較高的延遲。一般認為Storm的處理瓶頸是單條流水線20000Tuple／s（每個tuple大小為1KB），但在一些大數據量且延遲要求不高的場景下，其實Spark Streaming可能更適合，目前mmTrix也準備將靜態CDN訪問日志相關的秒級監控遷到Spark Streaming。?

三、輔助－Kafka、OpenTSDB、Kylin?
Kafka為LinkedIn開源的優秀分布式發布訂閱消息系統，即便是廉價的服務器也能跑出單機10W/s的效率。Kafka解藕了服務的同時，對消費端消費能力不足的情況下，實現了數據緩沖，并且消費不刪除和Retention機制也提高了其在實踐中的高可用。即便在后端消費服務全部宕機的情況下，Kafka也能默默承載全部數據壓力，并給予運維、開發人員修復的時間（取決于配置項log.retention.hours）。?

由于mmTrix是主要做APM業務的，不可避免地會遇到時間序列的監控數據，如OS監控、Plugin監控、Server監控等業務。早期的做法，選擇了Mongo作為存儲工具，但最終我們還是選擇了HBase，并配合OpenTSDB使用。OpenTSDB主要由Time Series Daemon (TSD)以及一系列的命令工具組成。每個TSD都是獨立的，它們之間沒有Master，沒有共享狀態，從而在使用的時候可以部署任意多個，且相互之間不影響。數據的存儲主要依托開源的列存儲數據HBase，按時間序列存儲。與TSD之間的數據交互，可以通過簡單的telnet-style協議，比如HTTP API或者內建的GUI。時間序列的數據是高密集的，如果設計HBase Rowkey時，只注重在時間尺度上的Scan且把全時間帶入到Rowkey中，當大規模灌入數據的時候是極易引起Region熱點問題的。?

而OpenTSDB的Rowkey設計巧妙的規避了這個問題，采用固定長度的Rowkey，讓Rowkey包含盡可能多的檢索信息。同時，其使用AsyncHbase而非HBase自帶的HTable，且線程安全、非阻塞、異步、多線程并發的HBase API，在高并發和高吞吐時，可以獲得更好的效果。?

?

Kylin是eBay開源給Apache的OLAP平臺，并于2015年12月8日成為Apache頂級項目。對于需要長期建立的數據分析倉庫，在不同的時間彈性尺度上聚合結果是比較耗時的，而用戶經常要求在秒級返回結果，OLAP平臺正好解決這個問題。同時，mmTrix的技術支持和OP人員也需要快速的幫助客戶排查一些問題或者快速制作分析報表。Kylin目前來看使用的限制較多，對于其依賴的組件Hive、HBase、Hadoop有一定限制，而且目前使用的公司還較少（京東云海分享過使用經驗），mmTrix目前也在試水。?

四、大數據分析平臺實踐?

?

目前mmTrix整個大數據分析平臺主要抽象成5層，包括數據源層、數據集成層、數據分析層、數據分析存儲層、數據服務層，組件的監控則貫穿整個平臺。?

數據源層?

數據源目前主要分3類，新增的外部數據、已保存的外部數據、已保存的內部數據。新增的外部數據，主要是非結構化的數據，由log agent，plugin agent（Redis、MySQL、Mongo等）、OS agent等上傳的數據。已保存的外部數據，主要是由其他服務、采集整合的結構化數據，輔助構建數據倉庫，同時存儲部分元數據。已保存的內部數據 ，主要是數據落地備份和長期增量建立的數據倉庫，業務主要涵蓋全站加速、圖片加速、網絡加速、OS監控、Plugin監控等。?

數據的規模，日新增數據量約1.5TB，其中網絡加速日新增約20億條，全站加速約1200萬條，OS監控日新增約110GB。?

數據集成層?

數據集成層則是匯聚集成數據源，供各種組件使用（例如數據獲取、數據清洗入庫等）。目前，有kafka2hdfs、kafka2opentsdb服務分別落地新增的數據到HDFS、OpenTSDB，以多線程模式并行處理。Collector主要設計為數據收集、數據適配、數據分發，將上傳的plugin數據收集后適配成OpenTSDB所需的數據格式，然后數據分發到TSD進行數據落地。?

數據分析層?

數據分析層則分為實時計算、離線計算、OLAP分析三塊。?

實時計算目前由Storm搭建，已運行的topology主要負責全站加速、網絡加速的各項統計，計算結果在開啟pipeline的情況下通過Codis寫入（測試對比寫入單機Redis，性能損耗約10%-15%），過期時效為6分鐘。一些需要原語特性的實時計算，則使用Trident API，如實時監控報警（防止失敗處理導致重復發送，繼而引起誤報，其實有時候誤報比一兩次的漏報更可怕）。?

離線計算目前由MapReduce和Spark計算框架負責，Job調度由基于Quartz自研的JobScheduler定時調度，主要負責全站加速、網絡加速、圖片加速等各項業務的統計調度。JobScheduler是一個輕量級的調度系統，對任務依賴、補跑、失敗重試等都進行了較好的實現，但也存在一些問題，目前也在借鑒阿里的Zeus系統進行完善，如分布式等特性。目前離線計算任務，僅定時任務月均13W左右。?

OLAP分析是基于長期建立的數據分析倉庫，對每日新增數據進行預計算，更新維度索引，提供彈性的數據分析，目前只是處于試水階段。?

數據分析存儲層?

數據分析存儲層存儲數據分析結果或者中間結果，由后續數據服務提供簡單聚合等計算。目前，Redis負責實時數據的結果存儲（過期失效），以及調度狀態、任務成功失敗標記等。MySQL主要負責時效性較長、數據量不大的計算結果，目前存儲全站加速、網絡加速、圖片加速的報表數據，會對冷熱數據（根據用戶的查詢頻率）進行分離，對歷史數據存入HBase，較新的數據存入MySQL。Hive和HBase主要負責時效性長、數據量大的計算結果，比如存入各種預計算的結果、中間表、長期保存的數據，包括監控數據、報表數據等。?

數據服務層?

數據服務層主要負責應用層的服務請求，由go語言開發，采用微服務的架構體系，Docker部署，服務不相互依賴或簡單依賴，提供各種監控數據、報表服務。由于本文只注重對于平臺的構建，對服務治理、服務監控等就不做過多贅述。?

總結?

本文詳細介紹了mmTrix大數據分析平臺的基本架構構建過程，基于Hadoop的大數據分析平臺逐步實現mmTrix APM后端數據的存儲、分析、挖掘，同時隨著業務的更迭也加速驅動數據的平臺化。?

本文作者來自性能魔方大數據負責人朱昱強

轉載于:https://www.cnblogs.com/davidwang456/articles/5340145.html

總結

以上是生活随笔為你收集整理的mmTrix大数据分析平台构建实录--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。