近年來，隨著雲端計算、移動網際網路、物聯網等技術的發展，以及智慧手機、平板電腦等終端裝置的不斷湧現，各種型別的電商、社交媒體等應用快速發展，產生了海量的資料，並且資料量增長的速度越來越快，龐大的資料資源引起了各個行業越來越多的關注，並促進了相關技術的發展與創新，產生越來越重要的價值，“大資料時代”已經悄然降臨。

對於電信運營商來說，目前正處在一個轉型的關鍵時期，從以語音、簡訊通訊為核心業務的傳統通訊時代向移動網際網路時代轉移，從話務經營轉為流量經營，從通訊運營商轉為資訊運營商。因此，探討如何通過引入大資料及其分析處理技術，規劃建設大資料中心，以支撐流量經營，促進運營商戰略轉型，這對於運營商來說具有非常重要的現實意義。

浙江移動早在2014年就已經逐步開始試點基於分散式架構的大資料平臺技術，在區域性使用MPP資料庫、Hadoop、流處理技術，試執行取得了較好的效果，但是由於缺乏統一的規劃和技術演進策略。存在平臺重複建設、資料大量冗餘，資料質量較低，以及MPP資料庫相容性問題、Hadoop版本不統一、人員不足等問題，嚴重影響了對大資料的應用，因此亟須在公司層面構建“資料整合、能力共享、應用創新”的企業級大資料平臺，對各域資料實現資產化的統一管理，進行持續的業務創新、運營提升、管理優化，推動開放共享，助力數字化服務曲線的發展。

企業級大資料平臺一期專案從2014年開始規劃設計，經過一年多的努力，截至目前，企業級大資料基礎平臺建設專案混合雲平臺建設工作已經完成，並已制定相應資源分配策略，進行了初始的資源分配。在專案建設過程中，遇到了各種技術難題，技術團隊百折不撓地進行技術攻堅並取得一些成果，下面我們將把大資料平臺建設過程遇到的一些典型問題和解決思路進行分析，以拋磚引玉，歡迎更多的技術交流和探討。

（Hadoop生態系統）

Hadoop是一個能夠對大量資料進行分散式處理的軟體框架，具有可靠、高效、可伸縮的特點。Hadoop的核心是HDFS、Mapreduce和YARN等。

Hadoop主要應用於資料量大的離線場景。其特徵為：

• 資料量大：一般線上用Hadoop的，叢集規模都在上百臺到幾千臺的機器，資料量從幾十T到幾千T不等甚至更高。

• 離線：Mapreduce框架下，很難處理實時計算，作業都以日誌分析這樣的線下作業為主。另外，叢集中一般都會有大量作業等待被排程，保證資源充分利用。

• 資料塊大：由於HDFS設計的特點，Hadoop適合處理檔案塊大的檔案。大量的小檔案使用Hadoop來處理效率會很低。

這一部分Hadoop叢集主要分為雲化ETL、基礎分析庫、實時查詢庫三大塊，其中雲化ETL和基礎分析庫物理上是一個Hadoop叢集，實時查詢庫獨立一個Hadoop叢集；資源由雲管理平臺統一管理，通過多租戶機制進行許可權控制和資源隔離，通過平臺建設，完善資料採集和資料交換平臺建設，為大資料的儲存、計算、分析和查詢提供支撐。

問題一：Hadoop叢集訪問安全控制

問題描述：大資料Hadoop叢集作為一個大的融合平臺，會提供多個場景進行資料的儲存計算，因此要求不同的廠家能夠訪問的資料是受限的，只能訪問其獲得授權的資料。

問題分析：開源版本和CDH版本，要獨立搭建KDC，並進行非常複雜的配置，因此在國內基於Hadoop開發的大資料產品，除了FusionInsigh的局點，一般都不會使用安全版本，這個在叢集訪問安全上存在巨大的隱患。

問題解決：FusionInsight將Kerberos統一整合到版本中，採用RBAC的方式對大資料系統進行許可權管理，將系統中各元件零散的許可權管理功能集中呈現和管理，對普通使用者遮蔽掉了內部的許可權管理細節，對管理員簡化了許可權管理的操作方法，提升許可權管理的易用性和使用者體驗。

問題二：HDFS儲存共享計算隔離

問題描述：ETL、基礎分析庫叢集需要由兩個不同的部門同時使用，並且需要共享資料。兩個部門的業務執行要互不干擾。

問題分析：由於需要共享資料，所以只能部署一套Hadoop叢集，資料存放在同一個HDFS中，不同部門的計算業務使用Yarn做資源管理和排程，使用不同的任務佇列，並限定佇列的容量。但是這樣做仍然會出現兩個部門的作業執行到一臺物理機上的情況，無法保證作業的互不干擾。

問題解決：完全計算隔離的實現採用yarn的標籤排程策略（Label based scheduling），該排程策略適用於異構叢集。通過該策略，將叢集劃分為不同的資源池，並打上不同的標籤，資源池內按佇列劃分，同時將主機劃分到不同的資源池中。如下圖：

將一個Hadoop叢集的計算節點劃分為多個的resourcepool, 一個計算節點只能屬於一個resource pool. 通過引入標籤排程能力將不同部門的Yarn 任務佇列繫結到不同的resource pool。任務佇列中的作業只能在繫結的resource pool節點內執行，這樣部門之間的計算任務就完全物理隔離了，保證互不干擾。

問題三：實時查詢庫Hbase多例項

問題描述：實時查詢庫有多個不同的應用，應用之間無資料共享，對於請求的響應時間非常高，需要達到毫秒級別，同時應用之間要求資源隔離互不影響。

問題分析：在之前的實踐中，每個應用部署一套Hbase叢集, 三個應用就需要三套叢集，帶來極大的維護成本，而且叢集的利用率非常低。

問題解決：在一個Hadoop叢集中支援部署HBase多例項，每個上層應用對應一個HBase服務例項。服務例項之間的資源通過Cgroup等機制進行控制和隔離，保證每個服務例項的SLA，實現了各Hbase例項之間的資源隔離，而且每個服務例項的資源還可以動態調整，極大的提高了叢集的利用率，降低了維護成本。如下圖：

問題四：Flume叢集高可用

問題描述：目前Flume是非叢集模式的，存在單點故障的風險，因此如何保障生產環境下Flume的可靠性，即使在某個Flume節點down掉之後依然能保證正常接收資料、業務不受影響。

問題分析：針對此問題提出採用DNS輪詢方式，在SEQ側通過域名方式連線Flume節點，當一臺Flume節點down掉之後，會自動連線其他Flume節點，保證業務連續性。

問題解決：DNS輪詢方式就是指將相同的域名解析到不同的IP上，並隨機使用其中某臺主機的技術。在SEQ節點上配置DNS服務後，每次SEQ節點訪問Flume節點都需要一次DNS解析，然後選取可用的主機節點。這裡又配置了NSCD服務（NSCD服務就是能實現DNS快取，其可以在本地快取DNS解析的結果來加快DNS解析的速度）。具體框架如下圖：

問題五：HDFS磁碟檢查機制優化

問題描述：目前DataNode所在部分節點，會出現一個磁碟utils佔用率持續100%現象，導致HDFS讀寫速度下降，並在DataNode日誌中有很多slow傳輸和slow寫盤的異常。

問題分析：

• 通過對DataNode的日誌持續的分析，發現有114個DataNode不定的頻率出現“Noroute to host”異常，頻率高的DataNode出現了117次，導致寫Block檔案失敗，頻繁觸發了DiskChecker，結果出現磁碟utils上升的情況。DataNode部分資料盤IO持續10+s100%，則讓client寫檔案時很慢，最終從業務側發現查詢資料或者寫檔案都變慢。

• 可以確定DataNode資料盤讀寫很慢的原因是磁碟不停的在做DiskChecker所致，進而影響了整個HDFS讀寫的效率，降低了平臺的處理能力。

• DiskChecker的存在，是為了解決當DataNode網路或者磁碟異常情況下，HDFS對管理的磁碟做健康檢查的執行緒，最終會將異常磁碟排除，以避免壞磁碟對DataNode的影響。它的檢查機制是進入資料盤每個目錄下，建立一個目錄，測試磁碟的可用性及讀寫速率（注意是遞迴的，會遞迴資料盤下所有的目錄），測試完成後再刪除之前建立的目錄。但是當時DataNode在做DiskChecker時，資料盤的目錄達到了6.5W個，這樣在檢查時耗時且執行頻繁，對磁碟IO佔用、效能消耗非常大，最終導致了磁碟讀寫變慢，HDFS讀寫變慢。

問題解決：

• 減少平臺業務小檔案數量；

• 合入開源優化補丁HDFS-8845，重啟DataNode （DiskChecker由遍歷資料盤整個檔案目錄樹檢查磁碟，改為只檢查資料盤的根目錄）；

優化的關鍵程式碼如下：

實時計算系統一般都是針對海量資料進行的，一般要求為秒級。實時計算主要分為兩塊：資料的實時入庫、資料的實時計算。

主要應用的場景：

1. 資料來源是實時的不間斷的，要求使用者的響應時間也是實時的（比如網站的訪問PV/UV、使用者訪問了什麼內容、搜尋了什麼內容、實時信令、實時人流等，實時的資料計算和分析可以動態實時地重新整理使用者訪問資料，展示實時流量的變化情況，分析每天各小時的流量和使用者分佈情況）；

2. 資料量大且無法預計，但要求對使用者的響應時間是實時的。

（浙江移動大資料平臺實時分析系統）

• 數據實時採集

需求：功能上保證可以完整的收集到所有日誌資料，為實時應用提供實時資料；響應時間上要保證實時性、低延遲在1秒左右；配置簡單，部署容易；系統穩定可靠等。

目前的產品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘寶開源的TimeTunnel、Hadoop的Chukwa等，均可以滿足每秒數百MB的日誌資料採集和傳輸需求。

• 流處理技術

在流資料不斷變化的運動過程中實時地進行分析，捕捉到可能對使用者有用的資訊，並把結果傳送出去。流處理技術具有低延遲、可擴充套件和容錯性等特性。

目前的產品：IBM Streams、Storm、SparkStreaming等。

• 記憶體資料庫

記憶體資料庫通過將資料放在記憶體中直接操作的資料庫，利用記憶體的讀寫速度快速讀寫、記憶體隨機訪問的特點，將資料儲存在記憶體中，在記憶體中模仿建立表結構和索引結構並針對記憶體特性進行優化，相比從磁碟上訪問，記憶體資料庫能夠提高應用的效能。

目前的產品：Redis、SQLfire等。

問題一：多執行緒模式下提升分散式記憶體資料庫SQLfire的資料匯入速率

問題描述：Sqlfire是一款SQL型的記憶體資料庫產品，支援叢集模式，具有高吞吐量，可預測的低延遲低延遲，支援動態和線性擴充套件，支援資料持久化等特點。我們在進行Sqlfire壓力測試時發現，向Sqlfire中匯入1W條記錄需要7.5s的時間，這對於記憶體資料庫來說是有點慢的。

問題分析：測試建立的表為分割槽表，Sqlfire支援分割槽表和複製表兩種表模式，分割槽表按照建表時指定的分割槽欄位分割槽，複製表則在Sqlfire叢集每個節點都存有一份資料。一般大表適合建立為分割槽表，浙江移動場景下，比如客戶資訊表，產品訂購表等大表適合建立為分割槽表，小表比如產品配置表，地區資訊表，套餐維度表等一些維表更適合建立為複製表。建立的測試表為使用者資訊表，包括使用者id，地市，縣市，年齡，入網時間等11個欄位資訊。

浙江移動的Sqlfire叢集由90個節點組成，主要使用Docker技術在18臺物理機上每臺隔離出5個Sqlfire節點，共計90個節點。

首先測試單執行緒模式下的Sqlfire的匯入資料能力，以插入1W條記錄為例，測試結果為1W條記錄耗時為7.5秒。

然後是多執行緒模式下測試1W記錄做insert操作，以開20個執行緒為例，測試結果1s。程式中開20個執行緒，每500條記錄開一個執行緒做insert操作。在這種情況下測試10W條記錄的插入，耗時為4s，相當於每5000條記錄開一個執行緒做insert操作，進一步可以使用執行緒池來進行執行緒的管理。

以上結果可以看出，在一定執行緒數範圍內提高執行緒數，可以明顯的提高記憶體資料庫Sqlfire的匯入資料的速率，但對於多執行緒模式來說，存在的瓶頸就是當執行緒數達到一定的數量後，對於一定的硬體條件下可能提高執行緒資料對提高的匯入資料速率並無明顯的提高，這是因為執行緒數達到一定數量後，執行緒間的執行緒切換也是一個較大的開銷。

問題二：IBM Streams與Kafka連線

問題描述：

1. IBM Streams與Kafka進行傳輸時發現，Streams與Kafka並不能連通；

2. IBM Streams 在與Kafka讀寫時發現效能不到1萬條每秒，這遠遠沒有達到我們設計之初的要求。

問題分析：通過查閱文件發現，Streams確實存在於Kafka傳輸的介面，進一步檢視Kafka程式碼發現，原來Kafka本身存在缺乏安全機制，為了解決這個問題，我們在Kafka中間層上加入了Kerberos安全認證，所以Streams在連線Kafka時沒有進行Kerberos的安全認證，從而導致Stream與Kafka不能連線。

針對讀寫效能問題，嘗試使用多執行緒，並使效能達到100萬條每秒。

問題解決：

Streams加入安全認證的部分程式碼如下：

多執行緒以下是部分程式碼：

問題三：Redis的Slave節點複製Master時，BGSAVE操作存在小概率資料錯亂

隱患問題描述：在主從模式下的從Redis如果開啟了定期BGSAVE，並且在做主從SYNC的時候，可能存在資料錯亂的問題

問題分析：Redis的BGSAVE操作和slaveof觸發的同步操作是互不相關的（對於從庫），所以就完全有可能同時在進行備份和同步。Slave從Master讀取最新的rdb檔案後，載入到記憶體的步驟如下：

1. 將讀取回來的臨時檔案rename成server.rdb_filename檔案

2. 呼叫emptyDb方法清空整個資料庫

3. 然後呼叫rdbLoad(server.rdb_filename)將server.rdb_filename檔案載入到記憶體

4. 載入從master接受到的最新資料

問題在第一步到跟第三步裡面的server.rdb_filename檔案可能會被覆蓋，因為此時如果有後臺的BGSAVE程序由於定期事件觸發啟動備份後（正好大部分主從都是在從庫做備份的），正好此備份程式在一和三之間完成（這中間需要清空所有資料，時間較長），於是 BGSAVE程序會覆蓋掉server.rdb_filename檔案內容。然後再第3步還是繼續去載入server.rdb_filename檔案到記憶體，實際上這個檔案完全不是剛剛同步回來的檔案，而是slave自己bgsave出來的檔案。這樣資料庫的資料就會出現錯亂。

問題解決：其實主從在做SYNC全量同步的時候，此時並沒有必要做BGSAVE，因為等SYNC完成後，自然就會將同步回來的rdb檔案覆蓋BGSAVE檔案 的：rename(server.repl_transfer_tmpfile,server.rdb_filename)，所以BGSAVE等於白做。
 

企業級大資料平臺通過構建MPP資源池叢集側重於B域資料分析，主要包括核心資料倉庫、資料集市）。

• 核心資料倉庫：通過引入MPP資料庫取代現有DB2資料庫。資料只在核心資料倉庫建資料模型，完成之後把資料同步到列存資料分析集市，同時列存資料分析集市作為大資料集市承載目前所有的基於資料庫標準SQL開發的應用；僅當核心資料倉庫出故障時，列存資料分析集市將接管核心資料倉庫，避免兩套系統同時跑造成資源浪費。

• 資料集市：承擔核心倉庫的容災，以及資料集市的功能，向上層應用開放。分行存、列存建設。

下面我們介紹MPP叢集應用過程中遇到的一些問題及解決措施：

問題：MPP叢集裝載機高可用實現

問題描述：GBase叢集中的三臺載入機為三個獨立的點，三臺機器建立了相同的目錄，部署了相同的應用，每臺機器人為分配不同的作業，相當於人為實現負載均衡，但是一旦某個點宕機，此節點的作業就被迫停掉。換句話說，載入機無高可用。

問題解決：三臺載入機通過賽門鐵克高可用軟體實現三方互備，以VIP的方式實現業務漂移，可以做到在節點宕機時做到應用無感知遷移。改造後，三臺載入機最可實現2臺宕機不影響生產（處理能力會有相應下降）。

（示意圖）

隨著大資料處理和分析技術的不斷進步和完善，對大資料的研究和應用必將得到進一步的深化，大資料的價值也可以得到更大程度的挖掘和利用，並在企業運營過程中發揮著越來越重要的作用。

浙江移動通過企業級大資料平臺建設，並探討建設過程的問題和解決方案，解決了大資料平臺執行過程中的一些燃眉之急，同時增強了技術能力和知識儲備，為未來大資料百放齊放的應用生態打下堅實的基礎。

但正所謂“橫看成嶺側成峰，遠近高低各不同”，以上的問題分析和解決方案也許並不完全正確或完整，歡迎有更多志同道合的朋友一起交流和討論！大資料平臺建設不是一朝一夕的事，路漫漫其修遠兮，我們永遠都在路上。