둘다 엔지니어 배경이 아닌, 인문학과 공연학을 전공한 친구들. → 미국도 인문계는 취업이 어렵다고 함.
현재는 데이터사이언스팀 매니저로 업무를 함.
시작은 미약했지만, 커리어를 잘 성장시킨 케이스
Meet M & S and coding boot-camps
여성들을 대상으로하는 파이썬 부트캠프..
M은 열심히 알려주었는데 에어비엔비 데이터엔지니어로 도망(?)감.
코딩을 처음 배운사람도 노력에 의해 어디든 갈 수 있다는 것을 보여주는 선례.
천재가 아닌이상 미니멈 6개월을 해야함.
네트워킹
일별 활동 보기
월요일
스프린트는 2주 기간.→ 칸반(vs. 스크럼)
스프린트 데모 미팅 (30분)
스프린트 회고 미팅
무엇이 잘되었고, 잘할수있었을지
스프린트 플래닝 미팅
다음 2주 스프린트 계획.
하루 5시간 일한다고 가정.
40%의 시간은 인프라 코드의 리팩토링에 사용.
On-Call 미팅
애자일 보드
TODO | DOING | DONE 으로 구분.
화요일
스탠드업 [매일 아침마다 가볍게 할 내용 공유. → 플랭크 미팅]
지난 24시간. 앞으로 24시간.
어려운 점. 이슈되는 내용.
매번은 아니고 슬랙으로 대체하기도 함.
데이터엔지니어링 == 노가다
데이터 파이프라인을 높은 수준으로 계속 유지하는 과정.
슬랙/이메일로 실패를 확인.
사고가 발생하면 다음 사고를 방지하기 위한 대처.
백필 (4주차에 설명함0
사고가 생기거나 품질에 이슈가 있을때, 데이터가 어떠한 이유로 적재가 되지 않았을 때 함.
에어플로우를 쓰는 이유 중에 하나가 이것. 백필이 쉬워진다.
수/목
오피스 아워
데이터분석가 한 사람이 한 시간 정도 시간을 내서 내부 직원들로부터 다양한 데이터 관련 질문에 답을 해줌. → 한번에 몰아서 해결.
금
주간 스태프 미팅
지표 & 분기 목표 리뷰.
DW capacity 리뷰 → 용량이 혹시나 부족한지. 미리 확인.
주요 데이터 파이프라인 실패의 비중 확인.
리크루팅 & 리텐션
주간 사건incident 리뷰 - postmortem(사후) 리뷰.
쓰는 이유는 동일 사고를 막기 위함.
사고가 언제 발생.
얼마나 영향이 있었고.
타임라인.
원인파악
액션 아이템
메인 프로젝트 리뷰
외부/내부 프로젝트
팀/개인 업데이트
Cloud & AWS
정의
컴퓨팅 자원을 잘못 관리해서 해고된 케이스도 많음. 그러니 자원을 탄력적으로 필요한 만큼 잘 쓰는 것이 중요함.
클라우드 컴퓨팅이 없다면.
서버/네트웍/스토리지 구매와 설정 등을 직접 수행.
데이터센터 공간도 직접 확보
위 공간에 서버를 구매하여 설치하고 네트웍 설정 → 적어도 두세달 걸림
피크 타임 기준 capacity planning 해야함.
(결론)직접 운영비용 vs. 클라우드 비용.
무엇이 더 나을까? 정신적 스트레스. 관리 기회비용을 생각하면 압도적으로 클라우드가 나을 수 있다.
클라우드 컴퓨팅 장점
초기 투자 비용이 크게 줄어듬
CAPEX(Capital Expenditure) vs. OPEX(Oprating Expense)
CAPEX(재무팀에서 관리. 감가상각 등을 고려.) → OPEX
리소스 준비를 위한 대기시간 대폭 감소
클릭 한번으로 필요한 자원을 제어 가능.
노는 리소스 제거로 비용 감소
글로벌 확장 용이
소프트웨어 개발 시간 단축 (SaaS)
클라우드 이전에 있었던 문제점들(큰 기업)
C레벨의 지원이 적음.
기존 인력들의 반발.
새로운 기술의 재교육 비용.
일이 달라지는 거지 없어지는게 아님. 그러나 사람들은 두려움이 있음.
AWS 소개
시작하게 된 배경.
남은 서버자원을 팔아보는 것에서 시작.
20조 정도 순이익이 나옴.
점점 글로벌 클라우드 시장 점유율이 높아짐.
MS가 많이 따라왔음.
AWS Regions
미국 버지니아에서 시작해서 이제는 안하는 대륙이 없음.
AWS 서비스
EC2로 시작했다가 DataBase, AI/ML 등을 제공
맥스의 클라우드 사용 후기.
구글 클라우드가 사용성 면에서는 가장 만족함. 다만, 커뮤니티도 작은 점은 아쉬움.
AWS는 잡화점 느낌.
EC2
Spot Instance
경매방식.
만약 경매에 실패했다면, 작업이 중단됨.
S3
낮은 비용 1TB/월 → $23
글래시어 스토리지 $4
가격은 싼데, 파일 하나 읽는데 4시간 걸림.
그 외 기타 중요 서비스
RDS
SageMaker → AI/ML
Alexa → 보이스봇
Connect → 콜센터
Lambda
최근에 Airflow 론칭함. → MWAA.
이전에는 서버 띄우고 Airflow 설치했었는데, 이제는 직접 구동 가능.
QnA
[질문]
유데미가 작은 회사였을 당시에도 월-금까지 같은 스케쥴을 유지를 하셨나요? 아니면 말씀해주신 것을 기반으로 탄력적으로 스케쥴을 유지하셨나요? 제가 다니는 회사에 적용을 해보고싶은데 쌤께서는 회사의 규모에 따라 위의 스케쥴을 어떻게 탄력적으로 적용하셨는지에 대한 노하우들이 궁금합니다
-
Q. 현재 속한 회사엔 대부분의 데이터 플랫폼이 구축된 상황인데, 제 손으로 직접 구축한게 아니다보니 컴포넌트 하나하나를 파악하기가 어렵더라구요. 이럴 땐 어떻게 파악해가는게 좋을지 여쭙고 싶습니다.
온프레미스와 ec2 비용 비교하실때 기준을 어떻게 잡고 하시는지가 궁금합니다. 예를 들어 저희회사에서 서버비용 비교할때 서버 폐기기한을 대충 5년정도잡고 그 비용을 기준으로 진행을 했는데요 제대로 비교했을때 어떤식인지가 궁금합니다.
Q. 현업에서 EMR을 띄워서 Airflow로 데이터적재를 하고 있는데, Spot instance로 자원을 실행하다보니 가끔씩 실패를 하는 경우가 있습니다. 아까 경매에 실패한 경우를 대비하는 방법에 대해서 설명을 짧게 주셨는데 혹시 그 대안방법을 구체적으로 설명해주실 수 있을까요?
기본은 온디맨드로 하고, 엑스트라 노드를 스팟인스터스로 하는게 좋음.
어느정도 예상을 할 수 있게 함.
운이 좋으면 빨리 끝나는거.
Q. 지금은 데이터 ETL 과정에서 full fresh를 하고 있는데요. 데이터가 점점 커지다보니 로딩시간도 늘어납니다.. 어느정도 규모에 도달하면 incremental update 사용을 고려해야할까요?
full 로 하면 간단함.
그러나 만약에 데이터가 업데이트가 되었거나 뭔가 잘못되었다면 incremental로 할시 다시 적재해야함.
여기서 백필이 들어감.
백필을 해야하는 경우는 사실 엄청 큰 문제임ㅠ
Q. 회사에 dw를 cloud로 이관하려 하는데 고려해야 할점은무엇일까요 규모는 약 250TB정도 됩니다
250TB는 엄청큼. 한번에 옮기지 못함.
여기서 일부만 옮기거나 그런식으로 해야하지 않을까 싶음.
RedShift 소개
Support Bulf-update
데이터량이 많은 경우 CSV,JSON파일을 S3에서 곧바로 테이블로 저장가능한 것을 지원함.
Scalable SQL Engine In AWS
Fixed Capacity SQL engine
최근에는 레드시프트도 가변비용 을 지원함.
vs. SnowFlake vs. BigQuery(가변비용)
PK가 보장이 안됨
이번 실습에 쓸거 dc2.large
월에 고정비. 제일 싼게 $180임. → 50~60명이 써도 큰 문제 없음.
부족할때마다 스토리지나 메모리 등을 추가하면 됨1
레드시프트의 안좋은점.
스노우플레이크, 빅쿼리에 비해 스케일러블 퍼포먼스가 떨어짐. 그 이유는 테이블이 분산되어서 저장해야하는데, 그 부분을 개발자가 수동으로 해줘야 함. 이를 managed로 바꾸면 해결되지만 비용이 비쌈.