今天，在Spark+AI峯會首日主題演講中，Databricks帶來了一系列重磅發佈：推出用於實現高性能查詢的Delta Engine原生執行引擎；收購數據可視化開源項目Redash背後的公司；發佈Koalas 1.0等。這些動作無一不標誌着Databricks正在朝着統一數據分析平臺的目標大步邁進。爲了幫助讀者快速獲取重要信息，InfoQ將今日主題演講中的亮點彙總整理如下：
終極願景：Data Lakehouse
數據倉庫在決策支持和商業智能應用方面擁有悠久的歷史。但數據倉庫並不適用於處理現代企業中常見的非結構化、半結構化和流式數據。因此很多企業在約十年前就開始構建存儲原始數據的數據湖。數據湖雖然適用於存儲數據，但缺少一些關鍵功能：不支持事務，不強調數據質量，並且缺乏一致性/隔離性，導致其幾乎不可能混合處理追加和讀取、以及批處理和流式作業。由於這些原因，數據湖的許多承諾尚未實現，並且在很多情況下失去了數據倉庫的許多好處。Databricks過去幾年在許多客戶案例和使用場景中看到了一種新的數據管理範式：lakehouse。
Lakehouse是一種新的數據管理範式，它結合了數據湖和數據倉庫的最佳元素：直接在用於數據湖的低成本存儲上實現與數據倉庫類似的數據結構和數據管理功能。
Data Lakehouse需要具備以下關鍵特徵：
- 支持事務：在企業內部lakehouse，通常會有許多數據管道同時讀取和寫入數據，支持ACID事務可以確保一致性。
- 模式執行和治理（schema enforcement and governance）：Lakehouse應該支持模式執行和演進，支持DW schema範式（例如star/snowflake-schemas），能夠推理數據完整性，並且應該具有健壯的治理和審計機制。
- 支持BI：Lakehouses可以直接在源數據上使用BI工具。這樣可以減少數據過時（staleness）並提高新近性（recency），減少延遲，並降低必須在數據湖和數據倉庫中操作兩個數據副本的成本。
- 存儲計算分離：實際上，這意味着存儲和計算使用單獨的集羣，因此係統能夠擴展到更多併發用戶和更大的數據量。有一些現代數據倉庫也具備這一屬性。
- 開放性：使用開放和標準化的存儲格式，如Parquet，並提供API，這樣各種工具和引擎（包括機器學習庫和Python/R庫）都可以直接高效地訪問數據。
- 支持從非結構化數據到結構化數據的多種數據類型：Lakehouse可用於存儲、優化、分析和訪問許多新數據應用所需的不同數據類型，包括圖像、視頻、音頻、半結構化數據和文本。
- 支持各類工作負載：包括數據科學、機器學習以及SQL和分析。要支持所有這些工作負載可能需要多種工具，但它們都基於同一個數據存儲庫。
- 端到端流：實時報告是許多企業的標準需求。支持端到端流，企業就不需要單獨再開發一個專門用於服務實時數據應用的系統。
以上是lakehouse的關鍵屬性，當然，企業級系統還需要更多功能，比如安全和訪問控制工具、數據發現工具等。
目前業界已有一些Data Lakehouse數據管理範式的早期案例：Databricks平臺具備lakehouse的架構特性；微軟的Azure Synapse Analytics服務與Azure Databricks集成在一起，也可以實現類似lakehouse的模式；其他託管服務（例如BigQuery和Redshift Spectrum）也具備上面列出的部分lakehouse功能，但它們主要針對BI和其他SQL應用；還有一些公司正在通過開源表格式（如Delta Lake、Apache Iceberg、Apache Hudi）構建自己的lakehouse。
今天在Spark+AI峯會上發佈原生執行引擎Delta Engine和收購數據可視化開源項目Redash背後的公司，都可以視作Databricks爲實現Data Lakehouse數據管理範式採取的行動。
Delta Engine：實現高性能查詢的原生執行引擎
Delta Engine是爲了實現高性能查詢而打造的原生執行引擎，該引擎由三個部分組成，包括：100％與Apache Spark兼容的矢量化查詢引擎，以充分發揮現代CPU架構的性能；基於Spark 3.0查詢優化器的進一步優化；以及作爲Databricks Runtime 7.0的一部分推出的緩存功能。這些功能特性結合在一起將顯著提高數據湖（尤其是由Delta Lake支持的數據湖）上的查詢性能，從而使用戶可以更輕鬆地採用和擴展lakehouse架構。
過去幾年的主要硬件趨勢之一是CPU時鐘速度已趨於平穩。我們必須找到新的方法來以超出原始計算能力的速度更快地處理數據。最有效的方法之一是提高可以並行處理的數據量。但是，數據處理引擎需要經過專門設計纔能有效利用這種並行性。
此外，隨着業務發展日益加快，數據團隊可以用於數據建模的時間越來越少。如果爲了更好的業務敏捷性而犧牲建模質量，就會導致查詢性能變差。Databricks希望能找到同時讓敏捷性和性能最大化的方法，Delta Engine由此而生。
Delta Engine通過三個組件來提高Delta Lake的SQL和數據幀工作負載的性能：改進的查詢優化器，位於執行層和雲對象存儲之間的緩存層，以及使用C ++編寫的原生矢量執行引擎（Native Execution Engine）。
改進的查詢優化器對Spark 3.0中已有的功能（基於成本的優化器，自適應查詢執行和動態運行時過濾器）做了更多擴展，能夠將星型架構的工作負載性能提高最多18倍。
Delta Engine的緩存層會爲用戶自動選擇要緩存的輸入數據，並以更高效的CPU格式對代碼進行轉碼，以更好地利用不斷提高的NVMe SSD存儲速度。基於這一點，幾乎所有工作負載的掃描性能都能得到提升，最高可加快5倍。
不過，Delta Engine解決當今數據團隊所面臨挑戰的最大創新是中間的原生執行引擎，Databricks內部稱之爲Photon。這個執行引擎針對Databricks進行了徹底的重寫，旨在充分利用現代雲計算硬件的新變化使性能最大化。它能夠改進所有工作負載類型的性能，同時仍與開放的Spark API完全兼容。
Databricks表示接下來會另寫一篇文章對Photon的工作原理和具體性能表現做具體介紹，InfoQ屆時會第一時間帶來中文版本，敬請期待。
收購Redash：增強數據可視化功能
在今天早上的Spark+AI峯會上，Databricks宣佈收購Redash，後者是流行的同名開源項目背後的公司。通過此次收購，Redash將與Apache Spark、Delta Lake和MLflow共同構成一個更大、更繁榮的開源系統，爲數據團隊提供一流的工具。目前Redash僅在私有預覽版本中可用，未來Redash將完全集成到Databricks平臺中，以打造更豐富的可視化和儀表板體驗。
Redash是一個協作式的可視化和儀表板平臺，目標是使所有人（無論他們的技術水平如何）都可以在團隊內部和團隊之間共享見解。SQL用戶利用Redash來探索、查詢、可視化和共享來自任何數據源的數據。而他們的工作反過來又使他們所在公司中的所有人都可以使用數據。目前，全球成千上萬個組織中的數百萬用戶都在使用Redash開發見解並制定數據驅動的決策。
Redash包括以下功能：
- 查詢編輯器：通過schema瀏覽器和自動完成功能快速整合SQL和NoSQL查詢。
- 可視化和儀表板：可以通過簡單的拖拽創建漂亮的可視化效果，並將它們組合成一個儀表板。
- 共享：通過共享可視化及相關查詢，可以輕鬆地進行協作，進而對報告和查詢進行同行審查。
- 定期刷新：可以根據用戶配置的間隔時間定期自動更新圖表和儀表盤。
- 告警：支持自定義條件並在數據更改時立即收到告警通知。
- REST API：所有可以使用UI進行的操作都可以通過REST API使用。
- 廣泛支持各類數據源：數據源API可擴展，原生支持衆多常見的SQL、NoSQL數據庫和平臺。
Databricks表示，集成後的Redash服務將幫助SQL分析師、數據科學家和數據工程師更輕鬆地查詢和可視化Delta Lakes和其他數據源中的數據。Redash將與現有的Databricks平臺無縫集成：Databricks運營的所有數據中心都會提供該服務；統一的身份管理和數據治理，無需額外配置；SQL端點將在Redash中自動填充；兩款產品共享目錄和元數據。
Databricks強調，Redash的加入旨在幫助公司更好地實現爲所有數據團隊創建一個開放統一的數據分析平臺的願景。Databricks希望通過這樣一個平臺爲每個團隊提供各自工作所需的工具和一個可以協作的共享平臺，讓所有數據團隊共同實現成功。通過將數據湖和數據倉庫的最佳功能結合在一個統一的架構中，每個團隊可以在同一個完整且權威的數據源上共同工作，這將幫助Databricks實現lakehouse數據管理範式的終極目標。
Koalas 1.0發佈
經過一年多的開發，Koalas 1.0版本正式發佈，新版本實現了將近80%的pandas API，同時支持Apache Spark 3.0、Python 3.8、Spark訪問器、新的類型提示和更好的就地（in-place）操作。目前Koalas 在 PyPI 上的月下載量已迅速增長到 85 萬，並以每兩週發佈一次的節奏快速演進。
以下是1.0版本重要新特性的概覽，詳細介紹可以點此查看。
更好的pandas API覆蓋率
Koalas實現了幾乎所有被廣泛使用的pandas API和功能，如plotting、grouping、windowing、I/O和轉換。
另外，諸如transform_batch和apply_batch之類的Koalas API可以最大化利用pandas API，因此在Koalas 1.0.0中只需要做非常少的更改就可以做到使幾乎所有pandas工作負載轉換爲Koalas工作負載。
支持Apache Spark 3.0、Python 3.8和pandas 1.0
Koalas 1.0.0支持Apache Spark 3.0，Koalas用戶可以幾乎零更改地切換其Spark版本。 Apache Spark 3.0版本包含了3400多個修復補丁，而Koalas許多組件共享了這些修復，詳情參閱Apache Spark 3.0重要特性解讀。
基於Apache Spark 3.0，Koalas支持最新的Python 3.8版本。Koalas開放了許多類似於pandas的API，以便在DataFrame上執行原生Python代碼，這將從Python 3.8支持中受益。另外，Koalas充分利用了Python中大量開發的Python類型提示。Koalas中的某些類型提示功能可能只在較新的Python版本才允許使用。
Koalas 1.0.0的目標之一是跟進最新的pandas版本，並涵蓋pandas 1.0中的大多數API。除了與API更改和棄用保持同步之外，Koalas還對API的覆蓋範圍進行了衡量和改進。另外，Koalas也支持將最新的pandas版本作爲Koalas的依賴項，因此使用最新pandas版本的用戶可以輕鬆嘗試Koalas。
Spark訪問器（accessor）
Koalas 1.0.0引入了Spark訪問器，以使Koalas用戶可以更輕鬆地利用現有的PySpark API。
import databricks.koalas as ks
import pyspark.sql.functions as F
kss = ks.Series([1, 2, 3, 4])
kss.spark.apply(lambda s: F.collect_list(s))
更快的性能
許多Koalas API依賴於pandas UDF。Apache Spark 3.0引入了新的pandas UDF，Koalas內部通過它們來提高性能，例如DataFrame.apply(func)和DataFrame.apply_batch(func)。
在基於Spark 3.0.0的Koalas 1.0.0中，基準測試的性能提高了20％到25％。
更好的類型提示支持
大多數執行Python原生功能的Koalas API實際上都採用並輸出pandas實例。 過去，需要使用Koalas實例來返回類型提示，這些提示看起來有些尷尬。
def pandas_div(pdf) -> ks.DataFrame[float, float]:
# pdf is actually a pandas DataFrame.
return pdf[['B', 'C']] / pdf[['B', 'C']]
df = ks.DataFrame({'A': ['a', 'a', 'b'], 'B': [1, 2, 3], 'C': [4, 6, 5]})
df.groupby('A').apply(pandas_div)
在Koalas 1.0.0（基於Python 3.7或更新版本），開發者也可以在返回類型中使用pandas實例：
def pandas_div(pdf) -> pd.DataFrame[float, float]:
return pdf[['B', 'C']] / pdf[['B', 'C']]
另外，Koalas 1.0.0實驗性地引入了新的類型提示，以允許用戶在類型提示中指定列名稱：
def pandas_div(pdf) -> pd.DataFrame['B': float, 'C': float]:
return pdf[['B', 'C']] / pdf[['B', 'C']]
支持更多繪圖功能
在Koalas 1.0.0中，Koalas的繪圖功能API覆蓋率已達到90％。現在開發者可以像在pandas中一樣輕鬆地在Koalas中實現可視化效果。
更廣泛的就地（in-place）更新支持
在Koalas 1.0.0中，Series中的就地更新可以很自然地應用到DataFrame中，就像DataFrame是完全可變的一樣。
更好地支持缺失值、NaN和NA
在處理PySpark和pands的缺失數據時，存在一些細微的差異。 例如，缺失數據在PySpark中通常表示爲“None”，而在pandas中則表示爲“ NaN”。 此外，pandas還引入了新的實驗性NA值，目前在Koalas中支持的不是很好。
其中大部分問題已經得到解決，目前Koalas正在大力開發以更全面地解決上述問題。舉個例子，Series.fillna在Koalas 1.0.0中已經可以正確處理NaN。