빅데이터 - 분석기술 - 데이터 마이닝 - 시계열 분석(Cross-section Analysis)

[개념] 일정 기간에 대해 시간의 함수로 표현되는 데이터를 통해 문제의 이론적 예측 변수와 해당 현상과의 관계를 분석하는 기법

[특징] 정상성(Stationary) : 과거의 시계열 데이터 분석을 통해 앞으로의 사건을 예측가능

[유형] 자기상관 모형, 이동평균 모형, 자기회귀누적이동평균 모형

[학습] 학습 데이터를 이용해 학습 모델을 생성하여 입력 데이터를 특정 시간의 값으로 예측하는 방식을 사용

1. 정상성(Stationary) : 일관된 평균과 분산(variance)과 자기 상관(auto-correlation) 정도를 보이는 데이터

로그변환과 차분을 통해 정상성을 확보한 후에 자기회귀 모형을 적합

-평균이 일정 : 모든 시점에 대해서 일정한 평균을 가진다.

-평균이 일정하지 않은 시계열은 차분(difference)을 통해 정상화 할 수 있다.

-차분(difference)은 현 시점 자료에서 전 시점 자료를 빼는 것.

-일반차분(regular difference) : 바로 전 시점의 자료를 빼는 것

-계정차분(seasonal difference) : 여러 시점 전의 자료를 빼는 것. 주로 계절성을 갖는 자료를 정상화

-분산도 시점에 의존하지 않음 : 분산이 일정하지 않은 시계열은 변환(transformation)을 통해 정상화

-공분산도 단지 시차에만 의존, 실제 특정 시점 t, s에는 의존하지 않는다.

* 원래 시간의 흐름에 따라 증가 혹은 감소 추세가 있는 현상을 연구할 때, 혹은 계절적, 주기적으로 증감 현상을 보이는 이슈를 연구할 때 그런 자연 발생적인, 혹은 문제의 예측 변 수와 관계 없는 요인들의 영향력을 배제하고 순수한 예측변수의 힘을 보고 싶다는 말

2. 시계열 모형  - 자기상관함수(ACF), 편자기상관함수(PACF)

1) 자기회귀 모형 (AR모형, auto regressive model)

-p시점 전의 자료가 현재 자료에 영향을 줌. (즉, p시점 전의 시계열이 현재 시점과의 공분산이 있다.)

2) 이동평균 모형 (MA 모형, Moving average model)

(1) 유한 개수의 백색잡음의 결합 -> 항상 정상성을 만족

(2) 1차 이동평균 모형(MA(1) 모형) -> 바로 전 시점의 백색잡음의 결합으로 이루어진 모형

(3) 2차 이동평균 모형(MA(2) 모형) -> 바로 전 시점의 백색잡음 + 시차가 2인 백색잡음의

결합.

3) 자기회귀누적이동평균 모형(ARIMA(p,d,q) 모형, autoregressive integrated moving average model)

-ARIMA모형은 비정상시계열 모형. (non-stationary)

-차분이나 변환을 통해 AR모형, MA모형, 이 둘을 합친 ARMA모형으로 정상화 할 수 있다.

-p는 AR모형, q는 MA모형과 관련된 차수

-시계열 {Zt}의 d번 차분한 시계열이 ARMA(p,q) 모형이면, 시계열{Zt}는 차수가 p,d,q인 ARIMA 모형

(https://m.blog.naver.com/PostView.nhn?blogId=projaewon2&logNo=220771157113&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F)

[알고리즘 비교]

- 대상 데이터 : 잡음이 많이 포함된 초음파 센서로부터 입력되는 시계열 데이터 분류

- 유형: 비선형 패턴분류 모델

- 알고리즘 성능 평가 : RF(Random Forest) 와 MLP(MultiLayer Perceptron) 는 SVM 보다 잡음과 Outlier 가 많은 비선형적 데이터에 대하여 높은 성능을 보임

[사례] 넷플릭스

시계열 데이터 - 회원보기 기록

시청 기록 저장소 아키텍처의 첫 번째 클라우드 기본 버전은 다음과 같은 이유로 Cassandra를 사용했습니다.

카산드라 (Cassandra)는 시계열 데이터 를 모델링하는데 좋은 지원을 합니다. 여기서 각 행은 동적 수의 열을 가질 수 있습니다.

시청률 데이터 기록 비율에 대한 읽기 비율은 약 9 : 1입니다. 카산드라는 글쓰기에 매우 효율적 이기 때문에 이처럼 무거운 작업량은 카산드라에게 적합합니다.

CAP 정리를 고려할 때 , 팀은 가용성 손실보다 궁극적인 일관성을 선호합니다. 카산드라는 조정 가능한 일관성을 통해 이러한 상반 관계를 지원합니다 .

Figure 1: Single Table Data Model

Figure 2: Live and Compressed Data Model

Figure 3: Auto Scale via Chunking

(https://medium.com/netflix-techblog/scaling-time-series-data-storage-part-i-ec2b6d44ba39)

예를 들어 실제 세계에서 태양열 에너지 회사는 원격 모니터링 및 배터리 관리를 위해 모든 태양열 패널을 계측한다. 고객의 패널에서 수집된 사용량 정보는 모바일 네트워크를 통해 클라우드의 데이터베이스로 전송된다. 이 데이터는 분석되고 분석에서 도출된 정보는 배터리 수명을 늘리고 제품을 제어하기 위해 각 고객의 시스템을 구성하고 조정하는 데 사용된다. 이상 또는 문제가 감지되면 서비스 담당자에게 경보가 전달되어 더 이상 악화되기 전에 대처할 수 있도록 한다. 따라서 고객 설비의 태양열 에너지 시스템에서 보내는 실시간 데이터를 기반으로 선제적 고객 서비스가 가능해진다.

IT 세계에서는 시스템의 가상 인프라를 자동으로 확장할 시점을 결정하기 위해 이벤트가 측정된다. 예를 들어 기업은 판매 증가 또는 기타 다른 활동을 수용하고자 단시간 동안 클라우드 용량을 늘릴 시점을 파악하기 위해 동시에 일어나는 여러 가지 이벤트(웹 사이트 방문자, 제품 조회, 구매 거래 등)를 상호 연계하고자 할 수 있다.

모든 것을 측정한다는 개념은 데이터를 중심으로 하는 기업이 되고 이벤트, 측정 지표 또는 다른 시간 기반 데이터를 기반으로 더 나은 의사 결정을 내리고 적시에 조치를 취할 수 있게 됨을 의미한다. 기업이 디지털 트랜스포메이션을 사용해서 비즈니스 방식을 바꾸면서 모든 산업에서 이러한 현상이 일어나고 있다.

데이터베이스와 시계열 데이터 : 필수 요소

이 데이터의 상당 부분은 시계열 데이터다. 시계열 데이터에서는 이벤트가 발생하거나 지표가 측정된 정확한 시간을 기록하는 것이 중요하다. 그런 다음 일정 시간에 걸쳐 데이터를 관찰하고 분석해서 시스템 내에서 일어나는 변화를 파악할 수 있다.

시계열 데이터베이스는 수집하고 저장하는 이벤트 또는 지표의 수에 따라 상당히 커질 수 있다. 예를 들어 자율 운전 차량은 매초 방대한 데이터 포인트를 수집하고 평가해 차량의 조작을 결정한다.

카산드라(Cassandra) 또는 MySQL과 같은 범용 데이터베이스는 시계열 데이터에 적합하지 않다. 시계열 데이터를 다루기 위한 전용 데이터베이스는 범용 데이터베이스에는 없는 다음과 같은 기능을 포함해야 한다.

- 데이터베이스는 거의 실시간으로 데이터를 흡수(ingest)할 수 있어야 한다. 일부 애플리케이션(예를 들어 자율 자동차)은 초당 수백만 또는 수억 개의 데이터 포인트를 생성할 수 있으므로 데이터베이스는 이 정도 양의 데이터 흡수를 처리할 수 있어야 한다.

- 데이터베이스를 사용해서 사물을 모니터링하고 제어하려면 실시간으로 데이터베이스를 쿼리할 수 있어야 하며, 쿼리는 지속적으로 실행이 가능해야 한다. 범용 데이터베이스에서 쿼리는 스트리밍이 아닌 배치로 실행된다.

- 데이터 압축은 중요하다. 데이터베이스가 시계열 데이터 전용으로 설계된 경우 비교적 간단히 데이터 압축을 수행할 수 있다.

- 데이터를 흡수하는 만큼 빠르게 방출할 수 있어야 한다. 시계열 데이터는 일주일 또는 한 달과 같이 특정 기간 동안에만 필요하고 이후 버려도 되는 경우가 많다. 일반 데이터베이스는 이렇게 신속하게 데이터를 제거하도록 설계되지 않는다.

- 마지막으로, 전체가 아닌 일부 데이터를 제거하여 “다운샘플”이 가능해야 한다. 예를 들어 ms 단위로 데이터 포인트를 수집하며 약 일주일 동안 이 데이터의 높은 해상도를 유지해야 한다고 가정해 보자. 그 이후에는 대부분의 데이터를 제거할 수 있지만 초당 데이터 포인트 하나의 해상도로 일부를 보관해야 한다. 시계열 데이터의 경우 처음에는 높은 해상도가 매우 중요하지만 이후 장기간 보관을 위해서는 저해상도 데이터로도 충분한 경우가 많다.

시계열 데이터를 겨냥한 오픈소스 프로젝트

인플럭스데이터(InfluxData)의 창업자인 폴 딕스는 이러한 요구 사항에 착안해서 시계열 데이터를 축적, 분석하고 적절한 조치를 취하기 위한 용도의 인플럭스데이터 플랫폼(InfluxData Platform)을 구축했다. 처음에는 인플럭스DB가 포함된 오픈소스 프로젝트인 코어 데이터베이스로 시작했다. 인플럭스DB는 깃허브에서 개발자들 사이에 빠르게 인기를 얻었다. 이후 딕스는 자금을 모아 다음과 같은 세 가지 오픈소스 프로젝트를 더 출범해서 인플럭스데이터 플랫폼을 완성했다.

- 텔레그라프(Telegraf) : 네트워크 디바이스, 애플리케이션, 센서 또는 독립 실행 서버와 같은 사물을 다루는 데이터 수집기다. 모든 데이터를 수집해서 인플럭스DB 데이터베이스로 보낸다. 오픈소스 기여자들이 현재까지 160개 이상의 텔레그라프 플러그인을 만들었다.

- 크로노그라프(Chronograf) : 시각화 엔진으로, 데이터의 그래프를 작성하고 시각화하고 즉석(ad hoc) 탐색을 수행할 수 있다. 데이터가 데이터베이스로 들어올 때 대시보드에서 데이터 차트를 그릴 수 있다.

- 커패시터(Kapacitor) : 커패시터는 데이터베이스의 코프로세서로, 데이터를 근거로 작업을 수행할 수 있게 해준다. 자체 스크립팅 언어와 기능이 있으므로 맞춤형 논리 또는 사용자 정의 함수를 집어넣을 수 있다. 백엔드에 위치하면서 데이터가 들어오는 대로 머신러닝 알고리즘을 실행할 수 있다. 커패시터는 매우 강력한 오픈소스 프로젝트다.

TICK 스택(Telegraf, InfluxDB, Chronograf, Kapacitor)으로 통하는 이 4가지 구성 요소는 시계열 데이터 작업을 위한 강력하고 인기 있는 플랫폼이다. 모든 요소는 개발자를 위한 오픈소스 소프트웨어로 제공된다. 인플럭스데이터는 클러스터링과 고가용성, 강력한 보안이 필요한 프로덕션 시나리오를 위한 클로즈드 소스 상용 버전도 제공한다.

측정을 위해 모든 요소 계측

IoT 세계에는 태생적으로 TICK 스택이 필요하다. 사물 인터넷의 실제 세계에는 방대한 센서가 사용된다. 우리의 인체, 의류, 의료 장비, 산업 설비, 집, 자동차, 모든 것이 시계열 데이터 측정을 위해 계측된다. 이러한 센서는 압력, 온도, 속도, 심박수, 양, 빛 등을 주시하며, 많은 경우 이러한 데이터의 변화에 따라 특정한 조치가 필요하다. 예를 들어 신체 활동 추적기는 심박수를 낮추기 위해 달리는 속도를 늦출 것을 권고할 수 있다. 충돌 방지 시스템이 탑재된 자동차는 자동차가 정지된 물체에 근접하면 자동으로 브레이크를 작동한다. 우리 주변의 온갖 센서는 지속적으로 데이터를 수집하고 모니터링하면서 사람과 프로그램의 의사 결정을 돕는다.

모든 것의 계측은 미래를 향한 길이며, 데이터가 유의미한 시한 내에 그 데이터를 수집, 분석하고 이에 근거하여 작업을 실행하기 위해서는 시계열 데이터베이스와 관련 툴이 필요하다.

또한 IT 세계에서는 시스템 가상화로 인해 인플럭스데이터 플랫폼을 위한 유력한 사용 사례가 탄생했다. 시작은 가상머신이다. 가상머신 덕분에 서버 하나가 아닌 5개를 갖게 됐다. 이후 VLAN이 등장해서 복수의 LAN이 하나의 머신에 있는 복수의 VM과 통신하게 됐다. 이후 컨테이너가 등장해서 이제는 하나의 서버에서 6개의 VM과 40개의 컨테이너를 실행하기도 한다. 그리고 각각의 컨테이너에는 일련의 마이크로서비스가 있다.

정리하자면 전체 소프트웨어 인프라의 단명이다. 모든 것은 가상이고 이식 가능하며 일시적이고 오르내림을 반복한다. 그러나 이러한 시스템 내에서 일어나는 일에 대한 실시간 시야는 여전히 필요하다. 그래서 실시간 상황 데이터, 이른바 관찰 가능성을 제공하기 위해 소프트웨어가 계측되는 것이다. 이는 소프트웨어 인프라와 하드웨어 인프라에서 오는 모든 지표와 이벤트를 캡처해서 한 곳에 저장하는 기록 시스템을 제공한다. 이제 인프라에서 일어나는 일을 보는 것이 가능하다. 걱정스러운 일이 발생하면 이를 인식할 수 있고 시스템에는 관련 기록이 존재한다. 한 걸음 더 나아가 이벤트와 지표를 상호 연계해서 SLA가 충족되거나 충족되지 않는 이유도 알 수 있다.

모든 것의 계측은 미래를 향한 길이며, 데이터가 유의미한 시한 내에 그 데이터를 수집, 분석하고 이에 근거하여 작업을 실행하기 위해서는 인플럭스데이터 플랫폼과 같은 시계열 데이터베이스와 관련 툴이 필요하다.

(http://www.itworld.co.kr/t/54649/%EB%B9%85+%EB%8D%B0%EC%9D%B4%ED%84%B0/108995)

시계열 데이터를 겨냥한 오픈소스 프로젝트

인플럭스데이터(InfluxData)의 창업자인 폴 딕스는 이러한 요구 사항에 착안해서 시계열 데이터를 축적, 분석하고 적절한 조치를 취하기 위한 용도의 인플럭스데이터 플랫폼(InfluxData Platform)을 구축했다. 처음에는 인플럭스DB가 포함된 오픈소스 프로젝트인 코어 데이터베이스로 시작했다. 인플럭스DB는 깃허브에서 개발자들 사이에 빠르게 인기를 얻었다. 이후 딕스는 자금을 모아 다음과 같은 세 가지 오픈소스 프로젝트를 더 출범해서 인플럭스데이터 플랫폼을 완성했다.

- 텔레그라프(Telegraf) : 네트워크 디바이스, 애플리케이션, 센서 또는 독립 실행 서버와 같은 사물을 다루는 데이터 수집기다. 모든 데이터를 수집해서 인플럭스DB 데이터베이스로 보낸다. 오픈소스 기여자들이 현재까지 160개 이상의 텔레그라프 플러그인을 만들었다.

- 크로노그라프(Chronograf) : 시각화 엔진으로, 데이터의 그래프를 작성하고 시각화하고 즉석(ad hoc) 탐색을 수행할 수 있다. 데이터가 데이터베이스로 들어올 때 대시보드에서 데이터 차트를 그릴 수 있다.

- 커패시터(Kapacitor) : 커패시터는 데이터베이스의 코프로세서로, 데이터를 근거로 작업을 수행할 수 있게 해준다. 자체 스크립팅 언어와 기능이 있으므로 맞춤형 논리 또는 사용자 정의 함수를 집어넣을 수 있다. 백엔드에 위치하면서 데이터가 들어오는 대로 머신러닝 알고리즘을 실행할 수 있다. 커패시터는 매우 강력한 오픈소스 프로젝트다.

TICK 스택(Telegraf, InfluxDB, Chronograf, Kapacitor)으로 통하는 이 4가지 구성 요소는 시계열 데이터 작업을 위한 강력하고 인기 있는 플랫폼이다. 모든 요소는 개발자를 위한 오픈소스 소프트웨어로 제공된다. 인플럭스데이터는 클러스터링과 고가용성, 강력한 보안이 필요한 프로덕션 시나리오를 위한 클로즈드 소스 상용 버전도 제공한다.

측정을 위해 모든 요소 계측

IoT 세계에는 태생적으로 TICK 스택이 필요하다. 사물 인터넷의 실제 세계에는 방대한 센서가 사용된다. 우리의 인체, 의류, 의료 장비, 산업 설비, 집, 자동차, 모든 것이 시계열 데이터 측정을 위해 계측된다. 이러한 센서는 압력, 온도, 속도, 심박수, 양, 빛 등을 주시하며, 많은 경우 이러한 데이터의 변화에 따라 특정한 조치가 필요하다. 예를 들어 신체 활동 추적기는 심박수를 낮추기 위해 달리는 속도를 늦출 것을 권고할 수 있다. 충돌 방지 시스템이 탑재된 자동차는 자동차가 정지된 물체에 근접하면 자동으로 브레이크를 작동한다. 우리 주변의 온갖 센서는 지속적으로 데이터를 수집하고 모니터링하면서 사람과 프로그램의 의사 결정을 돕는다.

(http://www.itworld.co.kr/news/108995)

전통적으로 유통업계에서 많이 사용하는 수요예측 방법은 통계학을 응용한 ‘시계열 분석 기법’이다. 상품 판매 추세와 계절 요소, 불규칙 변동 등을 조합해서 미래 판매 수치를 예측한다. 여기에 사람의 ‘직관’이 결합된다. 현장 경력이 오래된 사람이라면 갖고 있는 그 느낌, 바로 그거다.

하지만 전통적인 수요예측 방법론의 한계가 없는 것은 아니다. 예컨대 시계열 데이터를 확보하기 어려운 신제품이나 코로나19와 같은 예측하지 못한 외부 변수가 들이닥쳤을 때 유연하고 빠른 대응이 어렵다는 지적이 나온다. 영업 사원 등으로부터 수기로 전달 받은 원데이터의 신뢰성을 담보하기도 어렵고, 사람의 직관이라는 것도 항상 맞는 것은 아니다.

이 팀장은 “유통회사들이 기존에 써오던 수요예측 방식은 최근 데이터를 집계해서 추세를 화인하고, 그 추세를 연장하여 미래 수요를 예측하는 방식”이라며 “이런 방식은 예측대상이 되는 다음 주 업무환경을 반영하기 어렵고, 단순 추세만을 기반으로 하기 때문에 실상 ‘예측’이라 말하기 어렵다”고 설명했다. 그는 이어 “반면 인공지능 모델은 지난 데이터를 기반으로 특정 상품이 왜 특정 시기에 팔렸는지 파악하는 데 집중한다”며 “그날그날 상품의 팔림새와 환경 변화를 학습하여 어떤 상황에서 상품이 판매되는지 추론할 수 있는 것”이라 말했다.

https://byline.network/2020/11/15-91/

https://www.slideshare.net/awskorea/aws-ai-aws-cloud-week-industry-edition  AWS Cloud Week 2020.11