본문 바로가기
TIL - 20241120 Yarn cluster에서 spark-submit으로 잡을 제출했을 때 로그 건 수 줄이기yarn cluster에 spark-submit을 사용해서 잡을 제출하면 1초마다 한 번씩 해당 앱의 상태를 조회해서 체크합니다. 그렇기 때문에 잡 수행시간이 긴 경우에는 불필요하게 로그가 많이 찍히는 이슈가 있습니다.이를 조절하기 위해서 spark 에서 spark.yarn.report.interval 설정을 통해 적용할 수 있습니다. 해당 값의 경우 기본 값이 '1s'로 설정되어 있고 이를 적절하게 사용하면 출력되는 로그 건 수를 줄일 수 있습니다.분 단위로는 'm', 'min'으로, 시간 단위는 'h'로 표현하면 됩니다.
TIL - 20241119 Airflow에서 schedule interval을 수정하는 경우airflow schedule interval을 변경하는 경우 이전 시간인지 아니면 이후 시간인지에 따라 동작 방식이 살짝 달라진다.예를 들어 기존 0시 5분으로 설정했는데 해당 DAG의 스케줄 시간을 0시 10분으로 변경한다면 DAG가 업데이트 된 시점에 한 번 실행이 되고 다음날 0시 10분에 실행이 된다.만약 기존 0시 10분으로 설정했는데 해당 DAG의 스케줄 시간을 0시 5분으로 변경하면 다음날 0시 10분에 실행된다.최근 Airflow 버전에서는 다음 스케줄링 시간에 대한 정보를 airflow 웹 화면에서 확인할 수 있다.
3일차 연말 콘서트 간략 후기 역시 콘서트는 막콘이 진리였다. 오르트 구름을 두 번 부르기도 했고, 슬로건 이벤트도 하긴 했는데 아무래도 타이밍을 잡지 못해서 슬로건을 못든 것이 아쉬웠다. 3일차에도 쇼츠를 찍었고 손준호씨도 반강제적으로 노래를 불렀다. VIP 석이어서 그런지 얼굴은 잘보였는데 반대쪽편으로 갔을 때를 보기 위해서 스크린을 봐야 했는데 큰 스크린이 너무 높게 있었어서 목이 아픈 점만 제외하곤 3일간 있었던 콘서트 중에서 가장 좋았다. 나중에라도 단체 춤 파트 부분을 유튜브로 올려주면 좋겠다는 생각이 들었다.
3일차에 쓰는 2일차 연말 콘서트 간략 후기 오늘은 1층 북쪽 위치로 자리를 잡았다. 1일차와의 차이점은 쇼츠를 찍었다는 점과 프로듀서인 손준호씨를 소개했다는 점이 달랐다.그리고 2층에서 1층으로 바뀌어서 그런건지 아니면 소리를 조절했는지 잘 모르겠는데, 이번에는 음향이 괜찮았었다.또 피드백이 있었는지는 모르겠는데, 1일차에 비해 북쪽도 신경쓰고 오는 느낌이 있었다. 다만 역시나 공연 내내 휴대폰으로 영상을 찍으시는 분들이나 카메라로 사진을 찍으시는 분들이 있어서 신경이 쓰였다. 심지어 영상에 나오는데도 꿋꿋이 휴대폰으로 영상을 찍으시는게 어떤 의미로는 대단하다고 느껴졌다.
2일차에 쓰는 1일차 연말 콘서트 간략 후기 3일차까지 다녀오고 나서 전체 후기를 작성할 예정이고 일단은 1일차 콘서트 간략 후기를 작성해보려고 한다. 위치의 경우 북쪽으로 2층이었고, 아무래도 금요일이다보니 옆에 빈자리가 매우매우 많았다. 2층이어서인지는 모르겠는데 음향이 별로였다. 노래 소리가 밴드소리에 묻혀서 가끔 안들리기도 했었고 아무래도 밴드쪽이 있는 방향이다보니 남쪽 위주로 공연이 짜여진 것 같은 느낌을 많이 받았다. 그래도 대형 스크린이 있어서 얼굴을 비춰주어서 그나마 괜찮았었다. 이번 공연의 경우 공연 제목처럼 7집 곡 위주로 구성이 되었으며 무대 장치라던지 댄스처럼 볼거리가 있어서 듣는 콘서트보다는 보는 콘서트의 느낌을 강하게 받았다. 자리 예매만 남쪽으로 했었다면 가장 좋지 않았을까라는 아쉬움이 있었다.
TIL - 20241115 MySQL 데이터 전체를 가져올 때 유의할 점.mysql에 직접 쿼리를 날리면서 분석하는 경우 부하 이슈라던지 혹은 다른 db와 연결해서 분석하는 것이 어렵기 때문에 mysql 데이터 전체를 가져와서 하둡에 적재하고 이를 Hive나 Spark 등을 사용해서 분석합니다. 다만 직접 쿼리를 날릴 때도 한 번에 많은 데이터를 가져오려고 하면 db에 부하가 가기 때문에 적절한 조건문을 걸어서 조회해가는 것이 필요합니다. 그래서 pk를 사용해서 범위로 조회하는 것이 좋으며 이 범위를 잘 설정하는 것이 중요합니다. 너무 짧게 잡게되면 연결을 자주하는 이슈가 있고, 너무 크게 잡으면 db 입장에서 데이터를 쿼리하는 과정에서 부하가 발생합니다. 이 때 당연히 데이터를 조회할 때 항상 pk를 기준으로 정렬해서 보여주는 ..
TIL - 20241114 Airflow backfill 과정에서 backfill이 안되는 경우Airflow 2.9.1 버전을 기준으로 airflow backfill을 실행하는 과정에서 겪었던 backfill이 안되는 다양한 이슈에 대해 정리합니다.하나의 DAG에 대해 2개 이상의 backfill을 수행하는 경우Deadlock 에러가 발생하면서 실행이 안되는 이슈가 있습니다. 따로 해결 방안은 없고 그냥 최대 1개의 backfill만 수행하도록 하며 필요한 경우 DAG를 복제해서 여러개를 돌리거나 혹은 max_active_runs 값을 늘려서 해당 backfill 잡이 여러 개의 dag run을 수행할 수 있도록 합니다.DAG에 명시된 start_date와 end_date를 벗어나는 기간에 대해 backfill을 수행하는 경우주어..
TIL - 20241113 Airflow task가 queue 상태로 유지되는 이슈관련 환경Kubernetes 상에서 CeleryExecutor로 실행Redis를 큐로 사용DB의 경우 postgresql을 사용문제가 된 TaskSpark 잡을 제출하기 위해서 SparkSubmitHook을 사용하는 custom operator를 만들었고 해당 operator를 Dynamic Task Mapping를 활용해서 task를 생성함.해당 task가 scheduled 에서 queue 상태로는 잘 가는데 그 이후로 running 상태로 변경되지 않는 문제가 있었음원인원인은 매우 심플했는데 custom operator를 만들 때 yarn 제출 시 사용할 queue에 대한 정보를 생성자에서 전달받을 수 있도록 queue 파라미터를 추가했는데, 이..

티스토리툴바