네이버 DAN24 플링크와 아이스버그를 활용한 데이터 웨어하우스 세션 정리

요즘 ~을 곁들인을 주제로한 세션들이 많아졌다

DAN24

DAN은 platform의 한국어 표현으로 네이버가 공유하는 플랫폼의 역할과 비전을 공유하는 네이버의 통합 컨퍼런스라고 한다. 근데 이왕 한국어표현을 가져올거면 DAN까지 단이라고 하지..처음에는 데이터 어쩌구 네이버의 줄인말인줄 알았다.

아무튼 네이버 컨퍼런스가 열린다는 소식을 듣고 신청을 하려고했는데 추첨제가 아닌 선착순이었고 무려 5분도 채 되지 않아서 접수가 마감되었다는 소식에 허탈함과 함께 컨퍼런스 영상이 올라오기만을 기다렸다.

그리고 드디어 컨퍼런스 영상이 올라왔고 세션들 중에서 제일 보고싶었던 해당 세션을 보고 내용을 정리해봤다. 사실 여러 다른 세션들도 정리하고 싶었으나 이번 컨퍼런스는 ML이나 AI에 많이 초점이 맞춰지고 내가 관심있는 엔지니어링 분야쪽은 그렇게 많지 않았어서 결과적으로 컨퍼런스에 참가하지 못했어도 크게 아쉽지는 않았다.

다음에는 카카오 컨퍼런스에 있는 세션들 중에 내가 관심있어하는 세션들을 모아서 정리해볼 예정이다.

Universal Log Data Warehouse

• 현재 네이버는 수많은 서비스를 제공
• 로그 분석을 위해서 각 서비스마다 로그 웨어하우스를 만든다면 리소스 낭비가 발생
• 이런 상황을 방지하기 위해서 범용적인 웨어하우스가 필요
• 이를 위해 기존에는 HBASE를 커스텀해서 범용적인 데이터 레이크하우스를 운영하고 있었음
• 오랜 기간 운영하면서 높은 안정성과 높은 스키마 자유도가 있었지만 로그라는 특성에는 맞지 않아서(시간베이스이기 때문에 random access방식인 hbase의 특성과 맞지않음) 조회속도가 느리고 타 쿼리엔진에서 사용하기가 힘들었음
• 그래서 결국 새로운 로그 데이터 웨어하우스의 필요성 대두
• 새로운 로그 데이터 웨어하우스의 목적

 

CQueryHub Architecture

• CQueryHub를 구성하기 위한 테이블포맷 라이브러리

• 데이타브릭스 제품을 사용하지 않아서 델타레이크를 제외하고 프라이머리 키와 오토컴팩션을 제공하는 후디는 데이터의 관리효율면에서 장점이 있음 아이스버그는 다양한 플랫폼과 쿼리엔진을 지원하기 때문에 현재 운영중인 시스템과의 호환성면에서 장점이 있음
• Hudi와 Iceberg를 직접 POC를 해봤을때 데이터 양이 많아지면 Auto Compation 작업시 타임아웃이 발생하며 사용이 불가하지만 Iceberg는 매우 안정적으로 동작하였음→ 기존 시스템과 호환되며, 안정적으로 동작하는 Iceberg를 선택하게됨
• Iceberg는 Spark, Flink를 스트리밍 라이브러리로 사용 가능
• 기존에 Storm의 사용 경험이 존재했기 때문에 Storm과 유사한 방식으로 동작하며 확장 가능성이 있는 Flink를 선택

• lassifier는 뭉쳐있는 로그들을 각 데이터셋별로 별개의 kafka 토픽으로 분리하는 역할을 함
• 의존성 제거 및 데이터 셋 별로 설정 추가로 관리 효율성을 올림
• 만약 제외할 로그들을 정적으로 관리한다면 변경될때마다 플링크를 재시작해야하므로 무중단으로 파이프라인을 운영한다는 기준에 불충족하므로 보완이 필요함
• Writer부분에서 로그들을 파싱하고 Iceberg 테이블 스키마에 맞게 변환하여 저장함
• Control Center에서 작업에 대한 모든 설정, 규칙, 리소스를 관리하고 데이터셋에 대한 파이프라인 자동 생성, 삭제, 수정 및 스키마 관리를 할 수 있음→ 운영자동화, 관리효율 높임

Flink Cluster

• 플링크 클러스트는 크게 JobManager와 TaskManager로 구성됨
• JobManager가 모든 작업을 관리하기 때문에 HA없이 구성되어 이 JobManager가 Down되면 작업정보가 유실될 수 있음
• TaskManager에는 실제 작업이 수행되며 N개의 TaskSlot이 존재하고 1개의 TaskSlot에서 1개의 Task 수행
• 플링크는 세션 모드와 어플리케이션 모드가 존재함

• 제한된 장비내에서 최적의 구성방법을 고민했을 때 AIDA 데이터 플랫폼이 프로젝트 단위로 운영되는 성격에 착안해서 프로젝트마다 별개의 Session 모드의 Flink 클러스터를 생성하기로 함
• 클러스터 전체에 영향을 주는 k8s의 CPU는 고정시켜두었고 개별 어플리케이션별 조절 가능한 Parallelism으로 리소스 사용량을 조절함
• 파이프라인의 안정성을 위해서 플링크 JobManager의 HA 구성이 필요

Data Integrity

• 로그 컬렉터가 at least once 정책으로 운영 중이기 때문에 중복이 존재할 수 있음
• writer과정에서 deduplicator 과정을 통해 중복제거
• 유니크키를 캐시에 저장 후 이후 처리하는 데이터와 동일한 유니크키가 있는지 확인하는 과정을 통해서 중복을 제거함
• Flink의 KeyBy 기능을 이용하여 같은 유니크키는 항상 같은 deduplicator로 전송되도록 설정함
• 유니크키는 메모리에 저장하기 때문에 너무 많은 유니크키가 저장되면 OOM이 발생되며 어플리케이션이 중지될 수 있음→ 최근 일정기간만 저장하도록 하고 이후 중복된 로그는 Iceberg 테이블에 주기적으로 검사하여 중복 로그 삭제하는 airflow dag를 추가함
• 캐시는 휘발성이라 어플리케이션이 재시작하면 캐시가 삭제되어 중복제거 불가능한 문제→ Flink에서 제공하는 State를 이용하여 체크포인트마다 캐시를 State로 저장하고 Flink가 재시작될 때 State를 이용하여 캐시를 복구해서 문제 해결→ State 크기가 커지면 State를 저장하는 시간이 체크아웃 주기보다 길어지면 에러가 발생하니 주의 요망

Data Cleaning

• 사용자는 로그를 단순 문자열로 보내고 있음 문자열을 Java Object로 파싱하고 아이스버그 스키마에 맞게 맵핑 작업
• 아이스버그의 필드명은 Case Insensitive하기 때문에 특정 특수문자만 사용가능함
• 데이터값이 변경되지 않는 선에서 타입을 변경해서 null로 값이 들어가는 것을 방지
• 그럼에도 불구하고 정상 처리 되지 않은 데이터는 일부 null로 저장되는 경우가 있음 오류에 대해 생산자에게 리포팅을 함→ 오류에 대해 사용자는 데이터를 버리거나 실패 정보를 함께 저장, 별도 테이블로 저장 등을 선택할 수 있음

Data Loading

• 실제로 데이터 웨어하우스에 파일을 쓰고 그에 대한 Commit을 수행하는 부분
• 커밋은 플링크의 체크포인트시 수행하며 체크포인트는 플링크의 중간저장지점으로 이를 이용해 플링크의 내결함성을 지원함
• 아이스버그는 크게 메타데이터 파일과 데이터 파일로 구성되어 있음

Current & Future

• 24년 6월 정식 오픈 5개월간 운영중
• 수백개의 프로젝트, 수백개의 테이블, 초당 수십만개 , 일간 수십억개 계속해서 처리중
• 급작스러운 로그 양 증가시 수동 대응 필요했음 앞으로는 자동으로 트래픽이 증가되도록 해야함
• OLAP 워크로드에 최적화하기 위해서 데이터별 커스터마이즈 기능 제공필요(다양한 파티션, key sort, z-order 등)

마무리

아, CQueryHub는 다른 프로젝트나 라이브러리 이름이 아니라 네이버에서 웨어하우스 플랫폼을 부르는 명칭인 것 같다. 이 세션을 보고느낀 건 요즘 아이스버그의 언급이 커뮤니티나 여러 회사의 사용기 같은게 이전보다 확실히 늘어나는게 체감된다는 정도? 그런점에서 후디와 아이스버그, 델타레이크를 비교하는 장표가 있는데 개인적으로 가장 좋았던 부분이다.