Apache Druid supports “multi-value” string dimensions. Multi-value string dimensions result from input fields that contain an array of values instead of a single value, such as the tags values in the following JSON array example:
{"timestamp": "2011-01-12T00:00:00.000Z", "tags": ["t1","t2","t3"]}
This document describes filtering and grouping behavior for multi-value dimensions. For information about the internal representation of multi-value dimensions, see segments documentation. Examples in this document are in the form of native Druid queries. Refer to the Druid SQL documentation for details about using multi-value string dimensions in SQL.
At ingestion time, Druid can detect multi-value dimensions and configure the dimensionsSpec accordingly. It detects JSON arrays or CSV/TSV fields as multi-value dimensions.
For TSV or CSV data, you can specify the multi-value delimiters using the listDelimiter field in the parseSpec. JSON data must be formatted as a JSON array to be ingested as a multi-value dimension. JSON data does not require parseSpec configuration.
The following shows an example multi-value dimension named tags in a dimensionsSpec:
"dimensions": [
{
"type": "string",
"name": "tags",
"multiValueHandling": "SORTED_ARRAY",
"createBitmapIndex": true
}
],
By default, Druid sorts values in multi-value dimensions. This behavior is controlled by the SORTED_ARRAY value of the multiValueHandling field. Alternatively, you can specify multi-value handling as:
SORTED_SET: results in the removal of duplicate valuesARRAY: retains the original order of the valuesSee Dimension Objects for information on configuring multi-value handling.
The following sections describe filtering and grouping behavior based on the following example data, which includes a multi-value dimension, tags.
{"timestamp": "2011-01-12T00:00:00.000Z", "tags": ["t1","t2","t3"]} #row1
{"timestamp": "2011-01-13T00:00:00.000Z", "tags": ["t3","t4","t5"]} #row2
{"timestamp": "2011-01-14T00:00:00.000Z", "tags": ["t5","t6","t7"]} #row3
{"timestamp": "2011-01-14T00:00:00.000Z", "tags": []} #row4
Be sure to remove the comments before trying out the sample data.
All query types, as well as filtered aggregators, can filter on multi-value dimensions. Filters follow these rules on multi-value dimensions:
null or "" (empty string) will match empty cells in a multi-value dimension.The following example illustrates these rules. This query applies an “or” filter to match row1 and row2 of the dataset above, but not row3:
{
"type": "or",
"fields": [
{
"type": "selector",
"dimension": "tags",
"value": "t1"
},
{
"type": "selector",
"dimension": "tags",
"value": "t3"
}
]
}
This “and” filter would match only row1 of the dataset above:
{
"type": "and",
"fields": [
{
"type": "selector",
"dimension": "tags",
"value": "t1"
},
{
"type": "selector",
"dimension": "tags",
"value": "t3"
}
]
}
This “selector” filter would match row4 of the dataset above:
{
"type": "selector",
"dimension": "tags",
"value": null
}
topN and groupBy queries can group on multi-value dimensions. When grouping on a multi-value dimension, all values from matching rows will be used to generate one group per value. This can be thought of as the equivalent to the UNNEST operator used on an ARRAY type that many SQL dialects support. This means it's possible for a query to return more groups than there are rows. For example, a topN on the dimension tags with filter "t1" AND "t3" would match only row1, and generate a result with three groups: t1, t2, and t3. If you only need to include values that match your filter, you can use a filtered dimensionSpec. This can also improve performance.
See GroupBy querying for details.
{ "queryType": "groupBy", "dataSource": "test", "intervals": [ "1970-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z" ], "granularity": { "type": "all" }, "dimensions": [ { "type": "default", "dimension": "tags", "outputName": "tags" } ], "aggregations": [ { "type": "count", "name": "count" } ] }
This query returns the following result:
[ { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t1" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t2" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 2, "tags": "t3" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t4" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 2, "tags": "t5" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t6" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t7" } } ]
Notice that original rows are “exploded” into multiple rows and merged.
See query filters for details of selector query filter.
{ "queryType": "groupBy", "dataSource": "test", "intervals": [ "1970-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z" ], "filter": { "type": "selector", "dimension": "tags", "value": "t3" }, "granularity": { "type": "all" }, "dimensions": [ { "type": "default", "dimension": "tags", "outputName": "tags" } ], "aggregations": [ { "type": "count", "name": "count" } ] }
This query returns the following result:
[ { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t1" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t2" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 2, "tags": "t3" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t4" } }, { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 1, "tags": "t5" } } ]
You might be surprised to see “t1”, “t2”, “t4” and “t5” included in the results. This is because the query filter is applied on the row before explosion. For multi-value dimensions, a selector filter for “t3” would match row1 and row2, after which exploding is done. For multi-value dimensions, a query filter matches a row if any individual value inside the multiple values matches the query filter.
To solve the problem above and to get only rows for “t3”, use a “filtered dimension spec”, as in the query below.
See filtered dimensionSpecs in dimensionSpecs for details.
{ "queryType": "groupBy", "dataSource": "test", "intervals": [ "1970-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z" ], "filter": { "type": "selector", "dimension": "tags", "value": "t3" }, "granularity": { "type": "all" }, "dimensions": [ { "type": "listFiltered", "delegate": { "type": "default", "dimension": "tags", "outputName": "tags" }, "values": ["t3"] } ], "aggregations": [ { "type": "count", "name": "count" } ] }
This query returns the following result:
[ { "timestamp": "1970-01-01T00:00:00.000Z", "event": { "count": 2, "tags": "t3" } } ]
Note that, for groupBy queries, you could get similar result with a having spec but using a filtered dimensionSpec is much more efficient because that gets applied at the lowest level in the query processing pipeline. Having specs are applied at the outermost level of groupBy query processing.