검색 서비스
이 글은 데이터 민주화와 셀프서비스 데이터를 읽고 쓰는 포스트입니다. 이 장에서는 주요하게 다루는 내용이 “실제 사용자가 메타데이터를 어떻게 찾아내는가?”에 대한 내용입니다. 제가 크게 관심이 있는 내용이지만, 도저히 정확한 방법이 떠오르지 않는 부분이기 때문에 정확하게 공부를 하고자 합니다.
여정 지도
비즈니스 단계에서 실행 가능성 확인
데이터 세트의 메타데이터를 수집하여 검색하고자 하기 때문에 실제 검색 서비스를 개발하기 전에 데이터 세트의 상태가 중요합니다. 데이터 세트가 가용한지 확인이 필요합니다.
데이터 세트의 상태는 다음과 같이 분류했습니다.
- 데이터가 존재하지 않으며 애플리케이션을 계측해야하는 상태
- 소스 시스템에서 데이터를 사용 할 수 있지만, 데이터 레이크에서 집계되지 않는 상태
- 데이터를 사용 할 수 있으며 이미 다른 아티팩트에서 사용 중인 상태
데이터 준비를 위해 연관된 데이터 세트 선택
데이터 준비를 위해 연관된 데이터 세트를 선택하는 것은 키워드를 사용해 데이터 세트를 검색하고, 검색 결과를 샘플링하고, 데이터 속성의 의미와 계보에 대한 심층 분석을 선택하는 반복 프로세스입니다. 이를 위해서는 적절하게 정의되어 있어야 기준으로 삼을 수 있습니다.
프로토타이핑을 위해 기존 아티팩트 재사용
데이터 파이프라인, 대시보드, 모델, 쿼리 등 재사용 할 수 있는 빌딩 블록을 찾으면 전 과정이 수월해집니다.
탐색 시간 최소화
데이터 세트 및 아티팩트 인덱싱
- 데이터 세트와 아티팩트의 소스 찾기
- 치트시트 혹은 위키, 경험 진술등의 형식으로 된 팀 지식을 활용하여 찾아야 합니다.
- 해당 소스를 조사해 스키마와 메타데이터 속성 같은 세부 정보 수집
- 소스 기술에 특화된 API, CLI가 필요합니다.
- 데이터 유형과 세부 사항을 알기위해서는 또 다시 팀 지식이 필요합니다.
- 데이터 파이프라인 코드와 같은 아티팩트는 쿼리 로직과 재사용 방법을 분석해야 합니다.
결과의 순위 매기기
결과의 순서를 매기는 건 다양한 문제로 인해 어렵습니다.
- 테이블에 명확한 이름이나 잘 정의된 스키마가 없을 수 있습니다.
- 테이블 내의 속성 이름이 적절하지 않을 수 있습니다.
- 적극적으로 사용되거나 관리되지 않는 묘지 데이터 세트와 아티팩트가 있을 수 있습니다.
- 스키마가 비즈니스의 발전에 상응해 발전하지 않을 수 있습니다.
- 스키마 디자인에 대해 큐레이션과 모범사례를 따르지 않았을 수 있습니다.
접근 제어
- 데이터 세트 및 아티팩트 소스에 안전하게 연결
- 검색 결과에 대한 접근 제한
요구 사항 정의
검색 서비스가 데이터 사용자의 질문에 대답 할 수 있어야 하는 질문의 예제도 포함되어 있습니다.
- 주제 X와 관련된 데이터 세트 또는 아티팩트가 있는지?
- X와 매치된 내용은 이름, 설명, 메타데이터, 태그, 범주 등과 관련되어 있는가?
- 주제 X 및 이와 관련된 데이터 사용자 팀에서 가장 많이 사용되는 데이터 세트와 아티팩트는 무엇인가?
- 최종 후보군 데이터 세트의 메타데이터의 세부정보는 무엇인가?
이러한 질문에 대답 할 수 있는 검색 시스템을 구축하는 것을 목표로 해야 한다고 말합니다.
그리고 이러한 검색 시스템을 구축하는 데에 주요 모델을 구분하면 다음과 같습니다.
- 인덱서 모듈
- 사용 가능한 데이터 세트와 아티팩트를 발견하고, 스키마 및 메타데이터 속성을 추출하고, 카탈로그에 추가합니다. 이 모듈은 변경 내용을 추적하고 세부 정보를 지속적으로 업데이트 해야 합니다.
- 순위 모듈
- 관련성과 인기도의 조합에 따라 검색 결과를 순위 매기는 역할을 합니다.
- 액세스 모듈
- 데이터 사용자에게 표시되는 검색 결과가 접근 제어 정책을 준수하도록 합니다.
인덱서 요구 사항
검색 엔티티는 데이터 세트와 아티팩트의 업데이트 내용을 지속적으로 추출하여 업데이트되어야 합니다. 이 부분은 이미지로 포함하는 편이 좋을 것 같습니다.
고려 할 부분은 다음과 같습니다.
- 변경 사항 반영을 위해 얼마나 빨리 인덱스를 업데이트 해야 하는지 결정합니다. 즉, 리프레시까지 감당 할 수 있는 지연 수준을 결정합니다.
- 버전 및 히스토리 파티션에 걸쳐 인덱스를 정의합니다. 즉, 검색 범위가 현재 파티션으로만 제한 되는지 여부를 정의합니다.
요구 사항 순위 매기기
순위는 관련성과 인기도의 조합입니다. 여기서 관련성은 이름, 설명, 메타데이터 속성의 매칭을 기반으로 합니다. 이 부분에서 메타데이터의 범주에 대한 이미지가 포함되어 있는데 이 부분도 이미지로 올릴 정도로 괜찮은 정보라 포함하겠습니다.
접근 제어 요구 사항
여기서 알아 갈 키워드는 모임의 스터디를 통해 조금 더 깊게 알 수 있었습니다.
RBAC ( Role Based Access Control )
RBAC은 Role 기반의 접근 제어 방식입니다. AWS에서 IAM에 해당 팀 및 업무에 관련한 접근 Role을 구성하고 일원에게 부여하는 방식이 이러한 Role 기반 접근 제어 방식에 해당합니다.
언뜻봐도 매우 편한 방식의 접근 제어 방식입니다. 하지만 특정 유저의 서비스 접근 제어를 하고있지만, 여전히 부족한 부분은 있습니다. 특정 컬럼에 대한 암호화, 데이터 태그등 속성에 대한 제어는 아닙니다.
ABAC ( Attribute Based Access Control )
ABAC은 말 그대로 속성을 이용하여 접근을 제어하는 방식입니다. 이해 한 내용으로는 리눅스의 접근 제어를 예시로 들 수 있을 것 같습니다. 파일의 작성자가 root의 경우 -rw-r–r—의 권한을 가진 파일이라면 root만 작성이 가능하고 다른 유저는 파일의 쓰기가 불가능합니다. 이렇듯 파일의 속성이나 -rw-rw—- 파일이라면 같은 그룹의 유저만 쓸 수 있는데 유저의 속성에 따라 접근 제어를 하는 등의 방식이 ABAC 입니다.
마침 두 방식에 대한 좋은 포스트가 있어서 링크를 포함하겠습니다.
구현 패턴
푸시 풀 인덱서 패턴
사용 가능한 데이터 세트와 아티팩트를 발견하고 지속적으로 업데이트 합니다. 이 과정을 책에서는 총 3단계로 나누었습니다.
1 ) 연결 단계
인덱서는 데이터베이스, 카탈로그, 모델 및 대시보드 저장소 등과 같은 사용 가능한 소스에 연결합니다.
2 ) 추출 단계
데이터 세트와 아티팩트의 이름, 설명, 기타 메타데이터와 같은 세부 정보를 추출합니다. 앞으로 이러한 업무를 진행하고자 하는 입장에서 고려 할 점은 수집 할 메타데이터를 정의하는게 좋을 것 같다는 생각을 하고 있습니다.
아마, 데이터 플랫폼의 성향마다 수집 할 수 있는 메타데이터가 조금 다를 수 있습니다. 유동적인 정보를 담아서 파이프라인을 별도 작업해야 할 것으로 예상되기 때문에 수집 데이터를 정의하는 단계가 필요 할 것 같습니다.
3 ) 업데이트 단계
소스는 이벤트 버스에서 데이터 세트와 아티팩트에 대한 업데이트를 게시합니다. 예를들면 DB에서 테이블을 삭제하면 이 푸시 알림을 구독해서 레코드를 삭제합니다.
이 부분은 조금 실 환경에서 사용 시 주의해서 개발해야 할 듯 합니다.
- 그림 추가하기
푸시-풀 인덱서 패턴의 강점
- 인덱스 업데이트가 시기적절합니다. 새 소스가 주기적으로 크롤링되어 변경 이벤트는 처리를 위해 이벤트 버스에 푸시됩니다.
- 다양한 범주의 메타데이터 속성을 추출하고 업데이트하기 위한 확장 가능한 패턴입니다.
- 푸시 및 풀 방식의 조합을 고려할 때 많은 소스를 지원하도록 확장 가능합니다.
푸시-풀 인덱서 패턴의 약점
- 다양한 소스 유형에 대한 구성과 배포가 어려울 수 있다.
- 풀을 통해 세부 정보에 접근하려면 소스 권한이 필요한데, 규제된 소스에는 우려 사항이 될 수 있다.
하이브리드 검색 순위 패턴
검색되는 목록에는 테이블 이름, 비즈니스 어휘 개념, 분류 태그 등의 문자열로 이루어져 있습니다. 주요 목표는 가장 관련성 있는 정보가 상위 N번째에 오는 것으로 이를 위해 검색 순위 패턴을 잘 구축해야 합니다.
패턴으로는 세 단계가 있습니다.
- 구문 분석 단계
- 검색은 기본적으로 역인덱싱을 기반으로한 검색을 기반으로 합니다.
- 메타데이터 범주는 인덱스의 특정 섹션과 연결 할 수 있습니다.
- 인기 있는 테이블과 아티팩트 목록을 찾아보고 비즈니스 문제와 가장 관련이 있는 항목을 찾는 방식을 추구 할 수 있습니다.
- 순위 단계
- 결과의 순서는 관련성(테이블 이름, 열 이름, 테이블 설명, 메타데이터 속성 등에 입력된 텍스트의 퍼지매칭)과 인기도(많이 쿼리 된 데이터 세트, 아티팩트)의 조합입니다.
- 새로 생성된 데이터는 인기가 없으므로 별도의 로직 필요
- 피드백 단계
- 좋아요, 싫어요, CTR등의 피드백을 기반으로 만듭니다.