커리어 개발

커리어를 계속 발전시키려면 1

• 건강한 몸과 마음
• 어떻게 하면 최선의 결과를 낼 수 있을까? 고민하기 → 우선순위 정하고 중요한 것부터(호기심 순서가 아니라)
• 결과를 내는데 필요한 기술 배움에 초점 맞추기 → 단순히 뜨는 기술이 아니라, 지금 내 일에 필요한 것에 초점을 맞추라

커리어를 계속 발전시키려면 2

• 요즘 세상의 전문성 → 어느 한 분야를 깊게 파고 아는 것 보다는,, 변화를 두려워하지 않는 마인드셋
• 큰 기업에서 일하면 작은 부분을 담당해서 일하게 되므로 후회할수도,,,
• 워터폴 대신 애자일 라이프 : 커리어도 좋은 곳에서 시작해서 그곳에서 끝내겠다는 생각이 아니라, 어디서든 시작해서 계속 발전해나가겠다는 마인드로 살아가기.
• 이력서 그냥 내보기 : 준비되면 이력서내야지! (x) 본인은 내가 얼마나 준비됐는지 알기 어려움.

매니저 입장에서 주니어에게 바라는 점?

• 피드백을 잘 받아들이고 개선하느냐
• 얼마나 발전가능성이 있느냐 - 처음에는 기술습득, 나중에는 영향력(leadership)
• 어떻게 질문하느냐도 매우 중요함
• 얼마나 열정적이고 빠르게 성장하느냐. 인턴 기회 잘 살려보라.
• 회사를 고르기보다는 같이 일하는 사람과 매니저가 중요하다.

데이터 파이프라인

용어 설명 : ETL

• 보통 데이터 파이프라인을 지칭
• 데이터를 소스에서 DW같은 목적지로 복사하는 역할을 수행
• ETL의 다른 이름 : 데이터 파이프라인, 데이터 워크플로우, DAG(AIRFLOW)
• ETL VS ELT
  • ETL은 보통 파이프라인 1개를 의미
  • ELT는 개별적인 파이프라인이 아니라, 어느 조직에서 데이터를 어떻게 처리할지에 대한 아키텍쳐를 의미함. 어느 회사든 ELT를 쓰게 되어있다.

용어 설명 : Data Lake vs DW

• Data Lake
  • 비정형화된 데이터, 스케일이 더 크고 ???
• Data Warehouse

데이터 파이프라인 정의

• 데이터를 소스로부터 목적지로 복사하는 작업
  • 코딩 혹은 SQL을 통해 이뤄짐
  • 대부분 목적지는 DW가 된다
• 데이터 소스의 예시 : 기본 RDBMS, API(외부 데이터) 등등
• 데이터 목적지의 예시 : DW(어떨때는 DW가 데이터소스가 되기도 함) 등등

다양한 종류의 데이터 파이프라인

• Raw Data ETL Jobs
  • 외부와 내부 데이터 소스에서 데이터를 읽어다가 (많은 경우 API를 통하게 됨)
  • 적당한 데이터 포맷 변환 후 (데이터의 크기가 커지면 Spark등이 필요해짐)
  • 데이터 웨어하우스에 로드이 작업은 보통 데이터 엔지니어가 함
• Summary/Report Jobs
  • DW로부터 데이터를 읽어 다시 DW에 쓰는 ETL
  • 많은 경우 Raw Data를 읽어서 일종의 리포트 형태나 써머리 형태의 테이블을 다시 만드는 용도
  • 특수한 형태로는 AB 테스트 결과를 분석하는 데이터 파이프라인도 존재요약 테이블의 경우 SQL (CTAS를 통해)만으로 만들어지고 이는 데이터 분석가가 하는 것이 맞음. 데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어 주느냐가 관건
• Production Data Jobs
  • DW에서 데이터 읽어서 다른 STORAGE로 쓰는 ETL
  • 타겟 STORAGE :
    • Cassandra/HBase/DynamoDB와 같은 NoSQL
    • MySQL과 같은 관계형 데이터베이스 (OLTP)
    • Redis/Memcache와 같은 캐시
    • ElasticSearch와 같은 검색엔진

간단한 ETL 작성

ETL실습

웹에 있는 CSV파일을 REDSHIFT 테이블로 복사

3개의 함수로 구성(E, T, L)

PSYCOPG2 POSTGRES 사용하는 라이브러리를 쓰면 레드시프트에도 사용 가능함

AUTOCOMMIT = TRUE 어떤의미인지 5,6주차에 자세히 보겠다

데이터파이프라인의 원칙1 : 멱등성 - (데이터 소스가 일정하다는 전제하에) 데이터 파이프라인은 한 번 돌리나 10번 돌리나 항상 결과가 같아야한다.

중복데이터가 쌓이나 → 멱등성 이슈발생했다는 의미

Airflow 소개

• 파이썬 기반 데이터 파이프라인 플랫폼
• 데이터 파이프라인 작성 자체를 쉽게 도와주고,
• 웹ui로 파이프라인 상세한 통계 확인해볼 수 있음, 문제 있으면 재실행시킬 수도 있고
• DAG 디렉티드 어사이클릭 그래프 : 데이터 파이프라인이구나 라고 생각하면 됨
• DAG는 하나 이상의 TASK로 구성됨 - 예시 코드에서는 1개의 DAG에 3개(E,T,L) TASK가 구성되었다고 생각하면 됨
• TASK는 Operator 클래스로 구현됨
• TASK간의 실행 순서 정의할 수 있음 → 그래서 DAG임. 루프X, 방향성만 존재해야함
• API도 제공해서 외부에서 에어플로우 모니터링을 할 수 있음
• 하나 혹은 다수의 서버로 구성이 가능함
  • 스케줄러1개지만, 워커는 여러 서버로 구성가능
  • 스케줄러가 TASK를 다수의 워커에게 나눠줌
  • DAG와 TASK, 스케줄 정보가 저장되는 메타DB가 있으며 기본적으로 SQLITE가 사용됨→ 이 SQLITE로는 별 의미가 없으므로 개발용으로라도 POSTGRES 혹은 MYSQL로 변경해야함
• 총 5개 컴포넌트로 구성
  • WEB SERVER - FLASK
  • 스케줄러 -
  • WORKER - 실제 작업수행하는
  • DATABASE - SQLITE가 기본
  • QUEUE - 워커가 여러개인 멀티노드인 경우에만 사용됨
• 아키텍쳐 이미지
• 처음에는 1개 서버에 WORKER, 스케줄러, WEB서버 동시에 올려서 사용하다가,, 스케일이 커지면
  • 스케일 업 : 더 좋은 사양의 서버를 사용하여 더 많은 데이터 처리
  • 스케일 아웃 : 워커노드를 추가하여 더 많은 데이터 처리
• 운영에어플로우는 클라우드 것을 사용하면 좋다.
• 개발용 에어플로우는 직접설치해보는 것이 좋다. 이해도도 확실히 높아지고
• DAG란? 그래프형태의 링크. 방향성 T1에서 T2, T3로. 루프는 없음 → 끝이 안 나고 계속 돌아가니까

D - 방향성이 있다.
A - 루프가 없다.
G - 그래프

• TASK는 OPERATOR로 구현된다
• DAG 예시
  • END_DATE는 왠만하면 잘 안 씀.
  • RETRIES : 실패할 경우 재시도 횟수
  • RETRY_DEALY : 재시도 할 경우 몇 분 후 재시도 할 것인지
  • START_DATE : 이거 조심해야함! 이것 때문에 러닝커브가 존재함
  • 스케줄 : CRONJOB과 유사한 스케줄링 형식. 기본 UTC 기준으로 설정됨. 타임존 지정하면 내가 원하는 타임존에서 실행이 가능하기도 함
  • BASHOPERATOR : 리눅스 셸 명령어 실행 오퍼레이터
  • DUMMYOPERATOR : 아무것도 안 하는 오퍼레이터 -> 최근 버전에서는 EmptyOperator로 이름변경

데이터파이프라인을 만들 때 고려할 점

데이터파이프라인을 만든다? → 코딩을 한다는 말임
코드가 5줄이 넘어가면 버그가 생김

이상과 현실간의 괴리

• 이상 혹은 환상
  • 내 데이터 파이프라인은 문제가 없을거야
  • 관리 어렵지 않을거야
• 현실
  • 많은 이유로 실패함
  • 파이프라인 갯수와 비례해서 버그가 생기고 그만큼 유지보수 비용이 증가함 → DE가 노가다 되는 순간

BEST PRACTICES

• 가능하면 데이터가 작을 경우 매번 통째로 복사해서 테이블 만들기
• 멱등성 보장 중요함
  • 여러 번 실행해도 동일한 결과
• 실패한 데이터 파이프라인 재실행이 쉬워야한다
• 과거 데이터를 다시 채우는 과정(BACKFILL)이 쉬워야함 → 에어플로우의 장점
• 풀리프레시할 때는 이런문제 안 생기는데 인크레멘탈 업데이트를 하게 되면 백필 문제 발생함
• 데이터 파이프라인의 입력과 출력을 명확히하고 문서화하기
• 주기적으로 쓸모없는 데이터 삭제하기(파이프라인, 테이블 등등)
• 데이터 파이프라인 사고 발생시 리포트 쓰기(POST-MORTEM)
  • 동일한, 유사한 사고가 발생하는 것을 막기 위함
• 중요 데이터 파이프라인 입력과 출력 체크하기
  • 입력 출력 체크하는 로직 개발도 좋다

BACKFILL

왜 필요한가?

• 인크레멘탈 업데이트 하는 경우에만 BACKFILL이 의미있음
• 가끔 소스쪽에 변경이 생기면서 전체를 다시 읽어와야 할 수도 있음
• BACKFILL 코드 스타일이 다르면 유지보수어렵

DAILY INCREMENTAL UPDATE 구현하기

• 2020년 11월 7일부터 매일 하루치 데이터 읽어오기
• ETL 동작 시작은 2020년 11월 8일부터 시작
• 11월 8일 동작하지만, 읽어와야 하는 데이터 날짜는? 11월 7일
• START_DATE : DAG가 읽어와야 하는 데이터의 날짜를 의미함 (그래서 2020년 8월 7일 시작이 아니라, 하루 뒤인 8월 8일 실행이 됨. 데이터는 8월 7일 데이터를 가져오고)

INCREMENTAL하게 1년치 데이터를 BACKFILL한다면?

어떻게 ETL 구현하면 편해질까?

• 해결방법 2
  • 모든 DAG는 EXECUTION_DATE 지정되어있음
  • EXECUTION_DATE로 채워야하는 날짜와 시간 넘어옴
  • 여기 더 공부해볼 것. 추후에 설명해주실 것

START_DATE와 EXECUTION_DATE 이해하기 - 가장 중요

• 캐치업?
• 캐치업필요 없으면 FALSE로 설정하기
• EXECUTION_DATE : ???어떤 의미??? 그냥 이 변수를 가져와서 코딩하면 된다.
• 이 예시에서 캐치업FALSE면 아무것도 실행되지 않을 것임. FALSE로 설정하면 과거에 안 잡힌건 그냥 놔두고 미래만 보고 달려감
• execution_date = start_date + (interval * N)

질의응답

💡 3번 파이프라인(Production Data Jobs)의 경우 백엔드 엔지니어가 해도 되는 일이 아닐까 생각이 드는데요. 백엔드 엔지니어와 역할분담을 나누는 기준 같은게 있을까요? DW를 건드리는 경우에 데이터 엔지니어가 한다고 생각해도 될지 궁금합니다.

-> 정해진건 없고 회사마다 하기 나름임