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

[Pandas886]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

无法预览数据，点击按钮后，没有触发请求

What you expected to happen

正常预览数据

How to reproduce

none

Anything else

No response

Version

dev

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[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 容器销毁触发数据持久化存储

[gaoyan1998]

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

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

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

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

[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