旺季前，BI 看板最危险的状态，不是“连不上数据”，而是“看起来还在更新，实际上已经延迟、漏数或改变了口径”。我做旺季准备时，会把验收问题从“数据源是否连通”改成“关键业务决策能否在约定时间内拿到可信数据”。这份清单围绕数据盘点、接入稳定性、质量校验、负载演练和故障响应展开；文中的数字案例均为情景模拟，不代表任何平台或客户的实测结果。
BI 平台落地进入旺季准备阶段，我建议先把范围收敛到三个问题：关键数据能不能按时到、到达的数据是不是可信、链路失败后能不能及时发现并恢复。只验证“测试账号可以连接数据库”，只能证明链路在某个时间点具备连通条件，不能证明高峰期间的刷新结果能支撑经营决策。
旺季可能是电商大促、月末关账、招生报名、集中营销或线下活动。它们的共同点不是数据量一定翻倍，而是关键数据的时效、完整性和稳定性突然变得更重要。对某些团队来说，库存看板延迟十分钟就有影响；对另一些团队，日报次日上午更新也足够。验收标准必须从业务用途推出来，而不是从工具默认刷新频率推出来。
我会将检查拆成五类：数据源与任务盘点、账号权限和结构变更、数据质量与指标口径、高峰负载和调度演练、监控告警与故障处置。每类检查都要有负责人、完成时间和证据。没有证据的“已确认”，在跨团队交接时很容易变成“我以为对方检查过”。
这套思路的关键不是增加检查项目，而是给每个项目补上验收条件。比如“检查刷新任务”太模糊；“连续三次按约定窗口完成刷新，关键字段校验通过，业务负责人确认差异在可接受范围内”，才是一项可以关闭的工作。
数据源清单不应只有系统名称和连接地址。实际排查时，我更关心它被谁使用、多久更新一次、出问题会影响哪些决策。建议至少记录数据源、接入方式、刷新周期、关键字段、下游报表、业务重要级别、技术负责人、业务确认人和外部依赖。
例如，“订单库”不是足够具体的登记项。应继续拆成订单主表、支付记录、退款记录等数据对象，并记录它们是否通过同一同步任务进入分析层。如果订单主表更新正常、退款记录延迟，销售额或净成交额就可能出现不同步。只看一个“订单数据源状态”，很难发现这种局部失效。
盘点时，把链路画成“源系统，抽取或同步任务，存储层，模型或数据集，关键看板”。不必一开始就追求完整的数据血缘平台；一张经过负责人确认的表格，也比散落在聊天记录里的口头约定更可用。重点是标出关键节点和依赖，而不是画出一张没人维护的复杂架构图。
我通常建议使用三级优先级。一级链路支撑经营决策或资金、库存等高影响事项；二级链路影响日常分析，但有人工替代或延后空间；三级链路主要用于探索分析，短时中断不会改变关键行动。分级不是永久标签，业务负责人、旺季时段和替代方案变化时都应重新确认。
容易被忽视的情况是：数据源不大，业务影响却很高。一个每天只产生几百条记录的退款明细，可能直接影响净收入；一份每天导入一次的促销排期表，可能决定旺季活动归因。数据量不能代替业务优先级。
如果数据依赖第三方 API、供应商文件、人工上传、VPN、定时导出或某个同事的个人账号，这些都属于数据接入链路。它们往往不是技术架构图上的“系统”，却是旺季最容易发生单点中断的地方。
对人工环节，我会具体记录文件格式、命名规则、上传截止时间、缺失时的联系人和补交方式。对外部接口，则记录服务方限流、维护窗口、密钥到期时间和变更通知渠道。不能确认的事项应标为待核实，而不是用“接口稳定”一笔带过。
| 台账字段 | 记录示例 | 为什么要记录 |
|---|---|---|
| 数据对象与来源 | 退款明细；交易系统 | 避免把一个系统名称当成完整的数据范围 |
| 更新与时效要求 | 每小时同步；午间前可用于经营复盘 | 把业务要求和技术调度连接起来 |
| 下游影响 | 净销售额看板、退款分析 | 判断故障影响等级和通知对象 |
| 负责人及替代方案 | 数据工程师；源系统导出文件待确认 | 避免故障发生后才寻找责任人 |
旺季前的权限检查，不是简单问“账号还能不能登录”。还要核对账号是否属于组织可管理的主体、权限是否仅覆盖所需对象、凭证是否会在关键时段过期，以及人员变动后是否存在无人维护的连接。若使用个人账号连接，人员休假、岗位调整或身份验证变化都可能造成中断。
我不建议为了赶上线而长期授予超范围权限。更稳妥的做法是按组织安全规范确认最小必要权限，并安排一次真实刷新验证。验证记录中写明使用的账号类型、可访问对象、验证时间和结果。密码、令牌等敏感凭证不要放入公开台账或文章示例中。
字段新增、删除、改名、类型变化和枚举值变化，都可能让原有报表出现空值、重复分类或计算错误。问题不一定表现为任务失败：有时同步仍然成功，只是字段映射失效，或新的状态值没有纳入业务逻辑。
对关键数据源，旺季前应确认近期是否有接口版本切换、表结构升级、字段语义调整或数据迁移计划。若源系统没有正式变更通知机制，至少要约定联系人和变更冻结窗口。对不能冻结的系统，安排变更后校验，并明确由谁确认下游报表。
“任务失败后会重试”还不足以证明恢复可靠。需要确认重试间隔、最大次数、重复执行是否可能写入重复记录、失败后如何补数，以及补数完成后怎样避免下游只刷新部分数据。不同平台和接入方式能力不同，应以当前产品文档、配置和实际演练为准，不要假设所有连接器都支持相同机制。
对增量同步，尤其要查清增量标记字段、更新时间精度、迟到数据处理和删除记录的识别方式。若源系统允许补录历史数据，只依赖“最后更新时间”而没有回补策略，数据可能长期漏掉。对全量覆盖方式，则要确认数据规模、执行窗口和失败时旧数据是否仍可用。
条件允许时，可以在测试环境或经批准的窗口内模拟凭证失效、接口暂时不可达、字段缺失等情况，观察任务是否产生可识别的失败状态、告警是否到达责任人、恢复后数据是否补齐。测试要限定影响范围，避免在生产环境随意制造故障。
演练结果不应只写“测试通过”。建议记录故障注入时间、发现时间、通知时间、恢复时间、缺失数据范围、补数结果和遗留问题。这样能识别“系统恢复了，但数据没有补齐”这类容易被忽略的情况。
质量校验不需要给所有字段套同一组阈值。关键是为高影响字段设置可解释的规则，例如订单号是否为空、业务主键是否重复、日期是否落在合理范围、状态值是否属于已知集合、金额字段是否出现异常突变。每条规则都应有负责人确认，避免把业务上正常的波动误报成故障。
记录数对比是一个实用起点，但不能单独作为质量结论。源系统与分析层的记录数可能因软删除、过滤条件、时区边界、迟到数据或同步窗口不同而不一致。做对账时应先统一时间范围、过滤条件和数据粒度，再解释差异。
“销售额”是否包含退款、“订单量”是否排除测试单、“新增客户”按注册时间还是首购时间计算，都是指标口径问题，不是接入工具能替业务自动决定的问题。旺季前应选出会影响关键行动的指标，逐项记录定义、过滤条件、统计时区、数据更新时间和口径确认人。
还要说明迟到数据、撤销订单、退款、补录和跨日交易如何处理。若业务负责人只确认了指标名称，没有确认边界条件，旺季期间报表数值出现差异时，团队很难分辨是技术故障、口径不同还是业务事件变化。
单看图表是否有数值，很难发现错误。建议挑选关键日期、关键业务对象和高影响指标，与源系统或已有可信报表做抽样核对。抽样范围应覆盖正常时段和特殊场景，例如退款、取消、跨日、补录或状态变更。
每次对账至少留下四项信息：抽样对象和时间范围、源端查询条件、BI 结果、差异解释及确认人。如果差异无法解释，不要先用“系统口径不同”关闭问题。先确认字段映射、过滤逻辑、同步窗口和业务定义，再决定是否属于可接受差异。
对九数云等 BI 平台的评估，也应把“平台是否支持目标数据源”和“该数据源能否按业务要求稳定更新”分开核实。连接器清单、刷新方式、权限要求及具体限制，应查阅对应产品的最新说明并在自身环境验证；产品名称本身不是验收结论。
准备时间有限时，我会优先检查三个层级：第一，可能影响核心指标的字段和规则；第二，可能造成整条链路漏数或延迟的任务；第三，历史上曾出现过问题的数据对象。非关键分析表可以采用较轻的抽查，而不是让所有资源平均分配测试时间。
| 校验对象 | 适用检查 | 不应直接得出的结论 |
|---|---|---|
| 主键与业务编号 | 空值、重复值、格式变化 | 重复记录一定是系统错误，需先排除业务拆分或多明细情况 |
| 金额与数量 | 范围检查、分布变化、与源端抽样对账 | 波动越大越异常，促销或业务事件可能造成真实变化 |
| 状态与分类 | 未知枚举、空值、映射覆盖 | 出现新状态就应删除，需由业务确认处理逻辑 |
| 更新时间 | 数据新鲜度、迟到数据和跨日边界 | 更新时间最新就代表数据完整 |
旺季负载评估先看现有任务运行记录和业务日历。哪些任务同时在整点启动，哪些看板会在开门前或经营会议前集中查看，哪些上游系统在活动开始后才产生大量记录，都可能形成局部高峰。把全日平均负载当成峰值，会掩盖短时间内的调度竞争。
测试前应记录当前任务耗时、刷新窗口、失败情况、数据规模和关键看板的实际时效要求。若没有历史记录，就先补采样，并明确数据代表的时段。不能把一次小样本测试直接外推到正式旺季，也不能拿未经验证的并发量作为平台能力承诺。
我倾向于先做低风险的计划核对，再做测试环境压测，最后才考虑经批准的生产演练。检查顺序可以是：确认任务是否有时间冲突；确认数据量和刷新窗口；使用代表性数据做负载测试；检查任务堆积和失败恢复；最后由业务确认时效是否满足用途。
演练要明确停止条件。比如关键任务延迟超过业务约定、源系统出现明显性能影响、测试数据无法隔离或告警没有到达负责人，就应暂停并处理问题。测试结果还要标记环境、数据量、并发设置、运行时段和限制，避免被转述成脱离条件的“系统支持某个固定吞吐量”。
不是每张看板都需要实时刷新。经营决策看板可能需要分钟级或小时级更新，财务分析可能更重视口径稳定和日终完整，探索性分析则可以接受更长延迟。统一把全部数据设为高频刷新，可能增加源系统压力、任务竞争和排查难度，却未必增加业务价值。
建议把时效要求写成业务语言：例如“开店前看到前一日完整数据”“活动期间每小时更新一次库存风险”“日终后确认退款口径”。然后再由技术团队评估同步频率、资源安排和平台限制。技术方案应服务于这个约定，而不是让业务适应某个默认刷新周期。
任务状态显示“成功”，并不一定意味着看板数据足够新。任务可能处理了不完整的时间窗口，也可能在上游数据尚未落地时按时完成。建议至少关注任务成功状态、运行时长、数据最后更新时间、关键记录量和质量规则结果，并为核心链路设置明确的业务可接受延迟。
监控规则需要结合链路特征。例如，某些数据源周末本来不产生记录，简单设置“记录数必须大于零”会造成误报；某些任务即使成功，只要更新时间停留在前一天，就可能已经影响当日经营判断。先理解数据行为，再设告警条件。
只有“任务失败”四个字的告警，通常会增加沟通成本。告警最好包含任务名称、数据对象、失败时间、影响报表、错误摘要、最近成功时间、责任人和排查入口。若告警会暴露敏感信息，应遵照内部安全规范处理，不要把密钥、完整连接串或个人数据直接塞入消息。
还要检查通知链路本身：责任人是否仍在岗、通知渠道是否会静音、升级对象是否明确、非工作时段是否有人响应。上线前可以安排一次低风险告警演练，确认告警不仅生成，而且真正到达处理人。
故障分级不要只按技术报错数量决定。关键经营看板无法更新、数据口径疑似错误、非关键任务延迟和单个探索性报表失败，影响等级不同。分级时至少考虑影响范围、业务时效、是否有替代数据、是否会导致错误决策。
可将处置动作写成简明流程：确认影响范围；通知业务负责人；暂停可能产生错误结果的发布或标注数据时间；检查上游和任务状态；执行恢复或补数；完成质量复核；向业务确认恢复。若没有经过验证的替代数据，不要把“切备用源”写成默认方案。
降级不是简单关闭看板。对不同业务，可以选择明确标注数据更新时间、暂停关键指标发布、暂时使用已确认的人工报表，或延后非关键任务以释放资源。每一种方式都需要业务方确认影响和有效期限。
恢复判据也要提前定义。任务状态恢复只是技术条件之一；还应确认缺失时间范围已补齐、关键指标通过质量校验、下游看板已刷新，并由指定业务负责人确认。没有最后的业务确认，技术团队可能误以为修复完成，业务团队却仍在使用旧数据。
下面用一个情景模拟说明检查逻辑，不代表真实客户案例。某零售团队准备促销活动，销售看板依赖订单明细、支付记录、退款记录和商品信息。平时这些任务可以按计划刷新，但促销期间业务团队希望更频繁查看销售表现。
初步检查发现，订单明细连接正常，任务也显示成功；支付记录的更新较晚，退款文件由人工上传，商品信息则计划在活动前调整字段。若只做“所有数据源能否连接”的检查，团队可能会得出准备完成的结论。但这四条链路分别存在时效、人工依赖和结构变更风险。
如果订单和支付链路已通过时效与质量检查，商品字段变更也有回归验证，退款数据延迟有明确标注和业务处理约定，那么团队可以按已确认的范围上线。若退款数据没有可靠来源，却仍把净销售额作为核心决策指标，就不应把问题包装成“刷新频率稍慢”；这是业务口径和决策风险问题。
当风险无法在旺季前消除，应采取透明的范围控制：暂时隐藏不可信指标、降低看板用途、使用经过确认的替代口径，或推迟相关决策。我的判断是，清楚地告诉业务“这项数据目前不能用于什么决策”，比继续展示一个看似完整的数字更负责任。
新上线的 BI 平台往往最缺的不是功能，而是运行基线。先记录每条关键任务的正常耗时、更新时间、错误表现和业务负责人，再决定告警阈值。没有基线时，团队很难判断一次耗时增长是正常波动还是实际风险。
同时把平台配置、数据源授权、任务维护和业务口径确认的责任拆开。项目交付团队可能负责初始配置，但旺季期间谁负责运行、谁能批准变更、谁确认报表结果，必须有明确安排。交接文档要写到具体任务和联系人，而不是只写部门名称。
已经稳定运行的项目，旺季前不必无差别重做所有测试。优先查最近的源系统变更、账号和凭证到期、任务运行时间趋势、历史失败任务、业务日历变化及高峰期间新增报表。这样能把有限时间用在“发生变化的部分”和“曾经出过问题的部分”。
但“过去稳定”不能当作豁免理由。若业务刷新频率提高、数据量显著变化、源系统迁移或新增依赖，旧的运行经验就不再足以支持新场景，需要补做针对性验证。
当数据源数量多、旺季窗口又短，先按业务影响排优先级：关键决策链路做完整校验，次关键链路做抽样和告警确认，低优先级链路明确可接受延迟和人工替代方式。不要为了“所有项都打勾”牺牲关键链路的验证质量。
对于不能及时完成的项目，明确记录风险、影响、临时措施、负责人和复查时间。清单的作用不是制造“全部通过”的表面结果，而是帮助团队知道哪些风险已关闭、哪些仍需业务接受。
当业务要求“越实时越好”，先追问数据更新会改变什么决策、需要多快响应、能否接受延迟提示。若数据源本身每小时才产生一次可靠数据，把 BI 刷新设置为每分钟，通常不会创造真实实时性，反而可能增加无效请求和资源竞争。
如果确实存在分钟级决策需求，就应把源系统产数节奏、接入方式、平台能力、任务调度和业务响应流程作为完整链路评估。局部加快某个环节，不代表端到端时效会等比例改善。
| 项目状态 | 优先行动 | 主要取舍 |
|---|---|---|
| 刚上线 | 建立运行基线、责任表和告警演练 | 先追求可观测、可交接，不急于优化所有性能 |
| 长期稳定 | 检查变更、异常历史和旺季新增需求 | 减少重复测试，但不沿用已失效的旧假设 |
| 资源紧张 | 优先保障一级链路并记录剩余风险 | 接受非关键报表延迟，不模糊核心数据风险 |
| 高时效需求 | 验证端到端数据产生与消费路径 | 在刷新速度、源系统压力和准确性之间权衡 |
若关键指标口径未确认、主要数据源权限即将失效、关键任务没有责任人、故障后无法补数、数据更新时间无法判断，这些问题不适合带入旺季。它们可能造成错误经营判断，或让团队在出现故障后无法定位影响范围。
尤其需要谨慎处理“数据有数但不可信”的状态。空白报表容易引起关注，错误数字却可能被当成事实使用。对于没有完成质量验证的关键指标，明确标注限制或暂时停止展示，往往比维持表面完整更安全。
对不影响旺季关键判断的视觉样式优化、低优先级探索报表、非关键数据源的深度性能优化，可以在风险评估后延期。延期不是忽略，而是写清楚为什么延期、影响范围、临时处理方式和复查日期。
需要避免另一种极端：为了赶工把所有非功能性优化都砍掉，却没有保留必要的监控、质量校验和恢复验证。真正可以延期的是体验增强或低影响优化，不是基本的安全、可观测性和业务验收。
一个实用的判断方法是同时评估三个维度：发生概率、业务影响、可恢复性。概率不容易精确时，不必编造精确分数，可以用高、中、低描述，并写明依据。比如“近期有源系统升级但没有变更通知”比“感觉可能有风险”更有决策价值。
随后评估补救成本和替代方案。若修复需要跨团队排期，但业务影响有限且有经确认的替代数据，可以安排延期；若没有替代方案、影响关键经营数据，即使修复成本较高，也应优先投入资源。取舍应留下业务负责人确认记录，而不是由技术团队独自承担业务风险。
下表可直接复制到团队台账。不要只填写“完成”，最好附上任务日志、测试记录、对账结果、告警截图或业务确认时间。敏感信息应放在受控系统内，公开台账只保留可追踪的引用位置。
| 检查事项 | 建议验收标准 | 负责人 | 证据记录 |
|---|---|---|---|
| 关键数据源盘点 | 源、接入方式、刷新周期、下游影响及联系人已确认 | 数据负责人 | 台账版本与确认日期 |
| 账号和权限复核 | 凭证有效期、权限范围和维护人已核实 | 平台或安全负责人 | 授权记录，不记录敏感凭证 |
| 接口与字段变更检查 | 旺季窗口内的变更计划已确认，关键字段有回归检查 | 源系统负责人 | 变更单或确认记录 |
| 数据质量与口径对账 | 关键指标、时间范围、差异解释和业务确认人明确 | 数据分析与业务负责人 | 抽样对账结果 |
| 负载和任务调度演练 | 测试条件记录完整，关键任务满足业务约定时效 | 数据工程负责人 | 测试环境、数据量和日志 |
| 告警与响应演练 | 告警到达责任人，升级路径及恢复判据明确 | 运维负责人 | 演练时间线与遗留问题 |
| 降级和补数方案 | 替代方式经业务确认，补数后有质量复核步骤 | 业务与技术共同确认 | 方案版本与批准记录 |
建议至少区分“未开始、处理中、已验证、带风险上线、已延期”。“已验证”表示证据齐全并通过约定标准；“带风险上线”表示风险尚未消除，但影响和临时措施已由业务负责人接受；“已延期”则需要明确后续期限。这样能避免把尚未验证的事项误报为完成。
关键风险可以标注责任人、决策人和下次更新时间。技术团队负责说明风险事实与处理选项，业务负责人确认风险对决策的影响。若影响范围变化，例如新增看板或调整刷新频率，应重新评估状态。
旺季前最后一次复核，不必逐行朗读清单。集中讨论一级链路的未关闭问题、关键指标的口径争议、未验证的替代方案，以及故障时的联系人和升级方式。会议结束时应留下明确决定：哪些事项已通过、哪些带风险上线、哪些功能暂停使用、谁在何时复查。
如果团队无法说明关键看板的数据更新时间、异常联系人和恢复判据，就不应仅凭任务状态判定准备完成。清单的价值在于让团队知道系统边界，而不是让表格看起来整齐。
我认为，BI 数据接入的旺季准备完成，不是所有任务都没有报错，也不是所有报表都能最快刷新。更可靠的标准是：关键链路有人负责，业务时效有约定，关键指标经过校验，异常能被发现，数据能按规则恢复，业务知道在什么情况下不应依赖某个数字。
如果一条非关键链路偶尔延迟，但业务可接受、看板能显示更新时间、补数流程明确，它可能不是旺季上线的阻断项。反过来，一条任务每天都显示成功，却没有口径确认、质量检查和数据新鲜度监控，就不能因为“平时没出事”而视为安全。
旺季准备真正要减少的，不只是任务失败次数，而是“数据已经不可靠，团队却还不知道”的时间。把连接成功变成业务可用，把任务成功变成结果可验证，把故障恢复变成业务确认，这才是 BI 平台落地清单中最值得优先投入的部分。
我负责过业务高峰前的报表准备，最纠结的不是要不要提前，而是提前多久才不会把时间浪费在反复确认上。我想知道，哪些工作必须提早做，哪些可以临近旺季再检查？
不要只按一个固定日期倒推，先找出关键报表依赖的最长链路：数据源审批、账号开通、接口改造、历史数据回补和业务对账都要算进去。建议至少预留一个完整的验证与整改周期；如果涉及新系统、第三方接口或跨部门审批，就应更早启动。可以按风险分层：核心经营看板和外部接口优先盘点、演练；低频且不影响决策的报表可以后排。
每项任务记录负责人、截止时间、验收证据和未完成时的替代方案。若高风险链路在旺季前仍没有完成端到端验证，应先缩小上线范围，而不是把“已连通”当作准备完成。
我以前会把连接测试通过理解为数据接入完成，但报表上线后才发现更新时间和业务统计口径对不上。我想知道，怎样用一组有限的检查尽早发现这类问题？
连接成功只证明数据能够传输，不代表字段含义、记录范围和业务计算正确。检查时先对齐三个时间：源系统产生时间、数据进入平台的时间、报表展示时间；再抽取关键指标与源系统或已确认的业务报表对账。例如，订单量出现差异时，不要只看总数，还要检查退款、取消、跨日订单和迟到数据是否采用相同规则。
可以为关键表设置空值、重复记录、记录数突变和更新时间检查，并记录抽样范围、差异原因及业务确认人。阈值应结合历史波动和业务容忍度设定，不要直接套用所谓通用标准。
我担心平时运行正常的同步任务，在业务高峰时会因为数据量增加或任务集中启动而积压。可我又不想直接在生产环境制造压力，应该怎样设计一次有参考价值的演练？
先从历史运行记录和业务排期中找出最忙的时间窗口，确认当时的数据量、任务并发和报表刷新需求。优先在隔离环境使用脱敏数据或可控样本，模拟任务集中启动、源端响应变慢和单次任务失败等情况；测试记录应注明数据规模、并发设置和环境，避免把结果误当成所有场景都适用的承诺。
观察的不只是任务是否成功，还包括运行时长、积压量、失败重试后的重复数据，以及恢复到正常更新所需的时间。验收标准应由业务时效要求决定：核心看板能接受多长延迟，哪些任务可以错峰，哪些数据延迟时必须明确标注。没有明确业务标准时，先协商目标，再做测试，而不是凭感觉设定并发数。
我遇到过任务失败后告警发出去了，却没人确定谁负责处理；业务方看到报表没有更新，也不知道数据是否还能用于决策。我想提前准备一份真正能执行的预案，而不是只写“联系技术人员”。
预案至少要说清四件事：谁接收告警、谁判断影响范围、谁通知业务方、谁批准恢复或降级。按影响区分等级，例如核心经营指标不可用、关键数据延迟但可追补、非关键报表暂时中断，并为每一级明确响应人和升级路径。每次异常都应显示最后成功更新时间和受影响的数据范围，避免用户把旧数据误认为最新数据。
降级方式可以包括暂停非关键任务、延后刷新、使用经过确认的备用数据或暂时下线受影响指标，但每种做法都要预先验证并说明限制。演练结束后记录发现时间、恢复时间、数据是否需要补跑及责任人，确保预案能从告警一路执行到业务确认。
读者评论
把“连通”拆成质量校验和业务确认两步很有必要，尤其退款明细延迟时，销售额看板可能仍正常刷新，却已经不能反映真实情况。
台账里记录外部接口、人工上传和替补人员，比较贴近实际运维。很多故障不在 BI 配置本身，而是凭证到期或文件没按时交付。
故障演练不仅看任务何时恢复，还核对数据是否补齐，这个区分很实用。文中也明确标注数字是情景模拟，避免把示例误读成平台实测。