데이터 파이프라인에서 중복 데이터 핸들링 방법

빅데이터를 지탱하는 기술, 니시다 케이스케

---

데이터 중복과 멱등한 조작

빅데이터를 다루는 시스템에서는 어느정도 중복을 허용하는 경향이 존재한다. 데이터 센터와 같은 안정된 회선의 경우 99% 이상의 신뢰성을 확보할 가능성이 높다. 따라서 이 정도의 오차는 허용하고, 멱등한 조작에 유의해서 중복 데이터가 생기더라도 문제가 되지 않는 시스템을 설계한다. (다만 과금 처리 같이 오차가 허용되어서는 안되는 경우는 트랜잭션 처리를 지원하는 데이터베이스를 사용하고, 이후에 벌크로 데이터를 전송해서 중복과 결손을 확실하게 피한다.) 

---

Exactly-once 의 단점

데이터 전송을 주고 받는 두 노드가 분산 코디네이터에 의존한다. 그러나 코디네이터에 장애가 발생하는 경우도 있으며, 이에 의존하기 때문에 성능과 트레이드하게 된다.

Exactly-Once가 좋긴 하지만, 그만큼 리소스 소모가 크며 장애와 관련된 변수도 많이 존재한다. 따라서 메시지 브로커에서는 성능상의 이유로 at least once를 기본으로 채책하고 중복 제거는 사용자에게 맞긴다.

---

중복 제거에 필요한 높은 비용의 오퍼레이션

모든 메시지에 일련 번호를 포함시킬 수 있지만, 이를 위한 리소스가 필요하여 성능 향상이 어려워지는 문제가 발생한다. 메시지 전송에서 성능과 신뢰성은 트레이드 오프 관계에 있다. 

1). offset을 이용한 중복 제거

벌크형 데이터 전송처럼 데이터 사이즈가 고정된 경우에 잘 작동하지만, 스트리밍에서는 잘 사용하지 않는다.

 

2). 고유 ID를 이용한 중복 제거

모든 메시지에 UUID(Universal Unique IDentifier) 와 같은 고유 ID를 부여한다. 단 해당 케이스는 메시지가 늘어남에 따라  ID가 폭발적으로 증가하므로 이를 어떻게 관리하느냐가 관건이다. 현실적으로는 최근 1시간 정도의 ID만을 기억하고 그보다 늦게 온 메시지의 중복은 허용하는 방법이 있다. (redis를 key-value 스토어로 사용하고 보존 기간을 1시간으로 설정하면 비교적 쉽게 구현이 가능할 것 같다.)

 

3.) End to End 간 신뢰성

빅데이터의 경우 종종 신뢰성보다 효율성이 중시된다. 따라서 중간 컴포넌트에 at least once를 구현하되 중복 제거는 하지 않는 것이 표준적인 구현이다. 

중복 제거는 종단 간에 실행하지 않으면 의미가 없으므로 모든 구간에서 at least once로 통일한다. 클라이언트 상에서 모든 메시지에 uuid를 포함시키고 경로의 말단에서 중복 제거를 실행한다. 

---

고유 ID를 사용한 중복 제거 방법

1). 분산 스토리지로 NoSQL DB 사용하기

Cassandra, Elasticsearch 등은 데이터를 쓸 때(Write) 고유 ID를 지정하는데, 동일한 ID는 덮어쓴다. 따라서 결과적으로는 중복 제거가 실현된다.

2). SQL로 중복 제거

받은 데이터는 그대로 객체 스토리지에 모두 저장하고, 읽어들이는 단계에서 중복을 제거한다. 보통 Hive와 같은 배치형 쿼리 엔진에서 실행한다. 

---