[TIL 31일자] 데브코스 데이터엔지니어링

·2023년 5월 22일
0

데브코스

목록 보기
30/55
post-thumbnail

📚 오늘 공부한 내용

1. 데이터 팀의 역할

1) 데이터 조직의 비전은?

  • 신뢰할 수 있는 데이터를 바탕으로 부가 가치를 생성
  • 데이터 팀이 어떻게 매출에 기여할 수 있는가?
    • 의사 결정에 데이터를 활용할 수 있도록 해 준다. 즉, 고품질 데이터를 기반으로 의사 결정권자에게 입력을 제공한다.
      • 결정 과학 (Decision Science)
      • 데이터 고려한 결정을 가능하게 해 줌
      • 예를 들어 데이터 기반 지표 정의, 대시보드, 리포트 생성과 같은 일을 수행
    • 고품질 데이터를 기반으로 사용자 서비스 경험 개선 혹은 프로세스 최적화한다.
      • 보통은 머신 러닝 같은 알고리즘을 사용해 개선한다.
      • Prouduct Science
      • 첫 번째 방법보다 조금 더 고도화된 방법으로 첫 번째가 되어야지 두 번째 방법을 수행할 수 있다.

2) 데이터 엔지니어 역할

  • 데이터 분석용 데이터베이스인 데이터 웨어하우스를 셋 업 하고 관리, 운영하는 것
    • 데이터 웨어하우스클라우드 기반으로 가는 추세이며, 데이터가 커질 수록 클라우드 기반으로 가야 한다.
  • 외부에 있는 다양한 데이터 소스에서 데이터를 추출해서 정제한 후 데이터 웨어하우스에 적재해 주는 프로세스를 구현하고 관리, 운영하는 것 (ETL)
    • ETL 스케줄러 혹은 프레임워크가 필요. (airflow라는 오픈 소스가 많이 쓰임.)
  • ETL 과정이 데이터 점점 커지게 되면 데이터 레이크가 도입되고, 빅데이터 프레임워크 Spark를 사용한다.
  • 자원의 낭비가 생기는 경우를 방지하기 위해 Container Technology를 사용한다.
  • 즉, 데이터 인프라를 구축
  • 데이터 분석가데이터 과학자 일을 효율적으로 할 수 있도록 지원

3) 데이터 엔지니어가 알아야 할 기술

🔨 주니어 데이터 엔지니어가 알아야 할 기술

  • SQL
  • 프로그래밍 언어: Python, Scala, Java
  • 데이터 웨어하우스: Redshift/Snowflake/BigQuery
  • ETL/ELT 프레임워크: Airflow
  • 대용량 데이터 처리 프레임워크: Spark/YARN

🔨 알면 도움이 되는 기술

3) 데이터 팀의 구성

  • 데이터 엔지니어 (Data Engineer)

    • 데이터 인프라 (데이터 웨어하우스와 ETL) 구축
  • 데이터 분석가 (Data Analyst)

    • 데이터 웨어하우스의 데이터를 기반으로 지표를 만들고 시각화 (대시보드)
      • 대시보드란 보통 중요한 지표를 시간의 흐름과 함께 보여 주는 게 일반적이다.
      • 지표의 경우 3A (Accessible, Actionable, Auditable)가 중요하다.
      • 가장 널리 사용되는 대시보드
        - 구글 클라우드의 Looker
        - 세일즈포스의 Tableau -> 가장 많이 사용됨
        - 마이크로소프트의 Power BI
        - 오픈소스 아파치 Superset
      • 이를 보고 중요한 결정을 내릴 수 있다.
    • 내부 직원들의 데이터 관련 질문 응답
  • 데이터 과학자 (Data Scientist)

    • 과거 데이터를 기반으로 미래를 예측하는 머신 러닝 모델을 만들어 고객들의 서비스 경험 개선
    • 개인화, 자동화 혹은 최적화

    -> 이상적으로는 1. 데이터 인프라 2. 데이터 분석 (지표 정의 및 시각화) -> 3. 데이터 과학 적용 (사용자 경험 개선) 순서로 가는 것이 좋다. 하지만 스타트업에서는 데이터 인프라 환경도 구축되지 않은 곳이 많다.

4) 새로운 데이터 직군들 혹은 서비스

  • ML 엔지니어
  • MLOps
    • DevOps와 하는 일은 동일하나 차이점은 코드가 아니라 ML 모델이 대상
    • 모델을 계속적으로 빌딩하고 배포하고 성능을 모니터링
  • 프라이버시 엔지니어
    • 전체 시스템에서 개인 정보 보호를 위한 가이드 라인과 툴을 제공
  • 데이터 디스커버리 서비스

2. 데이터 웨어하우스

✍ [데이터 엔지니어링] 데이터 웨어하우스(Data Warehouse)
내용이 길어져 따로 포스팅하였다.


3. 데이터 레이크


(사진 출처: http://blog.skby.net/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%A0%88%EC%9D%B4%ED%81%AC-data-lake/)

  • 데이터 레이크를 사용하는 이유
    • 데이터 웨어하우스는 기본적으로 SQL을 기반으로 데이터를 처리하는 관계형 데이터베이스이다. 즉, 로그 파일과 같은 비구조화된 데이터를 저장하고 처리하기에는 부적합하다.
    • 또한 비용이 비싸기 때문에 비구조화된 데이터를 적재하기에는 좋은 옵션이 아니다.
  • 스토리지에 가깝기 때문에 비용이 훨씬 더 경제적이고, 큰 비구조화된 데이터를 저장하기에 무리가 없다.
  • 클라우드 환경에서는 클라우드 스토리지가 된다. 예를 들어 AWS라면 S3가 대표적인 데이터 레이크가 된다.
  • 만약 로그 파일과 같이 비구조화된 데이터라면 바로 데이터 웨어하우스에 적재해 주는 게 아니라 ETL을 통해 데이터 레이크 안으로 가지고 오고, 필요할 때마다 이 데이터를 Load 해서 프로세싱한 후 데이터 웨어하우스에 저장하는 형태로 가게 된다.
  • 데이터 레이크가 있는 환경에서의 ETL과 ELT
    • 잘 정제된 데이터라면 데이터 레이크로 갈 필요 없이 데이터 웨어하우스에 적재되면 되므로 ETL이라고 볼 수 있다.
    • 또한 비구조화된 데이터라서 데이터 레이크 적재되는 것 또한 ETL이다.
    • 즉, 외부의 데이터를 데이터 레이크데이터 웨어하우스로 가지고 오는 것ETL이라고 한다.
    • 반대로 데이터 레이크나 데이터 웨어하우스에 이미 적재된 데이터를 프로세싱해서 새로운 데이터나 정제된 데이터를 만드는 과정을 ELT라고 한다.
    • 즉, 내부의 데이터를 처리하는 것ELT라고 한다.
  • ETL은 주로 airflow를 사용하고, ELT는 airflow를 통해 스케줄링은 하지만 새로운 데이터를 만들 때는 DBT라는 툴을 많이 쓴다.

4. 다양한 데이터 소스의 예

  • 프로덕션 데이터베이스
    • MySQL, Postgres 등
  • 이메일 마케팅 데이터
    • Mailchimp, HubSpot, SendGrid 등
  • 크레딧 카드 매출 데이터
    • Stripe
  • 서포트 티켓 데이터
    • Zendesk, Kustomer 등
  • 서포트 콜 데이터
    • ChannelTalk, RingCentral, Talkdesk 등
  • 세일즈 데이터
    • Salesforce
  • 사용자 이벤트 로그 (Data Lake에 더 적합함)
    • Amplitude, MixPanel, 웹 서버 로그 등

5. ETL / ELT

✍ [데이터 엔지니어링] ETL/ELT
내용이 길어져 따로 포스팅하였다.


6. 데이터 플랫폼의 발전 단계

  • 초기 단계: 데이터 웨어하우스 + ETL

  • 발전 단계: 데이터 양이 증가하면서 감당하지 못해 두 가지 변화가 필요한 상태

    • 데이터 레이크 도입 (보통 로그 데이터와 같은 대용량 비구조화 데이터를 대상으로 함)
      • 데이터 소스 -> 데이터 파이프라인 -> 데이터 웨어하우스
      • 데이터 소스 -> 데이터 파이프라인 -> 데이터 레이크
      • 데이터 레이크 -> 데이터 파이프라인 -> 데이터 웨어하우스
        • 이때 Spark/Hadoop 등이 사용됨
      • 데이터 레이크 -> 데이터 파이프라인 -> 데이터 레이크
      • 데이터 웨어하우스 -> 데이터 파이프라인 -> 데이터 웨어하우스
    • Spark와 같은 빅데이터 처리 시스템 도입 (데이터 레이크에 있는 데이터들을 처리할 수 있도록)
  • 성숙 단계: 데이터 활용 증대

    • 현업의 사람들 데이터 활용이 가속화
    • 데이터 플랫폼에서는 ELT 사용이 쉬워져야 하고 ELT 단에서 나오는 데이터의 품질이 중요해짐.
      -> ELT 단의 고도화가 필요해짐 (DBT 등의 Analytics Engineering 도입)
    • MLOps 등 머신 러닝 관련 효율성 증대를 위한 노력 증대
    • 더 나아가게 되면 각 현업들이 자신만의 웨어하우스 ETL을 구성하기를 원하기도 함


✔ 특강 (다양한 데이터 웨어하우스 살펴보기)

✍ 회사를 고를 때 보는 조건

  • 급격한 성장 (성장 가능성)
  • 문화 (사람)
  • 자유도

✍ 데이터 엔지니어 관점에서 회사를 보는 조건

  • 데이터 팀은 기본적으로 협업을 많이 하는 팀이기 때문에 회사 문화가 중요함
  • 데이터 문해력이란 측면에 얼마나 회사가 관심과 투자가 있는지
  • 데이터 조직과 활용도 회사 성장과 함께 같이 발전하는가
  • GDPR 준수로 인해 데이터 품질 관리와 거버넌스에 집중할 수 있는가

Udemy 데이터 엔지니어링 (현업에서 데이터 팀의 성장 흐름을 보여 주기 위해 이 특강을 준비하였다고 함)

1) 데이터 웨어하우스 도입 (RedShift)

2) ETL 프로세스 개발

  • crontab으로 관리하다가 pinterestpinball로 이전
    • crontab은 간단하게 현재는 Airflow 사용
    • 이제는 pinbal을 쓰지 않음
  • 처음에는 데이터 복사만 하다 점차 중요 프로세스의 개발도 시작함
    • 중요한 파이프라인의 경우 SLA (Service Level Agreement) 설정하고 지표로 계산

3) Decision Science 팀 도입 및 BI 툴 도입

  • 지표 표준화
    • 매출, Active Students, Active Instructors 등등
    • 데이터 문해력: 데이터를 기반으로 의사 소통을 할 수 있는가
  • 내부 직무 전환 제도를 통해 디지털 마케터들을 분석가로 많이 뽑음
  • 현업 부서들과의 협업 (하이브리드 모델)
    • B2C 마케팅 기여도 분석 프로세스를 정립
    • B2B 세일즈 파이프라인 분석 프로세스 정립

4) Product Science 팀 도입 및 ML 모델을 Production에 사용하기 시작

  • A/B 테스트 프로세스 도입
    • Data Driven Decision
    • 객관적인 비교 프로세스를 도입하기 위함

📊 A/B 테스트란?

  • 온라인 서비스에서 새 기능의 임팩트를 객관적으로 측정하는 방법
  • 원래 의료 쪽에 있던 무작위 대조 시험(Randomized Controlled Trial) 기반으로 만들어진 테스트 방법
  • 새 기능을 도입할 때 생기는 위험 부담을 줄이는 방법
    • 만약 추천을 기계 학습 기반으로 바꾼 경우,
      • 먼저 5 % 사용자에게만 새로운 기능을 사용할 수 있게 만들고 95 %의 사용자와 매출액 같은 중요한 지표를 가지고 비교
      • 이후 5 %의 문제가 없으면 10 %, 20 % 점진적으로 키우고 만약 비교했을 때 새 기능이 기존의 기능보다 매출액 등 지표가 되는 부분이 높아졌다면 최종적으로 100 %로 론치(launch)한다.

📌 데이터 과학자와 개발자의 마찰 시점

  • 데이터 과학자들이 R을 비롯해 다양한 툴로 모델을 개발함.
  • 하지만 실제 프로덕션 환경에서는 다양한 모델을 지원하지 않기 때문에 개발자들이 포팅을 해야 함.
  • 심한 경우 모델 관련 개발을 다시 해야 함.
    이를 해결하기 위해 처음부터 데이터 과학자들이 사용해 주는 툴을 개발자들이 사용하는 언어와 지원이 되는 환경으로 설정해야 함.

📌 머신러닝(Machine Learning)의 모델을 왜 주기적으로 빌드 해 주어야 하는가?

  • Data Drift: 시간이 지나면서 훈련에 사용한 데이터와 실제 환경의 데이터가 다르게 변화하는 현상.
  • Data Drift로 인한 모델 성능 저하가 일어나며 이를 모니터링해 주는 것이 중요하다.
  • 이러한 Data Drift 현상 때문에 머신러닝(Machine Learning)의 모델을 주기적으로 빌드 해 주어야 한다.

5) 클라우드로 이전

6) 데이터 레이크Spark 도입

  • Hive + Spark 중심으로 변화
  • S3를 데이터 레이크로 사용
  • Spark가 도입되면서 ML 모델링과 스트림 데이터 처리 시작

7) 데이터 활용 증가로 데이터 디스커버리 이슈가 발생 (대부분의 회사들이 겪는 이슈)

  • 너무 많은 테이블들이 만들어지기 시작함
  • 매출 관련 분석을 하려면 어떤 테이블을 써야 하는가?
  • 매출의 정의가 무엇이냐?
  • 매출 관련 가장 믿을 만한 대시보드는 무엇인가?

8) 데이터 디스커버리 이슈 해결

  • Airbnb에서 동일 이슈 해결을 위해 만든 Airpal을 레퍼런스로 삼음
  • 다양한 로그 데이터를 기반으로 검색 엔진을 만듦
    • Hive metastore 스키마와 SQL 쿼리 로그
    • Redshift SQL 쿼리 로그
    • ChartIO 액세스 로그
    • Pinball 로그
  • LinkedIn 오픈 소스한 DataHub로 정착 (국내에서는 쏘카 데이터 팀이 최초로 DataHub를 도입)

9) GDPR 준수

  • 개인 정보가 약관에 맞추어 사용되고 있고 불필요한 개인 정보가 사용되지 않도록 해야 한다는 법률안.
  • GDPR에서 가장 중요하게 생각하는 건 개인 정보의 주체는 개인에 있다.
    • 삭제권, 거부권, 이동권을 요구할 수 있고 이를 30 일 내에 수행해 주어야 함.
    • 개인 정보를 삭제할 때 어디까지를 삭제해야 하는가?
  • 처음에는 매뉴얼하게 하다가 자동화
  • PII 파악과 시스템 전반 사용 파악불필요 PII 제거와 감사 기능 구현
    • 데이터가 처음 도입될 때 PII 태깅을 의무화 (ETL)
    • 쓸 일이 없다면 개인 정보를 데이터 시스템 안에 가지고 오지 않도록 하는 게 좋음
  • PII 데이터를 최종적으로는 별도 물리 서버에 저장
  • 모든 데이터는 암호화
  • 정말 권한이 필요한 사람들에게만 접근 권한 부여 (CS 팀)

10) Data DemocratizationData Decentralization은 거스를 수 없는 추세

  • Data Mesh 데이터 활용을 완전히 분산화하기 위한 기술
  • 데이터 인프라는 데이터 엔지니어의 업무지만 다만 데이터 문해력이 있는 팀들부터 독립적으로 데이터 업무 수행을 할 수 있도록 환경을 만들어 줌.

11) 데이터 거버넌스 시작

  • 데이터 활용이 전사적으로 생기면서 더 많은 팀이 데이터를 활용하게 될 것이고 이 과정에서 개인 정보가 잘못 사용되는 경우를 막기 위한 프로세스

🔨 현업에서 사용한 툴

1) 데이터 웨어하우스와 데이터레이크

  • MySQL
  • Redshift
  • Hive/Presto/S3 -> Spark/S3
    -> 만약 돈이 충분하다면 Snowflake

2) 대시보드 툴

  • Google Spreadsheet
  • ChartIO
  • Tableau
  • Looker, Power BI, Redash
    -> 만약 지금 하게 된다면 Tableau나 Looker

3) ML 관련 툴

  • R, Scikit-Learn
  • Spark, Spark ML
  • Spark Streaming, Cassandra, Kafka
  • MLflow

4) ETL/ELT frame work

  • Cronjob
  • Pinball
  • Airflow
    -> 지금 한다면 Airflow와 DBT를 같이

5) 데이터 카탈로그/거버넌스

  • WhereHow -> 자체 툴 -> DataHub
  • Alation

🔨 개인 정보 보호

  • 개인 정보를 동의 없이 저장하고 사용하지 않는 것
  • 개인 정보를 동의 없이 노출하거나 배포하지 않는 것
  • 보호를 위한 다양한 법률이 GDPR을 기점으로 세계적으로 만들어지고 있음

  • 국내 (9월 법률 개정은 세 개의 보호법이 합쳐짐)
    • 개인 정보 보호법, 정보통신망법
    • 클라우드 컴퓨팅법
  • 미국
    • CCPA / CPRA (캘리포니아에만 적용되는 법)
    • HIPAA (의료 관련법)
    • Cloud Act, Honest Ads Act 등
  • 유럽 연합
    • GDPR

🛠 내부자 vs 외부 위협

  • 내부 사람들의 단순한 실수로 비롯된 Data Leak
  • 외부 위협의 예는 해커, 랜섬웨이, 사이버 범죄 조직 등
  • 이 문제를 해결하기 위해 생각해 보아야 하는 것
    • 보호가 필요한 중요 정보는 무엇인가?
    • 이런 정보들이 정말 우리에게 필요한 정보인가?
    • 이 정보에 대한 접근이 정말 필요한 사람은 누구인가?
    • 이 사람들이 정말로 해당 정보에 필요할 때 접근하는가?

🔎 어려웠던 내용 & 새로 알게 된 내용

특강 중 Cloud 이전을 반대했다는 내용이 있어 만약 반대한다면 무엇이 원인이었는지에 대해 물어보았다.
: 보통 Cloud를 반대하는 건 비용적인 측면이 강하고, 재무 팀에서 주로 반대를 한다고 한다. CAPEX는 연간 예산을 잡아 놓고 쓰는 것이고 OPEX는 매달 비용이 발생할 때마다 지출하는 것인데 대부분의 재무 팀은 CAPEX가 익숙하다. 그런데 Cloud는 매달 얼마나 쓰게 될지를 예측할 수는 있으나 정확하게 환산할 수 없으므로 OPEX 시스템이 된다. 그리고 개발자적 관점에서 Cloud는 좋지만 잘못 쓰게 되면 비용이 더 많이 청구되기 쉽다. (끄지 않았을 때)

1. Data Informed Decision vs Data Driven Decision

  • Data Informed Decision은 데이터를 고려한 결정으로 회사가 가고자 하는 방향을 정해 두었다면 그 방향으로 가는 과정에서 데이터를 참고하는 것을 말한다.
  • Data Driven Decision은 데이터 기반 결정으데이터가 이야기하는 대로 방향을 정하는 것을 말한다.
  • 데이터는 과거의 기록이다. 만약 과거의 기록만을 보고 방향을 정한다면 최적화를 할 수는 있겠지만 새로운 혁신을 만들기는 어렵다.
  • 즉, 둘을 적절하게 섞어서 사용하는 것이 중요하다.

✍ 회고

- 예전에 한기용 강사님께서 면접 때 데이터 인프라가 잘 구축되었는지 알기 위해서 데이터 웨어하우스로 어떤 걸 쓰고 있는지 먼저 질문해 보는 것도 좋다고 알려 주셨고, 이번 강의에서도 이 부분을 이야기하셨다. 데이터 웨어하우스가 구축이 되어 있는 회사라면 데이터 팀의 역할이 분명한 회사이고, 만약 데이터 엔지니어를 뽑음으로써 데이터 웨어하우스를 구축할 계획이 있는 회사라면 그것 또한 배울 수 있는 기회라고 하셨다. 그리고 오늘 추가적으로 더 할 수 있는 질문들을 말해 주었다. 대시보드 툴은 어떤 걸 쓰는지, 또 중요한 지표는 데이터 기반으로 자동 계산이 되는지 물어볼 것을 추천해 주셨다. 만약 이 부분까지 갖추어져 있다면 회사 데이터 시스템이 고도화된 곳이라고 볼 수 있다. 다만 갖추어지지 않았다고 해도 내가 해 볼 수 있는 일이 될 수도 있다고 하셨다. 늘 나 역시도 내가 일하게 될 회사에 대한 기준을 항상 생각해 두려고 하는 편이지만 배운 것을 토대로 좀 더 명확한 기준을 정해 두면 좋겠다고 생각했다.

- 퀴즈 문제에 있기도 하고 특강과 오늘 강의에 모두 나왔던 데이터 디스커버리와 관련해서 혼자 조금 더 공부해 보고 싶어 찾다가 쏘카 기술 블로그의 데이터 디스커버리 플랫폼 선정 과정에 대한 포스팅이 있어 좀 더 알아보았다. 쏘카가 국내 처음으로 DataHub를 도입한 회사라고 해서 호기심이 생겼었는데 해당 글을 정독해 보며 나도 이런 데이터 팀에서 겪을 수 있는 다양한 과정을 겪으며 경험하고 싶다는 생각이 들었다.

profile
송의 개발 LOG

0개의 댓글