Databricks의 지리 공간 워크로드에서 공간 데이터 처리 및 분석은 비즈니스에 매우 중요합니다. 많은 팀이 이러한 워크로드를 처리하기 위해 Apache Sedona, Geopandas, Databricks Lab 프로젝트인 Mosaic과 같은 외부 라이브러리나 Spark 확장 프로그램을 사용합니다. 고객이 성공적으로 사용해왔지만, 이러한 접근 방식은 운영 오버헤드를 추가하고 수용 가능한 성능에 도달하기 위해 종종 튜닝이 필요합니다.
올해 초 Databricks는 Spatial SQL 지원을 출시했습니다. 여기에는 이제 90개의 공간 함수와 GEOMETRY 또는 GEOGRAPHY 열에 데이터를 저장하는 기능이 포함됩니다. Databricks 기본 내장 Spatial SQL은 추가 기능 라이브러리 사용의 모든 주요 문제를 해 결하므로 다른 어떤 대안보다 벡터 데이터를 저장하고 처리하는 데 가장 좋은 방법입니다. 즉, 안정성이 매우 높고 성능이 뛰어나며, Databricks SQL Serverless를 사용하면 기존 클러스터, 라이브러리 호환성, 런타임 버전을 관리할 필요가 없습니다.
가장 일반적인 공간 처리 작업 중 하나는 두 지오메트리가 겹치는지, 하나의 지오메트리가 다른 지오메트리를 포함하는지 또는 서로 얼마나 가까운지 비교하는 것입니다. 이 분석에는 공간 조인을 사용해야 하며, 공간적 인사이트를 얻는 시간을 단축하기 위해서는 뛰어난 기본 성능이 필수적입니다.
공간 조인을 위해 기본 내장 Spatial SQL을 사용하는 모든 고객은 Apache Sedona1이 설치된 클래식 클러스터에 비해 최대 17배 더 빠른 성능을 경험하게 될 것 이라는 기쁜 소식을 전해드립니다. 성능 개선 사항은 Databricks SQL 서버리스 및 Databricks Runtime(DBR) 17.3이 설치된 클래식 클러스터를 사용하는 모든 고객에게 제공됩니다. 이미 ST_Intersects 또는 ST_Contains와 같은 Databricks 기본 내장 공간 술어를 사용하고 있다면 코드 변경이 필요 없습니다.
공간 조인을 실행할 때는 여러 요인이 성능에 영향을 미치므로 특별한 어려움이 있습니다. 지리 공간 데이터 세트는 밀집된 도시 지역과 희박한 시골 지역처럼 분포가 한쪽으로 치우쳐 있는 경우가 많으며, 콜로라도의 단순한 경계선과 비교되는 노르웨이의 복잡한 해안선처럼 기하학적 복잡성도 매우 다양합니다. 효율적인 파일 프루닝 후에도 남아있는 조인 후보들은 여전히 컴퓨팅 집약적인 기하학적 운영을 필요로 합니다. 이것이 바로 Databricks의 강점입니다.
공간 조인 성능 향상은 R-트리 인덱싱, Photon의 최적화된 공간 조인, 지능형 범위 조인 최적화를 사용하여 이루어지며, 이 모든 것이 자동으로 적용됩니다. 사용자는 공간 함수로 표준 SQL을 작성하면, 엔진이 복잡한 부분을 처리합니다.
공간 조인은 데이터베이스 조인과 유사하지만 ID를 일치시키는 대신 공간 술어 를 사용하여 위치를 기반으로 데이터를 일치시킵니다. 공간 술어는 중첩, 포함 또는 근접성과 같은 상대적인 물리적 관계를 평가하여 두 데이터세트를 연결합니다. 공간 조인은 애널리스트가 쇼핑센터와 농장에서부터 도시와 지구 전체에 이르기까지 다양한 장소에 걸쳐 트렌드, 패턴, 위치 기반 인사이트를 발견하는 데 도움이 되는 강력한 공간 집계 도구입니다.
공간 조인은 모든 산업에서 비즈니스에 중요한 질문에 대한 해답을 제공합니다. 예를 들어, 다음과 같은 접근 방식이 있습니다.
데이터로는 Overture Maps Foundation의 주소, 건물, 토지 이용, 도로 등 4개의 전 세계 대규모 데이터 세트를 선택했습니다. 아래에 설명된 방법을 사용하여 직접 query를 테스트할 수 있습니다.
Overture Maps 데이터세트를 사용했으며, 이는 처음에 GeoParquet로 다운로드되었습니다. Sedona 벤치마킹을 위해 주소를 준비하는 예시가 아래에 나와 있습니다. 모든 데이터 세트는 동일한 패턴을 따랐습니다.
또한 Databricks 벤치마킹을 위해 parquet WKB를 네이티브 GEOMETRY 데이터 유형으로 변환하여 데이터를 Lakehouse 테이블로 처리했습니다.
위 차트는 각 compute에 대해 테스트된 동일한 3가지 쿼리 세트를 사용합니다.
query #1 - ST_Contains(buildings, addresses)
이 쿼리는 4억 5천만 개의 주소 포인트(point-in-polygon join)를 포함하는 25억 개의 건물 폴리곤을 평가합니다. 결과는 2억 건 이상의 일치입니다. Sedona의 경우, 기본 왼쪽 빌드 측 최적화를 지원하기 위해 이를 ST_Within(a.geom, b.geom) 으로 변경했습니다. Databricks에서는 ST_Contains 또는 ST_Within 사용에 실질적인 차이가 없습니다.
query #2 - ST_Covers(landuse, buildings)
이 query는 25억 개의 건물 폴리곤에 걸쳐 있는 전 세계 130만 개의 `industrial` 토지 이용 폴리곤을 평가합니다. 결과는 2,500만 개 이상의 일치 항목입니다.
query #3 - ST_Intersects(roads, landuse)
이 query는 전 세계 1,000만 개의 '주거용' 토지 이용 폴리곤과 교차하는 3억 개의 도로를 평가합니다. 그 결과 1억 개 이상의 일치 항목이 나옵니다. Sedona의 경우, 기본 왼쪽 빌드 측 최적화를 지 원하기 위해 이를 ST_Intersects(l.geom, trans.geom) 으로 변경했습니다.
Databricks는 고객 요청에 따라 새로운 공간 표현식을 계속 추가하고 있습니다. 다음은 퍼블릭 프리뷰 이후에 추가된 공간 함수 목록입니다. ST_AsEWKB, ST_Dump, ST_ExteriorRing, ST_InteriorRingN, ST_NumInteriorRings. 현재 DBR 18.0 베타에서 사용 가능: ST_Azimuth, ST_Boundary, ST_ClosestPoint, 두 가지 새로운 표현식 ST_GeogFromEWKT 및 ST_GeomFromEWKT를 포함한 EWKT 수집 지원, 그리고 ST_IsValid, ST_MakeLine, ST_MakePolygon에 대한 성능 및 안정성 개선.
추가적인 ST 표현식 또는 지리 공간 기능에 대한 요청이 있으시면 이 짧은 설문조사를 작성해 주세요.
Apache Spark™에 GEOMETRY 및 GEOGRAPHY 데이터 유형을 기여하는 작업은 큰 진전을 이루었으며 2026년에 Spark 4.2에 커밋될 예정입니다.
지금 바로 Databricks SQL에서 다음 Spatial 쿼리를 실행하여 공간 조인이 얼마나 빠른지 확인해 보세요. Spatial SQL 함수에 대해 자세히 알아보려면 SQL 및 Pyspark 설명서를 참조하세요. Databricks SQL에 대한 자세한 내용은 웹사이트, 제품 둘러보기, Databricks Free Edition을 확인하세요. 기존 warehouse를 뛰어난 사용자 경험과 저렴한 총비용을 제공하는 고성능 서버리스 데이터 웨어하우스로 마이그레이션하고 싶다면 Databricks SQL이 바로 그 해답입니다. 무료로 사용해 보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
