Null value support

For historical reasons, null support is disabled in Apache Pinot by default. This is expected to be changed in future versions.

For historical reasons, null support is disabled by default in Apache Pinot. When null support is disabled, all columns are treated as not null. Predicates like IS NOT NULL evaluates to true, and IS NULL evaluates to false. Aggregation functions like COUNT, SUM, AVG, MODE, etc. treat all columns as not null.

For example, the predicate in the query below matches all records.

select count(*) from my_table where column IS NOT NULL

To handle null values in your data, you must:

  1. Indicate Pinot to store null values in your data before ingesting the data. See Store nulls at ingestion time.

  2. Use one of the null handling modes at query time. By default Pinot will use a basic support mode where only IS NULL and IS NOT NULL predicates are supported, but the advanced null handling support can be enabled.

The following table summarizes the behavior of null handling support in Pinot:

disabled (default)basic (enabled at ingestion time)advanced (enabled at query time)

IS NULL

always false

depends on data

depends on data

IS NOT NULL

always true

depends on data

depends on data

Transformation functions

use default value

use default value

null aware

Null aware aggregations

use default value

use default value

null aware

How Pinot stores null values

Pinot always stores column values in a forward index. Forward index never stores null values but have to store a value for each row. Therefore independent of the null handling configuration, Pinot always stores a default value for nulls rows in the forward index. The default value used in a column can be specified in the schema configuration by setting the defaultNullValue field spec. The defaultNullValue depends on the type of data.

Remember that in the JSON used as table configuration, defaultNullValue must always be a String. If the column type is not String, Pinot will convert that value to the column type automatically.

Disabled null handling

By default, Pinot does not store null values at all. This means that by default whenever a null value is ingested, Pinot stores the default null value (defined above) instead.

In order to store null values the table has to be configured to do so as explained below.

Store nulls at ingestion time

When null storing is enabled, Pinot creates a new index called the null index or null vector index. This index stores the document IDs of the rows that have null values for the column.

Although null storing can be enabled after data has been ingested, data ingested before this mode is enabled will not store the null index and therefore it will be treated as not null.

Null support is configured per table. You can configure one table to store nulls, and configure another table to not store nulls. There are two ways to define null storing support in Pinot:

  1. Column based null storing, where each column in a table is configured as nullable or not nullable. We recommend enabling null storing support by column. This is the only way to support null handling in the multi-stage query engine.

  2. Table based null storing, where all columns in the table are considered nullable. This is how null values were handled before Pinot 1.1.0 and now deprecated.

Remember that Column based null storing has priority over Table based null storing. In case both modes are enabled, Column based null storing will be used.

Column based null storing

We recommend configuring column based null storing, which lets you specify null handling per column and supports null handling in the multi-stage query engine.

To enable column based null handling:

  1. Set enableColumnBasedNullHandling to true in the schema configuration before ingesting data.

  2. Then specify which columns are not nullable using the notNull field spec, which defaults to false.

{
  "schemaName": "my_table",
  "enableColumnBasedNullHandling": true,
  "dimensionFieldSpecs": [
    {
      "name": "notNullColumn",
      "dataType": "STRING",
      "notNull": true
    },
    {
      "name": "explicitNullableColumn",
      "dataType": "STRING",
      "notNull": false
    },
    {
      "name": "implicitNullableColumn",
      "dataType": "STRING"
    }
  ]
}

Table based null storing

This is the only way to enable null storing in Pinot before 1.1.0, but it is deprecated since then. Table based null storing is more expensive in terms of disk space and query performance than column based null storing. Also, it is not possible to support null handling in multi-stage query engine using table based null storing.

When table based null storing is enabled, all columns will be considered nullable. To enable this mode you need to:

  1. Enable the nullHandlingEnabled configuration in tableIndexConfig.nullHandlingEnabled

  2. Disable enableColumnBasedNullHandling in the schema.

Remember nullHandlingEnabled table configuration enables table based null handling while enableNullHandling is the query option that enables advanced null handling at query time. See advanced null handling support for more information.

As an example:

{
  "tableIndexConfig": {
    "nullHandlingEnabled": true
  }
}

Null handling at query time

To enable basic null handling by at query time, enable Pinot to store nulls at ingestion time. Advanced null handling support can be optionally enabled.

The multi-stage query engine requires column based null storing. Tables with table based null storing are considered not nullable.

If you are converting from null support for the single-stage query engine, you can modify your schema to set enableColumnBasedNullHandling. There is no need to change your table config to remove or set nullHandlingEnabled to false. In fact we recommend to keep it as true to make it clear that the table may contain nulls. Also, when converting:

  • No reingestion is needed.

  • If the columns are changed from nullable to not nullable and there is a value that was previously null, the default value will be used instead.

Basic null support

The basic null support is automatically enabled when null values are stored on a segment (see storing nulls at ingestion time).

In this mode, Pinot is able to handle simple predicates like IS NULL or IS NOT NULL. Other transformation functions (like CASE, COALESCE, +, etc.) and aggregations functions (like COUNT, SUM, AVG, etc.) will use the default value specified in the schema for null values.

For example, in the following table:

rowIdcol1

0

null

1

1

2

2

3

2

4

null

If the default value for col1 is 1, the following query:

select $docId as rowId, col1 from my_table where col1 IS NOT NULL

Will return the following result:

rowIdcol1

1

1

2

2

3

2

While

select $docId as rowId, col1 + 1 as result from my_table

While return the following:

rowIdcol1

0

2

1

2

2

3

3

3

4

2

And queries like

select $docId as rowId, col1 from my_table where col1 = 1

Will return

rowIdcol1

0

null

1

1

4

null

Also

select count(col1)  as count, mode(col1) as mode from my_table
countmode

5

1

Given that neither count or mode function will ignore null values as expected but read instead the default value (in this case 1) stored in the forward index.

Advanced null handling support

Advanced null handling has two requirements:

  1. Segments must store null values (see storing nulls at ingestion time).

  2. The query must enable null handling by setting the enableNullHandling query option to true.

The later can be done in one of the following ways:

  • Set enableNullHandling=true at the beginning of the query.

  • If using JDBC, set the connection option enableNullHandling=true (either in the URL or as a property).

Even they have similar names, the nullHandlingEnabled table configuration and the enableNullHandling query option are different. Remember nullHandlingEnabled table configuration modifies how segments are stored and enableNullHandling query option modifies how queries are executed.

When the enableNullHandling option is set to true, the Pinot query engine uses a different execution path that interprets nulls in a standard SQL way. This means that IS NULL and IS NOT NULL predicates will evaluate to true or false according to whether a null is detected (like in basic null support mode) but also aggregation functions like COUNT, SUM, AVG, MODE, etc. will deal with null values as expected (usually ignoring null values).

In this mode, some indexes may not be usable, and queries may be significantly more expensive. Performance degradation impacts all the columns in the table, including columns in the query that do not contain null values. This degradation happens even when table uses column base null storing.

Examples queries

Select Query

Filter Query

Aggregate Query

Aggregate Filter Query

Group By Query

Order By Query

Transform Query

Appendix: Workarounds to handle null values without storing nulls

If you're not able to generate the null index for your use case, you may filter for null values using a default value specified in your schema or a specific value included in your query.

The following example queries work when the null value is not used in a dataset. Unexpected values may be returned if the specified null value is a valid value in the dataset.

Filter for default null value(s) specified in your schema

  1. Specify a default null value (defaultNullValue) in your schema for dimension fields, (dimensionFieldSpecs), metric fields (metricFieldSpecs), and date time fields (dateTimeFieldSpecs).

  2. Ingest the data.

  3. To filter out the specified default null value, for example, you could write a query like the following:

    select count(*) from my_table where column <> 'default_null_value'

Filter for a specific value in your query

Filter for a specific value in your query that will not be included in the dataset. For example, to calculate the average age, use -1 to indicate the value of Age is null.

  • Rewrite the following query:

    select avg(Age) from my_table
  • To cover null values as follows:

    select avg(Age) from my_table WHERE Age <> -1

Last updated