SEP configuration#

The starburst-presto Helm chart configures the SEP coordinator and worker nodes in the cluster with the values.yaml file detailed in the following sections.

A minimal values file adds the registry credentials, overrides any defaults to suitable values and adds configuration for catalogs and other information as desired.

Docker image and registry#

The default configuration automatically contains the details for the relevant Docker image on the Starburst Harbor instance.

image:
  repository: "harbor.starburstdata.net/starburstdata"
  name: "presto"
  tag: "338-e.0"
  pullPolicy: "IfNotPresent"

registryCredentials:
  enabled: false
  registry:
  username:
  password:

You need to add your credentials to access the registry as shown in the Docker requirements section.

The image node controls the Docker image to use including the version. Typically the Helm chart version is reflects the SEP version. However you can add and override the details tightly control the version of SEP in your cluster

For example, you can choose to use a newer patch version 338-e.1 of SEP:

image:
  repository: "harbor.starburstdata.net/starburstdata"
  name: "presto"
  tag: "338-e.1"
  pullPolicy: "IfNotPresent"

If you need to use an internal Docker registry you can do the following:

  • pull the Docker image from the Starburst Harbor registry with your credentials

  • tag the image as desired for your internal registry

  • push the image to your registry

  • add the image section to your values YAML file:

image:
  repository: "docker.example.com/thirdparty"
  name: "starburst-enterprise-presto"
  tag: "338-e.0"
  pullPolicy: "IfNotPresent"

registryCredentials:
  enabled: true
  registry: docker.example.com
  username: myusername
  password: mypassword

Internal communication#

The internal communication between the coordinator and the workers has to be improved by setting values to the following parameters:

environment:
sharedSecret:

environment

The environment name for the Presto cluster set as node.environment in the node properties file. Examples are values such as production, staging, batchcluster, site-analytics or any other short meaningful string.

sharedSecret

Set the shared secret value for secure communication between coordinator and workers in the cluster to a long random string. If not set, the node.environment value from the node.properties file is used.

environment: test-cluster
sharedSecret: u70Qhhw9PsZmEgIo7Zqg3kIj3AJZ5/Mnyy5iyjcsgnceM+SSV+APSTis...

Exposing the cluster to outside network#

You have to expose the cluster to allow users to connect to the Presto coordinator with tools such as the CLI, applications using the JDBC driver and others. This service type configuration is defined in the expose node.

You can choose from four different mechanisms by setting the type value, to the common configurations in k8s:

  • nodePort

  • clusterIp

  • loadBalancer

  • ingress

Depending on your choice you only have to configure the identically named sections.

The default is clusterIp, and only exposes coordinator on a k8s cluster internal IP.

expose:
  type: "clusterIp"
  clusterIp:
    name: "presto"
    ports:
      http:
        port: 8080

Using nodePort allows you to configure the internal port of the coordinator outside the cluster on the nodePort port number.

expose:
  type: "nodePort"
  nodePort:
    name: "presto"
    ports:
      http:
        port: 8080
        nodePort: 30080

You can use loadBalancer to configure usage of an loadbalancer. It can be automatically created and configured by your k8s platform.

expose:
  type: "loadBalancer"
  loadBalancer:
    name: "presto"
    IP: ""
    ports:
      http:
        port: 8080
    annotations: {}
    sourceRanges: []

Ingress usage is very powerful and may provide load balancing, SSL termination and name-based virtual hosting. This allows on loadbalancer to route to multiple apps in the cluster. For example, SEP coordinator and Ranger server can be in the same cluster and be exposed via ingress configuration.

expose:
  type: "ingress"
  ingress:
    serviceName: "presto"
    servicePort: 8080
    tls:
      enabled: true
      secretName:
    host:
    path: "/"
    annotations: {}

JVM config#

You can add further configuration properties for the JVM with the additionalJvmConfigProperties node. This affects the the JVM for coordinator and :ref`workers <helm-sep-workers>`.

additionalJvmConfigProperties:

Existing default values are overridden. For example, the default parameters include -XX:G1HeapRegionSize=32M and -XX:ReservedCodeCacheSize=512M, and you can override these values:

additionalJvmConfigProperties: |
  -XX:G1HeapRegionSize=64M
  -XX:ReservedCodeCacheSize=1024M

Coordinator#

The coordinator section configures the pod of the cluster that runs the Presto coordinator. The default values are suitable to get started with reasonable defaults on a production sized k8s cluster.

coordinator:
  resources:
    requests:
      memory: "60Gi"
      cpu: 16
    limits:
      memory: "60Gi"
      cpu: 16
  nodeMemoryHeadroom: "2Gi"
  heapSizePercentage: 90
  heapHeadroomPercentage: 30
  additionalProperties: ""
  nodeSelector: {}
  affinity: {}
  tolerations: []

coordinator.resources

The CPU and memory resources to use for the coordinator pod. Request and limit values should be identical.

coordinator.nodeMemoryHeadroom

The size of the container memory headroom. The value needs to be less than resource allocation limit for memory defined in resources.

coordinator.heapSizePercentage

Percentage of container memory reduced with headroom assigned to Java heap, must be less than 100.

coordinator.heapHeadroomPercentage

Headroom of Java heap memory not tracked by Presto during query execution, must be less than 100.

coordinator.additionalProperties

Additional properties to appends to the default configuration file. Default values are overridden. An example usage is to set query time out values

additionalProperties: |
  query.client.timeout=5m
  query.min-expire-age=30m

coordinator.nodeSelector, coordinator.affinity and coordinator.tolerations

If you need to increase settings for your workload or potentially decrease values to adjust for smaller nodes in your k8s cluster you have to adjust the relevant values. For example:

coordinator:
  resources:
    requests:
      memory: "256Gi"
      cpu: 32
    limits:
      memory: "256Gi"
      cpu: 32
  nodeMemoryHeadroom: "4Gi"

Workers#

The worker section configures the pods of the cluster that run the Presto workers. The default values in the following snippet have to be adjusted to be suitable to your workload and cluster:

worker:
  count: 2
  autoscaling:
    enabled: false
    minReplicas: 1
    maxReplicas: 100
    targetCPUUtilizationPercentage: 80
  deploymentTerminationGracePeriodSeconds: 7320 # 2 hours 5 min
  prestoWorkerShutdownGracePeriodSeconds: 7200 # 2 hours
  resources:
    requests:
      memory: "100Gi"
      cpu: 16
    limits:
      memory: "100Gi"
      cpu: 16
  nodeMemoryHeadroom: "2Gi"
  heapSizePercentage: 90
  heapHeadroomPercentage: 30
  additionalProperties: ""
  nodeSelector: {}
  affinity: {}
  tolerations: []

worker.count

The number of worker pods for a static cluster.

worker.autoscaling

Configuration for the minimum and maximum number of workers. Ensure the additional requirements for scaling are fulfilled on your k8s cluster. Set enabled to true to activate scaling. The targetCPUUtilizationPercentage sets the threshold value that triggers scaling up by adding more workers until maxReplicas is reached.

Scaling down proceeds until minReplicas is reached and is controlled by deploymentTerminationGracePeriodSeconds and prestoWorkerShutdownGracePeriodSeconds.

Read more information in our scaling section.

worker.deploymentTerminationGracePeriodSeconds

Specifies the termination grace period for workers. Workers are not terminated until queries running on the pod are finished and the grace period passes.

worker.prestoWorkerShutdownGracePeriodSeconds

Sets shutdown.grace-period to configure the grace period for worker process shutdown.

The following configuration properties for workers are identical to the coordinator properties, documented in preceding section.

  • worker.resources

  • worker.nodeMemoryHeadroom

  • worker.heapSizePercentage

  • worker.heapHeadroomPercentage

  • worker.additionalProperties

  • worker.nodeSelector

  • worker.affinity

  • worker.tolerations

Common settings for coordinator and workers nodes#

You can create a startup shell script to customize how Presto is started on the coordinator and workers and pass additional argument to it.

initFile:
extraArguments:

initFile

A shell script to run before Presto is launched. When called, it is passed the single parameter value coordinator or worker depending on the type of pod. The script needs to invoke the Presto launcher script /usr/lib/presto/bin/launcher for a successful start of Presto.

extraArguments

List of extra arguments to be passed to script.

Authentication#

Configure the file-based authentication usage and users.

authentication:
  enabled: true
  type: "file"
  file:
    users:
      - username: "admin"
        password: "46991b33f7a75ff79213c0dc0e610610"

Ranger#

Enable system level security with Apache Ranger and configure it with the accessControl section:

accessControl:
  enabled: false
  spec:
    access-control.name: "ranger"
    ranger.authentication-type: "BASIC"
    ranger.service-name:
    ranger.policy-refresh-interval: "10s"
    ranger.presto-plugin-username:
    ranger.presto-plugin-password:
    ranger.policy-rest-url:

Query memory usage control#

The query section allows you to configure some query processing properties, which are inserted in the configuration properties file.

query:
  maxMemoryForCluster: "1Pi"
  maxConcurrentQueries: 3

query.maxMemoryForCluster

Maximum memory used over all cluster nodes for queries execution

maxMemoryForCluster ==> presto.query.max-memory

query.heapHeadroomPercentage

Heap memory percentage not tracked by Presto during query execution. Used for java objects.

query.maxConcurrentQueries

Maximum queries executed in parallel on single node

Spilling#

You can configure disk spilling with the spilling section. It uses internal node storage, which is mounted within the container. It is disabled by default, and we recommend to leave is disabled.

spilling:
  enabled: false
  volume:
    emptyDir: {}

Hive connector storage caching#

The cache section allows you to configure Hive connector storage caching.

# - To enable caching only for specific connector, configure it via additionalCatalogs # and additionalVolumes. In such case this feature needs to be disabled.

cache:
  enabled: false
  diskUsagePercentage: 80
  ttl: "7d"
  volume:
    emptyDir: {}

cache.enabled

Enable or disable caching for all catalogs using the Hive connector. If you want to only enable it for a specific catalog, you have to configure it with the catalog configuration and additionalVolumes.

cache.diskUsagePercentage

Set the value for the hive.cache.disk-usage-percentage property.

cache.ttl

Set the value for the hive.cache.ttl property.

cache.volume

Configure the volume in which to store the cached files.

Catalogs#

The additionalCatalogs allows you to configure the catalog properties files that configure access to the data sources. Information for the specific properties supported in each catalog can be found with the documentation for the connector.

By default, no catalogs are configured:

additionalCatalogs: {}

Each catalog is comprised of a key and a value. The key determines the name of the catalog, and the value the content of the properties file. The best approach is to use the YAML multiline syntax to configure the content in multiple lines indented below the key.

For example, the following section adds the tpch-testdata catalog. It uses the TPCH connector and only specifies the connector name.

additionalCatalogs:
  tpch-testdata: |
    connector.name=tpch

Multiple catalogs are configured one after the other:

additionalCatalogs:
  tpch-testdata: |
    connector.name=tpch
  tpcds-testdata: |
    connector.name=tpcds
  tmpmemory: |
    connector.name=memory
  metrics: |
    connector.name=jmx
  devnull: |
    connector.name=blackhole
  datalake: |
    connector.name=hive-hadoop2
    hive.metastore.uri=thrift://example.net:9083

Additional volumes#

# Presto Additional Volumes mount. General purpose. # Provided as array # - path: <<container mount path>> # volume: {} # # Volume definition # https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes # without name parameter. # # E.g. for K8S emptyDir volume # additionalVolumes: # - path: /mnt/InContainer # volume: # emptyDir: {}

additionalVolumes: []

Usage Metrics#

usageMetrics:
  enabled: true
  usageClient:
    initialDelay: "1m"
    interval: "1m"

Prometheus#

prometheus:
  enabled: false
  agent:
    version: "0.13.0"
    port: 8081
    config: "/usr/lib/presto/etc/telemetry/prometheus.yaml"
  additionalRules: {}

License#

Starburst provides customers a license file to unlock additional features of SEP. The license file needs to be provided to SEP in the cluster:

  1. Rename the file you received to starburstdata.license.

  2. Create a k8a secret that contains the license file with a name of your choice in the cluster.

    kubectl create secret generic mylicense --from-file=starburstdata.license
    
  3. Configure the secret name as the Starburst platform license.

    starburstPlatformLicense: mylicense
    

Adding files#

Various use cases around security and event listeners need additional config files as properties or xml files. You can add any file to pod using config maps.

For example, …

Examples:

  • ldap authentication file

  • hive xml file

  • hadoop xml file