报表

[timzaak]

最近需要做报表相关的软件（基本上所有外包软件都会用的到）。 按需求发展状态来讲：报表很容易从预制报表，变成自定义报表+报表看板。 所以，这方面议价就会很麻烦。研发的时候，很容易扯皮。

所以一开始就最好搞一个能自定义报表+报表看版的。然后根据需求，快速调整。 目前市面上，更多是针对SQL语句，单DB的，涉及到缓存，多DB 协作，就很少了。

所以，针对业务端（更准确的说是前端），可以提出一个通用的模型，搜寻现成的，具化到后台，就需要具体情况具体分析。毕竟我们其实做的是业务应用层数据展示，不是数据分析平台。

期望达到的目标，在现有开源产品的增强，拿Grafana 举例：

1. 根据时间，获取维度，有些维度会随着时间变化而变化。
2. 支持 http 请求拓展。
3. 更美的报表

翻看了一下Grafana 的前端代码，angular+react 混合。 需要好好搞一下。

[timzaak]

Grafana angular 迁移进度：Angular migration: pages & views Ref #71

[timzaak]

做报表最容易被忽略的：时间！ 随着时间的变化，维度之间的关联关系会产生变化，基础数据与维度之间的映射也会产生变化。 这就导致一个问题，我在特定时间，根据现有的维度去探查历史数据时，历史数据应该按照现有的维度关联关系去获取，还是按照当时的关系去获取？

大部分的报表系统都会因为上面的问题出各种各样的数据不准确问题（实际是数据不符合认知）。

我目前的解决方案，是基于图数据库做关联关系，在关联（边）上引入有效时间跨度。先基于图数据库来索引基础数据的关键索引+有效时间。再去获取数据并做计算。

[timzaak]

报表的缓存，基于 SQL 语句 + 时间参数来搞。这个要对 ORM 进行深入了解。

根据时间拆分 SQL

今天的一批，昨天以前的是另一批，这样可以分别设定缓存策略。例如今天以前的 30分钟～1天。今天的5分钟。 问题： 1.凌晨时刻，如果有数据，如何处理？

情况有： {>=| > } start[5 days before], {<=|<}end[today 0:0] with {>=| > } start[today 0:0], {<=|<}end[now]
当以下情况时，就出了问题：

{start >=, end <= } ===> start>= 5days, end<=today 0:0 => start>= today 0:0, end<=now (多了一条数据) {start > , end < } ===> start> 5days, end< today 0:0 => start> today 0:0, end< now（少了一条数据）

所以时间判定要修正一下， 第一条SQL： end <= , 第二条 start >。这个涉及修改 SQL 语句。对 SQL 要进行解析，再组装才行。 要么就是提供一个函数，进行时间拆分，再由人工来搞定这个拆分。

问题：2. 缓存Key 该如何生成？

根据 SQL 语句 md5, 那么，endTime如果涉及今天，会一直变， 也就是今天的每次查询都无法缓存。如果对endTime 进行矫正，和问题1是一样的解决方案，不过有稍微简单一些的方法，key 值由人手工提供。

SQL查询任务化

可减少数据库压力，但这样就会引入任务执行管理监控的一堆东西要做。这些事情目前应该有成熟的框架在做了，拿来主义。

常用耗时 SQL 提前准备

额外问题

缓存设计中，还有个问题是，有可能涉及多个数据源，如果其中有非 SQL 的，那就尴尬了。另外，还有一些计算过程是写在代码中的。

那么更撸棒的做法，有可能是在请求一开始，就进入缓存 check。 这一层做完之后，再考虑执行SQL执行的缓存。

实际情况

1. 开发者有可能会想尽可能的一条SQL解决问题，这里面大概率会用到关联查询以及非标准SQL（尤其数据库是PG，很难抵挡诱惑）。这会给后期数据库更换迁移、分库分表带来障碍。所以尽量写单表标准SQL，关联查询（基本上是根据ID 获取 name的），应该在代码中进行二次组装。
2. 数据量太大了，这个废话的解决办法：加钱。

[timzaak]

用superset 等已经有的报表解决方案。

业务层面，就是指标+统计数字+时间，并可导出。 业务人员对于数据的精细要求，很多场景下实际上很糙，而且变化也快，历史数据很快就没有价值。

[timzaak]

cube.js 是符合预期的报表工具。