빅데이터 도구를 고르기 전에 결과, 마감, 정확성 규칙부터 정합니다. 데이터가 크다고 반드시 분산 처리 프레임워크가 필요한 것은 아닙니다.
매일 아침 판매자별 어제 매출이 필요하다고 합시다. 결제 승인 전에 의심 거래를 탐지하는 것과는 다릅니다. 둘 다 많은 레코드를 다룰 수 있지만 하나는 예약 처리가 가능하고 다른 하나는 빠른 판단이 필요합니다.
기존 데이터 양, 유입 속도, 필요한 필드, 보존 기간을 확인합니다. 매출 보고서라면 환불을 원래 날짜에 반영할지 환불 날짜에 반영할지 합의합니다. 이 규칙이 없으면 빠른 파이프라인도 틀린 합계를 만듭니다.
원본과 늦거나 수정된 레코드 처리도 정합니다. 그래야 과거 결과를 확정할 수 있는지 나중에 고쳐야 하는지 알 수 있습니다.
파일 읽기, DB 쿼리, 계산, 네트워크, 결과 쓰기 중 시간과 자원을 어디에 쓰는지 측정합니다. 불필요한 레코드를 일찍 걸러내고 필요한 열만 읽습니다.
전부 메모리에 올리지 말고 제한된 청크로 처리합니다. 워커 하나가 허용 비용으로 마감 안에 끝내면 가장 운영하기 쉬운 구조일 수 있습니다. 머신 추가에는 조정과 전송 비용이 있어 확인된 한계를 해결할 때 사용합니다.
| 필요 | 시작 방식 | 이유와 책임 |
|---|---|---|
| 매일 아침 완성된 보고서 | 예약 배치 | 유한한 입력은 대조와 재실행이 쉽지만 마감 전에 끝나야 함 |
| 하루 중 계속 갱신하는 대시보드 | 증분 배치 또는 스트리밍 | 새 데이터를 자주 처리하고 수정이 이전 합계에 반영되는 규칙을 정함 |
| 이벤트 직후 판단 | 스트리밍 | 지연을 줄이면서 중복, 늦은 이벤트, 복구를 처리함 |
스트리밍은 도착하는 데이터를 계속 처리한다는 뜻이지, 모든 이벤트가 한 번씩 순서대로 온다는 가정이 아닙니다. 일일 보고서는 더 최신 결과가 정말 필요하지 않다면 배치로 시작하겠습니다.
워커가 매출 합계를 저장한 뒤 진행 기록 전에 죽었다고 합시다. 재시작 후 같은 레코드를 다시 처리할 수 있습니다. 금액을 다시 더하면 매출이 부풀려집니다.
안정적인 레코드 식별자와 반복해도 안전한 쓰기를 사용하거나, 지원된다면 출력과 진행 기록을 트랜잭션으로 묶습니다. 체크포인트는 완료 진행을 기록합니다. 출력 저장 전에 기록하면 장애 후 작업을 건너뛸 수 있고, 뒤에 기록하면 그 공백을 안전하게 재생해야 합니다.
복구 동작은 설계의 일부이지 첫 장애 후 정리 작업이 아닙니다.
워커 하나로 부족하면 입력을 독립 실행 가능한 조각으로 나눕니다. 실제 분포를 확인합니다. 큰 판매자 하나 때문에 다른 워커는 끝났는데 하나만 바쁠 수 있습니다.
그룹화와 조인은 워커 간 레코드 이동인 셔플을 요구할 수 있습니다. 가능하면 이동 전에 데이터를 줄이고 목적지가 합쳐진 출력을 받을 수 있는지 확인합니다. Spark의 관련 기법은 쿼리와 버전에 따라 적합성이 달라집니다. 성능 조정 가이드를 참고합니다.
저장 방식도 접근 패턴을 따릅니다. Parquet 같은 열 지향 파일은 선택 열의 분석 스캔에, 인덱스 데이터베이스는 개별 운영 조회에 적합할 수 있습니다. 파일 크기만으로 고르지 말고 측정한 접근 요구로 결정합니다.
신뢰할 작은 데이터셋과 결과를 비교하고 건수와 업무 합계를 모두 확인합니다. 중복 이벤트, 환불, 늦은 레코드, 출력과 진행 저장 사이의 장애를 포함합니다.
그다음 실제 규모와 편향을 시험하며 실행 시간, 최고 메모리, 적체, 비용을 측정합니다. 매출 보고서의 성공은 정확하고 재현 가능한 합계가 정해진 시간에 도착하는 것입니다. 그 조건을 만족하고 누락이나 이중 집계 없이 복구할 가장 단순한 파이프라인을 선택합니다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기