新技術體系下大數據平台架構演進

1. 引言

近年，大數據相關應用發展迅猛，大數據技術亦隨之快速進化。這些技術以hadoop體系為基礎，不斷擴展完善其在數據存儲，計算和運維方面的能力，形成更強大的組件。隨著業務的發展出現瓶頸，新問題的湧現，我們不可避免會去尋找到這些新的組件，測試並完善，最終吸納接收。本文記錄DataEye數據平台組隨著開源社區的發展，在數據接入，調度器，數據計算，數據存儲和運維等方面不斷開拓新技術完善自身架構的過程。

2. 數據接入

接入系統是大數據平台的最基礎的部分，同時也是最關鍵的部分。大數據平台解決的兩大問題--存儲和計算都是針對數據的操作，所以數據的接入尤其重要。

傳統的數據接入方案都是在數據源安裝一個agent負責收集數據，然後把數據匯總到一起，按照不同的業務需求分發到不同的伺服器中，一般有批量和實時兩大部分。

基於以上思想，我們開發了一套自己的數據接入系統。其中有以下特點：

1、提供數據緩存功能

2、提供nginx作請求分發，充當負載均衡器。

3、多台logserver組成集群進行數據入庫。

我們的不足：

1、入庫功能比較單一，只能寫入HDFS和Kafka中。

2、寫入HDFS是通過crontab定時執行put操作上傳到HDFS中，不能實時寫入。

3、logserver代碼邏輯複雜，存在大量業務代碼，不容易維護。

基於以上幾點，我們需要尋找更好的數據接入系統。

目前市面上存在很多數據收集系統，使用比較廣泛的有sqoop、logstash、flume。sqoop一般用在從關係型資料庫導數據到hdfs中；logstash一般結合elasticsearch和kibana一起使用；而使用最廣泛而且功能最強大的是flume。flume是分散式的可靠的可用的系統，高效的從不同數據源收集聚合遷移大量數據到一個集中的數據存儲，使用基於事務的數據傳遞方式來保證事件傳遞的可靠性。基於以上特性，我們選擇flume作為新的數據接入系統。

我們的接入系統架構圖如下：

我們採用flume同時入庫到多個存儲組件中，提供給計算層作為數據源。

3. 調度器

任務調度系統是大數據計算里非常重要的組件。為了實現一次完整的計算，通常需要編寫多個MR任務，然後協調這些任務執行的先後順序，直到所有任務都執行完成，才能得到最終的結果。

基於這種思想，我們實現了一套純Java編寫的調度系統，其調度的核心在於：給每個任務都設定一個固定的執行時間點，到達這個時間點後，該任務會檢查指定目錄是否有上一個任務計算完成的標識文件(如done文件)，如果存在，則立即執行，否則就計算下一次調度的時間，重複以上過程。在我們的調度系統中，有以下特點：

1、配置任務只需要編寫Maper和Reducer模塊即可，不需要編寫提交類

2、可以重複執行和強制重複執行指定的任務

3、可以針對特定節點修改參數後再提交執行

4、支持cron表達式

但是缺點也是相當明顯的

1、界面簡陋

2、調度功能單一，不能實現上一個節點執行完成後，下一個立即執行，而是需要等到觸發的時間點

3、沒有任務流的可視化界面

4、只能調度MR和HIVE任務

為了支持更大規模的任務流調度，我們需要採用一套成熟的任務調度系統。目前市面上

存在的調度系統主要有Oozie、Airflow和Azkaban。其中知名度比較高的應該是ApachenOozie，但是其配置工作流的過程是編寫大量的XML配置，而且代碼複雜度比較高，不易於二次開發。另外一個應用也比較廣泛的調度系統是Airflow，但是其開發語言是Python。由於我們團隊內部使用Java作為主流開發語言，所以選型的時候就被淘汰掉了。我們選擇Azkaban的原因基於以下幾點：

1、提供功能清晰，簡單易用的Web UI界面

2、提供job配置文件快速建立任務和任務之間的依賴關係

3、提供模塊化和可插拔的插件機制，原生支持command、Java、Hive、Pig、Hadoop

4、基於Java開發，代碼結構清晰，易於二次開發

Azkaban的組成如下：

由上圖可知Azkaban的系統結構相當簡單，WebnServer提供前端訪問的web界面和接收HTTP請求，Executor Server負責執行相應的任務，MySQL則是用來保存元數據信息。

但是Azkaban也有一些不足的地方：

1、任務不能基於實例重跑

2、不支持cron表達式

3、需要編寫主類來執行MR任務

4、只能基於郵件告警

我們團隊對Azkaban做了大量的二次開發，吸收了我們老的調度器里的優點，也擴展了Azkaban原有的功能。具體改造情況如下：

1、由原來簡單按時間步長來調度任務，修改為支持cron表達式

2、由原來的郵件告警，修改為支持本公司的告警系統

3、添加重複執行實例的功能

4、支持把指定日期字元串解析為路徑

5、MR代碼提交方式的改造，不再需要編寫主類，通過配置的方式即可提交任務

通過以上改造後，Azkaban在保持原有功能的同時，也兼容了老調度器的優點。

4. 數據計算

Dataeye的計算平台分為實時計算和離線計算兩部分：

數據從接入系統進入kafka集群後，將分別進入實時處理的jstorm集群和離線處理的yarn/hdfs集群。

對於實時處理我們需要高穩定性和響應速度，我們選擇了單獨搭建jstorm集群來滿足我們實時處理的需求。一方面，單獨的jstorm集群更便於維護，減少了因為資源爭用而造成的影響實時系統穩定性的問題；另一方面，jstorm也支持我們做任何時間粒度實時計算的需求。

對於離線計算平台，我們選擇了yarn和hdfs，我們在yarn之上構建支持了不同數據計算引擎，包括spark、map-reduce和用於OLAP的kylin，通過組合這些不同的計算引擎來滿足我們各方面數據處理的需求。

通過yarn的資源抽象和管理能力，我們很容易的實現在一套集群上根據不同的需要選擇不同計算引擎的功能，且目前的數據處理框架一般對yarn的支持也比較完善，所以我們沒有選擇單獨搭建其他計算資源共享系統。在yarn中我們主要使用yarn的資源隊列、tag和彈性調度的功能來實現多租戶、多計算引擎的支持。例如，可以通過結合yarn的tag功能我們可以把spark任務儘可能的調度到我們大內存機器上。通過yarn我們也大大提高了我們集群資源的使用效率。

5. 數據存儲

• 傳統解決方案

業務上線初期，數據量通常較小，此時的應用，無論是側重OLTP還是OLAP，關係資料庫，如MYSQL都是很好的選擇。

但隨著業務的擴展，數據變化的多樣性及海量增長，MySql的可擴展能力及分析能力已顯得捉襟見肘，引入分散式存儲系統迫在眉睫。

• 分散式存儲系統要求

針對數據應用場景的不同以及數據組織的多樣性，如基於鍵值（Key-Value）的，有基於文檔（Document），還有基於列（Column）和圖表（Graph）的，如果採用單一的資料庫引擎，「一刀切式」的滿足所有類型的數據存儲需求，通常會嚴重降低資料庫管理的性能。因此，需要引入多元的數據存儲解決方案。

下面介紹數據平台幾種存儲系統（存儲引擎）的引入。

• Hive

Hive是一個典型的SQL on Hadoop的應用，Hive可以用傳統的SQL 讀寫和管理一個大規模的數據倉庫。由於其構建在HDFS之上，所以它繼承了HDFS的高可擴展性、高可用性和安全性。Hive將SQL轉化成一系列的MapReduce任務，執行後得到結果，大大減輕了數據分析人員的負擔，但也是由於其使用MapReduce作為計算引擎，所以數據訪問延遲較大，依然只適用離線分析的應用場景。在Hive即將發行的版本中，將集成Spark、Tez等計算引擎。這將大大降低在超大規模的數據倉庫上的數據分析時延。

• Impala

Impala是另一個SQL on Hadoop的應用。它的引入就是為了彌補Hive的不足，與Hive不同的是，它是一個可用於實時應用場景的系統。它避開了MapReduce計算引擎，採用了類似於商業的關係型資料庫中的並行計算引擎。因為查詢效率是Hive的多個數量級(order-of-magnitude)。與Hive類似，它同時支持一些面向行或者列的文件存儲格式，如：Text,RCFile,nParquet, ORCFile等。

• Hbase

Hbase是一個分散式的、面向列的開源資料庫。其設計理念源自谷歌的BigTable。在實時業務中，數據被送到Storm實時流引擎計算後，暫存於Redis集群；由於這些數據體量較大，指標通常較多(表寬，列多)，結構也具有不確定性，所以常常用Hbase來存儲，用於實時讀寫。

• Apache Kylin

在數據平台的部分業務中，存在一種需求：用戶通常需要關聯查詢，多個表的多個維度的匯總數據，這是一種典型的OLAP場景。Hive和Impala，固然能解決這種問題，然而Hive 的時延太高；impala對於單表查詢或者少量維度的連接查詢，性能尚可，但對於多個維度、大體量的表上顯得心餘力絀。然而，Apache Kylin正是解決這種問題的利刃。

Apache Kylin 是一個 實時(real-time)的OLAP onnHadoop的應用。n它可以通過ANSI-SQL,ODBC, JDBC,RESTful API等介面，提供基於hadoop的超大數據集（TB-PB級）的多維實時分析（OLAP）功能。

Apache Kylin以Hive數據倉庫為數據源，針對一個星型拓撲結構的數據立方體，預計算多個維度組合的度量，然後將結果保存在Hbase中，對外提供查詢分析功能。

• TITAN

對於圖（Graph）結構的數據和計算，我們引入TITAN. TITAN是一個分散式的圖資料庫，它可以存儲具有上千億級別頂點(vertice )和邊(edge)的圖結構在分散式集群中。另外TITAN是一個事務性的資料庫，可支持數千個用戶並發、實時地遍歷圖結構。

各種大數據處理技術存在能力互補，按照大數據處理技術能力互補原則，兼顧高效與低成本，結合當前技術發展狀態，業務應用場景等，採用多技術混搭方式實現大數據平台的存儲。

6. 運維繫統

Dataeye的大數據運維平台由以下幾個部分組成：部署和配置管理系統，平台各項metric採集、監控和告警系統，以及任務的自動化分析和優化框架。整個運維平台的建設的思路就是：自動化和靈活配置。

首先在平時的運維過程中會涉及到許多部署基礎軟體和變更配置信息的工作，在平台建設的初期，機器比較少，可能通過人工去部署和維護所有機器的配置信息也可以搞定，但隨著集群的快速發展，人工的方式越來越吃力和缺乏可維護性。在Dataeye我們通過fabric加上git來完成集群的部署和配置信息維護。在眾多的DevOps工具中我們選擇了fabric，主要是看中其簡單、靈活和依賴較少的特點。在fabric的基礎上我們封裝了一套基礎的介面，這些介面以合適的粒度包裝了常用的部署操作（例如安裝一個軟體包，執行基礎環境檢查，更新配置信息等等），然後通過組裝這些介面，我們可以很靈活的定義部署任務。對於集群的配置文件管理我們採用git進行版本化管理，所有配置信息放在主幹上版本化，對於某些機器需要特殊配置的（例如內存配置不同，磁碟有臨時壞盤）採用分支管理，更新集群的配置信息時只需要根據主幹和分支配置對不同機器進行更新即可，解決了配置管理的問題。

對於集群和任務執行的狀態進行監控，我們結合開源項目和內部平台，構建了一套完整的集指標採集、展示和監控告警為一體的系統。在指標採集方面充分利用各個基礎系統Metric數據，對於Metric指標中沒有的監控數據，我們採用logstash進行採集；對於採集的數據一方面寫入ganglia中進行展示，另一方面數據也會導入我們自己構建的監控告警系統，進行數據指標的監控和告警。對於任務的執行情況我們通過任務調度器azkaban的sal進行監控。

每天整個數據平台會運行非常多個各種任務，包括map-reduce、hive和spark等，一般情況下我們會通過yarn或者spark自身提供的web頁面去觀察任務的執行情況。對於任務的分析和優化，一方面只有在頁面上觀察和反映出問題的時候才去進行，這種方式比較被動和耗費精力；另一方面解決問題所使用的優化策略，也很難同步到所有的人。所以，我們希望任務的分析和性能優化這方面的工作儘可能做到自動化，並做到可以不斷積累優化經驗，使得分析和優化工作更加智能化。基於這種想法，我們使用了並改造了開源項目dr-elephant來自動化進行任務的分析和優化。dr-elephant通過我們自定義的啟發式優化規則來分析任務的執行的history的數據，如果任務的分析結果觸發了某些啟發規則，系統會給出優化提示。例如，如果任務處理大量的小文件，系統會提示進行文件合併或者採用CombineInputFormat格式，或者spark任務參數設置不合理等，並且這些啟發式規則可以不斷擴充，通過dr-elephant我們自動化了任務的分析和性能優化，使得整個數據平台的運行效率大大提高。

7. 總結

在各家工具都在標榜自身產品功能有多強大，性能有優越時，帶給開發者的難題其實是選擇上的困難。在我們看來不管是哪種產品在現實使用時往往只能解決一類問題，並不存在大一統的工具，例如在OLAP領域，我們需要權衡即席查詢的數據量，響應速度，維度，複雜度以及靈活性等多個方面的問題，最終得出的結論是必須多個工具一起上才能解決問題。

工具的多樣性給後期平台整體穩定運行帶來很大挑戰，為此，DE數平組的同事在工具選型，穩定性及性能測試時極為慎重，一個工具正式上線運營往往需要幾個月反覆測試，同時我們會積極探索平台的自運維能力，如採用啟發式的規則主動發現系統問題，這些在實際運維中都起到了非常好的效果。在經過不斷試錯創新之後，我們最終期望的是能構建一個功能強大，能長期穩定運行且具有自運維能力的數據平台。