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

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

　　一、基石－Hadoop

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

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

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

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

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

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

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

　　三、輔助－Kafka、OpenTSDB、Kylin

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

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

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

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

相關電子資料下載

• 大數(shù)據分析平臺能為企業(yè)帶來哪些好處 244
• 大數(shù)據分析平臺助今日頭條精準內容推送 548
• 機智云大數(shù)據分析平臺GI，強化數(shù)字賦能企業(yè)智能化管理與運維 409
• 大數(shù)據分析平臺建設藍圖布局與驅動數(shù)字化轉型的案例 3992
• 飛騰攜手京信大數(shù)據推出“產業(yè)發(fā)展大數(shù)據分析平臺”方案 1586
• 基于工業(yè)互聯(lián)網的大數(shù)據分析平臺 - 生產成本分析 3182
• 大數(shù)據分析平臺實現(xiàn)支持多維度篩選的交互式界面，是由哪些部分組成 3054
• 上海浦東臺區(qū)線損大數(shù)據分析平臺上線，應用于配電網 1109
• 大數(shù)據分析平臺哪一些方面值得去關注 401
• 大數(shù)據分析平臺的安全建設必不可少 643