Databricks Databricks ★ 52 4 min

Geospatial queries are up to 38X faster with Lakehouse//RT

Lakehouse

🔗 https://www.databricks.com/blog/geospatial-queries-are-38x-faster-lakehousert

📌 空間查詢加速38倍背後的架構

TL;DR:Databricks讓Spatial SQL跑在新推出的Lakehouse//RT上,高併發下最高快38倍。

當一家公司必須為地理空間應用另外維護一套PostGIS架構,只為了滿足低延遲需求時,資料卻因此多了一份副本、多了一條同步管線、多了一層治理負擔。

🤔 為什麼空間工作負載需要新架構

Databricks指出,保險、農業、能源、電信、零售、物流等產業的客戶已採用其今年推出的Spatial SQL(GA版),包括GEOMETRY資料型別、100多個空間函式、高效能spatial join、AI/BI maps與Delta Sharing。但對於同時有spatial OLAP與即時地理位置應用需求的組織,許多仍依賴傳統資料倉儲,並為每個應用場景另外搭建以PostGIS為核心的專用架構,這會導致更多資料副本、更多同步管線與更多治理成本。

🧩 四大支柱架構

Databricks現在提出地理空間工作負載的四個支柱:Lakehouse負責長時間執行的spatial OLAP;Lakebase負責spatial OLTP、應用程式與代理;Databricks Apps提供專屬體驗;而新加入的Lakehouse//RT則負責即時分析。GEOMETRY與GEOGRAPHY資料型別屬於開放lakehouse的一部分,在Apache Spark中可用,並支援Delta與Iceberg v3所使用的同一套底層parquet檔案格式。

📊 用SpatialBench跑出來的數字

Databricks以SpatialBench為基準,拿Lakehouse//RT與傳統雲端資料倉儲對比:

情境效能提升
一系列空間查詢,整體平均3X
測試查詢中的最佳表現最高20X
50個並行使用者的高負載情境最高38X

此外,Lakehouse//RT整體被設計為能在governed lakehouse資料上直接提供毫秒級查詢效能,Databricks表示其預覽客戶觀察到延遲低至10毫秒、併發量最高可達每秒12,000次查詢。

💡 最佳實務:直接用原生GEOMETRY型別

Databricks在文中特別提醒,在跑SpatialBench的查詢8時,建議移除將well-known binary轉換為GEOMETRY的ST_GeomFromWKB呼叫,改用原生GEOMETRY型別,因為這樣才能讓查詢最佳化與file-skipping發揮作用,拿到最好的效能。

⚠️ 目前仍是Beta,且為廠商自行benchmark

Spatial SQL在Lakehouse//RT上目前為Beta階段,上述倍數提升數字來自Databricks自行發布的SpatialBench測試結果,並未提及第三方獨立驗證。

🎯 實務啟示

對已經在用Databricks Spatial SQL的團隊來說,官方強調不需要改程式碼,只要建立一個Lakehouse//RT warehouse,把現有查詢指向它即可取得加速,這代表遷移成本主要是基礎設施層級的切換,而不是重寫查詢邏輯,值得評估是否能藉此收斂掉原本另外維護的PostGIS專用堆疊。

🔗 來源

#Databricks #SpatialSQL #Geospatial #Lakehouse #DataEngineering #RealTimeAnalytics #BigData #DeltaLake #CloudDataWarehouse #DataPlatform

原始資料 Databricks · 收集於 2026-10-16
來源原標題
Geospatial queries are up to 38X faster with Lakehouse//RT
機構
Databricks
原始標籤
Lakehouse
原始連結
https://www.databricks.com/blog/geospatial-queries-are-38x-faster-lakehousert

摘要原文

Spatial SQL and spatial joins now run on Lakehouse//RT and they're up to 38X faster than traditional cloud data warehouses. Earlier this year, we brought Spatial SQL to General Availability on Databricks: this included support for the GEOMETRY data type, 100+ spatial functions, high-performance spatial joins, AI/BI maps, Delta Sharing. The GEOMETRY and GEOGRAPHY data types are part of the open lakehouse, available in Apache Spark, and supported in the same underlying parquet files used by Delta and Iceberg v3. Customers across insurance, agriculture, energy, telecom, retail, logistics and more have adopted it to consolidate geospatial workloads onto a single governed platform. Organizations with both spatial OLAP workloads and real-time location-based applications want great performance and high concurrency. Many of these organizations still rely on traditional data warehouses and build out specialized architectures for spatial applications, sometimes managing a separate stack centered on PostGIS for every use case just to meet latency requirements. Separate stacks lead to more copies of data, more synchronization pipelines, and more governance overhead. Databricks now supports 4-pillars for geospatial workloads: Lakehouse for long-running spatial OLAP workloads, Lakebase for spatial OLTP, apps, and agents, Databricks Apps for purpose-built experiences, and now the Lakehouse//RT warehouse for real-time analytics. This blog covers what Lakehouse//RT delivers for spatial workloads, driving up to 38X performance improvement under high concurrency. We benchmarked Lakehouse//RT against a traditional cloud data warehouse across a suite of spatial queries using SpatialBench . By comparison, Lakehouse//RT delivers 3X faster on average, and up to 20X faster across the tested queries. Under heavy load, the performance differences are even more significant. At 50 concurrent users, Lakehouse//RT delivers up to 38X on the queries where the traditional warehouse could keep up. Try it for yourself: Follow the SpatialBench documentation to generate the synthetic data used in the benchmark queries from this page . Take a look at query #8. To follow best practices, it is recommended to remove the ST_GeomFromWKB call that converts data stored as well-known binary and instead use the native GEOMETRY data types. Using the native data types allows query optimizations and file-skipping to provide the best performance. Spatial SQL on Databricks already serves a wide range of industries. With Lakehouse//RT, workloads can run with the real-time speed applications demand. Here are a few examples: Spatial SQL on Lakehouse//RT is available now in Beta. To get started: At Data + AI Summit 2026, we introduced Lakehouse//RT , Databricks' new real-time data warehouse built to deliver millisecond query performance at massive concurrency directly on your lakehouse data . Lakehouse//RT was designed to solve a specific problem: as organizations expand data access across users, applications, dashboards, and AI agents, they need real-time responsiveness without copying data into a separate serving layer. Preview customers have seen significantly better performance overall with Lakehouse//RT vs. real-time serving layers, with latency as low as 10ms and concurrency as high as 12,000 queries per second. Yes. Spatial SQL and spatial joins now run on the Lakehouse//RT, so you can serve geospatial queries with low latency and high concurrency directly on your governed Delta and Iceberg tables. There is no need to copy data into a separate geospatial system or real-time analytics serving layer. No. The same spatial functions and spatial joins you run on Databricks SQL Serverless today run on Lakehouse//RT with no code changes. You get the speedup by creating a Lakehouse//RT warehouse and pointing your existing queries at it. In head-to-head benchmarks against a traditional data warehouse, Lakehouse//RT runs spatial queries up to 38X faster under heavy load. On average, benchmark queries are 3.5X faster even when you exclude the largest increase. Spatial SQL and spatial joins are available on Lakehouse//RT in Beta. To get started, create a Lakehouse//RT warehouse from the SQL Warehouses page and run your existing spatial queries with no code changes. Yes. All H3 expressions supported by Databricks Lakehouse are supported today with Lakehouse//RT. Read more about H3 here . Yes. You can create maps that use native geometry and geography data types in AI/BI dashboards. Read more here . Subscribe to our blog and get the latest posts delivered to your inbox.

由 claude-code/sonnet 自動生成