MaxCompute - ODPS重裝上陣 第四彈 - CTE,VALUES,SEMIJOIN

摘要: MaxCompute(原ODPS)是阿里雲自主研發的具備業界領先水平的分佈式大數據處理平臺, 尤爲在集團內部獲得普遍應用,支撐了多個BU的核心業務。 MaxCompute除了持續優化性能外,也致力於提高SQL語言的用戶體驗和表達能力,提升廣大ODPS開發者的生產力。html

 

點此查看原文sql

 

MaxCompute(原ODPS)是阿里雲自主研發的具備業界領先水平的分佈式大數據處理平臺, 尤爲在集團內部獲得普遍應用,支撐了多個BU的核心業務。 MaxCompute除了持續優化性能外,也致力於提高SQL語言的用戶體驗和表達能力,提升廣大ODPS開發者的生產力。數據庫

MaxCompute基於ODPS2.0新一代的SQL引擎,顯著提高了SQL語言編譯過程的易用性與語言的表達能力。咱們在此推出MaxCompute(ODPS2.0)重裝上陣系列文章分佈式

第一彈 - 善用MaxCompute編譯器的錯誤和警告
第二彈 - 新的基本數據類型與內建函數
第三彈 - 複雜類型
第四彈 - CTE,VALUES,SEMIJOIN函數

上次向您介紹了複雜類型,從本篇開始,向您介紹MaxCompute在SQL語言DML方面的改進性能

  • 場景1 
    _須要寫一個復現的SQL, 從多個表中讀取數據,有些之間作Join,有些之間作Union,生成中間數據又要Join, 最後須要輸出多張表,最後寫成了n層嵌套的子查詢,本身都看不懂了。並且一樣的查詢,在不一樣的子查詢中有重複。爲了維護方便,把複雜的語句拆成多個語句,可是發現每一個語句都須要單獨提交,排隊,而且要將中間結果寫到原本不須要的臨時表,在後面的語句中再讀出來,慢了好多。。。
  • 場景2
    正在開發新項目,須要給一個小數據表準備些基本數據,可是沒有INSERT ... VALUES 語句,沒辦法把數據和建立表的DDL放在一塊兒維護,只好另用一些腳本,調用ODPS命令行準備數據。。。
  • 場景3
    想測試一個新寫的UDF,只寫SELECT myudf('123');會報錯,還必須建立一個dual表,裏面加一行數據,好麻煩。若是測試UDAF,還要在測試表裏面準備多行數據,每次測試不一樣的輸入都要修改表內容或者建立新表,若是有個辦法不用建立表也能不一樣的數據組合測試個人UDF就行了。。。
  • 場景4
    遷移一個原來在Oracle上面的ETL系統,發現用了 WHERE EXISTS( SELECT ...) 和 WHERE IN (SELECT ...) 這類的語句,但是發現ODPS在這方面支持不完整,還要手工將這些半鏈接的語句轉換爲普通JOIN,再過濾。。。

MaxCompute採用基於ODPS2.0的SQL引擎,對DML進行了大幅擴充,提升了易用性和兼容性,基本解決了上述問題。測試

Common Table Expression (CTE)

MaxCompute支持SQL標準的CTE。可以提升SQL語句的可讀性與執行效率。大數據

此文中採用MaxCompute Studio做展現,首先,安裝MaxCompute Studio導入測試MaxCompute項目,建立工程,創建一個新的MaxCompute腳本文件, 以下優化

screenshot.png

能夠看到,頂層的union兩側各爲一個join,join的左表是相同的查詢。經過寫子查詢的方式,只能重複這段代碼。阿里雲

使用CTE的方式重寫以上語句
image.png

能夠看到,a對應的子查詢只須要寫一次,在後面重用,CTE的WITH字句中能夠指定多個子查詢,像使用變量同樣在整個語句中反覆重用。除了重用外,也沒必要再反覆嵌套了。

編譯此腳本,能夠觀察執行計劃以下
screenshot.png

其中M1, M2, M4三個分佈式任務分別對應對應三個輸入表,雙擊M2能夠看到中具體執行的DAG(在DAG中再次雙擊能夠返回),以下

screenshot.png

能夠看到對src讀後進行過濾的DAG。對src的讀取與過濾在整個執行計劃中只須要一次 ( 注1 )。

VALUES

建立一個新的文件,以下:
screenshot.png

執行後在,MaxCompute Project Explorer中能夠找到新建立的表,並看到values中的數據已經插入到表中,以下:
screenshot.png

有的時候表的列不少,準備數據的時候但願只插入部分列的數據,此時能夠用插入列表功能
screenshot.png

執行後,MaxCompute Project Explorer中找到目標表,並看到values中的數據已經插入,以下:

screenshot.png

對於在values中沒有制定的列,能夠看到取缺省值爲NULL。插入列表功能不必定和VALUES一塊兒用,對於INSERT INTO ... SELECT..., 一樣可使用。

INSERT... VALUES... 有一個限制,values必須是常量,可是有的時候但願在插入的數據中進行一些簡單的運算,這個時候可使用MaxCompute的VALUES TABLE功能,以下:

screenshot.png

其中的VALUES (...), (...) t (a, b), 至關於定義了一個名爲t,列爲a, b的表,類型爲(a string, b string),其中的類型從VALUES列表中推導。這樣在不許備任何物理表的時候,能夠模擬一個有任意數據的,多行的表,並進行任意運算。

實際上,VALUES表並不限於在INSERT語句中使用,任何DML語句均可以使用。

還有一種VALUES表的特殊形式

select abs(-1), length('abc'), getdate();

也就是能夠不寫from語句,直接執行SELECT,只要SELECT的表達式列表不用任何上游表數據就能夠。其底層實現爲從一個1行,0列的匿名VALUES表選取。這樣,在但願測試一些函數,好比本身的UDF等,就不再用手工建立DUAL表了。

SEMI JOIN

MaxCompute支持SEMI JOIN(半鏈接)。SEMI JOIN中,右表只用來過濾左表的數據而不出如今結果集中。支持的語法包括LEFT SEMI JOIN,LEFT ANTI JOIN,(NOT) IN SUBQUERY,(NOT) EXISTS

LEFT SEMI JOIN

返回左表中的數據,當join條件成立,也就是mytable1中某行的id在mytable2的全部id中出現過,此行就保留在結果集中

例如:
SELECT * from mytable1 a LEFT SEMI JOIN mytable2 b on a.id=b.id;
只會返回mytable1中的數據,只要mytable1的id在mytable2的id中出現過

LEFT ANTI JOIN

返回左表中的數據,當join條件不成立,也就是mytable1中某行的id在mytable2的全部id中沒有出現過,此行就保留在結果集中

例如:

SELECT * from mytable1 a LEFT ANTI JOIN mytable2 b on a.id=b.id;

只會返回mytable1中的數據,只要mytable1的id在mytable2的id沒有出現過

IN SUBQUERY/NOT IN SUBQUERY

IN SUBQUERY與LEFT SEMI JOIN相似。

例如:

SELECT * from mytable1 where id in (select id from mytable2);

等效於

SELECT * from mytable1 a LEFT SEMI JOIN mytable2 b on a.id=b.id;

原有ODPS也支持IN SUBQUERY,可是不支持correlated條件,MaxCompute支持
例如:

SELECT * from mytable1 where id in (select id from mytable2 where value = mytable1.value);

其中子查詢中的where value = mytable1.value就是一個correlated條件,原有ODPS對於這種既引用了子查詢中源表,由引用了外層查詢源表的表達式時,會報告錯誤。MaxCompute支持這種用法,這樣的過濾條件事實上構成了SEMI JOIN中的ON條件的一部分。

對於NOT IN SUBQUERY,相似於LEFT ANTI JOIN,可是有一點顯著不一樣
例如:

SELECT * from mytable1 where id not in (select id from mytable2);

若是mytable2中的全部id都不爲NULL,則等效於

SELECT * from mytable1 a LEFT ANTI JOIN mytable2 b on a.id=b.id;

可是,若是mytable2中有任何爲NULL的列,則 not in表達式會爲NULL,致使where條件不成立,無數據返回,此時與LEFT ANTI JOIN不一樣。

原有ODPS也支持[NOT] IN SUBQUERY不做爲JOIN條件,例如出如今非WHERE語句中,或者雖然在WHERE語句中,但沒法轉換爲JOIN條件。MaxCompute仍然支持這種用法,可是此時由於沒法轉換爲SEMI JOIN而必須實現啓動一個單獨的做業來運行SUBQUERY,因此不支持correlated條件。

例如:

SELECT * from mytable1 where id in (select id from mytable2) OR value > 0;

由於WHERE中包含了OR,致使沒法轉換爲SEMI JOIN,會單獨啓動做業執行子查詢

另外在處理分區表的時候,也會有特殊處理

SELECT * from sales_detail where ds in (select dt from sales_date);

其中的ds若是是分區列,則select dt from sales_date 會單獨啓動做業執行子查詢,而不會轉化爲SEMIJOIN,執行後的結果會逐個與ds比較,sales_detailds值不在返回結果中的分區不會讀取,保證分區裁剪仍然有效。

EXISTS SUBQUERY/NOT EXISTS SUBQUERY

當SUBQUERY中有至少一行數據時候,返回TRUE,不然FALSE。NOT EXISTS的時候則相反。目前只支持含有correlated WHERE條件的子查詢。EXISTS SUBQUERY/NOT EXISTS SUBQUERY實現的方式是轉換爲LEFT SEMI JOIN或者LEFT ANTI JOIN

例如:

SELECT * from mytable1 where exists (select * from mytable2 where id = mytable1.id);`

等效於

SELECT * from mytable1 a LEFT SEMI JOIN mytable2 b on a.id=b.id;

SELECT * from mytable1 where not exists (select * from mytable2 where id = mytable1.id);`

則等效於

SELECT * from mytable1 a LEFT ANTI JOIN mytable2 b on a.id=b.id;

其餘改進

  • MaxCompute支持UNION [DISTINCT] - 其中DISTINCT爲忽略
SELECT * FROM src1 UNION SELECT * FROM src2;

執行的效果至關於

SELECT DISTINCT * FROM (SELECT * FROM src1 UNION ALL SELECT * FROM src2) t;

支持IMPLICIT JOIN

SELECT * FROM table1, table2 WHERE table1.id = table2.id;

執行的效果至關於

SELECT * FROM table1 JOIN table2 ON table1.id = table2.id;

此功能主要是方便從其餘數據庫系統遷移,對於信貸買,咱們仍是推薦您使用JOIN,明確表示意圖

支持新的SELECT語序

在一個完整的查詢語句中,例如

SELECT key, max(value) FROM src t WHERE value > 0 GROUP BY key HAVING sum(value) > 100 ORDER BY key LIMIT 100;

實際上的邏輯執行順序是 FROM->WHERE->GROUY BY->HAVING->SELECT->ORDER BY->LIMIT,前一個是後一個的輸入,與標準的書寫語序實際並不相同。不少容易混淆的問題,都是由此引發的。例如order by中只能引用select列表中生成的列,而不是訪問FROM的源表中的列。HAVING能夠訪問的是 group by key和聚合函數。SELECT的時候,若是有GROUP BY,就只能訪問group key和聚合函數,而不是FROM中源表中的列。

MaxCompute支持以執行順序書寫查詢語句,例如上面的語句能夠寫爲

FROM src t WHERE value > 0 GROUP BY key HAVING sum(value) > 100 SELECT key, max(value) ORDER BY key LIMIT 100;

書寫順序和執行順序一致,就不容易混淆了。這樣有一個額外的好處,在MaxCompute Studio中寫SQL語句的時候,會有智能提示的功能,若是是SELECT在前,書寫select列表的表達式的時候,由於FROM尚未寫,MaxCompute Studio沒辦法知道可能訪問那些列,也就不能作提示。以下

screenshot.png

須要先寫好FROM,再回頭寫SELECT列表,才能提示。以下

screenshot.png

若是使用上述以FROM起始的方式書寫,則能夠天然而然的根據上下文進行提示。以下

screenshot.png

支持頂層UNION

ODPS1.0不支持頂層UNION。ODPS2.0能夠支持,例如

SELECT * FROM src UNION ALL SELECT * FROM src;

UNION後LIMIT的語義變化。

大部分DBMS系統中,如MySQL,Hive等,UNION後若是有CLUSTER BY, DISTRIBUTE BY, SORT BY, ORDER BY或者LIMIT子句,其做用於與前面全部UNION的結果,而不是UNION的最後一路。ODPS2.0在set odps.sql.type.system.odps2=true;的時候,也採用此行爲。例如:

set odps.sql.type.system.odps2=true;
SELECT explode(array(1, 3)) AS (a) UNION ALL SELECT explode(array(0, 2, 4)) AS (a) ORDER BY a LIMIT 3;

返回

a
0
1
2

小節

MaxCompute大大擴充了DML語句的支持,在易用性,兼容性和性能方面,能夠更好的知足您的需求。對於SQL比較熟悉的專家會發現,上述功能大部分是標準的SQL支持的功能。MaxCompute會持續提高與標準SQL和業界經常使用產品的兼容性。

除此以外,針對MaxCompute用戶的特色,也就是須要在很是複雜的業務場景下,支持對己大量數據的處理,MaxCompute提供了特有的腳本模式和參數化視圖,將在下一次爲您介紹。

標註

  • 注1 是否合併或者分裂子查詢,是由ODPS2.0的基於代價的優化器 (CBO)作出決定的,SQL自己的書寫方式,不論是CTE仍是子查詢,並不能確保物理執行計劃的合併或者分裂。
相關文章
相關標籤/搜索