brunch

You can make anything
by writing

C.S.Lewis

by 리플러스 Mar 06. 2023

부동산 정보 데이터 통합처리

수많은 데이터를 어떻게 처리해야 원하는 결과를 얻을 수 있을까



기존에 작성했던 부동산 매물정보에 대한 정보조사 글

https://brunch.co.kr/@clay1987/315



부동산 정보는 여러 국가기관에서 제공하는 데이터 API를 모아서 정리한 결과를 사용하고있다. 다만 한곳에서만 제공하는 정보가 아닌데다, 그 양이 많아 문제가된다. 일단 5년 ~ 10년이 넘는 개별 데이터들을 쌓아야하고, 개별 데이터를 특정 기준점을 잡아 정리해줘야한다. 주요 정보들을 정리해보면 다음과 같다.



국토교통부

1. 건축물 실거래가 정보 - 준공연도, 거래연도, 거래가격, 건물구분

2. 상업용 부동산 매매자료 - 건물면적, 계약연도, 대지면적    

3. 부동산 통계정보 - 지목 (토지 목적)

4. 건축물대장 정보 - 주용도, 기타용도, 지상 및 지하 층수, 승강기 수, 용적율

5. 용도 지역정보 서비스 - 도시개발 진행 여부

6. 토지이용계획 정보 서비스 - 용도지역, 용도지구

7. 건축물 소유자 정보

8. 개별 공시지가 정보 - 공시지가, 주택가격

9. 버스정류장 / 버스정류소 정보

10. 공동주택 관리비


행정안전부

1. 지역별 업종조회 - 건강, 동물, 식품, 문화, 생활, 자원환경 등 개별 업종정보


서울시

1. 건축물 대장 층별 개요정보

2. 서울시 도시계획 정비사업 현황


서울교통공사

1. 지하철역 위치정보


소상공인 시장진흥공단

1. 상가 / 상권 정보


공공데이터 활용 지원센터

1. 전국 어린이집 표준 데이터

2. 전국 초, 중, 고교 위치 표준데이터


한국교육학술정보원

1. 전국 유치원 표준 데이터



교육부

1.전국 대학교 개황 






지도 관련 커스터마이징에 필요한 기능은 대부분 지도 API 자체에서 제공하고있다.


카카오지도

1. 지적도 구분값

2. 위성사진 모드

3. A에서 B까지의 직선 실제 거리 계산

4. 마커 클러스터링

5. 커스텀 오버레이 생성

6. 로드뷰 썸네일 생성

7. 이미지 지도 생성

                    





위에서 모은 API 데이터들은 업데이트 주기가 제각각이다. 그러니 개별 기능이 업데이트될때마다 기존 DB와 합쳐주는 작업을 처리해줘야한다. 업데이트가되는 정보는 크게 두가지로 나눌 수 있다.


1. 소량의 개별 API 업데이트

2. 대량의 주요 API 업데이트


일반적으로 작은 양의 데이터가 업데이트되는건, 전체 서비스에 큰 영향을 주지않는다. 하지만 1년단위로 업데이트되는 전국 단위의 거래내역이나, 건축물대장같은 정보들은 상황이 다르다. 이런 많은 양의 데이터를 실시간 업데이트를 할 경우 서비스 이용에 문제가 생길 수 있다. 그러니 업데이트가 확인된 시점 이후 미리 다운로드받아두었다가, 새벽이나, 사용자가 많이 없는 밤 시간에 데이터 통합처리와 DB 업데이트를 처리하는게 낫다.



또한 개별 API들은 서비스가 중단되거나, 다른 데이터에 통합되어 제공되는 경우도 있다. 그렇기 때문에 개별 API 제공사의 공지사항 등을 주기적으로 확인해보아야한다. 또한 개별 API 리퀘스트를 보낼 때 답변이 없거나 에러가 생길 경우, '응답없음' 과 같은 케이스에 대해 관리자가 확인할 수 있는 방법을 준비해두어야한다.



공공데이터포털 공지사항 게시판

https://www.data.go.kr/bbs/ntc/selectNoticeListView.do






데이터를 통합하는 방식에 대해서도 고민해볼 필요가 있다. 부동산 서비스는 주로 주소값을 기준으로 정리가 되겠지만, 주소값 외에도 별도 지역별 코드값을 갖는 경우가 있다. 그러니 이 두가지를 중심으로 조합을 해서 DB 기준의 유니크 ID값을 정리해줄 수 있다.



API 요청을 보낸 다음, 다시 데이터베이스 (DB)에 쌓아주는 방식


여러 API 서비스에 보낼 정보요청을 하나로 묶어주는 방법도 있다.



데이터들을 정리하고나면 주기적으로 업데이트를 처리해줘야하고, 기존에 가져왔던 데이터와, 신규데이터를 비교해 신규정보만 저장해주는 형태로 처리를 해줘야한다. 그러니 신규데이터와 기존 데이터를 비교하는 과정이 필요하다. 다만 이 데이터의 양이 많고, 개별 조각으로 이뤄진 데이터인 경우, 변형된 최종 DB 테이블이 아닌, 기존의 조각들을 비교하는 것이 좋다. 그러면 이 경우, 합쳐지기 이전의 데이터들도 따로 저장을 해야하는거 아닐까?



1. 기존에 API를 통해서 불러온 개별 정보들을 따로 저장해둔다.

2. 신규로 API를 통해서 불러온 개별 정보도 따로 저장해둔다.

3. 1번과 2번을 비교해서 새로운 데이터를 찾아낸다.

4. 새로운 데이터라고 판별된 정보를 기존 통합 DB 테이블 (업데이트 이전)과 합쳐준다.

5. 새로운 데이터가 통합된 DB 테이블이 만들어진다 (업데이트 완료)

6. 통합된 정보들이 어떤 정보인지, 언제 업데이트를 처리했는지 태그처리해 저장해둔다.



개별 데이터가 업데이트된 날짜에 대한 정보를 갖고있지 않을 경우, 개별 데이터들을 일일히 비교해서 체크해봐야할거다. 하지만 데이터가 날짜 정보나, 별도의 넘버링 태그를 갖고있는 경우. 제일 마지막에 정리한 날짜나, 마지막 태그 이후의 값을 모두 저장하는 형태로도 처리할 수 있다. 그러니 이 부분에서 구분값으로 사용할 수 있는 태그가 API를 통해서 전달되는지. 개별 API 문서를 확인해보면 된다.






백엔드 기준에서 업데이트시 자동으로 '신규데이터'를 추려내고, 통합된 결과를 따로 저장하면 좋을것 같다. 문제는 로직연산의 복잡도가 얼마나 높은지. 또 개별 업데이트마다 얼마나 많은 정보가 합쳐져야하는지가 문제일듯 하다.


매거진의 이전글 건설현장의 사용자타입 / 업무단계별 작업정보
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari