[프로그래머스] 데이터 엔지니어 study - 4주차

0.질문 review

• AB test
  • 모델 테스트시 처음에는 작게 시작, 1% 사용자에 대해
  • 별문제 없으면 5%, 10% 점차적으로 늘려감
  • 시리즈D 정도받고, 팀안정화 시 50:50 정도 가능하지 않나
• Airflow 알아야 할 부분
  • 시간이 지날수록 DAG가 점점 많아지기 때문에 정해진 시간에 시행되는 cronjob으로는 한계가 있음
  • Backfill
  • 특정 DAG가 끝나면 다음 DAG, DAG들간의 dependency가 생김
  • 시간순으로 트리거 가능(세가지 방법)
  • 데이터 리니지 파악가능(어떤 데이터로부터 어떤 데이터가 생겨났는지), 데이터 과잉시 디스커버리 이슈, 데이터 카탈로그를 통해서 검색, 데이터 리니지 정보와 카탈로그 연동시 데이터 파악 쉽게 가능, 데이터 허브
• 데이터 엔지니어 연봉이 높은이유
  • 수요가 큼
  • 학습이 많이 필요
  • 서포트 위치
• 트랜잭션이 많은 경우, OLTP
  • MySQL, postgreSQL, mariaDB
  • 쓰기작업은 master에두고 읽기작업은 slave 여러대(복제본)
  • 데이터 팀 전용 복제본
  • slave 만들어서 거기서 작업하는게 가장 좋은데
  • 모르거나 작은기업은 안하는 경우 많음
• incremental update
  • devops 팀과 엔지니어 팀의 협업이 중요
• 최초의 데이터 수집 및 추출 누가하는지?
  • 회사 및 스테이지마다 다름
  • 처음에는 front, back에서 로깅해야 기록 남음
  • 데이터 엔지니어는 그 기록을 가공해 적재
  • 조직 발전시 수집자체도 데이터 엔지니어 팀이 할 수 있음
• 데이터 품질 검증은 누가 하는지?
  • 간단하게는 데이터 레코드 수
  • 일주일치, 일년치 등 적당한 임계값 찾아서 데이터 탐색
  • primary key
  • 운영시 발생하는 작은 사고를 회고 하면서 어떻게 하면 사고를 방지할 수 있었을까?
  • 데이터 품질을 체크하는 코드를 앞뒤로 주는게 좋음
• 신입 데이터엔지니어가 JAVA기반 알아야하는지?
  • python만 알아도 충분함
• ETL 작업에서 추출하는 데이터 중 필요없는 데이터는?
  • 가능하다면 extract 할 때 빼기
  • 나중에 쓸일 있다면 저장해두고, 필요한 것만 읽어오기
  • 데이터 크기, 향후 과정을 보면서 판단
• 오라클 DB 안쓰는 이유
  • 데이터 웨어하우스로는 쓸 수없고 스케일 하지 않음
  • 비용 비쌈
  • 90년대 후반 IT startup 생기면서 오픈소스로 감
  • 큰 데이터 처리 못함
• 데이터 레이크 vs 데이터 웨어하우스
  • 데이터 웨어하우스, 1980년대 후반
    • 한군데 모아서 처리하자
    • 구조화된 데이터의 작은 스토리지
    • 정형화된 데이터에 초점
  • 데이터 레이크, 2010년 초반, 하둡,…
    • 비정제된 데이터도 보자는 의미에서 나옴
    • 클라우드 스토리지, 비용 쌈
    • 인사이트를 뽑을 수도 있고
    • 모델링도 가능
    • 다 저장해두고 선별해서 데이터 웨어하우스에 옮기자
    • 이벤트 로그같은거
  • 많은 경우 둘다 사용함
  • 한 단계 더 나아가 데이터 레이크하우스
    • 두개의 장점을 다 취해보자
    • 데이터 레이크는 스키마 설정 x
    • 데이터 웨어하우스는 스키마 설정 o
    • 데이터 브릭스 2020년 개발해서 광고하는 중
    • 아직 미숙
  • 한 단계 더 나아가 데이터 매쉬
    • 아직 미숙
    • 포인트는 회사가 커지면 데이터를 중앙에 모으는게 가능한건지
• 마케팅 용어, 지식
  • 마지막 주에 공유
• OLTP vs OLAP
  • OLTP(운영 DB, production, 회원등록 및 물건구매 같은 트랜잭션, MySQL, 오라클)
  • OLAP(데이터 웨어하우스, 데이터 레이크 등 분석용 DB, redshift)
• 멱등성이란?
  • 데이터 파이프라인이 연속 실행되었을 때 소스에 있는 데이터가 그대로 DW로 저장되어야함
  • source와 DW 데이터가 일치해야함
  • Full refresh 관점에서 DW 데이터 다날리고 데이터 소스에서 읽어온 데이터를 DW 테이블로 적재

1.Airflow 설치 review

• EC2 서버에 2.2.5 설치 돼 있음
• 2.5.1 버전 설치 방법은 github에 있음
• 두번째 보낸 이메일로 access

2.숙제 review

• Airflow에서 하나의 DAG는 다수의 Task(operator)로 구성됨.
• DAG의 start date는 읽어와야할 데이터의 날짜와 시간
  • 첫실행은 start date + 1일
  • DAG execution date 는 읽어와야할 데이터의 날짜
• Schedule interval - 30 * * * *: 매시 30분 실행, 매분이면 * * * * *
• 0 * * * *, start date: 2021-02-04 00:00:00, 이면 2021-02-04 01:00:00에 DAG 첫 실행
• start date가 일주일전이고 오늘 활성화 시키면 그 사이 실행 안된것들을 catch up 하려고함
  • start date과 DAG 사이의 gap을 catch up parametor 설정을 통해 control해야함
  • default가 True임
• start_date
  • 이 시간에 처음 실행되는 것이 아니라 start_date + 실행주기가 처음 실행시간
  • 2022-02-23 01:00:00 start_date인 DAG 존재
    • Daily job이면 2022-02-24 01:00:00 처음 실행
    • 이때 execution date로 2022-02-23 01:00:00 들어옴
    • hourly job이면 2022-02-23 02:00:00 처음 실행
    • 이때 execution date로 2022-02-23 01:00:00 들어옴
  • execution_date를 보고 업데이트할 데이터의 날짜를 정하게 코딩하면
    • Backfill이 코드변경 없이 가능
    • 단, incremental update를 하는 DAG에서만 의미 있음
• Python ETL 개선하기
  • 데이터 웨어하우스에서 테이블 업데이트 방법 크게 두가지
    • Full Refresh
      • 단순해서 좋지만 데이터 커지면 사용 불가
      • 숙제는 Full Refresh하는 예
    • Incremental Update
      • 데이터가 클 경우 효과적이지만 복잡도 증가
      • 보통 타임스탬프 혹은 일련 번호 등의 필드 필요
      • execution_date 활용
  • DELETE FROM vs TRUNCATE
    • TRUNCATE는 테이블은 두고 record 삭제
    • TRUNCATE는 트랜잭션 무시, 바로 삭제
    • 큰 테이블 삭제시 빠르긴 함
    • DELETE FROM은 조건 맞는거 삭제 가능(WHERE)
    • DELETE FROM 트랜잭션 존중

3.트랜잭션(Transaction)?

• 개념: Atomic하게 실행되어야 하는 SQL들을 묶어서 하나의 작업처럼 처리하는 방법
  • BEGIN END(= COMMIT) 사이에 해당 SQL을 사용, 모두 성공하면 임시 상태가 최종 상태가 됨, BEGIN은 이제 부터 END나 COMMIT 하기전까지 DB에 쓰지 않는 것.
  • Transaction: 이 과정 중 SQL 결과는 임시 상태, 다른 세션에서는 커밋 전까지 보이지 않음, 트랜잭션에 들어가는 SQL을 최소화하는 것이 좋음
  • ROLLBACK: 중간에 하나라도 실패하면 원래 상태로 돌아감
• 구성(2가지): 레코드 변경을 바로 반영하는지 여부, autocommit이라는 파라미터로 조절가능
  • autocommit = True
    • 기본적으로 모든 SQL statement가 바로 커밋
    • 이를 바꾸려면 BEGIN; END(COMMIT);을 사용(혹은 ROLLBACK)
    • 명시적으로 BEGIN 명시
  • autocommit = False
    • 기본적으로 모든 SQL statement가 커밋되지 않음
    • 커넥션 객체의 .commit()과 .rollback()함수로 커밋할지 말지 결정
    • BEGIN 해도 무시해버림
  • 무엇을 사용할지는 팀 및 개인 취향
• try/except 사용시 유의할 점
  • error가 발생하지 않는 것 처럼 보일 수 있음
  • except에서 raise를 호출하면 원래 exception이 위로 전파됨
    • ETL 관리하는 입장에서 error 명확히 드러나는 것이 좋음

# autocommit = True case case1 ~ case3
# case1
try:
  cur.execute("BEGIN;")
  cur.execute("DELETE FROM table.name_gender;") 
  cur.execute("INSERT INTO table.name_gender VALUES ('Claire', 'Female');")
  cur.execute("END;")
except (Exception, psycopg2.DatabaseError) as error: # error 넘어감
  print(error)
  cur.execute("ROLLBACK;")
finally :
  conn.close()

# case2
# 데이터 파이프라인에서 error 전파시 유용
cur.execute("BEGIN;")
cur.execute("DELETE FROM table.name_gender;")
cur.execute("INSERT INTO table.name_gender VALUES ('Benjamin', 'Male');")
cur.execute("END;")

# case3 - 잘못된 SQL
# 없는 테이블에 record insert로, DB에 안씀
cur.execute("BEGIN;")
cur.execute("DELETE FROM hhs76862512.name_gender;")
cur.execute("INSERT INTO hhs76862512.name_gender3 VALUES ('Andrew', 'Male');")
cur.execute("END;")

# case4 - try/except
try:
  cur.execute(create_sql)
	cur.execute("COMMIT;")
except Exception as e;
  cur.execute("ROLLBACK;")
	raise # error 전파 명확히 하는 역할, 이슈시 slack으로 메세지 보내는것과 유사