1. OLAP
Online Analytical Processing 의 약자입니다. 온라인에서 데이터를 분석 처리 한다는 거죠. OLAP은 결국 Cube로 귀결됩니다. 연관성 분석이 목적이니까요 ㅎㅎ....cube = 소규모 집계를 통해 상위 집계나 하위 집계를 도출할 수 있도록 만들어진 데이터 집합입니다.
스타스키마와 큐브
자세히 보면 팩트 테이블은 지역, 날짜, 제품의 고유id를 갖고 있으며 판매량을 갖고 있습니다. 즉 팩트인 영업 테이블은은 시간, 지역, 제품에 따른 판매량 데이터를 갖고있다는 이야기가 됩니다.
지역에 따른 판매량을 집계 하려면
select
지역명, sum(판매량) 판매량
from
지역, 영업
where
지역.id = 영업.id
group by 지역명
지역명, sum(판매량) 판매량
from
지역, 영업
where
지역.id = 영업.id
group by 지역명
날짜에 따른 판매량을 집계 하려면
select
일자, sum(판매량) 판매량
from
날짜, 영업
where
일자.id = 영업.id
group by 일자
이런식으로 단일차원의 집계를 만들 수 있습니다.일자, sum(판매량) 판매량
from
날짜, 영업
where
일자.id = 영업.id
group by 일자
다차원 집계의 경우
지역, 날짜, 제품 에 따른 판매량을 집계 하려면
select
지역명, 주, 제품명, sum(판매량) 판매량
from
영업, 지역, 날짜, 제품
where
영업.id = 지역.id
and 영업.id = 날짜.id
이런식으로 작성을 할 수 있습니다. 결국 하나의 테이블에 각각의 디맨전에 해당하는 데이터를 몰아 놓고 인덱싱 한것과 큰 차이는 없는겁니다.지역명, 주, 제품명, sum(판매량) 판매량
from
영업, 지역, 날짜, 제품
where
영업.id = 지역.id
and 영업.id = 날짜.id
and 영업.id = 제품.id
group by 지역명, 주, 제품명
개념상 이런 형태를 띠고 있다는 것이지 실제로는 한 테이블에 지역, 날짜, 영업, 제품들의 각각 정보를 때려 넣고 그룹핑하고 인덱스를 걸었다고 해서 큐브가 아니라고 말 할 수도 없습니다. 엄밀한 의미로 따지자면, 관계연산을 통해 다양한 분석을 도출해내지 못하는 한 테이블 때려 넣기는 큐브로 취급하기 무리가 있습니다. 그리고 데이터가 무거워집니다. 분석하지 않는 대상도 먼저 들어가 있기 때문이죠.
OLAP은 4가지 유형의 분석 작업을 기본으로 합니다.
1. 롤업
롤업은 작은 단위의 데이터를 상위 데이터로 합쳐서 계산하는 겁니다. 예를 들자면 한국의 1,2,3,4분기의 데이터를 합치면 한국의 1년간 판매량을 뽑을 수 있습니다.2. 드릴다운
롤업의 반대 개념으로 1,2,3,4분기의 큰 개념을 월 단위로 쪼개어 집계하는 것이 드릴다운 입니다.3. 슬라이스
큐브의 특정 분기의 데이터만 필터 하는 것이 슬라이스 개념입니다.4. 피벗
분기단위 제품 판매량을 제품 판매량 별 분기로 바꾸는 가로 세로를 전환하는 형태의 집계를 피벗이라고 합니다.결국 이런 형태를 모두 지원하려면 세분화된 집계 기준으로 데이터를 세분화 하고, 상위 개념으로 데이터를 합해 큰 집합을 만들 수 있지만, 이미 큰 기준으로 큐브를 생성했다면, 작은 단위로는 분할할 수 없습니다.
그래서 큐브는 결국 작은 단위 집합이라고 표현 한 겁니다. 알고 보면 정말 별거 없습니다.
2. OLTP
Online Transaction processing 온라인 트랜잭션 처리. 이름에서 보듯이 이건 올랩보다 더 별거 없습니다.트랜잭션 = 데이터 처리의 가장 작은 단위로 여러 단위 SQL로 이루어져 있을 수 있다.
원자성, 일관성, 고립성, 지속성(영속성) 을 가져야 한다.
트랜잭션 성질 ACID 위키백과 클릭
간단히 말하면 잘 저장되고, 잘 가져오고 온라인에서 데이터를 주고받는 일이 문제없이 일어나야 한다는 게 트랜잭션입니다.
그리고 이런 처리가 정상적으로 이루어지기 위해서는 어느 정도의 성능이 뒷받침돼야 합니다.
예를 들어 돈을 100만원 송금하는데 10분이 걸린다고 하면, 10분 동안 컴퓨터를 켜놔야 하는데 실수로 송금 창을 닫을 경우 트랜잭션은 정상적으로 처리가 되지 않겠죠?
그래서 OLTP에서는 트랜잭션 처리 속도가 성능 기준으로 작용합니다. 뭐 OLAP에서도 처리 속도가 중요하기에 큐브 같은 서브집계 개념이 나온 거긴 합니다.
결국 온라인 환경에서 트랜잭션 처리는 빨라야 합니다. 왜 트랜잭션 성질에 아직도 몇 초 이내의 처리 성능을 가져야 한다는 정의가 들어가지 않는지 모르겠습니다.
속도가 결국 중요하기에 OLTP 시스템은 빠른 응답을 위해 사용자 요청에 즉각 반응하는 처리를 말하기도 합니다.
한국인이 빨리 빨리 문화가 이해가 안된다고 하는 외국인들이 있다는 말을 들었는데.. 전 어딜 봐도 그런 사람을 못 봤습니다. IT세상은 속도가 생명이니까요. 외국인도 '빨리 빨리해' 란 한국말을 알더군요.
3. 그럼 빅데이터는 ?
지난 장에 이야기 한 것처럼 빅데이터는 기존 RDB로 처리하기엔 너무 비싸거나 너무 양이 많거나 한 데이터도 있지만, NO-SQL이라는 SQL을 지양하는 플랫폼도 있습니다. 또한 기존의 XML파싱에서 벗어난 JSON데이터 타입의 형태로 데이터를 저장하는 경우도 많습니다.따라서 빅데이터를 정의하는 건 그냥 RDBMS에서 처리하지 않았던 것들은 다 BIGDATA 다 라고 할 수 있습니다.
ORACLE에서는 빅데이터는 전례 없이 빠른 속도로 쏟아져 나오는 다양한 종류의 데이터라고 정의하고 있습니다.
즉. "비정형이다. 데이터 량이 엄청난 속도로 증가한다." 라고 할 수 있습니다.
빅데이터는 그 규모가 기존의 데이터와 다르기에 표준화 할 수 없고, 처리할 수 없는 것처럼 여겨져 왔습니다. 하지만 최근 10여 년간 아파치 프로젝트에서 빅데이터를 처리할 수 있는 다양한 플랫폼을 개발 중이고, 기술의 완성도도 어느 정도 올라온 상태입니다.
초기의 빅데이터가 데이터의 처리 즉. 저장, 검색에 머물렀다면 5년 전부터는 오픈소스를 통한 빅데이터의 시각화도 가능해졌으며, 최근에는 OLAP 형태의 분석까지 가능해졌습니다.
기술의 완성도가 올라갈수록 쓰고 싶어 하는 사람과, 써야 하지만 쓸 수 없었던 사람들의 수요가 증가하는 추세에 있기에 앞으로 점점 더 인기가 있어질 전망입니다.
오늘도 이상입니다. 다음 장에서 찾아뵙겠습니다.
읽어주셔서 감사합니다.
빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.
댓글 없음:
댓글 쓰기