하둡에서 데이터 처리속도 개선을 위한 파일포맷 ？ OrcFile

하둡 플랫폼의 속도와 효율성을 높이기 위한 여러 기술이 등장하고 있습니다.

Hive또한 여러 가지 기술이 적용되고 있는데, 그 중 파일 포맷을 보다 고도화된 데이터모델로 바꿔주는 Parquet, RCFile, ORCFile 포맷이 개발되었습니다.

RCFile포멧은 데이터 파일의 읽기 성능을 향상시키기 위해 row 기반으로 저장되는 text 와 같은 파일을 column 기반의 데이터로 저장되는 구조를 가지게 되었고, ORCFile 은 RCFile 기반으로 ORCFile은 RC파일의 단점을 개선하여 다음과 같은 특징을 가지고 있습니다.

● 각 태스크의 결과가 하나의 파일로 생성됨. - 네임노드 부하를 줄여줌
● Datetime, Decimal, complex types (struct, list, map, and union)을 포함한 하이브타입을 지원함.
● 파일에 경량 인덱스가 저장됨
- 필터링 조건이 없는 로우그룹은 스킵한다.
- 특정 row로 seek 가능
● 데이터 타입 기반의 block-mode 압축
- Integer 컬럼은 run-length encoding을 사용 한다.
- 문자열 컬럼은 dictionary encoding을 사용 한다.
● 하나의 파일을 여러 개의 리더로 동시 읽기 가능함
● 마커 스캐닝 없이 파일분활 가능함
● 파일 읽기 쓰기에 일정한 메모리 용량만 필요함
● 필드의 추가나 제거가 가능한 메타 데이터는 Protocol Buffers 를 사용해 저장됨.


출처 - https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC

ORCFile의 두드러진 특징 하나는 데이터 데이터 압축률이 상당히 높다는 점입니다.
호튼웍스에서 공개한 TPC-DS Scale 500 dataset의 ORCFile 압축률을 보면 78%의 압축률을 보여주고 있습니다.


출처 - http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

'스트라타+하둡월드2013' 컨퍼런스 에서 클라우데라는 호튼웍스의 자료가 동일한 압축코덱이 아니기 ？문에 공정하지 못하고 오히려 같은 압축 코덱을 사용할때 Parquet 가 더 높은 압축율을 보여준다는 점을 발표하기도 했습니다.
*Parquet 은 트위터에서 오픈소스로 공개한 컬럼 스토어 포멧입니다. 구글 드레멜 논문 기반으로 작성되었고, 여러 플레폼에서 지원할수 있도록 고안되었습니다.

ORCFile이 원천 데이터 특성에 따라 압축률이 차이가 많이 나는 구조이기 때문에 파싱된 아파치 로그 데이터로 압축률을 다시 한번 측정해보았습니다.



측정값은 TextFile 대비 orc_zlib 은 95%, orc_snappy는 93%의 높은 압축률을 보여주고 있습니다.
호튼웍스 측정치보다 높은 압축률을 보여주고 있습니다. 이는 측정을 위해 사용한 데이터의 컬럼 값이 대부분 동일한 문자열을 가지고 있었기 때문에 높은 압축률이 나온 것으로 보입니다.

이번 테스트에서는 Text 파일을 직접 압축하는 방법보다 더 높은 효율을 보여준 결과였기 때문에 다양한 값이 있는 데이터는 어떻게 될지 테스트를 좀더 해보았습니다.

다음은 10만개의 문자열 풀을 만들고 균등한 비율로 100만 Row의 파일을 생성 후 ORCFile로 변환한 결과입니다.



두 번째 결과는 TextFile 대비 orc_zlib 은 43%, orc_snappy는 22%의 압축률을 보여주고 있습니다.
문자열의 Dictionary encoding의 특성상 컬럼의 문자열이 다양해지면 압축률이 낮아짐을 알 수 있습니다.

다음으로 쿼리 수행성능을 측정해 보았습니다.

select a.v1 from a, b



첫 번째 테스트는 TextFile이 ORCFile 보다 빠른 결과를 보여주었습니다.해당 쿼리는 TextFile 의 Task가 ORCFile 보다 10배가량 더 많이 할당 되었습니다.

Full join 작업을 수행한 MapTask는 리소스 사용량이 굉장히 큰 작업이었기 때문에 ORCFile의 DiskIO 이득은 미미하게 작용하였고, Task 개수의 영향이 큰 결과로 보여집니다.

select a.v1 from a, b where a.k1 = b.k1



이번 테스트 결과는 ORCFile이 TextFile보다 빠른 성능을 보여주었습니다. 이번에도 TextFile 의 Tesk가 10배정도 많이 구동되었지만, ORCFile 의 두 번째 강점인 필요한 컬럼만 읽어 DiskIO 상의 이득이 크다는 이점이 반영된 결과로 보여집니다.

select count(v1) from a where a.ch = 'a'



이번 결과도 2번 결과와 비슷한 결과를 보여주는데, 동일한 이유로 추정됩니다.

select k2 from a sort by k2



sort 테스트도 orc 파일이 좋은 성능을 보여주고 있습니다
· 2번 테스트와 동일한 쿼리지만 b 테이블은 txt 로 고정하고 a 테이블의 포맷은 변경하며 태스트 했습니다.



위 테스트와 유사한 패턴을 보여주었습니다만 수행시간이 증가 했습니다. 그와 동시에 zlib 와 snappy 의 속도가 비슷해졌는데 고정된 b 테이블의 영향인것 같습니다.

ORCFile 테이블을 사용하기 위해 테이블을 생성한후 텍스트 파일을 Load 명령어로 적재할려고 하면 에러가 발생합니다.

(ex - LOAD DATA LOCAL INPATH './examples/data.txt' OVERWRITE INTO TABLE orcTable) Load 명령어 자체로는 파일포멧 변환을 하지 않기 때문입니다.

텍스트 파일을 orc 파일로 변환하는 작업은 임시테이블을 하나 생성후 데이터를 적재하고 OrcTable로 변환하는 방법을 쓰면 됩니다.

( ex - INSERT OVERWRITE TABLE orcTable SELECT * from tempTable)

마치며

ORCFile에 대해 테스트를 진행하면서 느낀점은 기본적으로 TextFile보다는 좋은 성능과 효율성을 보여주고는 있지만 만병통치약은 아니다 라는점 입니다.

데이터의 특성에 따라 압축률의 차이가 있을수도 있고, 변환 후 쿼리 수행의 성능도 쿼리의 특성에 따라 크게 차이남을 알수 있었습니다.

결국 자신이 다뤄야 할 데이터에 대해 이해하고 적절한 방법을 찾는 것이 대용량 데이터를 처리함에 있어서 가장 중요한 점인 것 같습니다.

Reference

LanguageManual ORC - https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
※ 해당 글은 KTH DAISY 개발팀에서 테스트 및 작성한 글입니다.

출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net