36개 도시 이기종 API 통합을 통한 Building Permit 데이터 정규화 파이프라인 구축

I normalised building permit data across 36 US cities and launched it on Apify - here's what I learned

Pablo2026년 5월 16일2분intermediate

AI 요약

Context

Socrata, ArcGIS, Accela 등 서로 다른 데이터 플랫폼과 도시별로 상이한 Schema 및 Date Format으로 인한 데이터 통합의 어려움 존재. 개별 도시 API에 의존하는 파편화된 접근 방식으로 인해 대규모 Lead Generation 데이터 확보 및 활용에 병목 발생.

Technical Solution

Socrata, ArcGIS, Accela 세 가지 메이저 Open Data 플랫폼의 API 및 Pagination 로직을 추상화한 통합 수집 계층 설계
도시별로 상이한 필드 명명 규칙과 데이터 타입을 단일 표준 Schema로 변환하는 Normalization Layer 구현
Date arithmetic 오류 방지를 위해 문자열 기반 날짜 데이터에 issueDateIsString 플래그를 부여하는 예외 처리 로직 적용
Reverse-engineering을 통해 문서화되지 않은 도시별 Custom Field를 식별하고 이를 표준 매핑 테이블에 정의
Pay-per-use 기반의 Apify Actor 구조를 채택하여 데이터 사용량에 비례한 과금 모델 구현

Impact

시카고 지역 2개월 데이터 기준 2,755건의 Permit 추출 및 $783M 규모의 프로젝트 가치 정량화
태양광 설치(205건), 지붕 공사(394건) 등 특정 도메인 데이터의 표준화된 추출 성공
건당 $1.50/1,000 permits의 비용 효율적인 데이터 파이프라인 제공

Key Takeaway

이기종 데이터 소스 통합 시 플랫폼 레벨의 공통 추상화 계층을 먼저 구축하고, 도시별 특이 케이스는 플래그 기반의 메타데이터 처리를 통해 시스템 유연성을 확보하는 설계 전략이 유효함.

실천 포인트

1. 서로 다른 API 플랫폼(Socrata, ArcGIS 등) 사용 시 Pagination과 Auth 로직을 인터페이스로 추상화했는가?

2. 데이터 타입 불일치(ISO vs Unix vs String) 해결을 위한 타입 플래그나 변환 레이어가 존재하는가?

3. 문서화되지 않은 외부 필드에 대응하기 위한 필드 매핑 테이블(Mapping Table)을 관리하고 있는가?

4. 최종 사용자가 개발자인지 비즈니스 사용자인지에 따라 데이터 제공 인터페이스와 메시징을 구분했는가?

태그

#API Integration #Open Data #Data Normalization #Schema Mapping #ETL Pipeline

원문 읽기