[제9회 ACC]클라우데라 "맵리듀스-임팔라 차이점은"

클라우데라가 하둡분산파일시스템(HDFS)에서 맵리듀스 대신 데이터분석작업을 수행하기 위해 만든 기술 '임팔라(impala)'를 직접 소개했다.

클라우데라 소프트웨어(SW) 엔지니어이자 아파치 하둡 커미터인 애론 T. 마이어스는 17일 서울 잠실 롯데호텔 제9회 ACC 현장에서 '클라우데라 임팔라가 새로운 길로 HDFS을 제안하는 방식'이란 주제로 클로징 키노트를 진행했다.

그에 따르면 HDFS는 랜덤쓰기를 지원하지 않는 분산파일시스템으로, 방대한 크기의 파일을 저장하기 위한 목적으로 만들어졌다. 이는 전통적인 파일시스템에 비해 상대적으로 큰 블록 크기인 64~512MB 단위를 사용한다. 구글이 만든 구글파일시스템(GFS)처럼 '맵리듀스' 구현을 위해 설계됐으며 데이터를 네트워크로 전송해 매번 3개씩 복제되는 파일쌍을 만든다.

HDFS는 클러스터마다 '네임노드'가 존재해 파일시스템의 사용권한이나 블록ID같은 메타데이터를 저장한다. 블록ID란 각 블록이 실제 파일을 저장하고 있는 데이터노드를 매핑하는 역할이다. 이 아키텍처에서는 네임노드에 접속하는 서버를 'HDFS클라이언트'로 부른다. 네임노드와 통신해 파일시스템에 접속하기 때문이다. 또 네임노드 하위에 연결되는 여러 '데이터노드'가 존재한다. 각 데이터노드는 여러 디스크를 장착해 수GB짜리 크기파일을 쉽게 저장한다.

T. 마이어스는 임팔라는 이런 HDFS환경에서 범용 분석작업을 수행하기위해 만들어졌다며 1초 미만에서 몇시간동안 돌아가는 작업까지 수행해 데이터베이스(DB)처럼 일반 트랜잭션 작업에도 쓸 수 있다고 주장했다.

임팔라는 H베이스(HBase)나 맵리듀스같은 별도 계층을 거치지 않고 HDFS와 직접통신한다. 그리고 하이브처럼 '하이브쿼리언어(HiveQL)'를 쓴다. 클라우데라는 임팔라와 하이브의 최대 차이를 성능으로 꼽는다. 하이브는 자바로 만들어졌지만 임팔라는 C++ 기반이다. 또 별도의 실행엔진을 사용하므로 맵리듀스 프로그래밍이 불필요하다. 물론 임팔라와 맵리듀스는 나란히 놓고 쓸 수도 있다.

임팔라는 그러나 맵리듀스와 달리 쿼리를 아주 낮은 지연속도로 처리할 수 있다고 클라우데라는 강조한다. 맵리듀스에 있는 '셔플'단계를 거치지 않아 테이블간의 '조인' 작업도 반드시 맵리듀스처럼 다대다 커뮤니케이션을 요구하지 않는다.

T. 마이어스는 임팔라의 고유기능을 구현하기 위해 아파치프로젝트인 HDFS 자체도 개선시켰다고 설명했다. 그에따르면 임팔라는 가용 디스크 스루풋을 최대한 활용하며, 개선된 쿼리실행엔진을 갖고 있어 하이브와 비교시 I/O 바운드 가능성이 높다. 디스크의 최대 성능을 끌어내기에 더 유리하며 성능개선의 여지가 I/O 확장에 의존하게 된다는 설명이다.

그가 제시한 HDFS 관련 개선점은 개별 블록 레플리카디스크의 위치정보를 표시해주는 것, 특정파일 블록레플리카를 같은 데이터노드에 위치시키게 만든 것, 자주쓰는 테이블과 파일을 인메모리에 캐싱하는 것, HDFS 읽기 작업시 거치는 복제횟수를 줄인 것, 4가지로 요약된다.

T. 마이어스는 임팔라는 중복읽기를 하지 않기 위해 어느 디스크에 레플리카가 있는지 알아야 했는데 기존 HDFS에선 그걸 네임노드밖에 알지 못했다며 새로운 RPC콜을 통해 어떤 데이터노드에 블록레플리카가 있는지 정의하고 임팔라가 데이터노드를 쿼리해 어느디스크에 있는지도 발견하게 했다고 설명했다.

임팔라는 개별 디스크에 대한 요청을 큐잉해 1개 디스크에서는 1~2개 읽기 작업만 동시에 일어나게 설계됐다. T. 마이어스는 이를 '모든 디스크 스루풋을 완전히 활용하는 것'이라고 표현했다. 빈번한 읽기를 대단위 작업으로 몰아서 디스크의 탐색(Seek) 횟수를 최소화했다는 얘기다.

T. 마이어스는 거대 테이블 2개를 합치려 할 때 데이터가 원격에 있다면 로컬에서보다 훨씬 느려지기 때문에 모든 읽기를 로컬디스크에서 하는 게 이상적이라며 HDFS기능 추가로 임팔라가 특정파일을 같은 데이터노드에 레플리카가 이뤄지게 만들어 로컬읽기를 유도했다고 밝혔다.

이밖에 임팔라는 고밀도의 저가 메모리 환경이 갖춰짐에 따라 각 시스템의 인메모리 성능을 활용을 강화했다. 데이터가 디스크에서 운영체제(OS)의 버퍼 캐시를 사용하는 것보다 임팔라가 인메모리 성능을 활용할 때 훨씬 빨라졌기 때문이다. 이 작업은 다른 파일이 읽는 맵리듀스작업때문에 실제 원하는 데이터가 메모리테이블에서 밀려나지 않도록 막아주게 돼있다.

T. 마이어스는 하둡작업을 처음 시작할 때 8노드가 8GB램에 불과했는데 지금 고객들은 48~96GB램 짜리 시스템을 쓴다며 HDFS에 인메모리캐싱 기능을 더해 관리자가 HDFS 파일이나 하이브 테이블을 메인메모리에서 읽고 저장하게 만들었다고 설명했다.

또 HDFS 데이터처리과정의 복제과정을 줄이기 위한 변화도 이뤄졌다. HDFS는 원래 읽기시 데이터노드를 로컬 읽기로 메모리에 가져간다. 이를 복사해 버퍼에 올리면 커널이 또 이를 가져간다. 네트워크로 이게 올라가고 클라이언트가 읽는다. 그쪽 커널에서 버퍼로 가져간다. 그걸 노드로 옮긴다. 이 흐름은 전체적으로 메모리와 CPU 자원을 많이 소모한다.

T. 마이어스는 부가적인 카피 작업을 줄이기 위해 HDFS에서 '숏서킷리드'를 수행케 했다며 클라이언트에서 실제파일과 같은 노드에 임팔라 데몬이 있다면 데이터노드 데몬을 우회해 CPU가 직접 읽게 했고, HDFS에 API를 추가해서 직접 바이트버퍼도 읽을 수 있게 만들었다고 말했다.