大數(shù)據(jù)分析平臺構(gòu)建實(shí)錄

　　在數(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級到現(xiàn)在的TB級，甚至PB級也只是短短幾年光景。而移動互聯(lián)網(wǎng)的時(shí)代到來，可以說每個(gè)人無時(shí)無刻不在產(chǎn)生數(shù)據(jù)，幾乎成爆發(fā)式的增長。

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

　　一、基石－Hadoop

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

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

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

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

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

　　Storm作為開源實(shí)時(shí)框架的先驅(qū)，在提到實(shí)時(shí)計(jì)算的時(shí)候，會第一反應(yīng)想到它，盡管twitter公司已經(jīng)宣布棄用，改用Heron。從Twitter在SIGMOD 2015上發(fā)布的論文來看，Heron可以說有非常不錯(cuò)的提升，Twitter也表示在將來會開源。而阿里的JStorm在2015年10月份也加入了Storm的豪華午餐，應(yīng)該會出現(xiàn)在下個(gè)大版本里。我們部署了JStorm2.1.0進(jìn)行了測試，發(fā)現(xiàn)JStorm表現(xiàn)出非常不錯(cuò)的性能，僅從監(jiān)控UI就能看出阿里對于JStorm的誠意，但最重要的是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ù)量且延遲要求不高的場景下，其實(shí)Spark Streaming可能更適合，目前mmTrix也準(zhǔn)備將靜態(tài)CDN訪問日志相關(guān)的秒級監(jiān)控遷到Spark Streaming。

　　三、輔助－Kafka、OpenTSDB、Kylin

　　Kafka為LinkedIn開源的優(yōu)秀分布式發(fā)布訂閱消息系統(tǒng)，即便是廉價(jià)的服務(wù)器也能跑出單機(jī)10W/s的效率。Kafka解藕了服務(wù)的同時(shí)，對消費(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ù)的，不可避免地會遇到時(shí)間序列的監(jiān)控?cái)?shù)據(jù)，如OS監(jiān)控、Plugin監(jiān)控、Server監(jiān)控等業(yè)務(wù)。早期的做法，選擇了Mongo作為存儲工具，但最終我們還是選擇了HBase，并配合OpenTSDB使用。OpenTSDB主要由Time Series Daemon （TSD）以及一系列的命令工具組成。每個(gè)TSD都是獨(dú)立的，它們之間沒有Master，沒有共享狀態(tài)，從而在使用的時(shí)候可以部署任意多個(gè)，且相互之間不影響。數(shù)據(jù)的存儲主要依托開源的列存儲數(shù)據(jù)HBase，按時(shí)間序列存儲。與TSD之間的數(shù)據(jù)交互，可以通過簡單的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è)問題，采用固定長度的Rowkey，讓Rowkey包含盡可能多的檢索信息。同時(shí)，其使用AsyncHbase而非HBase自帶的HTable，且線程安全、非阻塞、異步、多線程并發(fā)的HBase API，在高并發(fā)和高吞吐時(shí)，可以獲得更好的效果。

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