SegmentMetadata queries

    Segment metadata queries return per-segment information about:

    • Number of rows stored inside the segment
    • Interval the segment covers
    • Estimated total segment byte size in if it was stored in a ‘flat format’ (e.g. a csv file)
    • Segment id
    • Is the segment rolled up
    • Detailed per column information such as:
      • type
      • cardinality
      • min/max values
      • presence of null values

    There are several main parts to a segment metadata query:

    The format of the result is:

    All columns contain a that Druid uses to represent the column type information internally. The typeSignature is typically the same value used to identify the JSON type information at query or ingest time. One of: STRING, FLOAT, DOUBLE, LONG, or COMPLEX<typeName>, e.g. COMPLEX<hyperUnique>.

    Columns also have a legacy type name. For some column types, the value may match the typeSignature (STRING, FLOAT, , or LONG). For COMPLEX columns, the type only contains the name of the underlying complex type such as hyperUnique.

    New applications should use typeSignature, not type.

    If the errorMessage field is non-null, you should not trust the other fields in the response. Their contents are undefined.

    Only columns which are dictionary encoded (i.e., have type STRING) will have any cardinality. Rest of the columns (timestamp and metric columns) will show cardinality as null.

    The length of this default time period is set in the Broker configuration via: druid.query.segmentMetadata.defaultHistory

    There are 3 types of toInclude objects.

    The grammar is as follows:

    None

    The grammar is as follows:

    List

    The grammar is as follows:

    This is a list of properties that determines the amount of information returned about the columns, i.e. analyses to be performed on the columns.

    By default, the “cardinality”, “interval”, and “minmax” types will be used. If a property is not needed, omitting it from this list will result in a more efficient query.

    The default analysis types can be set in the Broker configuration via: druid.query.segmentMetadata.defaultAnalysisTypes

    • cardinality is the number of unique values present in string columns. It is null for other column types.

    Druid examines the size of string column dictionaries to compute the cardinality value. There is one dictionary per column per segment. If is off (false), this reports the cardinality of each column of each segment individually. If merge is on (true), this reports the highest cardinality encountered for a particular column across all relevant segments.

    minmax

    • Estimated min/max values for each column. Only reported for string columns.

    size

    • size is the estimated total byte size as if the data were stored in text format. This is not the actual storage size of the column in Druid. If you want the actual storage size in bytes of a segment, look elsewhere. Some pointers:

    • To get the storage size in bytes of an entire segment, check the size field in the . This is the size of the memory-mappable content.

    • To get the storage size in bytes of a particular column in a particular segment, unpack the segment and look at the meta.smoosh file inside the archive. The difference between the third and fourth columns is the size in bytes. Currently, there is no API for retrieving this information.
    • intervals in the result will contain the list of intervals associated with the queried segments.

    timestampSpec

    • timestampSpec in the result will contain timestampSpec of data stored in segments. this can be null if timestampSpec of segments was unknown or unmergeable (if merging is enabled).

    queryGranularity

    • queryGranularity in the result will contain query granularity of data stored in segments. this can be null if query granularity of segments was unknown or unmergeable (if merging is enabled).

    • aggregators in the result will contain the list of aggregators usable for querying metric columns. This may be null if the aggregators are unknown or unmergeable (if merging is enabled).

    • Merging can be strict or lenient. See lenientAggregatorMerge below for details.

    • The form of the result is a map of column name to aggregator.

    rollup

    • rollup in the result is true/false/null.

    Conflicts between aggregator metadata across segments can occur if some segments have unknown aggregators, or if two segments use incompatible aggregators for the same column (e.g. longSum changed to doubleSum).

    Aggregators can be merged strictly (the default) or leniently. With strict merging, if there are any segments with unknown aggregators, or any conflicts of any kind, the merged aggregators list will be null. With lenient merging, segments with unknown aggregators will be ignored, and conflicts between aggregators will only null out the aggregator for that particular column.