나의 고민일기2

지영·2023년 11월 22일
0

백엔드개발자

목록 보기
7/11
post-thumbnail

??? : 배치 돌려서 데이터 생성해주세요~~ 양이 꽤 되니, chunked 배치로 하시는 게 좋을 것 같아요

업무 도중 이전에 배치 관련해서 포스팅한 부분에서 현업의 요청이 들어왓다.

레거시 시스템 이전 시스템에서의 데이터 산출을 해야 하는..(원천 테이블은 기존 테이블에서 join등을 통해 구할 수 있지만 원하는 데이터 산출까지는 못하는 상황)그런
상황에서 해당 데이터의 산출(Process부분)이라는 업무를 맡고 있던 내가 일을 받게 되었다.

일단, 일을 처리하기 전에 우선순위 겸 나의 문제점을 생각해보았다.

👀 고려해야 할 점

  1. 데이터가 옛날 데이터와 현재 db에 적재된 데이터간의 중복(무결성 침해)이 일어나지 않아야 함
  2. 원천테이블간의 join을 하려면, 어떤 원천테이블, 어떻게 join을 해야 하는가
  3. 나..배치 한번도 안돌려봤는데 괜찮을까...

에 대한 고민을 하게 되었다.

아, 그전에 먼저 현재 로컬기에서 사용중인 스킬셋들을 보자면 아래와 같다.

🎁 로컬 개발기 스킬셋

  • 개발언어 : java(1.8)
  • 빌드도구 : maven
  • 의존성관리 : Nexus
  • 개발 IDE : Eclipse
  • was : Embbed Tomcat
  • 형상관리 : SVN
  • 주요 LIB : Spring, Springboot
  • DBMS : Oracle
  • Mapper : Mybatis
  • 디자인패턴 : Singleton
  • 로그 : Logback(debug만 허용)
  • 트랜잭션 단위 : @ServiceId
  • Test : JUnit4

✨ 해결방안

1&2) 먼저 1번의 중복을 일어나지 않게 하려면 먼저 2번의 join쿼리를 오라클에서 짜고 생각해야 했다.

join테이블은 비지니스 지식이 있어야(원천테이블이 뭔지, 결과테이블은 어떻게 나와야 하는지가 얽혀있기 때문에)..하기 때문에 어차피 여기에 쿼리를 복붙해도 의미가 없을 것 같다.

다만 하나의 상품별 수수료를 산출할 때는 (월별신계약 상품) + (수수료 계산항목) + (수수료 항목별 기준사항)에 대한 테이블이 필요했다. 이들을 서브쿼리를 통해 join을 해주어 해결하였다.

이제 1번을 해결해야 하는데, 먼저 위에서 해결한 join테이블에서의 pk값을 확인하였다. 이미 활발히 사용중인 테이블과의 pk값을 비교하여 중복이 나지 않도록
기타 id값을 pk로 설정해주었다.

3) 이 부분은 신입들이 흔히 하는 걱정 때문에 생긴 것이 아닐까?한다. 내가 이론으로만 공부했던 부분을 실전에서 배치를 돌리고..확인하려니 겁이 많이 났다. 데이터가 중복나면 rollback하기 전까지 영향도는 어떻게 되지?(로컬에서는 괜찮지만 테스트DB로 COMMIT친 경우) 등등..일어나지 않은 일들을 고려했다.
실제로 처음에 배치를 돌릴 때는 실패를 했다. 원인은 데이터 중복. 위에서 중복나지 않게 조심을 했음에도 쉽지 않았다. 이 중복의 원인도 비지니스 지식이 부족해서 조건을 촘촘히 따지지 못해 생긴 오류였다.

오류 로그에서 특정 상품의 id에서 insert에러가 남을 확인한 후, 쿼리로 다시 확인을 해보았다.

_groupby와 count('중복될 것 같은 상품')>1인 것이 하나 이상 나오는지를 체크했다._

역시나 결과가 0이 나오지 않고 중복인 데이터가 여러개가 나와버렸다.

Junit으로 배치돌리고, 오류나면 로그를 중심으로 다시 오라클에서 해결하는 과정을 많이 반복했다.

결론적으로 잘 해결.....!

힘들긴 했지만, 뭔가 정말 <이론 → 실습>으로 가본 듯한..그런 뿌듯함와 정복감이 느껴졌던 시간이었다.
역시 사람은 제일 두려운 것을 계속 두드려봐야 실력이 늘어나나 보다.

앞으로 더 까다로운 요구사항이 들어와도 당황하느라 시간보내지는 않을 것 같다. 내가 모르는 것을 정리하고 하나하나 해결해보면 뭐든 된다.

profile
꾸준함의 힘을 아는 개발자📍

0개의 댓글