제 18회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [이탈리안 BMT] : 지하철 지연 시간 데이터 분석 및 시각화를 위한 데이터 파이프라인 구축

지하철 너 뭐 돼?
: 지하철 지연 시간 데이터 분석 및 시각화를
위한 데이터 파이프라인 구축

목차
(●’◡’●)
01 팀 구성
(❁´◡`❁)
02 주제 및 목표
(ﾉ*･ω･)ﾉ
03 소스 데이터 설명
( *^-^)ρ(^0^* )
04 데이터 파이프라인
(●ˇ∀ˇ●)
05 결과 도출 및 시각화
(┬┬﹏┬┬)
06 의의 및 한계

19기 엔지 김가경
동덕여대 정보통계학과
19기 엔지 김동진
경희대 컴퓨터공학과
19기 분석 김보겸
중앙대 사회학과
19기 엔지 박재은
숙명여대 컴퓨터과학 전공
19기 엔지 이재준
명지대 융합소프트웨어
데이터테크놀로지 전공
01 팀구성

지하철 운행시간표는
실시간이 아닌 정적으로 관리/운영
→ 지하철 도착 지연이 빈번하게 발생하여
운행 시간표의 신뢰도 의심
→ 현 운행 시간표의 신뢰도를 측정하고자 함
지하철 지연 시간 데이터 분석 및 시각화를
위한 데이터 파이프라인 구축
What? Why?

- 데이터
: 서울시 실시간 지하철 운행 데이터 API, 네이버 지도의 지하철 도착 시간표
- 데이터 수집
: AWS 서비스 ( S3, lambda, event bridge ) 를 활용하여 스크래퍼 개발 및 데이터 적재
- 데이터 분석 및 시각화
: 적재한 데이터를 바탕으로 ELK stack 및 BigQuery, Looker Studio를 활용한 분석 및 시각화
How?

서울시 실시간 지하철 운행 데이터 api 활용
https://data.seoul.go.kr/dataList/OA-12764/F/1/datasetView.do
03 소스 데이터 설명 - 실시간 지하철 운행 데이터

03 소스 데이터 설명 - 실시간 지하철 운행 데이터
{
“lineNum” : 호선,
“weekTag” : 평일(1), 토요일(2), 공휴일(3) 구분,
“inOutTag” : 상/하행, 내/외선 구분,
“stationNm” : 역 이름,
“arriveTime” : 도착시간,
“arriveDate” : 도착날짜
}
API 데이터 중
일부 사용
서울시 실시간 지하철 운행 데이터 API 활용

03 소스 데이터 설명 - 지하철 도착 시간표 데이터
네이버 지도의 지하철 도착 시간표 데이터 활용
{
“arriveTime” : 도착시간
}
스크래핑

04 데이터 파이프라인
Push
GitHub Actions Amazon ECR
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
요청, 응답, 처리
지하철 호선 정보
스크래퍼 (네이버)
당일 지하철 시간표
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Big Query Looker Studio
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Publish
Data
Transform

04 데이터 파이프라인 - Scrapper
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Big Query
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Publish
Looker Studio
Data
Transform

04 데이터 파이프라인 - 공공API 데이터 리퀘스트
출력명 설명
subwayId
지하철호선ID
(1001:1호선, 1002:2호선, 1003:3호선, 1004:4호선,
1005:5호선 1006:6호선, 1007:7호선, 1008:8호선,
1009:9호선, 1061:중앙선1063:경의중앙선, 1065:공항
철도, 1067:경춘선, 1075:수의분당선 1077:신분당선,
1092:우이신설선)
updnLine
상하행선구분
(0 : 상행/내선, 1 : 하행/외선)
statnId 지하철역ID
recptnDt 열차도착정보를 생성한 시각
arvlCd
도착코드
(0:진입, 1:도착, 2:출발, 3:전역출발, 4:전역진입, 5:전역도
착, 99:운행중)
{
“arriveTime” : 도착시간,
“arriveDate” : 도착날짜
}
1분 간격으로 호출하여 데이터 수신,
해당 데이터를 필요한 포맷에 맞게끔 transform

역별 시간표 페이지(네이버 지도)에서 정보 스크래핑
시간표 데이터

1. 정해진 URL 형식으로 쿼리
2. ‘전체 시간표' 클릭
3. 역 시간표 페이지 진입 후 원하는 정보 스크래핑
시간표 데이터 습득 과정

https://pts.map.naver.com/end-subway/ends/web/{역 코드}/home?timemode=
네이버에서 자체적으로 사용하고 있는 역 코드는 매우 불규칙적이며, 공개되어 있지도 않음

189번 1호선 오산역 190번 1호선 진위역 1401번 1호선 송탄역…?
네이버에서 자체적으로 사용하고 있는 역 코드는 매우 불규칙적이며, 공개되어 있지도 않음

100 ~ 20000까지 모두 쿼리를 날려보고 (역, 호선 신설 가능성 고려)
검색결과가 존재하는 숫자,
그리고 그 숫자에 매칭되는 역 이름을
하나의 파일로 저장해보자!
그 후에 저장된 역 코드를 바탕으로
해당 역의 시간표를 스크래핑 하면 될 것 같아!

{ ‘0호선' : [
{
“역 코드" : 000,
“역 이름”: “00역”
}
]}
{
“lineNum”: “00선”,
“weekTag”: “0”,
“inOutTag: “0”,
“stationNm”: “00역",
“arriveTime:
“00:00:00”
}
① ②
역 코드 스크래퍼 역 코드 파일 시간표 스크래퍼 시간표 파일
Overall plan for Scrapping

역 코드 스크래퍼
- BeautifulSoup 라이브러리 활용
- 100부터 20000까지 쿼리
- 역 정보가 있다면 코드, 역 이름 저장
- 역 정보가 없다면 continue
- 호선, 역 신설에 강건하게 대응할 수 있도록 설계
- ‘subway_information.json’ 파일에 데이터 최종 저장
Scrapper with Python
시간표 스크래퍼
- BeautifulSoup, Selenium 라이브러리 활용
- ‘subway_information.json’에서 역 코드, 이름 정보 획득
- 호선 별로 당일 역 시간 표 정보 저장

Amazon EventBridge AWS Lambda Amazon S3
Trigger
(Every 5:00, 5:30)
Upload
Scrapping
로컬 환경의 비효율성, 불안정성 개선
- 스크래퍼 2개 합쳐 하루에 최대 30분 실행
⟹ Lambda 사용
- 약 4달 동안 매일 오전 5시에 코드 실행 필요
⟹ EventBridge로 스케쥴링
- 팀원들 간 스크래핑 결과물(json) 공유 기능 필요
⟹ S3 이용
자동화 with AWS

Limitations of AWS Lambda
Lambda Timeout
최대 15분
(콜드 스타트로 실제 가용 시간은 더 적음 ...)
Computing Power
최대 10,240MB 메모리
(하지만 3,008MB 최대였음...)

Limitations of AWS Lambda
하지만 내 코드는 10코어 CPU, 16GB RAM에서 30분 이상 돌아가는 걸..?
🤔
Lambda Timeout
최대 15분
(콜드 스타트로 실제 가용 시간은 더 적음 ...)
Computing Power
최대 10,240MB 메모리
(하지만 3,008MB 최대였음...)

Scrapper with Multiprocessing
첫번째 시도: Python with Multiprocessing
- Multiprocessing 적용하여 병렬처리
- 시간표 스크래퍼의 경우 부분 적용 (webdriver 이슈)
⟹ Timeout은 충족하나 Lambda 위에서는 OS 에러 발생

Scrapper with Golang
- Goroutine을 활용한 경량화 스레드에서의 병렬처리
- 역 코드 스크래퍼: Goquery 라이브러리 이용
- 시간표 스크래퍼: Goquery + Chromedp 라이브러리 이용
두번째 시도: Golang
첫번째 시도: Python with Multiprocessing
- Multiprocessing 적용하여 병렬처리
- 시간표 스크래퍼의 경우 부분 적용 (webdriver 이슈)
⟹ Timeout은 충족하나 Lambda 위에서는 OS 에러 발생
⟹ Timeout 충족 + OS 에러 미발생

Performance Improvement
Python (plain) Python (with Multiprocessing) Go
역 코드 (쿼리 당) 0.1s 0.02s 0.002s
시간표 (역 당) 13s 1.75s 0.21s
역 코드 스크래퍼: 처리 속도 약 50배 향상 (쿼리 당 0.1s→ 0.002s)
시간표 스크래퍼: 처리 속도 약 62배 향상 (역 당 13s→ 0.21s)
⟹ EC2가 아닌 Lambda를 사용하여 서버 비용 절감
+ 경량화 스레드로 인한 낮은 컨텍스트 스위칭 비용

04 데이터 파이프라인 - CI/CD
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Data
Transform
Publish

GitHub Actions를 통한 Docker Image 배포 자동화
시간표 크롤러에서 사용한 chromedp 경우 chrome 프로세스를 띄워야 함
Lambda 위에서 chrome을 띄울 수 있도록 Docker Image 구성 필요
(+ 겸사겸사 다른 스크래퍼도 Dockerize)

GitHub Actions를 통한 Docker Image 배포 자동화
Docker Image
Build, Tag
Configure
AWS Credentials
Image push to ECR
Deploy Image
to Lambda
사람이 하나하나 직접 실행 ⟹ GitHub main 브랜치 push 시 자동으로 모든 프로세스 진행

04 데이터 파이프라인 - 모니터링
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Data
Transform
Publish

04 데이터 파이프라인 - 모니터링
Lambda 실행 중 사용자가 설정한
임계 값을 벗어났을 경우 알람
(ex. 에러가 1회 이상 발생했을 경우)
Publisher
(Amazon Cloudwatch)
Amazon SNS SNS Topic Message filtering
and fanout
Subscribers
(email, Lambda)
Cloudwatch가 알람(메시지)을 보내면
SNS는 메시지를 주제(Topic)에 전송
SNS를 구독하고 있는
구독자들에게 메시지 전송
Cloudwatch & SNS를 활용한 에러 리포팅

04 데이터 파이프라인 - Transformer
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Data
Transform
Publish

- Data Lake 형태로 필요한 정보를 가공하지 않고 저장
- 서로 다른 프레임워크에서 활용하기 위해 가공 작업 필요
- Amazon S3 버킷에서 정제 후 다른 S3 버킷에 적재
Amazon S3 Amazon S3

04 데이터 파이프라인 ELK Stack
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Data
Transform
Publish

ELK = Elasticsearch + Logstash + Kibana
: 사용자에게 모든 시스템과 애플리케이션에서 로그를 집계하고 이를 분석하며
애플리케이션과 인프라 모니터링 시각화를 생성하고, 빠르게 문제를 해결하며 보안 분석할 수 있는 능력을 제공
- Elasticsearch
: Apache Lucene(아파치 루씬) 기반의 java 오픈소스 분산 검색 엔진.
방대한 양의 데이터를 신속하고 거의 실시간으로 저장, 검색, 분석 가능.
- Logstash
: 여러 소스에서 동시에 데이터를 수집하여 변환 후 Elasticsearch 서버로 전송하는 데이터 처리 엔진.
- Kibana
: 분석한 내용을 차트와 그래프 등을 활용하여 시각화 가능한 툴

Kibana
Elasticsearch
Logstash
데이터 가공 및
인덱스 생성
데이터 검색 및 분석
데이터 시각화
데이터 전처리
ELK 도입 목적
- Elasticsearch를 통해 대용량 데이터 검색, 최종적으로는 데이터 간 비교 연산, 분석
- Kibana를 활용한 시각화를 통해 다양한 인사이트를 도출
데이터 전송
Amazon S3

Logstash → Elasticsearch
Logstash를 활용하여 Amazon S3의 Data를
원하는 구조의 index로 재구성하여 Elastic Search에 적재
인덱스 내부 구조
timetable_230601
{
“inOutTag: “0”,
“weekTag”: “0”,
“stationNm”: “00역",
“dataType”: “timetable”,
“arriveTime”: “yy-mm-ddT00:00:00”,
“lineNum”: “00선”,
…
}
Logstash

- Elasticsearch의 RESTful API를 활용한 HTTP
요청을 통해 데이터가 원하는 형태의 인덱스로
저장됨을 확인
- 각각의 인덱스는 약 20만개의 요소를 담고 있음
Elasticsearch

- 데이터 구분, 시각화를 위한 데이터 뷰 생성
- timetable (당일 지하철 도착 시간표)
- realtime (실시간 열차 도착 시간)
- 각 데이터 뷰는 약 600만개의 데이터로 구성
- (6월 1일 ~ 6월 30일 데이터 기준)
Elasticsearch

- Filter 기능을 활용하여 쉽게 검색 가능
Elasticsearch

Kibana

Query DSL로 필드 간 비교 연산 수행 시 에러 발생
Limit of Using Elasticsearch

Limit of Using Elasticsearch
- Query DSL을 통해 실시간 지하철 데이터와 지하철 시간표 데이터의 도착 시간 차이 분석 시도
- Elasticsearch는 필터를 이용한 빠른 검색에 용이
- 하지만, 원하는 데이터 간 비교 연산(특히 대규모 비교 연산)은 실질적으로 불가능
- SUM, AVERAGE 등의 집계 연산은 가능하나, 특정 필드 간의 (수리적인) 비교 연산은 불가
(수리적인 비교 연산을 하기 위해선 데이터의 조건 하나하나 직접 필터링 부분에 적어서 비교해야 함)
⟹ 비교 연산, 분석의 경우 BigQuery를 이용하는 것으로 변경
⟹ 저장된 데이터를 파악(ex. 지하철 역 별 열차가 지나간 횟수, 시간 별 열차가 지나간 횟수 등)에 ElasticSearch, Kibana 이용

04 데이터 파이프라인 - BigQuery & Looker Studio
Push
AWS Lambda
AWS Lambda
AWS Lambda
공공 API
Rule
Amazon S3
Kibana
Elasticsearch
Logstash
Amazon Cloudwatch
(Alarm)
Amazon SNS
(Topic)
Developer
Developer
Email, Slack
Notification
Data
Transform
Publish

- BigQuery
: 구글이 제공하는 클라우드 기반 데이터 웨어하우스
대용량의 데이터를 빠르고 강력한 쿼리로 분석할 수 있음
- Looker Studio
: 데이터 분석 및 시각화를 위한 클라우드 기반 비즈니스 인텔리전스 도구
사용자들이 데이터를 쉽게 이해하고 시각화하여 인사이트를 얻을 수 있도록 지원하는 서비스

BigQuery Looker Studio
Amazon S3
BigQuery omni로
데이터 전송
데이터 전처리
데이터 시각화
BigQuery 도입 목적
- ELK stack만으로는 지하철 지연 분석이 어려움
- BigQuery를 도입하여 지하철 도착 정확도를 분석, Looker Studio를 연동하여 시각화
JSON to Table

당일 시간표 데이터에
DATE 필드 추가
시간표 데이터 전체 병합
&
실시간 데이터와 비교하여
accord 필드 추가
실시간 열차 도착 데이터의
arriveTime 필드 ‘초’ 정보
00으로 통일
실시간 지하철 도착 시간이 당일
시간표와 일치하는 경우
accord = 1 ( default = 0 )
1. 당일 시간표 데이터 전처리
2. 실시간 열차 도착시간 데이터 전처리
3. 데이터 비교 및 결과 도출1 - 전체 데이터

호선 별 지하철 운행 정확도 도출 시간대 별 지하철 운행 정확도 도출
( timetag 는 24시간을 2시간 단위로 분할한 정보.
time1, 2, ..., 12 )
요일 별 지하철 운행 정확도 도출
( weekDay 는 요일 정보. 월, 화, …일 )
4. 데이터 비교 및 결과 도출2 - 호선, 시간, 요일 별 데이터

Looker Studio

05 결과 도출 및 시각화
ELK, BigQuery & Looker Studio

05 결과 도출 및 시각화 ELK Stack
- timetable 데이터를 통한 호선별 역개수 시각화
- 호선 개수 비교를 한눈에 확인 가능

- 6월 한달 동안의 지하철 역 별 열차가 지나간 횟수
- 막대그래프 및 워드클라우드로 시각화

- 시간 별 열차가 지나간 횟수를 heatmap으로 표현
- 색깔이 짙을 수록 그 시간에 열차가 많이 지나 간 것
- 평일에는 16시~18시 사이에 열차가 많음을 알 수 있음

05 결과 도출 및 시각화 - BigQuery & Looker Studio
- 날짜 별 지하철 운행 추이
- 지하철 도착 정확도
: 특정 날짜를 선택하여 해당 날짜의 지하철 도착 정확도
확인할 수 있음.
- 날짜 별 지하철 운행 수
: 주말과 공휴일에 상대적으로 운행 지하철 수가 적은
것을 알 수 있음.

- 지하철 호선 별 도착 정확도 (정확도 높은 순 정렬)
: 9호선과 2호선의 정확도가 매우 낮음…!
심지어 경의중앙선보다..?
- 주요 호선(1~9호선)의 도착 정확도 및 운행 열차 수
: 도착 정확도 Line chart
운행 열차 수 - Bar chart
: 특정 호선을 선택하여 해당 호선의 지하철 도착 정확도
확인할 수 있음.

- 지하철 도착 정확도 BEST / WORST TOP 5 시간대
: 06~08시 가 가장 정확도가 높음
01~04시 (새벽 time) 가 가장 낮음
- 시간대별 지하철 도착 정확도 추이
: 시간대는 24시간을 2시간 간격으로 나누어 time1,
… ,12로 설정함 (단, 2~4시는 운행 열차가 없어 0~1,
1~4시로 설정)
: 특정 시간대를 선택하여 해당 시간대의 지하철 도착
정확도 확인할 수 있음

- 요일 별 지하철 도착 정확도 순위
: 화요일이 BEST
토요일이 WORST
: 특정 요일을 선택하여 해당 요일의 지하철 도착 정확도
확인할 수 있음
- 요일 별 지하철 도착 정확도 (feat 요일 별 전체 운영 열차 수)
: 제 시간에 도착한 열차 수 확인 가능
- 요일 별 지하철 운행 수
: 전체 열차 수 확인 가능

06 의의 및 한계
의의
- 파이프라인을 구축하는 과정에서 다양한 기술 스택 경험
- 실시간 데이터 및 대용량의 데이터(600만 건) 핸들링 경험
- 각 스택(ELK, Big Query)별 다른 용도에 대한 이해
한계
- 파편화된 파이프라인 통합 관리 솔루션(ex. Airflow) 부재
- Git 활용에 대한 아쉬움

제 18회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [이탈리안 BMT] : 지하철 지연 시간 데이터 분석 및 시각화를 위한 데이터 파이프라인 구축

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 제 18회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [이탈리안 BMT] : 지하철 지연 시간 데이터 분석 및 시각화를 위한 데이터 파이프라인 구축

Similar to 제 18회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [이탈리안 BMT] : 지하철 지연 시간 데이터 분석 및 시각화를 위한 데이터 파이프라인 구축 (20)

More from BOAZ Bigdata

More from BOAZ Bigdata (20)

제 18회 보아즈(BOAZ) 빅데이터 컨퍼런스 - [이탈리안 BMT] : 지하철 지연 시간 데이터 분석 및 시각화를 위한 데이터 파이프라인 구축