Skip to content
This repository has been archived by the owner on Sep 18, 2023. It is now read-only.

Latest commit

 

History

History
213 lines (134 loc) · 12.7 KB

User-Guide.md

File metadata and controls

213 lines (134 loc) · 12.7 KB

Gazelle Plugin

A Native Engine for Spark SQL with vectorized SIMD optimizations

Introduction

Overview

Spark SQL works very well with structured row-based data. It used WholeStageCodeGen to improve the performance by Java JIT code. However Java JIT is usually not working very well on utilizing latest SIMD instructions, especially under complicated queries. Apache Arrow provided CPU-cache friendly columnar in-memory layout, its SIMD-optimized kernels and LLVM-based SQL engine Gandiva are also very efficient.

Gazelle Plugin reimplements Spark SQL execution layer with SIMD-friendly columnar data processing based on Apache Arrow, and leverages Arrow's CPU-cache friendly columnar in-memory layout, SIMD-optimized kernels and LLVM-based expression engine to bring better performance to Spark SQL.

Key Features

Apache Arrow formatted intermediate data among Spark operator

Overview

With Spark 27396 its possible to pass a RDD of Columnarbatch to operators. We implemented this API with Arrow columnar format.

Apache Arrow based Native Readers for Parquet and other formats

Overview

A native parquet reader was developed to speed up the data loading. it's based on Apache Arrow Dataset. For details please check Arrow Data Source Note both data source V1 and V2 are supported. Please check the example section for arrow data source

Apache Arrow Compute/Gandiva based operators

Overview

We implemented common operators based on Apache Arrow Compute and Gandiva. The SQL expression was compiled to one expression tree with protobuf and passed to native kernels. The native kernels will then evaluate the these expressions based on the input columnar batch.

Native Columnar Shuffle Operator with efficient compression support

Overview

We implemented columnar shuffle to improve the shuffle performance. With the columnar layout we could do very efficient data compression for different data format.

Please check the operator supporting details here

How to use OAP: Gazelle Plugin

There are three ways to use OAP: Gazelle Plugin,

  1. Use precompiled jars
  2. Building by Conda Environment
  3. Building by Yourself

Use precompiled jars

Before 1.4.0 release

Please go to OAP's Maven Central Repository to find Gazelle Plugin jars. For usage, you will require below two jar files:

  1. spark-arrow-datasource-standard-<version>-jar-with-dependencies.jar is located in com/intel/oap/spark-arrow-datasource-standard//
  2. spark-columnar-core-<version>-jar-with-dependencies.jar is located in com/intel/oap/spark-columnar-core//

Since 1.3.1 release, there are two extra jars to work with different Spark minor releases. For spark 3.1.x, the jar whose <spark-version> is spark311 should be used. And for spark 3.2.x, the jar whose <spark-version> is spark321 should be used.

  1. spark-sql-columnar-shims-common-<version>-SNAPSHOT.jar

  2. spark-sql-columnar-shims-<spark-version>-<version>-SNAPSHOT.jar

Start from 1.4.0 release

Since 1.4.0 release, we consolidate 4 jars into one single jar. And the supported spark version is contained in the jar name. User can pick one jar according to your spark version.

gazelle-plugin-<version>-spark-3.1.1.jar

gazelle-plugin-<version>-spark-3.2.1.jar

Please note the files are fat jars shipped with our custom Arrow library and pre-compiled from our server(using GCC 9.3.0 and LLVM 7.0.1), which means you will require to pre-install GCC 9.3.0 and LLVM 7.0.1 in your system for normal usage.

Building by Conda

If you already have a working Hadoop Spark Cluster, we provide a Conda package which will automatically install dependencies needed by OAP, you can refer to OAP-Installation-Guide for more information. Once finished OAP-Installation-Guide, you can find built gazelle-plugin-<version>-<spark-version>.jar under $HOME/miniconda2/envs/oapenv/oap_jars. Then you can just skip below steps and jump to Get Started.

Building by yourself

If you prefer to build from the source code on your hand, please follow below steps to set up your environment.

Prerequisite

There are some requirements before you build the project. Please check the document Prerequisite and make sure you have already installed the software in your system. A conda env was also provided to help to setup the building env quickly. If you are running a SPARK Cluster, please make sure all the software are installed in every single node.

Installation

Please check the document Installation Guide

Get started

To enable Gazelle Plugin, the previous built jar spark-columnar-core-<version>-jar-with-dependencies.jar and spark-arrow-datasource-standard-<version>-jar-with-dependencies.jar should be added to Spark configuration. As of 1.3.1 release, a new shim layer was introduced to work with Spark minor releases. The shim layer also have two jarsspark-sql-columnar-shims-common-<version>-SNAPSHOT.jar and spark-sql-columnar-shims-<spark-version>-<version>-SNAPSHOT.jar And after 1.4.0 release, only one single jar is required: gazelle-plugin-<version>-spark-3.1.1.jar or gazelle-plugin-<version>-spark-3.2.1.jar.

We will demonstrate how to deploy Gazelle (since 1.4.0 release) on Spark 3.2.1. SPARK related options are:

  • spark.driver.extraClassPath : Set to load jar file to driver.
  • spark.executor.extraClassPath : Set to load jar file to executor.
  • jars : Set to copy jar file to the executors when using yarn cluster mode.
  • spark.executorEnv.ARROW_LIBHDFS3_DIR : Optional if you are using a custom libhdfs3.so.
  • spark.executorEnv.LD_LIBRARY_PATH : Optional if you are using a custom libhdfs3.so.

For Spark Standalone Mode, please set the above value as relative path to the jar file. For Spark Yarn Cluster Mode, please set the above value as absolute path to the jar file.

More Configuration, please check the document Configuration Guide

Example to run Spark Shell with ArrowDataSource jar file

${SPARK_HOME}/bin/spark-shell \
        --verbose \
        --master yarn \
        --driver-memory 10G \
        --conf spark.plugins=com.intel.oap.GazellePlugin \
        --conf spark.driver.extraClassPath=$PATH_TO_JAR/gazelle-plugin-<version>-spark-3.2.1.jar \
        --conf spark.executor.extraClassPath=$PATH_TO_JAR/gazelle-plugin-<version>-spark-3.2.1.jar \
        --conf spark.shuffle.manager=org.apache.spark.shuffle.sort.ColumnarShuffleManager \
        --conf spark.driver.cores=1 \
        --conf spark.executor.instances=12 \
        --conf spark.executor.cores=6 \
        --conf spark.executor.memory=20G \
        --conf spark.memory.offHeap.enabled=true \
        --conf spark.memory.offHeap.size=20G \
        --conf spark.task.cpus=1 \
        --conf spark.locality.wait=0s \
        --conf spark.sql.shuffle.partitions=72 \
        --conf spark.executorEnv.ARROW_LIBHDFS3_DIR="$PATH_TO_LIBHDFS3_DIR/" \
        --conf spark.executorEnv.LD_LIBRARY_PATH="$PATH_TO_LIBHDFS3_DEPENDENCIES_DIR"
        --jars $PATH_TO_JAR/spark-arrow-datasource-standard-<version>-jar-with-dependencies.jar,$PATH_TO_JAR/spark-columnar-core-<version>-jar-with-dependencies.jar

Here is one example to verify if Gazelle Plugin works, make sure you have TPC-H dataset. We could do a simple projection on one parquet table. For detailed testing scripts, please refer to Solution Guide.

val orders = spark.read.format("arrow").load("hdfs:////user/root/data_tpch_10/orders")
orders.createOrReplaceTempView("orders")
spark.sql("select * from orders where o_orderdate > date '1998-07-26'").show(20000, false)

The result should showup on Spark console and you can check the DAG diagram with some Columnar Processing stage. Gazelle Plugin still lacks some features, please check out the limitations.

Cloud/K8s Integration

Amazon EMR

Please refer to Gazelle on EMR to find details about how to use OAP Gazelle on Amazon EMR Cloud.

Google Cloud Dataproc

Gazelle Plugin now supports to run on Dataproc 2.0, we provide a guide to help quickly install Gazelle Plugin and run TPC-DS with notebooks or scripts.

Please refer to Gazelle on Dataproc to find details about:

  1. Create a cluster on Dataproc 2.0 with initialization actions. Gazelle Plugin jars compiled with -Pdataproc-2.0 parameter will installed by Conda in all cluster nodes.

  2. Config for enabling Gazelle Plugin.

  3. Run TPC-DS with notebooks or scripts.

You can also find more information about how to use OAP on Google Dataproc.

Docker Image and Kubernetes Support

For Kubernetes Support, please refer to OAP on Kubernetes

For how to build the Docker Image, please refer to OAP Dockerfiles

For using an existing Docker Image, please check the repository OAP Docker Image and Gazelle Docker Image

Performance data

For advanced performance testing, below charts show the results by using two benchmarks with Gazelle v1.1: 1. Decision Support Benchmark1 and 2. Decision Support Benchmark2. The testing environment for Decision Support Benchmark1 is using 1 master + 3 workers and Intel(r) Xeon(r) Gold 6252 CPU|384GB memory|NVMe SSD x3 per single node with 1.5TB dataset and parquet format.

  • Decision Support Benchmark1 is a query set modified from TPC-H benchmark. We change Decimal to Double since Decimal hasn't been supported in OAP v1.0-Gazelle Plugin. Overall, the result shows a 1.49X performance speed up from OAP v1.0-Gazelle Plugin comparing to Vanilla SPARK 3.0.0. We also put the detail result by queries, most of queries in Decision Support Benchmark1 can take the advantages from Gazelle Plugin. The performance boost ratio may depend on the individual query.

Performance

Performance

The testing environment for Decision Support Benchmark2 is using 1 master + 3 workers and Intel(r) Xeon(r) Platinum 8360Y CPU|1440GB memory|NVMe SSD x4 per single node with 3TB dataset and parquet format.

  • Decision Support Benchmark2 is a query set modified from TPC-DS benchmark. We change Decimal to Doubel since Decimal hasn't been supported in OAP v1.0-Gazelle Plugin. We pick up 10 queries which can be fully supported in OAP v1.0-Gazelle Plugin and the result shows a 1.26X performance speed up comparing to Vanilla SPARK 3.0.0.

Performance

Please notes the performance data is not an official from TPC-H and TPC-DS. The actual performance result may vary by individual workloads. Please try your workloads with Gazelle Plugin first and check the DAG or log file to see if all the operators can be supported in OAP-Gazelle Plugin. Please check the detailed page on performance tuning for TPC-H and TPC-DS workloads.

Memory allocation

The memory usage in Gazelle Plugin is high. The allocations goes to two parts: 1) Java based allocation which is widely used in Arrow Java API. 2) Native side memory allocation used in each native kernel. We investigated the memory allocation behavior and made more turnings here, the memroy footprint is stable during a TPC-DS power run. Memory

Coding Style

Contact

[email protected] [email protected]