大數據處理黑科技：揭秘PB級數倉GaussDB(DWS) 並行計算技術

摘要：通過這篇文章，我們了解了GaussDB(DWS)並行計算技術的原理以及調優策略。希望廣大開發者朋友們能夠在實踐中嘗試該技術，更好地進行性能優化。

隨着硬件系統的越來越好，數據庫運行的CPU、磁盤、內存資源都日漸增大，SQL語句的串行執行由於不能充分利用資源，已經不能滿足日益發展的需要。為此，GaussDB(DWS)開發了並行計算技術，在語句執行時可以充分利用硬件資源進行並行加速，提高執行的吞吐率。本文將詳細介紹GaussDB(DWS)並行計算技術的原理，以及其在performance信息中的展示，幫助各位開發者朋友更好地分析並行的性能，從而進行並行執行方面的調優。

並行計算的原理很簡單，將原本一個線程的工作平均分配到多個線程來完成，示意圖如下圖所示：圖示中的關聯操作，原本需要操作四份數據，通過並行度為4的並行計算后，每個子線程僅需要處理一份數據，理論上性能提升可以達到4倍。

通常情況下，理論上的性能提升是達不到的，因為並行計算也有其性能損耗，包括：啟動線程的代價，以及線程之間進行數據傳輸的代價。因此，只能性能損耗較低，大大低於並行帶來的收益時，並行計算的收益才比較明顯。所以，並行只有在數據量較大的場景下才能獲得較高的性能收益，非常適合於分析型的AP場景。

通過上述分析，我們可以看出，並行計算的難點不在於如何並行，而在於如何正確選擇並行度。當數據量較小時，也許串行的性能是最好的，當數據量增大時，可以考慮進行並行。對於一個復雜的執行計划來說，可能包含多個算子，每個算子處理的數據量都不一樣，如何綜合考慮並行度，以及處理好各算子之間的數據收發關系，將成為並行計算技術的關鍵難點。

GaussDB(DWS)基於代價估算，根據表的數據量信息來為計划片段生成合適的並行度，下面以TPC-DS Q48為例來看一下，GaussDB(DWS)的並行計划長什么樣？

select sum (ss_quantity)
 from   store_sales, store, customer_demographics, customer_address, date_dim
 where s_store_sk = ss_store_sk
 and    ss_sold_date_sk = d_date_sk and d_year = 1998
 and 
 (
  (
     cd_demo_sk = ss_cdemo_sk
     and
     cd_marital_status = 'M'
     and
     cd_education_status = '4 yr Degree'
     and
     ss_sales_price between 100.00 and 150.00 
     )
 or
  (
    cd_demo_sk = ss_cdemo_sk
     and
     cd_marital_status = 'D'
     and
     cd_education_status = 'Primary'
     and
     ss_sales_price between 50.00 and 100.00  
  )
 or  
 (
    cd_demo_sk = ss_cdemo_sk
    and
     cd_marital_status = 'U'
     and
     cd_education_status = 'Advanced Degree'
     and
     ss_sales_price between 150.00 and 200.00 
 )
 )
 and
 (
  (
    ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('KY', 'GA', 'NM')
    and ss_net_profit between 0 and 2000   
  )
 or
    (ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('MT', 'OR', 'IN')
    and ss_net_profit between 150 and 3000
  )
 or
    (ss_addr_sk = ca_address_sk
    and
    ca_country = 'United States'
    and
    ca_state in ('WI', 'MO', 'WV')
    and ss_net_profit between 50 and 25000
  )
 )
;

對應的performance信息為：

通過將performance信息轉變為計划樹，可以得到該計划的計划樹如下圖所示：其中1-3號算子在CN上執行，DN上以跨線程數據傳輸的Stream算子進行分隔，一共會啟動5個線程。GaussDB(DWS)采用pipeline的迭代執行模式，線程4和5從磁盤讀取數據，其它每個Stream算子分隔的線程從子線程讀取數據，進行執行，並將結果返回給上層算子，頂層DN線程將數據返回給CN處理。通過這個圖，我們可以看出，線程1，4，5采用的並行度是1，而線程2，3采用的並行度是26。通過計划信息，我們可以看出，8-13號算子處理的數據量較大，剛好是線程2，3處理的范圍，所以選擇了較高的並行度。

並行計算的Stream線程仍然沿用DN間的Stream線程進行啟動和停止，但DN內部的數據傳輸改為內存拷貝進行，更節省網絡資源，但帶來一定程度的內存開銷。同時，並行度的增大也使得跨DN間數據傳輸的數據緩沖區增大，內存開銷變大。因此，大內存也是提高並行度的一個必備因素。那么線程之間是如何進行並行度的銜接呢？

通過計划，我們可以看出，並行場景下，Stream線程均顯示為：Streaming(type: T dop:N/M)，這是在串行場景基礎上的擴展，同時也可以以線程為級別看到每個線程執行時間，處理的行數和使用的內存。在串行場景下，我們支持三種類型的Stream算子，分別為redistribute, broadcast和gather，詳細介紹參見《GaussDB(DWS)性能調優系列基礎篇二：大道至簡explain分布式計划》中第一章節介紹。

並行場景是對串行場景中DN上的redistribute和broadcast類型Stream算子進行擴充，包括以下幾類：

1）Streaming(type: SPLIT REDISTRIBUTE)：同串行場景下的Redistribute，但以線程為單位進行數據傳輸，每條元組發送給一個目的線程。

2）Streaming(type: SPLIT BROADCAST)：同串行場景下的Broadcast，但以線程為單位進行數據傳輸，每個線程都將收到全量數據。

3）Streaming(type: LOCAL REDISTRIBUTE)：作用是DN內部根據當前分布鍵進行數據Redistribute。通常作用於基表掃描后，因為基表掃描是按頁面進行線程划分，此時線程間並不是按DN的分布鍵分布的，需要增加該DN內重分布操作。

4）Streaming(type: LOCAL BROADCAST)：作用是DN內部進行數據Broadcast，每個線程把數據發送給這個DN的所有線程，每個線程獲得該DN的全量數據。5）Streaming(type: LOCAL GATHER)：作用是DN內部把數據從多線程匯總到一個線程。

注意：“dop:N/M”表示發送端的dop為M，接收端的dop為N，從而完成從M個線程的並行度轉變為N個線程並行度的任務。

在GaussDB(DWS)中，我們增加了參數query_dop，來控制語句的並行度，取值如下：

1）query_dop=1，串行執行，默認值

2）query_dop=[2..N]，指定並行執行並行度

3）query_dop=0，自適應調優，根據系統資源和語句復雜度情況自適應選擇並行度

由於開啟並行會占用較多的內存，所以目前GaussDB(DWS)的默認並行度為1。在內存較大的環境下，可以通過手動設置query_dop達到並行加速的目的。通常情況下，我們可以考慮首先設置query_dop=0，查看語句的執行計划、performance信息和性能。在performance信息的下方Query Summary一欄，可以看到自適應dop選擇的信息，例如：TPC-DS Q48 dop選擇信息如下圖所示，可以看出初步選定的initial dop為24，最終確定的final dop為26。dop的選擇會綜合考慮各種因素，其信息也在圖中顯示出來。

由於自適應選擇並行度是根據語句復雜度和系統資源利用情況來進行選擇，而系統資源利用情況是獲取前一段時間的資源利用情況，有可能出現不准確的情況，此時就需要人為來設置並行度了。人為設置並行度，並不是設置越大越好，dop設置過大，會導致系統中的線程數量急劇增多，導致CPU沖突進行線程切換的額外開銷。要想人為設置並行度，同樣需要使用單機CPU核數和語句復雜程度進行考量。我們定義單機CPU核數/單機DN數為每個DN可用的CPU核數x，然后根據串行計划中DN Stream算子的個數初步判定語句的復雜度y（例如下圖TPC-H Q1計划中只有一個Stream節點，則y為1），單並發時，使用x/y的值設置query_dop。並發場景，再除以並發數p設置query_dop。由於此公式為粗略估計值，因此在設置時可以考慮擴大搜索范圍，來尋找合適的並行度。

在並發場景下，GaussDB(DWS)還支持max_active_statements來控制執行語句的個數，當語句的個數超過CPU核數時，可以考慮使用該參數限制並發數，然后再設置合理的query_dop進行調優。還是以剛才的示例為例，單機有96核，2個DN，則每個DN可用48核，則同時執行6個TPC-H Q1查詢時，並行度可以設置為8。

通過這篇文章，我們了解了GaussDB(DWS)並行計算技術的原理以及調優策略。希望廣大開發者朋友們能夠在實踐中嘗試該技術，更好地進行性能優化。

 

點擊關注，第一時間了解華為雲新鮮技術~