摘要： 2017年中國大資料技術大會於12月7-9日在北京新雲南皇冠假日酒店隆重舉行, 大會就大資料時代社會各行業的智慧化程式和行業實踐展開深入討論。 在12月8日的“大資料分析與生態系統”分論壇上，來自阿里巴巴計算平臺事業部的高階技術專家少傑，以“MaxCompute 複雜資料分佈的查詢優化實踐”為題，為現場來賓分享了阿里雲MaxCompute最新技術與實踐的洞察與經驗。
2017年中國大資料技術大會於12月7-9日在北京新雲南皇冠假日酒店隆重舉行, 大會就大資料時代社會各行業的智慧化程式和行業實踐展開深入討論。
在12月8日的“大資料分析與生態系統”分論壇上，來自阿里巴巴計算平臺事業部的高階技術專家少傑，以“MaxCompute 複雜資料分佈的查詢優化實踐”為題，為現場來賓分享了阿里雲MaxCompute最新技術與實踐的洞察與經驗。
概述
資料分佈的問題在大資料處理領域由來已久。很不幸，如今流行的大資料處理系統仍然沒有很好地解決這個問題。在MaxCompute 2.0全新的優化器中，我們引入了複雜資料分佈，新增了分割槽剪枝、分佈上拉、下推以及分佈對齊等優化措施。本文將從資料分佈的歷史和原理開始，介紹我們的思路和解決辦法。
理解資料分佈
提到資料分佈，很多人會想到MPP DBMS。的確，我們通常說只有MPP DBMS才需要考慮資料分佈優化。先考慮一個流行的分散式資料庫分類學：
Shared Everything: 區別於後兩類，這一類基本不是分散式的。
Shared Disk: 資料庫伺服器可以橫向擴充套件，他們本身沒有儲存器，通過SAN或NAS技術連線到後端同樣可以橫向擴充套件的統一儲存。受限於這層網路連線，資料庫伺服器的擴充套件能力非常有限。Oracle RAC等商業分散式資料庫屬於這類。
Shared Nothing: 區別於Shared Disk，這種架構讓資料庫伺服器和儲存落在相同的物理節點上（co-located），使得物理節點之間不share任何資訊，這大幅減少了網路IO。MPP DBMS和Hadoop屬於這類。
顯然，只有Shared Nothing的資料庫才需要考慮資料分佈，你需要預知怎樣把資料分佈到不同的物理節點（而不是像Shared Disk那樣放在統一儲存），會使後續的操作代價更小。例如，在Greenplum中，必須在建表時指定partition key，系統會按照指定的key（雜湊）分佈資料。如果Join的兩張表都按照join key來partition，這個Join就不需要網路IO。如果其中一張表使用了另一組partition key，那麼可能要做一次re-partition。
這就是為什麼要理解資料分佈的原因：它對應用優化和系統優化都是非常重要的。MPP DBMS在資料分佈上都有比較深的積累。但是為什麼Hadoop這種大資料處理系統沒有這類優化？是因為他們需要更強的擴充套件能力（以及非結構化資料支援，我們不展開這個話題）。
區別於MPP，Hadoop並不是在物理上強制資料和計算在相同節點，如果這麼做，系統的橫向擴充套件能力仍然受限。特別是動態擴充套件能力，考慮正在執行的一個50個節點的Greenplum叢集，我們基本無法做到快速地加入例如2個節點還能高效工作。Hadoop在這方面是很在行的，它的解決辦法主要是：
1、儲存計算分離
2、去中心化的設計支援高效的peer to peer讀寫（HDFS）
這就是為什麼你在Hive中建立一張表時，無須像Greenplum中那樣指定partition key，同時Hive在Join的效率低於Greenplum的原因。
資料分佈優化的目的
如上文所述，大資料分散式系統在儲存系統上通常傾向隨機分佈，這提升了擴充套件性，犧牲了效能。但是重新審視這個權衡，在儲存系統上隨機分佈並不意味著我們不能利用資料分佈優化查詢。分佈優化的目的是希望儘可能的利用已經存在的分佈，並儘可能滿足未來要求的分佈。這種優化包括：
1、分割槽剪枝：利用資料分佈特性，我們可以做分割槽剪枝來減少資料讀取。例如，雜湊分佈對於點查詢，範圍分佈對於區間查詢可以應用分割槽剪枝。
2、消除重分佈：如果當前的分佈滿足後續演算法的要求，我們可以消除額外的重分佈操作。眾所周知，重分佈（在Hadoop中叫做shuffle）是分散式演算法最主要的消耗。
3、避免資料傾斜：可以使用更好的資料分佈演算法避免資料傾斜。例如，某些單值重複率很高（end-biased）的資料集，使用範圍分佈而不是雜湊分佈可能會有效避免資料傾斜帶來的效能影響。
定義
資料分佈型別
資料分佈型別和對應的意義和範例如下所示：
實現
在不破壞Volcano優化器語義的前提下，我們把分佈特性實現為一種physical property，稱作distribution。和其他property一樣，它有required property和delivered property成對的屬性。例如，對於sorted merge join，它對所有輸入會施加一個Partial Ordered的required property，同時自身會deliver一個Partial Ordered property，這使得它的後繼操作有機會利用這個property，避免一次重新分佈。考慮以下查詢：
此時Join如果被實現為Sorted Merge Join，它可能會deliver一個Hash[uid]的property，這正好被Aggregate要求，那麼這裡我們就可以省去一次不必要的重分佈操作。
要做到類似的優化效果，我們需要關注下列問題：
1、收集分佈特性
2、（區域性關係代數編譯）選擇合適的分佈特性
3、（全部代價計算上）規避不合適的分佈特性
收集分佈特性
產生資料分佈有3種途徑：
1、使用者指定：就像MPP那樣，可以在DDL中引入partition key，允許使用者指定資料分佈。當然區別於MPP，這種分佈僅要求在分散式檔案系統上的目錄結構，並不能關聯具體的物理節點。
2、SQL邏輯：SQL邏輯可能產生一次執行時的資料分佈。例如distribute by字句宣告瞭一次執行時的資料分佈。
3、演算法的副作用：每個分散式演算法可能產生一次執行時資料分佈。例如，sorted merge join可以保證它的輸出資料滿足按join key的有序和雜湊分佈的特徵。
有若干演算法要求一種特殊的資料分佈：
1、Aggregate：Sorted Aggregate要求grouping key的Hash分佈。
2、Join：Sorted Merge Join和Hash Join都要求輸入按照join key的相同Hash分佈。
3、Sort：Order by要求sort key上的Range分佈，或Singleton分佈。
選擇合適的分佈特性
即使給定了一系列required和delivered distribution property， 確定某個操作的分佈仍然不是容易的事情。區別於ordering property（僅有排序列和升降序的屬性），distribution property的變化很多，這些變化的原因包括：
1、滿足要求的分佈有多種選擇。例如group by a, b, c這個aggregate，對輸入有按a, b, c的Partial Ordered的要求，它對ordering的要求是a, b, c有序，但是滿足它的分佈可以是Hash(a), Hash(b), Hash(a,b), Hash(a,b,c), RNG(a)等不同的組合。
2、能利用的實現分佈有多種選擇。例如join a and b on a.id = b.id這個join，如果a服從Hashid, b服從Hashid，對於Sorted Merge Join，它可以選擇要求Hashid，或Hashid，甚至任意Hash(id)。
這些複雜度加大了最優計劃的搜尋空間。事實上，最優計劃是相對於關係代數數量的一個NPC問題。為了縮小搜尋空間，我們引入了啟發式的分支選擇演算法。在編譯一個關係代數時，不僅需要滿足後繼操作的要求，還要考慮前序操作提供滿足的分佈的可能性，後者被實現為稱作Pulled Up Property的模組。
Pulled Up Property猜測並篩選可能的前序delivered property，用於在編譯時減少搜尋寬度。考慮上圖的查詢，在Join編譯時，因為Sink的需求下推，它被要求提供一個Hashc1。Pulled Up Property則從前序操作猜測可能會提供Hashc1和Hashc1，綜合考慮，Join可能會直接要求Hashc1，從而減少了Hashc1和Hashc1這兩個分支。
規避不合適的分佈特性
資料傾斜（Skew）是指在分佈中少量節點被分配了大部分資料，導致整個演算法退化為單機操作。低併發（Under Partition）是指分佈指定了過少的節點，是的分散式資源不能被有效利用。我們希望能避免這兩種情況。
很顯然，更好的統計資訊會幫助我們規避這兩種情況。Skew和Under Partition的情況下，需要對代價估計做相應的懲罰，降低他們被選為最優計劃的可能性。我們定義”好”的分佈是每個節點處理的資料量在一個預設的範圍，低於或高於這個範圍都會被施加懲罰。估計這個資料量的依據包括：
1、輸入資料記錄數（row count）
2、重複度最高的資料（top values）
3、直方圖（histogram）
總結
在這篇文章中，我們介紹了資料分佈優化的問題和意義，並解釋了MaxCompute在資料分佈優化上的實踐。這一優化效果已經體現在MaxCompute最新的釋出中。
從我們的測試來看，這個優化有相當顯著的效果。我們對TPC-H進行了適當分割槽後，整體效能提升在20%的量級。即使沒有對錶資料分割槽，對使用者完全透明的執行時分割槽優化也有很好的效果。在我們線上執行的環境中，14%的查詢因為這個優化減少了至少一次資料重分佈。