使用Spark+CarbonData替換Impala實例分析

本篇文章給大家分享的是有關使用Spark+CarbonData替換Impala實例分析，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

國內某移動局點使用Impala組件處理電信業務詳單，每天處理約100TB左右詳單，詳單表記錄每天大于百億級別，在使用impala過程中存在以下問題:

1. 詳單采用Parquet格式存儲，數據表使用時間+MSISDN號碼做分區，使用Impala查詢，利用不上分區的查詢場景，則查詢性能比較差。

   
   

2. 在使用Impala過程中，遇到很多性能問題(比如catalog元數據膨脹導致元數據同步慢等)，并發查詢性能差等。

   
   

3. Impala屬于MPP架構，只能做到百節點級，一般并發查詢個數達到20左右時，整個系統的吞吐已經達到滿負荷狀態，在擴容節點也提升不了吞吐量。

   
   

4. 資源不能通過YARN統一資源管理調度，所以Hadoop集群無法實現Impala、Spark、Hive等組件的動態資源共享。給第三方開放詳單查詢能力也無法做到資源隔離。

   
   

針對上面的一系列問題，移動局點客戶要求我們給出相應的解決方案，我們大數據團隊針對上面的問題進行分析，并且做技術選型，在這個過程中，我們以這個移動局點的幾個典型業務場景作為輸入，分別對Spark+CarbonData、Impala2.6、HAWQ、Greenplum、SybaseIQ進行原型驗證，性能調優，針對我們的業務場景優化CarbonData的數據加載性能，查詢性能并貢獻給CarbonData開源社區，最終我們選擇了Spark+CarbonData的方案，這個也是典型的SQL On Hadoop的方案，也間接印證了傳統數據倉庫往SQL on Hadoop上遷移的趨勢。參考社區官網資料，結合我們驗證測試和理解：CarbonData是大數據Hadoop生態高性能數據存儲方案，尤其在數據量較大的情況下加速明顯，與Spark進行了深度集成，兼容了Spark生態所有功能（SQL,ML，DataFrame等），Spark+CarbonData適合一份數據滿足多種業務場景的需求，它包含如下能力：

1. 存儲：行、列式文件存儲，列存儲類似于Parquet、ORC，行存儲類似Avro。支持針對話單、日志、流水等數據的多種索引結構。

   
   

2. 計算：與Spark計算引擎深度集成和優化；支持與Presto, Flink, Hive等引擎對接；

   
   

3. 接口：    

1. API：兼容DataFrame, MLlib, Pyspark等原生API接口；

2. SQL：兼容Spark語法基礎，同時支持CarbonSQL語法擴展（更新刪除，索引，預匯聚表等）。

4. 數據管理：    

1. 支持增量數據入庫，數據批次管理(老化管理)

2. 支持數據更新，刪除

3. 支持與Kafka對接，準實時入庫

詳細的關鍵技術介紹以及使用，請上官網閱讀查看文檔https://carbondata.apache.org/  

這里補充介紹下為什么選取SQL on Hadoop技術作為最終的解決方案。

接觸過大數據的人都知道，大數據有個5V特征，從傳統互聯網數據到移動互聯網數據，再到現在很熱門的IoT，實際上隨著每一次業界的進步，數據量而言都會出現兩到三個數量級的增長。而且現在的數據增長呈現出的是一個加速增長的趨勢，所以現在提出了一個包括移動互聯網以及物聯網在內的互聯網大數據的5大特征：Volume、 Velocity、Variety、Value、Veracity。隨著數據量的增長傳統的數據倉庫遇到的挑戰越來越多。

傳統數據倉庫面臨的挑戰:

同時數據體系也在不斷的進化

• 存儲方式的進化：離線、近線 -> 全部在線

• 存儲架構的進化：集中式存儲 -> 分布式存儲

• 存儲模型的進化：固定結構 -> 靈活結構.

數據處理模式的進化

• 固定模型固定算法 -> 靈活模型靈活算法

數據處理類型的進化

• 結構化集中單源計算 -> 多結構化分布式多源計算

數據處理架構的進化

• 數據庫靜態處理 -> 數據實時/流式/海量處理

針對上述的變化數據庫之父Kimball提出了一個觀點：

Kimball的核心觀點：

hadoop改變了傳統數倉庫的數據處理機制，傳統數據庫的一個處理單元在hadoop中解耦成三層：

• 存儲層：HDFS

• 元數據層：Hcatalog

• 查詢層：Hive、Impala、Spark SQL

Schema on Read給了用戶更多的選擇：

• 數據以原始格式導入存儲層

• 通過元數據層來管理目標數據結構

• 由查詢層來決定什么時候提取數據

• 用戶在長期探索和熟悉數據之后，可以采取Schema on Write模式固化中間表，提高查詢性能                                                                                                                                                                                     

SQL on Hadoop數據倉庫技術

數據處理和分析

     ? SQL on hadoop

     ? Kudu+Impala、Spark、HAWQ、Presto、Hive等

? 數據建模和存儲

           ? Schema on Read

           ? Avro & ORC & Parquet & CarbonData

? 流處理

           ? Flume+Kafka+Spark Streaming

SQL-on-Hadoop技術的發展和成熟推動變革

經過上述的技術分析，最終我們選擇了SQL on Hadoop的技術作為我們平臺未來的數據倉庫演進方向，這里肯定有人問了，為什么不選取MPPDB這種技術呢，這里我們同樣把SQL on Hadoop與MPPDB進行過對比分析（注Impala其實也是一種類似MPPDB的技術）：                                                                         

局點2018年9月底上線Spark+CarbonData替換Impala后運行至今，每天處理大于100TB的單據量，在業務高峰期，數據加載性能從之前impala的平均單臺60MB/s到平臺單臺100MB/s的性能，在局點典型業務場景下，查詢性能在20并發查詢下，Spark+CarbonData的查詢性能是Impala+parquet的2倍以上。

同時解決了以下問題：

1. Hadoop集群資源共享問題，Impala資源不能通過Yarn統一資源調度管理，Spark+CarbonData能通過Yarn統一資源調度管理，實現與其他如Spark，Hive等組件的動態資源共享。

2. Hadoop集群擴容問題，之前Impala只能使用百臺機器，現在Spark+CarbonData能做到上千臺節點集群規模。

實施過程中注意項：

1. 數據加載使用CarbonData的local sort方式加載，為了避免大集群產生過多小文件的問題，加載只指定少數機器上進行數據加載，另外對于每次加載數據量比較小的表可以指定表級別的compaction來合并加載過程中產生的小文件。

2. 根據業務的查詢特點，把經常查詢過濾的字段設置為數據表的sort column屬性(比如電信業務經常查詢的用戶號碼等)，并且設置sort column的字段順序先按照字段的查詢頻率由高到低排列，如果查詢頻率相差不大，則再按照字段distinct值由高到低排列，來提升查詢性能。

3. 創建數據表設置的blocksize大小，單個表的數據文件block大小可以通過TABLEPROPERTIES進行定義，單位為MB，默認值為1024MB。這個根據實際數據表的每次加載的數據量，根據我們實踐經驗：一般建議數據量小的表blocksize設置成256MB，數據量比較大的表blocksize設置成512MB。

4. 查詢性能的調優，還可以結合業務查詢的特點，對查詢高頻率的字段，創建bloomfilter等datamap來提升查詢性能。

5. 還有一些Spark相關的參數設置，對于數據加載和查詢，先結合SparkUI分析性能瓶頸點，在針對性的調整相關的參數，這里不一一介紹了，記住一點性能調優是個技術細活，參數調整要針對性的調整，一次調整只調相關的一個或者幾個參數，在看效果，不生效就調整回去，切記千萬不要一次性調整的參數過多。

以上就是使用Spark+CarbonData替換Impala實例分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。