电商数据抓取项目里，最危险的阶段往往不是爬虫报错，而是程序显示“抓取成功”之后：同一商品出现三条记录，价格字段一半是数字、一半是“39.9元”，销量同时出现“1.2万”和“12000”，昨天抓到的库存又把上周的历史状态覆盖掉。表面看是数据清洗不彻底，实际上已经演变成了商品身份、字段类型、时间版本和存储层级的全面混乱。
电商数据抓取：研究团队新手问答：数据清洗做不好会出现哪些存储混乱
我在参与电商竞品监测、价格追踪和商品资料整理时，通常不会先问“抓到了多少条数据”，而会先问四个问题：这些记录能否识别为同一个商品？同一个字段的含义是否始终一致？历史状态是否能够追溯？出现异常时能否回到原始页面重新核验？如果这四个问题没有答案，抓取量越大，后续整理成本越高。
很多新手把清洗理解为删除空白、去掉重复行、统一日期格式。这些动作当然有必要，但它们只解决了数据表面整齐的问题，没有解决数据的业务含义。
例如，“销量为0”“页面没有显示销量”“销量字段抓取失败”这三种情况，都可能在页面上表现为空或0。但它们在研究结论中完全不同：前者代表确实没有销量，第二种代表平台未公开数据，第三种代表采集链路出现问题。
真正的数据清洗，是把页面中的原始表达转换成稳定、可解释、可追溯的业务字段。如果只追求表格看起来整齐，错误往往会在入库时被“合法化”，最后变成很难发现的统计偏差。
| 混乱层面 | 典型表现 | 直接后果 | 最先需要确认的事项 |
|---|---|---|---|
| 内容混乱 | HTML标签、乱码、特殊符号、字段截断 | 搜索、比对和文本分析失真 | 字符集、转义规则和文本清洗范围 |
| 类型混乱 | 价格、销量、库存同时以数字和文本保存 | 排序、聚合和条件筛选异常 | 字段类型与单位口径 |
| 身份混乱 | 商品、SKU、SPU、店铺编号混用 | 重复统计、错误更新、关系断裂 | 业务唯一键和数据粒度 |
| 版本混乱 | 当前价格与历史价格被覆盖或混存 | 趋势分析、增量抓取和复盘失效 | 抓取批次、状态时间和生效时间 |
这四种混乱并不是彼此独立的。商品ID缺失会导致重复数据，重复数据又会让价格历史失真；时间字段混用会让同一批数据被识别成多个版本，最终影响库存和销量趋势。
抓取成功率通常只回答一个技术问题：请求是否返回了内容。它不回答页面是否加载完整、字段是否处于正确位置、商品是否已下架、价格是否为活动价，也不回答当前记录能否与历史记录准确对应。
在一个模拟的价格监测任务中，采集程序连续三天返回了99%以上的HTTP成功结果，但研究人员最后发现，约12%的商品价格实际抓到了“券后价”，而不是页面标注的原价；另有约7%的记录将“暂无销量”转换成了数值0。程序没有报错，数据却已经无法直接用于横向比较。
因此，我更愿意把数据质量拆成两层：第一层是采集完整性，确认数据有没有被拿到；第二层是业务可用性，确认数据拿到之后能不能被正确理解和存储。研究团队最容易忽略的，正是第二层。
假设一个研究小组需要监测三个平台上的运动水杯，字段包括商品名称、店铺名称、价格、销量、库存、规格、商品链接和抓取时间。第一轮只采集一百条记录时，直接保存成一张Excel表，往往没有明显问题。
因为数据量小，研究人员可以手工查看商品名称，也能通过排序发现价格异常。即使同一个商品出现两次，也可能在人工检查时被及时删除。
问题在于，这种“人工看起来没问题”的状态很容易让团队误以为数据模型已经成立。实际上，第一轮只是没有暴露规模问题，并不代表字段定义和唯一键设计正确。
第二次抓取时，平台链接增加了推广参数，部分商品标题加入了“升级款”“新包装”等营销词。程序如果直接使用完整链接或标题作为商品标识，就会把同一商品保存成多个对象。
同时，商品规格可能以不同方式返回：有的页面把颜色和容量放在单独字段，有的页面把它们拼在“商品名称”末尾，还有的页面只返回默认SKU。于是同一个商品在表里出现了三种粒度：商品级记录、SKU级记录和页面级记录。
| 原始表达 | 程序保存结果 | 实际含义 | 建议处理方式 |
|---|---|---|---|
| 运动水杯 750ml 蓝色 | 商品名称 | 一个具体SKU的展示名称 | 拆分商品主体、容量和颜色 |
| 运动水杯 | 商品名称 | SPU或商品主体 | 建立商品主表记录 |
| 默认款 | 规格字段 | 页面没有明确返回SKU | 保留原始值并标记规格不完整 |
| 750ml / 蓝色 / 两件装 | 规格长文本 | 多个SKU属性组合 | 拆分属性或建立SKU明细表 |
第三轮抓取通常会引入历史数据。此时团队可能想知道价格是否下降、库存是否减少、销量是否增长，但原有单表设计往往只保留“最新一条记录”。如果程序用商品名称更新数据，标题变化会导致更新失败；如果程序用链接更新，链接参数变化又会制造新记录。
最终会出现三种相互矛盾的结果：商品数量被高估、价格趋势被拆断、库存变化无法解释。研究人员看到的不是平台真实状态，而是数据模型对页面变化的错误反应。
数据量小的时候，错误主要表现为“表里有几行不对”；数据量变大以后，错误会变成“所有统计口径都不稳定”。前者还能手工修正，后者会影响数据库更新、研究结论和团队协作。
存储设计必须在扩大采集范围之前完成，而不是等到数据已经混乱后再补救。正式采集前，至少应该用几十条包含不同平台、不同规格、不同价格状态的样本，验证唯一键、字段类型、时间字段和异常处理规则。
重复记录的来源远比“爬虫重复执行”复杂。常见原因包括链接参数不同、标题发生变化、店铺名称变更、页面存在多个入口、同一商品被不同任务重复采集，以及商品ID没有被正确解析。
使用标题去重尤其危险。标题可能因为促销、搜索词、包装升级和平台规则发生变化，也可能因为颜色、容量和套装数量不同而看起来相似。标题适合用于辅助匹配，不适合单独承担业务唯一键的职责。
更稳妥的匹配优先级通常是：平台商品ID、店铺ID加商品ID、SKU或规格ID、规范化链接，最后才是品牌、标题、规格等组合字段。不同平台无法共享同一个商品ID时，还需要建立跨平台商品映射，而不能假设同名商品就是同一对象。
商品主体、销售规格和页面记录是不同的数据粒度。商品主体可以是“运动水杯”，SKU则可能是“750ml、蓝色、两件装”，而页面记录还包括某次抓取时的价格、库存和评价数。
如果三者全部塞进一张宽表，最常见的问题是：商品级信息被重复写入每个SKU，SKU级库存又被误当成商品总库存，价格变化时整行被覆盖，最后无法判断某个数字到底属于商品还是具体规格。
| 数据对象 | 适合保存的字段 | 不适合直接放入的字段 | 典型更新频率 |
|---|---|---|---|
| 商品主表 | 平台商品ID、标题、品牌、类目、详情链接 | 某个SKU的库存、某次抓取价格 | 低频或页面变更时更新 |
| SKU表 | 规格组合、SKU ID、条码、规格状态 | 所有历史价格和抓取响应信息 | 规格变更时更新 |
| 价格历史表 | 商品或SKU ID、价格、促销状态、生效时间、抓取批次 | 完整详情页文本 | 每次抓取产生新记录 |
| 采集任务表 | 任务ID、来源、请求时间、响应状态、失败原因 | 作为商品唯一标识 | 每个任务或页面请求产生记录 |
价格字段是最典型的例子。页面可能出现“39.9”“39.90元”“券后29.9”“暂无报价”和“登录后可见”。如果没有先拆分数值、单位和状态，直接把所有内容保存到价格列，后续排序就会按照文本规则执行。
销量也一样。“1.2万”不能简单等同于字符串“1.2万”，但也不能在不确认平台口径的情况下直接转换成12000。它可能代表近30天销量、累计销量或页面展示的估算值，转换前需要保留原始文本和口径说明。
建议将一个展示字段拆成至少两个字段：一个保存规范化数值，一个保存原始表达或状态。例如，价格可以拆为price_value、price_currency、price_type和price_raw；销量可以拆为sales_value、sales_unit、sales_period和sales_raw。
“空”不是一种业务含义，而是一组不同状态的集合。数据库里的NULL、数字0、空字符串、暂无、未知、无法采集和不适用，不能在没有规则的情况下互相替换。
例如，库存为0可能表示真正售罄，也可能表示页面未返回库存字段；评价数为空可能是新商品没有评价，也可能是页面加载失败。如果一律转换成0，研究人员会得到一个看似完整、实际偏差很大的数据集。
我通常会把数据状态拆成“值”和“状态”两部分。以销量为例，sales_value保存可以确认的数值，sales_status则保存observed、not_disclosed、parse_failed或not_applicable等状态。这样下游分析可以选择只使用状态为observed的数据。
把“2026/09/13 10:00:00”转换成“2026-09-13 10:00:00”，只解决了展示格式问题，没有解决它究竟代表什么时间。
电商数据中至少可能存在商品上架时间、页面更新时间、价格生效时间、库存更新时间、抓取开始时间、抓取结束时间和入库时间。如果把这些字段都命名为update_time，后续趋势分析就会把不同事件混成一条时间线。
此外，还要确认时区。跨区域平台或云服务器常使用UTC时间，而研究团队按北京时间查看数据。如果没有统一存储标准，临近午夜的记录可能被划分到错误日期，造成日度趋势断点。
“颜色：黑色；容量：750ml；包装：单个”在页面上方便用户阅读，但不适合作为分析字段长期使用。将多个属性保存在一个文本字段中，会让颜色筛选、容量比较和SKU库存统计变得困难。
如果规格组合很多，可以采用属性明细表，也可以在结构稳定时拆成color、capacity、package_count等字段。关键不在于一定要拆成哪种形式，而在于团队需要提前确认后续是否会按这些属性进行筛选、聚合或匹配。
商品标题和详情文本经常包含HTML标签、实体字符、换行符、表情符号、制表符和引号。直接写入CSV或SQL时，可能出现字段错位、内容截断、乱码和插入失败。
处理文本时，至少需要确认字符编码、HTML清除范围、换行处理规则、JSON转义规则和数据库连接编码。对于商品详情，不建议把所有HTML标签简单删除后只保留纯文本，因为图片链接、列表结构和表格信息可能具有研究价值。
更合理的做法是保留raw_description作为原始字段，再生成clean_description用于检索和分析。原始字段负责追溯，清洗字段负责使用，两者不要相互覆盖。
价格、库存、评价数和排名都属于动态字段。若每次抓取都直接更新商品主表，当前状态是有了，但历史变化被抹掉；若每次都追加到同一张商品表，又容易让商品基础信息重复。
我更建议采用“主数据加历史快照”的方式：商品主表只保存当前可识别的基础信息，价格历史、库存历史和采集快照分别追加记录。这样既能快速查看当前状态，也能回放某个时间点的数据。
保留原始数据是好习惯，但“原始”不等于“可以直接分析”。页面原始文本适合追溯，不适合直接承担价格排序、销量聚合和跨平台匹配。
如果团队只保存原始HTML或原始JSON，却没有记录字段提取规则、抓取时间和解析状态，那么所谓“原始数据”仍然无法被有效复核。原始层应该配套元数据，而不是一个无人解释的文件堆。
标题相同可能代表同一商品，也可能是不同店铺的仿款、不同容量的商品或不同促销页面。标题不同也不一定代表不同商品，平台可能只是在标题前增加了“新品”或“官方正品”等营销词。
跨平台研究时，商品匹配应该至少结合品牌、规格、店铺、图片特征、条码或平台商品ID等信息。对于无法确认的匹配，不应强行合并，而应该保留match_status，标记为confirmed、probable或unresolved。
异常值有三类：真实但少见的业务值、解析错误产生的异常值、暂时无法确认的可疑值。把它们全部删除，会损失真实样本；把它们全部保留，又会污染主表。
更专业的做法是隔离而不是直接丢弃。正常数据进入标准表，可疑数据进入待审核表，采集失败进入任务异常表，原始内容进入原始层。这样既不影响主分析，又保留了后续纠错空间。
数据库允许保存字符串，并不代表这个字符串就是合适的数据类型。把价格、销量和库存都存成文本，短期内很灵活，长期却会让排序、聚合、索引和校验全部变得复杂。
入库成功只是技术层面的成功。业务层面的成功还需要满足：字段含义稳定、数据类型可预测、记录身份唯一、更新规则明确、异常可追踪。
这是成本最高的一种做法。抓取规模扩大后，错误会以乘法方式扩散：一个错误字段可能影响数十万行，一个错误唯一键可能让每个批次都产生重复数据，一个错误时间转换可能让所有历史记录跨天偏移。
我通常建议先做小样本验收，再做压力测试，最后才扩大采集范围。小样本不需要覆盖所有页面，但必须覆盖正常页面、缺失字段页面、促销页面、多规格页面、下架页面和加载异常页面。
很多清洗问题从一开始就错在对象定义。团队没有先确定“这一行代表什么”，就开始讨论价格应该用整数还是小数，最后即使字段类型统一，整张表的粒度仍然不清晰。
入库前应先回答：一行代表一个商品、一个SKU、一次抓取结果，还是一个商品在某个时间点的状态？不同答案对应不同主键和表结构。
| 如果一行代表 | 建议主键 | 价格和库存如何处理 | 适合的用途 |
|---|---|---|---|
| 商品主体 | 平台ID或跨平台商品ID | 保存当前聚合状态，不保存全部历史 | 商品目录、类目分析 |
| 具体SKU | 平台商品ID加规格ID | 按规格保存价格、库存和销量 | 规格比较、库存监控 |
| 一次抓取结果 | 任务ID加页面ID | 保存原始响应和解析状态 | 采集审计、失败排查 |
| 历史状态快照 | 对象ID加抓取时间或批次 | 每次抓取追加一条状态 | 趋势分析、历史回放 |
字段字典不需要一开始就做得很复杂，但必须能让不同成员对同一个字段形成相同理解。至少应包含字段名、中文含义、数据类型、单位、是否必填、允许空值、示例值、异常处理方式和来源位置。
例如，price字段不能只写“商品价格”，还应说明它是页面原价、活动价、券后价还是当前最低可购买价。若页面同时展示多个价格，就要拆分字段或增加price_type，而不是随机选择其中一个。
唯一键不是“数据库里随便生成一个自增ID”。自增ID只能标识这条存储记录，不能说明两条记录是否属于同一个商品。业务唯一键必须来自稳定的业务信息，或者由多个字段组合得到。
在跨平台数据中，我会将“平台来源”纳入键值范围。例如，platform_code加platform_product_id可以标识一个平台内的商品；如果要建立跨平台映射，还需要另建canonical_product_id，并保留映射置信度和人工审核状态。
字段标准化应该建立在对象和唯一键明确之后。否则，即使价格已经转成数字，后续仍可能因为商品身份错误而把不同SKU的价格合并在一起。
数值转换时，建议同时保留原始字段和解析状态。对于无法解析的内容，不要直接设为0；应该保留raw_value，写入parse_status，并将失败原因记录到异常表。
原始字段：price_raw
标准字段：price_value
货币字段：price_currency
价格类型：price_type
解析状态：parse_status
异常原因：parse_error
示例：
price_raw = "券后 29.9 元"
price_value = 29.9
price_currency = "CNY"
price_type = "coupon_price"
parse_status = "parsed"
parse_error = NULL
数据质量检查可以分为完整性、唯一性、合法性、一致性和及时性五类。不同项目的阈值不一样，但检查维度应该在正式抓取前确定。
检查结果最好生成质量报告，而不是只在程序日志里打印“成功”。报告至少应该显示记录总数、异常数量、重复数量、缺失数量、解析失败数量和与上一批次的变化。
下面的数据是情景模拟，用于展示清洗逻辑，不代表任何平台的真实统计。假设研究团队抓取了某类运动水杯的商品信息，原始结果如下：
| 商品名称 | 价格 | 销量 | 库存 | 抓取时间 | 链接 |
|---|---|---|---|---|---|
| 轻量运动水杯 750ml | 39.9 | 1.2万 | 有货 | 2026/09/13 | example.com/item/1001 |
| 轻量运动水杯750ml | 39.90元 | 12000 | 库存充足 | 2026-09-13 10:00:00 | example.com/item/1001?source=search |
| 轻量运动水杯 750ml 蓝色 | 券后29.9元 | 暂无 | ， | 13 Sep 2026 10:02 | example.com/item/1001?sku=blue |
| 轻量运动水杯 | 39.9 | 12000 | 0 | 2026-09-13T02:05:00Z | example.com/item/1001 |
这四行并不一定代表四个商品。第一行和第二行很可能是同一个商品的不同链接入口；第三行可能是同一商品下的具体SKU；第四行的时间可能是UTC时间，换算后才是北京时间当天上午。
如果直接导入数据库，至少会产生两类错误。第一类是技术错误，例如价格无法聚合、时间无法统一解析；第二类是研究错误，例如把券后价与原价放在同一序列，或者把库存未知误判为售罄。
更合理的结果可以拆成商品表、SKU表、价格快照表、库存快照表和采集任务表。示意字段如下：
| 表名 | 核心字段 | 保存内容 |
|---|---|---|
| product_master | canonical_product_id、platform_code、platform_product_id、title | 商品主体和稳定身份 |
| sku_master | sku_id、product_id、color、capacity、package_count | 具体规格及其属性 |
| price_snapshot | sku_id、price_value、price_type、currency、observed_at | 每次抓取观察到的价格 |
| inventory_snapshot | sku_id、inventory_value、inventory_status、observed_at | 库存数值或库存状态 |
| crawl_run | run_id、source_url、request_time、parse_status、error_message | 采集任务和解析过程 |
有人会认为既然已经有price_value，就没必要保留price_raw。实际项目中，原始值是判断解析规则是否正确的重要证据。
例如，某平台把“39.9元起”解析成39.9，如果后续发现它代表最低规格价格，团队还需要回看原始表达，确认是否应该增加price_scope字段。没有原始值，就只能重新发起抓取，甚至无法证明历史数据是如何产生的。
九数云这类数据分析与可视化工具，更适合连接经过定义和清洗的数据，用于制作价格趋势、商品分布、店铺对比和异常监控看板。它可以帮助团队更快发现“某天价格突然为0”“某类目商品数异常增长”等问题，但不应被当成唯一的数据清洗和数据建模层。
比较稳妥的链路是：采集原始数据，经过清洗和分层入库，再将标准数据同步到分析工具。这样看板发现异常时，团队可以回到清洗层和原始层排查，而不是在可视化界面里反复手工修改结果。
一次性研究不一定需要复杂的数据仓库，但必须保留原始文件、字段字典、采集时间、清洗脚本和异常记录。否则研究结论被质疑时，团队无法说明数据从哪里来、经过了什么处理。
这类项目可以采用原始表加标准结果表的两层结构。标准结果表用于分析，原始表用于复核；即使不建立完整的SKU关系，也应明确哪些记录被合并、哪些记录被排除。
持续监测项目的核心不是“当前值”，而是“当前值如何从上一时点变化”。价格、库存和排名等动态字段应采用追加快照或有效时间区间，而不是简单覆盖。
如果存储成本有限，可以只对变化字段追加记录，对没有变化的字段减少重复写入。但必须保留抓取批次和观测时间，否则无法区分“没有变化”和“没有成功抓取”。
跨平台项目最难的通常不是抓取字段，而是判断不同平台的商品是否可以比较。相同标题不代表相同商品，不同标题也不一定代表不同商品。
可以把匹配结果分为确认匹配、疑似匹配和未匹配三类。只有确认匹配的数据才直接进入严格对比，疑似匹配需要保留匹配依据，未匹配数据则不应为了提高覆盖率而强行合并。
多人协作时，存储混乱经常不是由程序造成，而是由不同成员对字段含义的理解不同造成。有人把price理解为原价，有人理解为到手价；有人把crawl_time写成页面时间，有人写成入库时间。
这类项目需要把字段字典和质量规则纳入协作流程。每次新增字段，都要写清来源、定义、类型、示例和变更影响；每次修改清洗逻辑，都要记录版本和适用批次。
大规模抓取不可能保证每个页面每次都完美返回。真正重要的是异常是否被单独记录，清洗脚本是否可以重复执行，修正规则后能否从原始层重新生成结果。
一旦原始数据被覆盖，后续就只能依赖人工猜测。保留原始层并不是浪费存储，而是用相对可控的存储成本换取重跑、审计和问题定位能力。
| 方案 | 优点 | 代价 | 适用场景 |
|---|---|---|---|
| 一张宽表 | 上手快，导出方便，初期查询简单 | 字段重复，粒度混乱，历史更新容易覆盖 | 小样本、短周期、字段稳定的临时研究 |
| 按对象分表 | 商品、SKU、价格和任务关系清晰 | 需要设计关联关系，查询时需要连接 | 长期监测、多规格商品、多人协作 |
| 原始层加业务层 | 可追溯、可重跑、适合持续迭代 | 需要更多存储和管理规范 | 规模化采集、研究资产沉淀 |
我不建议把“分表”当成绝对正确答案。对于只有几百条记录的一次性调研，过度设计会增加维护成本；但对于每天持续抓取的项目，长期依赖一张大表通常会在第二或第三个周期暴露问题。
自动清洗适合处理规则明确、重复出现的格式问题，例如去除货币符号、统一时间格式、规范化链接参数。人工审核适合处理语义不确定的问题，例如两个标题相似的商品是否属于同一SKU。
不要把所有问题都交给人工，也不要为了自动化而强行自动合并。可以设置置信度阈值：高置信度记录自动处理，中间区域进入抽样审核，低置信度记录保留原样并标记为未确认。
只保留标准化数值，分析方便但丢失了原始表达；只保留原文，追溯完整但难以计算。更稳妥的做法是两者并存：标准字段用于分析，原始字段用于核对。
对于价格，还应记录价格类型。原价、活动价、券后价和会员价不能放在一个price_value里互相覆盖。如果研究目标是消费者实际支付成本，就应明确选择到手价；如果研究目标是平台标价变化，则应使用原价或页面主展示价。
清洗越严格，进入分析层的数据可能越少；清洗越宽松，覆盖率看起来越高，但异常值会增加。二者没有绝对的优劣，取决于研究问题。
如果研究的是价格趋势，宁可减少无法确认口径的记录，也不要把不同价格类型混在一起。如果研究的是商品覆盖范围，可以保留更多不完整记录，但必须通过字段状态告诉使用者哪些信息缺失。
Excel、CSV和脚本足以支撑小规模任务，但它们对版本、权限、并发修改和质量审计的支持有限。数据库或数据仓库更适合长期项目，但会带来建模、权限、备份和运维成本。
一个实用的判断方法是看三个问题：是否需要持续追加历史数据？是否有多人同时使用？是否需要重跑和追溯？只要其中两个答案为“是”，就不建议长期依赖一份人工维护的大表。
不要先改代码。先拿出当前表格，随机抽取二十行，逐行写下“这一行究竟代表一个什么对象”。如果同一张表中出现商品、SKU、页面和抓取任务四种答案，就说明需要重新设计粒度。
把所有字段列出来，补齐中文含义、类型、单位、来源、是否必填和异常处理方式。对于团队争议最大的字段，例如价格、销量和库存，单独开会确认业务口径。
选择一百条包含重复链接、不同标题、多规格和不同店铺的样本，测试平台商品ID、SKU ID、规范化链接和组合字段的去重效果。不要直接拿标题去重后就宣布成功。
原始数据只负责保存事实，不要在原始层覆盖字段。清洗层负责标准化、拆分字段和标记异常。两层之间至少记录批次ID、处理时间和规则版本。
为解析失败、缺少ID、无法匹配、字段缺失和页面异常分别建立状态或分类。异常表不一定要复杂，但必须能够回答“这条记录为什么没有进入分析层”。
重新处理正常页面、促销页面、多规格页面、下架页面、字段为空页面和编码异常页面。每次修改清洗逻辑，都要确认旧样本的结果没有被意外改变。
当小样本质量报告能够稳定输出后，再扩大采集范围。扩大后不要只看总记录数，还要观察重复率、字段缺失率、解析失败率、异常类型分布和批次间变化。
电商数据抓取项目中，真正值得警惕的不是某几行脏数据，而是团队逐渐失去回答三个问题的能力：这个数字从哪里来？它代表什么？为什么和上一批不一样？一旦这三个问题无法回答，数据即使被保存多年，也很难称为可复用的数据资产。
我对研究团队新手的建议是，不要把第一目标设成“抓更多”。先用小样本把商品身份、SKU粒度、价格类型、时间语义和异常状态定义清楚，再决定使用单表、分表还是分层存储。
如果只是一次性调研，保留原始数据和清洗记录就已经能显著降低返工风险；如果需要持续监测，就必须加入历史快照、批次管理和异常隔离；如果需要跨平台比较，则要把商品匹配置信度视为核心字段，而不是隐藏在某个成员的判断里。
数据清洗最重要的结果，不是把所有空值填满，也不是把所有记录都变成“正常”；而是让正常、未知、失败、下架、未公开和无法匹配这些状态被准确区分。下一步可以从当前项目中抽取一百条边界样本，完成字段字典、唯一键测试和入库前质量报告。只有这三件事跑通后，扩大抓取规模才不会把局部错误放大成系统性混乱。
我刚开始做商品抓取时，以为用商品标题去重就够了，结果同一个商品因为颜色、促销文案和链接参数不同，被保存成了好几条记录。后来统计商品数量时，明明只抓了几百个商品，数据库里却多出了一倍，我想知道这种重复到底应该怎么判断和处理？
同一商品被保存成多条记录，通常不是简单的“重复抓取”，而是团队没有先定义商品身份。电商数据里至少存在商品、SKU、店铺商品和抓取记录四种不同粒度，如果把它们都当成“商品”处理，数据库很快就会出现身份混乱。
我在一次脱敏项目复盘中看到过类似情况：同一款商品的原始记录有三条，标题分别是“无线降噪耳机”“无线降噪耳机-黑色”和“无线降噪耳机限时优惠”，链接也因为推广参数不同而发生变化。表面看是三件商品，实际对应的是同一个SPU下的两个SKU和一次不同批次的抓取。
判断字段可靠性常见问题 商品标题低促销词、颜色、标题改版都会导致变化 规范化链接中去除参数后仍可能存在短链或重定向 平台商品ID高跨店铺时需要同时保留店铺ID SKU或规格ID高适合判断颜色、尺码、容量等具体库存单元 我的判断是，标题只能用来辅助匹配，不能承担唯一键的职责。
更稳妥的优先级是“店铺ID+平台商品ID”识别SPU，再用“商品ID+SKU ID”识别具体SKU，最后单独增加抓取批次和抓取时间，保存每次观察结果。
如果暂时拿不到稳定的平台ID，可以先对链接做规范化：删除无业务意义的推广参数、统一协议和域名大小写、处理尾部斜杠，再结合品牌、标题、规格和店铺信息做人工抽样核验。但这只是过渡方案，不建议直接把标题哈希当成永久唯一键。入库时最好不要直接执行“发现重复就删除”。
建议保留原始表，并在清洗表增加duplicate_flag、match_method和review_status等字段。这样团队以后发现误合并时，还能追溯当时为什么把两条记录判定为同一商品。最实用的检查方式是随机抽取100条去重结果，人工核对商品ID、规格和链接。
若误合并率超过可接受范围，应优先调整身份规则，而不是继续堆叠更多模糊匹配条件。商品数量统计、竞品对比和增量抓取，最终都取决于这一步是否稳定。
我发现不同页面抓回来的价格有“39.9”“39.90元”和“券后29.9元”三种写法，销量还有“1.2万+”“12000”和“暂无”。如果直接存进数据库，后面排序和求平均值都会报错，我不确定哪些值应该清洗成数字，哪些值应该保留原文。
数字字段最容易制造一种假象：数据看起来都已经抓到了，但数据库实际上无法正确计算。价格、销量、评论数和库存如果同时混入数字、文本、单位和营销文案，查询层往往只能按字符串处理，结果会出现排序错误、聚合失败和异常值被误当成真实业务数据。
例如，字符串排序可能把“100”排在“39.9”前面，因为数据库比较的是字符而不是数值；“1.2万+”如果没有转换，无法和“12000”进行统一统计；而“券后29.9元”到底是原价、活动价还是用户实际支付价，也不能仅靠删除汉字解决。
原始值建议标准值额外保留字段 39.90元39.90price_raw：39.90元 1.2万+12000或12000以上标记sales_raw、sales_is_lower_bound 暂无NULLvalue_status：not_observed 无库存0或NULL，取决于页面语义stock_status：out_of_stock 这里最容易踩的坑是把“没有看到”直接清洗成0。
销量为0、页面未展示销量、接口请求失败和商品不适用，业务含义完全不同。如果全部写成0，后续团队会误以为这些商品确实没有销量，研究结论也会被悄悄改变。我更推荐“双字段”策略：一个字段保存可计算的标准值，另一个字段保存原始文本或状态。例如price_numeric用于统计，price_raw用于复核；
sales_numeric用于排序，sales_qualifier用于记录“约”“以上”或“万”等语义。这样既不会污染分析字段，也不会丢掉页面原貌。清洗顺序也很重要。先判断字段语义，再去除货币符号、千位分隔符和单位，最后转换类型并做范围校验。
不要先用正则表达式“抓出所有数字”，否则“满100减20”“评价4.9分”和“库存仅剩2件”都可能被错误写入价格、评分或库存字段。入库前至少做四项检查：字段类型是否统一、数值是否落在合理范围、原始值是否可追溯、异常记录是否单独标记。
对研究团队而言，保留一小批原始样本并逐字段比对，通常比一开始编写复杂的自动清洗规则更能减少返工。
我们现在的表里只有一个时间字段，开发同事有时写入页面更新时间，有时写入程序抓取时间，价格变化后也直接覆盖旧值。后来我发现同一天的记录无法判断到底是什么时候采集的，更不知道价格变化是真实发生，还是时区和字段含义混用了，该怎么设计才合理？
时间混乱比格式混乱更危险，因为日期格式即使看起来统一，字段含义也可能完全不同。商品上架时间、页面更新时间、价格生效时间、抓取时间和入库时间，分别回答不同问题，不能因为都叫“时间”就共用一个字段。在一次历史价格排查中，团队发现同一商品上午和下午的价格记录完全相同，但晚上却突然出现大幅波动。
进一步检查后才发现，上午记录使用的是接口返回的商品更新时间，下午记录使用的是本地抓取时间，晚上记录又转换成了UTC时间。图表上的“价格变化”其实混合了三种时间口径。
字段回答的问题是否适合替代抓取时间 published_at商品何时发布不适合 source_updated_at页面或平台何时更新不适合 observed_at研究团队何时看到该状态核心字段 ingested_at数据何时写入数据库用于排查延迟 我的建议是至少保留observed_at和ingested_at，并明确统一时区。
做价格、库存和销量研究时，应以observed_at作为观察时间；排查采集延迟、消息队列积压或批量导入问题时，再使用ingested_at。时间字段不能只统一展示格式，还要统一存储标准。团队可以约定数据库内部使用带时区的标准时间，前端展示时再转换为研究人员所在地区的本地时间。
否则一个团队按北京时间分析，另一个团队按UTC切分日期，最终会得到不同的日销量和价格曲线。动态字段也不建议简单覆盖。商品名称、品牌等相对稳定的信息可以放入商品主表；价格、库存和销量则应进入带观察时间的历史表。
这样同一商品每天有多条观察记录并不算重复，真正需要去重的是“同一商品、同一SKU、同一观察时间、同一数据来源”的重复写入。判断时间设计是否合格，可以做一个简单回放测试：任选一件商品，按时间顺序重建它的价格和库存变化。
如果无法回答“这个值是在什么时候被观察到的”，或者同一批数据按不同程序运行会产生不同日期，说明当前时间模型还不能用于研究分析。
我们之前为了省事，把原始响应、清洗后的商品字段和分析结果全放在一张宽表里。刚开始查询很方便，但后来一旦发现清洗规则错了，就无法恢复原始值，字段也没人能说清楚，我想知道新手团队最低限度应该怎样分层？
很多团队把“建一张能查询的表”误认为“完成了数据存储设计”。真正的问题通常在于，原始事实、清洗判断和业务结论被写进了同一张表。一旦规则调整，团队既无法重新清洗，也无法判断某个字段是页面原值、程序推断值还是分析人员改过的结果。我在项目排错时最看重的一点，是能否从业务表反查到原始记录。
如果一条价格异常只能看到“29.9”，却不知道页面原文是“券后29.9元”、接口返回的是29.90，还是人工修正后的结果，那么这条数据即使暂时可用，也不具备研究可信度。
数据层主要内容是否直接供分析使用 原始层页面响应、接口JSON、原始文本、抓取状态通常不直接使用 清洗层字段拆分、类型转换、异常标记、匹配结果用于复核和加工 业务层商品主表、SKU表、价格历史、库存历史是 质量层失败记录、重复记录、规则版本、检查结果用于监控和追溯 原始层的价值不是“以后可能用到”，而是给清洗规则提供可回放的输入。
建议至少保留来源URL、抓取批次、响应时间、原始内容摘要和采集状态。对于体积较大的响应，可以保存对象存储地址和校验值，不一定全部塞进业务数据库。清洗层不要只保存最终结果，还要保存处理痕迹。例如某条记录为什么被判定为重复、价格是如何从文本转换成数字、销量为何被标记为下界值。
规则版本也应该记录下来，因为同一批原始数据在不同规则版本下可能得到不同结果。业务层则要按数据粒度拆开：商品主表保存相对稳定的信息，SKU表保存规格和库存单元，价格历史表保存每次观察到的价格，抓取任务表保存批次和状态。这样价格更新不会覆盖商品基本信息，SKU变化也不会把整个商品记录复制一遍。
新手团队不必一开始就建设复杂的数据平台，但至少要做到“三不”：不让异常值直接污染主表，不让清洗后数据覆盖唯一的原始数据，不让不同含义的时间和身份字段共用一个列。再加上入库前的小样本验收，通常就能避免最昂贵的返工。我的最低检查标准是：抽取一批原始记录，经过清洗后能够解释每个字段的来源；
删除或修改一条业务记录时，能够找到对应的原始批次；重新运行清洗规则时，结果能够复现。满足这三点，研究团队才真正拥有可维护的数据，而不只是暂时能打开的一张表。
读者评论
文章把“抓取成功”和“数据可用”区分开来，这一点很实用。尤其是空值、0值和解析失败不能混为一谈，否则销量和库存分析很容易产生误判。
商品、SPU、SKU分层存储的建议比较清晰。实际项目中如果只用标题或完整链接去重，确实容易因规格变化、推广参数导致重复记录。
时间字段拆分和保留原始数据很重要。不过文中的示例比例属于情景模拟，实际团队仍需结合平台规则和抽样核验结果评估数据质量。