商業智能(BI)工具，如Tableau和Microsoft Power BI，在從傳統數據倉庫提取大型查詢結果時速度很慢，因為它們通常通過SQL端點在單個線程中獲取數據，從而成為數據傳輸的瓶頸。數據分析師可以將他們的BI工具連接到Databricks SQL端點，通過集成在Simba驅動程序中的ODBC/JDBC協議查詢表中的數據。我們在Databricks Runtime 8.3和Simba ODBC 2.6.17驅動程序中發布了Cloud Fetch，我們引入了一種新的機製，通過雲存儲(如AWS S3和Azure data Lake storage)並行獲取數據，從而更快地將數據帶到BI工具中。在我們使用Cloud Fetch的實驗中，我們觀察到由於並行性，提取性能提高了10倍。
動機和挑戰
BI工具在大型組織中變得越來越流行，因為它們為運行分析應用程序的數據分析師提供了出色的數據可視化，同時隱藏了查詢執行的複雜性。BI工具通過標準ODBC/JDBC協議與SQL端點通信，以執行查詢並提取結果。在引入Cloud Fetch之前，Databricks采用了與Apache Spark™類似的方法。在這種設置中，端到端提取性能通常取決於單線程SQL端點將結果傳輸回BI工具所花費的時間。
在Cloud Fetch出現之前，圖1中描述的數據流相當簡單。BI工具連接到由集群支持的SQL端點，在集群中查詢在計算槽上並行執行。查詢結果都在SQL端點上收集，SQL端點在客戶機和集群之間的通信中充當協調節點。為了在不超出SQL端點資源限製的情況下提供大量數據，我們在SQL端點上啟用了磁盤溢出，以便將大於100 MB的結果存儲在本地磁盤上。當收集完所有結果並可能溢出磁盤時，SQL端點就可以將結果提供給請求它的BI客戶機。服務器不會立即返回整個數據，而是將其分成多個更小的塊。
我們確定了兩個主要的可伸縮性問題，這些問題使數據流效率低下，並且在提取數百MB時使SQL端點麵臨成為瓶頸的風險:
- 多租戶。有限的出口帶寬可以由訪問同一SQL端點的多個用戶共享。隨著並發用戶數量的增加，每個並發用戶提取數據的性能都會下降。
- 缺乏並行性。即使集群並行執行查詢，從執行器收集查詢結果並將其返回給BI工具也是在單線程中執行的。當客戶端以幾個MB的塊順序獲取結果時，結果的存儲和服務受到SQL端點上單個線程的瓶頸。
雲獲取架構
為了解決這些限製，我們重新設計了數據提取架構，使結果的寫入和讀取都是並行完成的。在高層次上，每個查詢被分成多個任務，這些任務在所有可用的計算資源上運行，每個任務將其結果寫入Azure數據湖存儲、AWS S3或穀歌雲存儲。SQL端點將文件列表作為預先簽名的url發送到客戶機，以便客戶機可以直接從雲存儲並行下載數據。
數據布局。查詢任務處理輸入數據集的各個分區並生成Arrow序列化結果。Apache箭頭最近已經成為列式內存數據分析的事實上的標準，並且已經被大量的開源項目所采用。每個查詢任務使用Arrow流格式以20mb的塊將數據寫入雲存儲。在每個文件中，可能有多個Arrow批，這些批由固定數量的行和字節組成。我們進一步對上傳的數據塊應用LZ4壓縮，以解決用戶在帶寬受限的情況下獲取數據的問題。
結果集合。現在，SQL端點不再收集mb或gb的查詢結果，而是存儲到雲存儲的鏈接，從而大大減少了內存占用和磁盤溢出開銷。我們的實驗表明，對於大於1mb的查詢結果，Cloud Fetch提供了超過2倍的吞吐量提升。但是，將小於1mb的結果上傳到雲存儲容易遭受不可忽略的延遲。因此，我們設計了一種混合獲取機製，它允許我們內聯結果並避免小查詢結果的延遲，或者上傳結果並提高大型查詢結果的吞吐量。在SQL端點上收集結果時，我們確定了三種可能的場景:
- 所有任務都返回Arrow批，它們的總大小小於1mb。這是一個非常短的查詢，對延遲敏感，通過雲存儲獲取不是理想的情況。我們通過上麵描述的單線程機製將這些結果直接返回給客戶機。
- 所有任務返回Arrow批，並且它們的總大小大於1mb，或者任務返回Arrow批和雲文件的混合。在本例中，我們使用與任務相同的數據布局從SQL端點將剩餘的Arrow批上傳到雲存儲，並存儲結果文件列表。
- 所有任務都返回指向雲文件的鏈接。在這種情況下，我們將雲鏈接存儲在內存中，並在獲取請求時將它們返回給客戶端。
獲取請求。當數據在SQL端點上可用時，BI工具可以通過順序請求小塊來開始獲取數據。在獲取請求時，SQL Endpoint獲取與當前偏移量對應的文件，並向客戶端返回一組預先簽名的url。這樣的url對於BI客戶機來說非常方便，因為它們與雲提供商無關，並且可以使用基本的HTTP客戶機下載。BI工具並行下載返回的文件，解壓縮其內容，並從Arrow批處理中提取單個行。
實驗結果。我們使用一個合成數據集進行數據提取實驗，該數據集包含20列和400萬行，總量為3.42 GB。啟用Cloud Fetch後，我們觀察到與單線程基線相比，提取吞吐量提高了12倍。
開始
想要加快數據提取的速度?通過下載和安裝最新版本開始使用Cloud FetchODBC驅動程序。在Azure Databricks和Amazon上部署Databricks Runtime 8.3或更高版本的Databricks SQL和交互式Databricks集群中可以使用該功能。我們在最新版本的Simba ODBC驅動程序2.6.17和即將發布的Simba JDBC驅動程序2.6.18中合並了Cloud Fetch機製。
