76 lines
6.1 KiB
JSON
76 lines
6.1 KiB
JSON
{
|
||
"topic": "heavykeeper-topk",
|
||
"type": "short_answer",
|
||
"schema_version": "1.0.0",
|
||
"generated": "2026-09-09T21:42:00+08:00",
|
||
"questions": [
|
||
{
|
||
"id": "sa-001",
|
||
"type": "short_answer",
|
||
"difficulty": 3,
|
||
"tags": [
|
||
"heavykeeper-topk",
|
||
"cms"
|
||
],
|
||
"question": "请对比说明 HeavyKeeper 和 Count-Min Sketch (CMS) 在处理「冷 Key 与热 Key 哈希冲突」时的行为差异，以及这种差异对 Top-K 探测准确性的影响。",
|
||
"answer": "CMS：冷 Key 与热 Key 哈希到同一桶时，冷 Key 的频率会累加到热 Key 上，且 CMS 只做加法不做减法，导致热 Key 的频率被持续高估（正偏差），冷 Key 的存在会'污染'热 Key 的计数。HeavyKeeper：采用概率衰减淘汰策略——当冷 Key 冲突到热 Key 的桶时，会以较高概率递减桶计数（因为冷 Key 频率低对应桶 count 小，衰减概率高）；而热 Key 自身频繁命中会保持高 count，衰减概率低，不易被淘汰。结果是冷 Key 的污染被逐步清除，热 Key 的计数更准确。",
|
||
"keywords": [
|
||
"冷热冲突",
|
||
"概率衰减",
|
||
"计数累加",
|
||
"正偏差",
|
||
"污染"
|
||
],
|
||
"scoring_rubric": "评分标准：1. 准确描述 CMS 在冷热冲突时的行为——冷 Key 计数累加到热 Key 导致正偏差（2分）；2. 准确描述 HeavyKeeper 的概率衰减淘汰机制——低 count 衰减概率高、高 count 衰减概率低（2分）；3. 对比两者对 Top-K 准确性的影响——CMS 会误判、HeavyKeeper 更准确（1分）",
|
||
"explanation": "CMS 的核心缺陷是只增不减，冷 Key 的污染是永久性的。HeavyKeeper 通过指数衰减（0.92^count）让冷 Key（小 count）容易被淘汰，而热 Key（大 count）几乎不受影响，实现了'自清洁'效果。这是 HeavyKeeper 相比 CMS 在 Top-K 场景下的核心优势。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sa-002",
|
||
"type": "short_answer",
|
||
"difficulty": 4,
|
||
"tags": [
|
||
"heavykeeper-topk",
|
||
"heavykeeper"
|
||
],
|
||
"question": "HeavyKeeper 的 fading() 机制是如何实现时间窗口适应性的？请解释其工作原理以及为什么需要定期调用。",
|
||
"answer": "fading() 通过全局衰减实现时间窗口适应：每次调用时，将所有桶的计数、minHeap 中节点的计数、以及全局 total 都执行右移一位（除以 2）。效果等价于指数衰减的时间窗口——历史数据的权重随时间指数衰减。定期调用 fading() 的必要性：1. 数据流分布会随时间变化（如电商大促导致热点切换），不衰减会导致旧热点长期占据 Top-K 位置；2. 衰减让低频的旧 Key 逐渐被淘汰（count 趋向 0），腾出位置给新的热点 Key；3. 模拟滑动时间窗口，使算法只关注近期的数据分布。",
|
||
"keywords": [
|
||
"fading",
|
||
"指数衰减",
|
||
"时间窗口",
|
||
"右移减半",
|
||
"分布变化"
|
||
],
|
||
"scoring_rubric": "评分标准：1. 正确解释 fading() 的操作——对桶计数、堆节点、全局 total 统一执行右移减半（2分）；2. 说明指数衰减的时间窗口效果——历史权重随时间递减（1分）；3. 解释定期调用的必要性——适应数据分布变化、淘汰旧热点、腾出空间给新热点（2分）",
|
||
"explanation": "fading() 是 HeavyKeeper 区别于 CMS 的关键机制之一。CMS 没有内置衰减，数据分布变化后只能重建。HeavyKeeper 通过简单的位运算实现了优雅的指数衰减，兼顾了实现简洁性和运行效率。",
|
||
"source": null,
|
||
"related": []
|
||
},
|
||
{
|
||
"id": "sa-003",
|
||
"type": "short_answer",
|
||
"difficulty": 5,
|
||
"tags": [
|
||
"heavykeeper-topk",
|
||
"heavykeeper",
|
||
"hot-key-detection"
|
||
],
|
||
"question": "假设需要在生产环境中使用 HeavyKeeper 实现 Top-100 热 Key 检测（width=100000, depth=5, minCount=10），请分析：(1) 该配置的内存开销大约是多少？(2) 与同等精度的 CMS 相比，HeavyKeeper 的内存开销有何差异？(3) 在什么场景下应该选择 HeavyKeeper 而非 CMS？",
|
||
"answer": "(1) 内存开销分析：每个 Bucket 存储一个 fingerprint（8 字节 long）+ 一个 count（4 字节 int）+ 对象开销，假设约 24-32 字节。总桶数 = 5 × 100000 = 500000，桶内存 ≈ 500000 × 24 ≈ 12MB。加上 lookupTable（256 × 8 = 2KB）、minHeap（100 个节点，可忽略）、其他元数据，总计约 12-15MB。(2) 与 CMS 对比：CMS 每个计数器通常用 4 字节（int），相同 width×depth 配置下 CMS 只需 5 × 100000 × 4 ≈ 2MB。HeavyKeeper 多了 fingerprint 存储和对象开销，内存约为 CMS 的 5-7 倍。但 HeavyKeeper 的 Top-K 结果更准确（冷 Key 自清洁），这是用额外内存换精度。(3) 选择 HeavyKeeper 的场景：需要实时 Top-K 热 Key 探测且数据流分布会随时间变化（如 CDN 访问热点、电商流量分析）；选择 CMS 的场景：只需要频率估计且内存极度受限，或数据分布稳定不需要衰减。",
|
||
"keywords": [
|
||
"内存开销",
|
||
"width",
|
||
"depth",
|
||
"fingerprint",
|
||
"CMS 对比",
|
||
"场景选择"
|
||
],
|
||
"scoring_rubric": "评分标准：1. 正确计算 HeavyKeeper 内存开销——桶数 width×depth、每桶 fingerprint+count 约 24-32 字节、总计约 12-15MB（2分）；2. 正确对比与 CMS 的内存差异——CMS 仅存计数约 2MB，HeavyKeeper 约 5-7 倍但精度更高（2分）；3. 准确区分适用场景——HeavyKeeper 适合动态变化的 Top-K，CMS 适合静态频率估计或内存极度受限场景（1分）",
|
||
"explanation": "内存分析是工程实践中的关键考量。HeavyKeeper 的额外内存主要来自 fingerprint 存储和 Java 对象开销。在生产环境中，如果内存预算允许且需要高质量的 Top-K 结果，HeavyKeeper 是更好的选择。如果内存极度紧张或只需要粗粒度的频率估计，CMS 可能更合适。",
|
||
"source": null,
|
||
"related": []
|
||
}
|
||
]
|
||
} |