大數據分析平臺構建實錄
在數據分析中，有超過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目前也在試水。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%