Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tip
title새 문서 공간에 오신 것을 환영합니다!


빅데이터를 다루는 기술및 툴들과 다양한 오픈스택과

그것을 다시 이용하는 AI기술들을 정리하는 공간입니다.기술들을 가볍게 정리하는 공간입니다.


빅데이터와 관련된 오픈스택역시 설치형에서 , 클라우드 SASS의 대세로 복잡고 어려운 기술을 단순하게 사용할수 있는 방법은

계속 증가하고 있지만, 빅데이터를 활용한 빅데이터와 관련된 도메인은 점점 복잡해지고 있습니다. 

도메인의 복잡성을 이해하고 줄이는 방법은 단순하게 최신 기술 스택을 선택한것에 끝나지 않습니다.

과거의 모든 기술을 이해해야하고, 복잡성을 줄이기위해 선택과 조합을 해야합니다. 이것을 아키텍처라고 합니다.

엑셀을 모르고 통계를 다룬다는것은 있을수 없는일이고, SQL을 모르고 NOSQL을 하는것 역시 있을수 없는일입니다.

NOSQL은 SQL을 쓰지 않겠다는 의미가 아닙니다. SQL만을 쓰지 않겠다는 의미입니다. 


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

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

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

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

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

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

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

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

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

시스템로그도 빅데이터이기때문에 이것을 떨어트려놓고 모니터링 목적으로만 사용할필요가없습니다.

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

분석방법및 분석툴이 있어야된다 라고 시작한 컨셉입니다. 

저장소분리

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

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

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

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

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


분석툴

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

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

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

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

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

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

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

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

서로다른 기술의 상호연동

FastData

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

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

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

  • Akka Streams
  • Spark Streams
  • KAFKA


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

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

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

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


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

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

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

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

그래서 빅데이터 관을 올바르게 이끌어주실 키보드 워리어를 수배중에 있습니다. 그렇기 때문에 항상 최신 기술만 사용한다란 의미도 아닙니다. 오히려 과거 기술들을 모두 이해해야 하는 어려움이 있습니다.



이 문서 검색

Livesearch
spaceKeybdata

인기있는 주제

Popular Labels
spaceKeybdata
count10


특별 페이지

Content by Label
showLabelsfalse
spacesbdata
showSpacefalse
sorttitle
typepage
cqllabel = "featured" and type = "page" and space = "bdata"
labelsfeatured

최근에 변경된 페이지

Recently Updated
typespage
max5
hideHeadingtrue
themeconcise