尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
火焰烟雾数据集1000张:从标注转换到YOLOv8训练避坑全指南
简介该数据集面向使用深度学习进行火焰烟雾识别的研究者与开发者由1000张已精确标注的火焰烟雾图像组成每张图片均带有边界框级标注明确标出火焰与烟雾的位置可直接用于训练YOLO等目标检测模型解决监控场景下火情初期的自动识别与定位问题。包体共2000个文件其中1141个jpg原图与1141个xml标注文件一一对应可用于读取目标类别、坐标与尺寸另有859个txt标签文件以及训练集、验证集划分列表便于快速进入训练与验证流程整体压缩包大小约420MB按PASCAL VOC常见方式组织适合作为项目起步数据。已有3411人浏览学习说明该数据在安防监控、消防预警、森林防火等场景中具有较高的实用参考价值。借助Python与YOLO训练框架可以完成真实场景下的火焰烟雾检测、模型效果评估与超参数调优也能结合数据增强手段提升泛化能力帮助开发者快速搭建可落地的预警系统。1. 火焰烟雾已标注数据集1000张小样本火灾检测的起跑线半夜值班室的监控墙上一团灰白色的烟雾从厂房角落飘起来算法框却迟迟不出现这种场景做安防检测的人多少都撞上过。火焰烟雾已标注数据集1000张对应的就是火灾检测模型从“能跑”到“敢用”的这一段路。1000张的规模不算大但对火焰和烟雾这种目标明确、类别清晰的检测任务来说它恰好能把数据格式、标注质量、训练参数、漏检误检这些关键环节完整地暴露出来。这份数据的价值不在于“多”而在于它是一个可以反复调、反复验的地基。适合正在做火灾报警、森林防火、化工园区安防或者想把手头自采数据整理成可用训练集的人。下面不绕弯子直接讲拿到数据集之后第一步该做什么。2. 先看透这套火焰烟雾数据集格式确认、类别分布与三条自检命令拿到任何一份“已标注数据集”我从来不会直接拉去训练。第一件事永远是搞清楚它到底是什么格式、标了哪些类别、图片有没有损坏。这个习惯救过我太多次尤其是火焰烟雾这类数据很多是从现场摄像头里导出再人工标的格式和口径经常会混训练之前不摸底后面会花十倍时间填坑。2.1 拿到数据集先确认的三件事标注格式、类别名、图片是否可读先打开图片文件夹和标注文件夹各看一眼。火焰烟雾已标注数据集最常见的存法是两种一种是VOC格式图片在JPEGImages目录标注在Annotations目录里每张图对应一个同名xml另一种是YOLO格式图片和txt标签分开txt里每行是“类别id cx cy w h”四个坐标值全部做了归一化。还有些数据会带COCO的json文件结构跟coco2017数据集结构类似所有图片的标注都汇总在一个大json里。这三种我都遇到过第一步不是靠猜而是肉眼挑两张验证一下。然后确认类别名。有些数据集把火焰和烟雾合成一个类“fire-smoke”有些拆成两类“fire”和“smoke”还有混进“flame”“fog”之类别名的。这一步直接决定后面的类别映射不要轻信压缩包备注我一般会写个小命令把所有xml里出现过的name统计一遍。最后确认图片能否正常解码别训练到一半因为某张坏图崩掉。下面这张表是我自己常用的判定依据你可以对照手上的数据快速定位。格式标注文件每张图标注内容常见目录结构VOC同名xmlobject/name/bndbox坐标是绝对像素(xmin,ymin,xmax,ymax)JPEGImages、AnnotationsYOLO同名txt每行一个目标cls cx cy w h全部归一化到0-1images、labelsCOCO单个jsonannotations数组含bbox、area、image_idtrain2017、val2017、annotations表格只解决“是什么”的问题真正动手前还要做一次全量体检别只抽查两张就下结论。2.2 1000张的train/val划分按场景切而不是随机切1000张看起来不大但划分方式能直接决定验证mAP真不真实。最常见的错误是随机打乱后划分同一个视频里连续几帧的火焰画面被同时分进train和val模型等于开卷考试val mAP虚高到95%到现场连续帧测试马上现原形。这个坑比较隐蔽因为loss曲线看起来完全正常。我一般会在划分前先看文件名规律很多数据集文件名里带拍摄点或时间戳比如“factory_day_0421.jpg”“forest_night_1307.jpg”这种。写划分脚本时以文件名前缀为单位划分保证同一场景的连续帧只进train或只进val。按7:2:1或者8:1:1分配如果夜间场景特别少优先把夜间样本留在val里白天多放train。还有一点val里一定要包含没有火焰的真实场景负样本这些用于测试误检率不只是看模型找得到目标。2.3 一条命令看清数据集质量坏图、漏标、类别混用体检脚本下面这个脚本是我转格式之前必跑的一次性输出三样东西类别分布、缺标注的文件清单、坏图清单。前两个决定数据能不能用第三个决定训练会不会中途崩。# dataset_check.py 火焰烟雾数据集体检脚本 import os from pathlib import Path from PIL import Image import xml.etree.ElementTree as ET img_dir Path(数据集/JPEGImages) # 图片目录按实际修改 ann_dir Path(数据集/Annotations) # 标注目录 fmt voc # voc 或 yolo按实际修改 cls_counter {} missing [] broken [] for img_path in sorted(img_dir.iterdir()): if img_path.suffix.lower() not in {.jpg, .jpeg, .png}: continue stem img_path.stem ann_path ann_dir / f{stem}.xml if fmt yolo: ann_path ann_dir / f{stem}.txt if not ann_path.exists(): missing.append(stem) continue try: # Image.open是懒加载load()才会真正解码像素 Image.open(img_path).load() except Exception: broken.append(str(img_path)) if fmt voc: tree ET.parse(ann_path) for obj in tree.findall(object): cls obj.find(name).text.strip() cls_counter[cls] cls_counter.get(cls, 0) 1 else: for line in ann_path.read_text().strip().splitlines(): cls line.split()[0] cls_counter[cls] cls_counter.get(cls, 0) 1 print(类别分布:, cls_counter) print(缺标注图片数:, len(missing)) print(坏图数:, len(broken))这段代码的逻辑很简单按图片文件名去查找同名xml或txt找到就解析标注统计类别顺便用PIL的load()把图片强制解码一次。这里有个容易被忽略的点Image.open()本身是懒加载只有执行load()才会真正把像素读进内存文件头正常但中部损坏的图只有load()才能暴露出来。参数方面img_dir和ann_dir按实际路径改fmt决定用xml还是txt解析。如果脚本跑完类别分布里出现“unknown”或“object”这种泛化类别名说明标注时没按规范来尽早回去修别指望训练阶段自适应。脚本跑完后我还会顺手检查三个数字缺标注数除以总图片数超过1%就要警惕坏图数只要不为零就全部删掉或替换类别分布如果只有fire没有smoke检查是不是标注员把烟全标成了火。这三个数字正常情况下都应该非常干净任何一项异常都值得停下进度去处理。3. 把VOC标注转成YOLO格式归一化公式、转换脚本与最小训练命令如果数据集是VOC格式训练YOLOv8之前要先转成YOLO能吃的txt。这个转换看起来简单实际很容易出问题——坐标算错、宽高取错、类别序号和yaml没对上都会让训练变成一场灾难。我们一个一个拆开说。3.1 XML的bndbox到YOLO的cx,cy,w,h归一化公式和两个易错点VOC里box的四个值是绝对像素坐标xmin、ymin、xmax、ymax。YOLO要的是归一化相对坐标目标中心点cx、cy以及box的宽高bw、bh四个值全部除以图片宽高。公式很简单但有两个易错点。第一个是宽高用错了对象。有人直接用xml里的size节点但很多标注工具在截完图之后并没有更新xml里的size导致宽高和实际图片不一致。我一般直接从图片文件读取宽高不信xml里写的数据。第二个是忘记处理越界坐标有些框的xmax比图片宽度还大或者xmin是负的不裁剪就直接归一化训练时损失函数会跟着一起乱轻则mAP上不去重则训练根本收敛不了。这两个问题在火焰烟雾数据集里特别常见因为火焰边缘发光标注时经常把框拉出画面。3.2 批量转换脚本一条命令处理全部1000张标注# xml_to_yolo.py 批量将VOC xml转为YOLO txt import xml.etree.ElementTree as ET from pathlib import Path from PIL import Image # 类别映射顺序必须和后面yaml里的names一致 class_map {smoke: 0, fire: 1} src Path(数据集/Annotations) # VOC xml目录 img_dir Path(数据集/JPEGImages) # 原始图片目录 dst Path(数据集/labels) # 输出的YOLO txt目录 def convert_one(xml_path): tree ET.parse(xml_path) root tree.getroot() img_path img_dir / (xml_path.stem .jpg) with Image.open(img_path) as im: w, h im.size # 宽高以实际图片为准 lines [] for obj in root.findall(object): name obj.find(name).text.strip() cls_id class_map.get(name) if cls_id is None: print(f[跳过] 未知类别: {name} - {xml_path.name}) continue box obj.find(bndbox) x1 float(box.find(xmin).text) y1 float(box.find(ymin).text) x2 float(box.find(xmax).text) y2 float(box.find(ymax).text) # clip到图片边界过滤无效框 x1 max(0, min(x1, w)) x2 max(0, min(x2, w)) y1 max(0, min(y1, h)) y2 max(0, min(y2, h)) if x2 x1 or y2 y1: print(f[跳过] 无效框: {xml_path.name}) continue cx (x1 x2) / 2.0 cy (y1 y2) / 2.0 bw x2 - x1 bh y2 - y1 lines.append(f{cls_id} {cx/w:.6f} {cy/h:.6f} {bw/w:.6f} {bh/h:.6f}) out_txt dst / (xml_path.stem .txt) out_txt.parent.mkdir(parentsTrue, exist_okTrue) out_txt.write_text(\n.join(lines)) for xml_path in sorted(src.glob(*.xml)): convert_one(xml_path) print(转换完成输出目录:, dst)逻辑说明遍历xml读取图片真实宽高把每个object的坐标算成YOLO的cx、cy、w、h并归一化写进txt。两个参数要特别留意class_map的key是xml里的类别名value是类别id这个id必须和后面data yaml里的names顺序完全一致否则训练出来的模型类别会整个颠倒dst是labels输出目录和images平级等会儿训练时yaml里的路径就指到这里。脚本里的print日志不是多余的转完扫一眼“[跳过]”有没有刷屏比事后查mAP快得多。3.3 用YOLOv8跑通第一次训练yaml、命令行和训练日志快速判读转完之后把图片按train、val分开放好目录结构保持images/train、images/val、labels/train、labels/val四件套然后建一个数据描述yaml。train: data/fire_smoke/images/train val: data/fire_smoke/images/val nc: 2 names: [smoke, fire]注意names的顺序就是class_map里定义的顺序。训练命令先用最小配置跑通全流程yolo detect train \ modelyolov8n.pt \ datafire_smoke.yaml \ epochs50 \ imgsz640 \ batch16yolov8n是YOLOv8系列里最小的模型参数少适合先验证数据和链路通不通。batch16在多数8G显存的显卡上可以跑动imgsz640是默认值火焰烟雾这种目标尺寸差异大的场景先跑出基线再说。训练开始后重点看两列指标box_loss和cls_loss。正常曲线是前10个epoch快速下降之后缓慢震荡收敛。如果loss掉得飞快但P、R指标始终很低立刻停下来检查标签大概率是转换脚本的问题不要靠加大epoch硬补。提示第一次训练不要直接上yolov8x和大尺寸先在最小配置下跑通一遍确认标签没问题再加大规模。这个顺序能帮你省掉大量排查时间。3.4 转换完怎么验证把txt标签画回图片抽10张训练前最后一道手动检查是把生成的txt标签画回原图肉眼看框的位置和类别对不对。这一步不需要额外装库OpenCV几行就能做。我一般会随机抽10张覆盖白天、夜晚、室内、室外四种场景把框和类别名画上去看一眼。如果发现框的位置整体偏移回去查图片尺寸是不是取错了如果发现大目标被切成了碎框回去查是不是标注阶段就有问题。这个检查用不了五分钟但能拦住80%的标签事故。4. 火焰烟雾模型必调的三个参数cls权重、imgsz与置信度阈值数据链路跑通之后接下来的工作全是围绕“漏检”和“误检”这两个目标调参。火焰烟雾场景跟普通目标检测不太一样漏掉一团烟可能意味着整条生产线烧掉所以参数设置的优先级基本是先保召回、再压误报。下面三个参数是我每次做火焰烟雾项目都必调的。4.1 漏检比误检更要命先把cls损失权重提上来YOLOv8的训练参数里有三个损失权重box、cls、dfl。box控制框的位置回归cls控制分类dfl控制框边分布。火焰烟雾场景里漏掉一团烟比多框一个普通物体严重得多所以我一般会把默认的cls0.5提到0.7到1.0让模型更在意“这个东西到底是烟还是背景”。yolo detect train \ modelyolov8s.pt \ datafire_smoke.yaml \ epochs150 \ imgsz960 \ batch8 \ box7.5 cls0.8 dfl1.5这里的box7.5和dfl1.5是YOLOv8的默认值不用动只动cls。火焰和烟雾本身颜色纹理差异大提高cls对分类任务影响很明显。不过cls不是越高越好提到1.2以上会把雾气、蒸汽、炊烟全部当成烟误报会压不住。我的经验是在0.7到1.0之间来回试每次只改0.1用val集对比结果。4.2 烟雾是小目标imgsz和显存怎么权衡这是火焰烟雾检测里最容易踩的视觉坑远处的浓烟在画面里可能只占几十像素。如果imgsz640这种小目标经过下采样后只剩一两个像素特征基本丢光。很多项目在标好的展示图上看着很准换到现场远距离摄像头立刻失效原因就是imgsz没有跟着实际部署场景改。现场摄像头的图像一般是1080p甚至更高在网络能承受的范围内我一般直接把imgsz提到960目标很小的时候甚至上到1280。代价是显存翻倍。8G显存跑imgsz960时batch要降到8跑1280时batch只能到4。这时候优先保imgsz牺牲batch因为小目标检测的收益来自分辨率而不是每批看多少张。如果你的显卡实在撑不住另一个办法是把原图切块训练但这会引入新的边界框裁剪问题我一般不到万不得已不用。4.3 conf阈值降到0.15不是作弊把它当成报警后处理的一部分训练完成后做预测很多人随手设个conf0.25就不管了。火焰烟雾现场报警漏报一次就可能烧掉整个仓库宁可多几次误报。我一般推理时设conf0.15配合帧间去重后处理——连续三帧都有框才触发报警单帧的误报根本构不成报警。要理解conf表示的是模型对预测框的主观置信度调低它并不会改变模型本身的精度它只是改变业务系统的敏感度。真正导致漏报的往往是数据集缺真实拍摄场景这个问题在下一章展开。5. 火焰烟雾训练避坑清单五个最容易翻车的标注与训练问题下面这些坑我基本都踩过每一个都对应过真实项目的返工。按“现象→原因→解决”的方式写遇到类似情况可以直接照做。5.1 现象loss降得飞快验证mAP却一直是0训练日志里box_loss和cls_loss都掉得很漂亮但每轮结束的验证mAP稳在0一张框都出不来。最常见的原因是转换脚本把图片尺寸取错了比如xml里写的是1920x1080但实际图片已经被压成960x540归一化坐标整体放大了一倍box全部落在画面外。另一种情况是labels目录配错yaml里的train路径指向了一个空文件夹模型从头到尾都在学背景。解决方法是训练前跑一下标签统计看labels目录里有多少非空文件find data/fire_smoke/labels/train -name *.txt | wc -l find data/fire_smoke/labels/train -name *.txt -size 0c | wc -l两个数字如果差很多说明转换时大量文件被跳过回头检查转换脚本的日志。如果两个数字一致但mAP还是0用3.4的可视化脚本画几张图出来一眼就能看出坐标是不是飞到画面外。5.2 现象转换脚本跑完许多txt是空文件原因基本是两个xml里object的name不在class_map里被静默跳过了或者框太小x2减x1算出来小于1像素被当作无效框过滤掉。火焰烟雾的标注里常有极小目标比如远处烟头大小的火点这种框确实不应该被丢弃应该保留。解决方法是把“跳过”的日志保留下来而不是静默处理。在转换脚本里加一个计数器最后汇总打印“共跳过多少条unknown、多少条无效框”。如果unknown数量很大回到标注文件去看真实类别名把class_map补全。血泪经验是转换脚本不要静默所有丢弃行为都要有日志。5.3 现象白天测试准确傍晚和夜间误报爆炸白天在测试集上mAP有90%一到傍晚和夜间就疯狂误报把路灯、车灯、红色招牌全部当成火。原因是这1000张数据里几乎没有夜晚、黄昏、灯光下的画面模型没见过暗光环境就把暗部的暖色噪声当成火焰。这个坑在甲方自采数据里特别常见拍摄时间集中在9点到17点。解决分两步。第一步训练时打开色彩增强参数让模型对光照变化不敏感yolo detect train \ modelyolov8m.pt \ datafire_smoke.yaml \ epochs150 \ imgsz960 \ batch8 \ hsv_h0.02 hsv_s0.6 hsv_v0.4hsv_h、hsv_s、hsv_v分别控制色相、饱和度、明度的随机增强幅度把数值从默认的0.015、0.7、0.4稍微调整让模型在训练时见过更多暗光和偏色样本。第二步从现场监控视频里抽负样本帧没有任何火焰的真实场景直接放一张空jpg配同名空txt加入数据集。负样本不要求1000张每个场景抽50到100帧就够。5.4 现象同一团烟有的框框住整片烟有的框只圈住火芯做可视化抽检时发现同一段视频里不同帧对同一团烟的标注差异巨大有的框包住整片烟柱有的只框中间的火芯。原因是标注规范没定清楚烟和火的边界本来就是模糊的不同标注员理解不同。训练出来的模型会学到两个矛盾的模板预测框忽大忽小。解决方法是训练前强制统一标注规则比如“火焰框住火焰可见外沿烟雾框住整片可见烟柱”两类相交时以烟雾框为准。然后把有明显歧义的样本挑出来重标。这个检查要在训练前做训练后发现框抖动再回头重标返工成本高得多。5.5 现象epoch跑到一半显存溢出程序直接被杀我见过有人为了追求小目标精度把imgsz设成1280、batch设成16结果一张8G显卡第3个epoch就OOM。训练中断倒还好如果没开resume前面几十个epoch的进度全部清零。解决方法是降batch而不是降imgsz。小目标场景里imgsz优先级高batch从16降到8、4再不行就换卡。另一个办法是开启梯度累积YOLO里对应accumulate参数让多个小batch的梯度累加之后再更新。5.6 避坑复查清单训练前最后两分钟检查训练正式铺开之前按下面这张清单过一遍全绿再动手。这几步花不了多少时间但能拦住绝大多数返工。随机抽10张图把txt标签叠加可视化确认框的位置和类别与画面内容一致。labels目录里空txt数量接近零非空文件数等于原始标注文件数。类别id和yaml里names顺序完全一致没有颠倒。train和val的数据没有出现同一文件名前缀交叉避免数据泄漏。白天、黑夜、室内、室外、有烟无烟这几类场景在val里都有覆盖。这五条全过了再开长训练。任何一条有问题回到对应步骤去改别带着问题跑150个epoch。6. 从mAP到现场部署用连续视频帧验证火焰烟雾检测的稳定性mAP是模型在单张图片上的表现但现场摄像头是连续视频流。火焰烟雾检测最让人抓狂的不是精度本身而是“闪断”——上一帧有火下一帧没有再下一帧又有这种时有时无的预测会让报警系统不知所措值班员盯半小时就麻木了。我的做法是用一段包含真实烟火的连续视频跑逐帧预测统计两个数有目标帧占比、有到无的闪断次数。如果闪断次数太高说明置信度阈值或时域平滑需要调整。下面这个脚本就是干这个的。# video_stability.py 统计连续视频中的帧间闪断 import cv2 from ultralytics import YOLO model YOLO(runs/fire_smoke/train/weights/best.pt) cap cv2.VideoCapture(demo_fire.mp4) frame_id 0 fire_frames 0 flash_count 0 last_has_fire False while cap.isOpened(): ret, frame cap.read() if not ret: break results model(frame, conf0.15, verboseFalse) has_fire len(results[0].boxes) 0 if has_fire: fire_frames 1 if last_has_fire and not has_fire: flash_count 1 # 从有到无计一次闪断 last_has_fire has_fire frame_id 1 print(f总帧数: {frame_id}) print(f有目标帧数: {fire_frames}, 占比: {fire_frames/frame_id:.2%}) print(f闪断次数: {flash_count})逻辑说明逐帧送入模型记录每帧是否有目标框相邻两帧从有变成无计一次闪断。运行时把conf设成业务上实际使用的阈值而不是测试时的高阈值否则统计没有参考意义。如果“有目标帧占比”低于80%或者闪断次数占总帧数比例超过5%回头检查是imgsz太小导致小目标漏检还是cls权重偏低导致分类不稳。这个脚本也可以直接在哨兵摄像头录下的循环录像上跑不需要额外的标注。当初我接手第一个火焰烟雾项目时就是算完这些数字才决定返工补夜间数据的。先跑一遍视频稳定性比盯着mAP自我感动实用得多。这个检查顺序我沿用到现在希望帮到你。本文还有配套的精品资源点击获取
RELATED

相关推荐

从工作组到域环境:Windows网络身份管理与验证机制详解

从工作组到域环境:Windows网络身份管理与验证机制详解

1. 从一次真实的加域现场说起 前阵子帮一家做电商代运营的公司调整办公网络,他们大概三十几台电脑,从入职到现在一直用的是Windows默认的工作组模式。结果日常办公越来越别扭:设计部要访问一台共享素材服务器,得先在每台电脑上手动…

📅 2026/10/1 13:58:11
基于PyTorch的3D牙齿CBCT分割实战:从DICOM到训练优化

基于PyTorch的3D牙齿CBCT分割实战:从DICOM到训练优化

简介:基于Pytorch的三维牙齿CBCT图像分割项目,面向医学影像分析与深度学习学习者,也适合作为毕业设计参考,提供从数据预处理到模型部署的全流程实践。资源共五十九个文件,以三十九个Python脚本为主体,覆盖多…

📅 2026/10/1 13:58:11
Ubuntu 22.04 部署 Rime 引擎与雾凇拼音完整实践

Ubuntu 22.04 部署 Rime 引擎与雾凇拼音完整实践

想在 Ubuntu 22.04 Desktop 上把中文输入法调教到自己满意,很多人第一反应是搜狗拼音或百度输入法,但如果你是名开发者,或者对词库、隐私、跨平台一致性有执念,大概率最后都会绕到 Rime 引擎加雾凇拼音(Rime-Ice&#…

📅 2026/10/1 13:58:11
MORE NEWS

更多资讯

📰

wxPython之光标:TaoToken 统一 Key 接入下的桌面端光标状态管理实践

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

【Python 学习第 22 天】运算符

【Python 学习第 22 天】运算符学习日期:2026-09-30 知识点:运算符 难度:0.54一、今日知识点 今天学习的是 运算符。 运算符是 Python 中用于执行各种运算的符号,包括算术运算符(如 、-、、/、//、%、*)、比…

📰

周红伟:OpenClaw安全防控:OpenClaw+Skills+私有大模型安全部署、实操和企业应用实操|TaoToken统一Key接入

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

【Bug已解决】Permission denied EACCES / File operation errors — Claude Code 文件权限错误解决方案:把 settings 改到 TaoT

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

Vim插件之可见书签——Visual Mark 配置到 TaoToken 的完整实践

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

Snappy与Zstandard大对比:大数据压缩格式选型实战指南

这题我太熟了。不管是搞数仓、做实时计算还是维护Hadoop集群,压缩格式选型几乎是每天都要碰的事。早些年大家无脑选Snappy,因为这玩意儿到处都支持,性能也稳;但这两年Zstandard(简称zstd)势头很猛&#xff…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬