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: Advanced 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의 최초 실행 보호 로직에 걸려 실패할 것 같습니다.
배포 순서로 보장하는 건지, 아니면 최초 적재 전에는 태그 대상에서 빼는 게 좋을지 궁금합니다.
There was a problem hiding this comment.
말씀하신 상황이 발생할 수 있어, 최초 적재를 확인하기 전에는 후보 모델을 DAG 실행 대상에서 제외하도록 수정했습니다. 반영 커밋은 6ae88cb, deb8a78입니다.
silver_events_v2,silver__users에initial_load_required태그를 추가했습니다.- 새 환경변수
KOIN_DATA_SILVER_BOOTSTRAP_COMPLETE가 미설정이거나true가 아니면, daily/monthly 모두exclude=["tag:initial_load_required"]를 적용해 해당 모델과 테스트를 제외합니다. 기존silver_events의 daily 실행은 유지됩니다. - 같은 출력 환경에서 두 후보 모델을 명시 선택해 전체 이력을 적재하고 검증한 뒤, 환경변수를
true로 변경하고 Airflow 컨테이너를 재생성해 스케줄에 포함하는 절차를 README와.env.example에 추가했습니다. 이 값은 적재 완료를 자동 판정하는 것이 아니라 운영자가 검증 후 활성화하는 설정입니다.
검증은 Python 문법·설정값 18가지와, 저장된 manifest에 현재 YAML 태그를 반영한 오프라인 dbt 그래프의 daily/monthly 선택 결과를 확인했습니다. 비활성화 시 daily는 기존 모델 1개, monthly는 모델 0개이며, 활성화 시 각각 3개·2개로 복원됩니다. 태그를 다른 모델에 옮긴 경우에도 제외 대상이 따라 바뀌는 것을 확인했습니다. 실제 Airflow 통합 실행은 로컬 Docker 미실행 및 dbt 의존 라이브러리의 Windows 실행 제한으로 이번 검증에 포함하지 못했습니다.
| 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 ...