실무에 사용한 데이터 엔지니어링 스킬에 대한 정리내용입니다.
개인적인 기록을 위해 작성하였습니다.
https://github.com/mjs1995/muse-data-engineer/blob/main/doc/Batch%20Processing/hive_base.md
GitHub - mjs1995/muse-data-engineer: 데이터 엔지니어로 성장하기
데이터 엔지니어로 성장하기. Contribute to mjs1995/muse-data-engineer development by creating an account on GitHub.
github.com
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고, 로그 수준과 다른 로깅 관련 설정을 변경하고 싶으면 이 파일을 변경하면 됩니다.
읽기 스키마와 쓰기 스키마의 비교
- 쓰기 스키마(schema on write) - 전통적인 데이터베이스에서 테이블의 스키마는 데이터를 로드하는 시점에 검증됩니다. 로드 중인 데이터가 스키마에 부합되지 않으면 해당 데이터를 거부합니다. 데이버테이스 쓰는 시점에 데이터의 스키마를 검증하기 때문입니다.
- 읽기 스키마(schema on read) - 하이브는 로드 시점이 아니라 쿼리를 실행할 때 그 데이터를 검증합니다.
- 두 방식은 서로 상충 관계(trade-off)로 읽기 스키마는 데이터베이스 내부 형식으로 데이터를 읽거나 파싱하거나 디스크에 직렬화할 필요가 없기 때문에 초기에 매우 빠른 속도로 데이터를 로드할 수 있습니다. 로드 조작을 위해서는 단순히 파일을 복사하거나 이동하기만 하면 됩니다.
- 쓰기 스키마는 데이터베이스가 컬럼 단위의 데이터 색인과 압축을 제공하기 때문에 더 빠르게 쿼리를 수행할 수 있음, 상대적으로 데이터베이스에 데이터를 로드하는 시간은 더 오래 걸림, 더욱이 쿼리가 정해지지 않아서 로드 시점에 스키마를 지정할 수 없고 색인도 적용할 수 없는 경우도 빈번합니다.
갱신, 트랜잭션, 색인
- 실제 테이블의 갱신은 아예 새로운 테이블을 만들어 데이터를 변환하는 방식으로 구현된다는 점이며 대량의 데이터셋을 대상으로 실행되는 데이터웨어하우징 애플리케이션에서 작동하는 방식
- HDFS 기존 파일의 갱신을 지원하지 않기 때문에 삽입, 변경, 삭제로 인한 갱신 내역은 별도의 작은 델타 파일에 저장됩니다. 델타 파일은 메타스토어에서 백그라운드로 실행되는 맵리듀스 잡에 의해 기존 테이블과 주기적으로 병합됩니다.
- 테이블과 파티션 수준의 잠금을 지원하며 잠금은 특정 프로세스가 테이블을 읽는 도중에 다른 프로세스가 테이블을 삭제하는 것을 방지할 수 있습니다. 잠금은 주키퍼에 의해 투명하게 관리되므로 사용자가 직접 주키퍼를 조작하여 잠금을 적용하거나 해제할 수는 없습니다.
- 하이브는 특정한 경우에 쿼리의 속도를 높일 수 있는 색인을 지원하는데 콤패트(compact) 색인과 비트맵(bitmap) 색인을 지원합니다. 색인은 플러그인 방식으로 구현되었기 때문에 다른 방식의 색인도 추가할 수 있습니다.
- 콤팩트 색인은 각 값을 파일 오프셋이 아닌 HDFS 블록 넘버로 저장합니다. 디스크 공간을 많이 차지 않으면서도 인접한 행 사이에 분포된 특정 칼럼에 대한 값을 색인하는 데 매우 효율적입니다.
- 비트맵 색인은 특정 값이 출현하는 행을 효율적으로 저장하기 위해 압축된 비트셋(bitset)을 사용합니다.
파티션과 버킷
- 테이블을 파티션으로 구조화할 수 있습니다. 파티션이란 테이블의 데이터를 날짜와 같은 파티션 컬럼의 값을 기반으로 큰 단위(coarse-grained)로 분할하는 방식이며 파티션을 사용하면 데이터의 일부를 매우 빠르게 질의할 수 있습니다.
- 테이블과 파티션은 효율적인 쿼리를 위해 데이터에 추가된 구조인 버킷으로 더욱 세분화 될 수 있습니다. 사용자 ID를 기준으로 버킷을 생성하면 전체 사용자 중에서 무작위 데이터 샘플을 뽑아 사용자가 작성한 쿼리가 제대로 실행되는지 빠르게 평가할 수 있습니다.
- 파티션
- 테이블은 다중 차원으로 파티션될수 있습니다. 예를 들어 먼저 날짜를 기준으로 로그를 파티션 하고 그다음에 지역별로 효율적인 쿼리를 수행하기 위해 각 날짜별 파티션에 국가별 서브파티션을 추가할 수 있습니다.
- 버킷
- 테이블을 버킷으로 구조화하는 이유 두 가지
- 매우 효율적인 쿼리가 가능하기 때문, 버킷팅은 테이블에 대한 추가 구조를 부여하고, 하이브는 어떤 쿼리를 수행할 때 이 추가 구조를 이용할 수 있습니다. 특히 동일한 칼럼(조인할 칼럼)에 대한 버킷을 가진 두 테이블을 조인할 때 맵 조인을 구현하면 매우 효율적입니다.
- 효율적인 샘플링에 유리, 매우 큰 데이터셋을 대상으로 개발하거나 개선하는 과정에서 데이터셋의 일부만을 쿼리를 수행할 수 있으면 매우 편리합니다.
- 테이블을 버킷으로 구조화하는 이유 두 가지
HCatalog
- Hive 외부에서 Hive 메타스토어를 사용할 수 있도록 HCatalog라는 별도의 프로젝트가 시작되었고 HCatalog는 Hive의 일부이며 다른 도구(예: Pig 및 MapReduce)가 Hive 메타스토어와 통합할 수 있도록 합니다.
- HCatalog는 하둡이 모든 도구에서 사용할 수 있는 하이브 메타스토어를 만들고, 맵리듀스와 피그의 커넥터를 제공합니다. 하둡 도구를 사용하여 하이브 웨어하우스의 데이터를 읽고 쓸 수 있습니다. 하이브를 사용하지 않는 사용자를 위한 하이브 DDL로 메타스토어를 다루는 명령행 도구를 제공하고 알림 서비스도 제공합니다.
- 메타데이터 저장소를 공유하면 사용자가 도구 간에 손쉽게 데이터를 공유할 수 있습니다. 일반적으로 피그나 맵리듀스로 데이터를 올리고 나면 정규화한 다음 하이브로 분석합니다. 분석 쿼리를 위해 하이브를 사용하던 사용자는 ETL 처리를 하거나 데이터 모델을 구축할 때 피그를 사용합니다.
- HCatalog는 SerDe(serializer-deserializer)를 작성할 수 있는 모든 형식의 파일 읽기 및 쓰기를 지원합니다. 기본적으로 HCatalog는 RCFile, CSV, JSON, SequenceFile 및 ORC 파일 형식을 지원합니다. 사용자 지정 형식을 사용하려면 InputFormat, OutputFormat 및 SerDe를 제공해야 합니다.
Reference
'Data Engeneering > hive' 카테고리의 다른 글
| hiveQL (0) | 2023.03.01 |
|---|---|
| hive 저장 포맷 (0) | 2023.03.01 |
| hive 아키텍처 (0) | 2023.02.28 |
