AI 주식 트레이딩 개발(퀀트 트레이딩) 데이터 관리 수정 사항 기록(DuckDB)

피처 데이터, 라벨링 데이터 가공해서 데이터 저장하는 방법을 바꿨다.

DB에서 저장 -> 파일로 관리

 

 

 

• DB (raw_candles) ➔ [피처 데이터 생성 스크립트] ➔ Parquet (features)
• Parquet (features) ➔ [라벨링 데이터 생성 스크립트] ➔ 최종 학습 데이터 (train_data.parquet)
• 최종 학습 데이터 ➔ LightGBM 학습 ➔ Model 파일 (.txt or .bin)
• 실전 예측 시: 현재 시점 Raw 캔들 ➔ 피처 생성 ➔ 모델 예측 ➔ 예측 결과만 DB 저장

 

 

 

피처 테이블을 왜 없앴냐?

• 용량 낭비 차단: 300만 줄도 아니고 3억 줄 규모라면, 이걸 PostgreSQL 테이블로 옮기는 순간 인덱스(Index) 용량까지 포함해 수백 GB~수 TB를 차지하게 됩니다. Parquet 파일은 이미 압축률이 매우 높아서 저장 공간을 훨씬 적게 씁니다.
• 학습 속도 차이: LightGBM 학습을 위해 DB에서 3억 줄을 SELECT로 땡겨오는 것보다, Polars에서 scan_parquet으로 파일들을 한 번에 훑는 것이 수십 배 더 빠릅니다. * 스키마 변경의 유연성: "아, 이번엔 RSI 지표 하나 더 추가해 볼까?"라고 생각했을 때, DB라면 ALTER TABLE을 하며 고생해야 하지만, 파일 방식은 그냥 새로 뽑아서 폴더만 갈아 끼우면 끝입니다.

 

DB에 저장할 데이터들

 

• Raw 데이터 저장소: LS증권 등에서 받아온 오염되지 않은 원본 raw_candles 보관. (이건 절대 삭제하면 안 됩니다! 피처를 다시 뽑아야 할 때 원천 데이터니까요. 저는 1분봉 데이터를 거의 3년치 가까이 보유 중입니다.)
• 종목 마스터 관리: symbol_master처럼 종목 코드, 이름, 상장 상태 등을 관리하는 용도.
• 최종 시그널/결과 저장: AI 모델이 예측한 결과(예: "삼성전자 오늘 매수 신호 발생")나 실제 매매 내역만 DB에 저장합니다. 이 결과값들은 나중에 웹사이트(kirinsignal.com)에서 사용자에게 보여줄 때 필요하니까요. 텔레그램 발송도 개발 생각중...

 

데이터 관리

 

 

로컬 → SSH → 서버 → DuckDB 실행 → Parquet 직접 조회

---

1. 서버 접속

 

ssh -p 22 ai@ip

 

---

2. DuckDB 실행

(처음 1회만 DB 파일 생성)

 

duckdb /home/ai/duckdb/aiTrading.db

 

• 파일 없으면 자동 생성됨
• 이후부터는 재사용

---

3. Parquet 바로 조회

 

SELECT *
FROM read_parquet('/home/ai/data/.../m01_*.parquet')
LIMIT 10;