커리어
커리어 사다리라는 것은 없다.
커리어는 정글짐이다. 위로 항상 가면 좋겠지만 옆,아래 굉장히 많은 방향성이 있다. 옆으로 아래로 떨어지는게 당연한 세상이다. 길게 보면 젊었을때 몇년 허송세월한것 같아도 만약에 선택했던 회사가 망해도 내가 망하는 것은 아니다. 젊었을때 내가 하고싶은 일을 하다보면 나를 알 수 있다.
- 허송세월은 없다. 무슨 경험을 하던 그것을 바라보는 관점이 중요하다. 항상 위로 올라가야하는 것은 아니다.
- 요즘은 전문성, 안전성은 의미 없다. 경험, 배워나가는 능력이 중요하다.
- 기술은 항상 발전하고 바뀐다. 기술에 목숨을 걸면 안된다. 어떤 기술을 잘 활용하는 경험, 성취하는 경력, 그것을 통해 자신감을 얻는다. 경험,경력,성취는 어떤 기술로도 대체가 되지 않는다.
어느 배움이건 정체기가 있다. 정체기를 바라보는 관점이 중요하다.
- 버텨라. 당연하게 생각하고 즐겨라. 정체기가 왔을때 포기하지 마라.
- 잘하는 사람을 보고 기죽지 말아라.
기술을 쫓아다니지 마라. 성취하는 경험을 해라. 그 일을 왜, 전체에서 어떤의미, 아웃풋이 어떤형태여야 성공 실패, 전체적으로 일의 우선순위가 어떻게 되는가?
의사소통 능력이 중요하다. (자기 검열 안하고 질문 잘하기)
모르는 것이 있으면 편하게 물어봐라! 질문하는 것이 힘들다면 좋은 환경이 아니다.
정확히 이해한것이 아닌것 같으면 내가 이해한 것이 맞는지 확인해봐라
나의 성장을 저해하는 요소
나이 혹은 남과의 비교
나에 대한 고정관념, 과거의 상처
-> 나에 대한 인지를 해라
=> 어떤 일을 함에 있어 위의 요소가 걸림돌이 된다면 다시 해봐라
꾸준함이 중요하다
꾸준히 운동해라
내가 하고싶은거 해라, 혹은 내가 하는 일을 잘하기 위해서
사람을 많이 만나라, 상대방을 첫인상으로 판단하지 마라
책읽기/글쓰기
우리의 커리어도 agile
빠르게 순환한다! 취업준비 오래? 의미 없다. 적당히 사람좋고 성장하는 곳을 찾아서 돈벌면서 성장해라! 큰 회사 작은 회사? / 성장하는 회사, 좋은 동료가 있는 회사
데이터 팀
데이터팀이 하는 일
- 품질이 좋은 데이터로 부가가치를 만들어 내는 곳
- 데이터 엔지니어가 데이터 분석 전용 데이터, 웨어하우스에 ETL 파이프라인을 통해 데이터를 적재
- 데이터웨어하우스, ETL 파이프라인 메니지먼트
- 데이터 엔지니어는 데이터팀을 서포트하는 역할
++ Datawarehouse vs datalake
datalake가 크기가 크다는 느낌? 그래서 구조화 되지 않은 데이터를 저장해도 된다는 느낌
데이터 팀의 구조
- 중앙집중된 구조 -> 분산형 -> 중앙집중된 구조 -> 분산형 .. 반복하는 경우가 많다
- 하이브리드 형태가 좋다. 기본 중앙 집중화 되고 파견 형태로
- 면접할때 물어볼 수 있는 좋은 질문 데이터 팀의 조직구조가 어떻게 되느냐?
데이터 팀이 중요하게 생각해야하는 것
- 데이터 팀은 결국 데이터로 결과를 만들어 내야한다
- 인프라가 중요하다
- 데이터의 질이 중요하다 GIGO
- 지표부터 만들어야 한다. 성공과 실패를 측정하는 능력 = 문제정의 능력
- 간단한 솔루션일 수록 좋은 솔루션이다.딥러닝 머신러닝을 하다보면 내가 배운 것을 활용해보고 싶다. 하지만 모델을 활용하면 복잡도가 올라간다.
Data engineering
어떻게 데이터에서 의미를 찾을 것인가?
서비스의 수익성을 가져다 주기위해선
1. 돈을 쓰는 사용자는 누구인가?
2. 재방문률/이탈률이 어떻게 되는가?(Retention/Churn Rate)
3. 주요 이탈요인이 무엇인가?
를 고려해야함
서비스를 운영할때 서비스에 대한 트러블슈팅 전화가 온다면 어떻게 해야할까? 더 이상 트러블 슈팅 전화가 오지 않도록 문제를 해결해야할 것이다. 하지만 그보다 더 중요한 것은 트러블 슈팅 전화 조차 하지 않고 이탈하는 사용자에 대해 조사하는 것이다. 이처럼 데이터를 바라볼때 다양한 각도로 바라보는 것이 중요하다.
데이터 엔지니어의 역할
- 데이터웨어하우스 매니징 -> 클라우드 서비스 활용
- 데이터 파이프라인 작성,매니징 : 데이터 파이프라인 = ETL = 데이터 잡 = DAG
- 데이터 파이프라인 유형: 배치 프로세싱, 리얼타임
- 서머리 데이터 생성 == ELT (debt - Analytics Engineer)
- Skill : SQL 파이썬 에어플로우 Spark Docker, Kubernetes, 클라우드
데이터 웨어하우스는 어디서 읽어오나
- 프로덕션 데이터베이스, 마케팅을 했던 서비스에서 발생한 데이터를 ETL 파이프라인으로 가져옴
- 데이터 웨어하우스에 존재하는 데이터를 조합해서 새로운 것을 만들 수 있음. 이것을 ELT
ELT : dbt(data build tool) Analytics engineer
Redshift
- AWS 에서 제공해주는 데이터 웨어하우스
- OLAP, 빠른 응답시간을 보장하지 못함
- Columnar storage, record 단위로 저장하는 것이 아니라 column단위로 저장을함
- Bulk update 클라우드 서비스에 파일 형태로 저장하고 테이블로 한꺼번에 저장
- 데이터를 빠르게 저장하기 위해 프라이머리 키 유일성을 보장안함 -> 프라이머리 키 보장은 시스템의 책임이 아니라 데이터를 저장하는 사람의 책임
- json을 지원 안함, 텍스트 파일의 길이의 제약이 있음 postgresql과 달리
- 테이블이 다수의 노드로 구성이 되는 경우(분산 시스템?) 노드에 균등하게 저장되지 않아 skewed table이 생길수 있다.(병렬처리를 할때 문제) 어떤 노드에 저장할 것인지를 정해줘야하는 overhead가 있다. Redshift optimization이 다른 데이터 웨어하우스 보다 복잡하다.
- Redshift 는 aws와 다른 서비스와 커플링이 잘 되어 있음
- Athena(하둡 프레스토 SQL 엔진) : 비구조화 된 데이터를 구조화된 데이터로 정재/변경하는데 적합함, 비구조화 데이터를 다룰때 활용
- 캐싱 지원
Redshift 접근 방법
- 시각화 툴을 활용한 접근 : tableau, looker, superset…
- JDBC/ODBC Library : psycopg2(python)
- SQL clients(Postico, SQL workbench, DBeaver, DataGrip(JetBrain 사용중이라면 강추), Python Notebook
Redshift Schema
저장되는 테이블의 수가 많아지면 테이블을 구분하는 것이 어려워진다. 그래서 Schema를 만들어 테이블의 속성에 따라 저장함
스카마의 예
- raw_data => ETL 파이프라인을 통해 저장된 데이터 (데이터 엔지니어)
- Analytics => ELT를 통해 저장된 데이터
- Adhoc => play ground의 성격, 테스트를 위한
데이터 엔지니어는 어떤 데이터를 가져오는지 알아야함. 그래야 데이터 품질을 케어할 수 있음
스키마는 권한이 있어야 만들 수 있음. 보통 권한은 그룹별로 부여함
