- Posted at 2013/11/04 16:04
최근 SQL-On-Hadoop이라고 하여 Hadoop에 저장된 데이터를 MapReudce라는 프로그램을 이용하지 않고 개발자(또는 사용자, 데이터 분석가)에게 친근한 인터페이스인 SQL을 이용하여 데이터를 처리하는 솔루션이 많은 관심을 받고 있다.
SQL-On-Hadoop의 현재의 Hadoop기반 데이터 처리 플랫폼에서 중요한 이유는 SQL이라는 표준 기반이기 때문에 기존의 데이터 분석 솔루션(BI 도구) 등과 쉽게 연동될 수 있는 가능성을 보여주기 때문이다.페이스북에서 개발하여 지금은 아파치 프로젝트인 Hive는 개발된지 5년 정도되었으며 가장 많이 사용하면 SQL-On-Hadoop 계열의 솔루션이라 할 수 있다. 최근 Hive와 유사한 개념으로 새로운 솔루션이 많이 등장하는데 하나같이 Hive 대비 몇배라는 슬로건을 걸고 있는데 몇배 수준이 아니라 몇십배, 심지어는 몇백배 이상 성능이 빠르다는 문구로 유혹하고 있다.
이번 글에서는 SQL-On-Hadoop의 성능 factor와 각 솔루션에서 제시하는 성능 수치가 구라(?)임을 밝혀보고자 한다.
- SQL-On-Hadoop 솔루션의 특징
. 대부분의 데이터 파일은 Hadoop 파일 시스템에 저장
. 데이터 파일은 인덱스가 없는 flat한 파일 형태가 대부분
. 데이터 파일은 읽기 성능 향상을 위해 일부 구조화된 형태로 저장(RC, ORC Parquet 등)
. SQL 문을 이용하여 데이터 처리
. SQL 문 실행은 분산된 환경에서 실행
. 처리 결과가 많은 경우 결과를 다시 Hadoop 또는 다른 파일 시스템으로 저장하는 기능 제공
- SQL-On-Hadoop 솔루션 종류
. Hive: SQL을 MapReduce로 전환하여 실행, MapReduce의 장/단점을 그래도 가지고 있음(안정성, 셔플 오버헤드 등)
. Stinger: 별도 제품이 아닌 Hive 개선 프로젝트 이름으로 Hive를 MapReduce 기반이 아닌 Tez 기반의 컴퓨팅 플랫폼 기반으로 전환하는 등 다양한 개선 목표를 가지고 진행 중인 프로젝트
. Apache Tajo: hdfs에 저장된 파일을 별도의 컴퓨팅 플랫폼을 이용하여 질의 실행
. Cloudera Impala: hdfs에 저장된 파일을 별도의 컴퓨팅 플랫폼을 이용하여 질의 실행. 셔플 단계의 데이터는 모두 메모리에 존재. 셔플 부하는 없지만 메모리 크기 이상의 셔플 데이터는 처리하지 못함
. Pivotal HAWQ: EMC의 소프트웨어 계열사인 Pivotal에서 만든 SQL-On-Hadoop 솔루션으로 오픈소스는 아님.
. Apache Drill: Tajo와 유사한 프로젝트.
. 기타 등등: 많이 있음
- SQL-On-Hadoop 솔루션의 성능 factor
. Hadoop 파일 스캔 속도
데이터가 Hadoop에 저장되어 있고 특별한 경우를 제외하고는 대부분 full scan으로 데이터 파일을 읽기 때문에 처리 속도에 가장 중요한 영향을 미친다.
. 중간 데이터 처리
group by, order by 등의 연산을 처리할 때에는 여러 단계의 실행 계획을 거쳐야 하는데 이때 앞 단계의 결과 데이터가 다음 단계의 입력 데이터로 전달되어야 한다. 이 데이터 전달을 어떻게 효과적으로 처리하느냐도 성능에 많은 영향을 준다.
. 실행계획
SQL을 얼마나 효과적인 실행계획으로 처리하느냐도 성능에 많은 영향을 준다. 예를 들어 order by의 경우 hive에서는 특별한 처리를 하지 않으면 무조건 하나의 reduce에서 처리하게 되어 분산의 효과가 거의 없다.
. 파일 포맷
과거에는 textfile이나 seqfile 정도만 사용하였는데 최근에는 컬럼 기반의 파일 포맷인 RCFile이나 이를 확장한 ORCFile과 parquet등 다양한 파일들이 나타나고 있으며 각 파일에 따라 특성이 조금 달라서 테이터의 특성, 질의의 특성에 따라 적절한 파일을 선택해야 한다.
. 결과 저장
처리 결과가 많은 경우 저장되는 데이터 파일의 포맷, 파일 저장 처리 성능 등도 많은 영향을 준다. ORC 파일의 경우 읽기 성능은 좋지만 쓰기 성능이 나쁜 대표적인 파일 포맷이다.
. 압축
적절한 압축을 잘 사용할 경우 읽기, 쓰기 모두 성능 향상을 가져 올 수 있다.
. 질의 실행 초기화 시간
실행계획 수립, 분산된 환경으로 질의 작업 요청 등에 걸리는 시간으로 짧은 질의인 경우 이 시간이 많은 영향을 주지만 100초 이상되는 질의에서는 많은 영향을 주지는 않는다.
- SQL-On-Hadoop의 절대 성능 수치
. SQL-On-Hadoop은 당분간은 절대 이 수치를 넘을 수는 없다.
성능 <= HDFS 전체의 디스크 갯수 * 디스크 bandwidth
예를 들어 10대 서버, 서버 하나에 디스크 8개, SATA 7200 rpm인 경우
10대 * 8개 * 100MB/sec = 8GB/sec
. 실제로 1.5TB의 데이터를 Hive, Tajo, Impala를 이용하여 다음 질의를 수행하면 성능 차이는 크지 않다.
select count(*) from T_TEST
이 질의의 경우 셔플에 대한 부하는 거의 없으며 성능에 관련된 factor는 "파일 스캔 속도", "질의 실행 초기화 시간", "파일 포맷" 정도이다. 파일 포맷이 동일하다고 가정하고 데이터가 충분히 크기때문에 파일 스캔 속도가 가장 큰 영향을 주는 factor이다. 따라서 이 질의 경우 성능 차이가 각 솔루션별로 크지 않다. 성능 수치는 Hive를 1로 하면 Tajo, Impala는 1.5 ~ 3배 정도이다. 100배, 200배와는 너무나 차이가 많이 나는 수치이다.
- 성능 비교에 자주 사용하는 질의
. 질의 실행 시간이 짧은 질의
Hive(Stinger가 아닌)의 경우 MapReduce 작업을 실행시켜야 하는 초기 비용이 많이 들기 때문에 질의 실행 시간이 10초 이상인 경우 수십배, 수백배 정도 성능 차이가 날수 있다. 성능 결과에 Hive는 20초 였는데 A 솔루션은 0.1초 라고 나오는 경우 200배 성능 향상이 있다고 주장하지만 이 수치를 200초로 확대했을 때 1초만 A 솔루션이 1초만 걸릴지는 의문이다. 200초로 확대했다는 의미는 입력 데이터가 더 커졌다는 의미이다.
. 특정 솔루션에 최적화된 실행 계획
Hive와 성능 비교를 할때 비교 대상 솔루션의 성능을 가장 돋보이게 하는 질의는 order by가 있는 질이이다. 여기에 order by 대상 데이터가 많고 테스트 클러스터가 크면 클수록 성능 차이는 크다.
Hive의 경우 order by는 아무리 서버가 많아도 하나의 서버에서만 실행된다. 100대의 장비에 1대당 동시에 10개의 task를 실행시킬 수 있는 환경이고 경쟁 솔루션은 분산 order by를 지원할 경우 1000배의 성능 향상을 가져올 수 있다. 물론 Hive가 이런 기능을 제공하지 않기 떄문에 1000배라고 말하는 것이 맞기는 하지만 이 수치만으로 대부분의 질의에 평균 1000배의 성능 향상이 있다고 믿게끔 문서를 만들면 안된다.
또 다른 실행계획 중 하나는 join인데 큰 테이블과 작은 테이블 여러개 join 처리를 하는 경우 어떻게 처리하느냐에 따라 성능 차이가 많이 나기 떄문에 이 부분도 솔루션의 특징에 따라 천차만별이다.
- 결론
현재 SQL-On-Hadoop 진영에서 제시하는 대부분의 성능 수치는 일반적인 질의나 전체 질의에 대해서 평균 몇배 빠르다가 아닌 자신들이 유리한 조건에서 테스트한 결과만을 언급하는 경우가 많다. 필자의 테스트 결과를 보면 대략 평균 3 ~ 5배 정도이고 질의의 종류에 따라 수십배 정도 빠를 수도 있고, 더 느릴 수도 있다.
따라서 자신의 데이터 속성과 질의 속성에 맞는 플랫폼을 선택하는 안목이 필요할 때이다. 미국산 벤더, 블로그, 언론에서 제시한 수치라고 맹신하는 것은 금물이다. 요즘 추세가 오픈소스에도 구라를 무지하게 치는 추세로 가고 있는 것 같다.
더 많은 내용을 담고 싶었지만 타이핑의 압박으로 인해 여기까지만 합니다.
출처 - http://www.jaso.co.kr/480
