前情回顧

在“資料湖”概念與理論逐漸深入人心的今天，面向雲端儲存的互動式查詢這個需求場景顯得愈發重要。這是因為原生的雲端儲存（主要指S3這樣的物件儲存）既能夠容納大容量的明細資料，又能在效能和成本間取得一個很好的平衡——如果它同時再支援複雜的即席分析查詢，那麼雲原生儲存就將成為資料湖的最佳載體，對於實現資料分析人員的自由探索和應用系統的查詢整合都有著非常重要的意義。

因此，在上一篇文章中，我們圍繞著這個重要需求場景如何在Azure進行實現詳細地展開了我們的探索。首先作為參照，我們在AWS環境中利用S3和Athena成功地對一個csv檔案進行了SQL查詢。隨後，我們主要使用Azure Data Lake Analytics (ADLA)配合Azure Data Lake Storage (ADLS)作儲存來實現了同樣的分析需求。值得注意的是，ADLA支援的查詢語言是U-SQL，一種混合了C#與SQL語法的獨特語言。

然而，也如前文所提到，ADLA還是存在一些固有侷限，也並未在Azure中國區上線。故而我們有必要考慮和尋找Azure體系內的其他選擇。今天的參賽選手，是源自SQL Server體系的PolyBase。

初識PolyBase

其實PolyBase這個稱謂最早出現於SQL Server 2012 Parallel Data Warehouse(PDW)中，該版本本質上是一個軟硬一體化的分散式MPP資料庫。PolyBase元件賦予了在資料庫層面定義指向Hadoop/HDFS資料的外部表的能力，是幫助打通MPP資料庫與Hadoop大資料生態系統的重要橋樑。

而PolyBase真正變得成熟並且廣為人知，是自SQL Server 2016起，PolyBase技術正式地出現在了標準SQL Server中，畢竟PDW版本的受眾不夠廣泛。此舉大大提升了SQL Server在大資料時代的綜合競爭力，使得微軟體系內的使用者通過T-SQL即可輕鬆地訪問和獲取Hadoop叢集中的資料。

那麼，說了一大圈，源自SQL Server的PolyBase和Azure有什麼關係，和我們今天的話題有什麼關係呢？這就得說到在微軟全面雲化的戰略之下，SQL Server其實也以多種不同形式遷移到了Azure雲端，形成了若干款不同的雲端資料服務產品（詳情參見筆者介紹SQL Server 2017的文章）。而PolyBase自然也一起被帶到了雲端，並在支援訪問HDFS的基礎上還添加了訪問雲端儲存的能力，這樣我們就可以通過PolyBase和大家熟悉的T-SQL語言來輕鬆實現面向雲端儲存的互動式查詢了。

(圖片來源：微軟PolyBase官方文件)

動手體驗

讓我們進入實踐環節。首先我們需要尋找一個Azure上PolyBase技術的載體。SQL Server的Azure變體中有SQL Database、SQL Managed Instance、SQL Data Warehouse等相關產品，但支援通過PolyBase訪問雲端儲存的目前僅有SQL Data Warehouse（下簡稱SQL DW）這一款。我們就選擇它作為查詢引擎。

首先我們準備一下實驗所需的資料，我們同樣沿用上篇文章中的包含信用卡借貸資料的csv檔案，把它放置到儲存賬戶的Blob中。我們確認一下它的位置是在cloudpickersa這個儲存賬戶的sampledata容器中：

接下來讓我們請出今天的主角，建立一個SQL DW資料庫（本實驗使用美國西區資源，但相關服務均已在Azure中國上線），使用最新的Gen2版本：

建立完成之後，就可以使用大家所熟悉的SQL Server Management Studio(SSMS)進行連線了，除了個別圖示不同，其使用體驗與傳統SQL Server幾乎完全一致。

與Athena類似，PolyBase同樣是通過定義外部表的方式來對雲端儲存中的資料和格式進行對映的。我們來看一下具體的步驟。

第一步，需要在剛才新建的資料庫裡建立一個credential用以實現與指定儲存賬號訪問許可權的對應：

CREATE MASTER KEY ENCRYPTION BY PASSWORD='MyPassw0rd';
CREATE DATABASE SCOPED CREDENTIAL CloudpickerCredential
WITH
     IDENTITY   = 'cloudpickersa'
,    SECRET     = 'j2PJqjIR1IfkDEESjWEIFzcgip...accesskeyismysupersecret...5VeqM2B+1bCWFosyvm4Kg=='
; --此處secret為儲存賬戶設定中生成的access key

第二步，需要建立一個“資料來源”用以指向儲存賬號下的具體容器，並指定資料來源的型別。這裡會用到第一步建立的credential：

CREATE EXTERNAL DATA SOURCE CloudpickerStorage_SampleData
WITH
(    LOCATION   = 'wasbs://[email protected]/'
,    CREDENTIAL = CloudpickerCredential
,    TYPE       = HADOOP
);

這裡的引數"TYPE=HADOOP"其實耐人尋味，因為我們實際要連線的是Azure Blob Storage，而非HDFS。這隱含地說明PolyBase事實上是先支援Hadoop，後來才把Azure儲存以一種HDFS相容的方式加入了支援。LOCATION中使用的wasb協議也印證了這一點，因為wasb本來就用於讓Azure Blob儲存掛載和融入到Hadoop體系中。

第三步，則是先定義資料格式，然後終於可以建立外部表並指向具體的csv檔案。這裡會用到第二步建立的資料來源：

CREATE EXTERNAL FILE FORMAT MyFileFormat_CSV
WITH (FORMAT_TYPE = DELIMITEDTEXT,
      FORMAT_OPTIONS(
          FIELD_TERMINATOR = ',',
          FIRST_ROW = 2, 
          USE_TYPE_DEFAULT = False)
);

CREATE EXTERNAL TABLE credit_card_loans(
  "year" INT, 
  periodicity VARCHAR(20), 
  "quarter" VARCHAR(20), 
  load_type VARCHAR(MAX), 
  loan_value DECIMAL(20,8)
)
WITH (  
        LOCATION='/credit_card_loans.csv',  
        DATA_SOURCE = CloudpickerStorage_SampleData,  
        FILE_FORMAT = MyFileFormat_CSV  
    )  
;

這才算是大功告成。可以看到，在PolyBase中需要層層遞進地建立憑據、資料來源、外部表這些重要實體，這是與嚴謹的SQL Server/T-SQL抽象體系相對應的。

我們迫不及待地來嘗試一下外部表訪問csv的效果。先做一個簡單的計數：

嗯，頗為順暢。再來一個與前篇文章相同的查詢，這次使用T-SQL來表達：

也很快地返回了正確的結果。關於PolyBase的查詢效能，由於牽涉到的因素會比較多，需要專題探討，在此不作重點討論。就這裡的例子而言，第一次的冷查詢會相對較慢，之後對同一外部表的各種查詢就比較快了，可以秒級返回。

至此，我們已完整地使用Azure SQL DW中的PolyBase能力實現了對Blob Storage的即席查詢，實現了與前文例子中相同的效果。

小結

來自關係型資料庫世界的PolyBase，賦能使用者使用T-SQL直接訪問查詢Azure雲端儲存中的資料檔案，可謂神奇。這也許乍一聽上去是“曲線救國”，但真正實操下來其實相當方便，圓滿完成了面向雲端儲存的互動式查詢的既定任務。

在PolyBase的幫助下，開發者和資料分析師們可以通過熟悉的SSMS或Azure Data Studio等客戶端工具隨時連線和查詢雲上大資料了。如果再考慮到SQL Server體系中ADO.NET/JDBC/ODBC等方便而成熟的訪問介面，PolyBase還不失為一個生產應用整合雲上大資料的優美方式，既可用於資料搬運，也可直查資料湖。PolyBase對於呼叫方而言也較為友好，因為訪問外部表和普通的內部資料表並無二致，間接實現了異構資料來源的統一封裝和訪問。

在本系列文章中，ADLA和PolyBase都已分別登場，各自展現了不遜於Athena的特點和能力。但在Azure上還有第三個選項，同樣具備很強的競爭力，我們留待下回分解。

“雲間拾遺”專注於從使用者視角介紹雲端計算產品與技術，堅持以實操體驗為核心輸出內容，同時結合產品邏輯對應用場景進行深度解讀。歡迎掃描下方二維碼關注“雲間拾遺”微信公眾號，或訂閱本部落格。

&n