本發(fā)明涉及數據庫數據處理領域，具體地，涉及一種面向分布式內存數據庫查詢引擎的數據分發(fā)方法。

背景技術：

數據庫查詢引擎負責執(zhí)行數據查詢任務的部分，接收用戶的查詢請求，向用戶返回查詢結果，屏蔽具體的查詢執(zhí)行過程。查詢引擎對外提供標準sql的查詢接口，向用戶返回與傳統數據庫系統相同組織形式的查詢結果，可向上適配任意滿足sql標準的客戶端或中間件。同時向下適配滿足該查詢引擎協議的列式存儲系統。

數據庫查詢引擎其主要承擔的職責或功能如下：

1、解析用戶的sql查詢語句，生成查詢計劃；

2、基于規(guī)則和代價對查詢計劃進行優(yōu)化，使之具有最小的預估執(zhí)行代價；

3、與數據存儲系統交互，執(zhí)行查詢計劃，獲取數據；

4、根據查詢條件進行數據的計算和合并；

5、生成最終查詢結果，返回給用戶。

目前主流分布式內存數據庫查詢引擎的中間數據切分方式是固定的，但也因此限制了算子的擴展方式。如果算子的擴展方式被限制，則會導致任務并行度降低。因為sql查詢語句在查詢引擎中會轉換為一個dag物理計劃，如果在任務推進過程中數據無法二次切分，隨著任務的推進，后繼任務數目會越來越少，并行度必然大大降低。

綜上所述，本申請發(fā)明人在實現本申請發(fā)明技術方案的過程中，發(fā)現上述技術至少存在如下技術問題：

在現有技術中，現有的分布式內存數據庫查詢引擎存在限制了算子的擴展方式導致任務并行度降低的技術問題。

技術實現要素：

本發(fā)明提供了一種面向分布式內存數據庫查詢引擎的數據分發(fā)方法，解決了現有的分布式內存數據庫查詢引擎存在限制了算子的擴展方式導致任務并行度降低的技術問題，提高了任務并行度的技術效果。

為解決上述技術問題，本申請?zhí)峁┝艘环N面向分布式內存數據庫查詢引擎的數據分發(fā)方法，所述方法包括：

數據庫查詢引擎中的前置算子計算完成后，數據庫查詢引擎對計算完成后的數據進行切分，然后將切分后的數據分發(fā)給數據庫查詢引擎中的后繼算子。

本發(fā)明是一種面向分布式內存數據庫的數據分發(fā)方法。切片方式及分發(fā)策略相當于mapreduce或者spark任務中，中間數據如何分發(fā)shuffle。

進一步的，前置算子中計算完成后的數據切分后按照一個前置算子分區(qū)對應一個后繼算子分區(qū)的方式分發(fā)給后繼算子，或前置算子中計算完成后的數據按照多個前置算子分區(qū)對應一個后繼算子分區(qū)的方式分發(fā)給后繼算子。

進一步的，前置算子分區(qū)按照特定的哈希(hash)函數將切分后的數據分發(fā)給后繼算子分區(qū)。

進一步的，前置算子包括：一元算子、二元算子、無前置算子。

進一步的，當前置算子為getcolumn算子時：

getcolumn算子為物理執(zhí)行計劃中的第一個算子，只需要獲取這一列的數據。因此我們不需要設置十分復雜的數據分布方式，只需要指定分片數(默認分片數等于存儲引擎中該列數據的分片數即slice數)，然后按照輪詢調度(roundrobin)的方式和存儲引擎中該列數據的分片數slice對應起來。

進一步的，當前置算子為filter算子時：

filter算子是對行號rowid進行處理，我們可以指定filter算子按照哈希散列hashdistribution的方式進行處理。hash函數為fhash＝rowid％filter_num。這樣就保證了左右算子相同的rowid分布到相同的filter的算子中，而且數據不需要重復傳輸。

進一步的，當前置算子為join算子時：

由于join算子是olap(海量數據聯機分析處理業(yè)務)中的核心算子，所以我們對join算子提出了多種優(yōu)化策略。

分布式內存數據庫系統的元數據負責收集數據庫存儲引擎的數據分布信息，為每張表的每個列生成數據直方圖統計信息。join算子執(zhí)行過程中需要判斷前置輸入來源于大表還是小表，大小表根據數據直方圖元數據信息界定。

如果前置算子中某個表是小表，采用將小表數據轉發(fā)至存放大表數據節(jié)點ordereddistribution的方案，分發(fā)shuffle過程簡單，而且增加的數據傳輸量也不大，這種方案具有明顯的優(yōu)勢。然后join算子內部采用內部采用hashjoin進行連接操作join。

如果前置算子并沒有明顯的大小表關系。采用哈希散列hashdistribution的方案，hash函數為。然后內部采用排序合并連接sortmergejoin算法。

本方案所提出的數據分發(fā)策略，指的是前置算子計算完成后，選取最佳的切分方式對數據進行切分，然后將結果通過最佳分發(fā)方法發(fā)送給下一個物理算子。通過該數據分發(fā)策略，可以避免后繼任務數目的減少，大大提高了并行度，從而使得數據庫查詢引擎在計算過程中始終可以充分利用物理資源。

本申請?zhí)峁┑囊粋€或多個技術方案，至少具有如下技術效果或優(yōu)點：

根據本方案提出的數據切片方式，可以自由指定后繼任務的個數，從而避免了后繼任務并行度降低的情況。在對查詢引擎進行性能測試過程中發(fā)現，相對于傳統分布式內存數據庫的數據切分方案，本方案對每一個任務都進行了針對性的數據切分方式和分發(fā)方式的選擇。避免了在查詢引擎中由于任務數量不斷減少而導致的并行度降低的問題，滿足了分布式內存數據庫查詢引擎在計算過程中始終可以充分利用物理資源的需求。

附圖說明

此處所說明的附圖用來提供對本發(fā)明實施例的進一步理解，構成本申請的一部分，并不構成對本發(fā)明實施例的限定；

圖1是本申請中的一對一分發(fā)方式示意圖；

圖2是本申請中的多對一分發(fā)方式示意圖；

圖3是本申請中的join算子中對數據的哈希分發(fā)方式示意圖；

圖4是本申請中的join算子中對數據的范圍分發(fā)方式示意圖；

圖5是本申請中的getcolumn算子中對數據的輪詢調度分發(fā)方式示意圖；

圖6是本申請中的filter算子對行號的哈希分發(fā)方式示意圖；

圖7是本申請中的join算子在前置算子有明顯的大小表關系時的分發(fā)策略示意圖；

圖8是本申請中join算子在前置算子沒有明顯的大小表關系時的分發(fā)策略示意圖。

具體實施方式

本發(fā)明提供了一種面向分布式內存數據庫查詢引擎的數據分發(fā)方法，解決了現有的分布式內存數據庫查詢引擎存在限制了算子的擴展方式導致任務并行度降低的技術問題，提高了任務并行度的技術效果。

為了能夠更清楚地理解本發(fā)明的上述目的、特征和優(yōu)點，下面結合附圖和具體實施方式對本發(fā)明進行進一步的詳細描述。需要說明的是，在相互不沖突的情況下，本申請的實施例及實施例中的特征可以相互組合。

在下面的描述中闡述了很多具體細節(jié)以便于充分理解本發(fā)明，但是，本發(fā)明還可以采用其他不同于在此描述范圍內的其他方式來實施，因此，本發(fā)明的保護范圍并不受下面公開的具體實施例的限制。

請參考圖1，本申請?zhí)峁┝艘环N面向分布式內存數據庫查詢引擎的數據分發(fā)方法，所述方法包括：

數據庫查詢引擎中的前置算子計算完成后，數據庫查詢引擎對計算完成后的數據進行切分，然后將切分后的數據分發(fā)給數據庫查詢引擎中的后繼算子。

根據不同算子面臨的不同情況提出了多種數據分片方式，主要包含以下三種：

1.singledistribution：

前置算子分區(qū)采取一對一，或者多對一的方式將數據發(fā)送給后繼算子分區(qū)，請參考圖1-圖2。

2.hashdistribution：

前置算子分區(qū)將數據按照特定的hash函數將數據分發(fā)給后繼算子分區(qū)。這種方式的優(yōu)點是靈活，只需要知道后繼算子的分區(qū)數，就能確定某條數據需要發(fā)送給哪個分區(qū)，請參考圖3。

3.ordereddistribution：

ordereddistribution可以理解成是hashdistribution的一種特例，只是hash函數為按照值范圍映射，請參考圖4。

查詢引擎中涉及到的物理算子按照前置算子的個數可以分為：一元算子，二元算子，無前置算子。下面列舉出其中以上各類中的主要算子：無前置算子：getcolumn算子、一元算子：order算子、二元算子：filter算子、join算子。

因為一元算子不會導致后續(xù)任務數量減少，所以下面列舉getcolumn算子、filter算子、join算子利用本數據切片策略后的具體執(zhí)行流程。

getcolumn算子：

請參考圖5，getcolumn算子為物理執(zhí)行計劃中的第一個算子，只需要獲取這一列的數據。因此我們不需要設置十分復雜的數據分布方式，只需要指定分片數(默認分片數等于slice數)，然后按照roundrobin的方式和slice對應起來。

filter算子：

請參考圖6，filter算子是對rowid進行處理，我們可以指定filter算子按照hashdistribution的方式進行處理。hash函數為fhash＝rowed％filter_num。這樣就保證了左右算子相同的rowid分布到相同的filter的算子中，而且數據不需要重復傳輸。

join算子：

由于join算子是olap中的核心算子，所以我們對join算子提出了多種優(yōu)化策略。

系統的元數據負責收集數據庫存儲引擎收集數據分布情況，為每張表的每個列生成數據直方圖統計信息。join算子執(zhí)行過程中需要判斷前置輸入來源于大表還是小表，大小表根據數據直方圖元數據信息界定。

請參考圖7，如果前置算子中某個表是小表，采用ordereddistribution的方案，shuffle過程簡單，而且增加的數據傳輸量也不大，這種方案具有明顯的優(yōu)勢。然后join算子內部采用hashjoin進行join。

請參考圖8，如果前置算子并沒有明顯的大小表關系。采用hashdistribution的方案，hash函數為fhash＝value％join_num。然后內部采用sortmergejoin算法。

本發(fā)明是一種面向分布式內存數據庫的數據分發(fā)方法。切片方式及分發(fā)策略相當于mapreduce或者spark任務中，中間數據如何shuffle。

方案所提出的數據切分策略，指的是前置算子計算完成后，選取最佳的切分方式對數據進行切分，然后將結果發(fā)送給下一個物理算子。

方案中對每一個任務都進行了針對性的數據切分方式和分發(fā)方式的選擇。避免了在查詢引擎中由于任務數量不斷減少而導致的并行度降低的問題，滿足了分布式內存數據庫查詢引擎在計算過程中始終可以充分利用物理資源的需求。

上述本申請實施例中的技術方案，至少具有如下的技術效果或優(yōu)點：

根據本方案提出的數據切片方式，可以自由指定后繼任務的個數，從而避免了后繼任務并行度降低的情況。在對查詢引擎進行性能測試過程中發(fā)現，相對于傳統分布式內存數據庫的數據切分方案，本方案對每一個任務都進行了針對性的數據切分方式和分發(fā)方式的選擇。避免了在查詢引擎中由于任務數量不斷減少而導致的并行度降低的問題，滿足了分布式內存數據庫查詢引擎在計算過程中始終可以充分利用物理資源的需求。

盡管已描述了本發(fā)明的優(yōu)選實施例，但本領域內的技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本發(fā)明范圍的所有變更和修改。

顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。