hive_base

Hive

- https://www.simplilearn.com/tutorials/hadoop-tutorial/hive
하둡 기반의 데이터 웨어하우징 프레임워크로, 빠른 속도로 성장하는 페이스북의 소셜 네트워크에서 매일같이 생산되는 대량의 데이터를 관리하고 학습하기 위해 개발되었습니다.
하이브에서 레코드 단위 갱신(record-level update), 삽입, 삭제를 할 수 없긴 하지만 쿼리로 새 테이블을 만들 수 있고 쿼리 결과를 파일로 남길 수도 있습니다.
SQL은 비즈니스 인텔리전스 분야의 도구에서 사용되는 공통 언어(lingua franca)이기 때문에(예를 들어 ODBC는 공통 인터페이스) 해당 분야의 상용 제품과 쉽게 통합할 수 있습니다.
Hive는 데이터양에 좌우되지 않는 쿼리 엔진으로 다음과 같은 특징이 있습니다.
- 높은 확장성과 내결함성을 목표로 설계되었습니다.
- 대규모 배치 처리를 꾸준히 실행합니다.
- 텍스트 데이터를 가공하거나 열 지향 스토리지를 만드는 등의 무거운 처리는 아무래도 처리 시간이 길어지는 경향이 있어서 Hive에서 실행하는것이 적합합니다.
- 분산시스템의 동향은 서서히 인 메모리의 데이터 처리로 옮겨 가고 있지만, Hive는 앞으로도 데이터양에 좌우되지 않는 쿼리 엔진으로 계속 이용될 것입니다.
한계
- Hive는 온라인 트랜잭션 처리(OLTP)용으로 설계되지 않았으며 온라인 분석 처리에만 사용됩니다.
- Hive는 데이터 덮어쓰기 또는 파악을 지원하지만 업데이트 및 삭제는 지원하지 않습니다.
- Hive에서는 하위 쿼리가 지원되지 않습니다.
로깅
- 하이브의 에러 로그는 로컬 파일시스템의 ${java.io.tmpdir}/${user.name}/hive.log에서 찾을 수 있음, 환경 설정 문제나 다른 유형의 에러를 진단할 때 매우 유용합니다.
- 로깅 설정 파일은 conf/hive-log4j.properties고, 로그 수준과 다른 로깅 관련 설정을 변경하고 싶으면 이 파일을 변경하면 됩니다.

읽기 스키마와 쓰기 스키마의 비교

- https://www.oreilly.com/content/hadoop-what-you-need-to-know/
쓰기 스키마(schema on write) - 전통적인 데이터베이스에서 테이블의 스키마는 데이터를 로드하는 시점에 검증됩니다. 로드 중인 데이터가 스키마에 부합되지 않으면 해당 데이터를 거부합니다. 데이버테이스 쓰는 시점에 떼이터의 스키마를 검증하기 때문입니다.
읽기 스키마(schema on read) - 하이브는 로드 시점이 아니라 쿼리를 실행할 때 그 데이터를 검증합니다.
두 방식은 서로 상충 관계(trade-off)로 읽기 스키마는 데이터베이스 내부 형식으로 데이터를 읽거나 파싱하거나 디스크에 직렬화할 필요가 없기 때문에 초기에 매우 빠른 속도로 데이터를 로드할 수 있습니다. 로드 조작을 위해서는 단순히 파일을 복사하거나 이동하기만 하면 됩니다.
쓰기 스키마는 데이터베이스가 컬럼 단위의 데이터 색인과 압축을 제공하기 때문에 더 빠르게 쿼리를 수행할 수 있음, 상대적으로 데이터베이스에 데이터를 로드하는 시간은 더 오래 걸림, 더욱이 쿼리가 정해지지 않아서 로드 시점에 스키마를 지정할 수 없고 색인도 적용할 수 없는 경우도 빈번합니다.

갱신, 트랜잭션, 색인

실제 테이블의 갱신은 아예 새로운 테이블을 만들어 데이터를 변환하는 방식으로 구현된다는 점이며 대량의 데이터셋을 대상으로 실행되는 데이터웨어하우징 애플리케이션에서 작동하는 방식
HDFS 기존 파일의 갱신을 지원하지 않기 때문에 삽입, 변경, 삭제로 인한 갱신 내역은 별도의 작은 델타 파일에 저장됩니다. 델타 파일은 메타스토어에서 백그라운드로 실행되는 맵리듀스 잡에 의해 기존 테이블과 주기적으로 병합됩니다.
테이블과 파티션 수준의 잠금을 지원하며 잠금은 특정 프로세스가 테이블을 읽는 도중에 다른 프로세스가 테이블을 삭제하는 것을 방지할 수 있습니다. 잠금은 주키퍼에 의해 투명하게 관리되므로 사용자가 직접 주키퍼를 조작하여 잠금을 적용하거나 해제할 수는 없습니다.
하이브는 특정한 경우에 쿼리의 속도를 높일 수 있는 색인을 지원하는데 콤패트(compact) 색인과 비트맵(bitmap) 색인을 지원합니다. 색인은 플러그인 방식으로 구현되었기 때문에 다른 방식의 색인도 추가할 수 있습니다.
콤팩트 색인은 각 값을 파일 오프셋이 아닌 HDFS 블록 넘버로 저장합니다. 디스크 공간을 많이 차지 않으면서도 인접한 행 사이에 분포된 특정 컬럼에 대한 값을 색인하는 데 매우 효율적입니다.
비트맵 색인은 특정 값이 출현하는 행을 효율적으로 저장하기 위해 압축된 비트셋(bitset)을 사용합니다.

파티션과 버킷

- https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.4.0/bk_performance_tuning/content/hive_perf_best_pract_design_data_stg_smartly.html
테이블을 파티션으로 구조화할 수 있습니다. 파티션이란 테이블의 데이터를 날짜와 같은 파티션 컬럼의 값을 기반으로 큰 단위(coarse-grained)로 분할하는 방식이며 파티션을 사용하면 데이터의 일부를 매우 빠르게 질의할 수 있습니다.
테이블과 파티션은 효율적인 쿼리를 위해 데이터에 추가된 구조인 버킷으로 더욱 세분화 될 수 있습니다. 사용자 ID를 기준으로 버킷을 생성하면 전체 사용자 중에서 무작위 데이터 샘플을 뽑아 사용자가 작성한 쿼리가 제대로 실행되는지 빠르게 평가할 수 있습니다.
파티션
- 테이블은 다중 차원으로 파티션될수 있습니다. 예를 들어 먼저 날짜를 기준으로 로그를 파티션하고 그다음에 지역별로 효율적인 쿼리를 수행하기 위해 각 날짜별 파티션에 국가별 서브파티션을 추가할 수 있습니다.
버킷
- 테이블을 버킷으로 구조화하는 이유 두 가지
  - 매우 효율적인 쿼리가 가능하기 때문, 버킷팅은 테이블에 대한 추가 구조를 부여하고, 하이브는 어떤 쿼리를 수행할 때 이 추가 구조를 이용할 수 있습니다. 특히 동일한 컬럼(조인할 컬럼)에 대한 버킷을 가진 두 테이블을 조인할 때 맵 조인을 구현하면 매우 효율적입니다.
  - 효율적인 샘플링에 유리, 매우 큰 데이터셋을 대상으로 개발하거나 개선하는 과정에서 데이터셋의 일부만을 쿼리를 수행할 수 있으면 매우 편리합니다.

HCatalog

- https://www.oreilly.com/library/view/hadoop-application-architectures/9781491910313/ch01.html
Hive 외부에서 Hive 메타스토어를 사용할 수 있도록 HCatalog라는 별도의 프로젝트가 시작되었고 HCatalog는 Hive의 일부이며 다른 도구(예: Pig 및 MapReduce)가 Hive 메타스토어와 통합할 수 있도록 합니다.
HCatalog는 하둡이 모든 도구에서 사용할 수 있는 하이브 메타스토어를 만들고, 맵리듀스와 피그의 커넥터를 제공합니다. 하둡 도구를 사용하여 하이브 웨어하우스의 데이터를 읽고 쓸 수 있습니다. 하이브를 사용하지 않는 사용자를 위한 하이브 DDL로 메타스토어를 다루는 명령행 도구를 제공하고 알림 서비스도 제공합니다.
메타데이터 저장소를 공유하면 사용자가 도구 간에 손쉽게 데이터를 공유할 수 있습니다. 일반적으로 피그나 맵리듀스로 데이터를 올리고 나면 정규화한 다음 하이브로 분석합니다. 분석 쿼리를 위해 하이브를 사용하던 사용자는 ETL 처리를 하거나 데이터 모델을 구축할 때 피그를 사용합니다.
- https://cwiki.apache.org/confluence/display/hive/hcatalog+usinghcat
HCatalog는 SerDe(serializer-deserializer)를 작성할 수 있는 모든 형식의 파일 읽기 및 쓰기를 지원합니다. 기본적으로 HCatalog는 RCFile, CSV, JSON, SequenceFile 및 ORC 파일 형식을 지원합니다. 사용자 지정 형식을 사용하려면 InputFormat, OutputFormat 및 SerDe를 제공해야 합니다.

Reference

https://www.amazon.com/Programming-Hive-Warehouse-Language-Hadoop/dp/1449319335
https://www.amazon.com/Hadoop-Definitive-Guide-Tom-White/dp/1449311520

PreviousHive NextHive Architecture

Last updated 1 year ago

Hive

https://www.simplilearn.com/tutorials/hadoop-tutorial/hive

하둡 기반의 데이터 웨어하우징 프레임워크로, 빠른 속도로 성장하는 페이스북의 소셜 네트워크에서 매일같이 생산되는 대량의 데이터를 관리하고 학습하기 위해 개발되었습니다.

하이브에서 레코드 단위 갱신(record-level update), 삽입, 삭제를 할 수 없긴 하지만 쿼리로 새 테이블을 만들 수 있고 쿼리 결과를 파일로 남길 수도 있습니다.

SQL은 비즈니스 인텔리전스 분야의 도구에서 사용되는 공통 언어(lingua franca)이기 때문에(예를 들어 ODBC는 공통 인터페이스) 해당 분야의 상용 제품과 쉽게 통합할 수 있습니다.

Hive는 데이터양에 좌우되지 않는 쿼리 엔진으로 다음과 같은 특징이 있습니다.

높은 확장성과 내결함성을 목표로 설계되었습니다.
대규모 배치 처리를 꾸준히 실행합니다.
텍스트 데이터를 가공하거나 열 지향 스토리지를 만드는 등의 무거운 처리는 아무래도 처리 시간이 길어지는 경향이 있어서 Hive에서 실행하는것이 적합합니다.
분산시스템의 동향은 서서히 인 메모리의 데이터 처리로 옮겨 가고 있지만, Hive는 앞으로도 데이터양에 좌우되지 않는 쿼리 엔진으로 계속 이용될 것입니다.

한계

Hive는 온라인 트랜잭션 처리(OLTP)용으로 설계되지 않았으며 온라인 분석 처리에만 사용됩니다.
Hive는 데이터 덮어쓰기 또는 파악을 지원하지만 업데이트 및 삭제는 지원하지 않습니다.
Hive에서는 하위 쿼리가 지원되지 않습니다.

로깅

하이브의 에러 로그는 로컬 파일시스템의 ${java.io.tmpdir}/${user.name}/hive.log에서 찾을 수 있음, 환경 설정 문제나 다른 유형의 에러를 진단할 때 매우 유용합니다.
로깅 설정 파일은 conf/hive-log4j.properties고, 로그 수준과 다른 로깅 관련 설정을 변경하고 싶으면 이 파일을 변경하면 됩니다.

읽기 스키마와 쓰기 스키마의 비교

https://www.oreilly.com/content/hadoop-what-you-need-to-know/

쓰기 스키마(schema on write) - 전통적인 데이터베이스에서 테이블의 스키마는 데이터를 로드하는 시점에 검증됩니다. 로드 중인 데이터가 스키마에 부합되지 않으면 해당 데이터를 거부합니다. 데이버테이스 쓰는 시점에 떼이터의 스키마를 검증하기 때문입니다.

읽기 스키마(schema on read) - 하이브는 로드 시점이 아니라 쿼리를 실행할 때 그 데이터를 검증합니다.

두 방식은 서로 상충 관계(trade-off)로 읽기 스키마는 데이터베이스 내부 형식으로 데이터를 읽거나 파싱하거나 디스크에 직렬화할 필요가 없기 때문에 초기에 매우 빠른 속도로 데이터를 로드할 수 있습니다. 로드 조작을 위해서는 단순히 파일을 복사하거나 이동하기만 하면 됩니다.

쓰기 스키마는 데이터베이스가 컬럼 단위의 데이터 색인과 압축을 제공하기 때문에 더 빠르게 쿼리를 수행할 수 있음, 상대적으로 데이터베이스에 데이터를 로드하는 시간은 더 오래 걸림, 더욱이 쿼리가 정해지지 않아서 로드 시점에 스키마를 지정할 수 없고 색인도 적용할 수 없는 경우도 빈번합니다.

갱신, 트랜잭션, 색인

실제 테이블의 갱신은 아예 새로운 테이블을 만들어 데이터를 변환하는 방식으로 구현된다는 점이며 대량의 데이터셋을 대상으로 실행되는 데이터웨어하우징 애플리케이션에서 작동하는 방식

HDFS 기존 파일의 갱신을 지원하지 않기 때문에 삽입, 변경, 삭제로 인한 갱신 내역은 별도의 작은 델타 파일에 저장됩니다. 델타 파일은 메타스토어에서 백그라운드로 실행되는 맵리듀스 잡에 의해 기존 테이블과 주기적으로 병합됩니다.

테이블과 파티션 수준의 잠금을 지원하며 잠금은 특정 프로세스가 테이블을 읽는 도중에 다른 프로세스가 테이블을 삭제하는 것을 방지할 수 있습니다. 잠금은 주키퍼에 의해 투명하게 관리되므로 사용자가 직접 주키퍼를 조작하여 잠금을 적용하거나 해제할 수는 없습니다.

하이브는 특정한 경우에 쿼리의 속도를 높일 수 있는 색인을 지원하는데 콤패트(compact) 색인과 비트맵(bitmap) 색인을 지원합니다. 색인은 플러그인 방식으로 구현되었기 때문에 다른 방식의 색인도 추가할 수 있습니다.

콤팩트 색인은 각 값을 파일 오프셋이 아닌 HDFS 블록 넘버로 저장합니다. 디스크 공간을 많이 차지 않으면서도 인접한 행 사이에 분포된 특정 컬럼에 대한 값을 색인하는 데 매우 효율적입니다.

비트맵 색인은 특정 값이 출현하는 행을 효율적으로 저장하기 위해 압축된 비트셋(bitset)을 사용합니다.

파티션과 버킷

https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.4.0/bk_performance_tuning/content/hive_perf_best_pract_design_data_stg_smartly.html

테이블을 파티션으로 구조화할 수 있습니다. 파티션이란 테이블의 데이터를 날짜와 같은 파티션 컬럼의 값을 기반으로 큰 단위(coarse-grained)로 분할하는 방식이며 파티션을 사용하면 데이터의 일부를 매우 빠르게 질의할 수 있습니다.

테이블과 파티션은 효율적인 쿼리를 위해 데이터에 추가된 구조인 버킷으로 더욱 세분화 될 수 있습니다. 사용자 ID를 기준으로 버킷을 생성하면 전체 사용자 중에서 무작위 데이터 샘플을 뽑아 사용자가 작성한 쿼리가 제대로 실행되는지 빠르게 평가할 수 있습니다.

파티션

테이블은 다중 차원으로 파티션될수 있습니다. 예를 들어 먼저 날짜를 기준으로 로그를 파티션하고 그다음에 지역별로 효율적인 쿼리를 수행하기 위해 각 날짜별 파티션에 국가별 서브파티션을 추가할 수 있습니다.

버킷

테이블을 버킷으로 구조화하는 이유 두 가지
- 매우 효율적인 쿼리가 가능하기 때문, 버킷팅은 테이블에 대한 추가 구조를 부여하고, 하이브는 어떤 쿼리를 수행할 때 이 추가 구조를 이용할 수 있습니다. 특히 동일한 컬럼(조인할 컬럼)에 대한 버킷을 가진 두 테이블을 조인할 때 맵 조인을 구현하면 매우 효율적입니다.
- 효율적인 샘플링에 유리, 매우 큰 데이터셋을 대상으로 개발하거나 개선하는 과정에서 데이터셋의 일부만을 쿼리를 수행할 수 있으면 매우 편리합니다.

HCatalog

https://www.oreilly.com/library/view/hadoop-application-architectures/9781491910313/ch01.html

Hive 외부에서 Hive 메타스토어를 사용할 수 있도록 HCatalog라는 별도의 프로젝트가 시작되었고 HCatalog는 Hive의 일부이며 다른 도구(예: Pig 및 MapReduce)가 Hive 메타스토어와 통합할 수 있도록 합니다.

HCatalog는 하둡이 모든 도구에서 사용할 수 있는 하이브 메타스토어를 만들고, 맵리듀스와 피그의 커넥터를 제공합니다. 하둡 도구를 사용하여 하이브 웨어하우스의 데이터를 읽고 쓸 수 있습니다. 하이브를 사용하지 않는 사용자를 위한 하이브 DDL로 메타스토어를 다루는 명령행 도구를 제공하고 알림 서비스도 제공합니다.

메타데이터 저장소를 공유하면 사용자가 도구 간에 손쉽게 데이터를 공유할 수 있습니다. 일반적으로 피그나 맵리듀스로 데이터를 올리고 나면 정규화한 다음 하이브로 분석합니다. 분석 쿼리를 위해 하이브를 사용하던 사용자는 ETL 처리를 하거나 데이터 모델을 구축할 때 피그를 사용합니다.

https://cwiki.apache.org/confluence/display/hive/hcatalog+usinghcat

HCatalog는 SerDe(serializer-deserializer)를 작성할 수 있는 모든 형식의 파일 읽기 및 쓰기를 지원합니다. 기본적으로 HCatalog는 RCFile, CSV, JSON, SequenceFile 및 ORC 파일 형식을 지원합니다. 사용자 지정 형식을 사용하려면 InputFormat, OutputFormat 및 SerDe를 제공해야 합니다.