[요약 정리] 3-2. 쿼리 엔진

3-2. 쿼리 엔진

데이터 마트 구축의 파이프 라인

1. 분산 스토리지에 저장된 데이터를 구조화하고 열 지향 스토리지 형식으로 저장
   • 다수의 텍스트 파일을 읽어 들여 가공하는 부하가 큰 처리이기 때문에 Hive 이용
2. 완성한 구조화 데이터를 결합, 집계하고 비정규화 테이블로 데이터 마트에 써서 내보냄
   • 열 지향 스토리지를 이용한 쿼리의 실행에는 Presto를 사용함으로써 실행 시간을 단축
3. Hive에서 만든 각 테이블의 정보는 Hive 메타 스토어에 저장됨
   • Hive 뿐 아니라 다른 SQL-on-Hadoop의 쿼리 엔진에서도 공통의 테이블 정보로 참고됨

 

Hive에 의한 구조화 데이터 작성(csv 형식의 액세스 로그 파일을 처리할 때의 예시)

•  Hive를 비롯한 대부분의 쿼리 엔진은 MPP 데이터베이스처럼 데이터를 내부로 가져오지 않아도 텍스트 파일을 그대로 집계할 수 있음 but, csv를 그대로 집계하는 것은 비효율적임 (쿼리를 실행시킬 때마다 매번 텍스트를 읽음 200만 레코드 기준 8초) →열지향 스토리지로 변환한다

 

열 지향 스토리지로의 변환 - 데이터 집계의 고속화(배치형 쿼리 엔진용)

• 테이블을 열 지향 스토리지 형식인 ORC형식으로 변환(데이터 구조화) → 테이블 집계시 1.5초까지 단축

 

Hive로 비정규화 테이블을 작성하기

• 비정규화 테이블 만들기
• 시간이 걸리는 배치 처리는 원칙적으로 Hive를 사용해야 함
• Hive 쿼리를 개선하는 예
  • 서브 쿼리 안에서 레코드 수를 줄이는 방법
  • 데이터의 편향을 방지하는 방법

 

서브 쿼리 안에서 레코드 수 줄이기 - 초기 단계에서 팩트 테이블 작게하기

• 데이터베이스가 아닌 데이터 처리를 위한 배치 처리 구조
• 읽어 들이는 데이터의 양을 의식하면서 쿼리 작성
• 초기에 팩트 테이블을 작게

 

# 비효율 적인 쿼리
# 테이블을 결합한 수에 WHERE로 검색
SELECT ...
FROM access_log a
JOIN users b ON b.id = a.user_id
WHERE b.created_at = '2017-01-01'


# 보다 효율적인 쿼리
SELECT ...
FROM(
	# 처음에 시간으로 팩트 테이블 검색
    SELECT * access_log
	WHERE time >= TIMESTAMP '2017-01-01 00:00:00'
) a
JOIN users b ON b.id = a.user_id
WHERE b.created_at = '2017-01-01'

 

 

데이터 편향 피하기 - 분산 시스템의 성능 발휘를 위해

• 분산 시스템에서 SELECT distinct count 를 실행하는 것은 다른 처리보다 시간이 오래 걸림 → 중복이 없는 값을 세려면 데이터를 한곳에 모아야 해서 분산처리가 어렵
• distinct count는 분산되지 않아도 GROUP BY에 의한 그룹화는 분산 처리됨
• 웹페이지당 고유 방문자 수를 알려할 때
  • 웹페이지의 조회수에는 페이지 별로 조회수 편차가 큼
  • 하나의 페이지만 다른 페이지보다 100배의 접속이 발생했을 경우 그 웹페이지에 대한 distinct count만 극단적으로 늦어지고 전체적인 쿼리 실행 시간이 늘어나게 됨 → 데이터의 편향 문제

 

# 비효율적인 쿼리
# distinct count 분산되지 않음
SELECT date, count(distinct user_id) users
FROM access_log GROUP_BY date


# 보다 효율적인 쿼리
SELECT date, count(*) users
FROM (
	# 최초에 중복을 없앰
    SELECT DISTINCT date, user_id FROM access_log
) t
GROUP BY date

 

 

대화형 쿼리 엔진 Presto의 구조

- Presto로 구조화 데이터 집계하기

플러그인 가능한 스토리지 - 하나의 쿼리 안에서 여러 데이터 소스에 연결 가능

• 일반적인 MPP 데이터베이스에서는 스토리지와 컴퓨팅 노드가 밀접하게 결합되어 있어 처음에 데이터를 로드하지 않으면 집계를 시작할 수 없음
• Presto는 전용 스토리지를 갖고 있지 않으므로 Hive와 마찬가지로 다양한 데이터 소스에서 직접 데이터를 읽어들임
• Presto가 성능을 최대한 발휘하려면 원래 스토리지가 열 지향 데이터 구조로 되어있어야 함
• ORC 형식의 로드에 최적화되어 있으며, 확장성이 높은 분산 스토리지에 배치하여 최대의 성능 발휘
• 데이터의 로딩 속도를 높이려면 Presto 클러스터를 분산 스토리지와 네트워크의 가까운 곳에 설치한 후에 그것들을 가능한 한 고속 네트워크에 연결하도록 해야함
• 하나의 쿼리 안에서 분산 스토리지 상의 팩트 테이블과 MySQL의 마스터 테이블을 조인할 수 있음

 

CPU 처리의 최적화 - 읽기와 코드 실행 병렬 처리

• Presto는 SQL의 실행에 특화된 시스템, 쿼리를 분석하여 최적의 실행 계획을 생성하고, 그것을 자바 바이트 코드로 변환
• 바이트 코드는 Presto의 워커 노드에 배포되고, 런타임 시스템에 의해 기계 코드로 컴파일
• 코드의 실행은 멀티 스레드화되어 단일 머신에서 수백 태스크나 병렬로 실행됨
• 열지향 스토리지에서의 읽기도 병렬화되어 데이터가 도달할 때마다 처리가 진행
• Presto의 CPU 이용 효율이 높으므로 메모리와 CPU 리소스만 충분하다면 데이터의 읽기 속도가 쿼리의 실행 시간을 결정하게 됨
• Presto 쿼리는 일단 실행이 시작되면 중간에 끼어들 수 없기 때문에, 너무 큰 쿼리를 실행해서는 안됨

 

인 메모리 처리에 의한 고속화 - 쿼리 실행에는 가급적 대화형 쿼리엔진 사용

• 쿼리의 실행 과정에서 디스크에 쓰기를 하지않음
• 모든 데이터 처리를 메모리상에서 실시하고 메모리가 부족하면 여유가 생길 때까지 기다리거나 오류로 실패
• 데이터 양이 아무리 많아도 그에 비례하여 메모리 소비가 늘어나지는 않음
• 메모리상에서 할 수 있는 것으느 메모리상에서 실행하고, 디스크가 있으야 하는 일부 데이터의 처리는 Hive에 맡기는 것이 효과적

 

분산 결합과 브로드캐스트 결합

• Presto는 기본적으로 분산결합 실시 → 같은 키를 갖는 데이터는 동일한 노드에 모임
• 분산 결합에서는 노드 간의 데이터 전송을 위한 네트워크 통신이 발생하기 때문에 종종 쿼리의 지연을 초래함
• 한쪽 테이블이 충분히 작은 경우에는 브로드캐스트 결합을 사용하여 처리 속도 고속화
• 브로드캐스트 결합을 유효로 하려면 분산 결합을 명시적으로 무효화해야함
• 쿼리 안의 SELECT 문으로 먼저 팩트 테이블을 지정하여 그것에 디멘전 테이블을 결합해야 함

 

열 지향 스토리지 집계 - Presto에 의한 집계

 

데이터 분석의 프레임워크 선택하기

- MPP 데이터베이스, Hive, Presto, Spark

MPP 데이터베이스 - 완성한 비정규화 테이블의 고속 집계에 적합

• 스토리지 및 계산 노드가 일체화되어 있어 처음에 ETL 프로세스 등으로 데이터를 가져오는 절차 필요
• 확장성, 유연성 측면에서 유리
• 시각화를 위한 데이터 마트로 유력한 대안

 

Hive - 데이터양에 좌우되지 않는 쿼리 엔진

• 무거운 처리는 Hive에서 처리하는 것이 적합
• Hive의 장점은 대화성이라기보다 안정성에 있음

 

Presto - 속도 중시 & 대화식으로 특화된 쿼리엔진

• Hive와 정반대인 쿼리엔진
• 실행 중에 장애가 발생하면 처음부터 다시 실행, 메모리가 부족하면 쿼리 실행 못함
• 윈도우 함수를 비롯한 표준 SQL 준수
• 대화식 쿼리에 특화되어 있기 때문에 텍스트 처리가 중심이 되는 ETL 프로세스 및 데이터 구조화에는 적합하지 않음
• 데이터 구조화에는 Hive와 Spark를 사용하는 편이 좋음

 

Spark - 분산 시스템을 사용한 프로그래밍 환경

• ETL 프로세스에서 SQL에 이르기 까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술할 수 있음
• 메모리를 어떻게 관리하느냐가 중요

 

Mesos - YARN보다 더 엄격한 리소스 제어, OS 수준의 가상화 기술 사용

 

 

[출처]

빅데이터를 지탱하는 기술 - 니시다 케이스케