Lakehouse RT: geospatiale queries nu tot 38 keer sneller

Samenvatting

Lakehouse//RT verwerkt geospatiale queries tot 38 keer sneller dan een traditioneel datawarehouse bij 50 gelijktijdige gebruikers.

Lakehouse//RT versnelt Spatial SQL en spatial joins

Databricks ondersteunt Spatial SQL en spatial joins nu op Lakehouse//RT. In benchmarks met SpatialBench was Lakehouse//RT gemiddeld drie keer sneller dan een traditioneel clouddatawarehouse en tot twintig keer sneller over de geteste queries.

Bij een belasting van 50 gelijktijdige gebruikers liep het verschil op tot 38 keer, bij queries waarop het traditionele warehouse nog kon antwoorden. Lakehouse//RT draait deze bewerkingen rechtstreeks op governed lakehouse-data. Een aparte geospatiale servinglaag is daardoor niet nodig.

De functionaliteit omvat onder meer het GEOMETRY-datatype, meer dan honderd ruimtelijke functies en high-performance spatial joins. Die data blijft beschikbaar in open formaten, waaronder Parquet voor Delta en Iceberg v3. Unity Catalog levert de governance-laag.

Geospatiale workloads zonder aparte PostGIS-stack

Veel geospatiale toepassingen combineren ruimtelijke OLAP met locatiegebonden applicaties. Volgens Databricks gebruiken teams daarvoor nog vaak een traditioneel datawarehouse of een aparte architectuur rond PostGIS. Dat betekent extra datakopieën, synchronisatiepipelines en governancewerk.

Databricks deelt geospatiale workloads op in vier onderdelen: Lakehouse voor langdurige spatial OLAP, Lakebase voor spatial OLTP, applicaties en agents, Databricks Apps voor gespecialiseerde ervaringen en Lakehouse//RT voor realtime analytics. Daarmee plaatst het product zich naast, niet als vervanging van, de bestaande opties voor transacties en applicatielogica.

De benchmark zegt vooral iets over queryprestaties onder gelijktijdige belasting. De uitkomst geldt dus niet automatisch voor iedere query of iedere werklast.

Takeaway voor Lakehouse//RT

Gebruik de SpatialBench-documentatie om de eigen queries te vergelijken, met extra aandacht voor query acht. Sla geometrieën bij voorkeur op als native GEOMETRY in plaats van telkens ST_GeomFromWKB uit te voeren; volgens Databricks ondersteunen native datatypes query-optimalisaties en file-skipping.