bsyk commented on code in PR #15340: URL: https://github.com/apache/druid/pull/15340#discussion_r1443326531
########## docs/development/extensions-contrib/spectator-histogram.md: ########## @@ -0,0 +1,386 @@ +--- +id: spectator-histogram +title: "Spectator Histogram module" +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + +## Summary +This module provides Apache Druid approximate histogram aggregators and percentile +post-aggregators based on Spectator fixed-bucket histograms. + +Consider using this extension if you need percentile approximations and: +* want fast and accurate queries +* at a lower storage cost +* and have a large dataset +* using only positive measurements + +> The main benefit of this extension over data-sketches is the reduced storage +footprint. Which leads to smaller segment sizes, faster loading from deep storage +and lower memory usage. + +In the Druid instance shown below, the example Wikipedia dataset is loaded 3 times. +* As-is, no rollup applied +* With a single extra metric column of type `spectatorHistogram` ingesting the `added` column +* With a single extra metric column of type `quantilesDoublesSketch` ingesting the `added` column + +Spectator histograms average just 6 extra bytes per row, while the data-sketch +adds 48 bytes per row. This is an 8 x reduction in additional storage size. + + +As rollup improves, so does the size saving. For example, ingesting the wikipedia data +with day-grain query granularity and removing all dimensions except `countryName`, +we get to a segment that has just 106 rows. The base segment is 87 bytes per row, +adding a single `spectatorHistogram` column adds just 27 bytes per row on average vs +`quantilesDoublesSketch` adding 255 bytes per row. This is a 9.4 x reduction in additional storage size. +Storage gains will differ per dataset depending on the variance and rollup of the data. + +## Background +[Spectator](https://netflix.github.io/atlas-docs/spectator/) is a simple library +for instrumenting code to record dimensional time series data. +It was built, primarily, to work with [Atlas](https://netflix.github.io/atlas-docs/). +Atlas was developed by Netflix to manage dimensional time series data for near +real-time operational insight. + +With the [Atlas-Druid](https://github.com/Netflix-Skunkworks/iep-apps/tree/main/atlas-druid) +service, it's possible to use the power of Atlas queries, backed by Druid as a +data store to benefit from high-dimensionality and high-cardinality data. + +SpectatorHistogram is designed for efficient parallel aggregations while still +allowing for filtering and grouping by dimensions. +It provides similar functionality to the built-in data-sketch aggregator, but is +opinionated and optimized for typical measurements of cloud services and web-apps. +Measurements such as page load time, transferred bytes, response time, request latency, etc. +Through some trade-offs we're able to provide a significantly more compact +representation with the same aggregation performance and accuracy as +data-sketches (depending on data-set, see limitations below). + +## Limitations +* Supports positive numeric values within the range of [0, 2^53). Negatives are +coerced to 0. +* Fixed buckets with increasing bucket widths. Relative accuracy is maintained, +but absolute accuracy reduces with larger values. + +> If either of these limitations are a problem, then the data-sketch aggregator +is most likely a better choice. + +## Functionality +The SpectatorHistogram aggregator is capable of generating histograms from raw numeric +values as well as aggregating/combining pre-aggregated histograms generated using +the SpectatorHistogram aggregator itself. +While you can generate histograms on the fly at query time, it is generally more +performant to generate histograms during ingestion and then combine them at +query time. This is especially true where rollup is enabled. It may be misleading or +incorrect to generate histogram from already rolled-up summed data. + +The module provides postAggregators, `percentileSpectatorHistogram` (singular) and +`percentilesSpectatorHistogram` (plural), that can be used to compute approximate +percentiles from histograms generated by the SpectatorHistogram aggregator. +Again, these postAggregators can be used to compute percentiles from raw numeric +values via the SpectatorHistogram aggregator or from pre-aggregated histograms. + +> If you're only using the aggregator to compute percentiles from raw numeric values, +then you can use the built-in data-sketch aggregator instead. The performance +and accuracy are comparable, the data-sketch aggregator supports negative values, +and you don't need to load an additional extension. + +An aggregated SpectatorHistogram can also be queried using a `longSum` or `doubleSum` +aggregator to retrieve the population of the histogram. This is effectively the count +of the number of values that were aggregated into the histogram. This flexibility can +avoid the need to maintain a separate metric for the count of values. + +For high-frequency measurements, you may need to pre-aggregate data at the client prior +to sending into Druid. For example, if you're measuring individual image render times +on an image-heavy website, you may want to aggregate the render times for a page-view +into a single histogram prior to sending to Druid in real-time. This can reduce the +amount of data that's needed to send from the client across the wire. + +SpectatorHistogram supports ingesting pre-aggregated histograms in real-time and batch. +They can be sent as a JSON map, keyed by the spectator bucket ID and the value is the +count of values. This is the same format as the serialized JSON representation of the +histogram. The keys need not be ordered or contiguous e.g. + +```json +{ "4": 8, "5": 15, "6": 37, "7": 9, "8": 3, "10": 1, "13": 1 } +``` + +## Loading the extension +To use SpectatorHistogram, make sure you [include](../../configuration/extensions.md#loading-extensions) the extension in your config file: + +``` +druid.extensions.loadList=["druid-spectator-histogram"] +``` + +## Aggregators + +The result of the aggregation is a histogram that is built by ingesting numeric values from +the raw data, or from combining pre-aggregated histograms. The result is represented in +JSON format where the keys are the bucket index and the values are the count of entries +in that bucket. + +The buckets are defined as per the Spectator [PercentileBuckets](https://github.com/Netflix/spectator/blob/main/spectator-api/src/main/java/com/netflix/spectator/api/histogram/PercentileBuckets.java) specification. +See [Appendix](#histogram-bucket-boundaries) for the full list of bucket boundaries. +```js + // The set of buckets is generated by using powers of 4 and incrementing by one-third of the + // previous power of 4 in between as long as the value is less than the next power of 4 minus + // the delta. + // + // Base: 1, 2, 3 + // + // 4 (4^1), delta = 1 (~1/3 of 4) + // 5, 6, 7, ..., 14, + // + // 16 (4^2), delta = 5 (~1/3 of 16) + // 21, 26, 31, ..., 56, + // + // 64 (4^3), delta = 21 (~1/3 of 64) + // ... +``` + +There are multiple aggregator types included, all of which are based on the same +underlying implementation. The different types signal to the Atlas-Druid service (if using) +how to handle the resulting data from a query. + +* spectatorHistogramTimer signals that the histogram is representing +a collection of timer values. It is recommended to normalize timer values to nanoseconds +at, or prior to, ingestion. If queried via the Atlas-Druid service, it will +normalize timers to second resolution at query time as a more natural unit of time +for human consumption. +* spectatorHistogram and spectatorHistogramDistribution are generic histograms that +can be used to represent any measured value without units. No normalization is +required or performed. + +### `spectatorHistogram` aggregator +Alias: `spectatorHistogramDistribution`, `spectatorHistogramTimer` + +To aggregate at query time: +``` +{ + "type" : "spectatorHistogram", + "name" : <output_name>, + "fieldName" : <column_name> + } +``` + +| Property | Description | Required? | +|-----------|--------------------------------------------------------------------------------------------------------------|-----------| +| type | This String must be one of "spectatorHistogram", "spectatorHistogramTimer", "spectatorHistogramDistribution" | yes | +| name | A String for the output (result) name of the aggregation. | yes | +| fieldName | A String for the name of the input field containing raw numeric values or pre-aggregated histograms. | yes | + +### `longSum`, `doubleSum` and `floatSum` aggregators +To get the population size (count of events contributing to the histogram): +``` +{ + "type" : "longSum", + "name" : <output_name>, + "fieldName" : <column_name_of_aggregated_histogram> + } +``` + +| Property | Description | Required? | +|-----------|--------------------------------------------------------------------------------|-----------| +| type | Must be "longSum", "doubleSum", or "floatSum". | yes | +| name | A String for the output (result) name of the aggregation. | yes | +| fieldName | A String for the name of the input field containing pre-aggregated histograms. | yes | + +## Post Aggregators + +### Percentile (singular) +This returns a single percentile calculation based on the distribution of the values in the aggregated histogram. + +``` +{ + "type": "percentileSpectatorHistogram", + "name": <output name>, + "field": { + "type": "fieldAccess", + "fieldName": <name of aggregated SpectatorHistogram> + }, + "percentile": <decimal percentile, e.g. 50.0 for median> +} +``` + +| Property | Description | Required? | +|------------|-------------------------------------------------------------|-----------| +| type | This String should always be "percentileSpectatorHistogram" | yes | +| name | A String for the output (result) name of the calculation. | yes | +| field | A field reference pointing to the aggregated histogram. | yes | +| percentile | A single decimal percentile between 0.0 and 100.0 | yes | + +### Percentiles (multiple) +This returns an array of percentiles corresponding to those requested. + +``` +{ + "type": "percentilesSpectatorHistogram", + "name": <output name>, + "field": { + "type": "fieldAccess", + "fieldName": <name of aggregated SpectatorHistogram> + }, + "percentiles": [25, 50, 75, 99.5] +} +``` + +> Note: It's more efficient to request multiple percentiles in a single query Review Comment: Where only a single percentile is wanted, often median or 95th, it's slightly nicer to get a single value back, rather than having to extract from an array in the results. Also not a strong opinion. Is the note misleading? It's trying to say, "if you want multiple percentiles from the same underlying metric, then ask for them all at once, rather than as separate metrics". 1 query being more efficient than 2. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
