数据中台

一家门店三年的销售流水，按天展开是上千行，按物料展开可能到几十万行。这类查询如果和日常开单、备货、对账挤在同一套流程里，查一次就卡一次；查完的结果又散在各人手里，谁都认为自己的口径是对的。数据中台把历史经营数据和历次查询结果集中存放，查询在后台异步执行，前台工作不被打断，结论还能在企业内共享复核。

一、功能说明

能力	说明
历史数据集中存储	把企业多年的经营数据与历次查询结果集中存放，可反复调用
任意时长查询	按需要的起止时间取数，不受固定报表期间的约束
异步执行	大范围查询提交后在后台运行，前台可继续开单、查库存等操作
大结果集处理	过百万行的查询在后台自动跑完，不需要一直守着页面
结果共享	查询结果可一键分享给同事或管理者查阅
查询留档	历次查询的条件与结果长期保留，供事后复核与交接使用

查询在后台执行，结果单独存放，日常开单与库存作业不受影响；具体菜单、字段与数据同步时点以实际版本为准。

二、适用场景

跨年趋势复盘。 要看三年的节令曲线、会员结构变化、单店成长轨迹，固定报表的期间往往不够长。数据中台按任意起止时间取数，把多年数据放在同一口径下比较，避免一年一张表、几张表的统计范围各不相同。

营业高峰不敢跑大查询。 上午门店开单、下午备货、晚上对账，前台几乎没有空档。把大范围查询提交到后台异步执行，前台该做什么做什么，结果出来再回来看，不必为了出一张表停掉半小时业务。

结论要交给别人复核。 老板要看区域汇总，财务要核对同一批单据，店长只关心自己门店。同一份查询结果分享出去，几个人看的是同一组数字；发生争议时，回到查询记录就能看到当时的条件与结果，不必重跑一遍再说「我记得是这样」。岗位轮换时也一样，前任做过的查询都留在记录里，接手的人沿着记录走一遍就能上手。

三、使用要点

1. 先定口径，再提交查询。 时间范围、门店范围、金额是否含税、退货是否冲减，这四项先写下来。同一份数据在两种口径下可能得出相反结论，事后争的往往是口径，不是数字。
2. 大范围查询走异步，不要反复提交。 同一条件连续点几次，后台就排出几份相同任务，既占资源，也让自己分不清该看哪一份。提交后记下任务特征，等结果出来再核对。
3. 查询结果要命名并留备注。 按「用途 + 范围 + 期间」命名，备注里写清口径与提交人。半年后翻记录时，名称和备注是唯一能说清这张表是什么的东西。
4. 分享范围按需要控制。 结果里常带会员信息、成本与毛利，分享给谁、给到什么粒度要有约定；对外发送前先做字段裁剪。
5. 关注数据截止时间。 历史数据同步有先后，最新一天可能尚未完整。用当日数据下结论前先确认截止时点，避免把「还没同步进来」当成「卖得少」。

四、与其他功能的关系

环节	对应功能
首页经营看板	登录后首页与数据看板
集团层面汇总	集团运营决策看板
固定报表改造	自定义报表
周期对比	销售环比分析
自然语言问数	报表 AI 助手

五、验收清单

检查项	通过标准
历史跨度	能取到建账以来的完整期间，最早月份有数据
异步不阻塞	提交大范围查询后，前台仍可正常开单与查库存
结果可复现	同一口径、同一期间重复查询，两次结果一致
大结果集完整	百万行级查询能跑完，末页数据不缺失
分享可控	被分享人只能看到其授权范围内的数据
记录可查	历次查询的条件、提交人、结果都能回看

六、常见问题

查一个季度要等很久，是不是系统有问题？ 先看数据量与查询范围。跨年、全部门店、按明细展开的查询本来就慢，异步执行正是为了让等待不影响业务。若同一条件平时几分钟、这次几小时，再查是否同时提交了多份任务、数据是否正在同步。

两个人查同一时间段，数字不一样，信谁？ 先对齐四项：时间范围、门店范围、是否含税、退货如何处理。四项一致仍不同，再查是否一方用了明细、一方用了汇总，以及是否有人在同步完成前取的数。口径写清楚，数字才有可比性。

查询结果能直接发给客户或外部合作方吗？ 不建议。结果里通常带会员信息、成本与毛利，属于内部数据。对外提供前先做字段裁剪，并按企业规定走审批；分享功能是给内部复核用的，不是对外发布的通道。