DataRami DataRami

스타트업의 데이터 팀에는 수많은 리퀘스트가 들어옵니다. 그 중에서 단순 추출과 개인정보 처리는 그 중요도와는 별개로, 요청은 많고 얻어가는 보람은 적은 일에 속하죠. 조직에 직접 인사이트를 제공하는 생산적인 분석을 하고 싶어 데이터 분석가가 되었는데, 이런 애드혹이 반복되면 결국 내가 데이터 분석가인가? 추출가인가? 자괴감이 들게 됩니다. 이런 문제를 해결하기 위해 On-call(당번), 리퀘스트 워크플로우, 백로그 프로세스 개선 등 다양한 시도를 했지만 문제는 제품과 비즈니스 실무진의 데이터 접근성이 떨어지는 것이었습니다. 분석용 데이터 마트가 갖추어져 있고 리대시나 태블로를 통해 원하는 구성원이라면 누구나 데이터에 접근할 수 있는데 왜 접근성이 떨어지는가? 라고 반문했을 때는 아래와 같은 이유들을 찾..

기존 환경 - EMR 6.2.0 + PrestoSql 343 - Re:dash 8.0.0 1. Terraform을 통한 EMR Trino 업그레이드 + File Access Control 설정 - EMR 6.4.0 + Trino 359 업그레이드를 위한 Terraform Configuration 파일 수정사항 - Classification의 'prestosql'을 'trino'로 변경 - 일부 설정값 호환 여부 확인 ---- 변경 전 { "Classification": "prestosql-connector-hive", "Properties": { "hive.metastore": "glue", "hive.metastore.glue.datacatalog.enabled": "true", "hive.s3-fil..

배경 - Airflow를 Staging과 Production 환경으로 나누어 운영 중 - Github Actions를 이용하여 PR 생성 시 Staging에 배포 -> master merge 시 Production에 배포 프로세스 문제점 - 기본 airflow dag 템플릿에 맞추어 작업할 때, 하나의 dag.py 파일 아래 복수의 태스크를 작성함 - 여러 사람이 동시에 서로 다른 Task 추가를 위해 같은 DAG를 편집하면 Staging 환경에서 Conflict 발생 대안 - DAG 파일 하나를 동시에 수정하는 일이 없도록 개별 태스크를 각각의 파일로 처리한다. - DAG 파일에서 각 Task 생성은 함수로 처리한다. 코드 참조 from datetime import timedelta from utils..

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. 8월 13일부터 github 패스워드 인증 지원이 만료되었습니다. 이후 Personal Access Token을 사용해서 인증해야 하는데요, Pycharm을 활용하는 방법과 Terminal에 적용하기 위한 방법이 각각 달랐습니다. 1. Pycharm 계정 추가 Github 계정 추가 메뉴에서 Log In with Token을 선택하고 우측에서 Generate를 클릭하면 최소한의 필요한 권한이 선택된 토큰 발급 화면으로 넘어갑니다. 페이지 하단의 Generate Token 버튼을 누르고 나타나는..

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

사회생활 시작이 디지털 마케팅 쪽이었던 관계로 엑셀 파일과 스프레드시트로 '데이터' 형태를 다룰 일은 많았습니다. 그리고 숫자 사이에서 헤매는 일이 나름 재미도 있었습니다. 다만 '데이터' 라고 하기에는 매우 작고 귀여운 내용들이었고 방법도 단순해서 당시에는 제가 데이터를 다루는 거라고 생각하지는 않았습니다. 이후에 퍼포먼스 마케팅을 담당했던 전 회사 E에서 실제 DB 데이터를 접할 기회가 생겼고 그것을 잘 다루기 위한 SQL, Python 등을 배울 수 있는 좋은 기회도 잡았습니다. 처음에는 Null을 어떻게 읽는 지도 몰랐는데 몇 번 밤 새워가며 쿼리도 짜 보고 바쁜 CTO님을 붙잡고 질문해가며 코드도 짜 보고 실제로 업무에 적용해서 성과도 내 보면서 더 뿌듯한 시간을 보냈습니다. 그 후 데이터 분석..

1. 도입 배경 마케팅, 비즈니스, 물류, 콘텐츠 등.. 수많은 유저들이 구글 스프레드시트에 데이터를 기록합니다. DB 데이터와 연결하여 분석하기 위해서 기존에는 Re:dash의 스프레드시트 커넥터를 사용했습니다. Tableau 등 시각화에 대한 니즈가 커지면서 Re:dash에서 데이터를 보는 것만으로는 부족하게 되었습니다. 2. 작업 내역 GCP에서 프로젝트를 만들고, 서비스 계정을 생성합니다. api 접속을 위한 키를 발급 받고, auth 코드를 작성합니다. def gs_auth() : # 구글 API 인증 scope = ['https://spreadsheets.google.com/feeds', 'https://www.googleapis.com/auth/drive'] credentials = Serv..

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