빅알자 4.빅데이터 처리 성능. 스토리지 전략

빅데이터나 데이터나 시스템의 처리 성능은 대게 같은 곳에서 시작합니다. 처음은 컴퓨팅 파워. 즉 하드웨어 관점입니다. 이번엔 스토리지 전략에 대해 이야기해보겠습니다. 빅데이터를 저장만 하는 측면에서는 필요가 없고, 분석하고자 하는 시스템에서 필요한 이야기 입니다.

1. 하드웨어 성능 

흔히 컴퓨팅 파워라고 하는 것은 하드웨어의 어떤 부분에서 어떤 성능이 나오느냐를 평가하는 각 부분의 지표가 있지만 데이터 관점에서의 성능은 어떤 속도로 데이터를 읽어드리고, 처리하고 기록하느냐의 관점입니다.

즉, 조회 성능, 정렬 및 그룹화 성능, 기록성능 등이 있겠지요. 뭐 트랜잭션 처리 성능을 평가하기도 합니다.

컴퓨터 구성품 중 속도에 영향을 미치는 항목

그리고 이러한 성능들의 근원은 cpu, disk, memory, bus, network의 5가지 장비의 성능에 기인합니다. 이러한 성능들은 각각의 단위를 갖고 있고, 그 단위 중 일부는 주파수로 공개되고 있어 용량으로 환산할 수 없기에 공개된 기록을 기반으로 각각의 속도에 대해 알아보겠습니다.

데이터 전송 속도 비교

가) 하드웨어의 현재 공개된 최고 쓰기 속도 

장치	초당 읽기/쓰기 속도
CPU	2344.8GB/s
SSD	1.25GB/s
MEMORY(MCDRAM)	460GB/s
BUS	460GB/s
NETWORK	12GB/s

위 표에서 가장 주요하게 봐야 할 점은 SSD 즉 데이터 저장소의 속도가 가장 늦다는 것 입니다. (보편적으로는 500MB/s밖에 나오지 않습니다. ) 가장 속도가 늦는 장치가 데이터를 저장하고 있으니, 보편적인 데이터의 조회 속도는 저장소의 최저 속도가 기준이 될 수밖에 없습니다. 데이터가 메모리에 적재되지 않는 이상 조회도 연산도 할 수 없습니다. 

과거의 RDBMS에서는 이 문제를 해결하고자 메모리를 비대화 시켜 자주 쓰는 데이터는 메모리에 올려놓고, 찾아서 쓰는 방식을 선택했습니다. (HDD 120mb/s가 최고이던 시절) 그리고 스토리지 전략을 통해서 한 번에 여러 노드에서 데이터를 읽는 프로세스를 생각해냈습니다. 이 전략은 지금도 유효합니다. 

2. 스토리지 전략

앞서 설명했던 스토리지 전략의 하나인 RAID입니다. 여러 개의 디스크를 묶어 하나의 디스크처럼 사용할 수 있게 하는 기술이며, 파일 하나를 각각의 디스크에 여러 조각으로 분산시켜 각각의 디스크에서 병렬로 읽게 만들어 읽기 성능을 비약적으로 향상시키는 장치입니다. 

각각의 DISK에서는 500MB/s의 작은 속도밖에 내지 못하지만, 저장 파일을 각 노드에 분산하고, 병렬로 읽고, 결합하여 디스크 하나에서 읽는 속도보다 수배의 속도가 나옵니다.

정확한 원리를 바탕으로 구성된 스토리지 클러스터는 데이터 접근 성능을 크게 향상 시켜 빅데이터의 원활한 처리의 밑거름이 될 것입니다. 

3. 왜 스토리지 전략이 중요한가? 

물론 메모리에 주요 데이터를 올려서 처리하는 메모리 기반 프로세스는 언제고 필요한 전략입니다. 디스크는 메모리를 따라잡을 수 없으니까요. 하지만 스토리지 전략이 가장 기초가 돼야 하는 이유는 메모리를 아무리 늘렸다 한들 빅데이터 전체를 커버 할 수는 없기 때문입니다. 

예를 들자면 이런 겁니다. 가령 센서를 통해서 데이터가 주기적으로 발생한다고 칩시다. 

장치 ID와 특정 값을 발생시키는 태그유형 예 

이 센서 데이터가 1초마다 발생 시 일일 발생 건수는 86,400건 CSV 파일로 치면 약 2MB 매우 작은 양이지만, 연간으로 치면 750MB. 단일 SSD에서 1초에 조회할 수 있는 용량을 넘어버립니다. 그리고 이런 센서는 공장 하나에 수백~ 수천 개가 있기 때문에 연간 누적 데이터양은 100GB를 초월하게 되지요. 저희는 1000개가 넘어서 약 12Tera의 데이터가 쌓입니다. 

100개만 있다고 해도 71GB의 용량을 갖게 됩니다. 이 데이터에 대한 연간 집계를 내려면 데이터를 메모리에 올리는 것도 단일 SSD에서는 142초가 걸리게 되며, 메모리 용량이 충분치 않을 경우 MEMORY와 DISK의 SWAP이 일어나면서 속도는 더 지연되게 됩니다.

하지만 레이드를 통한 분산저장이 되어있을 경우 위 그림과 같이 4GB를 초당 로드한다면 17초로 8.2배의 로드 속도 향상이 발생합니다. SWAP은 동일하게 일어나더라도 읽고 쓰는 속도가 커버할 수 있는 크기가 되죠. 그리고 속도는 더욱 향상될 수 있습니다.

그리고 이 구성을 클러스터 형태로 더 크게 구성할 경우 소수점 이하의 시간 내에 로드가 가능해집니다.

최근 빅데이터 플랫폼 테스트베드의 기준이 되어가고 있는 아마존 AWS의 경우 이러한 처리들이 이미 되어있기에 실제 하드웨어를 구매하지 않고도 표준화 된 성능 테스트를 수행할 수 있기 때문입니다.

저장만 하는 관점에서는 전혀 필요 없지만, 분석이 필요한 시점에는 가장 필요한 프로세스가 됩니다. 

이상 스토리지 전략은 이 정도로 마치겠습니다. 

읽어주셔서 감사합니다. 

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

1.빅데이터 개념잡기
2.OLAP ? OLTP? 빅데이터?
3.빅데이터 도구 어떻게 고를까? - 벤치마크
4.빅데이터 처리 성능. 스토리지 전략

5.빅데이터 처리 성능. 네트워크 전략
6.시계열 DB를 알아봅시다.

빅알자 3.빅데이터 도구 어떻게 고를까? - 벤치마크

1. 빅데이터도 결국 데이터다. 

"데이터를 관리하려면 DBMS (DataBase Management System)이 필요하다."

과거의 DBMS 서버는 데이터 관리를 위해 풀 팩키징 (모든 기능이 집약된) 형태를 띤 반면 현재의 빅데이터 플랫폼은 대체로 그렇지 않습니다. 모두 모듈화, 소형화를 통해 각각 다른 라이브러리를 결합하는 아파치 프로젝트가 제법 주목 받고 있습니다. 대량의 데이터를 빠르게 처리 하는 것이 목적이죠.

따라서 빅데이터의 사용 관점에 따라 모듈을 선택하는 것이 중요합니다.

2. 데이터 분석 관점 

데이터를 분석하는데 있어서 관점이라는 것은 매우 중요합니다.

시간의 흐름에 따른 유동 인구 분포를 계산 할 때, 1분기 매출액을 계산 할 때. 혹은 1년 전과 비교 할 때. 대부분의 관점은 시간에서 시작됩니다.

그래서 나온 것이 timestamp base 빅데이터 DBMS 입니다. 이것들은 데이터를 분석하는 관점의 기준으로 가장 많이 차용되는 시간이라는 속성을 밀리 초 단위로 기록하고 이를 데이터를 구분하는 기준 값으로 활용합니다. 때로는 파티셔닝 마저도 Timestamp를 사용하기도 합니다.

이러한 특성을 가진 빅데이터 처리 프로그램을 현재 시계열 DB라고 합니다.
국내에서는 influxDB, Graphite, OpenTSDB등이 알려져 있지만 Druid 역시 시계열 DB에 속합니다.

그리고 특성을 말로 설명하기 힘든 많은 빅데이터 플랫폼이 있습니다. (대게의 빅데이터는 비정형 분석을 특기로 하기에 구분 짓는 것이 어렵습니다. )

하지만 앞으로 시계열 DB는 대세가 될 것 입니다. 시간은 사람이 개념적으로 사물의 상태를 분할하는 필수 조건 중 하나이기 때문이죠. 사람이기에 시간에 얽매이고, 사람이기에 시간을 살아갑니다. 그리고 인간 모두가 공유하는 개념입니다. 그러므로 시간은 빠질 수 없는 필수 조건이기 때문입니다.

그리고 잡설이지만 그래서 "블랙홀이 시간을 빨아들인다" 라는 생각이 이해가 안 됩니다. 시간은 인간의 개념이기 때문입니다. "그래서 지구의 특정 지역에서 시간이 느리게 가는 것을 확인했다." 라는 말도 말이 안되는 것이죠. 그랬다면 누구나 그 곳에 공장을 짓고 싶어 할 것 입니다.  그리고 그곳의 땅값은 평당 100조원 이상의 가치를 지니게 되겠죠. 제품 하나 만드는데 드는 시간이 다른 곳 보다 적을 테니까요.

3. 성능 관점 - 벤치마크 

빅데이터는 아직도 초기에 불과합니다. 앞으로 더욱 발전하겠지만 지금은 어느 것이 좋다 라며 대세를 자부할 수 없는 상태 입니다. 그래서 벤치마크가 중요합니다. 도입 하느냐 마느냐에 대한 관점을 제공할 수 있으니까요.

빅데이터 벤치마크 결과를 검색해보면 다양한 툴이 존재합니다. 10여개가 넘죠. 그런데 이런게 빅데이터에 대한 실질적인 벤치마크가 되는지는 의문입니다. 왜냐면 빅데이터는 말 그대로 정말 크기 때문이죠. 하지만 벤치마크 도구들의 성능측정 방법을 보면 RDBMS에서도 튜닝을 통해 어렵지 않게 처리할 수 있는 녀석도 종종 있습니다.

솔직히 제가 생각하는 빅데이터는 petabyte 정도의 처리를 빨리할 수 있어야 합니다.

여러 벤치마크 중 결과가 공유된 벤치마크만 소개하겠습니다.

1. AMPLAB (비정형 처리)

다양한 제품의 측정 결과를 제공

테스트 환경 정보

항목	내용
테스트 데이터 형태	비정형 웹페이지와 URL등
테스트 유형	스캔, 정렬, 조인, 외부스크립트
테스트 데이터 저장소	HDD, MEM
데이터 저장소 유형	S3

테스트 데이터 정보

S3 노드	랭크테이블		방문자		문서
	행	바이트	행	바이트	바이트
/tiny/	small	1200	77.6KB	1.7MB	6.8MB
/1node/	18,000,000	1.28GB	115,000,000	25.4GB	29.09GB
/5node/	90,000,000	6.38GB	775,000,000	126.8GB	136.9GB

3개의 테이블을 조인 연산 한다면 제법 빅데이터스러운 것 같습니다. 조인하지 않을 경우 빅데이터인지 의문스러운 양입니다.

2. TPC-H(정형 처리)

드루이드와 스파크의 벤치마크에 사용되었습니다.
1GB(, 100GB의 데이터 셋을 기준으로 데이터의 집계, 카운트, 정렬을 하는 벤치마크입니다.   정형입니다.(정확히 다 그런지는 모르겠습니다.)

TPC-H 데이터셋 형태

스타스키마를 구성해놓고 조인연산을 수행할 수 있는 환경도 제공하며, 조인처리를 하지 않는 DB시스템에서는 집계 성능만을 추출해서 공유하기도 합니다. 개인적으로 자료 검색할 때 가장 많이 보는 도표이기도 합니다. 그냥 단순 집계는 빅데이터라고 부르기 애매한 수준의 크기입니다.

4. 벤치마크를 소개한 이유 

벤치마크는 시스템의 처리 성능을 확인 할 수 있는 주요한 기준입니다. 각 시스템의 사양을 어느 정도로 구축해야할지, 시스템 규모와 비용을 산정할 수 있는 기준자료로 활용되기에 비즈니스 의사결정에 있어서 가장 중요한 포인트라고 할 수 있습니다.



오늘은 여기까지.
다음은 데이터 처리에 대해 기본적으로 알아야할 이야기를 소개할 것 같습니다.

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

1.빅데이터 개념잡기
2.OLAP ? OLTP? 빅데이터?
3.빅데이터 도구 어떻게 고를까? - 벤치마크
4.빅데이터 처리 성능. 스토리지 전략

5.빅데이터 처리 성능. 네트워크 전략
6.시계열 DB를 알아봅시다.

빅데이터 개념잡기 '빅알자'. 2.OLAP ? OLTP? 빅데이터?

1. OLAP 

Online Analytical Processing 의 약자입니다. 온라인에서 데이터를 분석 처리 한다는 거죠. OLAP은 결국 Cube로 귀결됩니다. 연관성 분석이 목적이니까요 ㅎㅎ....

cube = 소규모 집계를 통해 상위 집계나 하위 집계를 도출할 수 있도록 만들어진 데이터 집합입니다.

스타스키마와 큐브 

그림에 보면 왼쪽이 스타스키마 오른쪽이 큐브입니다. 가운데 파란 영업이 팩트 테이블이고 그 영업의 판매량을 분석할 지역, 날짜, 제품이 디맨전(차원정보)이 됩니다.

자세히 보면 팩트 테이블은 지역, 날짜, 제품의 고유id를 갖고 있으며 판매량을 갖고 있습니다. 즉 팩트인 영업 테이블은은 시간, 지역, 제품에 따른 판매량 데이터를 갖고있다는 이야기가 됩니다.

지역에 따른 판매량을 집계 하려면

select 
   지역명, sum(판매량) 판매량
from 
    지역, 영업
where 
    지역.id = 영업.id
group by 지역명

날짜에 따른 판매량을 집계 하려면

select 
   일자, sum(판매량) 판매량
from 
    날짜, 영업
where 
    일자.id = 영업.id
group by 일자

이런식으로 단일차원의 집계를 만들 수 있습니다.

다차원 집계의 경우
지역, 날짜, 제품 에 따른 판매량을 집계 하려면

select 
   지역명, 주, 제품명, 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 형태의 분석까지 가능해졌습니다.

기술의 완성도가 올라갈수록 쓰고 싶어 하는 사람과, 써야 하지만 쓸 수 없었던 사람들의 수요가 증가하는 추세에 있기에 앞으로 점점 더 인기가 있어질 전망입니다.

오늘도 이상입니다. 다음 장에서 찾아뵙겠습니다.
읽어주셔서 감사합니다.

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

1.빅데이터 개념잡기
2.OLAP ? OLTP? 빅데이터?
3.빅데이터 도구 어떻게 고를까? - 벤치마크
4.빅데이터 처리 성능. 스토리지 전략

5.빅데이터 처리 성능. 네트워크 전략
6.시계열 DB를 알아봅시다.

빅데이터 개념잡기 '빅알자'. - 1.빅데이터 개념잡기

최근 빅데이터 프로젝트를 시작하게 되면서 이런저런 조사를 하다 보니 수박 겉도 핥지 못한 문서들이 너무 많아 약간은 정리를 해야 할 것 같아 문서를 만들어봅니다. 5년전에 검색할때도 문서가 난해했는데. 지금도 마찬가지인 것 같아서요.

사람들이 가장 난해하게 생각하는 것들. 그리고 저에게 많이 질문해온 것들을 이야기 정리하자면 이렇습니다.

1. 빅데이터가 뭐야?
2. 큐브 인덱스라는게 있다는데 이건 또 뭐야?
3. 빅데이터 조인 분석은 어떻게 해야 해?

이러한 것의 개념이 해깔리는 이유는 많은 사이트에서 한글 문서를 지원해주는데 구글 번역기를 이용해 번역한 수준이고, 데이터 개념도 잡히지 않은 상태에서 글을 쓴다거나, 데이터 처리를 해보지 않은 사람이 의역하기 때문에 문서가 난잡하다. 로 정리됩니다.
답을 드리겠습니다.

1. 빅데이터 

IP V6 이야기 많이 들어보셨죠? '벌레에다가도 IP를 부여할 수 있다'라고. 이전에는 IP를 부여할 수 없어 지역별로 고립되어있던 정보가 지금은 다양한 형태의 네트워크를 통해서 연결되고, 서로 데이터를 주고받을 수 있는 상황이 되면서 데이터의 양이 엄청나게 늘었고, 분석하거나 조회하는 것 자체가 쉽지 않게 되었습니다. 아래 그림 같은 겁니다.

뭐 이런 형태가 아니더라도 SNS 같은 다양한 형태의 정보가 난무하는 플랫폼에서는 빅데이터 플랫폼의 도입을 더 빨리 했겠죠? 약 5년 전부터 갑자기 중요성이 대두되는 건 그만큼 활용할 수 있는 영역이 늘어났을 뿐, 빠른 업체들은 이미 다 하고 있습니다. 그리고 앞으로 더 늘어갈 추세입니다.

그리고 하자면 빅데이터도 결국 데이터입니다. 기존의 RDB 베이스에서 처리할 수 있는 방법이 있습니다. 최근의 하둡이나 여러 빅데이터 플랫폼이 주목받는 이유는 고가의 서버와 소프트웨어를 구입하지 않고도 빠른 속도의 처리를 할 수 있다는 장점 때문입니다. 결국 빅데이터도 어느 순간 비싸질 겁니다.

RDBMS보다 "빅데이터 플랫폼이 빠르다. 메모리를 덜 차지한다." 당연한 이야기 입니다. 개발자로서 기본을 이야기 하자면. 다양한 기능을 메모리에 올려놓고 여러 처리 방안을 고안해서 만들어진 패키지와 단일 기능을 가진 프로세스를 기준으로 같은 자원 상황에서 사용할 경우 단일 기능이 더 빠를 수 밖에 없습니다. 그럼에도 불구하고 빅데이터 플랫폼은 빠릅니다. 기존의 RDBMS에선 시도되지 않았던 여러 축약 기술, 분산 처리 기술들이 존재하기 때문이죠.

2. 큐브 인덱스 

큐브 인덱스는 로우 데이터를 인덱싱하는 분석용 인덱스가 생기는 게 아니라 분석용 OLAP 큐브에 인덱스를 생성한 겁니다. 결국 큐브 인덱스가 아니라 큐브와 인덱스라는 두 가지 다른 개념입니다.

큐브는 OLAP 큐브가 있죠. 큐브는 데이터웨어하우스에서 데이터를 다양한 관점으로 분석하기 위해 만들어진 개념입니다. 실제로 3차원 큐브가 아니라 여러 관점이 추가될 수 있으며, 그때마다 차원정보가 추가된다고 쓰여있는데. 분석 항목이 추가될 뿐 입니다.

스타스키마 라는 개념을 통해서 중심에 연관 집계의 키 역할을 하는 팩트 테이블을 두고, 주변에 분석 대상 차원(디맨전)을 두는 개념입니다. 그리고 팩트와 차원(디맨전)은 서로 조인해야 하기에 차원 테이블에 FK가 생기고 조인 속도를 위해 양쪽 모두 인덱스를 생성합니다.

간단하게 판매 - 고객 - 제품 - 시간 같은 결합하여 분석하면 도움이 되는 항목들을 설정하고, 해당 데이터에 대한 소규모 집계를 생성하여 작은 단위 집계를 만들어 놓고 분석을 하는 거죠.

예를 들자면

시간 + 제품 : "1월에 판매된 제품은 몇 개야? "
시간 + 고객 + 판매 : "2월에 제품을 구매한 고객은 몇 명이야? "
시간 + 고객 + 상품 : "3월에 몇 명의 고객이 제품을 N개 샀는데 남성 고객은X 상품을 많이 구매하고 여성 고객은 Y를 구매했어. 내년에도 준비해야 되겠네. "

같은 분석을 ROW데이터로 할 경우 너무 크기도 하고 필요 없는 항목 (예를 들어 고객과 구매 개수만 필요한데 고객과 고객 주소, 전화번호같은 불필요 한 항목) 들이 메모리에 올라오게 되고, 이로 인해 속도가 저하되기 때문이죠 분석에 필요 없는 것을 버리고 필요한 항목만 스타스키마를 만들어서 분석한다 = OLAP CUBE 입니다.

데이터 전문가 지식 포털 OLAP 설명
네이버 올랩 큐브
제 설명에 이해가 안가신다면 위 링크를 클릭해서 보세요

최근들어서 큐브 인덱스에 대한 설명이나 글들이 많이 올라오는데 이유는 빅데이터는 KYLIN이라는 OLAP도구가 생겨나기 전에는 연관분석을 지원하는 도구가 없었습니다. 그리고 KYLIN이 만드는 큐브 생성 원리만 봐도 이런 관점은 이해가 됩니다.

3. 빅데이터 조인 분석 어떻게 해야되? 

현재 KYLIN이라는 도구 이외에 OLAP도구가 없습니다. 대부분 시계열을 기반으로 차원정보를 생성하는 큐브와 유사한 기능을 하는 다중 인덱스, 다중 파티션을 제공하는 도구들이 대부분입니다. 대신 조인연산이 아닌 단일 테이블에 대한 시계열 집계를 진행합니다.

이상. 읽어주셔서 감사합니다.

빅데이터 개념잡기 '빅알자'는 여러 페이지로 이루어질 것 입니다.

1.빅데이터 개념잡기
2.OLAP ? OLTP? 빅데이터?
3.빅데이터 도구 어떻게 고를까? - 벤치마크
4.빅데이터 처리 성능. 스토리지 전략
5.빅데이터 처리 성능. 네트워크 전략
6.시계열 DB를 알아봅시다.