disclaimer -...
TRANSCRIPT
저 시-비 리- 경 지 2.0 한민
는 아래 조건 르는 경 에 한하여 게
l 저 물 복제, 포, 전송, 전시, 공연 송할 수 습니다.
다 과 같 조건 라야 합니다:
l 하는, 저 물 나 포 경 , 저 물에 적 된 허락조건 명확하게 나타내어야 합니다.
l 저 터 허가를 면 러한 조건들 적 되지 않습니다.
저 에 른 리는 내 에 하여 향 지 않습니다.
것 허락규약(Legal Code) 해하 쉽게 약한 것 니다.
Disclaimer
저 시. 하는 원저 를 시하여야 합니다.
비 리. 하는 저 물 리 목적 할 수 없습니다.
경 지. 하는 저 물 개 , 형 또는 가공할 수 없습니다.
공학석사학위논문
HDFS기반 데이터 처리 시스템 성능 평가
2016 년 2 월
서울대학교 대학원
컴퓨터 공학부
이 희 란
공학석사학위논문
HDFS기반 데이터 처리 시스템 성능 평가
2016 년 2 월
서울대학교 대학원
컴퓨터 공학부
이 희 란
HDFS기반 데이터 처리 시스템 성능
평가
지도교수 문 봉 기
이 논문을 공학석사학위논문으로 제출함
2015 년 10 월
서울대학교 대학원
컴퓨터 공학부
이 희 란
이희란의 석사학위논문을 인준함
2015 년 12 월
위 원 장 김형주 (인)
부위원장 문봉기 (인)
위 원 이상구 (인)
요약
최근 몇 년 동안 Big-data 처리에 있어 하둡이 주요한 역할을 하게 되면서
HDFS(Hadoop distributed File System) 상에서 SQL 인터페이스(Interface)를
제공하는 SQL-on-Hadoop 기술 또한 꾸준히 인기를 끌고 있다.
본 논문에서는 대중적으로 가장 많이 쓰이는 SQL-on-Hadoop 엔진인 Hive와
Spark의 성능 평가를 수행하고 각각 시스템의 특징을 분석하였다. 이러한 벤치마
크 테스트를 위해 IBM의 Hibench의 벤치마크 워크로드들을 사용하였다. 시스템
사용량을정량적으로측정하기위해각각의벤치마크수행시시스템프로파일링을
하여 검토하였다.
다양한 파일 형식도 테스트 되었다. 현재 학계와 산업계에서 성능에 대한 많은
논쟁이 이루어지고 있는 종횡 배열 스토리지(Columar storage) 형식의 파일들(파
케이(Parquet), 오알씨(ORC) 파일)과 압축 방식(스내피(snappy), 지집(gzip)등)
에 따른 성능 차이도 비교하여 보았다. 또한 실제 SNS(Social Network Service)에
서사용되는데이터(Tweet)를사용하여 Spark의신규기능인 Spark DataFrame을
이용, JSON(JavaScript Object Notation)파일의처리의성능차이도살펴보았다.
이와 같이 본 연구는 기존의 RDBMS(Releational Database Management
System)의 테스트에 주로 사용되었던 TPC(Transaction processing Performance
Council) 벤치 마크에서는 다루지 못한, 대용량 시스템의 성능 평가 지표로 포함
되어야 하는 기준들을 제안하고, 이를 실험 해 보고 효율적인 시스템 활용 방안에
대한 방법을 제안한다.
주요어: HDFS , 하둡, SQL-on-Hadoop, Hive, Spark
학번: 2014-21766
i
목차
요약 i
목차 ii
그림 목차 iv
표 목차 vi
제 1 장 서론 1
1.1 배경지식 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 HDFS(Hadoop Distribution File System) . . . . . . . . . 2
1.1.2 맵리듀스(MapReduce) . . . . . . . . . . . . . . . . . . . . 2
1.1.3 SQL-on-Hadoop . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 하이브 Hive(HiveQL) . . . . . . . . . . . . . . . . . . . . . 3
1.1.5 스파크 (Spark) . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 종횡배열 스토리지(Columnar Storage) . . . . . . . . . . . 7
1.1.7 JSON 파일 형식 (JavaScript Object Notation File Format) 8
1.2 관련연구 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Large Scale Data Benchmark . . . . . . . . . . . . . . . . 8
1.2.2 IBM Research Center . . . . . . . . . . . . . . . . . . . . 8
제 2 장 시스템 구성 및 실험 설계 11
2.1 시스템 사양 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 워크로드(Workloads) . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 워크로드 규모 (Workloads Scale Factor) . . . . . . . . . . 12
ii
2.2.2 마이크로 벤치마크(Micro Benchmark) . . . . . . . . . . . 12
2.2.3 웹 어플리케이션(Web Application) . . . . . . . . . . . . . 14
2.2.4 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 머신러닝 알고리즘 (Machine Learning Algorithms) . . . . 17
2.2.6 Workload에 따른 데이터 규모 상세 . . . . . . . . . . . . . 19
제 3 장 실험 결과 20
3.1 전체 테스트 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 각 수행 알고리즘에 따른 Profile 결과 분석 . . . . . . . . . . . . 21
3.3 확장성 테스트 (Scalability) . . . . . . . . . . . . . . . . . . . . . 26
3.4 리소스 사용에 따른 Spark 성능비교 . . . . . . . . . . . . . . . . . 28
3.4.1 메모리 크기에 따른 결과 분석 . . . . . . . . . . . . . . . . 29
3.4.2 Core 개수와 Executor 개수 설정에 따른 성능 분석 . . . . . 30
3.5 파일 타입과 파일 압축 코덱에 따른 결과 . . . . . . . . . . . . . . 31
3.6 병렬성(Parallelism) 테스트 결과 . . . . . . . . . . . . . . . . . . 34
3.7 SNS 데이터 테스트(Json file) . . . . . . . . . . . . . . . . . . . . 35
제 4 장 결론 및 향후 연구 39
참고문헌 41
Abstract 43
감사의 글 45
iii
그림 목차
그림 1.1 Apache Hive 시스템 구조 . . . . . . . . . . . . . . . . . . . . 4
그림 1.2 스파크(Spark) 프로세스 동작 설명 . . . . . . . . . . . . . . . 5
그림 1.3 스파크(Spark) RDD 동작 흐름도 . . . . . . . . . . . . . . . 5
그림 1.4 Spark-SQL 인터페이스 구조 . . . . . . . . . . . . . . . . . . 6
그림 3.1 Hive / Spark 실행시간 비교 . . . . . . . . . . . . . . . . . . 20
그림 3.2 Scan 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
그림 3.3 Aggregation 결과 . . . . . . . . . . . . . . . . . . . . . . . . 22
그림 3.4 Join 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
그림 3.5 K-means 결과 . . . . . . . . . . . . . . . . . . . . . . . . . 23
그림 3.6 Pagerank 결과 . . . . . . . . . . . . . . . . . . . . . . . . . 23
그림 3.7 Bayes 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
그림 3.8 Wordcount 결과 . . . . . . . . . . . . . . . . . . . . . . . . 24
그림 3.9 Sort 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
그림 3.10 Terasort 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
그림 3.11 Machine learning 결과 . . . . . . . . . . . . . . . . . . . . . 26
그림 3.12 sql 결과 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
그림 3.13 Wordcount, Sort, Terasort 결과 . . . . . . . . . . . . . . . . 27
그림 3.14 Spark와 Yarn 메모리 구조도 . . . . . . . . . . . . . . . . . . 28
그림 3.15 설정 메모리 크기에 따른 실행시간 비교 . . . . . . . . . . . . 29
그림 3.16 Executor 개수 설정 비교 . . . . . . . . . . . . . . . . . . . . 30
그림 3.17 파일에 따른 메타스토어(Metastore) 테이블 생성 시간 비교 . 31
그림 3.18 Aggregation 시간 비교 . . . . . . . . . . . . . . . . . . . . . 32
iv
그림 3.19 Join 시간 비교 . . . . . . . . . . . . . . . . . . . . . . . . . 33
그림 3.20 map reduce 개수 설정 비교 . . . . . . . . . . . . . . . . . . . 34
그림 3.21 Tweet 데이터(json 파일) 처리 결과 . . . . . . . . . . . . . . 35
v
표 목차
표 2.1 시스템 사양 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
표 2.2 HiBench 벤치마크 . . . . . . . . . . . . . . . . . . . . . . . . . 12
표 2.3 Workload 규모 (Scale Factor) . . . . . . . . . . . . . . . . . . 13
표 2.4 Pagerank 설정 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
표 2.5 테이블 Uservisits 와 Rankings 의 스키마 . . . . . . . . . . . . 15
표 2.6 평가 항목 별 SQL 문 . . . . . . . . . . . . . . . . . . . . . . . 16
표 2.7 Bayes 설정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
표 2.8 K-means 설정 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
표 2.9 셔플 단계의 데이터 사이즈 (입력 데이터 60G 기준) . . . . . . . 18
표 2.10 SQL 테스트 시 규모(Scale factor)별 테이블 레코드수 . . . . . . 19
표 3.1 Spark 가용 메모리 계산 . . . . . . . . . . . . . . . . . . . . . . 29
표 3.2 Tweet 데이터 예시 . . . . . . . . . . . . . . . . . . . . . . . . 36
표 3.3 Tweet 데이터(json 파일) 테스트 쿼리 . . . . . . . . . . . . . . 37
vi
제 1 장 서론
지난 몇 년 간 하둡(Hadoop)과 맵리듀스(MapReduce)은 대용량 분산 데이터
처리분야에많은혁신을가져다주었다.하둡과맵리듀스의조합은DAG(Directed
Acyclic Graph)형태의일괄처리작업(Batch Job)을처리하는데있어매우뛰어
나다.하지만순환그래프(Cyclic Graph)형태의작업에서는중간데이터를 HDFS
에저장함으로써추가적인입출력이발생하여비용적인측면에서비효율이발생한
다. 이러한 맵리듀스의 처리 구조상의 단점을 개선한 Apache社의 Spark의 등장은
데이터 분석 시스템의 많은 변화를 예고하고 있다. 그리고 RDBMS에서부터 사용
된 데이터 분석 처리를 하둡 상의 SQL interface를 통하여 처리할 수 있도록 한
SQL-on-Hadoop기술이 많은 주목을 받고 있다.
본논문에서는가장대중적으로많이사용되는 SQL-on-Hadoop시스템인 Hive
(MapReduce)와 Spark를 이용하여 여러 가지 방법으로 성능 평가를 수행 하고 이
둘의 성능 상의 차이점과 각 시스템의 특성을 분석하였다. 본 논문이 이루고자
하는 목표은 다음과 같다.
첫째, 다양한 방법으로 SQL-On-Hadoop (Spark, Hive)을 평가한다. 기존의
하둡 시스템의 특성만을 단순하게 평가하던 방법이나, SQL 데이터베이스를 평가
하는 복잡한 데이터 분석형 쿼리가 아닌 실제 데이터가 사용되는 패턴을 반영하여
하둡(HDFS)의 특성에 맞는 SQL-On-Hadoop시스템을 평가하는 방법을 제시하
고자 한다.
둘째, 각 시스템 특성을 정량화된 지표을 통해 관찰, 시스템 적인 차이를 도출
하고자 한다. 이를 위해 아래와 같이 평가를 수행하였다.
• 처리속도, 처리량, 시스템 사용량 등
• 파일 포맷(Format)에 따른 처리율 : Columnar storage file, Sequence file,
JSON file등
1
• 병렬성(Parallelism)에 따른 처리율
• 클러스터 내 노드 수(Scale out)
• 메모리크기 / 코어 개수에 따른 프로세스 개수에 따른 처리율
• 다양한 워크로드(Workloads) 와 마이크로 벤치마크(Micro-Benchmark) 사
용
셋째, Hive와 Spark의최신의기능을반영한다.테스트된버전은 Hive 0.13 , Spark
0.14이며 Spark의 SQL을 위한 신규 기능인 Dataframe이 평가되었다.
넷째, 각각의 시스템 성능 최적화를 위한 시스템 튜닝 방법에 대한 몇 가지
방법을 제시하고, 시스템 최적 사용 방법을 공유하고자 한다.
1.1 배경지식
1.1.1 HDFS(Hadoop Distribution File System)
Apache 하둡은 범용 장비에서 구동하는 분산 파일 처리 시스템이다. 자바 기
반의 오픈 소스 프래임 워크으로 기존의 분산 처리 시스템과는 다르게 저가의
하드웨어 상에서 동작하도록 높은 내고장성(false-tolerance)를 보장하며, 대용량
데이터의 처리에 알맞게 설계되어있다. 하나의 마스터 노드(name node)와 여러
개의 슬레이브 노드(data node)로 구성된다. 이들은 블록(기본 128MB) 단위로
파일을 저장/처리한다. Hadoop 2.0버전 이후에 YARN(Yet Another Resource
Negotiator)을 지원함으로써 YARN API를 통하여 맵리듀스이외의 다른 분산처
리 시스템을 도입할 수 있게 되었다.
1.1.2 맵리듀스(MapReduce)
맵리듀스(MapReduce)는 대용량 데이터 처리를 분상 병렬 컴퓨팅에서 처리
할 수 있도록 제작된 소프트웨어 프레임워크로 2004년도 구글에서 발표 되었다.
해당 프레임워크는 페타 바이트 이상의 대용량 데이터를 신뢰도가 낮은 컴퓨터
2
(Commodity Computers)들로 구성된 클러스터 환경에서의 병렬 처리를 지원하
기 위해 개발 되었다. 해당 프레임 워크는 Map 함수와 Reduce 함수로 구성된다.
Map함수는 Key/Value 쌍을 입력으로 받아 Key/Value쌍의 중간데이터로 결과를
생성하며 Reduce함수는모든중간데이터를통합한다.이때같은 Key들을가지고
있는 데이터들이 통합된다.
1.1.3 SQL-on-Hadoop
SQL-on- Hadoop이란 HDFS에 저장된 데이터에 대한 SQL 질의 처리를 제
공하는 시스템이다. HIVE나 PIG, IBM사의 JAQL 처럼 하둡의 맵리듀스 프레
임워크를 사용하는 시스템도 있지만 새로이 출시되는 대부분의 SQL-on-Hadoop
시스템들은 기존 하둡에서 제공하는 맵리듀스 아키텍처를 이용하지 않고, 새로
운 분산 처리 모델과 프레임워크를 기반으로 구현되어 있다. 대표적으로 Apache
Spark, Apache Tajo, Cloudera의 Impala, Facebook의 Presto, Pivotal의 HAWQ,
Apache Drill, Hortonworks Stinger 이외도 많은 SQL-on-Hadoop 엔진들이 출시
되고 있다.
1.1.4 하이브 Hive(HiveQL)
Hive는하둡에서동작하는데이터웨어하우스인프라구조로서데이터요약,질
의및분석기능을제공한다. Hive는 HiveQL을통하여 sql과비슷한인터페이스를
제공하며, CLI나 JDBC/ODBC를 이용한 프로그래밍으로 사용할 수 있다. 또한
웹 인터페이스를 통하여 사용이 가능하다. 쿼리가 입력되면 Hive driver에서 입력
된 질의를 맵리듀스 job으로 변환하여 준다. 이때 만들어진 테이블들은 Metastore
DB에 저장된다. 해당 메타 데이터를 내장(Derby) 데이터 베이스 안에 저장할 수
도 있지만 MySQL과 같은 다른 서버/클라이언트 데이터 베이스를 사용할 수도
있다. (본 논문의 실험들은 MySQL 서버를 이용하여 테스트 되었다.) 서버를 사
용할 경우 다중 사용자가 지원된다. 현재 TEXT FILE, 씨퀀스파일(SEQUENCE
FILE), 오알씨(ORC), 파케이(Parquet), 에이브로(Avro), 제이썬(JSON) 그리고
3
그림 1.1 Apache Hive 시스템 구조
알씨파일(RCFILE)등의 파일 포맷을 지원한다.
1.1.5 스파크 (Spark)
Spark는 하둡 맵리듀스와 유사한 목적을 해결하기 위한 클러스터 컴퓨팅 프레
임워크로, 메모리를 활용한 빠른 데이터 처리를 수행한다. 맵리듀스의 경우 처리
중 중간 데이터를 디스크에 저장함으로써 반복적인 작업의 경우 I/O 비용이 많이
발생한다. Spark는 RDDs(Resilient Distributed Datasets)를 이용하여 데이터의
사용이력 정보(lineage)를 관리하여 메모리에 데이터를 상주시켜 반복 작업을 수
행할 수 있게 함으로써 빠른 작업 속도를 확보할 수 있다.
Yarn상에서의동작은다음 [그림1.2]과같다. Spark는하나의드라이버(driver)
프로세스와 다수의익스큐터(executor) 프로세서로 동작한다. 드라이버는 상위 단
계의 프로세스 흐름을 담당하는 프로세스이다. 익스큐터는 드라이버에서 할당 받
은 작업을 Task의 형태로 실행하는 일 뿐만 아니라, 캐쉬(cache)에 사용자가 선택
한 데이터를 저장하는 일도 수행한다. 드라이버와 익스큐터 모두 어플리케이션이
4
그림 1.2 스파크(Spark) 프로세스 동작 설명
동작하는 시간 동안 상주하며, 실행 후 동적 자원 할당 내용이 변경되더라도 유지
된다. 익스큐터는 동작하는 Task(실행 작업)에 대해서 여러 개의 슬랏(slot)으로
분할하고 이를 동시에 수행한다. 이때 시스템상의 클러스터 관리자(Yarn, Spark
Standalone)에 의해서 프로세스 할당이 결정된다. 드라이버와 익스큐터는 실행
프로그램마다 존재한다. 이들과 시스템 리소스와의 관계는 이후 3장에서 자세히
소개하도록 하겠다.
그림 1.3 스파크(Spark) RDD 동작 흐름도
5
RDDs(Resilient Distributed Datasets)
Spark 에서 사용되는 데이터 구조로 메모리에 데이터를 상주시켜 재사용이
가능하도록 설계되어있다. Transformation 과 Actions 의 두 가지 종류의 실행 방
법이있다. RDDs는내부의 Lineage(사용이력정보)정보를관리함으로써데이터
변환 중에 소실된 내용도 재 구축이 가능하다.
스파크 SQL(Spark-Sql)
Spark는 1.3.0 버전부터 새로운 SQL 프로세싱을 빠르게 최적화한 Spark-Sql
을 선보인다.[12] 기존의 Hive thrift server와 연결되었던 Shark와는 다르게 원
활한 프로그래밍 환경을 제공하고, 이를 위해 DataFrame API를 제공한다. 기
존 RDD와 마찬가지로 scala, python,java 언어로 작성할 수 있다. Spark-sql은
SQL CLI(command line interface)와 Dataframe API 모두 사용할 수 있지만,
DataFrame API를 이용하는 것이 속도가 더 빠르다고 알려져있다.[12]
그림 1.4 Spark-SQL 인터페이스 구조
6
1.1.6 종횡배열 스토리지(Columnar Storage)
컬림 기반의 구조화된 저장방식으로 데이터 분석쿼리를 처리하는 데 있어 탁
월한 성능을 보인다. 기존의 데이터베이스 가 행(raw)기반의 튜플(tuple)단위의
저장을 수행하였다면, 종횡배열 스토리지(Columnar Storage)는 열 단위로 데이
터를 저장하여 Aggregation 등의 작업을 행기반 저장 방식보다 빠르게 수행할 수
있다. 또한 인코딩 방식에 따라서 저장되는 데이터 사이즈도 작게 만들 수 있다.
Parquet(파케이) VS 오알씨(ORC)
HDFS에서컬럼스토어를구현하기어렵고속도에한계가있기때문에고도화
된 데이터 모델을 제공하여 관리하도록 한다. 최근 이러한 컬럼 스토리지 테이터
형식인 호튼웍스社의 오알씨(ORC,Optimized Row Columnar)와 클라우데라社
의 파케이(Parquet) 파일이 성능 논란을 일으키며 첨예하게 대립하고 있다.
오알씨 파일은 하나의 파일에 컬럼을 JSON처럼 중첩(nested) 구조로 집어넣
을 수 있고, 리스트와 맵, 스트럭트 등을 컬럼값 대신 사용한다. ORC파일은 높은
압축률과 데이터 모델의 우수성으로 오픈소스 진영에서 많은 관심을 받았다. 다만
ORC파일은 지원하는 시스템이 적고, 자바만 지원해 다양한 플랫폼에 적용하기
힘들다는 한계가 있다.
파케이는 무엇보다 하이브뿐 아니라 피그 같은 다양한 플랫폼에서 독립적으로
사용될수있게만들어졌다.트위터에서파케이스펙을최초로공개했고,클라우데
라에서 자신들의 SQL-on-Hadoop 기술인 임팔라(Impala)에 파케이를 채택했다.
구글 드레멜(Dremel)[17] 논문을 참고로 해 고안된 파케이는 ORC파일처럼 중첩
구조로 컬럼을 하나의 파일 안에 저장한다. 게시판에 댓글 달 듯 컬럼을 계층적 구
조로 늘려가는 것이다.각 컬럼 값마다 리피티드, 리콰이어드, 옵셔널 등의 구문을
넣을 수 있다. 여러 컬럼 테이블을 하나의 파일안에 집어 넣음으로써 조인 작업을
최소화한다.
7
1.1.7 JSON 파일 형식 (JavaScript Object Notation File Format)
Json은 속성(key)-값(value) 쌍으로 이루어진 데이터 오브젝트를 전달하기 위
해 인간이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷이다. Xml을 대체
하기도 하며 주로 인터넷에서 데이터를 주고받을 때 데이터를 표현하는 방법으로
사용된다. 자바 스크립트 언어로부터 파생되어 자바 스크립트 구문 형식을 따르지
만 언어 독립형 데이터 포멧이다. 프로그래밍 언어나 플랫폼에 독립적으로 사용할
수 있다. 트위터(Tweets) 데이터 등 SNS 데이터를 표현하는데 사용되었다.
1.2 관련연구
1.2.1 Large Scale Data Benchmark
Spark시스템을개발한 Berkeley Amplab은유사시스템의비교벤치마킹결과
를 홈페이지에 공개하고 있다. [6] 해당 홈페이지에서 비교대상이 되는 시스템들은
아래와 같다.
• RedShift : 전통적인 MPP(Massively Parallel Processor)
• Impala , HAWQ : MPP 와 유사하고 hadoop 상에서 동작.
• Shark, Stinger/Tez : 최적화된MapReduce 엔진
사용되는 워크로드와 쿼리는 [9][pav09] 에서 사용된 내용을 반영하고 있다. 해당
쿼리 웹 어플리케이션에서의 실사용 데이터 사용 패턴을 반영하여 만들어졌다.
Aggregation, Join, Scan, UDF(user define function)들의 성능을 평가하며 TPC-
DS등의 기존 데이터 분석 쿼리와 다르게 단순하게 작성되었다. 해당 평가에는
ORC나 파케이 파일에 대한 내용은 포함하지 않는다.
1.2.2 IBM Research Center
IBM 연구소에서도 최근 SQL-on-Hadoop 시스템에 대한 연구 결과를 많이
출시 하고 있다. 대표적인 주제는 아래와 같다.
8
BigSQL[7]
IBM사의 Bigdata처리 SQL 시스템인 BigSQL 을 소개하고 Hive와의 비교를
수행하였다.
[Fatma2013][8]
[Fatma2013]에서 Hadoop 상에서의 Hive의 성능과 Tez 상에서의 Hive 성능,
Impla 시스템을 비교 하였다. TPC-DS 벤치마크의 변형한 워크로드를 통하여 수
행시간을비교하였다.또한파케이파일과 ORC파일, Snappy압축등을사용하여
각각의 시스템상에서 가장 효율적으로 동작하는 파일 포멧을 실험을 통해 알아보
았다.
[Fatma2015][13]
최근 [Fatma2015]라는 논문에서 MapReduce (Hive) 와 Spark 를 밀도 있게
분석하였다. 셔플(Shuffle), 실행 모델(Execution Model), 캐싱(Caching) 부분이
각각의마이크로벤치마크 (Word Count, Sort, K-Means, PageRank)에따라어떤
방식으로 수행되는 지 분석을 진행하였다.
본 연구가 [Fatma2015][13]와 유사한 점은 MapReduce(Hive)와 Spark 를 비
교하고 이를 프로파일링하고 리소스 사용량을 정량적으로 측정하여 두 시스템의
차이를 보였다는 것이다.
하지만 본 논문은 [Fatma2015][13] 와는 다르게 고성능 PC 아닌 저사양의
클러스터(comodity cluster)를 이용하여 실험이 진행되었다. 소규모의 클러스터
에서 동작을 관찰 함으로써, 리소스가 부족할 때의 MapReduce(Hive)와 Spark
시스템의 동작을 관찰하였다. 또한 Json 형식의 SNS data등의 실제 데이터를 사
용하여 테스트를 진행하였고, 파케이(parquet), ORC, 시퀀스(Sequence) 파일등
다양한 워크로드로 실험 되었다. [Fatma2015][13] 에서는 다루지 않은 SQL 쿼리
(Join, Aggregation, Scan)도 실험되었다. Spark에 대한 다양한 튜닝 설정을 가지
고 (예를 들면 driver memory, executor memory, executor core등) 다양한 시스템
9
리소스 사용량에 따른 처리율을 측정하였다. Spark의 신규 기능인 DataFrame도
테스트되었다. DataFrame은 SQL을효율적으로사용하기위하여새로추가된기
능이며, RDBMS의테이블과유사한개념이다.컬럼정보를포함한테이블데이터
(DataFrame)를 기존 RDD 데이터 처럼 메모리에 캐싱하여 SQL을 수행을 함으
로써 매우 빠른 성능을 보인다. 본 연구에서는 이 DataFrame을 실제 SNS(Tweet)
데이터에서 여러 가지 쿼리를 수행하도록 하여 기존 Spark-sql과 Hive 시스템에
서의 실행 시간과 비교해 보았다.
Spark Benchmark[15]
Spark의성능을평가하기위한툴을제공한다.각종마이크로벤치마크와머신
러닝 알고리즘, SQL 문을 제공한다. 시스템 사용을 측정하기 위한 프로파일 툴도
같이 제공된다. 단지 성능 비교 군에 대한 툴은 제공되지 않는다. Spark 스트리밍
데이터 테스트도 가능하다.
10
제 2 장 시스템 구성 및 실험 설계
2장에서는 실험에 사용되었던 시스템 구성 및 데이터 워크로드 상세, 또 어떤
실험들이 수행 되었는지 기술할 예정이다.
2.1 시스템 사양
실험에 사용된 환경은 두 가지 이다. 하나는 일반적이 사양을 가진 1개 마스
터 노드와 6개의 슬레이브 노드들로 구성된 소규모의 클러스터 환경이며 나머지
하나는 1개의 고성능 PC 이다. 편의를 위하여 이후부터는 TEST1 과 TEST2 라
고 명하도록 하겠다. TEST1은 클러스터 테스트에 사용되었고, TEST2는 메모리
사이즈에 따른 결과를 보기 위해 사용되었다.
Test 환경 TEST1 TEST2
OS Linux(Ubuntu 14.01) Linux(Ubuntu(14.01)
ProcessorIntel(R) Core(TM) i7-4770
CPU @ 3.40GHz 64bit /core: 4
Intel(R) Core(TM) i7-5820
CPU @ 3.30GHz 64bit / core : 6
Ram 8G * 6 = 48G 64G
Hadoop 2.7.0(Yarn) 2.7.0(Yarn)
Scala 2.11.6 2.11.6
Hive 1.3.0 1.3.0
Spark 1.4.1 1.4.1
Java 1.6.0 34 1.6.0 34
Node 구성 1 master, 6 slaves Single node
표 2.1 시스템 사양
11
2.2 워크로드(Workloads)
Intel사의 Hibench를 사용하여 테스트를 진행하였다. 해당 벤치마크에서 제공
되는 10가지 micoro workloads 중 8개를 사용하여 테스트 되었다. (Spark 미 지원
workload 2개는 실험에서 제외되었다.) 테스트된 벤치마크는 아래 표와 같다. 이
들의 기본 입력 형식은 text이다.
Category Workloads
Sort
Word CountMicro Benchmarks
Tera Sort
Web Search PageRank
Bayesian ClassificationMachine Learning
K-means Clustering
Scan
JoinSQL
Aggregation
표 2.2 HiBench 벤치마크
2.2.1 워크로드 규모 (Workloads Scale Factor)
HiBench에서 제공하는 workload scale factor는 tiny, small, large, huge, gi-
gantic, bigdata 이다. 본 논문에서는 주로 large 와 huge 의 규모로 테스트를 수행
하였다. 해당 데이터의 규모는 진행된 실험에 따라 다르며 아래 표와 같다. Tera-
sort 기준으로 gigantic은 300G, bigdata는 1T 정도의 크기로 테스트 된다.
2.2.2 마이크로 벤치마크(Micro Benchmark)
Sort, Word Count, Tera Sort는 하둡 분산 환경을 테스트 하는데 널리 사용되
는 micro benchmark이다. Sort와 Word Count는 실제 환경에서의 Map/Reduce
12
Workload /scale large huge
Aggregation 35M 350M
Join 180M 1.78G
Kmeans 3.7G 18.7G
Pagerank 250M 2.78G
Sort 315M 2G
Wordcount 2G 29.7G
Bayes 360M 1.75G
Terasort 3G 30G
Scan 175M 1.7G
표 2.3 Workload 규모 (Scale Factor)
job을 대변하는데 있어서 주요 부분을 차지한다. (Map Reduce 작업은 데이터를
변환하는 한가지 class 와 변환된 커다란 크기의 데이터로부터 작은 양의 관심
데이터를 추출하는 두 가지 class로 구성된다.)
정렬 (Sort)
Sort프로그램은하둡프레임워크가 Sort를수행하는결과를그대로출력한다.
Map함수와 reduce함수 모두 기본 정의만 사용한다. (즉, emit만 수행한 결과인
key-value쌍을 출력 값으로 사용한다.) 데이터의 생성은 Hadoop 배포판에 내장된
RandomWriter 와 RandomTextWriter가 사용되었다.
워드 카운트 (Word Count)
Word Count 프로그램은 입력된 각각의 단어에 대한 (단어, 1)쌍을 emit 하여
수행된다. Sort 와 마찬가지로 데이터의 생성은 Hadoop 배포판에 내장된 Ran-
domWriter 와 RandomTextWriter가 사용되었다.
13
Terasort
하둡 배포판에 포함된 TeraGen 프로그램을 이용하여 생성된 100byte 단위의
1000만개 레코드를 정렬한다. Map 단계에서 combiner는 단어 각각에 대한 부
분 합을 수행한다. 그리고 Reduce 단계에서는 각각의 Word에 대한 최종 합계를
계산한다.
2.2.3 웹 어플리케이션(Web Application)
페이지 랭크(PageRank)
해당 PageRank workload는 SmartFrog라는 분산 시스템 관리용 오픈 소스
에서 사용되었다. PageRank 알고리즘은 검색엔진에서 널리 쓰이는 링크 분석
알고리즘으로 웹 페이지에 참조 링크의 개수에 따라 순위를 계산한다. PageRank
workload는 연결된 Hadoop 작업들로 이루어져있으며 특정 수렴 조건에 만족하
도록 반복작업이 진행된다. Wikipedia 페이지와 페이지간의 링크로 된 데이터베
이스가 이 Workload의 입력으로 사용되었다.
Pagerank large huge
Pages 500000 5000000
num iterations 3 3
block 0 0
block width 16 16
표 2.4 Pagerank 설정
2.2.4 SQL
Scan, Join, Aggregation의세가지 SQL문이평가대상이다.이들의입력데이
터는 Text, 또는 Sequence 형태의 문서이다. 이들의 모델은 웹 환경에서 사용되는
비정형문서가모델이되었다.테이블은 Uservisits과 Rankings두개로구성된다.
Uservisits 은 각각의 서버에 저장되는 로그 데이터 형식이며, Rankings는 웹사이
14
트와 그 사이트의 정보(페이지 랭크, 평균 사용자 상주 시간 등) 목록이다. 이들의
스키마는 아래와 같다.
Table Name Schema
Uservisits
sourceIP STRING, destURL STRING, visitDate STRING, adRevenue DOUBLE, userAgent STRING,
countryCode STRING, languageCode STRING,
searchWord STRING, duration INT
Rankings pageURL STRING, pageRank INT, avgDuration INT
표 2.5 테이블 Uservisits 와 Rankings 의 스키마
평가항목에 따른 SQL 문은 아래와 같이 명시한다. 로우(raw)데이터인 Se-
quence 파일을 읽어와 Metastore에 저장될 수 있는 테이블을 생성 후, SQL 문을
수행한다. 여기서 경로는 임의의 HDFS 경로 이다.
15
평가 항목 SQL statements
SCAN
CREATE EXTERNAL TABLE uservisits
(sourceIP STRING,destURL STRING,visitDate STRING,adRevenue DOUBLE,userAgent
STRING,countryCode STRING,languageCode STRING,searchWord STRING,duration INT )
ROW FORMAT DELIMITED FIELDS TERMINATED BY ’,’
STORED AS SEQUENCEFILE LOCATION
’hdfs://localhost:9000/HiBench/Scan/Input/uservisits’;,
CREATE EXTERNAL TABLE
uservisits copy (sourceIP STRING,destURL STRING,visitDate STRING,adRevenue
DOUBLE,userAgent STRING,countryCode STRING,languageCode STRING,searchWord
STRING,duration INT )
ROW FORMAT DELIMITED FIELDS TERMINATED BY ’,’ STORED AS
SEQUENCEFILE LOCATION
’hdfs://localhost:9000/HiBench/Scan/Output/uservisits copy’;,
INSERT OVERWRITE TABLE uservisits copy
SELECT * FROM uservisits;
Aggregation
CREATE EXTERNAL TABLE uservisits
(sourceIP STRING,
destURL STRING,visitDate STRING,adRevenue DOUBLE,userAgent
STRING,countryCode STRING,
languageCode STRING,searchWord STRING,duration INT )
ROW FORMAT DELIMITED FIELDS TERMINATED BY ’,’
STORED AS SEQUENCEFILE LOCATION
’hdfs://localhost:9000/HiBench/Aggregation/Input/uservisits’;,
CREATE EXTERNAL TABLE uservisits aggre
( sourceIP STRING, sumAdRevenue DOUBLE) STORED AS SEQUENCEFILE
LOCATION ’hdfs://localhost:9000/HiBench/Aggregation/Output/uservisits aggre’;,
INSERT OVERWRITE TABLE uservisits aggre
SELECT sourceIP,SUM(adRevenue)
FROM uservisits GROUP BY sourceIP;
Join
CREATE EXTERNAL TABLE rankings
(pageURL STRING, pageRank INT, avgDuration INT) ROW FORMAT DELIMITED FIELDS
TERMINATED BY ’,’ STORED AS SEQUENCEFILE LOCATION
’hdfs://localhost:9000/HiBench/Join/Input/rankings’;
CREATE EXTERNAL TABLE
uservisits copy (sourceIP STRING,destURL STRING,visitDate STRING,adRevenue
DOUBLE,userAgent STRING,countryCode STRING,languageCode STRING,searchWord
STRING,duration INT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ’,’ STORED AS
SEQUENCEFILE LOCATION ’hdfs://localhost:9000/HiBench/Join/Input/uservisits’;,
CREATE EXTERNAL TABLE rankings uservisits join
( sourceIP STRING, avgPageRank DOUBLE, totalRevenue DOUBLE)
STORED AS SEQUENCEFILE LOCATION
’hdfs://localhost:9000/HiBench/Join/Output/rankings uservisits join’;
표 2.6 평가 항목 별 SQL 문16
Bayes large huge
Pages 100000 500000
Classes 100 100
ngrams 2 2
표 2.7 Bayes 설정
2.2.5 머신러닝 알고리즘 (Machine Learning Algorithms)
베이지안 분류기 (Bayes)
베이지안 분류기 workload는 naıve Baysian의 훈련 부분을 구현하였다. 4개의
연결된 하둡 잡으로 구성되며 이들은 N-Gram 알고리즘을 이용하여 특정 단어를
추출한다.이때입력데이터는 text형식의웹페이지이고, Tf-idf를계산한다.각각
의단어에대하여가중치를부여하고,정규화을수행한다.해당 workload의입력은
위키피디아(wikipedia) 덤프의 일부이다. 위키피디아(Wikipedia) 덤프 파일은 첫
째로 split 작업으로 built를 만든다. (Mahout의WikipediaXmlSplitter이용한다.)
그 다음, built를 이용하여 text 견본을 준비한다. 이 text견본은 최종적으로 여러
개의 파일로 분산되어 벤치마크의 입력으로 사용된다.
K-means
K-means 클러스터링 Workload는 데이터 마이니에 주로 사용되는 K-means
알고리즘의 구현이다. K-means란 주어진 데이터를 K개의 클러스터로 묶는 알
고리즘으로, 각 클러스터와 거리 차이의 분산을 최소화하는 방식으로 동작한다.
입력은 샘플 데이터의 집합으로 각각의 샘플은 각각의 공간 벡터(numerical d
–dimensional vector)를대변한다.첫번째에서하둡잡은반복적으로수행되며각
각의클러스터의중심을계산한다.이러한반복(iteration)작업은다른 iteration이
수렴하거나,사용자가설정한최대값에도달하게되면멈춘다.이후에각각샘플이
하나의 클러스터에 할당되어 클러스터링(Clustering) 작업이 수행된다. Hibench
17
Kmeans large huge
num of clusters 5 5
dimensions 20 20
num of samples 20000000 100000000
samples per input file 4000000 20000000
max iteration 5 5
k 10 10
표 2.8 K-means 설정
의 램덤 데이터 생성기를 이용해 각각의 Workload의 입력으로 들어가게 된다.
이때 랜덤 데이터 생성기는 statict distribution을 수행한다.
또한 아래 표는 Workload 크기에 따른 셔플(Shuffle) 단계의 데이터 크기를
명시하였다. 멀티 노드로 테스트 될 시에 셔플 데이터(Shuffle Data)로 표시된 내
용이실제네트워크상에서이동을하는데이터크기이다. Sort의경우입력데이터
(60G 기준) 그대로 같은 크기의 데이터(60G)가 셔플 단계에 적용되므로 네트워크
비용이 많이 발생하지만, WordCount의 경우 커다란 입력(60G) 중에 소수의 관심
데이터(3.99G)만셔플단계에적용된다.이러한데이터흐름은실제어플리케이션
실행시 리소스 사용과 수행 시간에 밀접한 영향을 끼치게 된다.
workload Job job/Map InputMap Output
(Combiner Input)Shuffle Data (Combiner Output) Job/Reduce output)
Sort Sort 60G 60G 60G(no combiner) 60G
WordCount WordCount 60G 85G 3.99G(no combiner) 1.6G
TeraSort TeraSort 1T 139G 139G(no combiner) 1T
Dangling-Pages 1.21G 81.7K 672B 30B
Update-Ranks 1.21G 5.3G 5.3G(no combiner) 1.21GPagerank
SortRanks 1.21G 86M 86M(no combiner) 167M
Feature 1.8G 52G 39.7G 35G
TfIdf 35G 26G 22.8G 13.3G
Weight-Summer 13.3G 16.8G 8.7G 8.2GBayesian Classification
Theta-Normalizer 13.3G 5.6G 163K 8.6K
Centroid-Computing 66G 67G 303K 4.6KK-means Clustering
Clustering 66G 66.3G (no combiner) no reducer
표 2.9 셔플 단계의 데이터 사이즈 (입력 데이터 60G 기준)
18
2.2.6 Workload에 따른 데이터 규모 상세
다음은 SQL 테스트 진행 시 테스트 되는 레코드의 개수이다. Scan, Join, Ag-
gregation 에 대해서 다음과 같은 규모의 데이터에 대해서 쿼리가 수행된다. 이는
실제 웹 어플리케이션등에서 로그 분석 할때 사용되는 데이터 사용패턴과 유사하
며 다음과 같이 커다란 테이블(Uservisits)과 작은 테이블(PageRankings)의 조합
으로 많이 사용된다.
large hugesql /records count
Uservisits PageRanks Uservisits PageRanks
Scan/Aggregation/Join 1000000 120000 10000000 1200000
표 2.10 SQL 테스트 시 규모(Scale factor)별 테이블 레코드수
19
제 3 장 실험 결과
3.1 전체 테스트 결과
Exe
cu
tio
n T
ime
(se
c)
workloads
Benchmark Test Result
hivespark
1.6
2.35
3.89
2.64
1.79
1.13
1.78 1.64
1.63
0
50
100
150
200
250
300
350
400
Aggregation
JoinKm
eans
Pagerank
Scan
SortW
ordcount
Bayes
Terasort
그림 3.1 Hive / Spark 실행시간 비교
해당 테스트는 위의 표[2.1] 의 TEST2 실행 환경에서 측정되었다. 워크로드의
크기는 large이며, driver memory : 24G, executor memory 12G, executor 개수 2
개, executor core 2로 설정 되었다. 위와 같이 Spark가 Hive보다 대부분의 실험에
서 1.13X에서 3.8X빠른결과를보였다.예상되는바와같이반복적인연산이다수
수행되는 머신 러닝 알고리즘인 k-means 와 web search 알고리즘인 Pagerank의
경우 차이가 두드러졌다. [그림 3.1]의 실험은 메모리 설정이 워크 로드 사이즈에
비해 여유롭게 설정되어 진행되었다. 메모리 크기가 처리하는 데이터 크기에 비해
20
작을 경우 k-means와 Pagerank에서 Hive의 수행 속도보다 몇 배에 이르는 속도
지연이 나타나기도 한다. 이후 장에서 메모리 설정에 따른 결과를 좀더 자세히 살
펴보도록 하겠다. 데이터 분석형 질의 (Join, Aggregation, Scan)의 경우 메모리의
사용이 많은 join에서 처리속도의 차이(2.35X)가 많이 났다. 해당 실험으로 반복
연산이많이수행되거나(K-means, Bayes, Pagerank등 ),메모리사용이많은연산
작업(Join)에 있어서 Spark가 더 유용함을 알 수 있다.
3.2 각 수행 알고리즘에 따른 Profile 결과 분석
System usage
Mbyte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
0 10 20 30 40 50 60
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30 35
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30 35
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
0 5 10 15 20 25 30 35
그림 3.2 Scan 결과
Hive와 Spark의 시스템적 특성을 알 수 있도록 각각의 벤치마크에 사용되는
시스템 사용량을 Profiling툴을 이용하여 측정해 보았다. Hive(MapReduce)(위)
과 Spark(아래) 이며 각각에 대한 메모리 사용량, CPU 사용량, I/O 사용량을
실험 시간에 따라 비교하였다.그림[3.1]과 같은 실험의 대한 프로파일링이며, 같
은 크기로 표지되었지만 Spark의 실행시간이 대체로 짧음을 감안하고 살펴보
도록 하겠다. 테스트 피씨의 메모리 총 크기는 64G이지만 설정 메모리가 30G
21
System usageM
byte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60
Mbyte
Time
IO(Hive)
write read
0
2e+07
4e+07
6e+07
8e+07
1e+08
1.2e+08
1.4e+08
0 10 20 30 40 50 60
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30 35 40
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
0 5 10 15 20 25 30 35 40
그림 3.3 Aggregation 결과
System usage
Mbyte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60 70 80 90 100
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60 70 80 90 100
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
140000
0 10 20 30 40 50 60 70 80 90 100
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30 35 40
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40
Mbyte
Time
IO(Spark)
write read
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
0 5 10 15 20 25 30 35 40
그림 3.4 Join 결과
정도로 되어있어 메모리 그래프의 30G Used의 사용이 나타내는 것은 가용메
모리를 전부 사용하고 있다는 뜻으로 해석이 가능하다. K-means를 비롯한 머
22
System usageM
byte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 50 100 150 200 250 300 350 400
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 50 100 150 200 250 300 350 400
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
0 50 100 150 200 250 300 350 400
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 20 40 60 80 100 120
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 20 40 60 80 100 120
Mbyte
Time
IO(Spark)
write read
0
2e+07
4e+07
6e+07
8e+07
1e+08
1.2e+08
0 20 40 60 80 100 120
그림 3.5 K-means 결과
System usage
Mbyte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 50 100 150 200 250 300
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 50 100 150 200 250 300
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
200000
0 50 100 150 200 250 300
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 20 40 60 80 100 120
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 20 40 60 80 100 120
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
0 20 40 60 80 100 120
그림 3.6 Pagerank 결과
신러닝 알고리즘,Pagerank 알고리즘 프로파일링 결과는 비슷한 양상을 보였다.
Hive(MapReduce)의 경우 CPU-bound 하고 IO bound 한 반면 Spark의 경우
23
System usageM
byte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60 70
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60 70
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
140000
0 10 20 30 40 50 60 70
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30 35 40 45
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40 45
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
140000
0 5 10 15 20 25 30 35 40 45
그림 3.7 Bayes 결과
System usage
Mbyte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60 70
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60 70
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
140000
0 10 20 30 40 50 60 70
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30 35 40
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30 35 40
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
0 5 10 15 20 25 30 35 40
그림 3.8 Wordcount 결과
Memory 사용량에서 Hive(MapReduce)보다 앞섰다. Machine learning 의 경우
Spark RDD Caching의사용으로메모리사용이메모리병목현상을유발하였지만
24
System usageM
byte
Time
Memory(Hive)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
0 5 10 15 20 25 30
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 5 10 15 20 25 30
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 5 10 15 20 25 30
Mbyte
Time
IO(Spark)
write read
0
5000
10000
15000
20000
25000
30000
0 5 10 15 20 25 30
그림 3.9 Sort 결과
System usage
Mbyte
Time
Memory(Hive)
free cach buff used
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
0 20 40 60 80 100 120
Mbyte
Time
CPU(Hive)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 20 40 60 80 100 120
Mbyte
Time
IO(Hive)
write read
0
20000
40000
60000
80000
100000
120000
0 20 40 60 80 100 120
Mbyte
Time
Memory(Spark)
free cach buff used
0
10000
20000
30000
40000
50000
60000
70000
0 10 20 30 40 50 60 70
Mbyte
Time
CPU(Spark)
siqhiq
waiidle
sysusr
0
20
40
60
80
100
0 10 20 30 40 50 60 70
Mbyte
Time
IO(Spark)
write read
0
20000
40000
60000
80000
100000
120000
0 10 20 30 40 50 60 70
그림 3.10 Terasort 결과
분석 형 질의들의 경우 각 리소스 들의 평이한 사용이 유지되었다. 실제 그래프
면적의 총량을 계산 하지 않았지만, Hive(MapReduce)는 CPU 사용, I/O 사용이
25
Spark보다 많고 Spark의 경우 메모리의 사용량이 많았다.
3.3 확장성 테스트 (Scalability)
TEST1환경에서 1개 node∼6개 node로 노드 개수를 늘려 같은 워크로드로
실험하여 보고 두 시스템의 실행 속도 추이를 관찰하였다. 실험 워크로드의 크
기는 huge 로 설정하였다. 대체적으로 Hive(MapReduce)가 일정한 기울기로 실
행 속도가 줄어들어 안정적인 확장성를 보임을 알수 있었다. 반면 Spark의 경우
Hive(MapReduce) 와 비슷하게 노드 수가 증가함에 따른 확장성을 보이기도 했
으나 일부 워크로드에서 node 수가 증가해도 성능이 비슷하거나 오히려 나빠지는
경우도 보였다. 그림[3.10]는 Bayes 와 Kmeans 알고리즘에 대한 결과이다. Spark
의 경우 노드 1개 일때 높은 실행시간을 가진 반면 클러스터가 커지면 가파른
기울기로 떨어짐을 알수 있다. 이는 클러스터의 합산 메모리가 해당 알고리즘을
실행하기 부족 할 경우, 실행 시간이 기하급수적(약 4X)으로 늘어나는 현상으로
설명할 수있다. Hive(MapReduce) 또한 1개 노드와 2개노드 사이에 실행 속도 차
이가 1.5X∼2X정도로많은차이를보이지만상대적으로그변화폭은적다. Spark
의 경우 노드 5∼6크기로 클러스터가 커지면 그전보다 실행 속도가 더 커져 역전
을 되는 현상이 발생하였다. 반면 Hive 는 안정적으로 클러스터가 확장됨에 따라
일정하게 실행속도가 줄어들고 있다.
Scalability
0
50
100
150
200
250
300
350
400
450
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Bayes
HiveSpark
0
2000
4000
6000
8000
10000
12000
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
K−means
HiveSpark
0
20
40
60
80
100
120
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Pagerank
HiveSpark
그림 3.11 Machine learning 결과
26
Scalability
0
10
20
30
40
50
60
70
80
90
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Scan
HiveSpark
0
20
40
60
80
100
120
140
160
180
0 1 2 3 4 5 6E
xe
cu
tio
n T
ime
(s)
# of nodes
Join
HiveSpark
0
20
40
60
80
100
120
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Aggregation
HiveSpark
그림 3.12 sql 결과
Scalability
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Wordcount
HiveSpark
0
50
100
150
200
250
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Sort
HiveSpark
0
500
1000
1500
2000
2500
3000
3500
4000
0 1 2 3 4 5 6
Exe
cu
tio
n T
ime
(s)
# of nodes
Terasort
HiveSpark
그림 3.13 Wordcount, Sort, Terasort 결과
그림[3.11]은 Scan, Join, Aggregation 의 SQL 실행에 대한 결과이며, 대체로
Hive 와 Spark가 비슷한 기울기로 떨어지며 안정적인 확장성을 보임을 알수 있
었다. 단지 Hive가 속도가 더 빨라지는 현상이 그림[3.11]의 Scan과 Aggregation
과 그림[3.12] Sort에서 나타났다. 그림 [3.1]에서는 모든 워크로드에서 Spark가 빨
랐으나 해당 데이터의 스케일이 5개까지 커지자 해당 환경에서 속도가 이전보다
늦어지는 역전 현상이 일어났다. Scan , Aggregation 과 Sort의 경우 메모리에 민
감한 작업이 아니고, 작업 단계(Stage)가 짧은 잡들이다. 즉, Spark의 장점인 중간
데이터가 메모리에 캐시되어 성능이 좋아지는 특성을 이용할 수 있는 작업이 아닌
경우 데이터 크기와 환경에 따라 Hive(MapReduce)보다 낮은 성능을 나타낼 수
있음을 알수 있다.
27
3.4 리소스 사용에 따른 Spark 성능비교
Spark와 Yarn에 있어서 중요한 시스템 자원은 메모리와 CPU 이다. 디스크 입
출력과 네트워크 입출력 역시 Spark의 성능에 영향을 미치지만 현재까지는 Spark
와 Yarn둘다이들을적극적으로관리할수있는환경은제공하고있지않다. 1장에
서간단하게설명하였듯이, Spark cluster에는한개의 driver프로세스와여러개의
executor프로세스가존재하고,이들을관리하기위한설정변수가있다. executor
개수, executor core 개수, executor 메모리 , drvier 메모리 등이다. executor core
는 동시에 실행할 수 있는 task 개수, executor 메모리는 힙사이즈를 나타낸다.
메모리 변수들은 Spark가 cache 할 수 있는 메모리 총량에 영향을 줄 뿐더러 셔플
데이터 구조의 최대 크기에 영향을 미친다. 이것은 grouping, aggregations, join
작업에 영향을 줄 수 있다.
그림 3.14 Spark와 Yarn 메모리 구조도
그림[3.13] 과 같이 Yarn은 nodemanager에 설정되어있는 메모리를 초과해서
는 executor메모리를할당하지않는다. YARN은항상 yarn.scheduler.minimum-
allocation-mb 배수만큼 올림만큼 메모리를 요청한다.(기본값 1G) 그리고 Spark
는 YARN 에 메모리를 요청하기 전에 SPARK EXECUTOR MEMORY,SPARK
DRIVER MEMORY 에 Overhead(추가) 메모리를 더해 요청한다. 이는 executor
나 driver 모두 동일하다. Spark와 Yarn는 아래 표와 같이 최대 가용 메모리를
28
YARN = 설정 메모리 + Overhead ( minimum-allocation-mb 배수 만큼 올림 )
Overhead = max(설정된 메모리 X 0.1, (최소값)384MB)
Cache = (설정 메모리 - Runtime 이 사용하는 메모리(약1G)) *
spark.storage.memoryFraction(0.6) * spark.shuffle.memoryFraction(0.4) )
표 3.1 Spark 가용 메모리 계산
결정한다.
다음 장에서는 이러한 변수들을 어떻게 사용하여 최적의 성능을 사용할 수
있을 지 확인하여보겠다.
3.4.1 메모리 크기에 따른 결과 분석
다음 실험은 executor 메모리 사이즈를 2 ∼ 12G로 두고 테스트를 진행하였다.
테스트 환경은 TEST2, 데이터의 크기는 large이다.
20
25
30
35
40
45
50
2 4 6 8 10 12
Exe
cu
tio
n T
ime
(s)
Scale
sql
AggregationJoin
Scan
10
20
30
40
50
60
70
2 4 6 8 10 12
Exe
cu
tio
n T
ime
(s)
Scale
Sort and Wordcount
SortWordcount
Terasort
0
100
200
300
400
500
600
700
800
900
1000
2 4 6 8 10 12
Exe
cu
tio
n T
ime
(s)
Scale
Machine learning and pagerank
KmeansPagerank
Bayes
그림 3.15 설정 메모리 크기에 따른 실행시간 비교
그래프는각각의워크로드를관찰하기좋게하기위해세가지종류로분할하여
표현하였다.첫번째그래프는 Scan, Join, Aggregation SQL문을실행한결과이다.
워크로드의 크기에 비하여 필요 메모리의 크기가 많지 않았는지 큰 변화는 보이지
않았다. 두번째는 Sort, Terasort, Wordcount 이다. Wordcount는 2G∼4G 크기일
때 성능 개선이 보였으나 그 이후에 측정값은 모두 비슷하였고, Sort와 Terasort
는 메모리가 크면 클수록 좋은 결과를 보여주었다. 세번째 그래프는 머신러닝 알
29
고리즘인 K-means 와 Bayes , 그리고 Pagerank를 실험하였다. K-means의 경우
속도가 2G 설정일 때와 12G일때 약 9X 차이가 발생하는 등 큰 폭의 성능향상을
보였고, Pagerank는약간의성능이좋아졌고(1.3X), Bayes는거의영향이없었다.
그림[3.14]참고
Exe
cu
tio
n T
ime
(se
c)
# of Executor
Executor number test
Executor 2Executor 4
0
10
20
30
40
50
60
70
80
90
100
Aggregation
JoinKm
eans
Pagerank
Scan
SortW
ordcount
Bayes
Terasort
그림 3.16 Executor 개수 설정 비교
3.4.2 Core 개수와 Executor 개수 설정에 따른 성능 분석
해당 테스트는 TEST1 환경에 싱글노드 환경에서 수행되었으며 TEST1의
CPU core 개수는 4개이다. 즉 virtual core는 최대 8개까지 동작 할수 있다. 그
림[3.15] yarn executor core 개수를 2로 고정하고, executor의 개수를 2와 4로
설정하여 실행하여 보았다. 나머지 설정은 동일하다. 결과 동작하는 task가 4와 8
로보았다.그결과 8일때 K-means와 Pagerank, Terasort에서각각 3X,1.5X,1.5X
정도의 지연이 발생함을 확인 할 수 있었다.
해당 실험으로 설정에 따라 크게는 9X까지 성능이 차이가 났다. 테이터에 알
30
맞는 적정한 힙 사이즈 설정과 지원되는 core 개수에 따른 프로세스 개수 설정이
성능에 큰 영향을 미치는 것으로 파악되었다. Spark 어프리케이션의 최적 성능
을 개선하고자 한다면 사용자가 해당 요소들의 튜닝(tuning)을 수행해 볼 것을
권장한다.
0
5
10
15
20
25
30
35
40
45
sequence(uncompressed)
ORC(uncom
pressed)
parquet(uncompressed)
ORC(gzip)
parquet(gzip)
ORC(snappy)
parquet(snappy)
Exe
cu
tio
n t
ime
(s)
File Format(Compression)
Compression and File format Comparison (Table Creation)
HiveSpark
그림 3.17 파일에 따른 메타스토어(Metastore) 테이블 생성 시간 비교
3.5 파일 타입과 파일 압축 코덱에 따른 결과
해당 실험은 HiBench에서 제공하는 DataGen 프로그램을 이용하여 데이터를
생성한 다음 Sequence file로 저장한 후 이를 가공하여 수행되었다. 생성된 스키마
는 표[2.3]과 같다. Hive CLI(Comand line interface) 와 Spark-sql CLI환경에서
같은시퀀스파일(Sequence file)을메타스토어서버에테이블형태로저장한다음,
다시 읽어 해당 압축(Compression)으로 적용하여 Parquet과 ORC 파일로 테이블
생성 한 후, Join 과 Aggregation을 수행 후 실행시간을 비교해 보았다. 그림[3.16]
31
0
5
10
15
20
25
sequence(uncompressed)
ORC(uncom
pressed)
parquet(uncompressed)
ORC(gzip)
parquet(gzip)
ORC(snappy)
parquet(snappy)
Exe
cu
tio
n t
ime
(s)
File Format(Compression)
Compression and File format Comparison (Aggregation)
HiveSpark
그림 3.18 Aggregation 시간 비교
에서 보듯이 Sequence file에서 Sequence table을 생성하는 것이 제일 빨랐으며,
Hive와 Spark의 시스템 차이는 거의 없었다. Parquet 파일 형식의 경우 메타스
토어 테이블로 변환하는 작업은 Hive에서 Gzip 압축이 제일 느렸고, 압축옵션이
없는 것과 Snappy은 비슷했다. Spark에서는 Uncompressed 가 제일 느렸으며 나
머지 두 압축 형식은 속도가 비슷했다. 실제 연산속도 또한 Hive와 Spark이 약간
다른 양상을 띠었다. ORC파일 형식의 경우 전반적으로 Parquet보다 1.5배정도의
빠른 테이블 저장 속도로를 보였다. ORC는 압축을 적용하지 않는게 제일 빨랐
으며 ORC-Gzip과 ORC-Snappy는 비슷한 속도를 보였다. Hive 와 Spark 에서의
Paquet파일과 ORC파일 저장시간은 10X에서 30X배까지 크게 차이가 났다. 그림
[3.17] Aggregation연산에서 Hive에서는 ORC-Snappy가, Spark에서는 Parquet-
Uncompressed가 제일 빠르게 수행되었다. 특이한 점은 Hive에서는 ORC가 빠
른 반면, Spark 에서는 ORC-Snappy는 Parquet-Snappy보다 느렸다. 전반적으로
ORC의성능이 1.2X가량좋다.그림[3.18] Join연산에서는모든경우에서 ORC가
32
0
10
20
30
40
50
60
sequence(uncompressed)
ORC(uncom
pressed)
parquet(uncompressed)
ORC(gzip)
parquet(gzip)
ORC(snappy)
parquet(snappy)
Exe
cu
tio
n t
ime
(s)
File Format(Compression)
Compression and File format Comparison (Join)
HiveSpark
그림 3.19 Join 시간 비교
우수했다. Spark에서는 3X가량, Hive에서는1.2X가량 빠른 속도를 보였다. 압축
코덱의경우 ORC-Uncompressed와 ORC-Snappy가비슷하게좋았고(Hive,Spark
모두에 해당된다.) Parquet의 경우 Sanppy가 가장 좋았으나, 서로 간의 차이가 크
지 않았다.
결론 적으로 파일간의 압축 코덱은 속도에 약간의 영향을 주나 크지 않았고
Snappy 압축이 명령 실행시 조금 빠르게 수행되었다. 파일 타입은 전반적으로
ORC-Snappy 압축은 압축하여 테이블 생성하는 시간도 빠르고 연산 속도도 빠르
므로 사용하는 것이 전체 시스템의 속도를 빠르게 할 수 있는 방법이 됨을 확인할
수 있었다. 또한, 이번 실험에서 Sequence 파일이 저장된 상태에서 Join 연산속
도가 가장 빠름을 알 수 있었다. (실제 연산 속도는 느리나 파일 생성시간이 거의
들지않아 결과적으로 빠르다.) 파일을 새로운 형식으로 압축하고 저장하는 시간도
상당하므로 파일 생성 시간과 연산 속도에 대한 득과 실을 계산하여 어떠한 데이
터 관리를 할 것 인지 생각해 봐야 할것이다. 이러한 압축 형태/파일 저장 방식의
33
특징을 반영한다면 시스템을 설계할 때 참고가 될 것이다.
3.6 병렬성(Parallelism) 테스트 결과
Exe
cu
tio
n T
ime
(se
c)
SQL
MapReduce number set TEST
HiveSpark
0
10
20
30
40
50
60
70
80
90
100
Aggregation(Not set)
Aggregation(Map 12/R
educe 6)
Join(Not set)
Join(Map 12/R
educe 6)
그림 3.20 map reduce 개수 설정 비교
[그림3.19] 의 경우 멀티 노드 클러스터 환경에서 Hive와 Spark 에서 Aggre-
gation과 Join 작업 수행 시 map/reduce의 개수를 12개 6개로 설정했을 시와
설정하지 않았을 시를 비교하였다. 결과 Hive의 경우 map/reduce를 설정 하였을
때 더 느려졌고, Spark의 경우 더 빨라졌다. Map/Reduce의 개수를 설정하지 않
게 되면 해당 workload에서는 설정 값보다 적은 개수 연산이 동작하게 된다. 이에
따라 Hive에서 Map/Reduce의 개수를 설정 했을 때 Reduce 단계 전IO가 더 많
이 일어나고 이에 따라 수행 시간이 더 길어짐을 확인 할 수 있다. Spark의 경우
전체수행시간 중 MapReduce 증가 분에 따른 각 노드 간의 network overhead에
비교하여, 많은 개수의 MapReduce의 메모리 내 연산 처리 속도가 전체적으로 더
빨라서 설정 했을 때 빨라지는 결과를 볼 수 있다.
34
3.7 SNS 데이터 테스트(Json file)
본실험에서는실제데이터를가지고테스트를수행하였다. Tweet이라는 SNS
데이터 로그로 Json 파일 형식으로 저장되어있다. 이를 Hive CLI 와 Spark Sql
CLI 와 Spark DataFrame API로 scala 언어로 같은 내용의 쿼리를 수행하도록
구현 한 것, 이렇게 3개의 대조군으로 실험을 진행하였다. 1G 크기의 하루 치 데
이터를 가지고 데이터 로딩 속도와 쿼리 3개를 가지고 실행 속도를 측정하였다.
실험에 사용된 SQL 쿼리문은 표[3.3]과 같다. 테스트는 TEST1 환경의 멀티노드
환경에서 수행되었다.
Exe
cu
tio
n T
ime
(se
c)
Query
Hive vs Spark sql vs Spark Data Frame
HiveSpark sql
Spark DataFrame
0
10
20
30
40
50
60
70
80
90
Read json
q1 q2 q3
그림 3.21 Tweet 데이터(json 파일) 처리 결과
실험 결과 Hive에서는 Json 파일을 로딩하여 파싱하는 시간이 많이 걸리고
Spark sql 은 0.5X, Spark DataFrame은 1초 이내의 빠른 로딩 속도를 보였다.
이외에 수행시간도 Hive와 Spark 의 경우 평군 7X의 차이가 났으며, Spark에
서는 Spark Data Frame을 이용한 쿼리 수행이 평균 2X 빨랐다. 데이터 크기를
35
{” id”:”53d8a5c79022699c8baa2f51”,”contributors”:null,
”text”:”tweet example”,
”geo”:{”type”:”Point”,”coordinates”:[42.68291626,-87.77269682]},retweeted”:false,
”in reply to screen name”:null, truncated”:false,”lang”:”en”,
”twitter entities”:{
”hashtags”:[{”text”:”snow”,”indices”:[66,71]}],
”urls”:[]}],
”user mentions”:[{”screen name”:”Tweet”,”name”:”Example of tweets”,
”id”:1234567890,”id str”:”1234567890”,
”indices”:[3,15]}]},”in reply to status id str”:null,
”id”:”297392058409308161”,”in reply to user id str”:null,
”favorited”:false,”in reply to status id”:null,
”retweet count”:0,”created at”:”Fri Feb 01 17:12:46 +0000 2013”,
”in reply to user id”:null,”id str”:”297392058409308161”,
”place”:null,
”user”:{
”location”:”LA, CA”,,”default profile”:false,,
”statuses count”:13095,,”profile background tile”:false,,
”lang”:”en”,,”profile link color”:”1F98C7”,,
”id”:134074166,,”following”:null,,”favourites count”:52,,
”protected”:false,,”profile text color”:”663B12”,,
”description”:”This is twitter example”,,”verified”:false,,
”contributors enabled”:false,,”profile sidebar border color”:”C6E2EE”,,
”name”:”heeran”,,”profile background color”:”C6E2EE”,,
”created at”:”Sat Apr 17 11:20:44 +0000 2010”,,
”default profile image”:false,,”followers count”:82,,
”profile image url https”:”https://tweet.com/image1 normal.jpg”,,
”geo enabled”:false,,”profile background image url”:”http://tweet.com/bg.gif”,,
”profile background image url https”:”https://tweet.com/bg.gif”,,”follow request sent”:null,,
”url”:”http://www.dream-pro.info”,,”utc offset”:32400,,
”time zone”:”LA”,,”notifications”:null,,
”profile use background image”:true,,”friends count”:56,,”profile sidebar fill color”:”DAECF4”,,
”screen name”:”rec 3”,,”id str”:”134074166”,,”profile image url”:”http://tweet.comimage1 normal.jpg”,,
”listed count”:25,,”is translator”:false
},”coordinates”:null
}
표 3.2 Tweet 데이터 예시
36
Top 10 Keyword
query 1
create table t1 asselect get json object(json, ” $.in reply to user id”) as in reply to user id,
get json object(json, ”$.id”) as id,
get json object(json, ”$.user.id”) as user id ,
get json object(json, ”$.user.time zone”) as time zone
from raw tweets
where json is not null;
create table t2 as
select get json object(json, ”$.user.id”) as user id,
get json object(json, ”$.entities.hashtags.text”) as text,
unix timestamp(get json object(json, ”$.created at”),”EEE MMM d HH:mm:ss Z yyyy”)
as ts created
from raw tweets
where json is not null;
create table result join as
select t1.id, t2.user id,t2.text,t2.ts created,t1.time zone
from t1 join t2 on (t1.in reply to user id = t2.user id);
select time zone , count(time zone)
from result join
group by time zone;
Followers Count
query 2
create table f table as,select get json object(json, ””$.id””) as id,
get json object(json, ””$.retweet count””) as r count,
get json object(json, ””$.user.followers count””) as f count,
from raw tweets,
where json is not null;
select id , f count
from f table
order by f count desc;
Retweet count
query 3select id , r count
from f table
order by r count desc;
표 3.3 Tweet 데이터(json 파일) 테스트 쿼리
37
10G∼100G 로 테스트 한 결과 Hive와 Spark의 갭은 줄어들었지만, 속도 차이
는 4X 이상 빨랐다. Spark DataFrame은 spark 1.3.0 부터 추가된 신규 개념으로
기존의 RDD에스키마를더한것으로 SQL실행의최적화를위해만들어졌다.아직
까지 HiveQL의 모든 문법을 제공하지는 못하지만 성능적으로 Spark의 SQL-On-
Hadoop 기능을 보다 효율적으로 사용할 수 있게 한다. Json 같은 semi-structured
데이터를 읽어 자동으로 스키마를 생성해주고, 전체 데이터를 들고 실행하지 않고
늦은실행(lazy execution)을통하여실행시필요한데이터만을로드하여실행하여
빠른 수행속도를 낼수있다.
38
제 4 장 결론 및 향후 연구
지금까지 SQL-On-Hadoop시스템의대표적인두시스템인Hive(MapReduce)
과 Spark를 비교하여 보았다. Yarn 상에서 동작하는 두 시스템이 할 수 있는 일은
비슷하였지만, 그 시스템의 사용은 구조적인 차이로 많은 차이가 나타난다.
이를 다각적으로 분석하기 위해, 8개의 벤치마크를 이용하였고 이러한 벤치마
크는 실제 웹 어플리케이션등의 데이터 사용패턴을 고 려한 실용적인 내용들이다.
정량적인 시스템 사용을 측정하기 위한 프로파일링 툴을 이용하였다. 각 벤치마
크 실행 특성상 조금씩 다른 패턴을 가지지만 대체로 Hive(MapReduce)의 경우
CPU 사용이 많았고 종종 이에 따른 병목현상이 관찰되었다.이와 반대로 Spark
는 RDD 캐싱으로 인한 메모리 병목 현상이 빈번히 발생하였고 이는 K-means 와
같은 이터레이션이 많은 작업에 더 잘 나타났다. 이는 메모리 크기가 더 커질 경우
성능을 더 높일 수 있는 가능성을 나타낸 것으로도 볼 수 있엇다.
Spark의성능결정요인중의하나로적절한시스템튜닝이필수적임을증명하
였다. Spark와 Yarn에실행에있어서메모리와 CPU의적절한사용은필수적이며
이를조정하기위해 executor메모리, executor개수, executor core개수등에따른
성능을 측정해 보았으며 시스템 사양에 따른 적정한 설정이 성능에 많은 영향을
줌을 보였다.
파일 형식과 압축 코텍 상의 차이에 따른 쿼리 실행 속도를 측정하여 가장 좋
은 시스템과 파일형식의 조합도 살펴보았다. 결론적으로 Parquet 과 ORC 파일은
ORC 파일이 좀더 압축률이 좋고 실행 성능이 좋았다. 압축 코덱은 해당 데이
터셋에서는 크게 차이를 보이지 않았다. 이들의 파일로 메타스토어의 테이블로
생성하는 시간이 상당하여, 이들이 애초에 저장된 형식이 아니라면, 변환 후 해
당 형식으로 사용하는 것에 전체 실행시간 득실을 고려한 선택적 검토가 필요할
것으로 보인다.
39
벤치마크에서생성된램덤데이터가아닌실제데이터를이용한실험도수행되
었다.이를위해서 Tweet데이터를가지고세가지로테스트해보았다. Hive, Spark
sql CLI 실행, Spark DataFrame 실행 으로 테스트 한 결과 Spark DataFrame에
서 상당히 빠른 결과를 얻었다. Spark DataFrame은 늦은 실행으로 Json 파일의
가장 큰 단점이 데이터 로드 및 파싱타임을 줄였고, 필요한 데이터만을 로드하여
실행함으로써 10X∼20배 이상의 빠른성능을 보여주었다.
결론적으로 실행 성능 기준으로 Spark가 대체적으로 우수함이 증명되었지만
이러한 우수한 성능이 발현되기 위해서는 Spark 사용에 있어서 불편함이 없을
정도의 데이터 량에 맞는 메모리 크기와, Core 개수등이 수반되어야 한다.
향후 연구는 기본적인 테스트만이 진행되었던 현재의 실험들을 심화해서 보다
다양한 데이터를 좀더 큰 규모도 진행할 예정이다.
40
참고문헌
[1] Apache. Spark. http://spark.apache.org
[2] Apache. Hadoop https://hadoop.apache.org
[3] HadoopMap/Reducetutorial.http://hadoop.apache.org/common/docs/
r0.20.0/mapredtutorial.html.
[4] Apache. Hive https://hive.apache.org
[5] Intel.HiBench. https://github.com/intel-hadoop/HiBench
[6] AMPLAB Big Data Benchmark. https://amplab.cs.berkeley.edu/ bench-
mark/
[7] BigSQL : Fatma Ozcan and Simon Harris. Blistering Fast SQL Accessto
Your Hadoop Data. http://www.ibmbigdatahub.com/blog/blistering-fast-
sql-access- your-hadoop-datal.
[8] Avrilia Floratou, Umar Farooq Minhas, Fatma ¨Ozcan. “SQLonHadoop:
Full Circle Back to SharedNothing Database.” Proceedings of the 2014
VLDB Endowment., Vol. 7, No. 12
[9] Pavlo A, Paulson E, Rasin A, Abadi D. J, DeWitt D. J, Madden S, Stone-
braker. M. (2009) “A comparison of approaches to large-scale data analy-
sis,.”In Proc. 2009 SIGMOD, ACM, pages 165-178.
[10] Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker,
Ion Stoica “Spark : Cluster Computing with Working Sets” . Proceedings
of the 2010 Hotcloud
41
[11] Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin
Ma, Murphy McCauley, Michael J. Franklin, Scott Shenker, Ion Stoica “Re-
silient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory
Cluster Computing” . Proceedings of the 2012 NSDI
[12] Michael Armbrust , Reynold S. Xin , Cheng Lian , Yin Huai , Davies Liu ,
Joseph K. Bradley , Xiangrui Meng , Tomer Kaftan , Michael J. Franklin,
Ali Ghodsi , Matei Zaharia “Spark SQL: Relational Data Processing in
Spark” Proceedings of the 2015 SIGMOD
[13] Juwei Shi, Yunjie Qiu, Umar Farooq Minhas, Limei Jiao, Chen Wang,
Berthold Reinwald, and Fatma O¨ zcan “Clash of the Titans: MapReduce
vs. Spark for Large Scale Data Analytics” Proceedings of the 2015 VLDB
[14] Shengsheng Huang, Jie Huang, Jinquan Dai, Tao Xie, and Bo Huang
“The HiBench Benchmark Suite: Characterization of the MapReduce-
Based Data Analysis” 26th IEEE ICDEW, pages 41–51, March 2010. 16.
[15] “SparkBench: a comprehensive benchmarking suite for in memory data
analytic platform Spark” Proceedings of the 2015 Computing Frontiers
[16] Apache. Spark. http://spark.apache.org
[17] Sergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva
Shivakumar, Matt Tolton, Theo Vassilakis “ Dremel: Interactive Analysis
of Web-Scale Datasets ”the 36th Very Large Data Bases (2010), pp. 330-
339
[18] R. S. Xin, J. Rosen, M. Zaharia, M. J. Franklin, S. Shenker, and I. Sto-
ica. “Shark: SQL and Rich Analytics at Scale.” In ACM SIGMOD, pages
13–24, 2013.
42
Abstract
Data processing system benchmarks on
HDFS
Heeran Lee
School of Computer Science Engineering
Collage of Engineering
The Graduate School
Seoul National University
Recently, Hadoop has a major role in Big-data processing. SQL-on-Hadoop
technology that provides a SQL interface on HDFS(Hadoop distributed File
System) is steadily gaining popularity.
In this paper, we conduct the performance evaluation of popular SQL-on-
Hadoop engines, namely, Hive and Spark. We analyze the characteristics of each
system. To do this on various manners, we used 8 benchmark workloads of Hi-
bench by Intel. We find that Spark provides a significant performance advantage
over Hive when the workload’s working set fits in memory. The performance dif-
ference is attributed to Spark’s efficient memory management system (RDDs)
by caching working data. It sticks out more significiently on interative jobs like
k-means.
Also it is tested on diverse columar strage file formats (e.g., Parquet and
ORC) as well as compression schemes(e.g, snappy, gzip, etc.). These two file
formats are very controversal these days for compression efficiency on columar
strage file format. Hortonworks and Cloudera claimes different opinions.
43
In addition, by using the real SNS data (Tweet), Json file handiling utility
is also tested. And the new feature of Spark sql is also tested, Spark Dataframe
which is introduced recently for optimized sql jobs.
This study covers more larger ranges than TPC benchmarks, popular bench-
mark standards used to test RDMBS. This study suggests new starndards for
evaluationg large-scale database systems with real data access patterns. And It
is proposed several schmes for using these system efficiently.
Keywords: SQL-on-Hadoop, Hive, Spark, Hibench, Benchmark
Student Number: 2014-21766
44