Page History

분석에 사용되는 데이터의 종류

• 시스템로그
• 어플리케이션로그
• RDB에 적재된 중요 적재된  데이터
• 사용자유입및 트래킹로그
• 중요이벤트(결제,취소등)
• 크롤링데이터: 내부서비스에서 생산하지 못하는정보  

시스템로그와 어플리케이션로그를 간과하는 경우가 많습니다. 로그 설계가 잘되어있으면

중요이벤트및 성능향상을 위한 유입측정등 많은 분석이 가능합니다.

성능을 위해 로그레벨을 경고이상에서만 적는다.란 정책이 아무렇지 않게 결정되는것을 봤으며

이것은 아주 무지한 정책입니다. 당연히 시스템로그와 인포레벨의 어플리케이션로그는 실제로

가장큰 빅데이터가 되며, 정의한것만 빅데이터화를 한다고하면 분석의 대처가 늦어져서 

실제로 쓰임새가 있기까지 오랜시간이 걸리게됩니다. 빅데이터의 원초 목적은 이것이 쓸모있는가?

없는가? 파악이안되는 모든 데이터를 가지고 의미있는 데이터로 분석을 하는과정이라고 봅니다. 

그래서 저장소및 분석툴을 각각 전략별로 분리를하고 그것을 다시 통합하여 분석할수 있는

분석툴이 있어야된다라고 봅니다.  

저장소분리

• RDB
• 시스템로그
• 어플리케이션로그
• 트래킹및 유입로그 + 기타수집로그

도메인별로 중요도는 다르며 RDB에 저장되는 데이터가 항상 중요하다라고 볼수 없습니다.

사용자정보를 가지고 있지않고, 이용 키워드를 수집하고 분석하는 트랜드를 제공하는

서비스라고 가정을 하면 그 서비스는  수집로그가 가장 중요한 데이터입니다.

분석툴

• 엘라스틱서치/Splunk : 주로 어플리케이션 로그를 분석하여 의미있는 데이터를 찾기위한 용도 (BI가 주로사용) 
• OpenNMS : 주로 시스템을 포함한 어플리케이션 모니터링을 위한툴이며 엘라스틱서치와도 연동이 되도록함 (데브옵스가 주로사용)
• SPARK ML/주피터 : 의미있는 빅데이터의 분석을 얼마나 빠르게하고 사용자에게 적절하게 제공할지 고민이 포함된 분석툴 (BA를 포함한 서비스개발자가 주로사용)

FastData

이벤트는 다양한 서비스 경로로부터 생성이되며, 사용자가 클릭한 마우스 클릭한 좌표의 히스토리를 데이터화 할수도 있습니다.

이것을 어느시점까지 모아두고 처리할까란 주제이며  배치보다는 빠르게 소비하고 생산을 해내는 빠른 데이터 처리 방향으로 가고 있습니다. 

주로 Streams을 이용하는 방법과 각기 다른 장치들을 유지하고 통합하는 방법에 대한 고민도 같이 하게 됩니다. 

• Akka Streams
• Spark Streams
• KAFKA

Image Added

위 그림은 라이트벤드 제안의 빅픽쳐의 일부이며, 대부분의 빠른 빅데이터처리란 주제에대해

구성요소가 약간식 다를뿐 위와같은 모습을 가지고 있습니다.

근미래에 더좋은방법이 등장하고 대부분의 기술이 대체될것이지만,

현시점 구글링을 하면 대부분 위와같은 아키텍구성을 만나게됩니다. 

빅데이터를 다룰려면, 한가지 기술만 사용되지 않고 그와 연관된 모든것과 연동을 해야하는 과제가 있습니다.

그렇기 때문에 항상 최신 기술만 사용한다란 의미도 아닙니다. 오히려 과거 기술들을 모두 이해해야 하는 어려움이 있습니다.

결제량별 네트워크 트리픽이란 문제를 풀기위해서 저장소관점에서

결제건수가 있는 저장소와 네트워크 트래픽을 시간별로 저장하는 저장소가 다르며

이것은 OpenNMS와 연동되는 엘라스틱서치의 키바나기능으로 시각화가 가능하며 실제로 중요한 분석결과입니다.

하지만 사용자에게 제공되는 리포팅은 아니기때문에 SPARK이 이용될 필요는 없습니다.

사용자의 결제에따른, 결제전 인기 카테고리혹은 평가글을 분석하여 실시간으로 미리 추천하는 문제를 풀기위해

사용자의 액션에 반응하여 빅데이터를 매번 분석하는것은 올바르지 않습니다.

SPARK는 분석해야할 타이밍및 범위 그리고 그것을 어떻게 흘려보내고 다시 러신머닝을 시킬것인가? 의 기능 제공을 해줍니다.