[DEV] 데이터 여정
1.2013-2018 유데미 특징
- 모든 직원들이 데이터 문해력 교육 (SQL)
- 데이터 웨어하우스 (RedShift) 도입
- BI 툴 도입 (ChartIO & Tableau)
- ML 프로덕션 도입 (A/B 프로세스 & MLOps)
- 데이터 디스커버리 툴 개발과 활용
- 누가 대시보드를 만들었는지 알 수 있음
- Cloud + On-Prem -> Cloud 이전
- 데이터 레이크(AWS S3)와 Spark 도입
- GDPR Compliance: PII 태깅과 Lineage 트랙킹
- 데이터팀 협업 모델을 분산 구조로 변경
2013년 10월쯤의 유데미
- ProductionDB를 데이터 분석 DB로 사용
- 새로운 데이터 소스를 추가하는 것이 불가능
- 가끔 최적화가 안된 쿼리를 돌리면 서비스 자체에 문제가 발생함
2014년 8월 데이터 엔지니어링팀을 처음 만듦
- 데이터 웨어하우스 도입 (Redshift)
- ETL 프로세스 개발
- crontab -> Pinball -> Airflow
- 처음에는 데이터 복사만 하다가, 점차 중요 프로세스 개발도 시작
- B2B 강사 보수 계산 (소비율에 따라 나눠줌)
- 중요 파이프라인의 경우 SLA(Service Level Agreement) 설정하고 지표로 계산
- 주로 개인 네트워크를 활용하여 구인
- 데이터 소스 추가 요청을 받는 슬랙 채널 개설
2015년 4월 데이터 분석팀 설립
- Decision Science팀
- BI 툴 도입 (ChartIO)
- 데이터 분석 요구 프로세스 도입
- 티켓의 수와 카테고리가 데이터 관련 만족도와 개선 방향의 중요 지표가 됨
- 투명성의 중요성
- 지표 표준화
- 매출, Active Students, Active Instructors 등등
- 지표 기반 의사결정 방법 교육 -> Next Feature Fallacy
-
내부 직무 전환 제도를 이용해 디지털 마케터들을 분석가로 많이 뽑았음
- B2C 마케팅 기여도 분석 프로세스 정립
- B2B 세일즈 파이프라인 분석 프로세스 정립
- 현업 팀들과 협업 가속화
- 하이브리드 모델
- 하지만, 현업팀들의 욕구를 채워주기에는 역부족 (느림)
- 데이터 문해력 교육과 함께 self-service 모델로 전환을 모색
- 자주 들어오는 질문은 대시보드로 만들기
- 데이터 셋을 제공해주고, 대시보드 비주얼 변경은 현업팀이 담당
- 매주 2번 데이터 관련 오피스 아워 진행
- 데이터 관련 요청이 모두 보이는 슬랙 채널 개설
2015년 4월 데이터 사이언스팀 설립
- Product Science팀
- ML 모델을 프로덕션에 사용하기 시작
- A/B 프로세스 도입
- ML 모델 배포 프로세스 도입
- 다른 엔지니어링 팀과 긴밀한 협업 시작
- MLOps 프로세스 정착
- 다양한 조직에서 ML 관련 도움 쇄도
- 인력 부족
- 분산 환경으로 전환 필요성 절감!
2015년 5월 ML 추천 모델 개발 시작
- 먼저 A/B 프로세스 도입
- Data Driven Decision 정점
- 객관적인 비교 프로세스를 도입하기 위함
- 동시에 모델 배포 프로세스에 대한 협의 시작
- 처음에는 사용자별 추천 강의를 하루에 한 번 저장하는 것으로 시작
- 이때 MLOps 프로세스 도입하여 매일 모델을 새로 훈련
- 나중에 실시간으로 추천 강의를 계산하는 것으로 고도화 (2017년)
- 처음에는 사용자별 추천 강의를 하루에 한 번 저장하는 것으로 시작
2016년 데이터레이크와 Spark 도입
- Hive 중심의 YARN 환경에서 Hive + Spark 중심으로 변화
- Spark 트레이닝 과정을 모든 데이터 엔지니어들과 원하는 데이터 과학자들에게 제공
- S3를 데이터레이크로 사용
- Spark이 도입되면서 ML 모델링과 스트림 데이터 처리도 시작
- Scikit-learn과 R 기반 모델링에서 Spark ML 기반으로 변화
- Spark-streaming을 사용해서 추천 모델을 실시간으로 변경 (2017년)
- Kafka 도입, 운영상의 이슈로 처음에는 쉽지 않았음 (문화의 중요성!)
폭발적인 데이터 활용 증가가 문제가 되기 시작
- 너무 많은 테이블들이 생성됨
- 모든 직원들이 Redshift와 ChartIO에 계정을 갖고 있고,
- adhoc 스키마 밑에 각자 필요한대로 테이블을 만들고 그것으로 ChartIO에 대시보드 생성
- 데이터 디스커버리 이슈 발생
- 매출 관련 분석을 하려면 어떤 테이블을 써야하는지
- 매출의 정의가 무엇인지
- 매출 관련 가장 믿을만한 대시보드는 무엇인지
2017년 초 데이터 디스커버리 툴 도입
- Airbnb에서 동일 이슈 해결을 위해 만든 Airpal을 레퍼런스로 삼음
- 처음에는 WhereHows라는 오픈소스를 써봤다가 포기
- 다양한 로그 데이터를 기반으로 검색 엔진(ElasticSearch)을 만듦
- Hive metastore 스키마와 SQL 엔진 로그
- Redshift SQL 쿼리 로그
- ChartIO 액세스 로그
- Pinball 로그
- 인력 부족으로 큰 성과는 없었지만 GDPR 준수에는 큰 도움이 됨
- 결국 LinkedIn이 오픈한 DataHub로 정작 (2020년)
- 데이터 디스커버리 오픈소스
2018년 4월 GHPR 준수 완료
- PII 파악과 시스템 전반 사용 파악
- PII: 개인정보
- 앞서 데이터 카탈로그가 큰 도움이 되었음
- 불필요 PII 제거와 감사 기능 구현
- 회사 전반에 걸친 리팩토링 필요
- 예를 들어 ML 모델에 사용되는 피쳐 중에 개인정보를 기반으로 만들어진 것들 존재
- audit log 구현 필수
- 데이터가 처음 도입될 때 PII 태깅 의무화 (ETL)
- 데이터 정보 주체 권한 관련 기능 준수
- 삭제권, 거부권, 이동권 요구 가능, 이를 30일 내에 수행해야 함
- 이 부분은 처음에는 메뉴얼하게 하다가 점진적으로 자동화함
- 최종적으로 PII 데이터는 별도 물리 서버에 저장
- 기본적으로 모든 다른 시스템에는 단방향 해시값을 전파
- 모든 PII 데이터 접근은 로깅하고 주기적으로 감사
- 모든 데이터는 암호화
- Data at rest, Data in motion
- 정말 권한이 필요한 사람에게만 접근 권한 부여 (Least privilege)
- CEO vs. CS팀원
- B2B 고객들의 경우 SSO를 통해 PII 저장을 최소화
데이터 팀 협업 모델의 변화 필요성
- 데이터팀이 결국 병목이 됨
- 데이터 문해력이 있는 팀부터 더 독립적으로 데이터 업무를 수행하는 것으로 변경
- 여전히 중앙 데이터 웨어하우스를 사용했기 때문에 데이터 인프라는 여전히 병목으로 남음
- Data Mesh
- 여전히 중앙 데이터 웨어하우스를 사용했기 때문에 데이터 인프라는 여전히 병목으로 남음
데이터 거버넌스 시작 (2017년 말)
- 데이터 거버넌스 : 데이터를 제대로 수집하고 저장하고 관리하고 있느냐
- 처음에는 GDPR 준수가 가장 큰 목표
- 더 나아가면 데이터를 중복해서 만들고 있는지, 불필요한 데이터가 있는지 등 데이터 품질까지 관리함
- 데이터 카탈로그부터 투자하기로 결정
- 데이터 거버넌스 관련하여 Alation을 도입하였으나 결국 포기
- 2020년 다시 도입했으나 만족도가 낮음
- 지금은 DataHub를 데이터 카탈로그와 거버넌스 기본 툴로 사용
사용 시스템과 툴 정리
- 데이터 웨어하우스와 데이터 레이크
- MySQL
- Redshift
- Hive / Presto / S3
- Spark / S3
- 대안: Snowflake, BigQuery
- 대시보드 툴
- Google Spreadsheet
- ChartIO
- Tableau
- 대안: Looker, Power BI, Redash
- ML 관련 툴
- R, Scikit-learn
- Spark, Spark ML
- Spark Streaming, Cassandra, Kafka
- MLflow
- ETL / ELT Framework
- Cronjob
- Pinball
- Airflow
- dbt
- 데이터 카탈로그/거버넌스
- WhereHow -> 자체툴(ES 기반) -> DataHub
- Alation
- Trial만 하고 마무리