이전까지는 생성자에 schedule_interval 을 적어서 DAG 를 주기적으로 실행했습니다. 그러던 중 Airflow 외부의 배치 프로그램이 끝날 때 마다 DAG 를 Trigger 하고 싶은 상황이 생겼습니다. 방법을 찾아보다가 Triggering DAGs (workflows) 문서를 발견했고 적용해봤습니다.

올해 데이터야 놀자 행사에서 타다(TADA) 서비스의 데이터 웨어하우스 : 태초부터 현재까지 라는 제목으로 발표하고 왔습니다. 발표 자료는 Speaker Deck 에서 확인하실 수 있습니다. 힘들지만 유익했던 경험이라 느낀 점들을 글로 정리해보고 싶었습니다.

Cloud Composer 를 써보기 위해 Environment 를 만들 때, Worker nodes 의 Node count 와 Machine type 값을 어떻게 줄 지 고민했습니다. 넉넉한 걸로 하자니 비용이 아까웠고, 작은 걸로 하자니 이후 resource 가 많이 필요한 task 를 실행할 수도 있을 것 같아 망설여집니다. Environment 생성 후에 Machine type 을 바꾸려면 Upgrading the machine type 문서에서 소개하는, default-pool 을 없애고 새로 만드는 방법을 써야 하는데, 그 동안 task 실행이 중단되는 것도 그렇고 그리 매력적이지 않습니다. Upgrading the machine type 문서에서도 처음 Environment 를 생성할 때 machine type 을 잘 선택하고, resource 가 많이 필요한 task 를 실행하고 싶으면 GKEPodOperator 를 쓰라고 얘기합니다.

Cloud Composer 를 업무에 적용해보기 위해 처음 학습한 내용을 Cloud Composer 시작하기 글에서 정리했었습니다. 학습한 내용들을 가지고 이후 실제로 업무에 (= 데이터 파이프라인 개발) 적용했고, 그 과정중에 몇가지 고민하고 정리한 내용들이 있었습니다.

회사 업무때 OLAP 로 BigQuery 를 쓰고 있습니다. 그래서 ETL 작업을 크게 BigQuery 로 옮기는 작업과, BigQuery 내에서의 작업으로 두 종류로 나눌 수 있습니다. 현재는 두 종류 작업 모두 Apache Spark 에 의존하는 Scala 코드로 작성되어 있고, Amazon EMR 클러스터에 spark-submit 로 제출되어 실행됩니다. 그런데 BigQuery 내에서의 작업은 컴퓨팅 자원이 적게 들기 때문에 굳이 Apache Spark 에 의존할 필요가 없고, 데이터 분석가 분들도 작업을 기술할 수 있도록 Python 코드로 작성되면 좋을 것 같습니다. 그래서 Apache Airflow 를 쓰면 좋겠다는 생각이 들었고, Google Cloud 가 제공하는 Managed Airflow 서비스인 Cloud Composer 를 써보려고 합니다.