[책정리]빅데이터를 지탱하는 기술2-2.열지향 스토리지에 의한 고속화

6월 선정도서 - 빅데이터를 지탱하는 기술

선정계기 - 데이터가 쌓이고 흐르는 전체적인 구조를 깊이 있게 이해할 수 있고,

미래의 데이터엔지니어로써 해야하는 업무들의 전반적인 흐름을 파악할 수 있을 것 같아 선정(기대가 된다

 

목차 

챕터2. 빅데이터의 탐색

2-1. 크로스집게계의 기본 

2-2. 열지향 스토리지에 의한 고속화

2-3. 애드혹 분석과 시각화 도구(주피터/Redash/Superset/Kibana)

2-4. 데이터마트의 기본구조 

 

---

데이터베이스 지연줄이기

데이터 기반 서비스를 운영하려면, 데이터 마트를 구축하여 초 단위로 처리가 이루어져야 한다.

어떻게 데이터를 빨리 처리하게 만들 수 있는가? 

데이터 처리응답이 빠르다 = 대기시간이 적다 = 지연이 적다 = 데이터마트를 만들때 필요한 데이터베이스의 조건

 

가장 간단한 방법은 모든 데이터를 '메모리'에 올리는 것 

메모리양에 맞는 정도의 데이터양을 넣는다면 큰 지연이 발생하지 않는다. 

대략적으로 전체 데이터의 양이 5GB가 되는 정도라면, MySQL이나 PostrgreSQL등 일반적인 RDB가 데이터마트에 적합

RDB는 지연이 적고, 다수의 클라이언트 동시접속해도 성능이 나빠지지 않아서 데이터마트로 특히 우수

다만, 메모리가 부족하면 데이터를 집계하기 위해 항상 IO가 발생해서 성능이 급격히 저하된다. 

 

또는 MPP아키텍쳐를 기반으로 데이터를 가능한 작게 '압축'하고, 여러 디스크에 '분산'한다.

분산된 데이터를 읽기 위해 멀티코어를 활용하면서 디스크IO를 병렬처리한다. 

MVPP(Massive Paralled Processing)은 대규모병렬처리로 대량의 데이터를 분석하기 위해

AWS RedShift와 구글빅쿼리 에서 널리 사용되고 있다. 

MVPP는 데이터집계에 최적화되어 있으며, 데이터웨어하우스와 데이터분석용 데이터베이스에서 특히 많이 사용된다. 

 

열지향 데이터베이스 접근

빅데이터로 취급되는 데이터들은 대부분 '디스크'상에 있다. 

디스크에 최소한으로 접근하거나, 쿼리에 필요한 최소한의 데이터만을 가져오는 것이
데이터를 빨리 처리 할 수 있는 근본적인 방법. 

 

행지향 데이터베이스 

일반적인 데이터베이스(Oracle, MySQL 등) 는 '레코드'단위로 '읽고 쓰기'에 최적화되어 있다. 

테이블의 각 행을 하나의 덩어리로 디스크에 저장한다.

그리고 새 레코드를 추가할때는 파일의 끝에 데이터를 쓰기 때문에 빠르게 추가할 수 있다. 

또한 일반적인 데이터베이스에서는 '인덱스'를 통해 검색을 빠르게 할 수 있다.

인덱스가 없다면 저장되는 모든 데이터를 로드하여 원하는 레코드를 찾을 수 있어서 디스크IO가 발생하기 떄문.

행지향 데이터베이스 : 레코드단위로 읽기/쓰기에 최적화, 빠르게 데이터 추가 가능 

그러나 데이터분석에서는 어떤 칼럼이 사용되는지 미리 알수 없어서 인덱스가 검색 성능향상에 도움이 되지 않는다.

필연적으로 대량의 데이터분석엔 디스크IO가 동반한다. 인덱스에 의지하지 않는 고속화 기술이 필요하다.

 

열지향 데이터베이스

데이터분석에서 사용되는 데이터베이스(AWS RedShift)는 '칼럼단위'로 '집계'에 최적화되어 있따. 

테이블의 칼럼별로 데이터를 보관한다. 그래서 데이터를 저장하는데 시간이 걸린다.

이때 데이터를 미리 칼럼단위로 압축시켜두었기 때문에 필요한 칼럼만 빠르게 읽어 디스크IO를 줄일 수 있다. 

열지향 데이베이스 : 칼럼단위로 집계에 최적화, 빠르게 필요한 컬럼만 읽기 가능

데이터압축효율도 우수하다. 

같은 칼럼에 유사한 데이터가 나열되지만 같은 문자열의 반복등 데이터를 매우 작게 압축시킬 수 있다.

행지향 데이터베이스에 비교하면 1/10이하로 압축가능

 

쿼리의 실행시간이 길어진다. 

디스크에서 대량의 데이터를 읽기 때문에 아무래도 1전의 쿼리실행시간이 길어진다.

또한 압축된 데이터를 다시 풀어헤져야하는 등 CPU 리소스를 필요하므로 멀티코어를 활용하여 고속화 권장

반면에 행지향 데이터베이스는 각 쿼리는 충분히 짧은 시간내에 끝나는것으로 본다.

보통 하나의 쿼리가 하나의 스레드에서 실행되는데, 여러개의 CPU코어를 사용한다고 해도 쿼리가 분산되진 않는다. 

 

MPP아키텍쳐

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

열지향 데이터베이스에서 쿼리의 실행시간이 길어지면

하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 가능한 병렬로 실행하는 방법이다. 

예를 들어 1억개의 레코드로 이루어진 테이블의 합계를 구하려고한다면 

데이이터를 10만 레코드씩 나눠 1000개의 테스트로 분할하는 것이다.

그리고 분할된 테스크는 각각 독립적으로 10만레코드의 합계를 집계하는 분산처리를 수행하고,

마지막에 각 분산처리결과들을 모아 총합계를 계산한다. 

 

MPP방식 

MPP데이터베이스에서는 여러디스크에 분산된 데이터가 서로다른 CPU코어에 의해 읽혀 부분적인 쿼리실행.

그 결과들을 한곳에 모이고 최종적인 결과를 출력하는데. 이런 처리들을 간으한 동시에 병렬로 처리한다. 

 

MPP를 사용한 데이터집계는 CPU코어수에 비례하여 고속화된다.

단 디스크로부터 로드가 병목현상이 발생하지 않도록 데이터가 고르게 분산되어 있어야한다. 

 

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

MPP데이터베이스

하드웨어 수준에서 데이터집계에 최적화된 데이터베이스

구조상 고속화를 위해 CPU와 디스크 모두 균형있게 늘려야하기 때문에 일부제품은 HW와SW를 통합하여 제공.

MPP데이터베이스를 사용하면 데이터마트의 지연을 작게 만들기 위해 열지향 스토리지 형식으로 저장할 수 있다. 

 

열지향스토리지와 MPP개념을 결합함으로써 데이터의 집계가 고속화된다.

하지만 쿼리의 리소스 사용량도 증가한다. 하나의 쿼리가 다수의 코어를 활용해서 리소스를 쉽게 소진할 수도 있음.

이러한 과부하를 방지하기 위해 시스템마다 리소스제한이 있을수도 있다. 없다면 주의깊은 감시필요.

예를 들어 장시간동안 계속동작하는 쿼리가 있으면 강제종료 등 규칙 필요. 

 

대화형쿼리엔진

MPP 아키텍쳐를 하둡과 함께 사용하면 '대화형쿼리엔진'이 될 수 있음

쿼리실행지연을 작게 만들면서 작은쿼리를 여러번 실행하는 대화형 데이터처리가 가능하고,

분산스토리지의 역할로 데이터를 저장할 수 있다. 

 

그러나 데이터를 열지향으로 압축하지 못하면 MPP 데이터베이스와 동일한 성능이 안된다.

그래서 하둡안에서 열지향 스토리지를 만들기 위한 라이브러리 사용 

 

어느쪽을 선택할지는 떄에 따라 다르다. 

시스템의 안정성과 서포트 체제의 측면에선 MPP데이터베이스, 하둡과 궁합을 고려하면 대화형쿼리엔진.

 

결론적으로 데이터 처리응답이 빠른 데이터마트를 위해 아래의 3가지 기술을 사용할 수 있다. 

• 행지향 데이터형식을 가진 RDB
• 열지향 데이터형식을 가지고, 하드웨어와 일체형인 MPP데이터베이스
• 열지행 데이터형식에, 분산스토리지에 보관하는 대화형쿼리엔진