9:30

하는 것보다는 오른쪽처럼 이렇게 컬럼별로 즉, 어트리뷰트 별로 데이터를 저장을 하는 게 더 유리합니다. 오른쪽같이 저장을 하게 되면 만약에 첫 번째 어트리뷰트에 대해서만 분석하고 싶다 라고 했을 때는 이 하나의 첫 번째 어트리뷰트 데이터만 가져오면 되기 때문에 다른 어트리뷰트 정보를 필요 없는데도 가져오는 것을 이제 방지할 수 있습니다. 그래서 이 내용을 예시를 통해서 조금 더 구체적으로 알아보도록 하겠습니다.

그래서 어떤 튜플이 있다고 하겠습니다. 튜플 T가 있다고 하고요. 그 튜플 T의 정보로 우리가 찾는 테스크를 진행한다고 생각해보도록 하겠습니다. 예를 들어서 어떤 주문 번호가 있고요. 그 주문번호에 해당하는 주문 상세 내역을 우리가 가져오는 이러한 작업을 한다고 생각해보도록 하겠습니다. 예를 들어서 그 주문번호에 해당하는

뭐... 예를 들어서 뭐... 상품명, 상품 수량, 상품 가격, 아니면 언제 구매를 진행을 했는가 구매를 진행했는지 등등의 여러가지 어트리뷰터에 대한 정보가 포함되어 있겠죠. 그 정보를 모두 한번에 가져오는 테스크를 수행을 한다고 하겠습니다. 그래서 이러한 테스크는 주로 OLTP에 많이 해당이 됩니다. 이때는 데이터 저장 방식을 호리즌탈 방식으로 하는 것이 더 유리합니다.

왜냐하면은, 호리진탈 방식으로 데이터를 저장했을 때는 한 줄만 불러오면 되죠. 한 행의 데이터만 불러와서 그 행에 해당하는 모든 어트리뷰트 정보를 한번 가져오면 되기 때문에 이러한 연산을 수행을 할 때는 이렇게 하나의 튜프를 한번 가져오는 연산만 수행을 해주면 그런데 만약에 어트리뷰트 별로 저장하는 vertical 방식을 사용했을 때는

우리가 이러한 한 행의 데이터가 필요할 때 어트리뷰트 별로 가져와야 되기 때문에 여러 번 계산을 수행을 해야 됩니다. 예를 들어서 100개의 어트리뷰트를 가지고 있다 라고 했을 때는 그럼 어트리뷰트 별로 데이터를 가져와야 되니까 100번의 연산을 수행을 해줘야겠죠. 그래서 이렇게 일반적인 업무 처리를 진행을 할 때는 하나의 튜플 혹은 몇 개의 튜플을 전체 다 가져오는 경우가 많기 때문에

이러한 경우에는 호리전탈 방식으로 저장을 하는 것이 더 유리하게 됩니다. 그럼 다음으로 두 번째 다른 예시를 볼 건데요. 이 예시 같은 경우에는 이제 Group By라는 것을 통해서 22번째 어트리뷰트 그리고 83번째 어트리뷰트가 같은 것끼리 그룹으로 묶습니다.

그리고 각 그룹마다 100번째 어트리뷰트에 대한 총 합계를 계산하는 이러한 쿼리입니다. 이 쿼리의 의미가 중요하다기보다는 이러한 식으로 데이터 분석을 수행을 할 때는 전체 어트리뷰트를 다 사용하는 경우는 이렇게 몇 개의 어투비트만 사용을 하게 됩니다. 그래서 어떤 분석을 위한 쿼리니까 OLAP에 일반적으로 해당이 되겠죠.

그래서 이러한 경우에 만약에 호리지털 방식으로 저장을 했다라고 생각을 해보도록 하겠습니다. 아까와 같이 총 드리뷰트는 100개가 있다고 우리가 가정을 할 거고요. 전체 데이터 개수가 n이라고 가정을 해보도록 하겠습니다. 그럼 이 호련진탈 방식은 결국에는 우리가 3개의 어트리뷰트가 필요하지만 한 행식 가져오니까 모든 어트리뷰트 정보를

즉 100개의 어트리뷰트 정보를 다 가져와야 됩니다. 그래서 우리는 100n개의 값을 읽어와야 한다 라는 것을 알 수 있습니다. 반면에 vertical 방식으로 저장을 했을 경우에는 이 3개의 attribute에 대한 데이터만 읽어오면 되죠. 그래서 3n개의 값만 읽어오면 되고요. 그래서 결과적으로 전체의 3%만 우리가 데이터를 읽어올 수 있습니다. 그래서 정리하자면, OLTP 연산은 호리젠탈 방식이 유리하고, OLAP는 vertical 방식이 유리하다고 생각할 수 있습니다.

그리고 위에 여기 호리젠탈 스토리지에 NO INDEX라고 적혀있는데요. 그런데 이렇게 INDEX라는 것을 호리젠탈 스토리지에 추가하게 되면, 일부 이러한 호리젠탈 저장 방식의 단점을 극복할 수 있습니다. 그래서 프로젝션 인덱스라는 것을 호리즌탈 스토리지에 추가하는 방법이 있는데요. 이 프로젝션 인덱스는 우리가 자주 사용하는 이 열에 대한 인덱스를 따로 저장하는 것을 의미합니다.

그러면 원래는 호리즌탈 방식은 모든 attribute 값을 다 가져와야 되는데 이렇게 projection index로 이미 저장된 열 같은 경우에는 그 열의 바로 그 열값만 가져올 수 있습니다. 그래서 이렇게 projection index를 활용하게 되면은 일부 horizontal storage의 단점을 개선을 해서요 OLAP에서도 어느정도 효과적으로 사용을 할 수 있습니다.

다음은 실제 데이터큐브를 연산하는 과정에 대해서 공부해보도록 하겠습니다. 그래서 기본적인 용어를 먼저 살펴보고요. 그 다음에 OLAP 서버 아키텍처를 구성하는 몇 가지 방법이 있습니다. 그 방법에 대해서 공부해보고 그 다음에는 데이터큐브 Materialization이라는 방법 그리고 효율적인 큐브 계산을 하는 몇가지 방법에 대해서 공부를 해보도록 하겠습니다.

이건 지난 시간에 봤던 그림인데 데이터 큐브를 큐보이드 관점에서 나타낸 그림입니다. 그래서 가장 아래에는 가장 저차원의 큐보이드가 위치하고요. 위로 올라갈수록 일부 차원을 집계를 하죠. 그래서 더 높은 차원의 값이 이렇게 표현되는 이런 구조를 가지고 있습니다. 그래서 가장 아래에 4차원, 3차원, 2차원 올라가서 가장 위에는 전체의 합계죠.

그래서 Apex Cuboid가 가장 상위의 계층에 위치합니다. 이것을 이런 Cuboid 단위가 아니고 실제 저장된 데이터 단위 즉, 셀 단위로 한번 보도록 하겠습니다. 그래서 셀이라는 것은 이러한 실제 저장된 데이터를 의미합니다. 데이터 큐브의 실제 저장된 데이터를 의미합니다. 그래서 아래 예시가 이러한 셀들인데요. 가장 밑에 있는 셀을 먼저 한번 살펴보도록 하겠습니다.

이 데이터 큐브는 4차원으로 구성이 되어 있습니다. 그리고 이 4차원의 값이 모두 다 실제로 저장이 세부적으로 표현이 되어 있는 그런 셀을 의미합니다. 그래서 이 4차원에 해당하는 이러한 데이터가 모두 구체적으로 나타나 있고요. 이러한 셀을 뭐라고 하냐면 Base 셀이라고 합니다. 그리고 그 위에 있는 나머지는 이것보다 더 상위 차원에 위치하는 셀에 해당이 됩니다.

그래서 일부 디멘션 값을 이렇게 집계해서 표현을 해주고 있는 것을 확인할 수 있습니다. 이 Star 같은 경우에는 지난 시간에 설명드렸는데 드렸던 것 같이 어떤 하나의 차원의 모든 값을 집계했다는 집계한 답이라는 것을 의미합니다. 그래서 예를 들어서 이 모든 차원의 값에 대한 썸이다. 이러한 식으로 우리가 이 해당 차원에 대한 모든 값들의 썸이다 라고 생각을 해 줄 수 있습니다.

그래서 어떤 하나의 차원이라도 이렇게 집계된 값을 사용하는 이러한 셀들을 어그리게이트 셀이라고 부를 수 있습니다. 여기서는 가장 아래에 있는 것만 베이스 셀이고 그 위에 있는 것들은 모두 어그리게이트 셀에 해당이 됩니다. 그리고 그 위에 두 번째 셀을 보면 이 밀크라는 값만 구체화가 되어 있고요.

나머지 값들을 모두 집게값으로 사용을 하고 있습니다. 이 중에 세 번째 집게값은 로케이션에 해당이 되는데요. 그 아래에 있는 세 번째와 네 번째 셀 같은 경우에는 이 밀크라는 값을 동일하게 가지고 있는데 이 세 번째 로케이션 값을 구체적인 값으로 표현을 해주는 그러한 셀에 해당이 됩니다.

이때 이 세 개의 셀의 관계를 우리가 표현을 할 수 있는데요. 이 더 상위의 셀, 동일한 밀크라는 값을 가지고 있지만 다른 구체적인 값을 집갯값으로 표현한 더 상위의 셀을 ancestor 라고 표현을 하고요 그리고 더 하위의 셀이죠 이것을 descendant 셀이라고 표현을 해주고 있습니다 여기서 세 번째, 네 번째, 다섯 번째, 여섯 번째

즉 이 아래에 있는 4개의 셀은 모두 밀크라는 값을 가지고 있죠. 그렇기 때문에 이 아래에 있는 4개의 셀은 모두 이 두 번째 셀의 Descendant 셀이다 라고 우리가 얘기를 할 수 있고요. 밀크는 반대로 이 아래 4개의 셀에 대한 Ancestor 셀이다 라고 얘기를 할 수 있습니다. 그러면 여기서 우리가 볼 수 있는게 이 ancestor와 descendant가 차원이 한 차원이 차이가 날 수도 있고 여러 차원이 차이가 날 수도 있겠죠.

이 중에서 차원이 하나만 즉 하나의 계층만 차이가 나는 이러한 관계를 구체적으로 parent와 child 셀이라고 표현합니다. 그래서 이 두 번째 밀크, 그리고 세 번째, 네 번째 셀은 각각 parent 그리고 child의 관계를 가지고 있다고 생각할 수 있습니다. 그래서 먼저 이제 뒤에 이러한 용어가 계속 계속 나오게 되고요. So, let's know what the six languages are.

Next, we'll talk about the server of OLAP. Let's talk about the architecture of OLAP. 크게 세 가지 방식이 있는데요. 첫 번째는 Relational OLAP, ROLAP라고 불리는 방식입니다.

이 이름에서 알 수 있듯이 우리가 지난 챕터에서 잠깐 다뤘던 Relational DB, 즉 관계형 데이터베이스. 혹은 관계형 테이블을 통해서 이 데이터를 실제로 저장하는 방식입니다. 즉 관계형 테이블이니까 2차원의 테이블 형태로 각각의 데이터를 저장해놓고요. 그리고 테이블 간의 관계를 우리가 키값을 통해서 연결을 해주는 구조입니다.

그래서 우리가 앞서 배웠던 스타 스키마나 혹은 스노우 플레이크 스키마와 유사한 형태로 실제 데이터를 저장해 놓는다 라고 생각을 해 줄 수 있습니다. 그래서 이 OLAP 같은 경우에는 결국에는 Relational DB 형태로 데이터를 저장하기 때문에 실제로 구축되어 있는 다양한 데이터베이스 시스템이죠.

Relational Database Management System 이것을 DBFS라고 하는데요. 이러한 기존에 구축된 DBFS를 이용해서 데이터 웨어하우스에 저장되어 있는 데이터들을 관리하고 저장하는 이러한 작업을 수행할 수 있습니다. 즉 우리가 기존에 많이 사용하던 데이터베이스 관리 시스템을 그대로 활용해서 데이터를 효율적으로 관리할 수 있다는 특징을 가지고 있고요.

그리고 가장 하위 차원의 DBMS를 통해 실체 데이터를 관리하고 사용자가 터리를 통해 이 데이터를 처리를 할 때는 그 중간 단계에서 OLAP Middleware라는 것이 그러한 중간 단계의 업무 처리를 진행을 해드립니다. 여기서 OLAP Middleware라는 것은 사용자가 쿼리를 입력을 했을 때

그 쿼리를 해석을 해서 DBMS가 동작할 수 있도록 그 쿼리를 해석해서 전달해주는 그런 과정을 수행하는 중간 단계에 있는 소프트웨어라고 생각을 할 수 있습니다. 그래서 여기서 결국에 알아야 될 것은 기존에 우리가 일반적으로 많이 사용하는 DBMS를 사용하고 대신 사용자가 쿼리를 줬을 때는 그것을 해석해서 분석을 해야 되기 때문에

OLAP middleware라는 걸 중간 단계에 둬서 그런 분석 업무를 추가적으로 처리한다고 생각을 해줄 수 있습니다. -

그래서 기존의 DBMS를 사용하니까 DBMS에서 제공하는 여러가지 최적화 방법을 그대로 사용할 수 있고요. 그리고 일부 값을 집계를 해서 그 값을 저장해놓고 그 집계값을 효율적으로 찾을 수 있는 그러한 내비게이션 로직도 DBMS에 있는데 잘 활용을 할 수 있습니다.

그래서 결국에는 DBMS에서 제공하는 여러가지 툴이나 서비스를 효과적으로 사용할 수 있다고 알아주시면 될 것 같습니다. 그리고 이제 아래에서 추가적으로 공부를 하지만 여기서는 실제로 데이터투브 형태의 데이터를 구성을 해서 저장하지는 않습니다. 저장할 때 기존의 테이블 형태로만 데이터를 결국에는 저장을 하고 있기 때문에 확장성이 좋습니다. 그래서 그 테이블만 계속해서 늘리게 되면은 데이터가 추가로 들어왔을 때 쉽게 그 데이터의 저장 공간을 확장할 수 있습니다.

아래 같은 경우에는 예를 들어서 OLM OLAP 같은 경우에는 데이터큐브로 데이터를 저장해놓기 때문에 좀 이렇게 확장을 하기 어렵다 라는 그런 차이점을 가지고 있습니다. 방금 전에 잠깐 말씀드렸던 것처럼 이 MOLAP 같은 경우에는 실제 데이터 큐브와 유사한 그런 멀티디멘셔널 구조로 데이터를 저장을 합니다.

즉 다차원의 배열 형태로 데이터를 저장을 한다 라고 생각을 하시면 됩니다. 우리가 데이터큐브라고 하는 것은 실제 데이터를 저장하는 방식이 아니고요. 우리가 개념적으로 생각할 수 있는 그러한 다차원 분석 구조를 의미합니다. 그럼 그 분석 구조를 반영을 해서 실제 데이터를 저장할 때도 단순한 2차원의 테이블 형태가 아니라 데이터큐브의 형태를 잘 반영할 수 있는

그러한 다차원의 배열 형태로 그 데이터를 저장해놓자 라는 것이 이 NOLAP 방식에 해당됩니다. 그럼 데이터 튜브와 유사하게 결국에는 이러한 다차원의 배열 구조에 기반을 해서 여러가지 차원의 직계값들을 미리 계산을 해서 저장할 수 있습니다. 그래서 미리 집계된, 요약된 데이터까지 가지고 있기 때문에

그러한 값들을 활용할 때 다시 계산을 하지 않아도 그 값에 접근을 해서 빨리 빨리 가져와서 활용할 수 있다는 장점을 가지고 있습니다. 그래서 결국에는 MOLAP 같은 경우에는 우리가 실제 계산 과정에서 더 빠르게 데이터를 가져와서 활용할 수 있다는 장점을 가지고 있습니다. 하지만 우리가 데이터 튜브를 미리 다 정의해야겠죠.

즉 다차원의 구조로 변화를 해서 데이터를 저장을 해야 되기 때문에 데이터를 확장하기가 조금 어렵다, 확장성이 낮다는 이러한 단점을 가지고 있습니다. 그래서 하이브리드 OLAP 또는 HOLAP라고 하는 방법은 이 두 가지를 섞어서 데이터를 저장하는 그러한 구조를 가지고 있습니다. 그래서 ROLAP의 장점은 확장성이겠죠.

그래서 그 장점과 MOLAP의 장점인 계산 속도를 함께 취하자는 아이디어에서 구성이 되었습니다. 구체적으로 어떻게 하이브리드로 사용을 하냐고 했을 때 가장 구체적인 가장 낮은 차원의 정보들은 기본적으로 이렇게 테이블 형태로 저장을 해놓습니다. 즉, Relational DB 형태로 가장 낮은 차원의 로우 데이터는 다 저장을 해놓고요.

그 위에 집객 값들 있죠. 더 상위 차원의 값들은 이제 아래와 같이 4차원의 배열 형태로 구성을 해놓습니다. 그래서 가장 아래 차원, 실제 모든 데이터가 다 저장된 것만 우리가 테이블 형태로 구성을 해놓고요. 그 위에 집게 값들이 포함된 상위 차원의 값들은 다차원 어레인 구조로 표현을 한다고 생각을 해줄 수 있습니다. 그렇기 때문에 이제 OLAP의 장점과 MOLAP의 장점을 동시에 활용할 수 있는 방법에 해당이 됩니다.

여기까지가 OLAP 서버의 아키텍처였고요. 워크카펫 밖에도 일반적인 우리가 SQL을 처리하는 그런 서버들도 데이터 분석 과정에 활용할 수 있게 특화되어서 제공되는 이러한 서버들도 존재합니다. Redbricks라는 서버가 대표적인 예인데요. SQL 서버는 일관적인 업무를 처리하기 위한 SQL을 처리하는 기능을 제공하는 서버입니다.

근데 그것 뿐만이 아니라 이러한 스페셜라이즈드 SQL 서버 같은 경우에는 이러한 데이터 분석을 처리하기 위한 여러가지 기능도 추가적으로 제공을 하고요. 그래서 이러한 서버를 사실 OLAP에 활용을 해줄 수도 있습니다. - Thank you.

다음으로 공부해볼 개념은 큐브 머터리얼라이제이션이라는 개념이고요 그래서 이것은 실제 우리가 모든 집계값을 실시간으로 계속 계산을 하다보면 계산 시간이 굉장히 오래 걸리겠죠 그래서 집계값들을 미리 계산을 해서 저장을 해두는 방식을 큐브 머터리얼라이제이션이라고 합니다

그래서 여기서 나오는 개념이'FULL CUBE'라는 개념이 나오는데요. 이'FULL CUBE' 같은 경우에는 모든 집계값을 결국에는 미리 계산을 해서 저장을 해 놓는 것을 의미합니다.

Oh 그런데 이렇게 풀큐브를 사용을 하게 되면은 예를 들어서 디멘전이 굉장히 많이 늘어날 경우에는 디멘전에 대한 각각의 서브스페이스 조합이 굉장히 많이 생기겠죠. 즉, 쌤값이 굉장히 많이 생기게 됩니다. 그래서 이렇게 모든 쌤값을 즉 모든 집계값을 다 계산하는데 너무 오랜 시간이 그래서 이것을 보완을 하고 우리가 원하는 값들만 계산을 하기 위한 아이스버그 큐브라는 방법을 사용할 수도 있는데요.

이 두 가지가 어떻게 다른지 예시를 통해서 구체적으로 설명을 해보도록 하겠습니다. 이 안에 예시는 이 sales info 라는 판매 정보에 대한 그런 분석을 수행하기 위한 그러한 커리에 해당이 됩니다. 그래서 판매 정보를 우리가 분석을 하고 있고요. 그 밑에 있는 group by q고 라는 것은

결국에 이 데이터를 기반으로 데이터 큐브를 만들라는 명령어입니다. 그래서 그룹 바이 큐브를 통해서 우리는 데이터 큐브를 만들 수 있습니다. 여기서 디멘전을 보면은 디멘전이 3개죠. 여기는 원스 시티 커스터머 그룹이라는 3개의 디멘전을 가질 수 있습니다. 그러면 이 세 개를 가지고 데이터 큐브를 만들 수 있겠죠. 튜보이드로 봤을 때 3 디멘션 큐브이드부터 2차원, 1차원, 0차원까지 이렇게 여러 차원의 데이터 큐브를 모두 구성을 하게 됩니다.

그 다음에 거기서 집계값을 계산을 합니다. 그래서 기존의 세 가지 값. 그리고 각각의 어떤 셀 값에 해당하는 카운트 값이죠. 즉 전체 갯수라는 직계 값까지 이 각각의 큐브에 대해서 함께 선택을 해서 가져오는 이러한 쿼리를 사용을 하고 있습니다.

그래서 예를 들어서 이 카운터 같은 경우는 같은 개월, 같은 도시, 같은 커스터머 그룹을 가진 그러한 그룹이 하나로 묶이겠죠. 그 그룹이 그룹에 해당되는 값이 몇 개가 있는지. 이 값을 카운트에 집계를 해서 각각의 그룹마다 계산을 해주게 됩니다. 여기서 이 마지막 줄을 일단은 여기서는 생략을 하고요.

위에 세 줄만 보게 되면은 이거는 풀 큐브에 해당이 됩니다. 왜냐면은 그룹 바이 큐브를 통해서 이 3개의 차원으로 만들 수 있는 모든 값들을 계산을 했죠. 그렇기 때문에 모든 집계값들을 계산을 하니까 이 3개는 이 3줄만 보면 풀 큐브에 해당이 됩니다. 그런데 이렇게 계산을 하게 되면 사실 계산량이 굉장히 많을 수 있겠죠. 여기서는 차원이 3개지만 이 차원이 100개, 200개 이렇게 늘어나게 되면은

계산량이 굉장히 많이 생길 수 있고요. 그래서 이 계산량을 줄이기 위해서 아래처럼 having 이라는 명령어를 통해서 우리가 어떤 조건을 걸어줄 수 있습니다. 어떠한 조건이냐면 이 count 값이 즉 각 그룹의 집객 값이 우리가 설정한 민서포트라는 이 값보다 클 때만 그 값들을 선택해라 라는 것을 의미합니다.

예를 들어서 민서포트가 100이다라고 하면은 거의 각 그룹에 대한 직급값이 100 이상인 것만 선택해서 가져와라 라는 것을 의미합니다. 그러면 여기서는 이제 전체 집계값을 모두 다 우리가 선택해서 가져오는게 아니고요. 이러한 조건에 만족하는 것만 가져오게 되죠. 그래서 이렇게 조건에 만족하는 특정한 조건에 만족하는 일부 집계값만 미리 계산을 해 놓는 것을 아이스버그 큐브라고 합니다.

그래서 일부값만 미리 계산을 해 놓는 방식이죠. 그리고 여기서 사용되는 우리가 정의해 준 조건이 있습니다. 여기서는 win-support 이상이다 라는 이러한 조건이 있죠. 이러한 조건을 ice-burgle-condition 이라고 합니다. 그래서 여기 나와 있는 것처럼 ice-burgle-condition을 만족하는 것만 우리가 계산을 하는 그런 방식을 사용을 합니다. 이름이 IceWorker인 이유는 사실 전체 우리가 계산할 수 있는

어그리게이트 셀이 굉장히 많은데 이렇게 조건을 걸게 되면 그중 굉장히 일부분만 실제로 사용을 하게 됩니다. 왜냐면은 우리가 실제로 데이터큐브를 구성을 하게 되면 스팔스 하기 때문에 빈 공간도 굉장히 많고요. 또 우리가 실제로 사용하는 어티리뷰톤은 일반적으로 몇 개가 되지 않죠. 100개의 어티리뷰톤이 예를 들어서 3개만 사용한다 라고 했을 때 이렇게 실제로 계산되는 양은 굉장히 적을 수 있습니다. 그래가지고 이 빙하중에 수면위로

드러난 부분이 굉장히 작듯이 이 아이스버그 큐브도 전체 풀 큐브에 비해서 굉장히 작은 양을 가지고 있다는 뜻으로 일반적으로 아이스버그 큐브라고 불리고 있습니다. 그럼 다음으로는 이 아이스버그 큐브를 사용했을 때 그러면 장점을 한번 우리가 비교를 해보도록 하겠습니다. 아이스 큐브를 사용하면은 결국에는 우리가 Threshold를 정했죠.

결국에는 아이스 볼 컨디션이라는 Threshold를 정해서 그것보다 높은 값만 표현을 해주기 때문에 계산량을 크게 줄일 수 있습니다. 그리고 두 번째로는 간결성을 높일 수 있습니다. 우리가 필요하지 않은 정보까지 다 이렇게 표현을 해주는 것보다는 우리가 필요한 정보만 가져오는 게 더 우리가 보기에도 편하겠죠. 그래서 간결성 그리고 어떤 계산의 효율성 이 두 가지를 다 가지고 있습니다.

아 그리고 이제 앞에서는 사실 우리가 데이터 큐브를 먼저 다 계산을 한 다음에 그중에 조건이 만족하지 않는 것만 제외를 했죠. 그러면 사실 어차피 여기서는 이제 전체 큐브를 다 계산을 해야 되는데

우리가 뒤에서 배울 데이터 큐브 컴퓨테이션 방법을 사용을 하게 되면은 우리가 조건을 만족하지 않는 셀들을 미리 계산하지 않고 쳐낼 수 있습니다. 그렇게 되면 일부 셀만 계산을 실제로 수행하면 되기 때문에 이 계산의 효율성을 크게 증가시킬 수 있다는 장점을 가지고 있습니다. 그래서 한번 R의 예시를 통해서 풀큐브와 아이스버그 큐브를 한번 비교를 해 보도록 하겠습니다.

그래서 하나의 큐브가 있다고 가정을 할 건데요. 그 큐브는 100개의 디멘전, 즉 100개의 어티뷰트를 가지고 있습니다. 그리고 베이스셀이 몇 개가 있다고 가정을 할 거냐면 여기서는 그냥 적게 두 개의 베이스셀만 있다고 가정을 하겠습니다. 그래서 왼쪽에 있는 베이스셀은 100개의 어트리뷰트를 가지고 있죠. 그래서 A1, A2부터 A100까지의 실제 값들을 가지고 있고요.

두 번째 베이스 셀 같은 경우에는 역시 100개의 어트리뷰트인데 앞에 두 개는 값이 동일합니다. A1, A2는 왼쪽에 있는 셀과 값이 동일한데, 세번째 값부터는 다른 값을 가지고 있다는 것을 확인을 할 수 있습니다. 이때 우리가 이 아래 조건 즉, count가 1보다 크거나 같다는 조건을 수행했을 때

어그리게이트 셀이 몇 개가 나오는지 한번 계산을 해보도록 하겠습니다. 여기서 COUNT라는 것은 뭘 의미하냐면 어떤 셀 값이 있을 때 이 두 개 중 하나가 최소한 포함이 되어야 된다는 것을 의미합니다. 몇 개 해당이 되는지가 카운트의 의미이고요.

그러면 사실 이 집계 값을 우리가 계산을 한다는 것은 각각의 어트리뷰트로 집계를 하게 되겠죠. 예를 들어서 첫 번째 셀을 기준으로 한다면 이 첫 번째 값을 그대로 사용할 수 있고요. 아니면은 이 A1과 이 오른쪽에 있는 두 번째 셀 두 개의 값을 집계하는 것을 첫 번째 차원으로 사용할 수 있습니다. 예를 들어서 A100 마지막 차원의 값 같은 경우에도 이걸 그냥 그대로 값을 가져올 수도 있고요.

아니면 집계를 해서 사용을 할 수도 있습니다. 즉 별로 표현을 하던가 아니면 해당 값을 그대로 사용하던가 두 개의 선택지를 가지고 있습니다. 즉 거꾸로 말하면은 어떤 집계값이든지 최소한 하나의 셀은 포함을 하고 있고요. 그래서 이 조건은 결국에 모든 어그리게이트 셀이 만족을 하게 됩니다. 좀 어렵게 표현이 되어 있지만 결국에 첫 번째 이것은 어떤 것을 의미하냐면 모든 어그리게이트 셀 즉

FULL CUBE를 의미합니다. 즉 FULL CUBE에는 어그리게이트 셀이 몇 개가 포함이 될까 라는 것을 의미하고 있습니다. 그럼 한번 FULL CUBE에 어그리게이트 셀이 몇 개 있는지를 계산을 해보도록 하겠습니다. 먼저 왼쪽에 있는 첫 번째 베이스 셀에서 집계값이 몇 개가 나올 수 있는지 어그리게이트 셀이 몇 개가 나올 수 있는지를 보면은 결국에는 각 디멘점별로 이 값을 사용을 할지 아니면 집계 값을 사용을 할지 둘 중 하나를 결정을 해야 되죠.

그래서 100개이니까 2의 100승이 나올 수 있습니다. 그런데 어그리게이트 셀이니까 이 베이스 셀을 하나 빼줘야겠죠. 그래서 2의 100승 -1이 이 왼쪽에 있는 베이스 셀로부터 나올 수 있는 어그리게이트 셀의 개수입니다. 오른쪽 베이스셀 기준으로 동일하게 2/100 -1이라는 어그리게이트셀이 만들어질 수 있겠죠.

그래서 이 두 개의 베이스셀을 기준으로 아래에 있는 것과 같이 2/100 -2개의 어그리게이트셀이 나올 수 있습니다. 그런데 여기서 이제 공통적으로 나올 수 있는 어그리게이트 셀이 있습니다. 왜냐하면 이 앞에 두 개의 값은 동일하게 가지고 있죠. 그래서 이 오른쪽 위에 표시된 이런 네 개의 셀 같은 경우에는

왼쪽에서도 나올 수도 있고 오른쪽에서도 나올 수도 있습니다. 즉 중복이 됩니다. 그래서 이 4개의 셀 중복을 빼주니까 -4를 이렇게 마지막에 하게 되서 그래서 총 이렇게 2/101승 -2, -4라는 이러한 셀이 계산이 됩니다. 그 다음에 아이스고그 셀을 계산해 보도록 하겠습니다.

이번에는 조건을 높여서 카운트 값이 2 이상인 것만을 계산해 보도록 하겠습니다. 카운트 값이 2니까 어떠한 집계 셀의 이 두 개가 모두 포함이 되는 그런 경우만 해당이 됩니다. 즉 어떤 경우만 해당이 되냐면 이 네 가지 경우에만 해당이 됩니다. 이 네 가지는 왼쪽도 해당이 되고 오른쪽 셀도 해당이 되는 걸 확인을 할 수 있죠.

하지만 이외에 예를 들어서 이 세 번째부터 100번째에 있는 E-Atrebute 값이 남아있다면 A3라는 값이 남아있다면 첫번째 셀은 거기에 해당이 되지만 오른쪽에 있는 두번째 베이스 셀은 세번째 값이 B3니까 거기에 해당이 안되겠죠. 그래서 무조건 첫 번째 값이나 두 번째 값만 남겨놓고 나머지를 어그리게이션을 해놓아야 됩니다.

그래서 이 네 가지 경우가 나오게 되고요. 그래서 이러한 아이스버그 셀을 계산하게 되면 결과적으로 이 네 개만 계산을 하면 됩니다. 그래서 굉장히 효과적으로 우리가 어떠한 특정 조건만 계산을 하고 싶다면 계산량을 감소시킬 수 있습니다. 다음으로는 그러면 이렇게 풀큐브 그리고 아이스버그 큐브를 계산을 수행을 하는데

어떻게 계산을 하는 것이 효과적인지 그 계산 방법 대표적인 세 가지에 대해서 공부를 해보도록 하겠습니다. 첫 번째 방법은 이제 멀티웨이 어레이 어그리게이션 이라는 방법이고요. 이 방법은 bottom-up 방식으로 분류할 수 있습니다. 즉 bottom-up 방식이기 때문에 아래부터 계산을 하죠. 그래서 가장 낮은 차원의 큐브이드부터 순서대로 올라가면서

이 데이터 큐브를 계산하는 방식에 해당합니다. 구체적인 내용은 뒤에서 추가적으로 공부해볼 예정이고요 두 번째는 BUC라는 방법이 있는데 이건 탑더운 방식입니다 그래서 거꾸로 상위 큐브이드, 높은 차원의 큐브이부터 계산해서 점점 내려오는 그런 방식에 해당합니다 그 다음에는 특히 굉장히 많은 차원을 가지고 있는

그러한 데이터 큐브를 계산을 할 때 활용할 수 있는 방법으로 셰일 플래그먼트 어프로치라는 방법이 있고요 이 세 가지 방법에 대해서 조금 구체적으로 알아보도록 하겠습니다. 첫 번째,'얼티웨이 어이 어그리게이션' 이라는 방법입니다. 이 방법은 아까 말씀드렸던 것처럼'바텀업' 방법에 해당이 됩니다. 그래서 이제 오른쪽에 나와 있는 것처럼 가장 낮은 차원이죠.

A, B, C 이것부터 계산을 하고요. 그 다음에 더 상위 차원의 큐보이드를 계산합니다. 그래서 A, B는 C라는 차원에 대해서 집계된 Aggregate Sel이고요. A, C는 B에 대해서 집계된 Aggregate Sel이죠. 그래서 이러한 것들을 계산을 하고 그것보다 더 상위차원을 그 다음에 계산하고 이렇게 올라가면서 계산을 하는 방식입니다.

여기서 이제 핵심적인 아이디어는 이 아래 값들을 아래 집계값들을 하위차원부터 계산을 하니까 하위차원에서 계산된 집계값들을 저장을 해두고요. 상위차원의 값을 계산을 할 때 이 가장 낮은 차원부터 다시 계산을 하는 게 아니고 중간차원의 직계값들을 활용을 해서 상위차원의 값들을 계산을 하는 이러한 방식을 사용을 합니다.

예를 들어서 A값을 계산을 할 때 이 B와 C에 대한 직계값을 계산을 해야 되죠. 그것을 A, B, C부터 항상 이렇게 반복해서 하는 게 아니고 그 전에 A, B라는 중간 단계를 우리가 계산을 해놨었죠. 그래서 A, B에서 구한 직계값을 활용을 해서 그 상위 단계의 A와 B의 직계값을 계산을 하는 이러한 방식을 사용을 합니다. 이렇게 하면은 계산의 중복을 막을 수 있고요.

더 빠르고 효율적인 연산을 수행을 할 수 있게 됩니다. 그리고 계산을 수행을 할 때 각각의 어떤 계층, 상위계층값만 이용을 해서 상위계층을 계산을 해주면 되기 때문에 이 상위 계층은 서로서로 결국에는 독립적으로 계산이 됩니다.

이 하위 계층값만 종속되어 있죠. 그렇기 때문에 여러 개의 디멘전에 대해서 동시에 계산을 수행할 수 있습니다. 즉 A를 하고 B를 하고 C를 하고 이렇게 순차적으로 계산하지 않고 한 번에 여러 개의 값을 계산을 할 수 있습니다. 그리고 그 다음에는 멀티 디멘저널 청크라는 것을 사용할 수 있는데요. 이것은 전체 데이터가 너무 많을 때 그것을 한 번에 계산하는 게 어려우니까

그것을 여러 개의 청크 단위로 여러 개의 그룹으로 분할을 해서 계산을 하는 방법입니다. 그래서 데이터가 너무 많으면 그 많은 데이터를 한 번에 메모리에 올리기 어렵기 때문에 그 데이터를 분할을 해서 그 분할 된 데이터로 계산을 하고 그 다음에 다음 청크를 계산을 하고 이런 식으로 청크 단위로 더 효율적으로 계산을 할 수 있습니다. 그런데 이 방법은 단점을 가지고 있는데요.

예를 들어서 하위 계층부터 계산이 되기 때문에 이 아이스버그 큐브를 만약에 우리가 만든다고 했을 때 예를 들어서 AB라는 이 값이 우리가 설정해 둔 아이스버그 컨디션을 넘지 못했습니다. 그러면은 이 AB는 이제 계산을 하지 않아도 되겠죠. 그런데 그 다음 단계에 있는 A와 B 같은 경우에는

더 집계된 값이기 때문에 그 컨디션을 넘을 수도 있습니다. 그래서 미리 이 A와 B라는 값을 계산을 하기 전에 이 아이스복 컨디션을 안 넘겠다고 판단을 할 수가 없고요. 그래서 미리 계산을 진행하지 않는 이 프로닝이라는 방법을 여기서는 사용할 수 없습니다. 즉 우리가 뒤에서 배울 방법은 계산을 실제로 하기 전에 보고

아 얘는 어차피 컨디션을 넘지 못하겠다 해서 계산을 선제적으로 수행하지 않는 이러한 방식으로 계산량을 줄일 수 있는데 이 방법 같은 경우에는 계산을 이미 한 이후에 컨디션을 넘는지 안 넘는지를 판단을 해야 되죠. 그렇기 때문에 아이스복 튜브를 사용을 한다고 하더라도 계산량을 줄일 수가 없습니다. 그래서 이 방법은 아이스버그 옵티마이제이션에는 적합하지 않은 방법이고요.

그래서 일반적으로 풀큐브를 구할 때, 풀큐브를 계산할 때 이 계산 방법을 많이 활용을 합니다. 그래서 일반적으로 차원이 적고 적은 차원의 풀큐브를 사용할 때 많이 사용하는 방식이다 라고 합니다. 생각을 해줄 수 있습니다. 그 다음은 두번째 방법인데요. buc라는 방법이고 이 방법은 반대로 top down 방법에 해당이 됩니다.

그래서 오른쪽에 나와있는 것처럼 상위큐브에이드의 값을 먼저 계산을 하고요. 하위로 점차 내려오면서 계산을 하는 이러한 방식에 해당이 됩니다. 그래서 여기서 보면은 이 A, B, C, D 상위 차원을 먼저 계산하고요. 그 다음에 A, B, C, D, A, D와 같은 하위 차원을 계산하는 이러한 방식을 사용합니다. 여기서 사용되는 주요한 개념이 파티션이라는 개념입니다.

파티션은 어떠한 하나의 차원의 값을 공유하는 하위집합을 의미합니다. 예를 들어서 이 첫 번째 차원의 값이 A다 라고 하면은 첫 번째 차원의 값 A를 공유하는 모든 Avalidate Set, 하위셀을 이제 하나의 파티션으로 묶을 수 있습니다. 이 왼쪽에서 보면은 이 왼쪽에 있는 이 셀이 A에 대한 파티션으로 묶일 수 있습니다.

그리고 또 하나의 예시를 드리자면 이 아래에 AB라는 값이 있죠. 이 셀 같은 경우에는 첫 번째 값이 a, 두 번째 차원의 값이 b를 가지고 있습니다. 그럼 이 두 개의 값을 공유하는 또 다른 파티션을 만들 수 있습니다. 그 파티션에는 이렇게 네 개의 값이 해당이 되겠죠. 그래서 이 파티션이라는 것을 정의를 하게 됩니다.

이 파티션을 기준으로 해서 계산을 수행을 하면 어떤게 좋냐 라고 하면은 여기서는 이 아이스 버그에서 활용할 수 있는 푸르닝이라는 방법을 사용할 수 있습니다. 푸르닝은 아까 말씀드렸던 것처럼 계산을 하기 전에 미리 가지를 쳐서 그 부분을 계산을 하지 않는 그러한 방법을 의미합니다. 예를 들어서 A라는 2번 셀 있죠.

이 2번 셀이 아이스버그 컨디션을 넘지 못했습니다. 예를 들어서 최소 100개가 있어야 되는데 이 A라는 셀은 80개의 가분만 해당이 되지 않습니다. 80개의 셀만 해당이 됩니다. 그렇게 되면 이 파티션 내에서 가장 상위에 있는 셀이 결국에는 가장 집게가 많이 된 셀이기 때문에 이 아래에 있는 파티션의 다른 셀은 어차피 이 컨디션을 넘지 못하겠죠.

그래서 이 파티션을 전체 다 계산을 안 할 수 있게 됩니다. 예를 들어서 3번, AB라는 셀이 컨디션을 넘지 못했다 라고 하면 초록색 파티션에 해당되는 그 하위의 셀들을 모두 계산을 안해버릴 수 있습니다. 그래서 이 아이스버그 튜브를 계산하는데 굉장히 효율적인 방법에 해당이 됩니다. 그리고 이 계산 과정을 살펴보면 여기 1,2,3,4라고 나와 있는게 이게 계산 순서를 의미합니다.

그래서 여기서는 이 푸르닝을 활용을 하기 위해서 이것을 한번에 이렇게 계산을 하는게 아니고요. 이 각 파티션을 따라가면서 순차적으로 값을 하나씩 계산합니다. 하나를 계산을 해서 조건이 만족하는지 확인을 하고 아 그럼 버릴 건지를 확인하고 그 다음 또 하나를 계산해서 또 조건을 확인하고 아래의 파티션을 버릴건지 확인하고 이런 순차적인 과정으로 진행을 하고요 그래서 전체적인 계산 순서는 우리가 알고리즘 시간에 많이 배우는 DFS

방법과 유사하게 계산이 된다고 생각을 할 수 있습니다. 그래서 이 번호 순서대로 계산이 진행이 됩니다. 다음으로 이제 마지막 방법인데요. 마지막 방법은 굉장히 높은 차원 데이터 커뮤을 구성할 때 효과적으로 사용할 수 있는 방법입니다.

굉장히 높은 일반적으로 굉장히 우리가 사용하는 많은 테스트에서 높은 차원의 이러한 데이터가 존재할 수 있습니다. 바이오 통계 분석 뿐만 아니라 다양한 분야에서 어틀뷰트의 개수가 많은 경우가 있죠. 그런데 문제점은 이렇게 어틀뷰트 개수가 많게 되면 데이터큐브의 값은 더 빠른 속도로 증가를 하게 됩니다. 그래서 오른쪽을 보면은

이제 디멘전이 가로축인데요. 이 디멘전이 증가할 때마다 7에서 12로 증가하면 이 큐브 사이즈, 세로축의 큐브 사이즈가 굉장히 빠른 속도로 증가하는 걸 확인할 수 있습니다. 그래서 당연히 빨간색인 풀 큐브가 더 빠른 속도로, 가장 빠른 속도로 이렇게 증가하고요. 그래서 이를 좀 방지하기 위해서 우리가 앞에 얘기했던 아이스버그 큐브를 활용을 할 수 있죠.

이게 초록색의 아이스버그 큐브입니다. 아이스버그 큐브를 활용하면 큐브가 커지는 속도를 효과적으로 억제할 수 있습니다. 그래도 여전히 빠른 속도로 증가한다는 것을 알 수 있습니다. 그래서 아이스버그 큐브를 활용하는 것만으로는 이러한 데이터 큐브가 커지는 것을 완전히 억제하기는 좀 힘듭니다. 그러면 어떻게 또 이러한 큐브가 너무 커지는 것을 방지할 수 있냐고 하면

우리가 앞에서 공부했던 풀 모터 리얼라이제이션을 통해서 모든 집계값을 먼저 계산을 한 다음에 다 저장을 해놓습니다. 그런 다음에 저장된 값을 다 가져오게 되면 실제 계산을 수행할 때 이렇게 연산량이 많이 필요하지는 않겠죠. 그런데 이렇게 Full Motor Realization으로 모든 값을 다 미리 계산을 해서 저장을 했을 때는 저장 공간이 굉장히 많이 필요하게 됩니다. 두 번째로 저장 공간이 굉장히 많이 필요하게 됩니다.

많이 데이터가 저장되어 있으니까 그 데이터에 접근해서 그 데이터를 저장된 직계값을 가져오는 이 시간이 또 오래 걸릴 수가 있습니다. 그래서 이것도 이제 다 정확히 이러한 문제를 해결하는 방법이 아니고요. 그래서 이 방법을 이 문제를 해결하기 위해서 많이 활용되는 방법이 Share Fragment Approach라는 방법입니다. 이 방법 같은 경우에는 이제 다음과 같은 옵저베이션에서 시작이 되었습니다.

그래서 계속 설명드렸던 것처럼 데이터 분석을 수행을 할 때는 전체 어트리뷰트 즉 전체 디벤전이죠. 전체 디벤전을 한 번에 다 사용하는 경우는 굉장히 드뭅니다. 그래서 그 중 일부의 디벤전값만 대부분 분석에 사용을 하는데요. 그럼 여기서 생각할 수 있는게, 아 그러면 모든 디멘전에 대해서 디멘전이 크니까 그런 데이터큐브를 다 서버스페이스를 계산을 하게 되면은 경우의 수가 너무 많아지죠.

그렇게 하지 말고 어차피 일부 디멘점만 많이 활용을 하니까 그 디멘전을 여러 조각으로 쪼갭니다. 여러 조각으로 쪼개서 그 일부 디멘전을 사용해서 각각의 데이터큐브를 만들게 됩니다. 예를 들어서 100개의 디멘전을 가지고 있다. 그럼 100개의 디멘전으로 데이터큐브를 만들게 되면 이의 100승 개가 대충 나오게 되겠죠 값이.

그럼 너무 크니까 이것을 10개의 구간으로 쪼갭니다. 그러면 하나의 구간에는, 하나의 플래그먼트에는 10개의 디멘점만 존재하겠죠. 그러면 2의 10승계의 크기를 가지는 큐브를 10개 구성할 수 있습니다. 즉 10 곱하기 2의 10승계만 계산을 해 두면 되니까 굉장히 이러한 계산 양을 효과적으로 줄일 수 있습니다.

그래서 이렇게 구간을 나눠서 각각의 구간에서 데이터 큐브를 만들고요. 그 구간을 SharePlagment라고 부르고 있습니다. 그래서 셀플래그먼트마다 이런 작은 플래그먼트 큐브를 만들게 되고요. 이 플래그먼트 큐브는 미리 계산된 값에 해당이 됩니다. 그래서 각각의 플래그먼트 큐브 값을 미리 계산을 해 놓고요. 그런데 실제

쿼리가 들어왔을 때 그 플래그먼트 큐브 내에서 해결이 되는 문제면 베스트인데 여러 개의 플래그먼트 큐브의 값을 조합해서 결과값을 내야 되는 경우도 생길 수 있겠죠. 즉 더 상위 계층의 집계값을 계산을 해야 되는 그러한 경우가 생길 수 있습니다. 그러한 경우에는 그 과정을 실시간으로 계산을 진행을 해주게 됩니다. 그래서 결국에는 플래그먼트 큐브라는

일부의 집계값을 미리 계산을 해두고 나머지 더 상위 차원의 집계값을 온라인으로 실시간으로 계산을 하는 그런 방식을 사용합니다. 그래서 완전한 오프라인도 아니고 그렇다고 모든 값을 미리 계산을 해놓는 완전한 오프라인도 아니죠. 그래서 이 방식은 일반적으로 세미 온라인 컴퓨테이셔널 모델이라고 그러고 있습니다.

그래서 이 방법에 결국에는 가장 큰 장점은 미리 만약에 집계값을 계산을 해두게 되면은 장점 같은 경우에는 실시간 계산량이 굉장히 줄어들겠죠. 그래서 빨리빨리 계산 결과를 얻을 수 있지만 이제 단점은 저장 공간이 많이 들고요. 그리고 사전 계산량이 많이 소모가 당연히 되겠죠 반대로 실시간 계산을 하는 방법을 사용하게 되면 저장공간은 많이 필요가 없는데 계산속도가 굉장히 느려지게 됩니다.

그래서 이러한 해당 방식 같은 경우에는 이 둘 사이에 트레이드 오프를 적절하게 조절할 수 있습니다. 그래서 저장 미리 사전 계산한 양을 많이 늘릴 수도 있고요. 이 양을 줄이고 실시간으로 계산하는 양을 늘릴 수도 있고 이것을 좀 자유자체로 설정을 해 둘 수 있습니다. 그래서 결국에 여기 나와 있는 것처럼 High Dimensional Cube의 컴퓨팅을 Low Dimensional Cube의 Pre-Com퓨팅으로 쪼개서 연상량을 감소시킨다고 할 수 있고요.

그래서 실시간으로 쿼리가 들어왔을 때 상위, 하위 디벤저널 큐브의 계산이 필요하다면 그 부분은 실시간으로 진행을 합니다. 그리고 여기서 이 플래그먼트를 분할하고 합치는 과정에서 여기서는 손실이 발생을 하지는 않습니다. 그래서 lossless reduction 즉 원상 복귀가 다 가능한 그러한 방식을 사용을 하고 있습니다. 오늘 수업은 여기서 마치도록 하겠습니다.