DataRami DataRami

이전 글에서는 빅쿼리 ETL 비용 최적화에 대해 소개했었는데요, 이번 글에서는 빅쿼리를 활용한 데이터 접근성 관리와 일반 사용자들의 사용량 관리에 대해 작성해 보겠습니다. Phase 4. 데이터 접근성 높이기 Trino 환경에서 가장 제한적이었던 부분은 일 배치였습니다. 서비스 DB를 긁는 부하를 줄이기 위해 사용량이 가장 낮은 시간에 한정해 ETL 파이프라인을 하루에 한 번 가동했기 때문이죠. 빅쿼리로 이전하면서 세웠던 계획 중 하나가 바로 가능하면 스트리밍, 최소 1시간 단위까지 배치 빈도를 늘리자- 였습니다. 그래서 아래와 같은 기능들을 사용하게 되었습니다. DataStream Google Cloud SQL, AWS RDS 등의 DB를 스트리밍할 수 있는 매니지드 서비스입니다. DB의 update ..

결론부터 말씀드리면, 사용자 작업이 없는 주말 기준으로 데이터 파이프라인 운영 비용을 30만원대 -> 3만원대로 줄였습니다. Phase 0. Trino 저희는 기존에 AWS EKS를 활용해 스케일링이 가능한 Trino 환경을 사용하고 있었습니다. 클라이언트 로그 데이터부터 MongoDB, RDS등의 데이터를 DW로 ETL하고, 전사 구성원들이 쿼리를 조회하는 용도로 활용되었죠. 장점이 있다면 대용량의 데이터를 일별 스냅샷으로 적재해도 상대적으로 부담이 적다는 것과 누가 언제 어디서 어떻게 쿼리를 조회해도 비용 자체는 안정적으로 관리할 수 있다는 것이었죠. 그러나, 점차 데이터 사이즈와 쿼리량의 증가로 인해 서버 비용 외에 저장 비용도 누적되고 급격히 사용자가 몰리는 시점에는 처리 속도도 만족스럽지 못했습..

아래 이미지는 현 회사에서 관리하고 있는 ETL 파이프라인 중 마케팅 Summary data에 관한 Airflow DAG 그래프입니다. 마케팅 데이터 파이프라인의 구성 1. 소스 데이터 입수 위의 DAG에는 포함되어있지 않지만, 광고 매체의 보고서 API를 호출하거나 서비스 DB에서 소스를 추출하는 스케줄도 에어플로우로 관리합니다. 2. 가공 및 적재 위의 DAG에서 가장 처음으로 실행되는 두 개의 Task인 userid_mapping >> userid_mapped_logs에 해당합니다. 이 Task는 log 데이터에서 로그인 전 생성되는 anonymous_id와 로그인 후 기록되는 user_id를 매핑해서 특정 유저가 로그인하기 전의 로그까지 해당 유저의 기록으로 연결해 주는 역할을 합니다. 다음으로 ..

1. 배경 기존 클라이언트 로그 환경 : Segment 서비스에서 Redshift로 바로 적재, 1시간 간격 문제점 1시간 이내 로그 조회 불가 파티셔닝이 되어 있지 않아 조회 속도 느림 이벤트 소스, 유형 별로 각각 테이블이 생성되어 유저의 행동 흐름을 파악하기 어려움 2. 작업 내역 Segment에서 Kinesis로 로그 전송하도록 설정 Kinesis에서 S3로 로그 적재하는 Firehose 데이터 전송 스트림 생성 S3 전송 시 디폴트로 연/월/일/시 4depth의 파티션이 구성됨 Lambda에서 S3에 로그가 적재될 때마다 특정 디렉토리 하나로 이동시키는 함수 생성 Kinesis에서 보내 주는 24시간 분량의 데이터만 파티션 없이 모아 두기 Glue Crawler로 테이블을 생성한 후 스키마를 일..