위 자료는 BOAZ 2016 프로젝트 주제의 하나로, Advanced 정규세션 동안 Base 정규세션에서 배웠던 다양한 이론들과 기본 지식들, 그리고 툴 활용능력들을 직접 실행하며 진행한 결과물입니다.
*** 회귀 분석 및 시뮬레이션 모델에 기반한 웹서비스 제작 ***
카페의 지점별 데이터를 바탕으로 시간당 판매량에 대한 회귀식을 도출하고, 이를 대기행렬 시뮬레이션에 반영하여 예상 대기시간 및 대기인원을 실시간으로 분석하는 프로그램 제공
박경록 서강대학교 경영학과
김도연 단국대학교 응용통계학과
이창준 성균관대학교 통계학과
임수만 서울시립대학교 통계학과
홍성근 중앙대학교 컴퓨터공학과
** 국내 최초 대학생 빅데이터 연합동아리 BOAZ **
Blog : http://BOAZbigdata.com
Facebook : http://fb.com/BOAZbigdata
11. 환자 차량 부품
의사 신호 노동자
진료 통제 조립
대 기
행 렬
1. 생활 속의 대기행렬
음료를 주문한 고객
쥬 시
믹서기 모터
음료 제공
12. 대 기
행 렬
2. 대기행렬의 각 요소들
도착 특성
도착률 분포
포아송
기타 (지수분포 등)
도착 패턴
랜덤형
계획형
투입량
제한
무제한
도착유형
서비스까지 기다림
Balk & Renege
13. 도착 유형에 따라
Number of arrivals / time : 포아송
Inter-arrival time : 지수분포
Balk : Line was too long!
Renege : I give up!
서비스 유형에 따라
Service time : 지수분포
때로는 포아송 쓰기도
대 기
행 렬
2. 대기행렬의 각 요소들
14. 대 기
행 렬
2. 대기행렬의 각 요소들
대기열 특성
대기열의 길이
제한
무제한
서비스 원칙
FIFO
기타
15. 대 기
행 렬
2. 대기행렬의 각 요소들
서비스시설 특성
채널의 수
단일
다중
채널당 단계
단일
다중
서비스 시간 분포
음의 지수분포
기타
16. Single-channel, Single-phase system
Single-channel, Multi-phase system
Multi-channel, Multi-phase system
대 기
행 렬
3. 대기행렬의 유형
Service 떠남도착
떠남도착 Phase 1 Phase 2
떠남도착
Phase 1
Channel 1
Phase 1
Channel 2
Phase 2
Channel 1
Phase 2
Channel 2
17. 대 기
행 렬
3. 대기행렬의 유형
Channel 1
Channel 2
Channel 3
Channel 4
대기행렬
(음료 기다림)
서비스 시설(믹서기 모터)
떠남
도착
(결제 직후)
쥬시의 대기행렬은 주문대기와 수령대기로
원칙적으로는 Single & Multi-channel, Multiphase system 에 가까우나,
주문대기 시간이 짧은 관계로 수령 대기행렬만 감안하기로 하였다.
뀨잉뀨잉의 대기행렬 모델은
Multi-channel, Single-phase system
위 모델에서는 Balk와 Renege가 드물다.
M/M/4
매장마다 4개 보유
1인 1음료 가정
18. 대 기
행 렬
4. 대기행렬 모형의 가정
FIFO
먼저 들어온 순서대로
제공된다.
도착은 독립적
도착은 이전의 도착과는
독립적이다.
도착은 포아송
도착률은 포아송 확률
분포에 의해 설명되며,
고객들은 매우 많은
인구에서 온 것이다.
서비스도 독립적
서비스 시간은 고객마다
다양하며 독립적이다.
평균은 알려져 있다.
음의 지수분포
서비스 시간은
음의 지수 확률 분포에
의해 설명된다.
서비스 > 도착
서비스 비율은
도착 비율 보다 크다.
19. 대 기
행 렬
4. 대기행렬 모형의 가정
FIFO
먼저 들어온 순서대로
제공된다.
도착은 독립적
도착은 이전의 도착과는
독립적이다.
도착은 포아송
도착률은 포아송 확률
분포에 의해 설명되며,
고객들은 매우 많은
인구에서 온 것이다.
서비스도 독립적
서비스 시간은 고객마다
다양하며 독립적이다.
평균은 알려져 있다.
음의 지수분포
서비스 시간은
음의 지수 확률 분포에
의해 설명된다.
서비스 > 도착
서비스 비율은
도착 비율 보다 크다.
조사 결과 서비스 시간(음료 제공 시간) 평균은 4분이며 변동이 적다.
다만, 주문이 누적될수록 시간 단축 효과가 있어 반영해야 한다.
시간당 고객 도착을 알아내면 시뮬레이션이 가능하다.
31. 시간
시스템 내 시간 호출
오전
8 ~11
오후
11 ~ 17
저녁
17 ~ 22
프로그램에서는 실시간으로 받아오지만
회귀분석 처리에서는 유동인구 데이터 문제로 범주형으로 간주한다.
회 귀
분 석
2. 데이터 가공
32. 유동인구
스마트 서울앱 데이터 수집
균일분포의 상한, 하한을 연도의 최대, 최소 값으로 놓고 랜덤추출
회 귀
분 석
2. 데이터 가공
33. 기온
기상청 데이터 실시간 크롤링
회 귀
분 석
2. 데이터 가공
전처리
| Pearson Residual | > 2 동일시간 or 온도 대비
판매량이 매우 크거나, 작은 것 제거
34. 강수 여부
범주형으로 직접 입력
회 귀
분 석
2. 데이터 가공
Q. 강수량이 아니라 범주형인 강수 여부로 정한 이유?
A. 3월에서 5월사이의 강수를 보게 되면 비가 온 횟수가 적고, 강수량이 적기 때문에 강수량으로
판단하기 보다는 강수의 유무로 판단하는 것이 더 좋은 결과를 얻을 수 있다고 생각했다.
A. 강수는 밖에서 기다릴 때 영향을 미치는데, 이는 양의 문제가 아니라 강수 여부의
문제이기 때문이다. 실제로 강수 여부가 더 유의미하게 나왔다.
35. 회 귀
분 석
3. 회귀분석 및 평가
GLM
log(판매량) = α + β1기온 + β2유동인구 + β3강수 + β4시간
랜덤성분(RC) : y~poi
체계적성분(SC) : 일차선형
연결함수(LF) : log
Value/DF 0.88 유의수준 0.05하에서 변수들이 유의함
평가
36. 유동인구 1명
증가 시
판매량 약 0.03% 증가
기온 1℃
증가 시
판매량 약 0.16% 증가
비가 오지 않은 날
오는 날 대비
판매량 약 3.7% 증가
회 귀
분 석
4. 회귀분석 결과
log(판매량) = 4.1392 + 0.0017기온 + 0.0003유동인구 + β3강수 + β4시간
48. 시 뮬
레 션
STEP 1. 크롤링 및 회귀분석
Nokogiri
Open-uri
시스템 내
시간 정보
입력한 날씨,
지점 정보
기상청 기온
크롤링
유동인구
범주 체크
실측값 최대최소 범위 내
균등분포로 유동인구 뽑아냄
지점별 회귀식 변수에 넣어 시간당 판매량 계산
(시간당 고객 도착 평균)= 시뮬레이션 시간(60) / 시간당 판매량λ
사용자의
입력
3단계(시뮬레이션 단계)로 전달
49. 시 뮬
레 션
STEP 2. 균등분포 및 지수분포 함수
유동인구 실측 값의 최대 최소 범위 내에서 유동인구를 뽑아낼 균등분포를 발생시키는 함수 코딩
도착시간과 서비스 시간을 누적할 때마다 불러올 지수분포를 발생시키는 함수 코딩
균등분포 함수
유동인구 추출
STEP 1에서 요구
도착 시간
지수분포 함수
STEP 1의 값을 기준으로
STEP 3에서 도착 시간
포아송 분포 발생
서비스 시간
지수분포 함수
실측 기준 평균 4.0
도착 시간 빠를수록
서비스 시간 감소
발생범위 0.34 ~ 0.4로 제한
1단계(회귀분석 - 유동인구)와 3단계(시뮬레이션 단계)에서 호출이 있을 때마다 실행
50. 시 뮬
레 션
STEP 3. 시뮬레이션 단계
0에서 시작하여 60분이 될 때까지 시간을 누적시키며 시뮬레이션 합니다.
도착
서버1
서버2
서버3
서버4
0 60
도착 간격은 지수 분포로 발생시킴
버퍼 서버 수를 초과하면 버퍼로 이동 비어있는 서버에 바로 들어간다
도착해서 떠나기까지 걸린 시간
누적 대기인원 계산
메인변수 선언 : 처리량(시간당 판매량), 평균 인원, 평균 대기시간
STEP 1 에서 λ 받음 → STEP 2 도착 시간 함수에서 λ 기준으로 지수 분포 발생
① 서버가 비어있으면 서비스 제공 → STEP 2 서비스 시간 함수에서 평균 4.0 기준으로 지수분포 발생
→ 서비스 시간 지나면 떠난 것으로 간주, 서버가 열림
② 서버가 차있으면 버퍼에 쌓임 → 서버 열릴 때까지 대기(누적 인원과 시간 기록) → 서버 열리면 투입
59. 한계점
시뮬레이션 특성상 근사를 목적으로 하지만 정확의 개념과는 거리가 있다.
가능한 모든 변수를 반영하면 오히려 역효과가 나기도 하며 반영할 수도 없기 때문이다.
이러한 시뮬레이션의 특성을 감안하더라도 데이터와 구현 수준에서 제약 조건이 많아
한계가 있었다. (데이터 확보, 계절 반영 불가, 메뉴 다양성 등)
데이터 자체보다는 그것을 가공하고 서비스로 만드는 과정에 주목하셨으면 한다.
아직 Demo 버전이지만 이후 데이터가 추가로 확보되고 전문가에 의해 보완된다면
좋은 서비스로 거듭날 것.