In this section we summarize the strengths and weaknesses of evaluated systems and the lessons learned from this study.
QUERY OPTIMIZER. The query optimizers in Impala and Spark SQL generate simple
and efficient execution plans by evaluating and selecting from a variety of join strategies including semi-join, anti-join, etc. However, we note that the cardinality estimates can be significantly off in Impala, resulting in expensive join order selection in some cases. The cost-based query optimization is still in its nascent stages in Phoenix; hence, users need to:
1) define the join evaluation order, and 2) choose the join algorithm to be used. The query optimizer in Drill can generate complex and inefficient execution plans, especially for the correlated sub-queries.
QUERY EXECUTION ENGINE. The Impala execution engine has the most efficient and stable disk I/O sub-system among all evaluated systems, as demonstrated by the lowest scan operator times for both storage formats. Although the Drill execution engine (with the columnar data model for in-memory processing) is optimized for the on-disk columnar data storage format (parquet), the scan operator is the principal contributor to the query RT in the parquet format. In addition, the scan operator becomes a performance bottleneck in Drill for the data stored in the text format with an unstable behavior characterized by the high scan operator wait times. In comparison with other evaluated systems, Phoenix has a notably larger data footprint due to the HBase HFile storage format, resulting in expensive full table scans.
The join and aggregation operator implementations in the Drill query engine harness all available CPU cores and achieve the shortest processing times among all evaluated systems.
In contrast, the use of a single CPU core to perform the join and aggregation operations in Impala, results in sub-optimal resource utilization; however, ongoing efforts to enable multi-core execution for all operators [99] should lead to performance improvement. Joins are costly in Spark SQL due to the choice of SMJ as the primary join operator, which requires an expensive sort operation prior to the join operation.
The data-exchange operator contributes nominally to the query RT in Impala, Spark SQL, and Drill. However, the client coordinated data-exchange operation is the primary performance bottleneck in Phoenix, making it ill-suited for join-heavy workloads that shuf-
fle large amounts of data.
The results from this study can be utilized in two ways: (i) to assist practitioners choose a SQL-on-Hadoop system based on their workloads and SLA requirements, and (ii) to provide the data architects more insight into the performance impacts of evaluated SQL- on-Hadoop systems.
Chapter 6
Fusion: Implementation and evaluation of block range indexes in a SQL-on-Object-Storage system
Cloud computing is emerging as a novel paradigm for large scale distributed comput- ing, driven by the economies of scale. Cloud platforms like Amazon EC2 [28], Microsoft Azure [79], Google Cloud [100] etc., enable users to elastically acquire and release re- sources from a virtually infinite resource pool. Concomitant with the emergence of cloud computing is the data deluge that the enterprises are experiencing in storing the data gen- erated from a variety of sources including social media, transactional systems, sensors, etc.
Now, the combination of the need to glean actionable insights from the big data and to tap the potential of cloud hosting platforms, has led to the development of both new storage systems (e.g. HDFS [21], MapR-FS [101], Amazon S3 [25], Microsoft Azure Blob Storage [26], etc.) and query engines (e.g. Impala [23], Drill [24], Spark SQL [20]).
Instance storage, network attached Block storage, and Object storage represent different storage substrate choices for modern query engines (e.g. Impala, Spark SQL, etc.) on the cloud platforms. Each storage substrate choice represents a trade off between cost, persistence and performance. Hadoop storage system is designed to leverage the shared nothing architecture where each node in the cluster acts both as a compute node and a storage node. A Hadoop cluster in the cloud environment can utilize either Instance storage or network attached Block storage (e.g. Amazon EBS) as the storage substrate. A Hadoop cluster achieves optimal performance with the Instance storage by leveraging short circuit local reads. Although Instance storage is ideal for ad hoc data analysis, complete data loss after a cluster shutdown makes it less suitable for analyzing large and growing data, due to the high data population times. A Block storage service like Amazon EBS is non- ephemeral and enables users to elastically attach/detach network drives to the VM instances
in the cluster; however, EBS is expensive. In contrast, object storage systems like S3, Azure blob storage, etc., are cheaper than the network attached Block storage systems and provide better performance per dollar [35]. In addition, the use of a object storage system like S3 as the storage backend de-couples compute from storage, enabling independent scaling of either clusters. However, despite S3’s better performance per dollar as compared to EBS, S3 may not be suitable for interactive analytics due to the data transfer latency (between EC2 and S3) and low read throughput. Hence, new mechanisms are required to enable interactive analytics with a object storage system as the storage backend of query engines.
Traditionally, the read performance of a query engine can be improved by increasing data read throughput and skipping irrelevant data. The data read throughput can be in- creased by employing caching, parallelizing reads and storing the data in a compressed format. Conventionally, columnar storage and indexing structures are used to skip reading the irrelevant data.
In this work, we focus on exploring indexing structures that can effectively skip irrel- evant data stored in object storage systems like S3. Although B-tree, B
+
-tree, and R-tree indexes have been shown to be very effective in traditional data warehousing systems, high maintenance overhead, large storage footprint, and poor random I/O performance of object storage systems like S3, makes them less attractive for the query engines that use object storage systems as the storage backend. On the contrary, Block Range Indexes (BRIN) can be a better fit for skipping irrelevant data stored in object stores, since they exhibit low maintenance overhead, are lightweight (orders of magnitude smaller in size than traditional indexes [27]) and can be very effective for naturally ordered data (e.g. sensor data).In this work our goals are two fold: 1) Empirically evaluate the performance impact of block range indexes in a object storage system using a standard benchmark. 2) Empirically evaluate the performance trade offs of different block range index implementations.
Table 6.1: Example Block range index foridcolumn of Customers table.
min max block number
1 20 1
24 48 2
36 100 3