Hudi에는 RDBMS와 비슷하게 인덱스가 존재한다. 다만 RDBMS의 index는 읽기성능을 위해 최적화 되어있다면, hudi는 Read & Write 성능을 위하여 인덱스를 사용한다.
예를 들어 인덱스는 hudi key(레코드 키 + 파티션 경로)를 파일 ID에 매핑하여, 데이터가 업데이트 될때, 어떤 파일을 업데이트 해야하는지 빠르게 찾아내어 write 성능을 높인다.
위 이미지에서 흰색 네모는 base file을, 노란색 네모는 update할 데이터를 나타낸다.(Merge On Read의 Delta file 이라고 보면될듯)
인덱스가 없는경우(우측) 모든 업데이트(25MB x 8 = 200MB)를 각 base파일에 머징을 시도하여 동일한 hudi key를 가진 데이터를 가진 데이터를 추려내 병합해야한다. 그러면 총 (base file 100MB + 업데이트 200MB) x 4(base file 갯수) = 1200MB의 코스트가 발생하게 된다.
인덱스가 있는경우(좌측) 업데이트 데이터들은 인덱스를 통해 어떤 base file에 병합해야하는지 알수 있음으로, 불필요한 병합 작업 없이 바로 base file과 업데이트 파일을 머지할수 있다. 따라서 (base file 100MB + (25MB x 2)) x 4(base file 갯수) = 600MB의 코스트가 발생하여 인덱스가 없는것보다 더 나은 write 성능을 확보할수 있다.
Index Type
Hudi에서 제공하는 인덱스는 아래와 같다.
- Bloom Index(기본값): Record Key와 블룸필터를 사용하여 대상이 되는 파일을 추려내어 작업
- Simple Index: update/delete 레코드에 대응하는 키를 테이블 저장소에서 추출하여 lean join을 수행한다.
- HBase Index: 외부 저장소인 Apache HBase를 이용하여 인덱스 매핑을 관리한다.
- Custom Index: API를 직접 구현하여 커스텀인덱스를 구현한다.