초보자라면 HDFS 헷갈리는 기본 개념 정리 (2) - Kudu

온프렘 HDFS에 있는 데이터를 클라우드에 구축된 HDFS로 이관하는 작업을 진행했었다. 이때 단순 parquet, textfile 등으로 분산 저장된 테이블(managed table 이든, external table이든)은 이관이 단순했는데 Kudu는 몇가지 절차가 더 필요했다. Kudu가 도대체 뭐길래 계속 거론되는지, 조금은 성가시게 하는지 궁금했다.

 

그래서 Kudu는 Hadoop EcoSystem에서 또 어떤 역할을 담당하고 있는지, Hive Table을 잘 쓰고 있는 기업에서 왜 Kudu Table 을 도입하려 하는지 알아보고자 한다.

 

먼저 Hive Table에 대한 기본적인 개념을 알아야 비교할 수 있다.

 

 

Hive Table

Hive Table은 HDFS와 같은 분산 저장 시스템에 흩어진 데이터를 우리에게 친숙한 테이블 형태로 관리한다. 파일과 디렉터리 구조, 파티션 정보에 관한 메타정보를 이용하여 table을 관리할 수 있기 때문에 해당 메타정보들을 관리하는 것이다. 또한 HiveQL을 통해 SQL 스럽게 쿼리할 수도 있다. 

 

하지만 아키텍쳐 상으로 update, delete가 힘들다. 또한 느리다는 점에서 용량이 큰 테이블에 관해서는 더 빠른 아키텍쳐에 대한 수요가 있었다.

 

(여담으론, 요즘 hive는 ACID transation 관련된 설정들을 true로 설정해주면 update/delete가 가능하긴 한데, impala가 해당 옵션을 지원해주질 않는다. 이전 글에서 작성했듯이 query를 할 때 속도 차이 때문에 주로 impala를 사용하기 때문에 impala가 지원해주지 않으면.. )

 

 

Kudu

이를 개선하기 위해 Kudu table을 사용하곤 한다. 필요성에 대해선 위에서 다뤘고 아래에선 차이점을 이해하고 사용법을 알아보자

• Column 기반 스토리지
• PK가 필수
• 데이터를 local disk에 저장

필자가 느끼기에 가장 Kudu의 핵심은 위의 세가지이다.

• Column 기반으로 하기 때문에 row 기반 기존 테이블보다 읽을 때에 속도가 빨라질 수 있으며 저장할 때에도 압축률이 좋아진다. 또한 스키마 변경이 유연하다. 컬럼 추가/타입 변경이 가능하다. (hive는 타입 변경을 하려면 테이블을 새로 생성해야한다)
• PK가 필수로 필요하다. 이를 기반으로 update/delete 작업들을 수행할 수 있기 때문이다. 또한 PK로 정렬될 수 있기 떄문에 속도 개선의 효과가 있음을 알 수 있다.
• 데이터를 Tablet Server에 직접 저장하고 관리한다. HDFS에 저장되어있지 않기 때문에 데이터 이관을 할 때 조금 성가시게 했다는걸 알 수 있다.

                   - 다수의 table이 hive table이었기 때문에 해당 table은 distcp로 해결하였고 kudu는 따로 처리해주었다.

 

 

사용법

일반적으로 kudu를 자체적으로 사용하진 않고 impala를 통해서 사용한다.

hive table과 동일하게 managed, external table 둘다 생성할 수 있으며 external table의 경우 삭제할 때 impala/kudu간의 매핑만 제거한다.

 

주석에 중요 내용들을 작성해두었다.

 

1. 생성하기

CREATE TABLE table_name ( #external이라고 명시하지 않으면 managed table이 생성된다.
   column1 datatype1 [DEFAULT value1],
   column2 datatype2 [DEFAULT value2],
   ...
   PRIMARY KEY (key_column1, key_column2, ...) #위에서 설명했듯이 PK는 필수이다. 여러개를 지정할 수 있다.
)
PARTITION BY RANGE (partition_column) ( #kudu는 기본적으로 range partitioning을 사용한다.
   PARTITION p0 VALUES LESS THAN (value0),
   PARTITION p1 VALUES LESS THAN (value1),
   ...
)
STORED AS KUDU # 당연히 필 수 !
TBLPROPERTIES(
   'kudu.master_addresses'='kudu_master_address1,kudu_master_address2', #보통은 생략하고 만들어주면 되는데
   									#external table을 생성할 땐 데이터가 있는 daemon 주소를 넣어준다.
   'kudu.table_name'='kudu_table_name', #kudu table은 대소문자를 구별하니 주의할 것, 역시 생략 가능
   ...
)

 

 

2. 데이터 추가하기

INSERT INTO TABLE table_name VALUES (value1, value2, ...);

 

3. 컬럼 업데이트하기

UPDATE table_name SET column1 = value1, column2 = value2 WHERE condition;

4. 데이터 삭제하기

DELETE FROM table_name WHERE condition;

5. 스키마 변경하기 - 컬럼 추가 / 데이터 타입 변경

ALTER TABLE table_name ADD COLUMN column_name data_type;
ALTER TABLE table_name ADD COLUMNS (column_name data_type, );


ALTER TABLE table_name ALTER COLUMN column_name SET DATA TYPE data_type;

6. table 삭제

DROP TABLE table_name;

 

 

마지막으로 내가 다루고 있는 테이블이 kudu table인지 궁금하다면 kudu의 master server UI로 들어가서 Tables을 눌러보면 kudu table들이 나열되어있다. 이를 통해 확인할 수도 있고 show create table 구문으로 쿼리하여 stored as kudu가 있으면 kudu table이구나~ 할수도 있다. 직접 HDFS 저장소를 뒤지는 타입이라면 해당 테이블 디렉토리만 있고 안에 데이터는 없는데 테이블 count는 0이 아니다? 이럴 땐 kudu table일 거란 의심을 해 볼 수 있다.(external hive table 일 수도 있다)

 

 

 

아키텍처를 비롯한 빠진 내용들이 있는데.. 보다 실질적인 내용으로 채우고자 했더니 몇몇 내용들은 빠지게 되었다. 앞으로도 이 시리즈는 이런 식으로 운영될 듯 하다.

 

 

 

+추가)

kudu table은 일반적으로 impala로만 쿼리가 가능한데 metadata 자체는 hive metastore에서 관리하고 있긴 하다. 그래서 meta data 관련 쿼리는 hive에서도 처리가 가능하다.