사용한 기술: airflow, spark sql
타 팀으로부터 데이터를 가져와서 주문접수율, 별점, 재주문율 등을 구하는 작업을 했다.
문제는 각 지표를 계산하는 작업을 쿼리로 할 것인가, 아니면 배치로 할 것인가였다.
배치의 장점
- 복잡한 비즈니스 로직을 가독성 있게 처리할 수 있다.
예로 들어 특정 별점 이하의 주문은 재주문율 산정에서 제외하는 복잡한 로직은 배치에서 코드로 가독성 있게 표현할 수 있다. - 테스트를 작성할 수 있다.
비즈니스 로직에 대하여 테스트를 작성할 수 있다.
배치의 단점
- 실행 시간이 오래 걸린다.
쿼리와 비교하여, 느리다.
회사에서 타팀으로부터 데이터를 가져올 때 cpu 수를 조정하여 쿼리를 실행할 수 있었다. 따라서 쿼리로 한다면 원하는 만큼 빠르게 실행하는게 가능하다. - 개발 및 유지보수 시간이 오래 걸린다.
배치 개발은 쿼리 개발보다 오래 걸린다.
엔티티 설정 등이 필요하기에, 쿼리보다 설정해야 하는 코드가 많다.
간단한 요구사항 변경이라면, 배치 수정보다 쿼리 수정이 더 빠르다.
쿼리에 대한 불안감
배치보다 쿼리가 장점이 더 많다고 결론을 내렸다.
하지만 불안감이 있었다.
쿼리로 풀어낼 수 없는 비즈니스 로직이 들어오면 어떻게 하지?라는 불안감이었다.
또한 쿼리는 spark sql을 사용하고, airflow라는 스케줄러를 사용해야 했다.
spark sql, airflow 모두 다뤄보지 않은 새로운 기술이라는 부담감이 있었다.
불안감, 부담감을 해소하기 위해 다음 작업을 진행했다.
상상해보자. 나에게 일주일의 시간이 있다면?
나에게 일주일의 빈 시간이 있다고 해보자.
새로운 기술의 불안감을 해소하기 위해 나는 일주일 간 어떠한 실험을 해볼 것인가?
위와 같은 가정을 했다.
불안감을 해소하기 위하여, 팀원 분과 함께 현재 요구사항 중 가장 복잡한 요구사항을 쿼리로 계산하는 작업을 진행했다.
셀러간에 등급을 매기는 랭킹로직을 쿼리로 계산했는데, 생각보다 간단했다.
불안감이 일정 부분 해소됐다.
쿼리로 구현
배치를 사용하지 않고, 쿼리로 각 지표들(주문접수율, 별점, 재주문율)을 계산했다.
쿼리로 각 지표를 계산 -> 지표를 데이터팀 공간에 저장(spark 형태로 저장) -> 쿼리로 각 지표 통합 -> 통합한 지표를 팀 내 RDS에 저장
위 구조로 작업을 진행하고, 작업 완료 후 오픈했다.
더 잘하려면
- 통합 지표는 데이터팀 공간에 저장해도 좋았을 것 같다.
각 개별 지표만 데이터팀 공간에 저장하고, 통합 지표는 데이터팀에 저장하지 않았다. 통합 지표는 팀 내 RDS에 저장되기 때문에 이중으로 저장할 필요가 없다고 생각했기 때문이다.
하지만 통합 지표도 타팀에서 조회할 수 있다. 통합 지표도 타팀에서 조회가 가능하도록 데이터팀 공간에 저장하도록 해도 좋았을 것 같다.
