Null value support

For performance reasons, null handling 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 configure your tables to store nulls at ingestion time. This has to be done before ingesting the data. Tables where null values are stored support basic null handling, which is limited to IS NULL and IS NOT NULL predicates, and can optionally be queried with advanced null handling support.

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

disabled (default)

basic (enabled at ingestion time)

advanced (enabled at query time)

IS NULL

always false

depends on data

IS NOT NULL

always true

depends on data

Transformation functions

use default value

null aware

Null aware aggregations

use default value

null aware

Default behavior

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.

Store nulls at ingestion time

To support null handling, Pinot must store null values in segments. The forward index stores the default value for null rows whether null storing is enabled or not. 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:

Column based null handling, 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.
Table based null handling, where all columns in the table are considered nullable. This is how null values were handled before Pinot 1.1.0 and now deprecated.

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:

Set enableColumnBasedNullHandling to true in the schema configuration before ingesting data.
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.

To enable table based null storing, enable the nullHandlingEnabled configuration in tableIndexConfig.nullHandlingEnabled before ingesting data. All columns in the table are now nullable.

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 simplify your model by removing nullHandlingEnabled at the same time you set enableColumnBasedNullHandling. 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:

rowId	col1
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 NULL

Will return the following result:

rowId	col1
1	1
2	2
3	2

While

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

While return the following:

rowId	col1
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

rowId	col1
0	null
1	1
4	null

Also

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

count	mode
5	1

count

mode

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:

Segments must store null values (see storing nulls at ingestion time).
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

Specify a default null value (defaultNullValue) in your schema for dimension fields, (dimensionFieldSpecs), metric fields (metricFieldSpecs), and date time fields (dateTimeFieldSpecs).
Ingest the data.
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

PreviousIngestion Transformations NextUse the multi-stage query engine (v2)

Last updated 23 days ago