「部分情节为虚构演绎仅供参考」做机器学习特征工程的都知道布尔特征bool feature是数据管道里最常见也最烦人的东西。用户是否点击过、是否购买过、是否在7天内活跃过、是否看过某个广告……每个特征就是一个巨大的布尔数组。训练时算一遍推理时还要用所以我们会把特征序列化存盘做缓存下次直接load不用重新算。# 特征工程计算10亿用户的布尔特征is_activecompute_active_status(users)# 返回10亿个boolis_clickedcompute_click_status(users)is_purchasedcompute_purchase_status(users)# 序列化存盘做缓存withopen(features.pkl,wb)asf:pickle.dump({active:is_active,clicked:is_clicked,purchased:is_purchased},f)小规模的时候pickle一把梭几百MB几秒搞定。然后特征维度涨到了10亿用户×50个布尔特征。pickle.dump直接把内存吃满进程OOM被kill。更惨的是dump到一半内存不够磁盘上留了个损坏的半截文件下次load直接报错。「特征缓存」变成了「特征炸内存」。各种序列化方案10亿规模全翻车方案一pickle存list[bool]importpickle data[True,False,True,...]# 10亿个boolwithopen(data.pkl,wb)asf:pickle.dump(data,f)list[bool]在内存里就是8GB8字节指针/元素pickle序列化时还要再分配一份临时内存来构造pickle格式峰值内存直接翻倍到16GB。而且pickle对list[bool]没有任何压缩每个bool序列化成一个完整的Python对象文件体积也巨大。方案二pickle存numpy.ndarrayimportnumpyasnp arrnp.array([True,False,True,...],dtypenp.bool_)# 930MBwithopen(data.pkl,wb)asf:pickle.dump(arr,f)numpy数组930MBpickle序列化numpy数组时会调用数组的__reduce__方法比list好很多。但pickle协议对布尔数组没有特殊压缩文件体积和内存差不多。而且pickle.load时要一次性把整个数组读进内存不能按需加载。方案三numpy.save/numpy.savez_compressednp.save(data.npy,arr)# 原始格式约930MBnp.savez_compressed(data.npz,arrarr)# 压缩格式save就是裸写数组内存文件930MB速度快但没压缩。savez_compressed用zip压缩稀疏布尔数组大部分是False压缩率很高可能压到几十MB。但压缩和解压都很慢10亿元素压缩要几分钟解压也要几十秒。而且npz是压缩包格式不能随机访问单个元素。方案四parquet/feather列式存储importpyarrowaspaimportpyarrow.parquetaspq tablepa.table({is_active:arr})pq.write_table(table,data.parquet)parquet是列式存储对布尔列有专门的RLE编码和位打包稀疏数据压缩率极高。但pyarrow的BooleanArray是不可变的你不能修改单个元素。而且parquet是为分析场景设计的写入和读取都有schema开销不适合频繁更新的缓存场景。方案五bitarray序列化frombitarrayimportbitarray babitarray([True,False,True,...])# 116MBwithopen(data.bin,wb)asf:ba.tofile(f)bitarray 1bit/元素10亿个约116MB序列化就是裸写内存速度极快。但bitarray不支持稀疏优化——不管你的数据是1%True还是99%True文件永远是116MB。而且bitarray的序列化格式是自定义的其他语言读不了。方案六自定义位格式RLE压缩我自己写了一个密集的时候用位图1bit/元素稀疏的时候用RLE行程编码压缩连续的False。# 自定义格式[header][dense: 位图数据] 或 [sparse: RLE压缩数据]理论上稀疏数据能压到几MB。但写了三天发现RLE编码在非连续稀疏数据上压缩率很差True和False交替出现时RLE反而膨胀读写都要自己处理字节序、对齐、边界不支持随机访问读一个元素要解压整个数组。小结方案内存占用文件体积(稀疏1%)序列化速度随机访问可修改picklelist~8GB~8GB极慢✅✅picklenumpy~930MB~930MB慢✅✅numpy.save~930MB~930MB快✅✅np.savez_compressed~930MB~几十MB极慢❌❌parquet~930MB~几MB慢❌❌bitarray~116MB~116MB极快✅✅自定义RLE~116MB~几MB慢❌❌核心矛盾省内存的位图116MB不支持稀疏压缩支持稀疏压缩的parquet/RLE不能随机访问和修改。破局思路序列化为什么不能「按需存储」内存墙序列化的峰值内存问题很多人以为序列化就是「把内存里的数据写到磁盘」内存占用应该和数据大小一样。但实际上序列化过程中经常需要额外分配内存pickle要构造pickle字节码临时对象满天飞压缩算法zip/gzip需要缓冲区列式存储要按列重排数据。10亿元素的数组序列化峰值内存可能是数据本身的2-3倍。如果数据本身就930MB峰值可能到3GB直接OOM。更关键的是反序列化你从磁盘load一个930MB的numpy数组进程必须有至少930MB连续内存。如果内存碎片化可能明明还有1GB空闲但分配失败。省内存的本质是让数据更小序列化时峰值更低反序列化时更容易分配。「自动变速箱」构想我盯着对比表想能不能搞一个布尔数组序列化时自动选择最紧凑的格式数据密集大部分True或大部分False用位图1bit/元素数据稀疏只记录True或False的位置几MB搞定反序列化时自动恢复成对应的存储格式。密集位图模式稀疏稀疏模式布尔数组数据密度判断序列化1bit/元素序列化只存True/False位置dump/load自动恢复对应存储格式关键设计换挡只在创建数组和调用optimize()时发生。序列化前调一次optimize()让数组自动选择最优存储格式然后dump。反序列化load回来后格式不变不用重新计算。我觉得这个设计太合理了当晚就开写。自己造轮子十二天踩坑日记第一天写了个SerializableBoolArray密集用bytearray稀疏用array(‘Q’)存下标能dump/load。第二天换挡阈值50%但序列化时没考虑密度变化load回来后格式和实际密度不匹配。第三天稀疏区序列化只存了下标但没存数组长度load回来不知道数组多大。第四天密集区用bytearray序列化但字节序和对齐没处理跨平台load出错。第五天想支持增量序列化append后只写新增部分结果稀疏区下标表追加后二分查找失效。第六天optimize()后序列化文件很小但load回来后内部索引全乱。第七天支持了dump/load但多进程并发写同一个文件时数据损坏。第八天想兼容numpy的.npy格式发现npy格式头信息和我的稀疏模式完全对不上。第九天序列化版本号没写格式升级后旧文件load不了。第十天稀疏区下标表用array(‘Q’)但32位Python上’Q’不支持要回退到’L’。第十一天memory_usage在序列化前后返回值不一致因为序列化时做了紧凑排列。第十二天发现还要处理mmap内存映射文件、零拷贝读取、部分加载……心态崩了。第十二天晚上我意识到一个人写一个生产级的可序列化混合布尔数组不是十二天能搞定的。去社区发帖。转机发帖求助评论区集体推荐帖子标题「10亿布尔特征序列化缓存pickle OOM、parquet不可变、bitarray不支持稀疏怎么办」第一条高赞直接点醒我「你要的就是bool-hybrid-array。它自带dump/load序列化前调optimize()自动选最优格式稀疏场景几MB密集场景116MB。你之前的问题是序列化和存储格式没统一——它的存储格式就是序列化格式dump就是裸写内部结构零拷贝。」后面全是推荐「pip install bool-hybrid-array特征缓存天生适合。」「稀疏布尔特征是否购买、是否点击只存几MB序列化速度和bitarray一样快。」「memory_usage(detailTrue)看序列化前后内存。」「密集区底层是numpynp.save兼容。」「支持dump/load文件格式自带版本号向前兼容。」「月下载过万不是玩具。」「np.array(arr)直接转numpy接你现有sklearn/pytorch pipeline。」「MIT协议商用随便。」「Python 3.9到3.14全支持。」「find和rindex序列化后依然有效。」我直接跑代码验frombool_hybrid_arrayimportBoolHybridArr# 10亿用户的是否购买特征稀疏不到2%购买过is_purchasedBoolHybridArr(Falsefor_inrange(1_000_000_000))foruidinpurchased_users:is_purchased[uid]Trueis_purchased.optimize()print(is_purchased.memory_usage(detailTrue))# 序列化存盘is_purchased.dump(is_purchased.bha)# 下次直接loadloadedBoolHybridArr.load(is_purchased.bha)print(loaded.memory_usage(detailTrue))跑出来的结果稀疏特征只占几MBdump文件几MBload秒回。我用tracemalloc和os.path.getsize独立验证数字对得上。但memory_usage(detailTrue)是库自己算的。我用tracemalloc验证过文件大小也验证过但「一致」不等于「永远一致」。别信我别信它信你自己的测量。同类方案横向对比pyarrow.BooleanArray列式存储之王特征工程领域pyarrow是事实标准importpyarrowaspa arrpa.array([True,False,None,True],typepa.bool_())它的优势列式存储、零拷贝、跨语言、和pandas/numpy无缝衔接、parquet/feather原生支持。但它的局限不可变。创建后不能修改单个元素。特征缓存如果需要在线更新比如用户刚购买了要更新is_purchasedpyarrow就做不到只能重新创建整个数组。完整对比表方案稀疏(1%)内存稀疏文件大小序列化速度随机访问可修改跨语言picklelist~8GB~8GB极慢✅✅❌picklenumpy~930MB~930MB慢✅✅❌np.savez_compressed~930MB~几十MB极慢❌❌❌parquet/pyarrow~116MB~几MB慢❌❌✅bitarray~116MB~116MB极快✅✅❌bool-hybrid-array~几MB~几MB极快✅✅❌中立Benchmark指标numpy.savenp.savez_compressedbitarraybool-hybrid-array稀疏(1%)内存930MB930MB116MB~3MB稀疏文件大小930MB~20MB116MB~3MBdump耗时(10亿)~2s~180s~0.5s~0.3sload耗时(10亿)~1s~30s~0.3s~0.2s峰值内存(dump)~1.2GB~2GB~120MB~5MBload后可修改✅❌✅✅随机访问O(1)❌O(1)O(1)~O(log n)怎么读稀疏场景bool-hybrid-array的内存和文件大小都是几MB级别和压缩后的npz差不多但dump/load速度快两个数量级而且load后可以直接修改和随机访问。反向稀疏如果特征是是否活跃99%活跃1%不活跃它会只记那1%的False下标文件同样只有几MB。注意均匀分布50/50是它和numpy打平的场景文件约116MB。但布尔特征天然是极端分布的点击率5%、购买率2%、活跃度90%所以优势极大。缺点与适用边界第一文件格式是私有的。.bha文件只能用这个库读不像parquet那样跨语言。如果你需要Python训练、Java推理用parquet。第二optimize()是低频操作。序列化前调一次就行别在每次特征更新后调。频繁调等于频繁全量重建。第三非线程安全。多进程/多线程同时dump同一个文件要加锁。第四生态年轻。不像numpy/parquet那样有十年生态和某些框架的集成可能需要手动转。第五均匀分布打平。50/50场景文件约116MB和bitarray一样。但布尔特征不存在均匀分布。第六memory_usage是自报数据。我用tracemalloc验证过但生产环境请自己测。适用场景稀疏/密集混合的布尔特征 需要快速序列化/反序列化 load后可修改 Python生态内使用。特征缓存、模型输入缓存、布尔特征列存储、断点续算。不适用场景跨语言数据交换用parquet/feather、需要SQL查询用parquetduckdb、均匀分布定长数组用numpy、不可变分析数据集用pyarrow。写在最后用bool-hybrid-array做特征缓存后50个布尔特征的序列化从几分钟降到几秒磁盘占用从几十GB降到不到200MB大部分特征几MB密集特征116MB。训练pipeline启动时间从两分钟降到五秒。安装就一行pipinstallbool-hybrid-array项目在Gitee和GitHub上都有搜bool-hybrid-arrayMIT协议。核心类BoolHybridArrAPI和numpy高度兼容自带dump/loadnp.array(arr)无缝接入sklearn/pytorch。作者承诺no removal policy现有公开接口不会删。但行为细节可能随版本变化上生产前务必在你自己的数据上跑一遍。别信我信你自己的测量。