[스터디] 실리콘밸리에서 날아온 데이터 엔지니어링 스타터 키트 with Python (6기) - 2주차

2innnnn0·2022년 1월 8일
0

dataengineeringstudy

목록 보기
2/5
post-thumbnail

1주차 복습

  • Q. 데이터분석 → 엔지니어 직무 전환을 준비. 무엇을 우선순위로 준비하면 좋을까요?
    • SQL → Python → Airflow을 기본으로 하면서 MLops를 준비
  • 데이터플로우 복습.
    • Spark 등으로 DW에 데이터를 옮김.
    • DW : 내부 데이터인력(즉 분석용)을 위한 DB임.
      • 서비스DB가 아니기 때문에 조금 느려도 괜찮음.

데이터 팀원들의 백그라운드

  • meet P and D (Peter & David : Udemy 초기멤버 소개)
    • 둘다 엔지니어 배경이 아닌, 인문학과 공연학을 전공한 친구들. → 미국도 인문계는 취업이 어렵다고 함.
    • 현재는 데이터사이언스팀 매니저로 업무를 함.
    • 시작은 미약했지만, 커리어를 잘 성장시킨 케이스
  • 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로 바꾸면 해결되지만 비용이 비쌈.
  • 레드시프트 UDF

  • 레드시프트 스펙트럼

    • 잘쓰지는 않음.
  • 서포팅 데이터 타입

    • 다른 DB(postgresSQL)들과 크게 다르진 않은데 VARCHAR는 크기의 제약이 있음. 65Kb 넘는 건 저장이 안됨.
  • 벌크 업데이트

    • 데이터를 읽어올때 벌크로 S3를 읽어와서 레드시프트에 저장.
profile
성장하고 싶은 데이터분석가.

0개의 댓글