[Feature] [datastudio] Preview data does not take effect about dinky

[gaoyan1998]

1. 保存执行历史最后几条数据，这个针对批任务比较好处理，实时任务在执行历史中有可能还没有停止，保存数据这个动作的触发时机不好把控，所以说是会有一定的延迟，可以采用 @Zzm0809 提出的方案，加一个获取最新数据的按钮，定时+手动触发更新，读取从本地缓存 ResultPool 都切换成 mysql 中读取，保证数据的一致性
2. resource 我从代码看确实不应该去实现执行历史数据存储这个功能，看起来代码都绑定死了上传路径这个东西，基本上就是为资源上传存储服务的，不知道我这个理解对吗，辛苦大佬帮忙解答一下 @gaoyan1998
3. 基于上面的回复，采用方案1，我下面画了个流程图，辛苦各位大佬帮忙看一下
   主要改动如下:
   3.1 SelectResult 增加数据更新时间、持久化时间、是否截断数据字段，用来标识数据是否需要做持久化存储
   3.2 增加定时扫描、注册监听器、Spring 容器销毁触发数据持久化存储

第二点是这样的，他主要是为了服务于用户主动上传文件的，因为dinky没有删除功能，存resource会造成大量垃圾数据

对于实时任务，在停止之前我觉得没必要保存数据，用户有更好的地方去查看实时数据，无延迟，所以完全可以和批任务一个逻辑，仅在任务停止之后再进行持久化，这样会更简单一些。

至于你那个监听器我没有理解，监听什么，他不是直接在任务结束触发吗，求解 @suxinshuo

[gaoyan1998]

This feature is not implemented yet, maybe 1.1? or later

[github-actions]

Hello @, this issue has not been active for more than 30 days. This issue will be closed in 7 days if there is no response. If you have any questions, you can comment and reply.

你好 @, 这个 issue 30 天内没有活跃，7 天后将关闭，如需回复，可以评论回复。

[suxinshuo]

我可以试着做一下这个吗？我打算在预览历史的时候从 org.dinky.data.result.ResultPool 取数据，同时监听 ResultPool 中数据过期行为，仿照任务执行日志，把数据存储到本地文件，当 spring 服务退出的时候也会把 ResultPool 中的数据存储到本地文件，这样如果预览历史从 ResultPool 取不到数据就从本地文件取，同时我会把本地文件路径存储到 dinky_history。为了防止本地文件过多，我会写一个定时任务，定时清理最近M天/每个任务最近N次的执行历史文件

[suxinshuo]

我可以试着做一下这个吗？我打算在预览历史的时候从 org.dinky.data.result.ResultPool 取数据，同时监听 ResultPool 中数据过期行为，仿照任务执行日志，把数据存储到本地文件，当 spring 服务退出的时候也会把 ResultPool 中的数据存储到本地文件，这样如果预览历史从 ResultPool 取不到数据就从本地文件取，同时我会把本地文件路径存储到 dinky_history。为了防止本地文件过多，我会写一个定时任务，定时清理最近M天/每个任务最近N次的执行历史文件

@Zzm0809 @gaoyan1998

[suxinshuo]

我可以试着做一下这个吗？我打算在预览历史的时候从 org.dinky.data.result.ResultPool 取数据，同时监听 ResultPool 中数据过期行为，仿照任务执行日志，把数据存储到本地文件，当 spring 服务退出的时候也会把 ResultPool 中的数据存储到本地文件，这样如果预览历史从 ResultPool 取不到数据就从本地文件取，同时我会把本地文件路径存储到 dinky_history。为了防止本地文件过多，我会写一个定时任务，定时清理最近M天/每个任务最近N次的执行历史文件

@Zzm0809 @gaoyan1998

@Zzm0809 hello，辛苦看下

[Zzm0809]

我可以试着做一下这个吗？我打算在预览历史的时候从 org.dinky.data.result.ResultPool 取数据，同时监听 ResultPool 中数据过期行为，仿照任务执行日志，把数据存储到本地文件，当 spring 服务退出的时候也会把 ResultPool 中的数据存储到本地文件，这样如果预览历史从 ResultPool 取不到数据就从本地文件取，同时我会把本地文件路径存储到 dinky_history。为了防止本地文件过多，我会写一个定时任务，定时清理最近M天/每个任务最近N次的执行历史文件

@Zzm0809 @gaoyan1998

@Zzm0809 hello，辛苦看下

@suxinshuo thanks, assigned

[suxinshuo]

我看现在是把预览的数据存在本地缓存了，这样的话如果有多台部署 dinky 的机器，就有可能由于请求没有打到执行 sql 的机器，出现获取不到预览数据的情况，存储到本地文件也会有一样的问题。所以我打算把预览数据放到外部存储，下面有几种方案，辛苦帮忙看一下有没有好的建议 @Zzm0809

---

方案1: 放到 mysql 表 dinky_history 的 result 字段
优点:

1. 实现成本较低

缺点/问题:

1. 字段长度有限制，预览结果数据有可能比较大，导致被截断
2. 存储较多的历史数据，会对 mysql 造成压力
3. 流式任务肯定没办法实时更新到 mysql，只能定时更新，所以会有延迟

---

方案2: 使用 Resource 配置中的存储模式做持久化存储，这样由用户来控制是选用本地存储还是外部存储

优点:

1. 由用户控制是否开启存储执行历史的结果
2. 可以复用现有的逻辑
3. 不用考虑结果数据截断的问题

缺点/问题:

1. 实现成本相对高一些，需要在页面新增执行历史预览数据存储路径，或者我设置成存储在【上传目录的根路径】下面的 /history_result/... 也可以，这样就不需要用户再去配置存储路径了，因为用户应该也不太关心这个执行历史数据存储在哪里
2. 同样也会有一定的数据延迟
3. 需要用户开启这个配置以后才会记录执行历史数据

---

[gaoyan1998]

@suxinshuo
我提供一下建议

1. 预览只是临时运行使用，不会一直在后台运行，所以mysql压力可以不必考虑，
2. 我认为这个历史功能应该尽他的职责，只是保存执行历史最后几条数据即可，而正在运行的实时数据就不用考虑写入，用户应该在结果页面查看实时数据，所以不存在延迟问题
3. dinky_history目前已经有机制定时删除
4. 我觉得存resource实现成本太大了无论是开发还是用户体验，为了这个功能不值得，而且，从功能设计上讲，resource也不应该服务于这个事情

[Zzm0809]

我看现在是把预览的数据存在本地缓存了，这样的话如果有多台部署 dinky 的机器，就有可能由于请求没有打到执行 sql 的机器，出现获取不到预览数据的情况，存储到本地文件也会有一样的问题。所以我打算把预览数据放到外部存储，下面有几种方案，辛苦帮忙看一下有没有好的建议 @Zzm0809

---

方案1: 放到 mysql 表 dinky_history 的 result 字段
优点:

1. 实现成本较低

缺点/问题:

1. 字段长度有限制，预览结果数据有可能比较大，导致被截断
2. 存储较多的历史数据，会对 mysql 造成压力
3. 流式任务肯定没办法实时更新到 mysql，只能定时更新，所以会有延迟

---

方案2: 使用 Resource 配置中的存储模式做持久化存储，这样由用户来控制是选用本地存储还是外部存储

优点:

1. 由用户控制是否开启存储执行历史的结果
2. 可以复用现有的逻辑
3. 不用考虑结果数据截断的问题

缺点/问题:

1. 实现成本相对高一些，需要在页面新增执行历史预览数据存储路径，或者我设置成存储在【上传目录的根路径】下面的 /history_result/... 也可以，这样就不需要用户再去配置存储路径了，因为用户应该也不太关心这个执行历史数据存储在哪里
2. 同样也会有一定的数据延迟
3. 需要用户开启这个配置以后才会记录执行历史数据

---

---

1. 按照第一种方案可以借助任务的预览配置。限制数据预览的条数，目前最大应该是9999，但是可能会有超大宽表同样会造成数据超出字段长度，如果能使用这个可以适当提高限制。比如从9999限制为999条，因为本身从预览数据功能来看，他不是查看所有，只是查看一部分数据而已，而且这个字段本身在0.7版本就是做这个功能的。存储肯定会因为用户的各种场景来带来各种压力。这个不用太过关注，因为会自动清理长时间的无用的任务执行历史数据，
   任务延迟方面可以交给用户自己触发。比如按钮点击获取最新数据即可，因为某种情况下，表格展示是无法实时更新渲染的，除非借助现有的sse机制来实现，但是这种方式前端实现复杂度相对较高，

2.如果按照第2方案实现复杂度太高。虽然可以借助目前逻辑，但是网络io 磁盘io都会有，而且清理数据动作无法在dinky中完成。且用户如果切换存储介质，那数据如何处理。这是个问题。如果用户不开启资源配置那么数据预览就不可用。这个不可取，且虽然资源管理中可以预览文本文件，但是读文件方式仍然会有网络io和磁盘io，且也需要手动点击刷新才可以查看最新数据。

综上所述，如果你认同以上观点，建议采用第一方案（仅代表个人观点），如其他大佬有不同观点，可以继续讨论

[suxinshuo]

1. 保存执行历史最后几条数据，这个针对批任务比较好处理，实时任务在执行历史中有可能还没有停止，保存数据这个动作的触发时机不好把控，所以说是会有一定的延迟，可以采用 @Zzm0809 提出的方案，加一个获取最新数据的按钮，定时+手动触发更新，读取从本地缓存 ResultPool 都切换成 mysql 中读取，保证数据的一致性
2. resource 我从代码看确实不应该去实现执行历史数据存储这个功能，看起来代码都绑定死了上传路径这个东西，基本上就是为资源上传存储服务的，不知道我这个理解对吗，辛苦大佬帮忙解答一下 @gaoyan1998
3. 基于上面的回复，采用方案1，我下面画了个流程图，辛苦各位大佬帮忙看一下
   主要改动如下:
   3.1 SelectResult 增加数据更新时间、持久化时间、是否截断数据字段，用来标识数据是否需要做持久化存储
   3.2 增加定时扫描、注册监听器、Spring 容器销毁触发数据持久化存储

[suxinshuo]

1. 保存执行历史最后几条数据，这个针对批任务比较好处理，实时任务在执行历史中有可能还没有停止，保存数据这个动作的触发时机不好把控，所以说是会有一定的延迟，可以采用 @Zzm0809 提出的方案，加一个获取最新数据的按钮，定时+手动触发更新，读取从本地缓存 ResultPool 都切换成 mysql 中读取，保证数据的一致性
2. resource 我从代码看确实不应该去实现执行历史数据存储这个功能，看起来代码都绑定死了上传路径这个东西，基本上就是为资源上传存储服务的，不知道我这个理解对吗，辛苦大佬帮忙解答一下 @gaoyan1998
3. 基于上面的回复，采用方案1，我下面画了个流程图，辛苦各位大佬帮忙看一下
   主要改动如下:
   3.1 SelectResult 增加数据更新时间、持久化时间、是否截断数据字段，用来标识数据是否需要做持久化存储
   3.2 增加定时扫描、注册监听器、Spring 容器销毁触发数据持久化存储

第二点是这样的，他主要是为了服务于用户主动上传文件的，因为dinky没有删除功能，存resource会造成大量垃圾数据

对于实时任务，在停止之前我觉得没必要保存数据，用户有更好的地方去查看实时数据，无延迟，所以完全可以和批任务一个逻辑，仅在任务停止之后再进行持久化，这样会更简单一些。

至于你那个监听器我没有理解，监听什么，他不是直接在任务结束触发吗，求解 @suxinshuo

第一点保存时机:
我看现在代码中的逻辑，只要任务开始执行了，就会存到执行历史，并没有感知批/流任务执行结束。
而且现在逻辑是统一的没有区分批和流任务，都是感知不到执行结束的，如果按照执行结束来保存数据，个人感觉有如下几个问题:

1. 只要开始执行就能看到执行历史，但是实际上可能还没有结束，用户看到有执行历史但是没有数据可能会比较疑惑
2. 现在查看实时数据的地方，只能看10分钟，10分钟以后缓存过期就查不到数据了，所以这里的逻辑需要改造

上面的流程图的方案是不区分批和流，只要任务开始执行，保存了执行历史，那就定时轮询获取更新的数据存储到 mysql，现在用户查询实时数据需要点击获取数据，这个时候会触发更新数据存储到 mysql，这个时候页面上看到的也没有延迟

第二点监听器:
基于第一点
现在批和流是同样的逻辑，都是在提交任务以后，就启动异步线程获取结果数据存到本地缓存，在本地缓存维护一个映射关系，持续从流/批中获取结果数据，所以这里加了一个监听器，当缓存数据失效，也即在原先的逻辑中获取最新数据获取不到数据的时候，认为流式任务结束了，触发数据持久化到 mysql，当然这里有点问题，缓存数据失效，流任务实际上并没有结束，只是我们人为中断了 @gaoyan1998

---

综上所述，感谢 @gaoyan1998 的建议，把方案做了如下改动，我认为这样更合理一些，整体的逻辑也会简单一些

1. ResultPool 结果缓存从10分钟改成永远不失效，任务执行完成以后从 ResultPool 手动移除(原先虽然10分钟会失效，但是内存并没有释放，还在不断获取结果写入内存，所以从10分钟缓存改为永久有效并不会相较原来增加大内存占用)
2. 批和流任务都是执行结束再写入 mysql
3. 执行历史预览数据先查 ResultPool，没有的话再查 mysql(防止出现有执行历史，但是没有预览数据的问题)
   

[gaoyan1998]

我觉得可以 @Zzm0809 你看看还有啥补充么

[Zzm0809]

我觉得可以 @Zzm0809 你看看还有啥补充么

无,可以先实现一下 pr上来看下 @suxinshuo