当我们遇见数字报表卡死的情况，该如何解决？而作为一名产品设计，如何在设计时避免出现这一问题？本篇文章将以四个设计原则为主，对数据报表设计提供一些参考思路，希望能对你有所启发。

最近，同样从事产品经理工作的朋友跟我抱怨，说在最近的一次例会上又跟开发吵起来了，原因是数据报表的页面又卡死了。

• 开始，前端说是后端的锅，因为数据太多了；
• 后来，后端说是前端的锅，因为渲染太慢了；
• 最后，前后端得出一致的结论：是产品的锅，因为数据报表的设计不合理。

他给我看了一下他们产品的数据报表，全部平铺在一个页面上，打开报表的时候，需要一次性将所有数据都加载出来，难怪会卡死。

我因为他这段“悲伤”的经历，专门整理了这篇文章，来说一说数据报表应该怎么设计。

导致数据报表卡死的“原罪”

雪崩时，没有一片雪花是无辜的，导致数据报表卡死的三大“原罪”，就是设计不合理、后端查询数据量太大以及前端渲染太久，而设计不合理，正是三大“原罪”之首。

我在之前的文章《那些被迫妥协的产品设计背后的技术原因》中分享过，如果一次性请求或处理的数据量过大，后台可能处理超时、响应过程可能失真、前端渲染可能卡死。

在《4个数据库语句，带你了解产品数据的增删改查应该怎么设计》中我也提到过，数据的查询效率跟数据表数量、字段数量以及数据数量有关。

因此，要解决这个问题，就要从设计上先进行优化，这里分享数据报表设计的四个“也许”法则，希望对你有所帮助。

一、也许你并不需要这个数据

产品经理在做数据报表的设计时，有时候会拿不准某个数据到底有没有必要，索性就加进去了，后来发现用不上就隐藏，结果冗余的数据越来越多，查询的性能越来越差。

由于数据报表往往牵涉大量数据的查询和统计，因此对每个数据都应该慎之又慎，谁也保证不了最新添加的一个数据会不会成为压垮数据报表的“最后一根稻草”。

因此，数据报表应该只统计有价值的数据，那么，如何才能评判一个数据是有价值的呢？

1）对业务具有总结意义

比如过去一周的用户增长数据、交易流水数据之类可以总结业务的发展与健康状况的数据。

2）对运营具有指导意义

比如轮播图点击率数据、产品转化率数据之类可以指导下一步运营重点和策略的数据。

3）对产品迭代具有参考意义

比如AB测试数据、埋点数据之类可以参考接下来产品迭代方向的数据。

当你不确定一个数据是否必要的时候，不妨看看这个数据是否符合上面的一个或多个条件。

二、也许你并不需要最新的数据

举个例子，如果我想通过数据报表来统计近一个星期的用户增长曲线，像这样的数据报表一般是这样设计的：

• 在用户数据表中统计近一周每天注册的用户总数。
• 统计完成后，后端将数据传递给前端。
• 前端绘制数据曲线。

但像这样的设计有个问题：每名用户的每次查询都需要实时进行统计，但其实每次统计到的结果并没有不同。

因此，要想对这个数据报表的设计进行优化，得先知道，这个数据报表实际上具有两个特点：

1）当天的数据是不要的

今天还没结束，数据会受各种因素影响而产生变化或波动，比如双十一之类节日活动的时候，数据量几乎都是在活动开始的一瞬间爆发，在当天结束前，最终数据都是未知的。

因此对于统计近一个星期用户增长曲线的需求，应该摒除当天的数据，从昨天开始往前一周进行统计。

2）过去的数据是不变的

如果只是单纯摒除当天的数据，对于数据统计的优化是非常有限的，但从这个需求我们可以知道，过去一周的用户增长数据已经是一个历史数据，是一个固定值。

无论后面的数据怎么变化，都不会影响之前的数据，利用这个特性，我们可以对这个数据报表的设计进行优化：

• 系统在每天0点过后跑一次统计算法，将过去一周每天注册的用户数进行统计并记录在另外一张数据表里。
• 后端将已经统计完成的数据传递给前端。
• 前端绘制数据曲线。

这样说也许你的感知还不是很强烈，但须知在整个数据报表呈现的过程中，最耗费时间的就是统计过程。

优化前，每名用户的每次访问都需要统计一次，而优化后总共只需要统计一次，每名用户的每次访问都是直接从已经完成统计的数据表里拿到统计结果，你可以想象这两者在查询速度上的区别。

为了让你更清晰地了解这个需求的报表设计优化前后的不同，我简单画了一张图。

三、也许你并不需要同时查看所有数据

我在之前的文章《那些被迫妥协的产品设计背后的技术原因》中分享过，要解决单次处理数据量过大导致出现的各种问题，可以对数据进行“分割”，也就是分页或分步浏览，这种设计在数据报表中同样适用。

如下图的报表，如果你的业务只有5个渠道还好说，但如果你有50个渠道，一轮查询下来，不卡死可能也过去几十秒了，而且报表本身的作用是使数据更易读。

但如果在一个报表中展示50条数据曲线，数据报表也就失去了它应有的作用。

但也许你并不需要同时查看50个渠道的数据，你可能只是关注资源总量前5的渠道，或者只是想看一下刚开拓的几个新渠道的资源总量曲线。

这种情况下，完全不用去统计所有渠道的数据，可以设计一个渠道的选择器，在选择了渠道之后，才去统计对应渠道的数据。对于没有选择的渠道，则无需统计，这样的设计也可以有效降低系统处理数据的压力。

四、也许你并不需要马上拿到数据

前面的3个法则主要是针对数据报表的设计和查询，而这个法则，主要是针对数据的导出和下载。

我们知道，有时候为了在各个地方使用系统的数据，数据报表有时会设计一些导出或下载的功能，但是当需要导出或下载的数据量极大的情况下，系统处理的时间可能会非常长，而且最后不一定能导出或下载成功。

类似这样的导出或下载数据报表的功能设计，想要避免系统处理时间过长导致卡死或导出失败，一般有两种优化设计方案。

1）告诉我你需要哪个时间段的数据

在用户操作导出或下载功能时，询问用户需要哪个时间段的数据，而不是将所有数据全都导出来，在限制了时间段之后，可以有效控制导出的数据量，降低导出失败的风险。

2）没问题，但请你过一会再回来拿数据

按照方案1设计之后，还是存在一种可能的风险，就是用户选择了从平台上线至今的时间段，这样还是等同于导出了系统的全部数据，还是会有卡死的风险，那怎么办呢？

这种情况下，有两种处理方案。

• 限制选择的时间段长度，比如最多只能选择3个月。
• 把导出和下载的功能分开，用户导出时，在服务器进行数据处理，在此期间，用户可以离开系统或操作系统的其他的功能，服务器处理完成后，生成可以提供给用户下载的文件，如 Excel 表格等，并通知用户，当用户回到数据报表页面点击下载时，直接将文件从服务器下载到本地即可。

数据报表设计时，遵循以上四个“也许”法则，也许下一次数据报表再次卡死时，开发就很难将锅甩到你的身上。

以上便是本文的全部内容，感谢阅读。