퇴고

Author: getChan

_posts/2024-09-22-paper_review_presto.md

@@ -79,15 +79,15 @@ Presto는 ANSI SQL 명세를 따른다. 명세의 모든 기능을 구현한 것
 ## B. Client Interfaces, Parsing, and Planning
 1. 클라이언트 인터페이스 : 코디네이터는 주로 RESTful HTTP 인터페이스를 노출하고 CLI도 지원한다. 다양한 BI도구와 호환되는 JDBC 드라이버도 지원한다. 
 2. 파싱 : SQL문을 구문 트리로 변환하기 위해 ANTLR 기반의 파서를 사용한다. 분석기는 타입 결정, 변환, 함수 해석, 스코프, 서브쿼리, 집계, 윈도우 등을 결정하기 위해 트리를 사용한다. 
-3. 논리 계획 : 논리 플래너는 구문 트리와 분석 정보를 이용해서 plan node의 트리 형태로 인코딩된 중간 표현(IR)을 생성한다. 각 노드는 물리적 논리적 연산을 나타낸다. 계획 노드의 자식은 입력값이다. 플래너는 완전히 논리적인 노드를 생성한다. **어떻게** 계획이 실행될 지에 대한 정보는 갖지 않는다. 
+3. 논리 계획 : 논리 플래너는 구문 트리와 분석 정보를 이용해서 plan node의 트리 형태로 인코딩된 중간 표현(IR)을 생성한다. 각 노드는 물리적 논리적 연산을 나타낸다. 계획 노드의 자식은 입력값이다. 플래너는 논리적인 노드를 생성한다. **어떻게** 계획이 실행될 지에 대한 정보는 갖지 않는다. 
 
 ![](https://dt5vp8kor0orz.cloudfront.net/deb3b1023aa97d164a291e64032fa3f05d566a58/3-Figure2-1.png)
 
 ## C. Query Optimization
 논리 계획을 효율적인 실행 전략을 가진 물리적인 구조로 변환한다. 특정 지점에 도달하기까지 greedy하게 변환 규칙 집합을 평가한다. presto는 predicate, limit 푸시다운, column pruning, decorrelation 등의 룰을 가진다. 테이블과 컬럼 통계를 사용해 조인 전략 선택, 조인 재정렬 등 비용 기반의 최적화도 한다. 
   1. Data Layouts : 옵티마이저는 커넥터 Data Layout API를 통해 데이터의 물리적 layout을 알 수 있다. 커넥터는 위치, 파티셔닝, 정렬, 그룹핑, 인덱스 등 데이터 속성을 알려준다. 단일 테이블에서 다른 속성을 가진 여러 layout을 반환할 수 있다. 옵티마이저는 최적의 layout을 선택한다.
   2. Predicate Pushdown : 옵티마이저는 range와 equality predicate을 커넥터에게 전달하여 데이터를 효과적으로 필터링할 수 있다. MySQL 커넥터는 데이터가 존재하는 샤드만 조회한다. 여러 레이아웃이 있다면 predicate 컬럼에 인덱싱된 레이아웃을 선택한다. 하이브 커넥터는 partition pruning 및 파일 포맷 특징을 활용해서 성능 향상한다.
-  3. Inter-node Parallelism : 계획에서 워커간 병렬 수행될 부분(**stage**)를 식별한다. stage는 하나 이상으로 분산된다. 각각 다른 집합의 입력 데이터에서 동일한 계산을 수행한다. 엔진은 버퍼된 인메모리 데이터 전송(**shuffle**)을 통해 stage간 데이터를 전달한다. 셔플은 지연시간, 버퍼 메모리, 높은 CPU 오버헤드를 추가한다. 때문에 옵티마이저는 총 셔플 수를 신중하게 추론해야 한다.
+  3. Inter-node Parallelism : 계획에서 워커간 병렬 수행될 부분(**stage**)를 식별한다. stage는 하나 이상으로 분산된다. 각각 다른 집합의 입력 데이터에서 동일한 계산을 수행한다. 엔진은 버퍼된 인메모리 데이터 전송(**shuffle**)을 통해 stage간 데이터를 전달한다. 셔플은 지연시간, 버퍼 메모리, 높은 CPU 오버헤드를 추가한다. 때문에 옵티마이저는 총 셔플 수를 신중하게 추론한다.
   4. Intra-node Parallelism : 옵티마이저는 단일 노드에서 스레드로 병렬화할수 있는 부분을 식별한다. 이전시간 오버헤드와 상태(해시테이블 등) 이 효율적으로 스레드 간 공유될 수 있기에 노드간 병렬화보다 노드내 병렬화가 더 효율적이다. 엔진은 단일 파이프라인을 여러 스레드에서 수행할 수있다. 
 
 ![](https://dt5vp8kor0orz.cloudfront.net/deb3b1023aa97d164a291e64032fa3f05d566a58/4-Figure3-1.png) ![](https://dt5vp8kor0orz.cloudfront.net/deb3b1023aa97d164a291e64032fa3f05d566a58/5-Figure4-1.png)
@@ -107,16 +107,16 @@ task는 여러 파이프라인을 가질 수 있다. 파이프라인은 operator
 > 
 > Once the hash table is built, scan the other relation (the probe side). For each row of the probe relation, find the relevant rows from the build relation by looking in the hash table.
 
-옵티파이저는 각 파이프라인을 분할하여 독립적으로 수행하도록 병렬화할 수 있다. 위쪽 그림에서 build 파이프라인을 scan data 파이프라인과 해시 테이블을 생성하는 파이프라인으로 분할한다. 파이프라인들은 로컬 인메모리 셔플을 통해 합쳐진다. 
+옵티마이저는 각 파이프라인을 분할하여 독립적으로 수행하도록 병렬화할 수 있다. 위쪽 그림에서 build 파이프라인을 scan data 파이프라인과 해시 테이블을 생성하는 파이프라인으로 분할한다. 파이프라인들은 로컬 인메모리 셔플을 통해 합쳐진다. 
 
 쿼리 수행을 위해 엔진은 두개의 스케줄링 결정 집합을 만든다. 하나는 스테이지가 스케줄될 순서를 결정한다. 다른 하나는 스케줄될 태스크의 수를 결정한다.
 
 1. Stage Scheduling : Presto는 두개의 stage 스케줄링 정책을 지원한다.
    1. all-at-once : 모든 스테이지 수행을 동시에 스케줄링하여 시간을 최소화한다. 데이터는 가용해지자마자 처리된다. 지연시간에 민감한 유즈케이스에 적합하다.(대화형 분석, 개발자 분석, A/B 테스트)
-   2. phased : 데이터 흐름과 연결된 컴포넌트를 모두 식별하고 우선순위에 따라 스케줄링한다. 예를 들어 해시 조인에서 build 파이프라인을 먼저 수행한 뒤 probe 파이프라인을 수행한다. 이 정책은 배치 처리 들엥서 메모리 효율적이다.
+   2. phased : 데이터 흐름과 연결된 컴포넌트를 모두 식별하고 우선순위에 따라 스케줄링한다. 예를 들어 해시 조인에서 build 파이프라인을 먼저 수행한 뒤 probe 파이프라인을 수행한다. 이 정책은 배치 처리 등에서 메모리 효율적이다.
 2. Task Scheduling : 태스크 스케줄러는 계획 트리를 검사하고 leaf와 intermediate stage로 분류한다. 단말 스테이지는 커넥터로부터 데이터를 읽는다. 중간 스테이지는 중간 결과를 다른 스테이지로 처리한다.
-   1. leaf stage : 태스크 스케줄러는 네트워크와 커넥터의 제약조건을 고려하여 태스크를 워커 노드에 할당한다. 예를 들어 스케줄러는 커넥터 데이터 레이아웃을 시용하여 데이터가 있는 노드에 task를 할당한다. 대부분의 CPU 시간은 압축해제/디코딩/필터링/변환에 소요된다. 이것들은 병렬화 가능하기에 이러한 스테이지를 가능한 많은 노드에서 수행하면 빠르다. 때문에 말단 스테이지는 대부분의 워커 노드에서 수행되도록 충분한 수의 task로 쪼개진다.  
-   2. intermediate stages : 중간 스테이지 태스크들은 모든 워커 노드에 위치할 수 있지만 각 스테이지의 태스크 수는 정해져야 한다. 태스크 수는 커넥터 설정, 계획 속성,  데이터 레이아웃 등에 기반한다. 떄떄로 엔진은 동적으로 태스크 수를 변경한다. 
+   1. leaf stage : 태스크 스케줄러는 네트워크와 커넥터의 제약조건을 고려하여 태스크를 워커 노드에 할당한다. 예를 들어 스케줄러는 커넥터 데이터 레이아웃을 활용하여 소스 데이터가 있는 노드에 task를 할당한다. 대부분의 CPU 시간은 압축해제/디코딩/필터링/변환에 소요된다. 이것들은 병렬화 가능하기에 이러한 스테이지를 가능한 많은 노드에서 수행하면 빠르다. 때문에 말단 스테이지는 대부분의 워커 노드에서 수행되도록 충분한 수의 task로 쪼개진다.  
+   2. intermediate stages : 중간 스테이지 태스크들은 모든 워커 노드에 위치할 수 있지만 각 스테이지의 태스크 수는 정해져야 한다. 태스크 수는 커넥터 설정, 계획 속성, 데이터 레이아웃 등에 기반한다. 떄떄로 엔진은 동적으로 태스크 수를 변경한다. 
 3. Split Scheduling : 말단 스테이지의 태스크가 시작하면 워커 노드는 하나 이상의 스플릿을 처리한다. 분산 파일시스템에서 읽을 때 스플릿은 파일 경로와 파일의 리전 오프셋으로 구성된다. 레디스 kv 저장소에서 읽을 때 스플릿은 테이블 정보, 키, 값 형태, 쿼리할 호스트 목록으로 구성된다. 
    1. Split Assignment : 코디네이터는 스플릿을 태스크에 할당한다. Presto는 커넥터에게 스플릿의 작은 배치를 요청하고 task에게 lazy하게 할당한다. 이는 다음과 같은 이점이 있다.
    - 쿼리 응답 시간을 커넥터가 스플릿을 읽는 시간과 분리할 수 있다.
@@ -147,7 +147,7 @@ Presto의 자원 관리는 단일 클러스터에서 수백개의 쿼리를 동
    - Presto는 전체 클러스터 처리량을 최적화한다. 로컬 스케줄러는 낮은 처리시간, 쿼리간 공정한 CPU 공유를 최적화한다.
    - 태스크의 자원 사용률은 각 스플릿에 주어진 총 thread CPU 시간이다. 조정 오버헤드를 최소화하기 위해 태스크 레벨에서 CPU 사용률을 추적하고 스케줄링을 로컬에서 수행한다. 
    - Presto는 멀티태스킹 모델을 위해 모든 워커노드에 있는 태스크를 스케줄링한다. 스플릿은 CPU 점유시간 제한이 있다. 제한에 도달하지 않더라도 출력 버퍼가 가득 차거나 입력 버퍼가 비었거나 OOM이 발생하면 로컬 스케줄러는 다른 다스크를 처리한다. 따라서 CPU 사용률은 증가한다. 
-   - 실행할 태스크를 선정할 때는 태스크의 CPU 시간을 5단계로 분리한 멀티 레벨 피드백 큐를 사용한다. split의 입출력과 CPU 특성은 다양해서 공정한 멀티 태스킹을 달성하는 것은 쉽지 않다. 정규표현식과 같은 복잡한 함수는 CPU를 많이 사용하고 어떤 커넥터는 미동기 API를 지원하지 않아 스레드를 점유할 수 있다.
+   - 실행할 태스크를 선정할 때는 태스크의 CPU 시간을 5단계로 분리한 멀티 레벨 피드백 큐를 사용한다. split의 입출력과 CPU 특성은 다양해서 공정한 멀티 태스킹을 달성하는 것은 쉽지 않다. 정규표현식과 같은 복잡한 함수는 CPU를 많이 사용하고 어떤 커넥터는 비동기 API를 지원하지 않아 스레드를 점유할 수 있다.
 2. Memory Management
    1. Memory Pools
       - 유저 메모리는 데이터를 처리하는 데 추론 가능한 메모리 사용량이다. 예를 들어 집계의 메모리 사용량은 카디널리티에 비례한다.
@@ -183,7 +183,7 @@ Presto의 자원 관리는 단일 클러스터에서 수백개의 쿼리를 동
 
 ## C. File Format Features
 - Scan 오퍼레이터는 커넥터 API를 호출하고 Page라는 형대로 컬럼 기반 데이터를 받는다. 페이지는 Block의 리스트이며 각 블럭은 컬럼의 플랫 인메모리 표현이다. 플랫 메모리 자료구조는 성능상 이점이 있다. 특히 복합 타입, 포인터 추적, 언박싱, 가상 메서드 호출 등에서
-- Presto는 파일 포맷의 커스텀 reader를 전달한다. 이는 파일 헤더나 푸터의 통계(min-max ragne header and Bloom filters)로 데이터 영역을 효과적으로 생략할 수 있다. 또한 커스텀 리더는 특정 형태의 압축 데이터를 블럭으로 직접 변환할 수 있다. 
+- Presto는 파일 포맷의 커스텀 reader를 전달한다. 이는 파일 헤더나 푸터의 통계(min-max range header, Bloom filters)로 데이터 영역을 효과적으로 생략할 수 있다. 또한 커스텀 리더는 특정 형태의 압축 데이터를 블럭으로 직접 변환할 수 있다. 
 - ![](https://dt5vp8kor0orz.cloudfront.net/deb3b1023aa97d164a291e64032fa3f05d566a58/9-Figure5-1.png)
   - 딕셔너리 인코딩 블럭은 low-cardinality 압축시 효과적이다. run-length 인코딩 블럭은 반복되는 데이터를 압축한다. 페이지 간 딕셔너리를 공유하면 메모리 효율적이다. ORC파일의 컬럼은 전체 stripe(수백만row)에 단일 딕셔너리를 사용 가능하다.
 
@@ -208,6 +208,6 @@ Presto의 디자인 철학
 4. Vertical integration : Presto 팀은 성능과 효율성이 중요한 컴포넌트를 위한 커스텀 라이브러리를 설계한다. 에를 들어 커스텀 파일 리더는 presto-네이티브한 자료구조를 사용하고 변환 오버헤드를 없앤다. 라이브러리를 쉽게 디버깅하고 통제하는 것 또한 매우 중요하다.
 
 # Conclusion
-Presto. 오픈 소스 MPP(Massive Parrallel Processing) SQL 쿼리 엔진. Facebook에서 개발. 빠르게 큰 데이터셋을 처리한다. 다양한 유즈케이스에서 고성능 SQL 처리를 위해 유연하게 설계되었다. 풍부한 플러그인 인터페이스와 커넥터 API는 다양한 데이터 소스와 통합이 가능하다. 또한 적응성있게 설계되었다. 읽기 쓰기 병렬도, 네트워크 입출력, 오퍼레이터 휴리스틱, 스케줄링을 쿼리의 특성에 맞게 자동으로 조정할 수 있다. Presto의 아키텍처는 적은 지연시간을 요구하는 서비스 워크로드를 가능하게 하고 비싸고 오래 수행되는 쿼리를 효율적으로 처리한다. 
+Presto. 오픈 소스 MPP(Massive Parrallel Processing) SQL 쿼리 엔진. Facebook에서 개발. 빠르게 큰 데이터셋을 처리한다. 다양한 유즈케이스에서 고성능 SQL 처리를 위해 유연하게 설계되었다. 풍부한 플러그인 인터페이스와 커넥터 API는 다양한 데이터 소스와 통합이 가능하다. 또한 적응성있게 설계되었다. 읽기/쓰기 병렬도, 네트워크 입출력, 오퍼레이터 휴리스틱, 스케줄링을 쿼리의 특성에 맞게 자동으로 조정할 수 있다. Presto의 아키텍처는 적은 지연시간을 요구하는 서비스 워크로드를 가능하게 하고 비싸고 오래 수행되는 쿼리를 효율적으로 처리한다.
 
 Presto는 단일 SQL시스템으로 여러 분석 유즈케이스를 수행할 수 있게 한다. 여러 저장 시스템에 쉽게 쿼리하고 1000개 노드까지 확장 가능하다. 아키텍처와 설계는 붐비는 SQL-on-Bigdata 시장에서 틈새를 찾았다.