feat: Silver 사용자 월간 보정과 태그 기반 DAG 추가 - #30
Conversation
silver_events_v2와 silver__users의 모델 설명, 태그, 컬럼 정의를 _silver__models.yml로 통합하고 개별 YAML 파일을 제거한다.
일간 DAG는 airflow_daily 태그를, 월간 DAG는 airflow_monthly 태그를 선택한다. 월간 실행은 최근 30일을 보정하고 같은 날 일간 DAG 성공 후 실행해 동시 갱신을 막는다.
Airflow 전역 cron 설정과 무관하게 실행 시각과 logical date가 일치하도록 CronTriggerTimetable을 사용한다.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| raw_event_id 물리 중복 제거와 event_id 논리 중복 제거를 UNNEST 전에 수행하고, | ||
| 공통 이벤트 파라미터·KST 시간·화면명·Android 가입 세션을 표준화한다. | ||
| config: | ||
| tags: ["airflow_daily", "airflow_monthly"] |
There was a problem hiding this comment.
이 부분은 최초 전체 적재 전에 daily DAG가 먼저 돌 가능성은 없을까요?
테이블이 없는 상태에서 실행되면 silver_events_v2는 최근 3일치만 생성되고, silver__users는 prod의 최초 실행 보호 로직에 걸려 실패할 것 같습니다.
배포 순서로 보장하는 건지, 아니면 최초 적재 전에는 태그 대상에서 빼는 게 좋을지 궁금합니다.
| Prod GA4 원천과 KOIN 회원 정보를 결합하는 운영 전환 후보 사용자 | ||
| Dimension이다. 로컬 Airflow 검증에서는 Stage silver 데이터셋에만 적재한다. | ||
| config: | ||
| tags: ["airflow_daily", "airflow_monthly"] |
There was a problem hiding this comment.
로컬 dev에서 이 태그가 실행될 때 app_db source가 운영을 바라볼 수 있을 것 같습니다.
.env.example에는 APP_DB 관련 환경변수가 없고 source 기본값은 kap-chat이라, 운영 koin_users를 읽어서 Stage에 적재할 가능성이 있어 보여요.
APP_DB 환경변수도 예시에 추가하거나 dev에서는 운영 source를 막는 검사가 필요하지 않을까요?
| description: 정규화된 이벤트 속성으로 분류한 KOIN 서비스명입니다. | ||
| data_tests: | ||
| - not_null | ||
| - name: stage_scope |
There was a problem hiding this comment.
YAML을 통합하면서 silver_events_v2가 출력하는 funnel_stage, step_order, is_entry_event, is_core_action, service_step_order가 빠진 것 같은데 의도된 걸까요?
특히 is_entry_event와 is_core_action은 Gold에서 사용하는 컬럼이라 같이 선언해두는 게 좋을 것 같습니다.
|
|
||
| GA4는 확정 데이터를 며칠에 걸쳐 갱신하므로 매 실행 최근 3일을 다시 만든다. | ||
| GA4는 확정 데이터를 며칠에 걸쳐 갱신하므로 daily는 최근 3일을 다시 만든다. | ||
| 모델이 `insert_overwrite`라 파티션이 통째로 교체되어 추가뿐 아니라 삭제·변경도 반영된다. |
There was a problem hiding this comment.
여기서 "삭제도 반영된다"는 설명은 결과가 0건인 날짜에도 해당하나요?
silver_events_v2.sql 주석에는 0건인 요청일의 기존 파티션은 비워지지 않는다고 되어 있어서, 그 예외를 README에도 적어두는 게 좋을 것 같습니다.
sm1118sm
left a comment
sm1118sm
left a comment
There was a problem hiding this comment.
월간 보정 로직을 커밋 단위로 다시 보면서 한 가지 더 확인했습니다.
| existing_users.top_user_id, | ||
| existing_users.property_user_id, | ||
| existing_users.param_user_id, | ||
| coalesce( |
There was a problem hiding this comment.
monthly DAG는 conf로 과거 구간도 수동 실행할 수 있는 것으로 보이는데, 이 경우 monthly_gender나 monthly_major가 현재 저장된 값보다 오래된 관측이어도 그대로 덮어쓰게 되지 않을까요?
first_seen_at/last_seen_at은 least/greatest로 보호하고 있지만 속성은 시점을 비교하지 않아서, 과거 백필 시 최신 속성이 이전 값으로 돌아갈 수 있을 것 같습니다. 과거 구간의 monthly 실행을 막거나 속성 관측 시각도 같이 비교해야 할지 궁금합니다.
2 participants
변경 사항
silver__users에 최근 30일 월간 보정 경로를 추가했습니다.first_seen_at,last_seen_at,gender,major만 갱신합니다.user_id·집계 count·MySQL 매핑 속성은 유지합니다.silver_events_v2,silver__users의 모델 문서를_silver__models.yml로 통합했습니다.airflow_daily/airflow_monthly태그 기반 DAG를 구성했습니다.검증
dbt debug --target dev— stage 데이터베이스·실행 프로젝트·schema 및 연결 확인dbt parse --target devdbt compile --target dev --select tag:airflow_daily ...dbt compile --target dev --select tag:airflow_monthly ...