데이터 엔지니어 밋업 정리
당근마켓 내용
당근마켓에서 MAU 1900만명의 이벤트를 처리하는 방법
캐럿매트릭스라는 지표를 모은 페이지를 만들었다.
기존 아키텍처 문제점
3일 이내에 포착한 이벤트만 발생 중복 이벤트 필터링 반드시 필요한 필드가 없는 데이터를 제외하는 처리
Sparkjob의 부하가 심해져서 처리하는 시간이 점점 늘어났다. 1시간마다 실행되는데 1시간 이상 걸리는 문제가 발생
처리 과정을 통해 필터링 된 데이터가 얼마나 유실되었는지에 대한 정보를 알 수 없었다. 데이터를 실시간으로 활용하기 어려웠다. Spark를 사용하고 있어서, 배치 작업이 끝나야만 가치있는 데이터를 사용 할 수 있었다.
개선 한 아키텍처
기준
- 확장성
- 실시간성
- 전처리를 모두 거친 실시간 데이터를 보고 싶어 했다.
- 운영 비용
빅쿼리의 호환성을 위해서 Pub/Sub과 Dataflow를 적용
beam을 통해 테스트 코드를 실 서버에 배포하는 것이 간단해졌다.
파이프라인 확장성을 얻을 수 있었음, 주에 400억건정도 이벤트
이벤트 모니터링 ( 전체 데이터중에서 얼마나 invalid한지 ) 서비스
Pubsub으로 피쳐스토어/실시간 디버깅/ML 로 파생 할 수 있는 방법을 활용
SDK의 언어만 바꾸더라도 CPU 사용량의 변화가 있었다. 파이썬의 경우 상당히 많은 부하가 있었음
중복제거에서 beam의 슬라이딩 윈도우로 구현하니 메모리를 많이 씀
- 1분 주기 중복제거했는데 2분뒤에 들어오면 해결 안됨
pubsub message attributes를 통한 중복 제거
Pubsub에서 보낼 때 attribute를 추가해주면 성능지연없이 가능
클라우드가 달라서 비용은 나오는데, 인터 클라우드 약정걸고 절약하거나 GCP 안에서 또 데이터 트랜스퍼를 좀 사용해서 함 장기적으로는 한 쪽으로 이관하는 작업도 고려하고 있음
databricks
DeltaLake 테이블 형식 데이터가 필요한 이유?
실패한 배치 작업시 깨진 파일
스키마 규정 준수 강제 부족
일관성 부족 - 파일 기반은 스트리밍이 어렵고, 일관성
데이터 레이크의 성능 문제
파일의 크기 ( 과하게 쪼개거나, 너무 커서 분산처리가 어렵거나 )
파티셔닝의 유연성이나, 카디널리티 등의 문제
delta가 신뢰성을 보장하는 방법
parquet File + Transaction log(JSON) => 트랜잭션 무결성 + 배치와 스트리밍 통합 + 스키마 준수
데이터 버저닝이 가능 함
인덱싱도 되고, 컴팩션도 해주고, 캐싱도 되고, 스키핑??
다 된다고??