在數(shù)據(jù)分析中，有超過(guò)90%數(shù)據(jù)都是來(lái)自于非結(jié)構(gòu)化數(shù)據(jù)，其中大部分的是日志，如運(yùn)維、安全審計(jì)、用戶訪問(wèn)數(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í)代到來(lái)，可以說(shuō)每個(gè)人無(wú)時(shí)無(wú)刻不在產(chǎn)生數(shù)據(jù)，幾乎成爆發(fā)式的增長(zhǎng)。

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

　　一、基石－Hadoop

　　Hadoop2.0之后，資源管理被剝離了出來(lái)，變成了YARN。雖然在集群規(guī)模小于200臺(tái)的企業(yè)里，可能不能感受到Y(jié)ARN帶來(lái)的過(guò)多優(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ú)障礙的部署在低廉的服務(wù)器上，Replication機(jī)制也保證了數(shù)據(jù)容災(zāi)性。但有些場(chǎng)景也不適合使用，如低延遲數(shù)據(jù)訪問(wèn)、大量小文件存儲(chǔ)等，但可以依賴其他框架解決，如HBase、Alluxio解決低延遲訪問(wèn)、FastDFS解決大量小文件存儲(chǔ)的問(wèn)題，mmTrix的真機(jī)監(jiān)測(cè)就是通過(guò)FastDFS來(lái)解決存儲(chǔ)真機(jī)客戶端大量回傳的幾KB小文件。

　　二、快刀－Spark、Mapreduce、Storm、Spark Streaming

　　很多人覺(jué)得Spark的出現(xiàn)，可以完全替代Mapreduce，盡管Mapreduce很優(yōu)秀，編程模型簡(jiǎn)單，但是真的太慢了（前公司的BI人員多次吐槽，敲完一條連表HiveSQL，他可以看一集火影）。Spark目前正朝著2.0大步邁進(jìn)，從目前最新的1.6版本來(lái)看，上千個(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)用程序來(lái)說(shuō)，在無(wú)需手動(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作為開(kāi)源實(shí)時(shí)框架的先驅(qū)，在提到實(shí)時(shí)計(jì)算的時(shí)候，會(huì)第一反應(yīng)想到它，盡管twitter公司已經(jīng)宣布棄用，改用Heron。從Twitter在SIGMOD 2015上發(fā)布的論文來(lái)看，Heron可以說(shuō)有非常不錯(cuò)的提升，Twitter也表示在將來(lái)會(huì)開(kāi)源。而阿里的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è)問(wèn)題，如過(guò)度依賴Zookeeper（頻繁交互Zookeeper）、HA、多集群監(jiān)控、資源硬隔離等。

　　而Spark Streaming則是目前我們正在過(guò)渡到的一個(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訪問(wèn)日志相關(guān)的秒級(jí)監(jiān)控遷到Spark Streaming。

　　三、輔助－Kafka、OpenTSDB、Kylin

　　Kafka為L(zhǎng)inkedIn開(kāi)源的優(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)維、開(kāi)發(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ú)立的，它們之間沒(méi)有Master，沒(méi)有共享狀態(tài)，從而在使用的時(shí)候可以部署任意多個(gè)，且相互之間不影響。數(shù)據(jù)的存儲(chǔ)主要依托開(kāi)源的列存儲(chǔ)數(shù)據(jù)HBase，按時(shí)間序列存儲(chǔ)。與TSD之間的數(shù)據(jù)交互，可以通過(guò)簡(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)問(wèn)題的。

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

　　Kylin是eBay開(kāi)源給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è)問(wèn)題。同時(shí)，mmTrix的技術(shù)支持和OP人員也需要快速的幫助客戶排查一些問(wèn)題或者快速制作分析報(bào)表。Kylin目前來(lái)看使用的限制較多，對(duì)于其依賴的組件Hive、HBase、Hadoop有一定限制，而且目前使用的公司還較少（京東云海分享過(guò)使用經(jīng)驗(yàn)），mmTrix目前也在試水。