NAVER DAN24 - CQueryHub

24년 11월 12일에 네이버 컨퍼런스 DAN에 다녀왔다.

참가한 세션 중 인상 깊은 세션이었던 [CQueryHub: Data Warehouse입니다. 근데 이제 Flink와 Iceberg를 곁들인] 세션에 대해 정리를 해보려 한다.

 

세션 주제는 CDC 아키텍쳐이었다.

CDC는 Change Data Capture의 약자로, Source DB에 변경점이 생기면 실시간으로 변경된 데이터에 대해서만 Target DB에 반영하는 기술이다. 기존 ETL 기술과 비교되는 기술이다. 둘 다 Source DB와 Target DB와의 sync를 맞춘다는 공통점을 갖고 있지만, ETL은 배치성 작업으로서의 성격이 짙다. ETL은 변경점을 기준으로 Target DB에 반영하지 않고 매일 매시간을 기준으로 업데이트 사항을 반영한다. 반면 CDC는 변경이 일어나면 실시간으로 업데이트해준다. 실시간에 대한 요구가 많아지면서 CDC 아키텍처가 많이 뜨고 있는 추세이다.

 

세션에서는 Log DW에 대해서 CDC를 적용한 사례를 소개하고 있다.

초기 Log DW는 각 서비스마다 따로따로 운영되고 있었다. 하지만 데이터의 양과 서비스의 종류가 많아지면서 DW를 각각 운영하는 것보단 범용적으로 lake 처럼 사용하고 싶은 요구들이 많아졌다. 그래서 Iceberg와 Flink를 활용해 새로운 Log DW를 구축했다.

 

왜 Iceberg와 Flink를 사용했을까?

라이브러리들이 많아지면서 어떤 라이브러리를 왜 선택했는지 아는 것이 중요해졌다. 어떤 라이브러리를 선택했는지에 따라 지원되는 장점과 단점이 달라지기 떄문이다.

 

네이버의 Log DW의 요구사항은 다음과 같았다.

- 실시간 조회

- 기존 시스템 호환성

- 무중단 시스템

- 다양한 형태의 로그 수용

 

네이버는 DW의 Table Format Library는 Iceberg, Streaming Library는 Flink를 선택했다.

 

Table Format이 어디에 필요한 테이블 형식일까?

Data Lake는 데이터를 RDBMS와 같은 테이블 형식으로 저장하지 않고, 파일 형식으로 저장한다. 테이블 형식으로 저장하기엔 데이터의 양이 너무 많기 때문에 비용이 많이 발생하기 때문이다. 보통 Hadoop을 이용하는 것이 업계 표준이다.

Hadoop이 나오기 전에는 RDBMS에 저장한 데이터를 한 개의 고사양 서버에서 처리하는 형식으로 빅데이터를 저장했다. 그러다보니 서버의 사양을 scale-up/down할 때 물리적으로 조정해야 하고, 무엇보다 데이터를 저장하는데 비용이 너무 많이 발생했다. 이때 구글이 하나의 고사양 서버에 의지하지 않던 기존 방식의 틀을 깬, 적당한 성능의 서버 여러 대를 클러스터화해 사용하는 Hadoop을 개발한다. Hadoop은 큰 크기의 데이터를 여러 클러스터에서 분산해 처리하고, 그 결과를 다시 합쳐 데이터를 처리한다.

데이터를 분산해 쪼개는데 MapReduce 기술이, 데이터를 저장하는 데에는 HDFS(Hadoop File System)이 사용되었다. 초기에 사용자들은 데이터를 조회할 때 MapReduce를 Java로 직접 구현해 사용해야 했다. 그러면서 데이터를 조회하는데 진입장벽이 커지게 되었다. 이때 Hive와 같은 쿼리 엔진이 나타났다. Hive는 MapReduce를 추상화해 HiveQL를 이용해 데이터를 조회할 수 있게 해주는 데이터 웨어하우징 솔루션이다.

Hive는 데이터가 어떤 클러스터에 저장되어 있는지 메타 데이터를 Hive Meta Store에 저장한다. 하지만 HMS는 RDB로 이루어져 있어, HDFS의 파일 목록이 쌓일수록 병목현상이 나타날 수 있다. 또한 스키마를 한번 지정한 후 바꾸고 싶으면 전체 데이터 파일을 다시 작성해야 해 시간이 많이 소요된다는 여러 단점이 발생했다.

이러한 단점들에 대한 여러 테이블 포맷 라이브러리들이 개발되었다. Hudi, Iceberg, Delta Lake가 그 예시이다. 

 

각 포맷의 장단점은 세션 장표에서 자세하게 설명해주고 있다.

당시 네이버는 Databricks의 제품을 사용하고 있지 않았기 때문에 primary key 기능을 제공해주지 않는 Delta Lake를 선택할 이유가 없었다.

Hudi의 가장 큰 장점인 자동 compaction은 데이터의 양이 증가하면 time-out이 발생했기 때문에 무중단 시스템에는 사용할 수 없었다.

그래서 Iceberg로 table format library를 선택했다.

 

 

streaming library는 MapReduce를 대신하는 데이터 처리 프레임워크이다.

데이터를 DataFrame, Dataset 형태로 변환하거나 실시간 데이터 스트림을 처리하게 해준다.

네이버에서는 기존 Storm을 사용해 익숙한 개발자가 다수여서 이와 비슷한 스택인 Flink를 선택했다고 한다.

 

DW의 아키텍처에 대해서 간략하게 알아보자.

 

여러 서비스들에서 Log Collector로 로그들이 전송된다. classifier(Flink App)는 전송된 로그들 중 저장할 로그들을 필터링하고, 데이터셋별로 별개의 kafka topic으로 전송한다. kafka topic별로 writer(Flink App)에 전송되고, writer에서는 중복된 로그 처리를 하고, iceberg 테이블 형식으로 변환해 데이터를 저장한다.

 

이번 세션으로 DW의 대략적인 개념을 정리할 수 있어 좋았다. 그치만 데이터 처리, 데이터 저장 등 추상적인 개념으로 DE를 다루다보니 용어가 나올 때마다 매번 헷갈리는거 같은 기분이다. 기회가 되면 각 기술 스택을 직접 다뤄보고 싶다.