[AI] Hive Metastore

하이브 메타 스토어???  처음 들어보는 용어다ㅋㅋㅋ

용어를 구글링 해보니 

아파치 하이브(Apache Hive) 시스템에서 테이블 구조(스키마), 파티션 정보, 데이터가 저장된 물리적 위치 등 모든 '메타데이터'를 중앙에서 관리하고 저장하는 서비스로, 실제 데이터가 아닌 데이터의 '설명'을 관리하는 핵심 저장소다.

라는데 .... 뭔말인지 잘 모르겠다.

이 놈의 탄생 역사는 하둡(Hadoop)에서 시작되었다.

 

하둡도 100% 자바이기에 데이터를 분석하려면 JAVA로 코드를 짜야만 했다.
분석가들은 SQL 밖에 모르는데 하둡에 있는 데이터들을 SQL로 볼수 없을까? 라는 요구에서 시작해 등장한 것이 Hive이고, 그 핵심 구성 요소가 바로 Hive Metastore 이다.

페이스북같은 큰 기업들이 데이터를 보관하려는데 오라클은 비싸고... 상대적으로 저렴한 Hadoop에 파일을 쌓기 시작했다.

 

그랬더니 이게 무슨 파일이고.. 저건 또 뭔 파일인지 확인할 방도가 없었다.

이 때 파일은 그대로 저장소에 두되 이 파일들에 대한 정보만(Metadata) 따로 모아서 저장소 하나 만들자! 
해서 나온게 HMS(하이브메타스토어) 다.


" Schema on Read "
HMS 의 핵심 사상이다.
데이터 저장소는 따로 있고 우린 Only 논리적인 정보만 갖고 있겠단 의미다.

DB나 S3에 있는 파일들이나 데이터를 읽을 때, HMS에 있는 정보를 보고 이 데이터를 읽어와 뿌려주는 것이다.

우린 이걸 데이터 카탈로그라고 부른다.

 

✔  그럼 언제쓰는게 좋은거지?

1. 데이터의 공통 표준 포맷이 필요할 때
프로젝트 하다보면 여러 저장소 및 서버가 있다.(S3, Trino 등)
이런곳에서 데이터를 가져올 때 우린 공통화된 포맷이 필요하다. 

이때 HMS를 이용하여 통역을 할 수 있다.

이 테이블의 첫번째 컬럼은 String이고 이름은 name 이다. (Schema & SerDe 데이터 규격)
뭐 이런 내용의 장부같은걸 만들어둔 후 트리노같은 애들이 읽을때, 이 장부를 보고 해석을 한다.

그리고 이 데이터들에 접근할때 쓰는 표준 프로토콜이 있다. Thrift라는 통신 규약이다. 
이걸 통해 알아들을 수 있는 언어로 번역해준다.

2. 여기저기 널브러진 파일 데이터들을 DB 처럼 쓰고 싶을 때
실제로 저장소에 있는건 수만개의 파일 조각들(.parquet) 이지만 깔끔하게 SQL로 조회하고자 할 때,
이걸 묶어주는 놈이 HMS다.

데이터의 동네(Location)와 데이터의 속성(Table Properties)를 표 형태로 갖고 있다 보면 된다.
이 정보들이 합쳐져서 SQL 테이블인거 마냥 쓸 수 있다.


3. 대규모 파티셔닝이 필요할 때
1과 연결되는 부분인데 
여러 엔진(서버)에서 파일들을 갖고 와야 할때 아까 표준화된 규격으로 가져온다고 했었다.
이 뿐만 아니라 수많은 데이터들중 원하는 것만 광속으로 찾아낸다.

어? 그럼 뭐야? 색인(Indexing)이되는건가? 싶은데

색인(Indexing)이랑은 비슷하지만 다른 개념이다.

* 색인 
- 전통적인 DB의 색인은 약간 책 맨뒷장에 있는 찾아보기 개념이다.
- 조건에 해당하는 데이터가 50페이지, 100페이지 이런곳에 있다는 표기이다.
> 찾아보기도 많아질수록 너무 커져서 관리가 힘들다.

* 파티셔닝
- 물리적인 방 나누기
- 데이터를 아예 조건으로 쪼개서 폴더(Directory) 단위로 쪼개서 저장한다.
> 조건이 들어오면 그 조건에 대한 파티션만 봄

색인은 "어디 있는지 찾아주는 것"이고, 파티셔닝은 "상관없는 걸 아예 안 읽게 버리는 것" 이다.


* 여기서 잠깐!
그럼 ES(엘라스틱서치)랑 뭐가 다른거지? 언제 써야 하지? 싶어 구분한다.

엘라스틱 서치는

 

"니가 뭘 물어볼지 이미 난 다알고있다!!! 왜냐면 그 답은 미리 다 색인이 되어있기 때문이지!!"

 

요 사상이기에 특정키워드, 문구가 포함된 단어를 찾는 속도가 아주 압도적이다.
하지만 이 단어를 갖고 더해봐 식의 연산이 들어가는 순간 아주 성능이 뚝 떨어진다.

그에 비해 HMS는 

 

"니가 뭘 물어볼지 모르니 대충 파티션만 나눠놓고 그 때 처리할게..."

사상이기 때문에 통계,분석, 조인에 아주 특화되어있다.
분석한 데이터를 가지고 새로운 가공데이터를 만드는거에 적합한 구조로 되어있다.

상황에 따라 적합하게 병행해서 쓰면 되겠다.

✔ 그럼 단점은 없는걸까? 지양해야 하는 경우는?

 

이 세상에 단점이 없는 기술은 없다.
물론 HMS도 단점이 있다.

1. 치명적인 단점이 Schema on Read 다.
ㅋㅋㅋ 아니 핵심사상이 단점이라니.. ㄱ-ㅋㅋㅋㅋㅋ

저장할 때 모든 데이터 유실없이 프리패쓰 되는게 장점이지만,
읽을때 포맷이 조금이라도 다르다면 에러가 터져버린다.


2. 성능저하
파티셔닝을 너무 많이 하면 HMS가 파일이 어딨는지 찾는 시간이 굉장히 오래걸린다.(1개 찾는데 10만건일 경우 한참 뒤짐)

3. 복구 불가
만약 내가 100건을 저장하는 과정에서 90건쯤에 에러가 나서 멈춰 버린경우
우리가 보통 DB에 저장할땐 트랜젝션으로 복구가 되지만 
HMS는 이 잘못된 90건의 데이터를 그냥 내버려둔다. (쓰레기 데이터가 걍 들어가있는 상태)
이렇게 되면 추후 통계 조회를 할때 잘못된 데이터도 읽어버리기 때문에 정합성에 문제가 생긴다.

 

아 그럼 이건뭐... 데이터좀 틀려도 되는곳에 써야겠네?

맞다, 보통 단순로그를 수집하거나 이미 하둡을 쓰고 있을경우 HMS를 쓰면 아주좋다.

하지만 이 단점들을 보완한 기능이 나왔으니!!! 두둥....

 

그게 바로 아파치 아이스버그(Apache Iceberg) 이다.

 

 

✅ 아이스 버그

아이스 버그는 HMS를 대체하는 서비스는 아니고 이 단점 때문에 개발된 플러그인 이다.
HMS를 쓸 때 iceberg-*.jar 라이브러리를 포함시키면 된다.

1. Commit 도입
에러없이 모든 데이터가 100건 다 명확하게 저장해야 커밋을 한다. (ACID 트랜잭션 지원)

2. Manifest 도입
매니페스트라는 파일 목록표를 만들어 정보를 저장해 둔다.
HMS가 파티셔닝 된 폴더를 하나하나 뒤질 때 아이스버그는 이놈을 통해 목록표 하나만 읽어 어디있는지 바로 조회해온다.
O(N) 작업을 O(1)로 단축시킨다.

3. 복구 가능
스냅샷을 저장을 통해 백업이 가능하다.

4. 저장할 때 빡시게 검사함
저장하려는 데이터와 실제 저장소 포맷이 다를 경우 에러를 뱉어 버린다.
따라서 검증된 데이터만 저장소에 들어가게 된다.
만약 저장소 컬럼의 이름을 바꾼다고 해도 아이스버그는 주소값으로 관리 하기에 상관없다.