vtlim commented on code in PR #15340: URL: https://github.com/apache/druid/pull/15340#discussion_r1445441959
########## docs/development/extensions-contrib/spectator-histogram.md: ########## @@ -0,0 +1,453 @@ +--- +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 long integer values within the range of [0, 2^53). Negatives are +coerced to 0. +* Decimals are not supported. +* 276 fixed buckets with increasing bucket widths. In practice, the observed error of computed percentiles is in the range (0.1%, 3%). See [Bucket Boundaries](#histogram-bucket-boundaries) for the full list of bucket boundaries. +* DruidSQL queries are yet not supported. You must use native Druid queries. +* Vectorized queries are yet not supported. + +> If any 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 +than to request individual percentiles in separate queries. This array-based +helper is provided for convenience and has a marginal performance benefit over +using the singular percentile post-aggregator multiple times within a query. +The more expensive part of the query is the aggregation of the histogram. +The post-aggregation calculations all happen on the same aggregated histogram. + +Results will contain arrays matching the length and order of the requested +array of percentiles. + +``` +"percentilesAdded": [ + 0.5504911679884643, // 25th percentile + 4.013975155279504, // 50th percentile + 78.89518317503394, // 75th percentile + 8580.024999999994 // 99.5th percentile +] +``` + +| Property | Description | Required? | +|-------------|--------------------------------------------------------------|-----------| +| type | This String should always be "percentilesSpectatorHistogram" | yes | +| name | A String for the output (result) name of the calculation. | yes | +| field | A field reference pointing to the aggregated histogram. | yes | +| percentiles | Non-empty array of decimal percentiles between 0.0 and 100.0 | yes | + +## Appendix + +### Example Ingestion Spec +Example of ingesting the sample wikipedia dataset with a histogram metric column: +```json +{ + "type": "index_parallel", + "spec": { + "ioConfig": { + "type": "index_parallel", + "inputSource": { + "type": "http", + "uris": ["https://druid.apache.org/data/wikipedia.json.gz";] + }, + "inputFormat": { "type": "json" } + }, + "dataSchema": { + "granularitySpec": { + "segmentGranularity": "day", + "queryGranularity": "minute", + "rollup": true + }, + "dataSource": "wikipedia", + "timestampSpec": { "column": "timestamp", "format": "iso" }, + "dimensionsSpec": { + "dimensions": [ + "isRobot", + "channel", + "flags", + "isUnpatrolled", + "page", + "diffUrl", + "comment", + "isNew", + "isMinor", + "isAnonymous", + "user", + "namespace", + "cityName", + "countryName", + "regionIsoCode", + "metroCode", + "countryIsoCode", + "regionName" + ] + }, + "metricsSpec": [ + { "name": "count", "type": "count" }, + { "name": "sum_added", "type": "longSum", "fieldName": "added" }, + { + "name": "hist_added", + "type": "spectatorHistogram", + "fieldName": "added" + } + ] + }, + "tuningConfig": { + "type": "index_parallel", + "partitionsSpec": { "type": "hashed" }, + "forceGuaranteedRollup": true + } + } +} +``` + +### Example Query +Example query using the sample wikipedia dataset: +```json +{ + "queryType": "timeseries", + "dataSource": { + "type": "table", + "name": "wikipedia" + }, + "intervals": { + "type": "intervals", + "intervals": [ + "0000-01-01/9999-12-31" + ] + }, + "granularity": { + "type": "all" + }, + "aggregations": [ + { + "type": "spectatorHistogram", + "name": "histogram_added", + "fieldName": "added" + } + ], + "postAggregations": [ + { + "type": "percentileSpectatorHistogram", + "name": "medianAdded", + "field": { + "type": "fieldAccess", + "fieldName": "histogram_added" + }, + "percentile": "50.0" + } + ] +} +``` +Results in +```json +[ + { + "result": { + "histogram_added": { + "0": 11096, "1": 632, "2": 297, "3": 187, "4": 322, "5": 161, + "6": 174, "7": 127, "8": 125, "9": 162, "10": 123, "11": 106, + "12": 95, "13": 104, "14": 95, "15": 588, "16": 540, "17": 690, + "18": 719, "19": 478, "20": 288, "21": 250, "22": 219, "23": 224, + "24": 737, "25": 424, "26": 343, "27": 266, "28": 232, "29": 217, + "30": 171, "31": 164, "32": 161, "33": 530, "34": 339, "35": 236, + "36": 181, "37": 152, "38": 113, "39": 128, "40": 80, "41": 75, + "42": 289, "43": 145, "44": 138, "45": 83, "46": 45, "47": 46, + "48": 64, "49": 65, "50": 71, "51": 421, "52": 525, "53": 59, + "54": 31, "55": 35, "56": 8, "57": 10, "58": 5, "59": 4, "60": 11, + "61": 10, "62": 5, "63": 2, "64": 2, "65": 1, "67": 1, "68": 1, + "69": 1, "70": 1, "71": 1, "78": 2 + }, + "medianAdded": 4.013975155279504 + }, + "timestamp": "2016-06-27T00:00:00.000Z" + } +] +``` + +### Histogram Bucket Boundaries +These are the upper bounds of each bucket index. There are 276 buckets. +The first bucket index is 0 and the last bucket index is 275. +As you can see the bucket widths increase as the bucket index increases. This leads to a greater absolute error for larger values, but maintains a relative error of rough percentage across the number range. +i.e the maximum error at value 10 is 0 since the bucket width is 1. But for a value of 16,000,000,000 the bucket width is 1,431,655,768 giving an error of up to ~8.9%. In practice, the observed error of computed percentiles is in the range (0.1%, 3%). Review Comment: ```suggestion For example, the maximum error at value 10 is zero since the bucket width is 1 (the difference of 11-10). For a value of 16,000,000,000, the bucket width is 1,431,655,768 (17179869184-15748213416). This gives an error of up to ~8.9%. In practice, the observed error of computed percentiles is in the range of (0.1%, 3%). ``` Not sure if it's 11-10 or 10-9. Also it's not clear how you get 8.9%. Consider explaining in more detail, or linking to relevant docs. -- 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]
