andygrove commented on code in PR #2671: URL: https://github.com/apache/datafusion-ballista/pull/2671#discussion_r4448669288
########## ballista/core/src/hll.rs: ########## @@ -0,0 +1,219 @@ +// 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. + +//! HyperLogLog distinct-count sketch for shuffle output columns. +//! +//! Shuffle writers update one sketch per sketched column, executors ship the +//! registers to the scheduler in `TaskColumnStats.sketches`, and the scheduler +//! merges every task's sketch for a column into a stage-level distinct count. +//! +//! Values are hashed with DataFusion's `HLL_RANDOM_STATE`, the hash state +//! `approx_distinct` uses, and the count uses the same estimator (Ertl, +//! "New cardinality estimation algorithms for HyperLogLog sketches", 2017). +//! Precision is 12 rather than DataFusion's 14: 4 KiB of registers per +//! column per task instead of 16 KiB, for a standard error of about 1.6%, +//! which is plenty for join cardinality estimation. Review Comment: Fair question: the doc comment only argued 12 against 14, and 12 was chosen as "plenty" rather than from a comparison with 10. I measured it now (random 64-bit keys, 1K / 100K / 2M distinct, 200 trials per size, 40 at 2M): | precision | sketch size | RMS error | worst single trial | | --------- | ----------- | --------- | ------------------ | | 10 | 1 KiB | 2.5-3.2% | 10.1% | | 12 | 4 KiB | 1.1-1.7% | 5.9% | | 14 | 16 KiB | 0.6-0.8% | 2.5% | That matches 1.04/√m. The error goes straight into the join estimate, and 1-3% is small next to the ~380x miss this is meant to fix (400K estimated vs 151M actual in q21), so for accuracy alone 10 would probably do. Where the size shows up is the scheduler, not the executors: it keeps every successful task's sketch, so the cost is tasks × key columns × size. Precision 10 saves 3 KiB of that: about 2 MB at 300 tasks with two key columns, 60 MB at 10,000. CPU doesn't change with precision, about 1.2 ns/row at 10, 12 and 14 on `Int64` keys, because hashing dominates. So I kept 12: it costs nothing noticeable at normal sizes, and the clusters where 10 would pay off can now pick it (see the next comment). I haven't compared AQE plan choices at 10 vs 12 on TPC-H/TPC-DS, so "10 would probably do" is arithmetic, not a result. The module docs now carry this reasoning. ########## docs/source/user-guide/configs.md: ########## @@ -152,6 +152,7 @@ explanation of the sort-based shuffle writer. <!-- prettier-ignore --> | key | type | default | description | | -------------------------------------------------------- | ------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| ballista.shuffle.collect_distinct_counts | Boolean | true | Sketch the approximate distinct count of each hash-partitioning key column with HyperLogLog while writing shuffle output, so the adaptive planner can estimate join cardinalities downstream of the shuffle. Costs hashing every key value on the write path and 4 KiB per key column in each task's status update. | Review Comment: Good suggestion, added in 4f1ac84b1: `ballista.shuffle.collect_distinct_counts_precision`, default 12. - Accepts 4 to 16. Out-of-range values are clamped rather than rejected, like `ballista.pipelined.queue_capacity`, so they can't fail a shuffle write. - No proto change. A sketch's precision follows from its register count (2^p bytes), so `from_bytes` accepts every supported size. `merge` refuses a sketch of a different precision, and the scheduler leaves `distinct_count` absent for a column whose tasks disagree. Tasks of a job share a session config, so that is a guard, not an expected case. - `shuffle_bench --distinct-count-precision` for measuring it, and the config reference is regenerated. One cost: runtime-sized registers make the sketch update about 0.07 ns/row slower at precision 12 than the old fixed array (1.23 vs 1.16 ns/row, release build, `Int64` keys), around 0.02% of the ~325 ns/row in the `shuffle_bench` run in the description. I tried hoisting the loop invariants and slicing the registers to drop the bounds check; neither moved it beyond run-to-run noise, so I kept the simpler code. -- 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]
