題幹與適用場景
這是資料工程與串流處理面試題。事件量達到數十億，查詢維度包含小時、租戶、地區，結果允許約 1% 相對誤差，但帳務、配額與稽核仍要求精確值。你要先確認誤差預算、時間視窗、遲到範圍、是否需要集合交集/差集，以及資料是否含可識別使用者識別碼。
題庫已有串流處理、熱點分割區和批流架構題；本題聚焦「可合併的基數草圖如何改變分散式去重成本」，不把某個資料庫產品當作答案。
面試官考察點
- 能否區分 cardinality、membership 與 frequency，避免把 HLL 當成 Bloom filter 或 Count-Min Sketch。
- 能否說明每個分片產生固定大小草圖，查詢時以逐暫存器最大值合併，而不是加總局部計數。
- 能否把誤差、遲到、重置、隱私與業務精確性轉成可驗證的契約。
普通回答只說「用 Redis HLL，記憶體很小」。強回答會先給精確基線，再說明近似方案的失效邊界，並定義回放、抽樣與漂移監控。
回答前需要澄清的問題
- 結果允許多大誤差？ 約 1% 的分析看板可以使用草圖；計費或合規報表必須走精確路徑或校準流程。
- 查詢是固定視窗還是任意時間範圍？ 固定小時可保存小時草圖；任意範圍需要可合併的時間桶，並定義桶邊界與保留期。
- 遲到事件最多晚多久？ 遲到範圍決定是否重開桶、保留原始事件，或只接受最終化水位線。
- 是否需要交集、差集或列出使用者？ HLL 的強項是聯集基數；需要成員、交集或刪除時要換集合、Theta 等結構或精確補算。
30 秒回答框架
「我先用精確集合作為正確性基線，但它的記憶體、網路 shuffle 與跨分片合併成本會隨不重複使用者數成長。若看板允許約 1% 誤差，我讓每個分片按小時、租戶和地區維護固定精度的 HyperLogLog，查詢時對相同維度的暫存器取最大值，再用統一估計器輸出結果。草圖只解決聯集基數，不能回答某個使用者是否存在，也不能可靠刪除。遲到事件依水位線重開有限視窗，超過視窗的修正進入精確回放。最後用全量小樣本與精確集合對帳，監控相對誤差、空桶、重複事件、草圖合併與隱私風險。」
分步驟深入解答
第一步：建立精確基線。
對每個 (hour, tenant, region) 保存使用者 ID 集合，結果是精確的，但分片必須傳送大量 ID 或執行全域 shuffle。若同一使用者跨多個分片，局部 COUNT(DISTINCT) 相加會重複計算。
第二步：說明 HLL 的核心狀態。
將穩定雜湊拆成暫存器索引和前導零長度。每個輸入只更新對應暫存器的最大值；估計器由所有暫存器的調和平均類統計量推導，並用小範圍修正降低偏差。工程回答不應憑空承諾固定誤差，精度由暫存器數量、雜湊實作和估計範圍共同決定。
第三步：解釋分散式合併。
相同維度的草圖必須使用相同暫存器數量、雜湊規範和編碼。合併不是把估計值相加，而是逐暫存器取最大值，因此先按分鐘聚合再合併到小時，仍能避免原始 ID shuffle。
for each event(user_id, bucket, tenant, region):
i, rank = hash_and_rank(user_id, precision)
sketch[bucket, tenant, region][i] = max(sketch[...][i], rank)
merged[i] = max(sketch_a[i], sketch_b[i])
estimate = hll_estimator(merged)第四步：處理遲到和視窗。
以事件時間分桶，並用水位線標記可最終化的桶。只在最大遲到範圍內接受更新；超過範圍的事件進入原始日誌回放或精確修正表。不能從 HLL 中刪除單一使用者，因此「撤銷一筆事件」需要重建受影響桶。
第五步：把近似結果和業務正確性分開。
對帳作業隨機抽取已關閉桶，用精確集合或離線 SQL 計算真值，記錄相對誤差、偏差方向和異常維度。計費、配額、隱私刪除等路徑保留精確帳本，草圖只作為低成本觀測或預估。
第六步：控制成本和隱私。
限制維度組合、桶保留期和每租戶草圖數量，避免高基數標籤產生海量狀態。雜湊輸入應使用受控正規化和金鑰輪換策略，存取草圖需授權；草圖不是匿名化保證，仍可能洩露群體規模。
高品質示範回答
「我會先問結果能不能近似。精確集合適合帳務和稽核，但在數十億事件、多個分片和長視窗下會帶來記憶體與 shuffle 壓力。看板允許約 1% 誤差時，我讓每個分片按固定時間桶和維度維護同配置的 HLL。事件經過穩定雜湊後更新一個暫存器，查詢階段對各分片暫存器取最大值，再執行同一估計器；絕不能把局部估計值相加。
我會用事件時間和水位線關閉桶，保留有限遲到視窗。視窗外的更正進入原始日誌回放，因為 HLL 不能刪除單一元素。每個版本記錄精度、雜湊規範與桶邊界，避免不同草圖不可合併。監控草圖大小、合併延遲、重複事件率與相對誤差；抽樣桶用精確集合對帳。帳務和合規刪除仍走精確儲存，HLL 只是分析加速層。」
常見錯誤
- 錯誤表現：把每個分片的估計值相加 → 失敗原因：同一使用者可能出現在多個分片 → 修正方法：合併暫存器後只估計一次。
- 錯誤表現：說 HLL 能判斷某個使用者是否訪問過 → 失敗原因：它只保留統計摘要 → 修正方法：需要成員查詢時使用集合或 Bloom filter，並說明誤報。
- 錯誤表現：遲到或刪除事件直接從草圖扣除 → 失敗原因：暫存器最大值無法逆向定位貢獻者 → 修正方法：重建桶或走精確修正表。
- 錯誤表現：用任意精度和雜湊混合合併 → 失敗原因：暫存器語意不一致 → 修正方法：把精度、雜湊、編碼和版本寫入草圖中繼資料。
- 錯誤表現：把草圖當作隱私保護 → 失敗原因：聚合規模仍可能洩露群體資訊 → 修正方法：授權、最小維度、保留期和隱私評估一起設計。
追問及應對
追問一：業務要求查詢任意 37 天視窗，怎麼組織桶？
按分鐘保存會產生較多狀態，但查詢可以合併連續分鐘草圖；再用小時和天級草圖降低長視窗讀取量。多級桶必須明確邊界，不能重複包含同一時間段；查詢規劃器選擇不重疊的最粗粒度組合，並在跨層邊界用細粒度桶補齊。
追問二：同一使用者的刪除請求必須在 24 小時內生效，HLL 還能用嗎？
HLL 不能執行按使用者刪除。保留可刪除的精確事件索引或加密映射，刪除時重建受影響桶並在看板層遮蔽舊版本；草圖只作為非權威近似快取。若法規要求證明刪除完成，必須以精確刪除帳本和回放校驗為證據。
追問三：合併後誤差突然從 1% 變成 8%，先查什麼？
先比較草圖中繼資料：精度、雜湊種子、暫存器編碼和版本是否一致；再檢查某個分片是否把估計值當暫存器、是否重複合併、是否出現異常高頻雜湊輸入。最後用可重現的小集合逐步建立單片、雙片和合併結果，定位估計器或序列化錯誤。