Version 2 프로젝트 목표는 Version 1이 가진 효율성 문제를 고민하고 해결하고자 함.
고려 사항으로는 크게 아래 두 가지가 존재.
This project is aimed for improving efficiency of The pipeline ver 1. There are two types consideration.
- 병렬 컴퓨팅(Parallel computing)
-
Auto Scaling
스케일 아웃 방식이 필요함. 이는 기존 Local VM 위 LocalExecutor를 사용한 지난 Version 1 프로젝트는 데이터 파이프라인이 증가함에 따라 문제가 생길 수 있음. Operator 정리를 근거로 KubernetesExecutor와 KubernetesPodOperator를 사용.
Using a way having scale-out resources(server) to perform the Operators in parallel is needed, instead of such as LocalExecutor which can perform the pipeline on a single VM and multiprocessing. Based on operators,KubernetesPodOperator is decided. -
Multi Threading
만일 데이터가 엄청 많다면 해당 operator 실행 시 너무 많은 시간이 걸릴 수 있다고 생각.
동시성 & 병렬성 제어로 데이터를 가져오는 방법을 고려.
There is a lot of time should be spent when data pipelines have to deal with much data.
a parallel and concurrent method are needed in this case.
- Network Throughput
- Compression Algorithm
- Locality
- Shuffling
- 여러 개발 환경 언제 셔플링이 발생하고, 어떻게 인식하고, 어떤 방법이 효율적인지를 고려할 것.
두 가지를 참고.
-
Airflow Cluster 설치(Install The Airflow cluster)
Deploying Airflow on Google Kubernetes Engine with Helm -
yaml 파일 변경(Config yaml files)
-
Webserver svc
helm 초기 webserver 서비스 설정은 ClusterIP로 설정되어 있다.
Webserver는 외부에서 접근 가능해야하기 때문에 Cluster 내부에서만 접근 가능한 ClusterIP 타입이 아닌 LoadBalancer를 선택. 참고
A default value of the webserver service's type is 'ClusterIP'. But only the webserver has to be accessed from the outside of a cluster, so the webserver service's type should be changed into 'LoadBalancer'. -
Executor
helm 초기 Executor 설정은 CeleryExecutor인데 MQ 등 인프라 관리를 하지 않기위해 KubernetesExecutor 방식으로 동작시켜 분산시킬 것임
A default value of executor is 'CeleryExecutor'. But because this project won't use a way using the Message Queue, so change the executor into 'KubernetesExecutor'.
