在 Spark AI Summit 的第一天會議中，數磚重磅發佈了 Delta Engine。這個引擎 100% 兼容 Apache Spark 的向量化查詢引擎，並且利用了現代化的 CPU 架構，優化了 Spark 3.0 的查詢優化器和緩存功能。這些特性顯著提高了 Delta Lake 的查詢性能。當然，這個引擎目前只能在 Databricks Runtime 7.0 中使用。
數磚研發 Delta Engine 的目的
過去十年，存儲的速度從 50MB/s（HDD）提升到 16GB/s（NvMe）；網絡的速度從 1Gbps 提升到 100Gbps；但是 CPU 的主頻從 2010 年的 3GHz 到現在基本不變。
NVM Express（NVMe），或稱非易失性內存主機控制器接口規範（英語：Non-Volatile Memory Host Controller Interface Specification，縮寫：NVMHCIS），是一個邏輯設備接口規範。它是與 AHCI 類似的、基於裝置邏輯接口的匯流排傳輸協定規範（相當於通訊協議中的應用層），用於訪問通過 PCI Express（PCIe）總線附加的非揮發性記憶體介質（例如採用快閃記憶體的固態硬碟機），雖然理論上不一定要求 PCIe 匯流排協定。歷史上，大多數 SSD 使用如 SATA、SAS 或光纖通道等接口與計算機接口的總線連接。隨着固態硬盤在大衆市場上的流行，SATA 已成爲個人電腦中連接 SSD 的最典型方式；但是，SATA 的設計主要是作爲機械硬盤驅動器（HDD）的接口，並隨着時間的推移越來越難滿足速度日益提高的 SSD。隨着在大衆市場的流行，許多固態硬盤的數據速率提升已經放緩。不同於機械硬盤，部分 SSD 已受到 SATA 最大吞吐量的限制。
在 NVMe 出現之前，高端 SSD 只得以採用 PCI Express 總線製造，但需使用非標準規範的接口。若使用標準化的 SSD 接口，操作系統只需要一個驅動程序就能使用符合規範的所有 SSD。這也意味着每個 SSD 製造商不必用額外的資源來設計特定接口的驅動程序。
摘抄自 https://zh.wikipedia.org/zh-hans/NVM_Express
從上圖可以看出，CPU 主頻是目前數據分析的重要瓶頸。
另外，隨着業務速度的加快，數據團隊用於正確建模數據的時間越來越少。爲了更好的業務敏捷性而進行的較差的建模會導致較差的查詢性能。比如
•大多數列沒有定義 "NOT NULL"；•String 時候起來很方便，所以很多人使用 String 來存儲日期；•數據越來越不規範，而且數據還在不斷的持續生成。
Delta Engine：高性能的查詢引擎
爲了解決上面的一些問題，數磚專門開發了 Delta Engine，這個引擎專門用於數據分析的加速以及靈活適應多種工作負載。從下圖可以看出 Delta Engine 主要包括三個組件：改進的查詢優化器、位於執行層和雲對象存儲之間的緩存層，以及用 C++ 編寫的原生向量化執行引擎（Photon），這個引擎可以加速使用 SQL 和 DataFrame 分析 Delta Lake 的工作負載。
Delta Engine 的查詢優化器擴展了 Spark 3.0 中已有的功能，包括基於成本的優化器（CBO）、自適應查詢執行（adaptive query execution）和動態運行時過濾器（dynamic runtime filters），提供了更高級的統計信息，在星型模式工作負載中提供了高達18倍的性能提升。
Delta Engine 的緩存層自動選擇要爲用戶緩存的輸入數據，並以一種 CPU 高效的格式對其進行代碼轉換，以更好地利用 NVMe SSDs 提高的存儲速度。這幾乎爲所有工作負載提供了高達5倍的掃描性能。值得注意的是，在計算引擎中引入緩存在很多產品都可以看到，比如 Snowflake 的數倉產品（參見論文《The Snowflake Elastic Data Warehouse》），在國內，比如阿里雲的很多雲產品也在往這方面發展，如阿里雲的數據湖分析（DLA）。
Delta Engine 在解決數據團隊面臨的挑戰方面最大的創新是原生執行引擎，這個引擎稱爲 Photon。這個引擎是完全重寫的，目的是充分利用現代雲硬件來最大化計算性能。這個引擎爲所有類型的工作負載帶來了性能改進，重要的是，這個引擎和開源的 Spark API 是完全兼容的。
Photon：原生向量化執行引擎
Delta Engine 中最重要的 Photon 是完全使用 C++ 實現的，其通過利用數據級並行和指令級並行大大提升計算能力，大大提升了 Delta Engine 上的 Spark SQL 查詢，並且對結構化和非結構化的工作負載都有不同程度的優化。
儘管這麼多年 CPU 的主頻並沒有什麼變化，但是並行度卻有不同程度的提升，主要包括 data-level 層面上的並行度和指令層面上的並行度。
比如我們的查詢爲 select sum(value) from table group by key，這個查詢底層的實現變成下面的代碼：
for(int32_t i = 0; i < batchSize; ++i) {
int32_t bucket = hash(keyCol[i]) % ht->size;
if(ht[bucket].key == keyCol[i]) {
ht[bucket].value += valueCol[i];
}
}
上面的代碼訪問內存（ht[bucket]）的指令與計算哈希碼（int32_t bucket = hash(keyCol[i]) % ht->size;）、比較鍵（key == keyCol[i]）和加法（ht[bucket].value += valueCol[i];）的指令混合在一起。而且上面的循環體非常大，導致 CPU 很少看到內存訪問指令。解決上面的問題是將上面大的循環體修改成更小的循環體，如下：
for(int32_t i = 0; i < batchSize; ++i) {
buckets[i] = hash(keyCol[i]) % ht->size;
}
for(int32_t i = 0; i < batchSize; ++i) {
keys[i] = ht[bucket].key;
}
for(int32_t i = 0; i < batchSize; ++i) {
if(keys[i] == keyCol[i]) {
ht[buckets[i]].value += valueCol[i];
}
}
經過上面指令層面的修改，帶有 Photon 的 Delta Engine 比傳統的引擎提升很多性能，
在 TPC-DS 30TB 數據量的測試下的表現提升了 3.3 倍。
String 優化
另外，在 String 的處理 Photon 也做了大量的優化。比如在使用 C++ 實現執行引擎之後，String 的 UPPER 和 SUBSTRING 函數操作性能相對 JVM 的實現有了大幅提升，如下：
雖然 C++ 實現之後 string 的性能相對 JVM 的性能有所提升，但是數磚團隊對這個進一步優化，結合 UTF-8 可變長度的編碼和 ASCII 定長的編碼，使得 Photon 引擎對字符串的操作進一步提升：
引用鏈接
1.https://databricks.com/blog/2020/06/24/introducing-delta-engine.html
2.https://zh.wikipedia.org/zh-hans/NVM_Express
3.https://www.iteblog.com/archives/9833.html
猜你喜歡
1、Apache Spark 3.0.0 正式版終於發佈了，重要特性全面解析
4、Spark 3.0 自適應查詢優化介紹，在運行時加速 Spark SQL 的執行性能
過往記憶大數據微信羣，請添加微信：fangzhen0219,備註【進羣】