Azure Storage · Phone Screen System/Coding Design

Microsoft Azure 大文件块去重:16GB 内存、两类重复与冗余率

无序记录含块大小、压缩大小、校验码和地址;按大小+校验码保留代表块,用外部分区与精确计数应对 16GB 内存。

题目重点:无序记录含块大小、压缩大小、校验码和地址;按大小+校验码保留代表块,用外部分区与精确计数应对 16GB 内存。

题意与假设

这道练习题保留了面经中值得训练的核心约束,并将需要澄清的条件单独列出。现场拿到变体时,先和面试官确认这些条件。

  • 训练版唯一性键为 (原始块大小, checksum),不把压缩大小或地址放进键;相同键保留首次出现的完整代表记录。
  • 总块大小对输入每条有效记录累加,包含完全相同的重复行;唯一块大小每个键只加一次。这与题目给出的公式一致,若业务要先排除日志重放需重新约定。
  • 数据格式、checksum 长度和总记录数未给;不能仅凭 10%/3% 预测哈希表一定装入 16GB。
  • checksum 可能碰撞;按题目给定的‘大小+校验值即唯一’执行,生产级真内容相等需额外字节比对或强校验策略。

解题路线

  1. 定义流式 API:parseRecord→validate→key(size,checksum)→选择代表;用 128 位或任意精度累计 totalBytes/uniqueBytes,避免总文件超过 64 位时溢出。
  2. 若预估 distinct key 数×哈希条目实际开销低于 16GB 安全预算,在内存哈希表保存键及首条代表地址;扫描一次即可写去重结果和两种字节总数。
  3. 更稳健的外部方案按 key 的稳定哈希将原始记录写入多个磁盘分区,同时一遍累计 totalBytes。相同 key 必落同分区;逐分区载入内存去重并写唯一输出,若单个分区仍过大就递归分桶或外排。
  4. 每个分区只为首次键增加 uniqueBytes,故全局汇总无重复;输出如要保持原输入顺序,须在记录中保存原始序号并对代表再外部排序,额外 I/O 需要计入。
  5. 3% 完全行重复和 10% 块冗余用于容量估计与压测,不替代精确去重。监控坏记录、checksum 冲突风险、分区偏斜、输出文件原子发布和可恢复 checkpoint。

手动走一遍

三行:(size=10,checksum=h,address=A)、(10,h,B)、(10,h,B)。按内容键只保留 A 一行,totalBytes=30、uniqueBytes=10,冗余率 20/30。第二和第三行还构成整行重复;若先把整行重复剔出分母会得到另一业务指标,不能混用。

规模与取舍

内存方案扫描 N 行预期 O(N) 时间、O(D) 键内存,D 为不同 (size,checksum) 数;外部分区需要 O(N) 顺序读写加分区处理,磁盘空间约 O(N×记录大小),内存受最大分区不同键数控制。若外排方案则 O(N log N) 比较/外部归并量级。16GB 是机器总物理内存,不应全部分配给哈希表。

易错点与追问

容易失分的边界

  • 把地址加入唯一键,导致相同块不同地址无法去重。
  • 把 3% 整行重复率当成 10% 内容冗余率,两种口径不同。
  • 把压缩大小当原始 size 代入题目的总块大小公式。
  • 没有 N/键长度就声称 16GB 一定够。
  • 不同分区使用不同 hash 规则,使同键落到不同分区。

继续深挖

  • 如要求精确字节级同一内容而 checksum 可能碰撞,如何补验?
  • 输出需要按首见顺序时怎样外部排序?
  • 分区严重倾斜或 worker 失败时如何续跑而不重复计入 uniqueBytes?
  • 若压缩大小也要计节省比例,两个指标如何分别命名?
✓已复制微信号!