1,500만 GPS 핑에 대한 ETL: 스택 및 아키텍처

일일 1,500만 GPS 신호 처리: 교통 분석을 위한 ETL 아키텍처

이 시스템은 타슈켄트의 170개 노선, 1,800대 버스에서 발생하는 1,500만 개의 GPS 좌표를 처리합니다. 3TM API를 통해 10초마다 신호가 수신됩니다. 핵심 과제는 고립된 좌표 데이터를 분석 가능한 구조화된 데이터로 변환하는 것입니다: 정류장 식별, 교통 체증, 운행 구간, 노선 이탈 등을 파악합니다.

asyncio + aiohttp를 사용한 로더가 systemd 타이머를 통해 API를 폴링합니다. 데이터는 PostgreSQL과 PostGIS에 기록됩니다. Dagster를 통한 ETL 오케스트레이션으로 경로 → 버스 → 정류장 → GPS 업데이트 순서를 보장합니다.

기술 스택 선택과 오버엔지니어링 회피

초기에는 Kafka와 ClickHouse를 테스트했으나 적합하지 않았습니다:

• Kafka는 풀 기반 API 폴링 모델에 이상적이지 않습니다—이점 없이 오버헤드만 추가합니다.
• 현재 쿼리 볼륨을 고려할 때 ClickHouse는 시기상조입니다.

최종 스택:

• 수집: 비동기 Python 로더, 2 vCPU / 4 GB RAM에서 약 360회/초 삽입.
• 저장: 경로, 정류장, GPS 시계열을 위한 PostgreSQL + PostGIS.
• 오케스트레이션: 의존성과 추적성을 위한 Dagster.
• 공간 분석: 무거운 작업(경로에 GPS 스냅핑, 수요 계산)을 위한 PySpark.

스테이징 계층은 원시 JSON을 1일간 저장한 후, ODS는 데이터베이스에서 재읽지 않고 메모리에서 데이터를 구조화합니다.

다중 계층 데이터 모델

확장성과 감사 가능성을 위해 데이터는 세 계층으로 구성됩니다:

• ODS: 운영 데이터—경로, 정류장, 현재 버스 위치.
• DDS (Data Vault 2.0): 허브(엔티티), 위성(속성), 링크(관계). GPS는 저장되지 않으며, 경로, 버스, 정류장에 초점을 맞춥니다.

• CDM: 분석 마트. fct_bus_trips 테이블—운행당 PostGIS LineString과 메타데이터(타임스탬프, 주행 거리, 속도, 노선 일치율) 포함.

Data Vault는 모델을 리팩토링하지 않고도 속성(원격 측정)을 추가할 수 있게 합니다.

운행 구간 분할 알고리즘

분할은 세 가지 신호를 기반으로 운행 시작/종료를 결정합니다:

• 속도: 출발/도착 정류장에서의 공회전.
• 5분 이상의 시간 간격: 스트림 중단.
• 노선 종점 근접성.

— Editorial Team