제목, 태그, 카테고리로 검색

모든 태그

# DuckDB

5개의 글

7일이면 버려지는 스냅샷을 장기 이력으로 살려낸 dbtower-lakehouse 실측 총정리

DBTower가 7일 뒤 버리는 쿼리 스냅샷을 컬럼형 저장소로 내려 장기 이력을 만드는 ELT 파이프라인의 전체 기록을 한 편에 정리합니다. 오케스트레이션은 Airflow, 적재는 MinIO의 Parquet입니다. 변환은 dbt가 맡고 질의는 DuckLake로 합니다. 문제 정의(7일 시야로는 '지난달 대비 느려진 쿼리'에 못 답함)에서 시작해, 원천·적재·조회 3자 일치로 검증한 멱등 추출(닫힌 창 07-05=149,259·07-06=79,894), 누적 카운터를 일간 델타로 접는 변환, 조용한 오답을 막는 4축 fail-closed 게이트, lake를 house로 올리는 DuckLake 타임트래블, 아카이브가 자신을 지우던 치명 결함의 차단, 1년치를 합성해 407.62초 재빌드를 4초로 줄인 규모 실측, Kafka를 넣지 않은 근거를 담았습니다. 여기에 남이 그대로 띄우는 셀프호스트 어플라이언스, 두 저장소가 손잡는 되쓰기, 그리고 이 창고만 할 수 있는 여섯 가지 판정(용량 D-day·플랜 회귀·백업 공백·미사용 인덱스·설정 변경 상관·가용성 SLO)까지, 파이프라인이 답을 만드는 공정에서 판정을 내리는 창고로 자란 과정을 이었습니다. 라이브에서 MSSQL 두 인스턴스가 63퍼센트대 가용성에 평균 ping 2에서 7초로 목표 미달, 나머지는 99.9퍼센트로 목표를 지킵니다. 모든 수치는 직접 측정했고 재현 기록이 저장소에 있습니다.

창고가 데이터를 내리는 데서 판정을 내리는 데까지, 여섯 가지 판정을 채우다

창고에 데이터를 내리기만 하고 판정을 안 하고 있었습니다. plan_snapshot과 fct_query_daily를 둘 다 갖고도 상관시키지 않아 신고마다 30분씩 플랜 이력을 뒤졌고, 백업 공백은 판정 컬럼이 없어 복구하다 발견했습니다. 셋 다 신규 수집 없이 이미 내린 데이터를 판정 컬럼까지 잇는 일이었습니다. 플랜 회귀는 일 단위 대표 플랜의 뒤집힘을 전후 N일 지연과 겹치되 관측이 덜 차면 PENDING, 창이 오염되면 AMBIGUOUS로 지어내지 않고, 백업 공백은 유니버스를 query 팩트에서 잡아 기록 없는 인스턴스도 행으로 드러내며 기준일을 벽시계가 아닌 창고 최신 dt로 잡습니다. 이 셋을 주간 보고 한 장으로 접었습니다. 그리고 판정에 "왜"가 빠졌음을 깨달아 설정 드리프트를 원인 후보로 붙이고, 상관을 플랜 뒤집힘 한 축에서 지연·볼륨까지 넓히고, change_review는 저빈도라 자리만 열어 두었습니다. 여러 마트가 달던 "기종 축이 없다"는 각주는 이미 읽던 database_instance의 name·type로 회수해 instance_id 1이 local-mysql (MYSQL)로 읽히게 했고, 마지막으로 DBTower가 35일 뒤 지우는 up 여부를 장기 가용성 SLO로 만들었습니다. 라이브에서 MSSQL 두 인스턴스가 63퍼센트대 가용성에 평균 ping 2에서 7초로 목표 미달, 나머지는 99.9퍼센트로 목표를 지킵니다. 이걸로 관리 대상 DB에 관해 창고가 답할 판정 여섯이 한 바퀴 찼습니다. 발화는 여전히 남에게 맡기고 판정 컬럼까지만 정직하게 계산합니다.

며칠치로는 규모를 증명 못 해서 1년치를 만들었고, 축을 돌려 다시 쟀습니다

지금까지 모든 실측은 닫힌 dt 세 개, 수십만 행에서 돌았습니다. 그 규모에선 전부 초 단위라 "규모에서도 버틴다"고 말하고 싶어지는데, 며칠치로는 증명이 안 됩니다. 마트(fct)는 매일 전체 이력을 다시 계산하는데 이력이 3일이라 안 아팠을 뿐입니다. 그래서 닫힌 dt를 날짜 시프트로 복제해 365dt×6인스턴스=2,190파일(54.5M행)을 격리 프리픽스에 만들어 어디가 먼저 무너지는지 쟀습니다. 병목은 fct 전체 재빌드 407.62초 하나였고, 나머지는 규모에서도 초 단위였습니다. 그 수치가 정당화하니 dt 단위 독립성을 살려 delete+insert로 증분화했고, 컴파일 타임 워터마크 리터럴로 파티션 프루닝을 걸어 407.62초를 4초로 줄였습니다. 그런데 규모의 축은 시간 하나가 아닙니다. 셀프호스터가 몇백 대를 관제하는 사람이라면 늘어나는 축은 dt가 아니라 인스턴스 수입니다. 로드맵에 "소파일이 먼저 무너지고 그다음 추출, 컴퓨트는 마지막"이라고 외삽해 뒀었는데 재보지 않은 문장이었습니다. 총량을 고정하고 축만 돌려 300대(52.2M행)로 다시 재보니, 증분 fct는 8.03초로 건재했고 급소는 소파일이 아니라 full-refresh였습니다. 제 외삽 두 개가 틀렸고, 그걸 수치가 바로잡았습니다. 최적화는 병목 수치가 정당화한 곳만 건드렸습니다.

코드보다 데이터 계약을 먼저 쓰고, 조용한 오답을 게이트로 막으며 파이프라인을 지었습니다

DBTower가 7일 뒤 버리는 쿼리 스냅샷을 컬럼형 저장소로 내려 장기 이력을 만드는 파이프라인을, 짓는 순서대로 담았습니다. DAG를 짜기 전에 무엇을 어떤 계약으로 옮길지부터 못박고, 원천 인덱스 선두를 타는 인스턴스별 등치 질의와 파티션 통째 덮어쓰기로 어제치를 안전하고 멱등하게 내립니다(닫힌 창 재실행에 79,894행 불변). 누적 카운터 raw로는 "느려진 쿼리"에 답할 수 없어, 지문 충돌 12,743키를 SUM으로 접고 하루 양 끝 차분에 리셋 클램프를 걸어 일간 델타로 바꿉니다. 반쪽 파티션 위 랭킹이 조용히 오답을 내는 걸 막으려 reconciliation·completeness·freshness·드리프트 4축 게이트를 다운스트림 앞에 세워 fail-closed로 dbt를 아예 실행하지 않게 했습니다(장애 주입 시 exit 2). 덮어쓰기만으로는 ACID도 타임트래블도 없어 lake일 뿐이라, 카탈로그를 이미 쓰던 PostgreSQL에 두고 데이터는 S3 parquet에 두는 DuckLake를 얹어 과거 버전 복원과 롤백을 실증했습니다. 막았다는 사실을 아무도 모르면 마트가 조용히 낡으니 컨테이너 안 dbt e2e·webhook·retry·CHECKPOINT로 운영을 경화했고, 마지막으로 Metabase가 DuckLake를 read-only로 읽게 해 처음 던진 "지난달 대비 느려진 쿼리"에 화면이 답하게 했습니다. 모든 수치는 직접 측정했습니다.

아카이브가 자기 자신을 지우던 치명 경로를 막고, CI와 deadman과 dbt contracts로 신뢰를 마저 묶은 이야기

코드 감사에서 받은 결함 목록의 1번이 치명이었습니다. offload의 멱등 재적재는 '파티션을 통째로 지우고 다시 쓴다'인데 삭제가 원천 0행 체크보다 먼저라, 원천 보존(7일) 밖의 dt를 backfill이나 Clear로 재실행하면 아카이브 유일본 parquet를 지운 뒤 아무것도 안 쓰고 exit 0으로 '성공'합니다. 1부에서 이 경로를 실제로 재현하고 fail-closed 가드(ArchiveSelfDestructError, exit 1 → 재시도·webhook 경로 탑승)로 막았습니다. 같은 감사에서 나온 나머지 셋, 곧 게이트의 원천 Seq Scan(332ms/31k버퍼 → 인스턴스별 인덱스 루프 20ms/76버퍼), publish 혼합 버전(개별 커밋 → 단일 트랜잭션), 유지보수 DAG의 데모 테이블 하드 참조도 걷어내고 pytest 35개로 고정했습니다. 2부는 그 신뢰를 커밋·침묵·계약 세 축으로 마저 묶습니다. CI(GitHub Actions 3관문: ruff·pytest·dbt)가 임베디드 DuckDB 덕에 MinIO도 PG도 없는 러너에서 tiny 픽스처 parquet로 dbt build를 e2e로 돌리고(PASS=25), dbt unit test로 델타 로직 엣지 4개를 정적 입력→기대 출력으로 못박고, deadman heartbeat가 30h 침묵을 실제 경보 발화로 잡고(기한 26h), dbt contracts가 마트 컬럼 타입을 DB 레벨로 강제해 latency_increase_ms를 VARCHAR로 바꾸자 빌드가 'data type mismatch'로 막혔습니다. 회귀는 없었습니다. verify는 ALL MATCH(149,259/79,894행), pytest는 53개 통과입니다.