Presto C++ Benchmarking on Iceberg and Google Cloud Storage (GCS)

This project provides a rigorous framework for benchmarking the Presto C++ (Velox) engine against Iceberg data lakes on Google Cloud Storage. While pre-configured for Scale Factor 10 (SF-10), this environment is designed as a template for large-scale data lake performance evaluation.

System Architecture

The benchmarking stack is composed of a decoupled architecture to simulate real-world production environments:

• Computational Layer: A dual-node Presto cluster consisting of a Java-based Coordinator and a high-performance C++ Worker (Velox).
• Metadata Layer: A standalone Hive Metastore service using a PostgreSQL backend. This provides the schema definitions for both the Hive (raw) and Iceberg (production) catalogs.
• Storage Layer: Google Cloud Storage (GCS) serves as the source of truth for both raw TPC data (.dat files) and optimized Iceberg tables (Parquet).
• Instrumentation Layer: A metrics-collection suite featuring a MySQL backend for PBench results and a Grafana instance for real-time visualization of system resources.

Building the Presto C++ Worker

The Presto C++ worker (Prestissimo) must be compiled from source to ensure compatibility with your host architecture and OS. This repository includes a high-performance, three-stage Dockerfile.worker that mirrors the official Presto native build process.

Automated Build (Docker)

The provided Dockerfile.worker performs the following steps:

1. Dependency Stage: Installs the required toolchain (CMake, gRPC, c-ares) and clones the official Presto repository.
2. Build Stage: Compiles the native C++ runtime using the Velox engine.
3. Runtime Stage: Produces a lightweight Ubuntu 22.04 image containing only the presto_server binary and its runtime libraries.

To build the worker image:

docker build -f Dockerfile.worker -t presto-cpp-worker:latest .

Manual Build Requirements

If building outside of Docker, the following dependencies are required:

• Ubuntu 22.04 or similar Linux distribution.
• ninja-build, cmake, ccache, and gcc-12+.
• Initialized submodules within the presto-native-execution directory of the Presto source.

Prerequisites and Setup

System Requirements

• Docker & Docker Compose: Ensure you have at least 16GB of allocated RAM to Docker.
• GCS Access: A Google Cloud Service Account with the Storage Object Admin role is required.
• PBench Utility: This repository includes the pbench binary for Darwin ARM64. For other architectures, recompile the binary from the official Presto repository.

GCS Connectivity

To enable GCS access, place your Service Account JSON key in the project root and ensure it is referenced in the docker-compose.yml environment variables:

• PRESTO_GCS_CREDENTIALS_PATH: Path to your JSON key inside the container.
• HIVE_METASTORE_GCS_CREDENTIALS_PATH: Corresponding path for the Metastore.

Initializing Infrastructure

docker-compose up -d

Data Lifecycle: From Raw to Optimized Iceberg

For accurate benchmarking, data must be migrated from raw flat files into the optimized Iceberg format.

1. Hive Raw Layer (External Tables)

Map the raw .dat files in GCS to Presto Hive tables. Ensure that the textfile_field_delim matches your data generation settings (standard TPC-H/DS generators typically use |).

2. Iceberg Production Layer (CTAS)

Create the optimized Iceberg tables using a CREATE TABLE AS SELECT (CTAS) operation. This process converts raw text data into highly compressed, columnar Parquet files.

-- Example for TPC-H Lineitem
CREATE TABLE iceberg.tpch_sf10.lineitem AS 
SELECT * FROM hive.tpch_sf10_raw.lineitem;

3. Optimizer Statistics

After migration, populate the Cost-Based Optimizer (CBO) statistics. This is critical for join-order optimization in complex TPC-DS queries:

ANALYZE iceberg.<schema>.<table>;

Running the Benchmark Suite

All benchmark operations should be executed from the /pbench directory to maintain relative path integrity for SQL queries and connection configurations.

Configuration Files

• mysql.json: Defines the connection parameters for the results database.
• tpch_sf10_iceberg.json: The stage file for TPC-H.
• tpcds_sf10_iceberg.json: The stage file for TPC-DS.

Execution Command

./pbench run \
  --server http://localhost:8080 \
  --user admin \
  --mysql mysql.json \
  tpcds_sf10_iceberg.json

Scaling Guide

This setup can be scaled to handle larger datasets (SF-100, SF-1000) and multi-node clusters.

Horizontal Scaling (More Workers)

To add additional Presto C++ workers, replicate the worker service in docker-compose.yml. Presto will automatically discover new workers via the Discovery Service on the Coordinator. Ensure that query.max-memory-per-node is consistent across the cluster.

Vertical Scaling (SF-10 to SF-1000)

• Memory Tuning: For SF-100+, increase the Velox memory pool in conf/worker/config.properties. Pay specific attention to query.max-memory-per-node and velox.memory_usage_cap.
• GCS Throughput: For large-scale scans, increase the number of GCS connection threads in the Presto configuration to maximize network throughput.
• Spilling: Enable Velox disk spilling if the dataset size significantly exceeds the available RAM.

Performance Tuning and Troubleshooting

Common Tuning Properties

• Velox Cache: Adjust velox.expression_eval_cache_size to optimize repeated expression evaluation.
• Connector Optimization: Ensure iceberg.file-format=PARQUET is set for optimal compatibility with the Velox reader.
• Visualization: Use the provided Grafana dashboards (Port 3000) to analyze system utilization and query latencies.

Troubleshooting

• 403 Forbidden: Verify the GCS Service Account has the correct bucket permissions and that the JSON key is valid.
• Worker Crashes (OOM): Reduce task_concurrency or increase the total memory allocated to the C++ worker process.
• Metastore Timeout: Ensure the PostgreSQL backend is healthy and that the Metastore can resolve the gs:// protocol.

Visualizing Results

The following snapshots demonstrate the performance visualization available within the environment:

Figure 1: TPC-H and TPC-DS Performance Overview

Figure 2: Detailed Query Execution Metrics and Latency Trends

Compliance and Standard Naming

This repository uses the Official TPC Standard Naming for all schemas. This includes standard column prefixes (l_, o_, ss_, etc.). Using non-standard names will break compatibility with the included query library and the PBench execution suite.

Community (Stay Connected with Presto Ecosystem)

• Official Website: prestodb.io
• Official Docs: prestodb.github.io/docs
• Join Slack Community: Join Here