1. 시작말

안녕하세요.

데이터 엔지니어링 & 운영 업무를 하는 중 알게 된 지식이나 의문점들을 시리즈 형식으로 계속해서 작성해나가며

새로 알게 된 점이나 잘 못 알고 있었던 점을 더욱 기억에 남기기 위해 글을 꾸준히 작성 할려고 합니다.

Hive 경우 하둡 완벽 가이드와 구글링, ChatGPT 를 참고하여 운영하고 있습니다.

반드시 글을 읽어 주실 때 잘 못 말하고 있는 부분은 정정 요청 드립니다.

저의 지식에 큰 도움이 됩니다. :)

2. Bucketing 이란?

join 이 발생하는 키를 hash 처리하여 사용자가 원하는 버켓 개수 만큼 나누어 데이터를 분할하여 저장하는 방법을 말합니다.

전통적인 RDBMS 에서 hash indexing 을 하는 것과 비슷하게 보면 될 듯 합니다.

CREATE TABLE LAKE.TEST_TABLE(
	ID STRING,
    NAME STRING,
    CREATE_TIME TIMESTAMP,
    PASSWD STRING
)
PARTITIOINED BY (PART_KEY STRING)
-- Bucketing 구문은 CLUSTERED BY 구문으로 작성합니다.
CLUSTERED BY (ID) INTO 20 BUCKET
-- 정렬을 원하는 컬럼을 지정하면 해당 컬럼을 기준으로 정렬 되어 bucketing 됩니다. (Sort Merge Bucketing)
-- CLUSTERD BY (ID) SORTED BY CREATE_TIME 20 BUCKET
STORED AS PARQUET;

Bueckting 을 지정하여 저장하게 되면 HDFS 에는 아래와 같은 형태로 저장이 됩니다

TEST_TABLE
	|_ PART_KEY=VALUE
    |	|_BUECKET_HASH_KEY_1
    |	|	|_bucket_file1.parquet
    |	|	|_bucket_file2.parquet
    |	|_BUECKET_HASH_KEY_1
    |	|	|_bucket_file1.parquet
    |	|	|_bucket_file2.parquet
    |_ PART_KEY=VALUE
	|	|_BUECKET_HASH_KEY_1
    |	|	|_bucket_file1.parquet
    |	|	|_bucket_file2.parquet
    |	|_BUECKET_HASH_KEY_2
    |	|	|_bucket_file1.parquet
    |	|	|_bucket_file2.parquet
...

Hive 테이블의 Bucket 컬럼을 조회하고 싶을 때는 아래와 같이 구문을 사용하여 확인할 수 있습니다.

DESCRIBE FORMATTED TEST_TABLE;

3. Bucketing 의 이점

Bucketing 을 지정하면 아래와 같은 이점이 있습니다.

• Join 성능 향상
  Join 을 원하는 컬럼을 Hashing 하여 나눠담고, sort merge join 에 유리하도록 데이터를 미리 정렬하여 저장할 수 있으므로, Join 성능 향상에 도움이 됩니다.
  
• 데이터 샘플링 작업 속도 향상
  원하는 컬럼을 미리 Hashing 하여 나눠 담기 때문에 데이터 샘플링 시 속도 향상에 도움이 됩니다.

4. Bucket 개수 기준

Hive 에서 Bucketing 시 Bucket 개수에 대한 별도의 제한은 없습니다.

그러나 Bucket 개수가 너무 작다면 MapReduce 작업 시 Map 단계의 병렬성을 많이 기대하기 어려울 수 있고, 개수가 너무 많다면 파일 개수가 너무 많아져 HDFS 네임 노드 메모리에 부하를 많이 줄 수 있습니다.

이 때 어떤 기준으로 Clustered by 를 수행해야 할지 몰라 ChatGPT 를 사용하여 질의를 했습니다.

Q. 보통 bucket 개수를 최대 몇개 정도들 하는 편이야?

A. Hive에서 버킷(bucket)의 개수를 결정할 때 "보통"이라고 할 수 있는 정해진 숫자는 없습니다.
적절한 버킷 수는 데이터의 크기, 사용하는 하드웨어의 사양, 그리고 특정 사용 사례에 따라 크게 달라질 수 있습니다.

그러나 몇 가지 일반적인 지침을 제시할 수 있습니다:

• 작업의 병렬성: 버킷의 개수는 종종 MapReduce 작업 또는 Hive 쿼리 실행 시 생성되는 작업의 병렬성에 영향을 줍니다. 너무 적은 수의 버킷은 리소스를 충분히 활용하지 못할 수 있으며, 너무 많은 버킷은 작은 파일이 과도하게 생성되어 파일 시스템의 성능을 저하시킬 수 있습니다.

• 파일의 크기와 개수: 일반적으로 한 버킷 당 생성되는 파일의 크기가 너무 작지 않도록(예를 들어, 수백 MB 이상) 하는 것이 좋습니다. Hadoop 에코시스템에서는 작은 파일의 과도한 생성이 성능 저하의 주요 원인 중 하나이기 때문입니다.

• 하드웨어 리소스: 클러스터의 CPU 코어 수와 메모리 사양도 버킷 수를 결정할 때 고려해야 합니다. 가능한 많은 병렬 처리를 허용하면서도, 각 작업이 충분한 리소스를 할당받을 수 있도록 균형을 맞추는 것이 중요합니다.

• 경험치와 벤치마크: 다양한 버킷 수에 대한 테스트를 실시하여, 실제 데이터와 쿼리 패턴에 대해 최적의 성능을 보이는 버킷 수를 찾는 것이 좋습니다. 일반적으로, 32, 64, 128, 256과 같이 2의 거듭제곱을 사용하는 경우가 많으나, 이는 단순한 출발점일 뿐 최적의 수치는 테스트를 통해 결정해야 합니다.

실제 사용 사례에서는 수십에서 수백 개의 버킷을 사용하는 것이 일반적입니다. 그러나 특정 상황에서는 수천 개의 버킷이 필요할 수도 있으며, 이는 전적으로 데이터의 특성과 처리 요구에 의해 결정됩니다. 중요한 것은 각각의 상황에서 성능과 관리 용이성 사이에 적절한 균형을 찾는 것입니다.

5. 맺음말

Hive 에서 지원하는 Bucketing 에 대해 다시금 정리해봤습니다. 운영 시 테이블 join 이 많이 일어나게 됩니다. 이 때 성능 향상을 도모하기 위해 Bucketing 을 활용하면 더 최적화 된 운영을 할 수 있을 듯 합니다.