일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 기업 조사 빨리 하는 법
- mac hive
- hadoop safe mode leave
- 자소서 빨리 쓰는 법
- 이더리움 #ethereum
- is not allowed to impersonate hive (state=08S01
- code=0)
- Resources are low on NN
- 카카오 2020 코테
- hive beeline
- mac hadoop 3
- hadoop safe mode
- Failed to connect to localhost:10000
- mac hadoop 설치
- hive beeline 실행
- 카카오 2020 코딩테스트
- 도커 교과서
- hive beeline 설정
- 자소서 시간 줄이기
- mac hive 3
- mac hadoop 설정
- 이더리움
- Safe mode is ON
- 자소서 빨리
- mac hadoop
- Could not open client transport with JDBC Uri: jdbc:hive2://localhost:10000
- 카카오 자물쇠와 열쇠
- 백준 18428
- 자소서 너무 오래 걸림
- hive beeline 에러
- Today
- Total
A seeker after truth
10주차: 데이터 파이프라인, Airflow (4) 본문
Open Weathermap Dag 구현
먼저 스키마 생성.
완료. 여기서 default값 갖는 created_date 필드는 인크리멘탈 업뎃 때 중복 처리에 쓰임.
daily 안에 dt란 필드가 epoch다. 이에 대한 설명은 강의 자료에... 결국 이게 날짜 데이터이므로 사람이 이해할 수 있는 형태로 바꿔야함
음 키 발급 받아서 해도 계속 안되네.. 키 발급 후 2시간 이상 지나야 사용 가능하다는데 만약 그 말이 진짜면 이것때문일듯?
사실 응답 제대로 오고있는지 알고싶은데 알 길이 없네.. 로그 옵션 코드로 지정해줄 수 있나?
암튼 이따 다시 해보고 그때도 안되면 조치를.. 아 로그 못남기면 try except 처리하는게 좋을듯. 200 코드 반환 안하면 에러 발생하게..
아 이런..강의에서 제공해주는 키 사용하니까 바로 됐다.
version2도 성공... 이건 굳이 캡쳐 ㄴ
이번엔 위의 걸 인크리멘탈 업뎃 형식으로 바꿔보고, 개인키 고유성 보장에 대해 다뤄본다. 이걸 보장해주지 않는 이유는 뭘까?
레코드도 엄청 많은데, 이걸 지키기 위해 모든 테이블의 키를 비트리 인덱스로 만들어 메모리에 올려놓고 LookUp을 해야 한다. 레코드 하나 추가될 때마다 레코드 고유키가 존재하고 있는가? 체크를 매번 해야 하기 때문에 시간 많이 들 뿐 아니라 효율적 데이터 구조 만들어놔야 하니 메모리 리소스 등 잡아 먹고.. 따라서 ETL을 할 때는 데이터 엔지니어가, ELT를 할 때는 데이터 분석가가 개인키 고유성을 보장해줘야 한다.
강의자료 고유키 유지법 2번째 항목은 편의상 date created_Date temp 셋만 갖고 이야기 해보겠다.
created_Date의 역순으로 정렬한 뒤 번호가 1번인 것만 갖고 오면 날짜별로 가장 신뢰하는, 최신 정보를 갖고올 수 있는 셈.ㅇㅇㅇㅇㅇㅇ일련 번호를 어떻게 붙일지를 (윈도우 함수 들어간 SQL 문에서) OVER 다음에 기록, 뭘 기준으로 그룹핑 할건지를 partition by에 기술. 오더바이는 같은 파티션 내 레코드의 정렬 순서 말하는 거다.
유지법 3번째에 나온 질문인, 트랜잭션으로 묶어줘야 하는 최소 단위는?
sql 문 전체를 묶어줘도 되고, 4번째로 넘어가면 1, 2번은 묶어준다 해서 데이터 정합성이 깨지는 부분은 아님. 따라서 최소화 하고 싶으면 3번과 4번을 묶어주면 된다.
두 날짜에 레코드 읽어 오면, 저 빨간 부분이 서로 중복 레코드. 이걸 우선시 해 중복 제거를 한다!
그럼 이런 식으로 번호붙을거다. 요 상태서 번호 1인 것들만 읽는거다.
Weather_to_Redshift_v2.py 코드와 같은 동작을 update+insert = upsert라 함. 보통 데웨에 자기들만의 업서트를 구현해주는 문법 있다.
Backfill
강의자료 33쪽. 왼쪽에 나와있는건 아마존 사이트에 대해 실행하는 각종 대그들. 알고보니 이게 중간에 이틀 동안 실패했었단걸 나중에 알았다. 이 부분 처리가 안되면 2일 간의 데이터가 빠져있단 말이겠지?
34쪽: 웬만하면 풀리프레쉬 사용하다 이걸로 도저히 안되겠을 때 인크리멘탈로 전환하는 게 맞다.
에어플로는 이 백필 문제를 데엔 관점서 해결하기 쉽게 디자인 했단 점에서 많이 사용됨 (인기이유 중 하나)
실패할 수 있는 원인들: 알고보니 소스 DB가 유지보수 중이었다, 로드가 많이 걸려서 응답 못했다. 그럼 이 dag가 실패할거고, 그 날짜 데웨는 빠져 있을 것. 그걸 모종의 이유로 며칠 지나고 해결하려 보면 36쪽에서 어제 날짜 구하는 코드처럼 날짜 구해서 실행할 수가 없게됨. 그럼 뭘 모르는 경우 37쪽처럼 이 코드를 해킹하고 하드 코딩으로 바꿔 실행함. 이러면 문제 엄청 많음(코드 복잡해지면 어디가 문젠지 못찾음, 코드 원상복구 시키려 하면 이전 코드 기억 안날 수도 있고 etc..)
38: 결국 처음 대그 만들 때부터 백필 쉽게 가는 구조로 안만들면 나중에 몸이 고생한다. 핵심은 위험한 지점이 무엇인지 아는 것.
에어플로는 이 문제를 시스템차원서 해결할 수 있게 지원해주고 있.
39: 우선 모든 실행에 대해 데베에 기록. 에어플로는 작업이 모두 인크리멘탈 업뎃이라 가정하고 실패 시기를 시스템에 알아서 기록해주고 있어서, 이를 불러와 사용하는 식으로 코드 작성하면 된다. 내가 날짜 직접 계산할 필요 없다~!
이 부분이 가장 혼동을 유발해 사람들이 가장 많은 혼란 겪는다.
41: 이거 실수한 사람 캐치업이 디폴트 트루인거몰랐. 또 내가 지금 실행하면 과거 실행 안한 걸 실행 안된다고 혼자 가정해버린거. 그래서여기서 핵심은 캐치업이 갖고 있는 위험성을 숙지하는 것.
42: 숙제. 중요한건 start_Date이 대그 시작 날짜가 아닌 처음으로 읽어와야 하는 날짜라는 점. 4번 실행될 것 같지만 3번이 정답이다 왜냐면 8/10건 실행 안된다. 이게 첨 읽어와야 하는 날짜기 때문에 그 다음날에나 실행이 된다. 다시 - 이 대그가 하루 1번 도는 대그면 그 다음날, 1시간 도는 대그면 1시간 뒤부터 처음 실행 된다. . 8/11~13일 실행분은 밀린 잡이 되므로 큐잉된 뒤 그담날부터 차례로 실행되는 거. 코드를 안바꾸고도 동일 코드로 운영도 백필도 할 수 있게 되는 것.
결론적으로 세팅 날짜 대비 4일하고 12시간 뒤 이 대그를 처음 실행했다? 그럼 이 대그는 11~13일자 잡 연달아 3번 실행되고, 그 이유는 앞의 3번의 런이 실행이 안됐기 때문에 이를 캐치업 하고자.
'Data > 데엔 데브코스 TIL' 카테고리의 다른 글
13주차 Airflow 고급 1,2일차 (0) | 2024.01.02 |
---|---|
10주차: 데이터 파이프라인, Airflow (5) (0) | 2023.12.19 |
10주차: 데이터 파이프라인, Airflow (3) (0) | 2023.12.13 |
10주차: 데이터 파이프라인, Airflow (1, 2) (0) | 2023.12.12 |
부동산 BI 구축 (2) - 12/5 화 일정 (0) | 2023.12.04 |