查詢資料

查詢數據是執行 Azure Databricks 中幾乎所有數據驅動工作的基礎步驟。 無論使用何種語言或工具，工作負載一開始都會從針對數據表或其他數據源定義查詢開始，然後執行動作以從數據取得見解。 本文概述跨各種 Azure Databricks 產品供應專案執行查詢的核心概念和程式，並包含您可以適應使用案例的程式代碼範例。

您可以使用下列方式以互動方式查詢資料：

• Notebooks
• SQL 編輯器
• 檔案編輯器
• 儀表板​​

您也可以在 Delta Live Tables 管線或工作流程中執行查詢。

如需 Azure Databricks 上串流查詢的概觀，請參閱 查詢串流數據。

您可以使用 Azure Databricks 查詢哪些數據？

Azure Databricks 支援以多種格式和企業系統查詢數據。 您使用 Azure Databricks 查詢的數據分為兩個廣泛的類別之一：Databricks Lakehouse 和外部數據中的數據。

Databricks Lakehouse 中有哪些數據？

Databricks Data Intelligence Platform 預設會將所有數據儲存在 Databricks Lakehouse 中。

這表示當您執行基本 CREATE TABLE 語句來建立新的數據表時，您已建立 Lakehouse 數據表。 Lakehouse 數據具有下列屬性：

• 儲存在 Delta Lake 格式中。
• 儲存在雲端物件記憶體中。
• 受 Unity 目錄控管。

Azure Databricks 上的大部分 Lakehouse 數據都會在 Unity 目錄中註冊為受控數據表。 受控數據表提供最簡單的語法，而且行為就像大部分關係資料庫管理系統中的其他數據表一樣。 在大部分的使用案例中，建議使用Managed數據表，且適合不想擔心數據記憶體實作詳細數據的使用者。

Unmanaged 數據表或外部數據表是向LOCATION指定註冊的數據表。 外部詞彙可能會產生誤導，因為外部 Delta 數據表仍然是 Lakehouse 數據。 直接從其他 Delta 讀取器用戶端存取數據表的使用者可能會偏好使用 Unmanaged 數據表。 如需數據表語意差異的概觀，請參閱 什麼是數據表？。

某些舊版工作負載可能會透過檔案路徑與 Delta Lake 數據獨佔互動，而不會註冊數據表。 此數據仍然是 Lakehouse 數據，但可能更難探索，因為它未註冊至 Unity 目錄。

注意

您的工作區系統管理員可能尚未升級數據控管以使用 Unity 目錄。 您仍然可以在沒有 Unity 目錄的情況下取得 Databricks Lakehouse 的許多優點，但不支援本文或整個 Azure Databricks 檔中所列的所有功能。

哪些數據被視為外部數據？

任何不在 Databricks Lakehouse 中的數據都可以視為外部數據。 外部資料的一些範例包括下列專案：

• 向 Lakehouse 同盟註冊的外國數據表。
• Parquet 所支援 Hive 中繼存放區中的數據表。
• 由 JSON 支援的 Unity 目錄中的外部資料表。
• 儲存在雲端物件記憶體中的 CSV 資料。
• 從 Kafka 讀取的串流數據。

Azure Databricks 支援設定與許多數據源的連線。 請參閱數據源 連線。

雖然您可以使用 Unity 目錄來控管對儲存於多種格式和外部系統之數據的存取和定義數據表，但 Delta Lake 是數據在 Lakehouse 中考慮的需求。

Delta Lake 提供 Azure Databricks 中的所有交易保證，這對維護數據完整性和一致性至關重要。 如果您想要深入瞭解 Azure Databricks 數據的交易式保證，以及為何重要，請參閱 什麼是 Azure Databricks 上的 ACID 保證？。

大部分的 Azure Databricks 用戶會查詢 Lakehouse 數據和外部數據的組合。 使用外部數據 連線 一律是將數據帶入 Lakehouse 的數據擷取和 ETL 管線的第一個步驟。 如需擷取數據的相關信息，請參閱 將數據內嵌至 Databricks Lakehouse。

依名稱查詢數據表

針對註冊為數據表的所有數據，Databricks 建議使用數據表名稱進行查詢。

如果您使用 Unity 目錄，資料表會使用具有下列格式的三層命名空間： <catalog-name>.<schema-name>.<table-name>。

如果沒有 Unity 目錄，數據表標識子會使用 格式 <schema-name>.<table-name>。

注意

Azure Databricks 會從 Apache Spark 繼承其大部分的 SQL 語法，而不會區分 SCHEMA 和 DATABASE。

所有 Azure Databricks 執行內容和支援的語言都支援依數據表名稱查詢。

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

依路徑查詢數據

您可以使用檔案路徑查詢結構化、半結構化和非結構化數據。 Azure Databricks 上的大部分檔案都受到雲端物件記憶體的支援。 請參閱 使用 Azure Databricks 上的檔案。

Databricks 建議使用 Unity 目錄設定雲端物件記憶體的所有存取權，併為直接查詢的物件儲存位置定義磁碟區。 磁碟區會使用檔案路徑的目錄和架構名稱，為雲端物件記憶體中的位置和檔案提供人類可讀取的別名。 請參閱使用 Unity 目錄將 連線 至雲端物件記憶體。

下列範例示範如何使用 Unity 目錄磁碟區路徑來讀取 JSON 數據：

SQL

SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`

Python

spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")

針對未設定為 Unity 目錄磁碟區的雲端位置，您可以使用 URI 直接查詢數據。 您必須設定雲端物件記憶體的存取權，以使用 URI 查詢數據。 請參閱 設定 Azure Databricks 雲端物件記憶體的存取。

下列範例示範如何使用 URI 來查詢 Azure Data Lake 儲存體 Gen2、GCS 和 S3 中的 JSON 數據：

SQL

SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;

SELECT * FROM json.`gs://bucket_name/path/to/data`;

SELECT * FROM json.`s3://bucket_name/path/to/data`;

Python

spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")

spark.read.format("json").load("gs://bucket_name/path/to/data")

spark.read.format("json").load("s3://bucket_name/path/to/data")

使用 SQL 倉儲查詢數據

Azure Databricks 會使用 SQL 倉儲在下列介面中進行計算：

• SQL 編輯器
• Databricks SQL 查詢
• 儀表板​​
• 舊版儀錶板
• SQL 警示

您可以選擇性地搭配下列產品使用 SQL 倉儲：

• Databricks 筆記本
• Databricks 檔案編輯器
• Databricks 工作流程

當您使用 SQL 倉儲查詢數據時，只能使用 SQL 語法。 不支援其他程式設計語言和 API。

針對已啟用 Unity 目錄的工作區，SQL 倉儲一律會使用 Unity 目錄來管理數據源的存取權。

大部分在 SQL 倉儲上執行的查詢都會以數據表為目標。 以數據檔為目標的查詢應利用 Unity 目錄磁碟區來管理記憶體位置的存取權。

直接在 SQL 倉儲上執行的查詢中使用 URI 可能會導致非預期的錯誤。

使用所有用途計算或作業計算查詢數據

您從 Databricks 筆記本、工作流程和檔案編輯器執行的大部分查詢，都會針對使用 Databricks Runtime 設定的計算叢集執行。 您可以將這些叢集設定為以互動方式執行，或將其部署為 可提供工作流程的作業計算 。 Databricks 建議您一律針對非互動式工作負載使用作業計算。

互動式與非互動式工作負載

許多使用者在開發期間處理轉換時，發現檢視查詢結果會很有説明。 將互動式工作負載從所有用途計算移至作業計算，您可以藉由移除顯示結果的查詢來節省時間和處理成本。

Apache Spark 會使用延遲程式代碼執行，這表示結果只會視需要計算，而且如果您不強制結果，針對數據源的多個轉換或查詢可以優化為單一查詢。 這與 pandas 中使用的急切執行模式形成對比，這需要在將結果傳遞至下一個方法之前，依序處理計算。

如果您的目標是將清理、轉換、匯總的數據儲存為新的數據集，您應該先移除顯示程式代碼結果的查詢，再排程執行。

對於小型作業和小型數據集，節省的時間和成本可能很微不足道。 不過，使用大型作業，將大量時間浪費在可能未手動檢查的筆記本上計算和列印結果。 儲存結果之後，可能會從儲存的輸出中查詢相同的結果，幾乎不需要任何成本。