개요 DAG 설계 및 Library를 잘못 활용함으로서 발생할 수 있는 문제를 살펴보고, DAG 최적화의 중요성 및 효과를 다뤄보고자 한다. Worker Node의 사양 산정은 중요하다. (Autoscaling 이런 거는 우선 논외로 하자) Task를 실행하다보면

개요 특정 URL에서 대용량의 데이터를 다운로드 받을 경우가 있다. 그리고 이 데이터를 또 다른 데이터랑 결합하여 분석하여 인사이트를 찾는 등의 니즈가 있다. 이런 니즈를 위해 이 데이터를 내부 S3에 업로드하고, 여러 사람이 가져다 쓰거나 그때그때 쿼리할 수 있도록

Worker Node를 부팅했을 때 systemctl로 등록해놓은 서비스가 잘 동작하다가 언젠가부터 자동 실행되지 않는다.systemctl로 airflow-worker.service 서비스를 시작해보면 문제없이 실행도 된다.Unit 파일 자체는 문제 없는 것 같다.ai

Task를 실행할 때 Negsinal.SIGKILL이란 Log를 발생시키며 Task fail이 난다.이 경우 Memory 문제라고 한다.Task가 Airflow Worker에 할당된 Memory보다 더 많이 사용하기 때문에 발생한다고 한다.따라서 해결 방법은 단순하다.

Airflow Webserver가 먹통이 됐다.프로세스를 확인해보니 Airflow Webserver 프로세스가 떠 있긴 한데, Airflow Web Interface를 담당하는 gunicorn이 안 떠있다.airflow-webserver.err를 확인해보니, FileE

Git sync로 GitHub의 DAGs들을 Sync하고 있었는데 다음과 같은 에러 발생에러 메세지ssh: Could not resolve hostname github.com: Temporary failure in name resolution 요런 문구가 보인다면 DN

Airflow의 Default Helm Chart는 Metadata DB로 Container에서 동작하는 Postgre DB를 사용한다.하지만 실무에서는 AWS RDS 같은 DB를 사용한다.따라서 Airflow Metadata DB를 외부 DB롤 설정하는 방법을 알아본

DevOps 엔지니어, 개발자 같은 IT 종사자라면 실무에서 사용하고 한 번쯤은 들어봤을 유명한 Container S/W Docker!고래 위에 컨테이너가 쌓여있는 모습이 매우 익살스럽다 ㅎㅎ이 컨테이너를 실물로 영접할 수 있는 기회가 생겼다.실물로??먼소리여?바로바로

아래와 같이 Init:~ 현상이 반복적으로 계속되거나, Error를 나타내는 문구를 나타내면 Init Container 기동에 문제가 발생한 것이다.Kubernetes는 Pod라는 배포 최소단위를 쓰고, 이 Pod 안에는 1개 또는 그 이상의 Container가 포함된

GitHub에서 연동할 Repo의 Deploy key에 SSH Public key를 등록한다. Deploy key 대신 계정에 SSH Key를 등록해도 된다.kubectl create secret generic airflow-ssh-git-secret --from-fi

Provider dependency를 설치하기 위해서는 Custom docker image를 Build 해야 한다.데이터 분석 및 처리를 위해 많이 사용하는 Spark dependency를 설치해보자.requirements.txtDockerfiledocker build

kind는 Docker container nodes를 이용하여 Local k8s cluster를 실행하게 도와주는 Tool이다. kind는 주로 K8s를 Test하기 위해 설계되었지만, Local 개발 또는 CI에 사용될 수도 있다.https://kind.si

Airflow의 의존성 패턴에 다음이 있다.선형 체인 (linear chain) 유형팬아웃/팬인 (fan-out/fan-in) 유형 하나의 Task가 여러 Downstream Task에 연결되거나 그 반대인 유형이전 Task 결과가 다음 Task 입력으로 사용되는 관계

Airflow는 간격 기반 접근 방식을 사용한다. 이점은 작업이 실행되는 시간 간격(시작 및 끝)을 정확히 알고 있으므로 위에서 본 증분 데이터 처리 유형을 수행하는 데 적합하다. 증분 처리의 경우 일반적으로 시간은 해당 간격이 지나자마자 처리되는 개별적인 시간 간격으

스케줄 간격을 정의하기 위해서 schedule_interval 인수를 설정한다. default 값은 Noneschedule_interval="@daily"와 같이 @daily 매크로는 매일 자정에 DAG를 실행하도록 예약한다.이 외에도 다음과 같은 매크로를 지원한다.자

해시 테이블은 (Key, Value)쌍으로 저장하는 자료 구조이다. 해시 테이블의 데이터에 접근하는 방식은 다음과 같다.각각의 key에 hash 함수를 적용하여 index를 찾는다.이 찾은 index로 값을 저장하거나 검색한다. 이 때 실제 값이 저장되는 장소를 buc

실시간으로 발생되는 금융 거래 내역이 있다. 금융 거래 내역을 지불 유형에 따라 분류하고, 이 중에서 수상한 거래를 Detection해서 처리하는 로직을 구성해본다.로직은 크게 다음과 같이 구성된다.금융 거래 내역을 발생시키는 Generator (Producer)지불

Zookeeper 1, Broker 3 Kafka Cluster에 Message를 송수신하는 간단한 Producer, Consumer를 만들어 본다.Zookeeper 1, Broker 3 Kafka Cluster 구축 방법은 아래 포스팅 참고Kafka Cluster 구

Local만으로는 Cluster를 구축하기 어렵기 때문에 Docker를 이용하여 Kafka Cluster를 구축해본다.Zookeeper 1개, Broker 3개로 구성한다.추가로 Kafka를 Web UI에서 쉽게 Manage하기 위해 Kafdrop이란 서비스도 사용한다

Kafka Library 설치하기 pip3 install kafka-python