사용자 중복 제거는 사용자 관련 데이터 집합을 관리하는 모든 사람에게 중요한 활동입니다. 경우에 따라 데이터베이스에 동일한 사용자의 여러 버전이 존재할 수 있습니다. 이는 잘못된 데이터 관리, 일치하지 않는 사용자 데이터, 사용자 또는 시스템 오류 등 여러 가지 이유로 발생할 수 있습니다. 또한 여러 다른 시스템에서 사용자 정보가 집계되는 경우도 흔합니다. 기본 사용자 데이터 세트가 있지만 소셜 미디어, 티켓팅 또는 등록 시스템과 같은 타사 데이터 또는 조직 내 다른 사일로의 추가 사용자 정보로 보강하고 싶을 수도 있습니다.
이 글은 Andy Kruth가 작성한 게스트 블로그 게시물입니다. Andy Kruth는 다음과 같은 회사의 수석 컨설턴트입니다. 아발론 컨설팅, LLC 에서 빅데이터 시스템의 아키텍처 및 개발과 NoSQL 솔루션에 주력하고 있습니다. 이 게시물은 신시내티 레즈에서 수행한 작업의 영향을 받았습니다. 다음 예제는 단순해 보이지만, Reds 비즈니스의 여러 측면에 있는 사용자 데이터를 단일 계정 및 가구 데이터 집합으로 중복 제거한 훨씬 더 복잡한 애플리케이션을 기반으로 합니다.
어떤 경우든 사용자 정보를 간결하고 정확한 데이터 집합으로 중복 제거하기는 일반적인 작업입니다. 이를 수행하는 전통적인 접근 방식은 애플리케이션을 통해 모든 사용자 정보를 실행하여 정의된 휴리스틱에 따라 레코드를 매칭하고 단일 데이터 세트를 출력하는 것입니다. 이 방법은 '효과가 있지만', 캡처할 수 있는 모든 델타에 대해 정기적으로 또는 적어도 정기적으로 일괄적으로 수행해야 하는 작업인 경우가 많습니다. 그러나 이 접근 방식의 단점은 배치 또는 예약된 작업을 사용할 때마다 데이터 결과가 부실해질 가능성이 상당히 높다는 것입니다.
도입과 함께 카우치베이스 이벤트이제 효과적인 중복 제거를 위한 새로운 옵션이 실시간으로 제공됩니다! 이벤트에 대한 일반적인 정보는 이미 다른 여러 글에서 충분히 다루었기 때문에 여기서는 생략하겠습니다( 여기및 여기및 여기). 대신 이 글에서는 Couchbase Eventing을 사용하여 실시간 중복 제거 엔진을 개발하는 방법에 대한 간단한 예제에 초점을 맞추고자 합니다. 시작해 보겠습니다.
버킷 설정
이 데모에는 총 4개의 버킷이 필요합니다:
- 메타데이터 - 이벤트 함수를 실행하기 위한 모든 정보를 저장하는 필수 메타데이터 버킷입니다.
- 스테이징 - 이 버킷은 모든 사용자 데이터의 랜딩 존 역할을 합니다.
- fieldindex - 이 버킷은 사용자를 매칭하는 데 필요한 필드 정보의 인덱스 역할을 합니다.
- 사용자 - 이 버킷은 최종 결과물인 간결한 사용자 데이터 세트입니다.
기능 설정
중복 제거 함수를 만들 때(저는 "중복 제거"라고 이름 지었습니다), 메타데이터 버킷은 "메타데이터"로, 소스 버킷은 "스테이징"으로 지정합니다. 또한 두 개의 별칭을 정의해야 합니다: "users"는 사용자 버킷을 가리키고 "fieldindex"는 필드 인덱스 버킷을 가리킬 수 있습니다.
함수 코드
이 데모에서는 매우 간단한 중복 제거 시나리오를 고려해 보겠습니다: 이메일 주소를 기반으로 한 간결한 사용자 목록과 나중에 감사 목적으로 해당 이메일이 포함된 모든 원본 문서 목록이 필요합니다.
이 예에서는 매우 간단한 문서로 작업하겠습니다. 다음은 아이디어를 제공하기 위한 문서입니다:
|
1 2 3 |
"test::1" { "이메일": "abc@abc.com" } |
함수 코드 전체는 다음과 같습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
함수 온업데이트(doc, 메타) { var 이메일 = getEmailFromDoc(doc) 만약 (이메일 != null) { var 사용자 = getUserFromEmail(이메일) var 사용자 문서 = {} 만약 (사용자 != null) { 사용자 문서 = 사용자[사용자] 사용자 문서.일치 = 사용자 문서.일치.concat([메타.id]) } else { 사용자 문서 = doc 사용자 문서.userid = 메타.id 사용자 문서.생성 = 날짜.지금() 사용자 문서.일치 = [메타.id] } 사용자[사용자 문서.userid] = 사용자 문서 필드 인덱스에 이메일 추가(이메일, 사용자 문서.userid) } else { // 문서에 이메일이 없으며 중복 제거에 유효하지 않습니다. } } 함수 getEmailFromDoc(doc) { 에 대한 (var 키 in doc) { var 필드 = 키.toLowerCase() 만약 (필드.포함("이메일")) { 반환 doc[키] } } 반환 null } 함수 getUserFromEmail(이메일) { 시도 { 반환 필드 인덱스["이메일::" + 이메일].userid } catch (e) { // 사용자를 찾을 수 없으니 그냥 null을 반환하겠습니다. } 반환 null } 함수 필드 인덱스에 이메일 추가(이메일, 사용자) { 필드 인덱스["이메일::" + 이메일] = {"userid": 사용자} } |
문서 구문 분석하기
OnUpdate(doc, meta) 함수에서 시작합니다. 이 함수는 스테이징 버킷에 있는 문서가 변경될 때마다, 즉 원시 문서가 추가되거나 업데이트될 때마다 호출됩니다. 첫 번째 단계는 수신 문서의 이메일 주소를 확인하는 것입니다. 이를 위해 작은 도우미 함수인 getEmailFromDoc(doc)이 있습니다. 이 함수는 단순히 문서의 모든 필드 이름을 반복하여 '이메일'이라는 문자열이 포함된 필드 이름을 찾은 다음 해당 값을 반환합니다. 이 함수에서는 특정 필드 이름을 찾도록 선택할 수도 있습니다. 여기에 여러 데이터 소스가 있는 경우 각 소스에서 서로 다른 필드 이름을 사용할 수 있으므로 위의 일반화된 접근 방식이 적합할 수 있다는 점을 염두에 두어야 합니다.
일치하는 항목 찾기
이메일 주소가 준비되었으면 이제 다음 단계로 넘어갈 차례입니다. 이메일이 없으면 이 예제에서 문서를 무시하면 됩니다. 이메일 주소를 성공적으로 얻었다고 가정하면 다음 단계는 사용자가 이미 존재하는 경우 '사용자' 버킷에서 표준 사용자를 검색하는 것입니다. 이를 위해 두 번째 도우미 함수인 getUserFromEmail(email)이 있습니다. 이 함수는 이메일에 대한 키 값 조회로 간단히 사용할 "fieldindex" 버킷을 활용합니다. "fieldindex" 버킷에서 이메일과 일치하는 문서를 검색합니다. "fieldindex"의 키에 데이터 유형을 미리 추가하여 나중에 더 많은 데이터 유형을 추가할 때 혼동하지 않도록 합니다! "fieldindex"에서 이메일을 찾으면 관련 사용자 아이디를 반환하고, 그렇지 않으면 null을 반환합니다.
중복 제거
온업데이트 함수에서 기존 사용자 아이디를 찾는 데 성공했다면 '사용자' 버킷에서 해당 기존 사용자를 검색하고 현재 문서 메타아이디를 일치하는 문서 목록에 추가하기만 하면 됩니다. 기존 사용자 아이디를 찾지 못하면 새 사용자를 만들어야 합니다. 이렇게 하려면 원본 문서에서 시작하여 생성된 타임스탬프와 이 사용자 이메일과 일치하는 문서 목록을 담을 일치 항목 시작 필드 등 몇 가지 필드를 추가하기만 하면 됩니다.
새 사용자 문서를 가져오거나 만든 후에는 해당 문서를 '사용자' 버킷에 저장합니다. 사용자를 저장할 메타아이디가 필요합니다. 이 예에서는 단순히 이 사용자를 생성하는 원본 문서의 메타아이디를 사용하고 있지만, 다른 것을 선택할 수도 있으며 이는 여러분의 선택에 달려 있습니다. 사용자가 이미 존재하는 경우 단순히 덮어쓰기만 하면 됩니다.
사용자 색인 생성
마지막으로, 이 이메일 주소가 포함된 향후 문서를 올바르게 식별할 수 있도록 "fieldindex" 버킷을 업데이트해야 합니다. 이를 위해 마지막 헬퍼 함수인 addEmailToFieldIndex(email, user)를 사용합니다. 이 함수는 지정된 이메일을 키로, 지정된 사용자 아이디를 문서 본문으로 "fieldindex" 버킷에 간단히 기록합니다.
여기까지입니다! 단 50줄의 코드만으로 실시간 사용자 중복 제거 엔진의 시작을 알 수 있습니다. 테스트해 보겠습니다.
기능 테스트
이 함수를 배포한 후 '스테이징' 버킷에 몇 개의 문서를 만들어 테스트해 볼 수 있습니다.
먼저 기준 사용자를 만들어 보겠습니다. '스테이징' 버킷에 다음과 같은 새 문서를 만듭니다:
|
1 2 3 |
"test::1" { "이메일": "abc@abc.com" } |
"fieldindex" 및 "users" 버킷에서 즉각적인 효과를 볼 수 있어야 합니다. "fieldindex"에는 키/값 문서가 만들어져 있습니다:
|
1 2 3 |
이메일::abc@abc.com { "userid":"test::1" } |
이 이메일은 단순히 사용자 아이디를 가리키는 이메일이며, 이 경우 첫 번째 원본 문서의 메타 아이디인 test::1에 해당합니다.
다음으로 '사용자' 버킷을 살펴봅니다. 여기에는 새로 생성된 사용자가 있습니다:
|
1 2 3 4 5 6 |
테스트::1 { "이메일":"abc@abc.com", "userid":"test::1", "created":1546531965825, "matches":["test::1"] } |
원본 이메일 주소와 일치하는 문서의 전체 목록을 포함한 몇 가지 추가 필드가 있음을 알 수 있습니다(현재로서는 첫 번째 문서에 불과합니다).
에지 케이스를 테스트하기 위해 문서를 몇 개 더 추가해 보겠습니다. 다음 두 문서를 '스테이징' 버킷에 추가합니다:
|
1 2 3 4 5 6 7 |
테스트::2 { "name":"Tavi" } 테스트::3 { "useremail":"abc@abc.com" } |
test::2 문서에는 이메일 필드가 없으며 이메일이 없는 문서를 무시하고 있다는 사실을 테스트하는 용도로만 사용됩니다.
test::3 문서에서는 몇 가지를 테스트합니다. 첫째, 이메일 필드가 "useremail"이지만 일반적인 이메일 필드 찾기 방식이므로 문제없이 잡혀야 합니다. 둘째, 일치하는 이메일이 있습니다! "사용자" 버킷을 확인하여 어떻게 되었는지 살펴봅시다. 여전히 한 명의 사용자만 있지만 문서가 약간 다릅니다:
|
1 2 3 4 5 6 |
테스트::1 { "이메일":"abc@abc.com", "userid":"test::1", "created":1546531965825, "matches":["test::1", "test::3"] } |
여기서 유일한 차이점은 이제 일치 필드에 test::3 문서에 대한 참조가 있다는 것입니다. 만세! 해당 문서를 성공적으로 중복 제거했습니다.
결론
위에 표시된 것처럼 새로운 Couchbase Eventing 시스템을 사용하여 실시간 사용자 중복 제거 엔진을 만들 수 있습니다. 이 예제는 매우 단순화되었지만, 자바스크립트(이벤트 함수에 사용되는 언어)는 매우 다재다능하며 원하는 거의 모든 것을 할 수 있습니다.
보다 완벽한 기능을 갖춘 중복 제거 엔진은 사용자 이메일뿐 아니라 더 많은 필드를 고려할 수 있습니다. 훨씬 더 복잡한 휴리스틱을 사용해 문서를 서로 일치시킬 수도 있습니다. 특정 사용자의 식별 정보를 기반으로 특정 사용자를 가구로 그룹화하는 두 번째 수준의 매칭을 고려할 수도 있습니다. 이 모든 것은 사용자의 선택에 달려 있지만, Couchbase Eventing을 사용하면 실시간 중복 제거가 쉬워집니다.
