單表千億電信大數據場景，使用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.六、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模式固化中間表，提升查詢性能

序號	基於RDBMS的數據處理模式	基於hadoop的數據處理模式
1	強一致性	最終一致性，處理效率高於數據精確度
2	數據必須進行轉換，不然後續流程沒法繼續	數據能夠不作轉換，長期以原始格式存儲
3	數據必須進行清洗、範式化	數據不建議進行清洗和範式化
4	數據基本上都保存在物理表中，文件方式訪問效率低	數據大部分保存在文件中，物理表等同於結構化文件
5	元數據侷限爲字典表	元數據擴展爲HCatalog服務
6	數據處理引擎只有SQL一種	開放式的數據處理引擎：SQL、NOSQL、Java API
7	數據加工過程徹底由IT人員掌控	數據工程師、數據科學家、數據分析人員均可以參與數據加工

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的技術）：

對比項	SQL on Hadoop	MPPDB
容錯性	支持細粒度容錯,細粒度容錯是指某個task失敗會自動重試，不用從新提交整個查詢	粗粒度容錯，不能處理落後節點 (Straggler node)。粗粒度容錯是指某個task執行失敗將致使整個查詢失敗，而後系統從新提交整個查詢來獲取結果
擴展性	集羣節點數量能夠擴展到幾百甚至上千個	很難擴展到100個節點以上，通常在50個節點左右(好比以前咱們使用Greenplum驗證超過32臺機器性能出現降低)
併發性	隨着集羣規模可用資源增長，併發數近線性增加	MPPDB針對查詢會最大化利用資源，以提高查詢性能，所以支撐的併發數較低，通常併發查詢個數達到 20 左右時，整個系統的吞吐已經達到滿負荷狀態
查詢時延	一、數據規模小於1PB，單表10億記錄級別，單個查詢時延一般在10s左右 二、數據規模大於1PB，可經過增長集羣資源，保證查詢性能	一、數據規模小於1PB，單表10億記錄級別，單個查詢MPP時延一般在秒計甚至毫秒級之內就能夠返回查詢結果 二、數據規模大於1PB，受架構限制，查詢性能可能會出現急劇降低
數據共享	存儲與計算分離，通用的存儲格式能夠支撐不一樣的數據分析引擎，包括數據挖掘等	獨有的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分析性能瓶頸點，在針對性的調整相關的參數，這裏不一一介紹了，記住一點性能調優是個技術細活，參數調整要針對性的調整，一次調整隻調相關的一個或者幾個參數，在看效果，不生效就調整回去，切記千萬不要一次性調整的參數過多。