worker와 master도 연결했으니 스파크 어플리케이션을 실행해보겠습니다.

worker 컨테이너를 띄우고 master 컨테이너와 연결해보겠습니다.

최근 스파크를 공부하고 있습니다. 실무에서 aws glue를 사용하면서 직접 스파크 코드를 작성하기도 하지만, 단순히 문법이나 메서드보다는 spark의 클러스터 환경을 직접 구축해보고 경험해보는 게 더 값지고 재밌을거라 생각했습니다.

airflow에서 DAG instance는 execution_date를 기준으로 생성됩니다. 주기적으로 발생하는 ETL 스케줄을 편리하게 task / dag 단위로 관리할 수 있다는게 airflow의 큰 장점입니다.

glue job을 사용하다보니 불편함을 느낀 점은 2가지입니다.

Reduce

airflow task 설정을 하다가, 이전 task에 의존적으로 실행 계획을 만들 수 있는 옵션 2개를 찾았습니다. 이전 task에 상관없이 실행 가능한 모든 task를 실행시키는 경우에는 이 옵션들이 의미가 없겠지만, task의 성공여부에 따라 ETL 계획에서 조건을 주고 싶은 경우에는 이 두가지 옵션이 도움이 될 것입니다.

docker / airflow의 설정 파일을 크게 3가지로 나눴습니다.

회사에서 머신 러닝을 위해 우선적으로 고려했던 방법이 AWS Sagemaker였는데, 효율성이 좋지 않아 물리 서버에서 직접 모델을 돌리게 됐습니다. (Sagemaker가 너무 비쌉니다..너무…)

map과 flatMap은 spark transformation의 대표적인 연산입니다. 이 둘을 사용해보고 차이점이 무엇인지 살펴보겠습니다. pyspark을 이용합니다.