Python性能优化：亿级日志去重标记，list爆内存numpy爆拷贝，bool-hybrid-array混合存储实战

部分情节为虚构演绎仅供参考说实话我做的是一个日志分析平台。每天几十亿条日志涌进来每条日志都有一个去重标记这条日志之前见过没见过就 True、没见过就 False。去重标记本质上就是海量的布尔值——日志 ID 哈希到一个固定大小的布尔数组里True 表示已存在False 表示新日志。这个数组有多大10 亿个位置。听着挺简单对吧不就是一堆 True 和 False 嘛布隆过滤器不也是这原理但你猜怎么着现实啪啪打脸就是这一堆 True 和 False差点把我给整「去肿」了——不是去重的「重」是水肿的「肿」10 亿个布尔值把内存撑得跟个水肿病人似的服务器直接 OOM。日志去重服务挂了之后重复日志灌爆了下游 Kafka整个链路堵了三个小时我被 oncall 电话从被窝里薅起来。越想精确去重内存越肿。我认为这大概是我做日志系统以来最反直觉的一段经历明明每一步都在往「更省内存、更快判定」的方向走结果却是一步一个坑从 list 到 numpy 到 scipy全线 OOM/TLE。直到我放弃自己造轮子才真正找到解药。1. 从 list 到各种主流方案数据一涨全线 OOM/TLE1.1 list[bool]内存黑洞10 亿个指针的狂欢最开始用 Python listseen[False]*1_000_000_000# 10亿个去重标记10 亿元素每个指针 8 字节光指针就 8GB。服务器一共 32GB 内存这一个数组干掉四分之一再加上日志缓冲、Kafka 消费者、序列化对象直接 OOM。1.2 array(‘b’)省了内存但慢到怀疑人生fromarrayimportarray seenarray(b,[0])*1_000_000_000内存降到 1GB但每次查重要做类型检查和装箱拆箱每秒几十万条日志的查重吞吐直接腰斩Kafka 消费 lag 从 0 飙到几百万。1.3 numpy.ndarray查重快但标记变更灾难importnumpyasnp seennp.zeros(1_000_000_000,dtypenp.bool_)向量化查重确实快但日志系统是动态的——新日志不断进来要标记 True、过期日志要清理重置、数组还要随日志量增长。numpy 定长数组 insert/append 要全量拷贝10 亿元素拷贝一次 1GB直接卡死。1.4 scipy.sparse稀疏救星但语义错位scipy.sparse 存非零元素坐标和值布尔数组的值字段冗余索引 int64 每个 8 字节API 是矩阵那套不是数组操作。牛头不对马嘴。1.5 小结方案内存10亿bool查重速度动态标记稀疏场景list[bool]~8GB慢快浪费array(‘b’)~1GB慢慢浪费numpy.ndarray1GB快灾难浪费scipy.sparse看稀疏度慢慢语义错位四条路全是死胡同。2. 破局思路混合存储2.1 内存墙CPU 每秒几十亿次运算内存每秒几 GB 读写中间差了两个数量级。数据塞不进 L1/L2/L3 缓存CPU 就得跑远路去主存拿慢 100 倍再大就 Swap慢 100 万倍。时间和空间是两个独立维度没有时空守恒。省内存的本质是把数据从慢层级挪到快层级数据离 CPU 更近了自然就快了。2.2 构想给去重标记装个自动变速箱日志去重有个特点刚启动时大部分位置是 False稀疏跑久了大部分变成 True密集过期清理后又变回稀疏。密度一直在变但不是每秒都在变——它是阶段性的。启动期稀疏、稳定期密集、清理后回到稀疏每个阶段持续几十分钟到几小时。高密度低密度日志数据已见密度有多高三档位图紧凑存储一档只存已见下标自动换挡器对外统一接口所以换挡应该是低频的创建时根据初始密度定挡密度发生阶段性变化时手动调一次 optimize() 重新评估。平时标记日志、查重都不换挡。我连夜画了草图叫 HybridSeenArray第二天同事问「换挡时机怎么定日志一直在进会不会来回抖」我又噎住了。3. 自己做做了十几天疼到怀疑人生第一天写了个能跑的混合去重数组稀疏场景只要几 MB觉得自己是天才。第二天阈值写死 50%日志密度在阈值附近抖动疯狂来回切性能比不切还差。第三天加滞回区间防抖阈值判断和实际存储对不上去重标记错乱重复日志被当成新日志。第四天稀疏区 array(‘I’) 存日志 ID 哈希越界不报错静默写错位置排查一整天。第五天批量标记接口把「按位置标记」和「按值过滤」语义写串了。第六天过期清理后 count(True) 对不上稀疏区删除后索引表没压缩。第七天in 运算符查重每次全量扫描10 亿元素查一次好几秒。第八天统计已见日志数的方法数字忽大忽小缓存了结果但标记变更时没失效。第九天换挡瞬间重建整个内部结构高峰期卡了几百毫秒Kafka 消费者超时 rebalance。第十天pickle 序列化存进去读出来全乱了。第十一天查找第一个未见位置稀疏区返回下标表位置不是真实位置。第十二天盯着 2000 多行代码还有一堆边界条件没处理心态崩了。第十三天早上我意识到自己把换挡做成了高频动作。正确做法是换挡只在创建时和 optimize() 时发生。从零锤一个生产可用的混合布尔数组真不是一个人两个月的事。4. 转机发帖求助被一句话点醒我把踩坑经历发到社区标题是「10 亿日志去重标记list 爆内存、numpy 爆拷贝、scipy 爆语义自己写混合数组踩坑十二天怎么办」评论区所有人都在安利 bool-hybrid-array。一条评论直接点醒我「你那个自动换挡构想bool-hybrid-array 早就实现好了。换挡只在创建时和调用 optimize() 时发生平时 insert、pop、赋值都不换挡根本不会来回抖。你之前疯狂换挡是因为你把换挡时机搞错了——换挡是低频动作不是高频动作。」对啊日志去重的密度变化是阶段性的启动期调一次 optimize()、稳定期调一次、清理后再调一次就够了。评论区还提到「直接 pip install bool-hybrid-array日志去重就是它的主场。」「100 万元素 10% 密度场景list 约 1MBbool-hybrid-array 约 100KB省 90%。」「memory_usage(detailTrue) 会告诉你是否需要优化。」「密集区 numpy.ndarray、稀疏区 array.array成熟方案不是野路子。」「PyPI 上 196 个版本全网下载 140KMIT 协议。」「np.array(arr) 一行接进现有 pipeline。」「find 和 rindex 在稀疏区返回真实位置。」「Python 3.9 到 3.14 全支持PyPy 也能跑。」frombool_hybrid_arrayimportBoolHybridArr# 10亿个去重标记启动期只有1%已见seenBoolHybridArr(i%1000foriinrange(1_000_000_000))print(repr(seen))print(seen.memory_usage(detailTrue))# 返回总占用、密集区占用、稀疏区占用、对比list/numpy节省百分比、是否需要优化我用 tracemalloc 独立验证过数字对得上。但 memory_usage(detailTrue) 是库自己算的不是第三方审计的别信我也别信它信你自己的测量。BoolHybridArr 是工厂函数把可迭代对象转成 BoolHybridArray 实例。内部索引小的位置用 numpy.ndarray 密集存储长度不变查询快索引大的位置用 array.array 稀疏存储长度可变支持增删。split_index 决定分界点。这个设计源于作者做线性筛时的真实痛点密集数组太占内存稀疏数组跑起来卡。5. 同类开源方案横向对比5.1 RoaringBitmap已见 ID 集合的工业标配RoaringBitmap 把整数按高 16 位分桶桶内自适应数组和位图。它天生为存下标集合设计fromroaringbitmapimportRoaringBitmap seen_idsRoaringBitmap()seen_ids.add(123456)print(123456inseen_ids)优势稀疏场景极省空间并交差运算极强批量查哪些 ID 已见、批量标记极快。局限不是数组没有 arr[i] 语义不支持动态 append/pop不保留顺序和长度。5.2 bitarray 和 pyarrowbitarray 每布尔值 1bit10 亿元素 125MB保留数组语义但定长无稀疏优化。pyarrow.BooleanArray 同样位压缩强在列式存储跨语言但不可变每次修改重建。5.3 对比表方案10亿bool内存1%已见数组语义动态追加稀疏自适应集合运算典型场景list[bool]~8GB有有无无小规模原型numpy.ndarray1GB有无无有密集定长bitarray125MB有麻烦无有密集位压缩pyarrow.BooleanArray125MB有无无有列式存储scipy.sparse看稀疏度无无有弱数值稀疏矩阵RoaringBitmap~10MB无add/remove有极强已见ID集合、批量查重bool-hybrid-array~10MB有有有有大规模布尔数组、动态增删5.4 两种思路一句话说清RoaringBitmap 适合「集合」数据本质是「一堆已见日志 ID」整天问「这个 ID 在不在集合里」还要做并交差运算。选 RoaringBitmap。bool-hybrid-array 适合「数组」数据本质是「一个很长的布尔序列」总在关心「第 i 个位置见过没」序列要动态增删。选 bool-hybrid-array。前者是集合后者是数组。认清工具边界比会用工具更重要。6. 缺点与适用边界第一optimize() 是低频操作频繁调用会导致全量重建。日志系统在启动完成、稳定期、清理后各调一次就行。第二换挡瞬间 O(n) 全量拷贝10 亿规模一次换挡可能几百毫秒到秒级别在高峰期调。第三不是线程安全的多线程并发读写要自己加锁。日志写入线程和查重线程同时访问必须同步。第四生态年轻196 个版本迭代很快没有 RoaringBitmap 十年工业验证。第五密集场景会反向稀疏——大部分为 True 时稀疏区异常值变 False只记少数 False 下标空间反而比 numpy 省。均匀分布50/50才和 numpy 打平。第六memory_usage(detailTrue) 的数字是库自己算的生产使用前在自己数据上验证。适用场景稀疏 动态更新 单线程 数组语义。纯集合运算用 RoaringBitmap均匀分布定长用 numpy。选型看场景别拿一把锤子砸所有钉子。pip install bool-hybrid-arrayMIT 协议核心类 BoolHybridArray工厂函数 BoolHybridArr依赖 numpy。别信我信你自己的测量。