프로젝트를 마치며 #2. Kudu 와 Hive

본 프로젝트를 진행하면서 저장소로 kudu와 hive를 사용했다. 데이터의 특성과 각 저장소의 특성을 알맞게 연관 지어 사용했다. 그래서 이번에는 각 저장소의 특징을 정리하고자 한다.

Hive란?

Apache Hive는 광범위한 Hadoop 에코시스템에 속하는 Apache Hadoop Distributed File System(HDFS)에서 추출한 대용량 데이터세트를 읽고, 쓰고, 관리하도록 설계된 오픈 소스 데이터 웨어하우스 소프트웨어입니다.

출처는 아래 링크이고, Hive에 대해 매우 자세하게 쓰여있기 때문에 내가 추가로 쓸 필요는 없을 것 같다.

Apache Hive는 어디에 사용합니까? - Databricks

Hive 특징

1. Record 단위 데이터로 수정하거나 삭제할 수 없음
2. Partition 단위 관리 필요
3. Small File issue
4. 대용량 데이터 풀스캔에 최적화
5. HDFS에 쿼리 사용

Kudu란?

Kudu는 빠른 데이터에서 빠른 분석을 수행하기 위한 스토리지입니다. 빠른 삽입과 업데이트를 복합적으로 제공하며, 효율적인 열별 스캔으로 하나의 스토리지 계층에서 여러 개의 실시간 분석 워크로드를 실행합니다.

마찬가지로 출처는 아래 링크이고, 내용 또한 자세히 쓰여있다.

Kudu는 빠른 데이터에 빠른 분석을 실행하기 위한 스토리지입니다 | Cloudera

이미 관련 내용은 다른 곳에서 자세하게 다루었기 때문에 내가 작성하려는 내용은 이전 글과 마찬가지로 프로젝트에서 어떻게 사용하였는가, 어떤 점이 많이 힘들었는가? 에 대해서만 작성하려 한다.

Kudu 특징

1. Non-alterable
- pk(pk값도 업데이트 할 수 없다…날 힘들게 해쒀)
- partitioning
- nullable

2. Double, float, bool은 pk로 사용할 수 없다.
3. Secondaru key, Foriegn key 가 없다.
여담이지만, 데이터엔지니어 방에서 토론이 있던 주제인데, 현업에서 fk를 잘 쓰지 않는다고도 한다…
4. Impala SQL로 Insert, update, delete transaction 처리가 불가능하다.
5. Pk는 무조건 맨 앞에 위치하도록 create 해야 한다. 그렇지 않으면 에러가 뜬다.
6. 테이블 별 meta정보만 볼 수 있다. Oracle 같은 경우는 전체 테이블에 대한 정보를 볼 수 있는 테이블이 있었다. All_columns라던지…
7. Pk 지원

언제 사용하는 것이 좋을까?

그래서 특징을 기반으로 Hive는 수정이 발생되지 않는 대용량 데이터 저장소에 적합하고, Kudu는 빈번한 변경이 발생되는 데이터 저장소에 적합하다. 특히 kudu는 key를 제공하기 때문에 key기반 작업이 필요할 땐 Kudu를 사용하여야 하고, partition 기반 작업이 필요할 땐 Hive를 사용하는 것이 좋다. 때문에 테이블을 생성하기 전 해당 테이블의 용도나 목적 등을 고려하여 설계를 하는 것이 중요하다고 생각되었다. 안그러면 재생성,, 하고 데이터를 재적재하는 불상사가 일어난다.

Hive의 Internal, External Table

나는 이곳에서 external table을 처음 들어봤다. 근데 보니까 https://m.blog.naver.com/ohho7942/80048544236 (2008년 글)처럼 아주 오래전부터 있었던 개념이고, Hive에 국한된 개념도 아닌 것 같다.

우선은 Hive에서의 External Table을 보려 한다.

Internal Table의 특징은 다음과 같다.
1. HDFS 기본 위치에 저장 됨
2. HIVE INSERT만 가능
3. TRUNCATE로 데이터 삭제
4. DROP TABLE하면 HDFS까지도 삭제 됨

이에 반해, External Table의 특징은 다음과 같다.
1. Hive에 Table Meta 정보만 생성되고 실 데이터는 입력받은 경로에 저장
2. HDFS 직접 입력, HIVE INSERT 가능
3. HDFS 파일 자체를 삭제해야 함
4. Table Meta 만 삭제됨

4번이 처음에 나를 힘들게 했다.
External Table 의 개념이 없던 나는 Drop 했는데 Table이 존재한다고 재생성 및 alter가 안된 다는 오류에 극대노를 했다.

이후 알게 된 사실로, 깔끔한 삭제를 위해 external table drop을 하기 전에 아래와 같이 SET을 해줘야 했다.

alter table {Table name} set tblproperties (‘EXTERNAL’=‘FALSE’);

파일 포맷

이번 플젝을 하면서 접한 포멧은 3가지다.
Parquet, orc(Optimized Row Columnar), Snappy

1. Parquet
이 포맷은 예전에 블로그에서 Spark 할 때 다뤘던 것으로 기억한다.
- 컬럼 베이스 저장 포멧
- 블록 압축 지원 2. ORC
- 실제 컬럼 포맷으로 저장
- 컬럼 별 기본적인 통곗값들을 가짐
- RC파일 개선본
- RC파일: 바이너리 key-value 컬럼 베이스 저장에 최적화 된 포맷 I/O 가 많이 발생되는 컬럼 단위의 Aggreatation query 성능이 매우 좋음

3. Snappy
- 압축률을 낮으나, CPU를 덜 사용하고 속도가 빠름(..음 당연한 거 같기도..)
- 자주 액세스 되는 데이터에 적합