https://www.youtube.com/watch?v=xUpi8pXyiyk
- 솔라는 아파치 루씬 기반의 오픈소스 검색 플랫폼, 역색인 구조를 사용하여 빠른 검색을 가능
- 색인 파이프라인은 데이터 처리 및 분석을 위한 일련의 단계를 의미
- 현재 구조 및 이슈: 필요한 데이터를 생성하고 전처리한 다음 색인하는 과정을 거치지만
- 그러나, 이 과정에서 많은 데이터베이스 테이블에서 변경 사항을 가져와 처리해야 하며, 증분 처리 시에도 각 문서에 많은 데이터를 반복적으로 생성해야 함
- 이는 불필요한 데이터 생성을 초래하고, 상당한 리소스를 소요
- 개선 포인트 및 향후 개선 방향: 가격 변경과 같은 단일 항목의 수정에도 문서 전체를 새로 생성하는 현재 방식은 효율적이지 않음
- 이를 개선하기 위해, 변경된 부분만을 업데이트하는 방식으로의 전환을 고려하고 있습니다. 또한, 데이터베이스 리소스 사용 최적화를 위한 방안도 모색 중
- 상품 수의 변화와 데이터 양의 증가
- 2013년부터 현재까지의 데이터를 보면, 상품 수가 약 3천만 건에서 3억 건 이상으로 급격히 증가
- 이러한 변화는 데이터 처리 시스템에 큰 부담을 주고 있으며, 이에 따라 기존의 시스템 구조를 개선하고 고도화하는 것이 필요
- 증분 큐(Queue) 처리 시간 증가: 전체 상품 수가 증가함에 따라 변경되어야 하는 상품의 수도 늘어남
- 증분 큐에 들어오는 데이터의 양이 증가하면서 처리 시간이 길어지게 됨
- 전체 데이터 생성 시간 증가: 현재는 약 8시간이 걸리는 작업이 더 긴 시간을 필요로 할 수 있음
- 지속적인 최적화를 통해 성능을 향상시켜 왔지만, 상품 수의 지속적인 증가를 고려했을 때 기존 구조의 한계가 있음
- 배치 처리 시간 증가: 각 문서별로 텀(Term)을 추출하고 스코어를 생성하는 배치 작업 시간도 함께 증가. 데이터 변경이 검색 결과에 반영되기까지의 지연시간이 발생 가능
- 구조 변경: 증분 때문에 도큐먼트의 모든 데이터를 조회하는 구조를 변경하여, 중요 피처로 분리하고 관리
- 풀 데이터 배치 페이드 아웃: 데이터 레이크를 적용하고, 아이스버그(Iceberg)를 이용하여 데이터를 더 효율적으로 관리
- 분산 처리 시스템 활용: 대용량 데이터 처리를 위해 분산 처리 시스템을 사용하여 데이터 처리의 효율성 제고
- 데이터 연동 속도 향상: CDC(Change Data Capture)를 통해 데이터를 빠르게 동기화
- 분산 처리 성능 향상: 스파크(Spark) 분산 환경을 이용하여 데이터 처리를 신속하게
- 리소스 확보: 매일 풀 데이터를 생성하는데 사용되던 많은 데이터베이스 자원을 절약
- 유형별 데이터 관리: 데이터를 유형별로 분리하여 관리함으로써, 발생할 수 있는 데이터 이슈에 대한 대응성과 관리 편의성이 증가
- 아파치 아이스버그는 분산 환경에서의 실시간 데이터 갱신을 가능하게 하는 기술, 대용량의 데이터를 실시간으로 업데이트하는 것이 가능해짐
- 아이스버그를 선택한 이유는 실시간으로 변경되는 데이터를 효율적으로 관리하고 업데이트할 수 있기 때문
- 실시간 데이터 갱신의 어려움: 한 번 쓰여진 데이터를 수정하거나 갱신하는 것은 기존 파일을 삭제하고 새로 만드는 복잡한 과정을 필요
- 데이터 엔지니어링의 주된 목표는 오라클과 같은 데이터베이스에서 데이터가 변경될 때, 이를 실시간으로 감지하고 반영하는 것
- 이를 위해 CDC(Change Data Capture) 로그를 카프카로 전송하고, 이를 스트림 처리하여 하둡에 즉시 반영하는 방식을 사용
- 이 과정은 배치 처리에서 스트림 처리로의 전환을 요구
- 데이터 압축을 통해 파일 크기를 최적화하고, 그에 따라 조회 성능을 향상
- 아이스버그는 메타 정보와 데이터를 파일 단위로 관리하며, 이는 하이브 테이블 형식의 문제점을 해결하는 중요한 기능
- 카탈로그(Catalog): 메타데이터를 관리하는 레이어입니다. 설정에 따라 파일로 관리할 수 있으며, 하이브 메타스토어를 카탈로그로 사용.
- 메타데이터 레이어(Metadata Layer): 현재의 스냅샷, 매니페스트 리스트 파일, 매니페스트 파일 등을 관리. 이를 통해 데이터 파일의 최신 상태를 추적.
- 데이터 파일 레이어(Data File Layer): 실제 데이터가 저장된 파일들
- 카탈로그에 접근하여 현재 메타데이터 파일을 가리키는 포인터를 확인합니다.
- 포인터가 가리키는 메타데이터 파일을 읽어 현재 스냅샷을 파악합니다.
- 현재 스냅샷에서 매니페스트 리스트 파일을 읽어 해당 스냅샷이 참조하는 매니페스트 파일 목록을 확인합니다.
- 매니페스트 파일을 읽어 조회해야 할 데이터 파일을 확인합니다.
- 데이터 파일을 읽고 SQL 쿼리에 대한 결과를 반환합니다.
- 업서트 쿼리가 수행되면, 최종 스냅샷이 참조하는 데이터 파일을 메모리에 로드하고, 변경된 내용을 반영하여 새로운 데이터 파일을 생성합니다.
- 새로 생성된 데이터 파일과 변경되지 않은 데이터 파일을 포함하는 매니페스트 파일이 생성됩니다.
- 마지막으로 카탈로그의 메타데이터 포인터를 새로 생성된 메타데이터 파일로 변경하면서 종료된다
- 여기서 중요한 점은 메타데이터가 메타데이터 포인터가 변경되기 전 즉 업서트 작업이 진행 중인 과정에 특정 사용자가 해당 테이블에 조회를 했을 경우 최종 스냅샷인 S1을 참조하게 되고 그에 따라 변경전 데이터 파일을 읽게 되고 이 때 무결성이 보장된다.
- 타임트래블 기능을 지원하여, 이전 스냅샷으로 돌아가 과거의 데이터를 참조할 수 있는 장점이 있다.
- 실제 운영 환경에서는 아이스버그 테이블을 사용하기 전에 RDBMS로부터의 풀 싱크 작업이 필요하다.
- 이는 카프카에 저장되는 데이터가 변경 데이터 캡처(CDC) 로그 형태로만 존재하기 때문이다.
- 아파치 스파크를 사용하여 풀 싱크를 진행한 후에는 하이브 테이블을 생성하고, 이를 아이스버그 테이블로 변환하는 '부트스트래핑' 과정
- 실시간 데이터 갱신을 위해 플링크를 사용하여 스트림 처리를 담당
- 플링크는 아이스버그 테이블의 경로에 메타데이터 파일과 데이터 파일을 생성하며, 이 데이터는 BI 도구나 머신러닝 등에 실시간으로 활용될 수 있음 데이터 파일의 병합이나 스몰 파일 문제 해결을 위해 '콤팩션(compaction)'이라는 후처리 과정이 필요
- 과정은 비동기 방식으로 백그라운드에서 수행되며, 데이터 파일을 큰 파일로 병합하여 조회 성능을 향상
- 프로메테우스와 엘라스틱서치를 이용하여 아이스버그 테이블의 상태와 성능을 모니터링하고, 그라파나를 통해 시각화하여 장애 대응에 필요한 알람 설정을 할 수 있음
- 아이스버그와 플링크의 연동 방법에는 체크포인트 인터벌 설정, 아이스버그 카탈로그 생성, 카프카와 플링크 연동을 위한 다이나믹 테이블 생성 등이 포함되며, 이 모든 과정이 완료되면 플링크 아이스버그 연동이 마무리됨
- 마지막으로, 실시간 데이터 갱신은 사용자가 빠르게 데이터에 접근할 수 있게 해주지만, 스몰 파일 문제와 같은 트레이드 오프가 존재
- 적절한 갱신 속도와 조회 성능을 찾는 것이 중요하며, 각자의 환경에 맞게 최적화된 솔루션을 찾기 위한 테스트와 시행착오가 필수적