在數(shù)據(jù)分析中，有超過90%數(shù)據(jù)都是來自于非結(jié)構(gòu)化數(shù)據(jù)，其中大部分的是日志，如運(yùn)維、安全審計(jì)、用戶訪問數(shù)據(jù)以及業(yè)務(wù)數(shù)據(jù)等，但隨著互聯(lián)網(wǎng)快速的發(fā)展，數(shù)據(jù)規(guī)模也是水漲船高，從早前的GB級(jí)到現(xiàn)在的TB級(jí)，甚至PB級(jí)也只是短短幾年光景。而移動(dòng)互聯(lián)網(wǎng)的時(shí)代到來，可以說每個(gè)人無時(shí)無刻不在產(chǎn)生數(shù)據(jù)，幾乎成爆發(fā)式的增長(zhǎng)。?

如此多的數(shù)據(jù)早已壓榨完單機(jī)的性能，在性價(jià)比的驅(qū)使下，轉(zhuǎn)向分布式也是多數(shù)互聯(lián)網(wǎng)企業(yè)早就未雨綢繆的事。2016年恰逢Hadoop十周年，可以說Hadoop改變了企業(yè)對(duì)數(shù)據(jù)的存儲(chǔ)、處理和分析的過程，并引燃了整個(gè)大數(shù)據(jù)生態(tài)圈，而構(gòu)建企業(yè)級(jí)大數(shù)據(jù)分析平臺(tái)也必不可少?gòu)乃_始。?

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

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

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

盡管Spark如此優(yōu)秀，但是在日級(jí)別、部分業(yè)務(wù)小時(shí)級(jí)的數(shù)據(jù)計(jì)算時(shí)，我們依舊選擇Mapreduce，但對(duì)于分鐘級(jí)的計(jì)算已經(jīng)將這光榮的任務(wù)移交給Spark。?

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

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

三、輔助－Kafka、OpenTSDB、Kylin?
Kafka為L(zhǎng)inkedIn開源的優(yōu)秀分布式發(fā)布訂閱消息系統(tǒng)，即便是廉價(jià)的服務(wù)器也能跑出單機(jī)10W/s的效率。Kafka解藕了服務(wù)的同時(shí)，對(duì)消費(fèi)端消費(fèi)能力不足的情況下，實(shí)現(xiàn)了數(shù)據(jù)緩沖，并且消費(fèi)不刪除和Retention機(jī)制也提高了其在實(shí)踐中的高可用。即便在后端消費(fèi)服務(wù)全部宕機(jī)的情況下，Kafka也能默默承載全部數(shù)據(jù)壓力，并給予運(yùn)維、開發(fā)人員修復(fù)的時(shí)間（取決于配置項(xiàng)log.retention.hours）。?

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

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

?

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

四、大數(shù)據(jù)分析平臺(tái)實(shí)踐?

?

目前mmTrix整個(gè)大數(shù)據(jù)分析平臺(tái)主要抽象成5層，包括數(shù)據(jù)源層、數(shù)據(jù)集成層、數(shù)據(jù)分析層、數(shù)據(jù)分析存儲(chǔ)層、數(shù)據(jù)服務(wù)層，組件的監(jiān)控則貫穿整個(gè)平臺(tái)。?

數(shù)據(jù)源層?

數(shù)據(jù)源目前主要分3類，新增的外部數(shù)據(jù)、已保存的外部數(shù)據(jù)、已保存的內(nèi)部數(shù)據(jù)。新增的外部數(shù)據(jù)，主要是非結(jié)構(gòu)化的數(shù)據(jù)，由log agent，plugin agent（Redis、MySQL、Mongo等）、OS agent等上傳的數(shù)據(jù)。已保存的外部數(shù)據(jù)，主要是由其他服務(wù)、采集整合的結(jié)構(gòu)化數(shù)據(jù)，輔助構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，同時(shí)存儲(chǔ)部分元數(shù)據(jù)。已保存的內(nèi)部數(shù)據(jù) ，主要是數(shù)據(jù)落地備份和長(zhǎng)期增量建立的數(shù)據(jù)倉(cāng)庫(kù)，業(yè)務(wù)主要涵蓋全站加速、圖片加速、網(wǎng)絡(luò)加速、OS監(jiān)控、Plugin監(jiān)控等。?

數(shù)據(jù)的規(guī)模，日新增數(shù)據(jù)量約1.5TB，其中網(wǎng)絡(luò)加速日新增約20億條，全站加速約1200萬條，OS監(jiān)控日新增約110GB。?

數(shù)據(jù)集成層?

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

數(shù)據(jù)分析層?

數(shù)據(jù)分析層則分為實(shí)時(shí)計(jì)算、離線計(jì)算、OLAP分析三塊。?

實(shí)時(shí)計(jì)算目前由Storm搭建，已運(yùn)行的topology主要負(fù)責(zé)全站加速、網(wǎng)絡(luò)加速的各項(xiàng)統(tǒng)計(jì)，計(jì)算結(jié)果在開啟pipeline的情況下通過Codis寫入（測(cè)試對(duì)比寫入單機(jī)Redis，性能損耗約10%-15%），過期時(shí)效為6分鐘。一些需要原語特性的實(shí)時(shí)計(jì)算，則使用Trident API，如實(shí)時(shí)監(jiān)控報(bào)警（防止失敗處理導(dǎo)致重復(fù)發(fā)送，繼而引起誤報(bào)，其實(shí)有時(shí)候誤報(bào)比一兩次的漏報(bào)更可怕）。?

離線計(jì)算目前由MapReduce和Spark計(jì)算框架負(fù)責(zé)，Job調(diào)度由基于Quartz自研的JobScheduler定時(shí)調(diào)度，主要負(fù)責(zé)全站加速、網(wǎng)絡(luò)加速、圖片加速等各項(xiàng)業(yè)務(wù)的統(tǒng)計(jì)調(diào)度。JobScheduler是一個(gè)輕量級(jí)的調(diào)度系統(tǒng)，對(duì)任務(wù)依賴、補(bǔ)跑、失敗重試等都進(jìn)行了較好的實(shí)現(xiàn)，但也存在一些問題，目前也在借鑒阿里的Zeus系統(tǒng)進(jìn)行完善，如分布式等特性。目前離線計(jì)算任務(wù)，僅定時(shí)任務(wù)月均13W左右。?

OLAP分析是基于長(zhǎng)期建立的數(shù)據(jù)分析倉(cāng)庫(kù)，對(duì)每日新增數(shù)據(jù)進(jìn)行預(yù)計(jì)算，更新維度索引，提供彈性的數(shù)據(jù)分析，目前只是處于試水階段。?

數(shù)據(jù)分析存儲(chǔ)層?

數(shù)據(jù)分析存儲(chǔ)層存儲(chǔ)數(shù)據(jù)分析結(jié)果或者中間結(jié)果，由后續(xù)數(shù)據(jù)服務(wù)提供簡(jiǎn)單聚合等計(jì)算。目前，Redis負(fù)責(zé)實(shí)時(shí)數(shù)據(jù)的結(jié)果存儲(chǔ)（過期失效），以及調(diào)度狀態(tài)、任務(wù)成功失敗標(biāo)記等。MySQL主要負(fù)責(zé)時(shí)效性較長(zhǎng)、數(shù)據(jù)量不大的計(jì)算結(jié)果，目前存儲(chǔ)全站加速、網(wǎng)絡(luò)加速、圖片加速的報(bào)表數(shù)據(jù)，會(huì)對(duì)冷熱數(shù)據(jù)（根據(jù)用戶的查詢頻率）進(jìn)行分離，對(duì)歷史數(shù)據(jù)存入HBase，較新的數(shù)據(jù)存入MySQL。Hive和HBase主要負(fù)責(zé)時(shí)效性長(zhǎng)、數(shù)據(jù)量大的計(jì)算結(jié)果，比如存入各種預(yù)計(jì)算的結(jié)果、中間表、長(zhǎng)期保存的數(shù)據(jù)，包括監(jiān)控?cái)?shù)據(jù)、報(bào)表數(shù)據(jù)等。?

數(shù)據(jù)服務(wù)層?

數(shù)據(jù)服務(wù)層主要負(fù)責(zé)應(yīng)用層的服務(wù)請(qǐng)求，由go語言開發(fā)，采用微服務(wù)的架構(gòu)體系，Docker部署，服務(wù)不相互依賴或簡(jiǎn)單依賴，提供各種監(jiān)控?cái)?shù)據(jù)、報(bào)表服務(wù)。由于本文只注重對(duì)于平臺(tái)的構(gòu)建，對(duì)服務(wù)治理、服務(wù)監(jiān)控等就不做過多贅述。?

總結(jié)?

本文詳細(xì)介紹了mmTrix大數(shù)據(jù)分析平臺(tái)的基本架構(gòu)構(gòu)建過程，基于Hadoop的大數(shù)據(jù)分析平臺(tái)逐步實(shí)現(xiàn)mmTrix APM后端數(shù)據(jù)的存儲(chǔ)、分析、挖掘，同時(shí)隨著業(yè)務(wù)的更迭也加速驅(qū)動(dòng)數(shù)據(jù)的平臺(tái)化。?

本文作者來自性能魔方大數(shù)據(jù)負(fù)責(zé)人朱昱強(qiáng)

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/5340145.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。