Databricks에서 지리공간 데이터를 대규모로 처리하기

기술의 발전과 융합은 시기적절하고 정확한 지리공간 데이터를 위한 활발한 시장을 형성했습니다. 매일 수십억 개의 휴대용 및 IoT 장치와 수천 개의 항공 및 위성 원격 감지 플랫폼은 수백 엑사바이트의 위치 인식 데이터를 생성합니다. 이러한 지리공간 빅데이터의 붐과 머신러닝의 발전은 업계 전반의 조직이 새로운 제품과 기능을 구축할 수 있도록 지원하고 있습니다.

예를 들어, 수많은 회사들이 매핑 및 현장 조사와 같은 지역화된 드론 기반 서비스를 제공합니다(참조: 지능형 클라우드 및 지능형 에지 개발). 또 다른 빠르게 성장하는 지리공간 데이터 산업은 자율 주행 차량입니다. 스타트업과 기존 회사 모두 차세대 자율 주행 자동차 혁신을 제공하기 위해 차량 센서에서 고도로 맥락화된 지오데이터의 대규모 코퍼스를 축적하고 있습니다(참조: Databricks, wejo의 모빌리티 데이터 생태계 구축 야망 지원). 소매업체와 정부 기관도 지리공간 데이터를 활용하려고 합니다. 예를 들어, 유동 인구 분석(참조: 유동 인구 통찰력 데이터 세트 구축)은 새 매장을 열기에 가장 좋은 위치를 결정하거나 공공 부문에서는 도시 계획을 개선하는 데 도움이 될 수 있습니다. 이러한 지리공간 데이터에 대한 모든 투자에도 불구하고 몇 가지 과제가 존재합니다.

대규모 지리공간 분석의 과제

첫 번째 과제는 스트리밍 및 배치 애플리케이션에서 규모를 처리하는 것입니다. 지리공간 데이터의 엄청난 확산과 애플리케이션에서 요구하는 SLA는 기존 스토리지 및 처리 시스템을 압도합니다. 데이터 볼륨, 속도, 스토리지 비용 및 엄격한 쓰기 시 스키마 적용과 같은 압력으로 인해 고객 데이터는 수년 동안 기존의 수직 확장 지오 데이터베이스에서 데이터 레이크로 유출되었습니다. 기업들은 지리공간 데이터에 투자했지만, 이러한 대규모 복잡한 데이터 세트를 다운스트림 분석에 준비할 적절한 기술 아키텍처를 갖춘 곳은 거의 없습니다. 또한, 고급 사용 사례에는 종종 확장된 데이터가 필요하므로 대부분의 AI 기반 이니셔티브는 파일럿에서 프로덕션으로 전환하지 못하고 있습니다.

다양한 공간 형식과의 호환성은 두 번째 과제입니다. 수십 년에 걸쳐 확립된 다양한 전문 지리공간 형식과 위치 정보가 수집될 수 있는 임시 데이터 소스가 많이 있습니다.

• GeoJSON, KML, Shapefile 및 WKT와 같은 벡터 형식
• ESRI Grid, GeoTIFF, JPEG 2000 및 NITF와 같은 래스터 형식
• AIS 및 GPS 장치에서 사용되는 것과 같은 탐색 표준
• PostgreSQL / PostGIS와 같은 JDBC / ODBC 연결을 통해 액세스 가능한 지오데이터베이스
• Hyperspectral, Multispectral, Lidar 및 Radar 플랫폼의 원격 센서 형식
• WCS, WFS, WMS 및 WMTS와 같은 OGC 웹 표준
• 지오태그가 지정된 로그, 사진, 비디오 및 소셜 미디어
• 위치 참조가 있는 비정형 데이터

이 블로그 게시물에서는 Databricks 통합 데이터 분석 플랫폼을 사용하여 위에서 언급한 두 가지 주요 과제를 해결하기 위한 일반적인 접근 방식에 대한 개요를 제공합니다. 이것은 대량의 지리공간 데이터를 다루는 일련의 블로그 게시물 중 첫 번째 부분입니다.

Databricks를 사용한 지리공간 워크로드 확장

Databricks는 전 세계 수천 명의 고객이 사용하는 빅데이터 분석 및 머신러닝을 위한 통합 데이터 분석 플랫폼을 제공합니다. Apache Spark™, Delta Lake 및 MLflow를 기반으로 하며 광범위한 타사 및 사용 가능한 라이브러리 통합 생태계를 갖추고 있습니다. Databricks UDAP는 프로덕션 워크로드에 대해 엔터프라이즈급 보안, 지원, 안정성 및 성능을 확장하여 제공합니다. 지리공간 워크로드는 일반적으로 복잡하며 모든 사용 사례에 맞는 단일 라이브러리는 없습니다. Apache Spark는 기본적으로 지리공간 데이터 유형을 제공하지 않지만, 오픈 소스 커뮤니티와 기업들은 공간 라이브러리를 개발하는 데 많은 노력을 기울여 선택할 수 있는 다양한 옵션을 제공합니다.

일반적으로 공간 조인 또는 최근접 이웃과 같은 지리공간 연산을 확장하는 세 가지 패턴이 있습니다.

1. 지리공간 분석을 위해 Apache Spark를 확장하는 전용 라이브러리 사용. GeoSpark, GeoMesa, GeoTrellis 및 Rasterframes는 고객이 사용하는 라이브러리 중 일부입니다. 이러한 프레임워크는 종종 여러 언어 바인딩을 제공하고 비공식적인 접근 방식보다 훨씬 뛰어난 확장성과 성능을 제공하지만 학습 곡선이 있을 수 있습니다.
2. GeoPandas, GDAL(Geospatial Data Abstraction Library) 또는 JTS(Java Topology Service)와 같은 단일 노드 라이브러리를 임시 사용자 정의 함수(UDF)로 래핑하여 Spark DataFrames를 사용하여 분산 방식으로 처리합니다. 이것은 많은 코드 재작성 없이 기존 워크로드를 확장하는 가장 간단한 접근 방식이지만, 더 많은 리프트 앤 시프트 특성으로 인해 성능상의 단점이 발생할 수 있습니다.
3. 그리드 시스템으로 데이터를 인덱싱하고 생성된 인덱스를 활용하여 공간 연산을 수행하는 것은 매우 큰 규모 또는 계산적으로 제한된 워크로드를 처리하는 일반적인 접근 방식입니다. S2, GeoHex 및 Uber의 H3는 이러한 그리드 시스템의 예입니다. 그리드는 고정된 식별 가능한 셀 세트로 지오 피처(예: 폴리곤 또는 포인트)를 근사화하여 값비싼 지리공간 연산을 완전히 피하므로 훨씬 더 나은 확장성을 제공합니다. 구현자는 다소 손실이 발생할 수 있지만 성능이 더 뛰어난 단일 정확도 그리드 또는 성능이 떨어질 수 있지만 손실을 완화할 수 있는 여러 정확도 그리드 중에서 선택할 수 있습니다.

다음 예제는 일반적으로 여기에서 찾을 수 있는 NYC 택시 픽업/하차 데이터 세트를 중심으로 합니다. 지오메트리가 있는 NYC 택시 구역 데이터도 폴리곤 세트로 사용됩니다. 이 데이터에는 NYC의 5개 자치구와 동네의 폴리곤이 포함되어 있습니다. 이 노트북은 초기 CSV 파일을 안정적이고 성능이 뛰어난 데이터 소스로 Delta Lake 테이블로 변환하기 위해 수행된 준비 및 정리 작업을 안내합니다.

기본 DataFrame은 Databricks를 사용하여 Delta Lake 테이블에서 읽은 택시 픽업/하차 데이터입니다.

Apache Spark용 지오스페이셜 라이브러리를 사용한 지오스페이셜 연산

지난 몇 년 동안 지오스페이셜 분석을 위한 Apache Spark의 기능을 확장하기 위해 여러 라이브러리가 개발되었습니다. 이러한 프레임워크는 일반적으로 적용되는 사용자 정의 유형(UDT) 및 함수(UDF)를 일관된 방식으로 등록하는 데 중점을 두어, 사용자와 팀이 임시 공간 로직을 작성해야 하는 부담을 덜어줍니다. 이 블로그 게시물에서는 다양한 기능을 강조하기 위해 여러 지오스페이셜 프레임워크를 사용한다는 점에 유의해 주십시오. 저희는 Databricks에서 공간 워크로드를 처리하는 데 사용할 수 있는 다른 프레임워크도 존재한다는 것을 알고 있습니다.

이전에 기본 데이터를 DataFrame으로 로드했습니다. 이제 위도/경도 속성을 포인트 지오메트리로 변환해야 합니다. 이를 달성하기 위해 UDF를 사용하여 DataFrame에서 분산 방식으로 연산을 수행할 것입니다. 클러스터에 이러한 프레임워크를 추가하는 방법과 UDF 및 UDT를 등록하기 위한 초기화 호출에 대한 자세한 내용은 블로그 끝에 제공된 노트북을 참조하십시오. 우선, 벡터 데이터를 처리하는 데 특히 능숙한 프레임워크인 GeoMesa를 클러스터에 추가했습니다. 수집을 위해 JTS와 Spark SQL의 통합을 주로 활용하고 있으며, 이를 통해 등록된 JTS 지오메트리 클래스로 쉽게 변환하고 사용할 수 있습니다. 위도와 경도를 주면 Point 지오메트리 객체를 생성하는 st_makePoint 함수를 사용할 것입니다. 이 함수는 UDF이므로 열에 직접 적용할 수 있습니다.

GeoMesa에서 제공하는 st_contains UDF를 사용하여 모든 폴리곤과 픽업 포인트의 조인 결과를 생성하는 분산 공간 조인도 수행할 수 있습니다.

단일 노드 라이브러리를 UDF로 래핑

전용 분산 공간 프레임워크를 사용하는 것 외에도 기존 단일 노드 라이브러리를 임시 UDF로 래핑하여 DataFrame에서 지오스페이셜 연산을 분산 방식으로 수행할 수 있습니다. 이 패턴은 모든 Spark 언어 바인딩(Scala, Java, Python, R, SQL)에서 사용할 수 있으며, 코드 변경을 최소화하면서 기존 워크로드를 활용하는 간단한 접근 방식입니다. 단일 노드 예제를 시연하기 위해 NYC 자치구 데이터를 로드하고 geopandas를 사용하여 점-폴리곤 연산을 위한 UDF find_borough(...)를 정의하여 각 GPS 위치를 자치구에 할당해 보겠습니다. 이는 성능 향상을 위해 벡터화된 UDF로도 달성할 수 있습니다.

이제 UDF를 적용하여 Spark DataFrame에 열을 추가하고 각 픽업 포인트에 자치구 이름을 할당할 수 있습니다.

공간 인덱싱을 위한 그리드 시스템

지오스페이셜 연산은 본질적으로 계산 비용이 많이 듭니다. 점-폴리곤, 공간 조인, 최근접 이웃 또는 경로 스내핑은 모두 복잡한 연산을 포함합니다. 그리드 시스템으로 인덱싱함으로써 지오스페이셜 연산을 완전히 피하는 것을 목표로 합니다. 이 접근 방식은 근사 연산이라는 단점이 있지만 가장 확장 가능한 구현으로 이어집니다. H3을 사용한 간단한 예는 다음과 같습니다.

H3을 사용한 공간 연산 확장은 본질적으로 두 단계 프로세스입니다. 첫 번째 단계는 UDF geoToH3(...)로 정의된 각 피처(점, 폴리곤 등)에 대한 H3 인덱스를 계산하는 것입니다. 두 번째 단계는 UDF multiPolygonToH3(...)로 정의된 공간 조인(점-폴리곤, k-최근접 이웃 등)과 같은 공간 연산에 이러한 인덱스를 사용하는 것입니다.

이제 NYC 택시 데이터와 자치구 폴리곤 세트에 이러한 두 UDF를 적용하여 H3 인덱스를 생성할 수 있습니다.

이제 위도/경도 포인트 세트와 폴리곤 지오메트리 세트가 주어지면 h3index 필드를 조인 조건으로 사용하여 공간 조인을 수행할 수 있습니다. 이러한 할당은 예를 들어 각 폴리곤 내에 속하는 포인트 수를 집계하는 데 사용될 수 있습니다. 일반적으로 수백만 또는 수십억 개의 포인트가 수천 또는 수백만 개의 폴리곤과 일치해야 하므로 확장 가능한 접근 방식이 필요합니다. 근사가 불충분할 때 공간 연산을 지원하기 위한 인덱싱에 사용할 수 있는 다른 기술이 이 블로그에서 다루지 않았습니다.

다음은 택시 하차 위치를 위도와 경도를 7 해상도(1.22km 변 길이)로 구간화하고 각 구간 내 집계된 카운트로 색칠한 시각화 자료입니다.

Databricks로 공간 형식 처리하기

지리 공간 데이터는 속성으로 설명되는 특징과 함께 지구상의 물리적 위치 또는 범위에 대한 위도 및 경도와 같은 참조 지점을 포함합니다. 선택할 수 있는 파일 형식이 많이 있지만, Databricks로 읽는 것을 시연하기 위해 몇 가지 대표적인 벡터 및 래스터 형식을 선정했습니다.

벡터 데이터

벡터 데이터는 도(경도), 위도(위도) 좌표로 저장되며, 고도까지 고려하면 미터 단위의 z(고도) 좌표도 포함하는 세계 표현입니다. 벡터 데이터의 세 가지 기본 기호 유형은 점, 선, 다각형입니다. Well-known-text (WKT), GeoJSON, Shapefile은 아래에서 강조할 벡터 데이터를 저장하는 몇 가지 인기 있는 형식입니다.

WKT로 저장된 지오메트리가 있는 NYC 택시 구역 데이터를 읽어 보겠습니다. 원하는 데이터 구조는 DataFrame으로, 블로그의 다른 부분에서 사용되는 것과 같은 다른 API 및 사용 가능한 데이터 소스와 표준화할 수 있습니다. `st_geomFromWKT(...)` UDF 호출을 통해 `the_geom` 필드에 있는 WKT 텍스트 내용을 해당 JTS Geometry 클래스로 쉽게 변환할 수 있습니다.

GeoJSON은 많은 오픈 소스 GIS 패키지에서 기능, 속성 및 공간 범위를 포함한 다양한 지리 데이터 구조를 인코딩하는 데 사용됩니다. 이 예에서는 NYC 자치구 경계 데이터를 읽을 것이며, 접근 방식은 워크플로에 따라 달라집니다. 데이터가 JSON 형식이므로 Databricks 내장 JSON 판독기와 `.option("multiline","true")`를 사용하여 중첩된 스키마로 데이터를 로드할 수 있습니다.

여기서 Spark의 내장 `explode` 함수를 사용하여 필드를 최상위 열로 올릴 수 있습니다. 예를 들어, 지오메트리, 속성 및 유형을 가져온 다음 WKT 예시에서 보여준 것처럼 지오메트리를 해당 JTS 클래스로 변환할 수 있습니다.

기존 DataFrame을 사용하여 노트북 내에서 NYC 택시 구역 데이터를 시각화하거나, 공간 데이터를 렌더링하는 Python 라이브러리인 Folium과 같은 라이브러리를 사용하여 데이터를 직접 렌더링할 수도 있습니다. Databricks File System (DBFS)는 분산 스토리지 계층 위에서 실행되어 코드가 익숙한 파일 시스템 표준을 사용하여 데이터 형식으로 작업할 수 있도록 합니다. DBFS에는 파일 읽기 및 쓰기 작업을 수행하는 로컬 API 호출을 허용하는 FUSE 마운트가 있어, 대화형 렌더링을 위해 비분산 API로 데이터를 쉽게 로드할 수 있습니다. 아래 Python `open(...)` 명령에서 "/dbfs/..." 접두사는 FUSE 마운트 사용을 활성화합니다.

Shapefile은 ESRI에서 개발한 인기 있는 벡터 형식으로, 지리적 특징의 기하학적 위치 및 속성 정보를 저장합니다. 이 형식은 동일한 디렉토리에 저장된 공통 파일 이름 접두사(*.shp, *.shx, *.dbf는 필수)를 가진 파일 모음으로 구성됩니다. Shapefile의 대안으로 KML이 있으며, 고객들도 사용하지만 간결성을 위해 여기서는 다루지 않습니다. 이 예에서는 NYC 건물 Shapefile을 사용하겠습니다. Shapefile을 읽는 방법을 시연하는 방법은 많지만, GeoSpark를 사용한 예시를 제공하겠습니다. 내장 ShapefileReader를 사용하여 `rawSpatialDf` DataFrame을 생성합니다.

`rawSpatialDf`를 임시 뷰로 등록함으로써 순수 Spark SQL 구문으로 쉽게 작업하여 DataFrame을 처리할 수 있으며, 여기에는 Shapefile WKT를 Geometry로 변환하는 UDF 적용도 포함됩니다.

또한, NYC에서 가장 높은 건물을 차트로 그리는 것과 같은 인라인 분석을 위해 Databricks 내장 시각화를 사용할 수 있습니다.

래스터 데이터

래스터 데이터는 행과 열(이산형 또는 연속형)로 구성된 셀(또는 픽셀) 행렬에 특징 정보를 저장합니다. 위성 이미지, 사진 측량, 스캔된 지도는 모두 래스터 기반 지구 관측(EO) 데이터의 유형입니다.

다음 Python 예제에서는 DataFrame 중심의 공간 분석 프레임워크인 RasterFrames를 사용하여 GeoTIFF Landsat-8 영상(빨간색 및 근적외선)의 두 개 밴드를 읽고 이를 정규화 차이 식생 지수로 결합합니다. 이 데이터를 사용하여 NYC 주변 식물의 건강 상태를 평가할 수 있습니다. rf_ipython 모듈은 RasterFrame 내용을 시각적으로 유용한 다양한 형태로 조작하는 데 사용됩니다. 예를 들어, 아래에서는 빨간색, NIR 및 NDVI 타일 열이 색상 램프를 사용하여 렌더링되며, Databricks의 내장 displayHTML(...) 명령을 사용하여 노트북 내에서 결과를 표시합니다.

사용자 지정 Spark DataSource를 통해 RasterFrames는 GeoTIFF, JP2000, MRF, HDF를 포함한 다양한 래스터 형식을 다양한 서비스 배열에서 읽을 수 있습니다. 또한 GeoJSON 및 WKT/WKB 벡터 형식 읽기도 지원합니다. RasterFrame 내용은 위 예제에서 사용된 st_reproject(...) 및 st_centroid(...)와 같은 200개 이상의 래스터 및 벡터 함수를 통해 필터링, 변환, 요약, 리샘플링 및 래스터화할 수 있습니다. Python, SQL 및 Scala용 API와 Spark ML과의 상호 운용성을 제공합니다.

지오데이터베이스

지오 데이터베이스는 소규모 데이터의 경우 파일 기반이거나 중간 규모 데이터의 경우 JDBC / ODBC 연결을 통해 액세스할 수 있습니다. Databricks를 사용하여 내장된 JDBC / ODBC 데이터 소스로 많은 SQL 데이터베이스를 쿼리할 수 있습니다. 아래에서는 일반적으로 소규모 워크로드에 사용되는 PostgreSQL에 연결하는 방법을 보여주며, 이는 PostGIS 확장을 적용합니다. 이 연결 패턴을 통해 고객은 기존 데이터베이스에 대한 기존 액세스를 유지할 수 있습니다.

Databricks에서 지리 공간 분석 시작하기

기업 및 정부 기관은 엔터프라이즈 데이터 소스와 함께 공간 참조 데이터를 사용하여 실행 가능한 통찰력을 얻고 광범위한 혁신적인 사용 사례를 제공하고자 합니다. 이 블로그에서는 Databricks 통합 데이터 분석 플랫폼이 지리 공간 워크로드를 어떻게 쉽게 확장하여 고객이 클라우드의 강력한 기능을 활용하여 방대한 크기의 데이터를 캡처, 저장 및 분석할 수 있도록 하는지 보여주었습니다.

다음 블로그에서는 Databricks를 사용한 지리 공간 처리 확장에 대한 더 고급 주제를 심층적으로 다룰 것입니다. 데이터 준비 노트북, GeoMesa + H3 노트북, GeoSpark 노트북, GeoPandas 노트북 및 Rasterframes 노트북을 검토하여 공간 형식 및 강조 표시된 프레임워크에 대한 추가 세부 정보를 찾을 수 있습니다. 또한 관심 있는 지리 공간 주제를 위한 문서의 새로운 섹션을 계속 지켜봐 주십시오.

다음 단계

• 곧 열릴 웨비나 공공 부문에서의 지리 공간 분석 및 AI에 참여하여 인기 있는 여러 사용 사례를 다루는 라이브 데모를 시청하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)