Page History

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

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

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

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

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

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

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

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

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

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

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

저장소분리

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

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

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

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

RDB는 수집로그분석을  돌리면 다시생성할수 있는 요약 데이터입니다.

분석툴

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

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

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

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

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

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

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

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

서로다른 기술의 상호연동

Image Added

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

구성요소가 약간식 다를뿐 위와같은 아키텍을 가지고 가며 거의 흡사합니다.

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

RDB - 하둡 - SPARK - 머신러닝 로 이어지는 변천사에서 중간과정의 이해없이

SPARK혹은 SPAKML을 먼저 이해하는것은 처음본 SF영화가 스타워즈 라스트 제다이이며

이것만보고 스타워즈 세계관과 여기서에 등장하는 수많은 신규장치들을 이해해야하는 꼴입니다.

그래서 빅데이터 관을 올바르게 이끌어주실 키보드 워리어를 수배중에 있습니다.