오픈소스를 뜯어보는 것 외에도 해외 기술블로그를 보는 습관을 들이고 있습니다. CS를 포함한 기초공부에도 많은 시간을 투자해야 하는데… 그런게 하기 싫어서 이런 쪽으로 계속 눈이 가는 것 아닌가 싶기도 합니다. 이럼 안되는데.ㅠㅠ

이 포스팅은 제가 제일 처음 봤던 해외 기술블로그 글인데, 하나의 주제이긴 하지만 빅데이터 플랫폼 전반에 대한 설명이 되어있어 유익하게 읽었던 기억이 납니다. 제목은 Cost-Efficient Open Source Big Data Platform at Uber이고, 원문은 여기입니다 :)

우버의 효율적인 오픈소스 빅데이터 플랫폼

우버 비즈니스가 확장되면서, 우버가 감당해야 할 데이터 풀이 커지고 처리비용 또한 상당히 증가했습니다. 빅데이터가 우리 비즈니스에서 큰 비용을 차지하게 되었고, 우리는 플랫폼에서 효율성, 수요, 공급의 비용 절감이라는 3가지 과제를 내걸었습니다.

이 포스팅에서 우리가 어떤 노력을 했고 어떻게 비용절감을 했는지에 대한 내용을 다룰 것입니다.

빅데이터 파일 포맷 최적화

HDFS는 대부분 Apache Hive 계열이 점유합니다. Parquet와 ORC가 대표적이며, 아직 구현하지 못했지만 호환성과 성능을 고려해 Parquet 단일 포맷으로 통합할 계획을 가지고 있습니다.

Parquet와 ORC 모두 블록 기반 컬럼 베이스 포맷입니다. 이 말은, 파일이 여러 개의 block으로 구성되어 있고 각 블록마다 column 단위로 수많은 row가 저장된다는 의미입니다. 우리는 HDFS 파일 포맷을 조사하는데 상당한 시간을 썼으며, Parquet 포맷을 중점으로 최적화를 진행하기로 결정했습니다.

압축 알고리즘

기본적으로 parquet는 레벨 6 gzip 알고리즘을 사용해 파일을 압축합니다. 최근 ZSTD 알고리즘이 parquet를 지원하도록 개발한 것에 주목했고, 실험에서 ZSTD 레벨 9와 19는 gzip 기반 parquet 파일보다 8%, 12%만큼 크기가 감소한 것을 확인했습니다.

또한 ZSTD 레벨 9와 19는 레벨 6 gzip보다 압축 해제 속도도 빠릅니다. 우리는 자체 실험에서 레벨 9 압축이 레벨 19 압축보다 3배 더 빨랐다는 것을 이유로, 1개월이 지난 데이터는 ZSTD 레벨 9로, 3개월이 지난 데이터는 ZSTD 레벨 19로 압축하기로 결정했습니다. 재압축은 컴퓨팅 리소스가 메인으로 사용되어야 하는 작업이 아닌, 백그라운드에서 자유롭게 실행되어도 되는 작업이기 때문입니다.

컬럼 삭제

많은 Hive 기반 포맷이 그렇지만 특히 Apache Kafka의 로그 파일은 컬럼이 매우 많으며 nested 형태의 컬럼도 존재합니다. kafka의 디버깅 규정에 따른 메타데이터 컬럼은 규정에 따라 일정 기간 이후에는 삭제해야 하는데, 이처럼 굳이 장기간 보관하지 않아도 되거나 반드시 삭제해야 하는 컬럼도 분명 존재합니다.

컬럼의 포맷이 주어지면, 컬럼을 삭제하기 위해 다른 컬럼도 압축을 해제하거나 재압축할 필요 없이 파일 내부의 컬럼을 삭제할 수 있습니다. 이는 컬럼 삭제에 드는 CPU 비용을 크게 줄일 수 있고, Uber는 이 기능을 구현해 많은 Hive 테이블에서 사용하고 Apache parquet에 코드를 제공했습니다.

Row 재정렬

Row 정렬은 parquet 파일 크기에 엄청난 영향을 줄 수 있습니다. Parquet 포맷 내부의 Run-Length 인코딩 방식과 Local repeat을 활용하는 압축 알고리즘 때문입니다. 우리는 Uber에서 가장 큰 Hive 테이블을 조사하고 수동으로 재정렬했습니다. 사용자 ID를 기준으로 정렬한 뒤 로그 테이블에 타임스탬프를 추가하는 일반적인 패턴으로 우리는 50% 가까이 테이블 크기를 줄일 수 있었습니다.

이를 통해 User ID와 관련된 비정규화 컬럼들을 잘 압축할 수 있었습니다.

Delta Encoding

타임스탬프를 기준으로 정렬을 한다면, 타임스탬프 간의 차이가 매우 적기 때문에 델타 인코딩이 데이터 크기를 줄이는 데 도움이 될 거라 생각했습니다. 그 간격이 일정한 경우에는 더 효율이 높을 것입니다. 그러나 Hive, Spark, Presto 등 다양한 환경에서 Parquet에 델타 인코딩을 적용하는 것은 쉽지 않았습니다. 스택오버플로우 참고

우리는 이에 대해 계속 연구하는 중입니다.