LOCAT: Low-Overhead Online Configuration Auto-Tuning of Spark SQL Applications 리뷰

LOCAT 논문 리뷰!

 

* 본 글에 첨부한 ppt 자료는 글쓴이가 제작한 ppt 자료입니다.

   궁금한 점이나 잘못된 부분 언제든지 댓글로 남겨주세요!

 

Introduction

Spark SQL application의 configuration parameter를 튜닝하는데 있어서 두가지 challenge가 존재한다.

첫번째는 Spark와 Spark SQL의 configuration parameter의 수가 너무 많다는 점.

두번째는 configuration parameter가 서로 영향을 미치기 때문에 튜닝을 하는데 어려움이 있다는 점이다.

=> 여기까지는 모든 튜닝 논문에서 얘기하는 challenge였음

 

최근들어 ML을 통해 Spark 튜닝하는 방법에 대한 연구가 많이 진행되고 있지만  ML-based에도 두가지 결점이 있다.

첫번째는 training sample을 수집하는데 너무 오랜 시간이 걸린다는 점.

두번째는 Spark SQL application의 input data size 변화가 ML-based에서는 적용이 어렵다는 점이다.

-> ML같은 경우에는 input feature가 고정되어 있는데 input data size가 변화되면 ML learning이 어렵다.

-> 여기서 input data size : input는 knob인데 knob을 각 다른 workload마다 적용했을 때의 결과가 다름.

그렇기때문에 LOCAT에서는 세가지 innovation을 가지고 새로운 model을 제안한다.

첫번째, 각 Spark SQL application은 각기 다른 configuration에 미치는 sensitivity가 다르기때문에 configuration에 대해 sensitivity가 높은 쿼리만 튜닝에 사용하겠다고 한다.

두번째, input data size의 변화때문에 ML을 사용하지 못한다는 단점을 해결하기위해 Datasize-Aware Gaussian Process(DAGP)를 제안한다.

세번째, configuration parameter에 대해서도 영향력이 높은 configuration parameter를 추출하고 Cayesian Optimization iteration을 통해서만 튜닝을 진행한다.

 

Spark SQL Framework

다음은 Spark SQL의 framework인데 사실 완전히 이해를 하지는 못했다.ㅠㅠ

일단 Application은 여러개의 쿼리로 이루어져 있고 각각의 쿼리는 DAG로 변환된다. 그 안에서의 stage 1과 stage 2는 각각 upper level, lower level로 나뉘어진다. Upper level(stage 1)은 Spark SQL의 성질을 나타내는 configuration parameter (ex. spark.sql.autoBroadcastJoinThreshold) 를 나타내고 Lower level(stage 2)는 Spark의 core에 관련된 configuration parameter를 나타낸다. (ex. spark.executor.cores and spark.executor.instances)

그래서 서로의 executor와 core의 수를 곱해서 Spark SQL 클러스터에서 실행될 수 있는 최대의 task를 결과로 낸다.

 

LOCAT Architecture

드디어! LOCAT의 아키텍쳐이다.

먼저 sample collecting을 한다.

1. Query Configuration Sensitivity Analysis (QCSA)

각 쿼리를 여러개의 configuration에 대해서 실행을 시킨 후 configuration에 대해서 sensitive가 높은 쿼리들을 추출해낸다. (sensitive가 높다는건 configuratio parameter의 value를 변경했을 때 많은 영향을 받는 쿼리를 sensitive가 높다고 표현)

 

2. Identifying Important Configuration Parameters (IICP)

보통의 튜닝 과정처럼 영향력이 높은 configuration parameter를 추출해낸다. LOCAT에서는 두가지 방법을 합쳐서 이 과정을 수행한다.

 

3. Datasize Aware Gaussian Process (DAGP)

위 단계에서 골라진 configuratio parameter와 input data size를 넣어서 BO의 surrogate model을 통해 줄여진 쿼리 space에 대해 적합한 configuration을 찾는다.

 

자 그럼 이제 QCSA에 대해 알아보장,,

 

QCSA

일단 앞에서 얘기했던 것처럼 쿼리의 수가 너무 많으면 tuning을 하는데 시간이 너무 오래걸리기 때문에 sensitive한 쿼리를 골라내는 과정이다.

일단 쿼리 하나씩을 여러개의 configuration에 대해 BO with DAGP(뒤에 설명)로 실행시키고 QCSA는 각 실행시간을 저장한다. 이후에 Coefficient of Variation을 구한다. (sensitivity를 구하기 위해!)

여기서 t_qij는 i번째 쿼리는 j번째 실행시켰을 때의 실행시간을 뜻하고 t_qi바 (아오.. 블로그에선 어떻게 표현하는지 모르겠다) 는 i번째 쿼리의 전체적인 실행시간의 평균을 뜻한다.

 

QCSA

자 이제 CV를 구했기 때문에 어떤 임계점을 통해서 이 쿼리가 sensitive한지 insensitive한지 구별을 해줘야하는데 서로 다른 쿼리에 대한 CV의 값 범위는 크게 다를 수 있기 때문에 어떤 절대적인 숫자를 임계점으로 할 수 없다.

그렇기 때문에 Width_CV의 식을 통해 CV를 high, medium, low 세 단계로 분류한다.

이후에 3번에 있는 식에 해당하는 쿼리는 insensitive하다고 분류하여서 제거하고 이외의 쿼리는 sensitive하다고 분류하여 이 쿼리들만 사용해서 튜닝을 진행한다. RQA는 이렇게 줄여진 쿼리 space를 뜻한다. (Reduced Query Application)

 

쿼리를 골라냈으니 이번엔 configuration parameter를 골라내보자..

 

IICP

첫번째로 sample collection을 진행한다. S' 집합은 위 단계에서 쿼리에 대한 실행시간을 S에 저장했듯이 이번엔 configuration parameter의 실행시간을 저장한다.

 

IICP

자 이제 IICP에서는 중요한 parameter를 추출하는데 두가지 방법을 혼합해서 사용한다.

첫번째는 중요하지 않은 parameter를 제거하는 CPS, 두번째는 그 중에서도 중요한 parameter를 추출해내는 CPE이다.

 

IICP - CPS

첫번째 단계인 CPS에서는 기존의 conf 벡터에서 중요하지 않은 parameter를 제거한 r_conf 벡터를 새롭게 생성한다. 

이 과정에서 Spearman Correlation Coefficient (SCC)를 사용하는데 Pearson Correlation Coefficient랑 비교 설명을 해준다. PCC같은 경우에는 두 feature 사이의 linear한 관계는 평가하는 방법인데 r_conf은 서로 non-linear하기 때문에 PCC가 아닌 SCC를 사용한다고 하였다.

 

IICP - CPE

다음 단계는 더 중요한 parameter를 추출하는 CPE 단계이다. 앞서 새롭게 생성한 벡터인 r_conf에서 추출해내는 것이고 여기서 걸러진 parameter는 DAGP with BO를 실행하는데 사용된다.

여기서는 보통 차원축소나 변수추출에서 많이 쓰이는 기법인 PCA가 아닌 KernelPCA(KPCA)를 사용하는데 그 이유는 PCA는 linear combination을 통해서 새로운 변수를 만들고 모델링을 하는데 사용이 된다. 그러나 r_conf는 non-linear하기 때문에 KPCA를 사용한다.

그럼 어떤 Kernel을 사용할것인지! 그건 Figure6에 있는 실험결과를 참고하면된다.

세개의 커널에 대해서 TPC_DS, TPC-H 를 실행시켰을 때의 표준편차를 구하면 가우시안 커널이 제일 크기 때문에 가우시안을 사용한다고 한다.

 

DAGP

다음 단계는 input data size change에 대한 결점을 해결하기 위한 방법인 DAGP이다. BO를 통해서 모델링한다.

Acquisition Function은 MCMC 알고리즘을 사용한다. MCMC란.. 간단하게 서칭해보았을 때 샘플링을 하는 이유가 높은 차원에서의 문제를 풀기 위해서이기 때문에 수렴속도가 느리면 안된다. 근데 MCMC는 다른 샘플링보다 빠르고 실용적이여서 더 많은 확률 분포 샘플링이 가능하다.

마르코프체인이랑 몬테카를로를 합친 방식이어서 첫 샘플은 랜덤하게 선정을하고 이전 샘플에 의해 다음번 샘플이 추천되는 방식의 시도를 무수하게 많이 해보는 방식이다.

 

Start points는 LHS를 통해서 랜덤하게 추출하고 Stop point는 GP 모델이 적어도 10번 실행된 이후에 configuration space의 exploration과 exploitation이 balance를 가질 때 멈춘다.

 

Summary는 데이터가 어떻게 흘러가는지에 대한 부분이니 잘 읽어보면 될 듯 하다!

 

---

여기까지가 전체적인 주요 내용이고 뒤는 실험 내용인데 이후에 추가하도록 하겠다..