【背景介紹】

國內某移動局點使用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分析效能瓶頸點，在針對性的調整相關的引數，這裡不一一介紹了，記住一點效能調優是個技術細活，引數調整要針對性的調整，一次調整隻調相關的一個或者幾個引數，在看效果，不生效就調整回去，切記千萬不要一次性調整的引數過多。