[Line Developer Day 2021] LINE Data Platform에서 Apache Iceberg 도입

LINE Data Platform에서 Apache Iceberg 도입

• DAY1 14:20-15:00 KST
• Youtube 영상 link

배경

• 데이터 포맷은 파일시스템 디렉토리로 관리됨.

• 메타데이터 변경 및 조회는 하이브 메타스토어를 통해 이루어지는데,

• 테이블 메타데이터는 메타스토어 DB (RDBMS) 에 저장

• 라인 데이터 플랫폼은 데이터를 저장하는 HDFS, 테이블 메타데이터를 저장하는 하이브 메타스토어

• sql 엔진은 spark hive trino

• 데이터분석가는 interactive 쿼리나 스케줄러를 통해 etl 파이프라인 구현

• 메타스토어 인스턴스는 플랫폼 사용자 전체가 공유 -> 트러블 발생 영향 큼

• 메타스토어 DB에는 select 의 qps 가 크고 초당 5천개 꼴로 쿼리 수행됨.

  • 사용률이 높을 때 CPU 사용량이 매우 높음
  • -> 하나의 메타스토어 DB에 천만이 넘는 row가 있어 과부하 걸렸음

• 파티션이 너무 많아 OOM으로 다운되는 일도 있었음

• 하이브 메타스토어가 대량의 데이터를 다룰 수 없어 러프한 단위로 파티셔닝할 필요는 있음

Apache Iceberg

• 오픈소스 테이블 포맷.

• sql 쿼리 엔진에 대해 파일 포맷, 파일 스토리지 레이아웃을 추상화하였음.

• spark 용 라이브러리를 사용해 spark sql 로 iceberg table 을 다루는 등.

• 아이스버그는 스냅샷 이라는 컨셉이 있음.

• SQL 실행시 테이블 파일로 추상화하고, 이를 스냅샷으로 관리해 테이블 상태를 추적함.

• 데이터를 쓰고 커밋하면 새로운 스냅샷을 작성.
  • 새 파일이 하나 추가되면 테이블 참조를 추가하여 저장

• 테이블 메타데이터 파일에는 스냅샷 정보가 있고, manifest 파일 참조를 가짐
• manifest 파일은 통계 정보 등 메타데이터 정보를 직접 가지고 있음

• 하이브와 다른 부분은 메타데이터가 파일로 추적이 된다는 점. (하이브는 하이브 메타스토어)
• 하이브에 대한 의존성이 없어지고, Hdfs를 보관장소로 이용 가능.

• 파일을 사용하기 때문에 메타데이터에 대한 캐퍼시티도 증가함

• 쿼리시 실제로 읽는 파일을 더 줄일 수 있음.

• 하이브 메타스토어 대신 파일로 저장, 파티션 제한도 해소, 파티션당 통계가 파일당 통계로 관리됨

  • -> 퍼포먼스 개선

• 그외 다양한 장점이 있으나 발표자가 생략.

요약

• 하이브 테이블은 하이브 메타스토어로 인한 scalability 문제가 있었음.

• iceberg로 이 이슈를 해결하고, 분석에서도 이점이 있을 것으로 예상됨.

• 원래는 엔드포인트 -> Kafka -> Flink -> RAW table -> 엔드포인트 이렇게 간단한 파이프라인이었음.

• 파이프라인은 Protobuf/JSON 포맷 직렬화하였음. Flink 를 통해 exatly-once delivery 를 지원.

• 모든 행을 한줄한줄 처리해야하는 문제가 있었기 때문에, ORC 테이블을 도입

• HDFS 갱신을 검출하면 ORC로 변환하여 유저가 읽을 수 있음

문제점

• end-to-end 도달에 시간이 오래걸림
• 테이블로서 읽는데까지 1~2시간이 소요됨. 작은 파일이 많으면 hdfs namenode 부하가 커지는 small file 이슈가 생김
• ORC 변환을 위해 추가된 Watcher, Hive, yarn 등 의존 컴포넌트가 많아 장애 발생 가능성이 높아짐.
• 메타데이터와 데이터를 분리하면서 사용자 요청이 있으면 수동 처리가 필요한 상황이 됨. (외부 스토리지라서)

Iceberg 적용으로 문제 해결

• filnk가 아이스버그 테이블에 직접 ORC/파케이 파일을 직접 write 함

• filnk가 파일을 5분마다 flush 할 수 있게 됨 (기존 1~2시간 소요)

• 작은 구조 덕분에 파일 로딩으로 인한 실패가 발생하지 않게 됨.

• spark를 이용한 컴팩션도 안전하게 처리됨

• filnk는 5분마다 00, 01, 02, ... 이렇게 스냅샷을 만들고

• spark에서는 00~03 스냅샷에 접근하는 식으로 컴팩션을 처리, 새로운 스냅샷 생성(012 식으로)

• spark 나 yarn 에 의존성이 있긴 하지만 테이블 옵티마이저에 의한 딜레이이므로 치명적이지 않음 -> 로그 파이프라인 트러블은 줄어듬

• 네임노드, 하이브 메타스토어 부하 감소 (파일로 쓰므로 네임노드나 하이브 메타스토어 스캔이 불필요하므로.)