The state of SQL-on-Hadoop in the cloud

Poggi, Nicolás; Berral, Josep Ll.; Fenech, Thomas; Carrera, David; Blakeley, José A.; Minhas, Umar Farooq; Vujic, Nikola

doi:10.1109/bigdata.2016.7840751

Cited by 8 publications

(11 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The reason for Hive in GCD being at least twice as slow is due to GCD not using Tez as the execution engine, and using the legacy Map/Reduce engine. This result is consistent with previous work [16].…”

Section: Power Tests From 1gb To 10tbsupporting

confidence: 94%

“…We can also see a great variation of results in HDI with Spark, as with 16 streams is the slowest of the systems, but the fastest at 32 streams. This situation also highlights the variability of cloud results as we have studied previously in [16].…”

Section: Additional Experimentssupporting

confidence: 71%

“…The elasticity properties of the 3 providers have been previously studied [16] using a derived TPC-H benchmark implemented in Hive [11], along with Rackspace's Cloud Big Data (CBD) not included in this report. There were different reasons justifying the selection of each provider.…”

Section: Providers and Systems-under-test (Suts)mentioning

confidence: 99%

“…Most recent evaluations of Hadoop systems in the cloud are SQL-only [4,16]. This is the first attempt to measure performance of cloud-based SUTs and make comparisons between the main providers using BigBench, which expands use cases from the SQL-only boundary and includes both Hive and Spark v2 results.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

Characterizing BigBench Queries, Hive, and Spark in Multi-cloud Environments

Poggi

Montero

Carrera

2017

Performance Evaluation and Benchmarking for the Analytics Era

Self Cite

View full text Add to dashboard Cite

Abstract. BigBench is the new standard (TPCx-BB) for benchmarking and testing Big Data systems. The BigBench specification describes several business use cases which require a broad combination of data extraction techniques including SQL queries, Map/Reduce, user code (UDF), and Machine Learning code. However, currently there is not widespread knowledge of the different resource requirements of each query, as is the case to more established benchmarks. Moreover, the current BigBench implementation allows us to combine different frameworks and libraries from the Hadoop ecosystem. Including combinations such as Hadoop+Hive+Tez (with Mahout) and Spark (SparkSQL+MLlib) in their different versions and configurations. Over the last year, the Spark framework and APIs have been evolving very rapidly, with major improvements on performance and the release of v2. It is our intent to compare the current state of Spark v2 to Hive's base implementation. At the same time, cloud providers currently offer convenient on-demand managed big data clusters (PaaS) with a pay-as-you-go model. In PaaS, analytical engines such as Hive and Spark come ready to use, with a general-purpose configuration and upgrade management. The study characterizes TPCx-BB queries and the out-of-the-box performance of Spark and Hive versions in the cloud. At the same time, comparing popular PaaS offerings, reliability, scalability, and performance, including Azure HDinsight, Amazon Web Services EMR, and Google Dataproc, with an onpremises commodity cluster as baseline. Results show how there is a need for configuration tuning in most cloud providers as data scales grows, especially with Sparks memory usage. The query characterization shows queries are the most resource consuming according to CPU, Memory (especially for ML), and I/O both disk and network. These results can help practitioners to quickly test systems by picking a subset of the queries which stresses each of the categories. At the same time, results show how Hive and Spark compare in the different query types and what performance can be expected of each in PaaS.

show abstract

Section: Power Tests From 1gb To 10tbsupporting

confidence: 94%

Section: Additional Experimentssupporting

confidence: 71%

Section: Providers and Systems-under-test (Suts)mentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Characterizing BigBench Queries, Hive, and Spark in Multi-cloud Environments

Poggi

Montero

Carrera

2017

Performance Evaluation and Benchmarking for the Analytics Era

Self Cite

View full text Add to dashboard Cite

show abstract

“…A recent work by Poggi et al evaluated the Hive on MapReduce and Hive on Tez (with default ORC format configuration) performance on multiple cloud providers using the TPC‐H benchmark. The results showed that the price‐to‐performance ratio for the best cloud configuration is within a 30% cost difference for the 1TB scale.…”

Section: Background and Related Workmentioning

confidence: 99%

The impact of columnar file formats on SQL‐on‐hadoop engine performance: A study on ORC and Parquet

Ivanov

Pergolesi

2019

Concurrency and Computation

View full text Add to dashboard Cite

Columnar file formats provide an efficient way to store data to be queried by SQL-on-Hadoop engines. Related works consider the performance of processing engine and file format together, which makes it impossible to predict their individual impact. In this work, we propose an alternative approach: by executing each file format on the same processing engine, we compare the different file formats as well as their different parameter settings. We apply our strategy to two processing engines, Hive and SparkSQL, and evaluate the performance of two columnar file formats, ORC and Parquet. We use BigBench (TPCx-BB), a standardized application-level benchmark for Big Data scenarios. Our experiments confirm that the file format selection and its configuration significantly affect the overall performance. We show that ORC generally performs better on Hive, whereas Parquet achieves best performance with SparkSQL. Using ZLIB compression brings up to 60.2% improvement with ORC, while Parquet achieves up to 7% improvement with Snappy. Exceptions are the queries involving text processing, which do not benefit from using any compression.

show abstract