1. 題目
公司希望了解桌面客戶端哪些功能最常用、不同版本的崩潰類別和地區級效能分布。每天約有 2,000 萬活躍裝置，每台裝置最多產生 200 筆遙測事件；產品團隊要求 24 小時內看到聚合趨勢，但隱私團隊禁止平台保存可還原的使用者行為時間線。
請設計隱私保護的遙測與分析平台。重點說明端側採集邊界、事件格式、匿名化或本地隨機化、中心側差分隱私、使用者級貢獻上限、預算與查詢介面、可靠性、刪除要求、權限和驗證。請明確哪些問題不能用「把 ID 雜湊一下」解決。
2. 約束與釐清
- 隱私單位優先按使用者或裝置定義，而不是把每筆事件視為獨立個體；必須說明共享裝置和多裝置使用者的邊界。
- 只允許收集預先登記的事件名稱、版本、粗粒度地區、效能桶和必要錯誤類別；禁止原始 URL、自由文字、完整 IP、精確位置和內容載荷。
- 統計結果按至少 24 小時視窗發布，要求小群體抑制、差分隱私預算和可追溯的查詢稽核。
- 遙測允許丟失和延遲，但不能因重試、快取或多副本讓單一使用者貢獻被無限放大。
3. 總體架構與資料流
端側 SDK 先執行事件白名單、欄位裁剪、值域限制和本地抽樣，再將批次寫入帶版本的遙測佇列。入口服務驗證簽章、大小、時間窗和速率，但不把帳號令牌當作分析鍵。串流處理層做使用者級去重、貢獻上限、時間視窗聚合和異常過濾；原始短期緩衝設定嚴格 TTL，長期倉庫只保存受保護的聚合中間結果。
client SDK
-> schema/allowlist + local sampling + coarse buckets
-> encrypted batch with rotating upload token
-> ingestion gateway (auth, size, rate, replay checks)
-> stream buffer
-> privacy transform (user contribution cap, clipping, optional local noise)
-> aggregate store
-> DP query service (budget, minimum group, audit)
-> dashboards and export API端側隨機化可以在不可信收集器前保護單次報告，但會降低準確率；中心式差分隱私適合可信內部聚合器統一管理使用者級預算。混合方案要明確每一層的威脅模型和保證，不能把多層雜訊簡單相加後宣稱更強隱私。
4. 資料模型、最小化與去重
事件包含 event_type、客戶端版本、粗粒度地區、效能桶、事件時間桶和協定版本。上傳批次帶隨機批次 ID、過期時間和簽章；服務端用短期內部鍵做冪等，不把穩定使用者識別寫進長期分析表。
同一使用者在視窗內對某功能的多次事件應按預先規則計數，例如每個使用者每天每功能最多貢獻一次。貢獻上限必須在使用者級執行，不能只在機器或批次級裁剪；否則攻擊者可以拆分批次繞過限制。崩潰堆疊、錯誤文字和 URL 需要在端側分桶或丟棄，避免自由文字成為隱性身分標識。
刪除要求需要定義可執行範圍：若長期倉庫只保留不可逆的差分隱私聚合，通常無法從聚合中準確刪除單一使用者；仍要刪除短期原始緩衝、撤銷後續採集，並在產品政策中說明聚合發布的不可逆邊界。
5. 隱私預算、可靠性與查詢介面
查詢服務按隱私單位、資料集和時間視窗維護 epsilon/delta 預算。每個正式查詢先校驗預算、最小群體門檻和允許維度，再從版本化聚合表生成加雜訊結果並寫稽核記錄。相同邏輯查詢的重試必須回傳冪等結果或只記帳一次；任意增加篩選維度都可能消耗額外預算。
事件上傳採用至少一次傳輸。端側批次可重試，入口以批次令牌去重；串流處理按使用者和時間桶去重，並將無法確認的遲到事件放入隔離佇列。丟包、延遲和抽樣率必須進入品質指標，否則儀表板的下降可能被誤判為產品行為變化。
系統容量按 2,000 萬裝置、每台每天最多 200 筆事件估算，理論上限為 40 億事件／天；實際設計應使用抽樣、批量壓縮和分區儲存，並為版本發布、崩潰風暴和重播保留餘量。查詢層要限制高基數切片、並行匯出和跨視窗 join，防止預算與資源同時耗盡。
6. 追問與陷阱
- 雜湊裝置 ID 是否匿名？ 穩定雜湊仍可跨事件關聯，結合外部資料可能重新識別；應優先短期令牌、粗粒度欄位和使用者級聚合。
- 端側雜訊和中心側雜訊如何選？ 端側模型降低對收集器的信任要求但變異更大；中心模型便於統一預算和查詢，前提是聚合器與原始緩衝的存取邊界可信。
- 如何處理崩潰風暴？ 端側抽樣和速率上限先保護使用者與入口，閘道隔離異常版本，佇列背壓和降級查詢保護下游；不能只擴容資料庫。
- 能否回答任意分析問題？ 不能。白名單指標、最小群體、預算會計和維度限制是產品契約；探索需求應走審批和獨立預算。
7. 驗證與執行指標
- 隱私性質： 用相鄰使用者資料集測試貢獻上限、雜訊校準、預算組合和查詢拒絕，稽核每個發布版本的參數。
- 資料品質： 監控抽樣率、覆蓋裝置數、重複率、遲到率、丟包率、版本分布和視窗完整度，並與受控合成資料對帳。
- 可靠性： 對入口、佇列、聚合器和預算服務注入故障，驗證重試冪等、背壓、隔離佇列、恢復點和無原始資料洩露。
- 濫用防護： 測試高維查詢、並行匯出、預算耗盡、權限越權、批次重播和自由文字注入，確認都有拒絕或降級路徑。
8. 面試評分點
能畫出隱私邊界和資料流
候選人應明確端側、入口、短期緩衝、聚合層和查詢層分別信任什麼、保存什麼、何時刪除。
能把使用者級貢獻落實到實作
應說明按使用者和視窗去重、貢獻上限、裁剪、批次冪等與遲到事件處理，避免只在文件寫「匿名化」。
能把預算與可靠性一起設計
應覆蓋 epsilon/delta 會計、重試只記帳一次、最小群體、查詢維度限制、背壓和故障恢復。
能給出量化驗證方案
應使用 40 億事件／天的上限估算，提出隱私性質、資料品質、可靠性和濫用測試，而不是只給元件清單。