빅데이터의 탐색

 

💡크로스 집계의 기본💡

 

✔️ 트랜잭션 테이블, 크로스 테이블, 피벗 테이블

 

크로스 테이블

 

행과 열이 교차하는 부분에 숫자 데이터가 들어가기 때문에 이를 크로스 테이블이라고 부름

 

=> 사람이 보기에는 편한 보고서이지만, 데이터베이스에서는 다루기 어려운 데이터 형식임

(DB에서 행을 추가하는 것은 간단하지만, 열을 늘리는 것은 간단하지 X)

 

 

트랜잭션 테이블

 

따라서, 보고서의 바탕이 되는 데이터는 행 방향으로만 증가하게 하는게 좋은데 이것을 트랜잭션 테이블이라고 함

 

트랜잭션 테이블에서 크로스 테이블로 변환하는 과정을 크로스 집계라고 함

소량의 데이터를 크로스 집계하는데 편리한 것이 스프레드시트의 피벗 테이블 기능임

 

 

피벗 테이블에서는 행과 열이 교차하는 부분의 값은 자동으로 집계됨

 

결과를 크로스 테이블에 정리할 뿐만 아니라 그래프로 시각화한 피벗 그래프 기능도 있음

 

=> 많은 시각화 도구의 내부 원리는 이와 같으며, 크로스 집계는 데이터를 시각화하는 기초가 됨

 

✔️ 룩업 테이블

 

트랜잭션 테이블에 새로운 항목을 추가하는게 아니라, 다른 테이블과 결합하고 싶은 경우에 사용되는 것이 룩업 테이블임

 

 

=> 상품 ID를 사용하여 상품명과 상품 카테고리를 참고하는 형태

 

트랜잭션 테이블과 룩업 테이블은 서로 독립적으로 관리할 수 있음

(트랜잭션 테이블은 업무 데이터베이스등에서 가져오고 룩업 테이블은 데이터 분석 용도에 따라 변경해도 상관 X)

=> 상품 카테고리 등은 자유롭게 바꿀 수 있는 편이 분석하는데 보다 편리함

 

 

✔️ SQL에 의한 테이블의 집계

 

피벗 테이블에 의한 크로스 집계 : 간편 하지만 데이터의 양이 너무 많으면 처리할 수 X

 

BI 도구와 pandas에 의한 크로스 집계 : 수백만 레코드는 집계할 수 있지만 그 이상이 되면 너무 느려서 쓸 수 X

 

=> 대량의 데이터를 크로스 집계하려면 SQL을 사용하여 (sum과 같은 집계 함수) 데이터양 감소를 고려할 필요가 있음

 

만약 업무 DB에 판매 이력이 저장되어 있으면 모든 것을 꺼내 크로스 집계하는 것이 아니라 먼저 SQL로 집계함

=> 월간 판매 이력을 알고싶으면 SQL을 작성해서 다달이 데이터를 집계함

 

SELECT date_trunc('month', "매출일"):: DATE AS "매출일",
       "점포 ID",
       "상품 ID",
       "고객 ID",
       sum("금액") AS "금액"
FROM "판매 이력"
GROUP BY 1, 2, 3, 4

 

이런 예시가 있을 수 있는데 SQL의 실행 결과가 크로스 테이블이 아니라 트랜잭션 테이블의 형태로 되어 있음

 

=> 이를 크로스 집계함으로써 임의의 크로스 테이블을 얻을 수 있음

 

 

 

데이터 집계에 뛰어는 SQL과 크로스 집계에 뛰어난 시각화 도구를 결합함으로써 이론상 무한히 많은 데이터가 있더라도 크로스 집계가 가능함!

 

 

✔️ 데이터 집계 => 데이터 마트 => 시각화

 

데이터의 집계와 시각화 사이에 있는 것이 데이터 마트이다!

 

데이터 마트의 크기가 작다면 시각화하는 것은 간단하지만 동시에 원래 데이터에 포함된 정보를 잃어버리게 되어 피벗 테이블과 BI 도구를 사용해 대화적인 데이터를 검색한다면 정보 부족으로 곤란한 상황에 처할 수 있음

 

반대로 데이터 집계의 프로세스에서 가능한 많은 정보를 남기게 되면, 데이터 마트가 거대화되어 좋은 시각화를 할 수 없게 될 수 있음

 

둘은 trade off 관계에 있기에 필요에 따라 어느 정도의 정보를 남길 것인가를 결정해야 함!

=> 최종적으로는 데이터 마트의 크기에 따라 시스템 구성이 결정됨

 

 

💡열 지향 스토리지에 의한 고속💡

 

메모리에 다 올라가지 않을 정도의 대량의 데이터를 신속하게 집계하려면, 미리 데이터를 집계에 적합한 형태로 변환하는 것이 필요함!

 

 

✔️ 데이터베이스의 지연을 줄이기

 

데이터양이 증가함에 따라 집계에 걸리는 시간은 길어짐

 

(대기 시간이 늘어나면 작업을 멈추거나 대기 후에 여러 작업을 병행하게 되어 모든 작업이 느려짐)

 

=> 초 단위로 데이터를 집계하려면 처음부터 그것을 예상해서 시스템을 마련해야 함!

 

 

3계층의 데이터 집계 시스템

 

원 데이터는 용량적인 제약이 적어서 대량의 데이터를 처리할 수 있는 데이터 레이크와 데이터 웨어하우스에 저장함

 

=> 원하는 데이터를 추출하여 데이터 마트를 구축함

(여기서는 항상 초 단위의 응답을 얻을 수 있도록 함)

 

데이터 처리의 지연

 

데이터 마트를 만들 때는 가급적 지연이 적은 데이터베이스가 있어야 하는데 크게 2가지 선택이 있음

 

1. 모든 데이터를 메모리에 올림

 

한 레코드 크기가 500바이트라고 하면 천만 레코드의 경우 5GB가 되는데 그 정도의 데이터양이라면 MySQL이나 PostgreSQL 등의 일반적인 RDB가 데이터 마트에 적합함

 

=> RDB는 원래 지연이 적고, 많은 수의 클라이언트가 동시 접속해도 성능이 나빠지지 않으므로 많은 사용자가 사용하는 실제 운영 환경의 데이터 마트로 특히 우수함!

 

(하지만 메모리가 부족하면 RDB의 성능이 급격히 저하된다.. 수억 레코드를 초과하는 데이터 집계에서는 항상 디바이스 I/O가 발생한다고 가정하고 어떻게 효율화 할지를 고민해야함)

 

 

2. 압축과 분산에 의해 지연 줄이기 (MPP 기술)

 

 

고속화를 위해 사용되는 기법이 압축, 분산 이다!

 

=> 데이터를 가능한 한 작게 압축하고 그것을 여러 디스크에 분산함으로써 데이터의 로드에 따른 지연을 줄인다

 

분산된 데이터를 읽어 들이려면 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 것이 효과적인데 이러한 아키텍처를 MPP(massive parallel processing : 대규모 병렬 처리)라고 한다!

 

(MPP는 데이터 집계에 최적화되어 있음)

 

=> 대량의 데이터를 분석하기 위해 데이터베이스에서 널리 사용됨 (Redshift, BigQuery 등)

 

 

✔️ 열 지향 데이터베이스 접근

 

빅데이터로 취급되는 데이터 대부분은 디스크 상에 있기 때문에 쿼리에 필요한 최소한의 데이터만을 가져옴으로써 지연이 줄어들게 됨

 

=> 이를 위해 사용되는 방법이 칼럼 단위로의 데이터 압축임

 

일반적으로 업무 시스템등에서 사용되는 DB는 레코드 단위의 읽고 쓰기에 최적화 되어 있는 행 지향 데이터베이스 임!

 

(Oracle, MySQL과 같은 일반적인 RDB가 여기에 해당)

 

이에 반해 데이터 분석에 사용되는 데이터베이스는 칼럼 단위의 집계에 최적화 되어 있으며 '열 지향 데이터베이스' 또는 '컬럼 지향 데이터베이스' 라고 함!

 

(Teradate와 Amazon Redshift 등이 여기에 해당)

 

데이터 처리의 성능은 두 종류 숫자로 자주 표시되는데

1. 일정 시간에 처리할 수 있는 데이터의 양(처리량)

=> 배치 처리 등의 대규모 데이터 처리에서 중요시 됨 (데이터 레이크, 데이터 웨어하우스)

2. 데이터 처리가 끝날 때까지의 대기 시간(지연)

=> 애드 훅 데이터 분석 등에서 중시(데이터 마트)

(데이터 마트에서 요구되는 것은 시간의 단축이므로 충분한 메모리를 준비하거나 디스크 I/O 절감이 필수적)

 

 

행 지향 데이터베이스

 

행 지향 데이터베이스에서는 테이블의 각 행을 하나의 덩어리로 디스크에 저장한다

 

(새 레코드를 추가할 때 파일의 끝에 데이터를 쓸 뿐이므로 빠르게 추가할 수 있음)

 

=> 매일 발생하는 대량의 트랜잭션을 지연 없이 처리하기 위해 데이터 추가를 효율적으로 할 수 있도록 함

 

행 지향 데이터베이스에서는 데이터 검색을 고속화하기 위해 인덱스(index)를 만듬

=> 인덱스가 없으면 저장되는 모든 데이터를 로드해야 원하는 레코드를 찾게 되므로 디스크 I/O로 인한 성능 저하 가 발생

(적절한 인덱스가 사용되도록 튜닝하는게 중요함)

 

그래도 데이터 분석에서는 어떤 칼럼이 사용되는지 미리 알 수 없기 때문에 인덱스를 작성해도 거의 도움이 되지 X

 

(필연적으로 디스크 I/O를 동반함)

=> 인덱스에 의지하지 않는 고속화 기술이 필요함

 

열 지향 데이터베이스

 

 

데이터 분석에서는 종종 일부 칼럼만이 집계 대상이 됨

(행 지향의 경우 레코드 단위로 데이터가 저장되어 있으므로 필요 없는 열까지 디스크로부터 로드)

 

=>열 지향 데이터베이스는 데이터를 미리 칼럼 단위로 정리해 둠으로써 디스크 I/O를 줄임!

 

(집계하는 데는 고속이지만, 저장하는 데는 시간이 걸림)

 

같은 칼럼에는 종종 유사한 데이터가 나열됨

=> 데이터의 압축 효율도 우수함

 

압축 방식이 궁금해서 찾아본 GPT의 답변

 

 

✔️ MPP 데이터베이스의 접근 방식

 

쿼리 지연을 줄일 또 다른 방법은 MPP 아키텍처에 의한 데이터 처리의 병렬화임!

 

행 지향 데이터베이스에서는 보통 하나의 쿼리는 하나의 스레드에서 실행됨

 

=> 각 쿼리는 충분히 짧은 시간에 끝나는 것으로 생각하므로, 하나의 쿼리를 분산 처리하는 상황은 가정 X

(많은 쿼리를 동시에 실행함으로써 여러 개의 CPU 코어를 활용할 수는 있음)

 

하지만, 열 지향 데이터베이스에서는 디스크에서 대량의 데이터를 읽기 때문에 1번의 쿼리 실행 시간이 길어진

또한, 압축된 데이터의 전개 등으로 CPU 리소스를 필요로 하므로 멀티 코어를 활용하여 고속화 하는 것이 좋음

 

 

 

여러 디스크에 분산된 데이터가 서로 다른 CPU 코어에 의해 읽혀 부분적인 쿼리 실행이 이루어지고 그 결과들이 한 곳에 모여 최종적인 결과가 출력됨

 

=> MPP에서는 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 가능한 한 병렬로 실행함

 

MPP 데이터베이스와 대화형 쿼리 엔진

 

쿼리를 잘 병렬화할 수 있다면, MPP를 사용한 데이터의 집계는 CPU 코어 수에 비례하여 고속화됨!

 

(단, 디스크로부터의 로드가 병목 현상이 발생하지 않도록 데이터가 고르게 분산되어 있어야 함)

 

MPP는 구조상, 고속화를 위해 CPU와 디스크 모두를 균형 있게 늘려야 하므로 일부 제품은 하드웨어 + 소프트웨어가 통합된 제품으로 제공됨

=> 이렇게 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스를 MPP 데이터베이스라고 함

 

 

이런 MPP 아키텍처는 Hadoop과 함께 사용되는 대화형 쿼리 엔진으로도 채택되고 있음

 

=> 이 경우 데이터를 저장하는 것은 분산 스토리지의 역할이므로 데이터를 열 지향으로 압축하지 않는 한 MPP 데이터베이스와 동등한 성능은 되지 못함!

 

(분산 스토리지 시스템은 데이터를 블록 단위로 저장하고 읽음)

 

=> 따라서, Hadoop 상에서 열 지향 스토리지를 만들기 위해 여러 라이브러리가 개발되고 있음

 

열 지향 스토리지 + MPP로 데이터의 집계가 크게 고속화 되지만 이에 따라 쿼리의 리소스 사용랑도 많이 증가함

=> 쿼리가 다수의 코어를 활용하는 것은 시스템의 모든 컴퓨터 리소스를 쉽게 소진해 버린다는 뜻

따라서, 리소스 소비를 제한하는 등의 규칙이 필요함