Backend Engineer - Data Platform Engineering 사전 과제

아래 문안을 참고하여 데이터 플랫폼의 설계를 다이어그램으로 작성한 뒤, PDF 파일로 제출해 주세요.
(분량과 양식은 자유입니다.)

개요

데이터 플랫폼 팀에서는 여러 데이터 소스로부터 다양한 종류의 데이터를 받아 관리하는 데이터 컨소시엄을 개발 및 운영 해야 합니다. 일반적으로 데이터 소스와 실시간 스트리밍으로 데이터를 송/수신 하거나, 파일 서버를 통해 데이터를 교환해야 합니다. 데이터의 세부 스펙은 데이터 제공사 별로 다르지만, 유형은 크게 이벤트 데이터와 유저 데이터로 분류됩니다. 데이터 컨소시엄에서 데이터 플랫폼 팀의 역할은 데이터를 수집하고, 가공 및 정제 후 데이터를 각 컨소시엄 참여사가 다시 활용할 수 있도록 돕는 것 입니다.

많은 유저 정보와 이벤트 데이터를 수집하는 것도 중요 하지만, 신뢰할 수 있는 파이프라인을 통해 유실 없이 데이터를 이동할 수 있어야 합니다. 데이터와 인프라에 대한 보안은 필수이기 때문에, 관리 가능한 데이터 접근 권한과 트래픽 증가를 대비한 확장성을 모두 고려하여 설계를 해야 합니다.

요구사항

자사 데이터를 보유하고 있는 서로 다른 3개의 회사와 AB180이 협동하여, 상호간 데이터를 교환할 수 있는 데이터 컨소시엄을 개설하려고 합니다. AB180의 데이터 엔지니어 팀은 해당 컨소시엄의 데이터 교환 플랫폼을 설계하고 운영해야 합니다.

플랫폼에서는 아래와 같은 작업들을 수행 합니다.

•

Input

◦

플랫폼에서 제공하는 서비스들을 활용해 데이터를 수집 합니다.

•

Validation

◦

데이터 제공자 검증과 데이터 유효성을 확인하고 사용 가능 여부를 판단합니다.

•

Transformation

◦

플랫폼에서 제공하는 서비스에서 사용할수 있는 형태로 정제 및 변형 시킵니다.

•

Storage

◦

필요한 저장소들에 데이터를 적절히 저장하여 데이터를 활요할수 있게 합니다.

•

Output

◦

플랫폼 이용자, 즉 컨소시엄 참여사들에게 데이터를 요구사항에 맞춰 분배 합니다.

위의 작업들을 수행하기 서비스를 구분해서 운영해도 또는 결합하여 여러 기능을 한개의 서비스에서 수행해도 무관합니다. 다만 데이터 플랫폼에 많은 트래픽을 처리할수 있어야되며 장애 대처가 가능 해야 합니다.

아래 세부 내용들을 검토 후 본 컨소시엄을 위한 데이터 플랫폼의 설계를 다이어그램으로 보여주십시오.

예시

데이터

INPUT

데이터 플랫폼으로 전송될 INPUT 데이터 종류는 아래 두가지로 분류 됩니다.

•

USER - 이벤트를 발생시키는 유저에 대한 정보입니다.

◦

참여사의 앱에 가입시 생성되는 유저 데이터 입니다.

◦

alias 는 유저 식별 정보 입니다

▪

adid - 유저 광고 식별자

▪

phoneNo - 유저 전화번호

▪

email - 유저 이메일

◦

personalInfo 는 식별 정보 외 유저 기타 정보 입니다.

◦

consent 는 유저가 데이터 활용에 대한 동의 여부 입니다.

◦

dataProvider 데이터 제공자 (참여사) 식별자 .

USER {
alias : {
adid: string
phoneNo: string
email: string
}
personalInfo : {
name: string
birthDate: string
gender: string
postcode: string
}
consent: bool
dataProvider: string
} 
JavaScript

•

EVENT - 참여사별 다른 데이터를 제공합니다.

◦

userAlias 이벤트를 발생시킨 유저 식별자 입니다.

◦

eventData 이벤트 정보 입니다. 참여사별 제공되는 데이터는 상이합니다. 

▪

currency - 결제시 사용된 통화

▪

value - 결제된 금액

▪

itemName - 결제된 품목명

▪

itemCategory - 결제된 품목 1차 분류

▪

itemSubCategory - 결제된 품목 2차 분류

▪

storeName - 이벤트 발생 매장명

▪

searchVal - 검색 키워드

◦

dataProvider 데이터 제공자 (참여사) 식별자. 

◦

모바일 / 웹 SDK, 또는 참여사에서 자체 수집한 이벤트 데이터 입니다.

◦

EVENT_DATA 에는 참여사에서 전송 가능한 데이터만 필히 포함 되어 있습니다. 각 참여사가 보내는 이벤트 데이터 항목은 [참여사별 세부사항]에 있는 데이터 예제로 확인 가능합니다.

EVENT {
userAlias: {
adid: string
phoneNo: string
email: string
}
eventData: {
currency: string
value: int
itemName: string
itemCategory: string
itemSubCategory: string
storeName: string
searchVal: string
}
dataProvider: string
}
JavaScript

VALIDATION

데이터 검증 단계에서는 아래 작업들을 수행 합니다.

•

데이터 소스 검증

◦

dataProvider 값이 컨소시엄 참여사의 것인지 검증 합니다.

•

데이터 유효성 검증

◦

USER

▪

alias 최소 한개의 이상의 식별자가 포함 되어 있는지 검증 합니다.

•

adid - 정확히 36바이트 인지 확인합니다.

•

phoneNo - 전화번호 regex 패턴에 비교해 이메일 주소인지 확인 합니다.

•

email - 이메일 regex 패턴에 비교해 이메일 주소인지 확인 합니다.

▪

personalInfo 최소 두개 이상의 항목이 포함 되어 있는지 확인 합니다.

▪

consent 필히 포함 되어 있어야 합니다.

▪

dataProvider 필히 포함 되어 있어야 하며, 컨소시엄 참여사중 하나이어야 합니다.

◦

EVENT

▪

userAlias : 최소한 한개 이상의 식별자가 있어야 합니다.

▪

eventData : 참여사에 전송하기로 한 데이터 내용은 모두 포함 되어 있어야 합니다.

▪

dataProvider : 필히 포함 되어 있어야 하며, 컨소시엄 참여사중 하나이어야 합니다.

▪

최소 한개의 참여사에서라도 동의된 유저라면 이벤트 데이터 수집이 가능하고, 모든 참여사에 데이터를 전송 가능 합니다.

•

즉 [A,B,C,D] 사의 컨소시엄에서, A사를 통해 동의한 유저는 [B,C,D] 사의 이벤트 데이터를 수집 할수 있습니다.

▪

한개의 참여사에서라도 동의 하지 않은 유저의 이벤트 데이터는 수집 불가능하며, 어떠한 참여의 데이터도 공유 되어선 안됩니다.

•

즉 [A,B,C,D] 사의 컨소시엄에서, A사에서 동의 했던 유저가 B사의 미동의 고객이라면 [A,B,C,D] 사의 이벤트 데이터를 수집할수 없습니다.

▪

존재하지 않는 유저의 alias는 동의 되지 않은 유저의 이벤트 데이터와 동일하게 수집 불가능 합니다.

TRANSFORMATION

데이터를 저장할수 있도록 정제 및 가공 시킵니다.

•

USER_PROFILE - 유저 정보를 매핑해서 생성한 유저 프로필 데이터 입니다.

◦

INPUT 으로 들어온 USER 데이터를 매핑하여 생성한 유저 프로필입니다.

◦

매핑 및 프로필 생성 로직은 아래와 같습니다.

▪

USER 의 alias 에 있는 식별자중 1개가 같고 personalInfo 내용중 2가지 이상이 같다면 동일 인물로 판단하고 기존 데이터를 신규 유저 데이터로 modify 합니다.

▪

USER 의 alias 에 있는 식별자중 2개 또는 그 이상의 식별자가 같다면 동일 인물로 판단하고 기존 데이터를 신규 유저 데이터로 modify 합니다.

▪

그외 상황에서는 모두 신규 프로필을 create 합니다.

 USER_PROFILE {
id: string
profileId: string
alias: {
adid: string
phoneNo: string
email: string
}
personalInfo: {
name: string
birthDate: string
gender: string
postcode: string
}
consent: bool
createdAt: Timestamp[RFC 3339]
modifiedAt: Timestamp[RFC 3339]
dataProvider: string
} 
JavaScript

•

EVENT

◦

EVENT userData alias와 매핑되는 USER_PROFILE 의 uid 를 userProfileId 필드에 기입합니다. 

◦

만약 alias 로 조회 가능한 USER_PROFILE 이 하나 이상이라면 아래 순서대로 userProfileId 매핑 합니다. 

▪

1개 이상 매핑 되는 프로필

alias {
phoneNo -> PROFILE#2
email -> PROFILE#1
adid -> PROFILE#1
}
위 이벤트는 PROFILE#1이 발생 시킨 이벤트로 간주
JavaScript

▪

phoneNo

▪

email

▪

adid

EVENT_OUT {
userProfileId: string
eventData: {
currency: string
value: int
itemName: string
itemCategory: string
itemSubCategory: string
storeName: string
searchVal: string
}
dataProvider: string
}
JavaScript

STORAGE

TRANSFORM 된 데이터를 사용 가능하도록 적절히 저장합니다.

•

스토리지 방법과 종류에 대한 사용은 제한이 없습니다. 필요에 따라 사용 하면 됩니다. 

OUTPUT

STORAGE 에 저장된 데이터를 컨소시엄 참여사에 전송 합니다.

DATA 연동 방식

데이터 교환은 두가지 방식이 있습니다.

실시간

•

데이터 플랫폼으로 들어오는 실시간 데이터를, 필요한 데이터 검증 및 가공 후, 참여사에 실시간 또는 최소한의 시간 지연 후에 데이터를 보내주는것을 의미합니다. 

배치 (Batch)

•

당일 오전에 어제 발생한 이벤트 데이터를 JSON 파일 형태로 저장 하는 것을 뜻 합니다.

참여사별 세부사항

AB180

기본 설명

•

컨소시엄의 원할한 데이터 교환을 위한 플랫폼을 제공합니다. 

•

AWS 기반 클라우드 인프라를 사용 합니다.

데이터 예제

•

별도로 데이터 플랫폼에 제공하는 데이터는 없습니다. 

•

수집되는 데이터를 참여사 요구사항에 맞춰 전송 합니다.

◦

플랫폼에 들어오는 실시간 데이터를 참여사의 data pipeline 에 연결

◦

플랫폼에 들어오는 데이터를 파일형태 배치로 다른 참여사에 제공. 

네트워크

•

클라우드 인프라 사용

BestCard (BC)

기본 설명

•

신용카드사 입니다. 카드 결제 데이터를 제공 합니다.

•

BetterThanBestCard (BTBC) 의 경제사 입니다.

데이터 예제

USER 예제

EVENT 예제

네트워크

•

인터넷을 통해 데이터를 송/수신 할수 없기때문에 VPN 연결이 필요 합니다.

•

BC사 전용 별도 망(신규 VPC)을 생성 해주길 원합니다, 또한 해당 망은 인터넷 연결이 되지 않은 프라이빗 망 이여야 합니다.

연동 형태

•

실시간

◦

BC에서 유저 데이터를 보냅니다

◦

BC에서 이벤트 데이터를 보냅니다

◦

BC에서 유저 데이터 받습니다.

◦

BC에서 이벤트 데이터를 받습니다.

•

배치

◦

BC에서 유저 데이터를 배치로 받습니다

◦

BC에서 이벤트 데이터를 배치로 받습니다

실시간, 배치 두가지 형태로 다 받는 이유는, 동일한 데이터임에도 사용 용도가 다르기 때문입니다.

특이사항

•

BTBC 사의 이벤트 데이터를 BC 카드에 보내면 안됩니다. 유저 데이터는 보내줍니다.

MyDepartmentStore (MDS)

기본 설명

•

면세점입니다. 고객 구매 데이터를 제공합니다.

데이터 예제

USER 예제

EVENT 예제

네트워크

•

인터넷을 통해 접근 가능 합니다.

•

전용 망 사용 요청은 없었습니다.

연동 형태

•

배치

◦

MDS에서 유저 데이터를 배치로 보냅니다(파일)

◦

MDS에서 이벤트 데이터를 배치로 보냅니다(파일)

◦

MDS에서 유저 데이터를 배치로 받습니다(파일)

◦

MDS에서 이벤트 데이터를 배치로 받습니다(파일)

특이사항

•

없음

Doogle (DG)

기본 설명

•

검색 엔진 서비스 제공사 입니다. 검색 데이터를 제공 합니다.

데이터 예제

USER 예제

EVENT 예제

네트워크

•

인터넷을 통해 접근 가능 합니다.

•

전용 망 사용 요청은 없었습니다.

연동 형태

•

실시간

◦

DG에서 유저 데이터를 실시간으로 보냅니다.

◦

DG에서 유저 데이터를 실시간으로 받습니다.

◦

DG에서 이벤트 데이터를 실시간으로 보냅니다.

◦

DG에서 이벤트 데이터를 실시간으로 받습니다.

특이사항

•

없음

BetterThanBestCard (BCBC)

기본 설명

•

신용카드사 입니다. 카드 결제 데이터를 제공 합니다.

•

BestCard (BC) 의 경제사 입니다.

데이터 예제

USER 예제

EVENT 예제

네트워크

•

인터넷을 통해 데이터를 송/수신 할수 없기때문에 VPN 연결이 필요 합니다.

•

BC사 전용 별도 망(신규 VPC)을 생성 해주길 원합니다, 또한 해당 망은 인터넷 연결이 되지 않은 프라이빗 망 이여야 합니다.

연동 형태

•

실시간

◦

BTBC에서 이벤트 데이터를 보냅니다

◦

BTBC에서 이벤트 데이터를 받습니다.

•

배치

◦

BTBC에서 유저 데이터를 배치로 받습니다

◦

BTBC에서 유저 데이터를 배치로 보냅니다

특이사항

•

BC 사의 이벤트 데이터를 BTBC 카드에 보내면 안됩니다. 유저 데이터는 보내줍니다.

인프라 설계에 참고하면 좋은 점

•

데이터 처리를 위해 어떠한 서비스들이 필요한지

•

서비스에 장애가 발생했을때 어떻게 대처하면 좋을지

•

대량의 데이터를 받을수 있는 구조인지