iOS 앱의 행동 로그를 Treasure Data에 등록하려고하면 데이터가 중복되어 버린 이야기

TD에 iOS용 SDK( td-ios-sdk )로, 기동시의 로그를 등록하려고 하면, 서버측에 등록한 데이터가 중복되어 있었다고 하는 화제입니다. (아마 사양입니다.)

하고 싶은 일 개요

어플리의 기동시 여러가지 장소에서 addEvent()를 해, 서버에 upload했는지 어떤지는 관리하고 싶지 않기 때문에, addEvent()한 직후에 uploadEvents()를 매번 실행한다고 하는 것을 해 보았습니다.

코드 이미지

TreasureData.sharedInstance().addEvent(["msg":"first"], database: "test_app", table: "test_table")
TreasureData.sharedInstance().uploadEvents()

TreasureData.sharedInstance().addEvent(["msg":"second"], database: "test_app", table: "test_table")
TreasureData.sharedInstance().uploadEvents()

결과

first와 second의 레코드가 각각 2건 만들어졌습니다.

중복 조사

그 1

TD 사이트에 마지막으로 등록된 10분간에 UUID가 중복되어 있으면 삭제한다고 쓰여집니다.

그 2

서버측에서 이벤트의 중복 제거를 하고 있기 때문에 업로드가 여러 번 이루어져도 데이터의 중복을 방지(현재, 1일간의 중복 제거를 실시)

td-ios-sdk의 커미터쪽의 기사로 서버측에서 중복에 대한 고려되고 있다고 했습니다.

SDK에서 레코드를 추가하면 레코드마다 값이 다른 uuid 열이 내재적으로 추가되어 enableAutoAppendRecordUUID()와의 차이가 잘 보이지 않았지만 uuid 열을 사용하여 중복 제거하는 메커니즘 같아요. 다만, 실험한 환경이라고 움직이지 않는 것 같았습니다.

회피를 마음껏

시도한 것

uploadEvents 메서드에는 콜백을 수락하는 변형이 있습니다. 이것을 사용하여 uploadEvents를 직렬화하면 중복을 피할 수 있습니다.

TreasureData.sharedInstance().uploadEventsWithCallback(
    {
        //成功した場合
    },
    onError: {errCode,errMsg in
        //失敗した場合
    }
)

//dispatch_sync()とかdispatch_semaphore_waitとかで直列に処理する

결과

Request data is empty 와 로그가 나오고, 직렬화의 도중에 막혔습니다. 내부의 KeenClient 클래스로, 업로드하는 데이터가 없는 경우는, 성공의 블록도, 실패의 블록도 불리지 않는 사양인 것 같습니다.

이번 정리

찾아보면 쓰고 있을지도 모르겠지만 공식 문서와 github 프로젝트를 하루 정도 바라보고 있었습니다만, 특히 더 이상의 정보는 발견되지 않았습니다. 서버에 등록된 레코드에는, time 컬럼이 자동적으로 부여되어 처리 시간이 기록됩니다만, 밀리 세컨드 이하의 시간은 반올림되고 있습니다. 디폴트라고 초단위로 레코드를 기록하는 구조이므로, 1초간에 몇번이나 이벤트를 기록하는 등의 용도는 원래 적합하지 않을지도 모릅니다.