running-elephant
[纯好奇]现在还有哪些公司在做自定义报表，做成什么样了
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？
首先，十分感谢官方开源，替我们走出了重要的第一步。
简单说一下我们的。
可视化：
编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
增加了一种新的图表类型-group，增强了图表跳转能力
数据：
物化视图（缓存数据，加快访问），变更追踪（数据比对，显示差异样式）
接口请求： 缓存、可取消等
AI: done：AI分析图表和报表、操作和用户手册指引。待开发：AI生成变量、AI生成SQL、AI生成图表
其余功能都有很多优化，不一一列举
目前刚刚整合，出现比较严重的问题就是聚合性能问题，请问您是怎么调整优化的？
场景：新建app浏览量图表（按用户汇总），开启聚合功能、视图缓存
问题：直接执行sql的平均耗时都是接口响应平均耗时的一半（目前浏览表有百万数据）
请教：您或您的团队是如何解决这个性能问题的（目前 还不考虑升级服务器）
@Wesilnt
目前刚刚整合，出现比较严重的问题就是聚合性能问题，请问您是怎么调整优化的？ 场景：新建app浏览量图表（按用户汇总），开启聚合功能、视图缓存 问题：直接执行sql的平均耗时都是接口响应平均耗时的一半（目前浏览表有百万数据）
请教：您或您的团队是如何解决这个性能问题的（目前 还不考虑升级服务器） @Wesilnt
我们实现了物化视图的能力，能显著提高性能，不过对应的技术难点和流程复杂度会提高很多
目前刚刚整合，出现比较严重的问题就是聚合性能问题，请问您是怎么调整优化的？ 场景：新建app浏览量图表（按用户汇总），开启聚合功能、视图缓存 问题：直接执行sql的平均耗时都是接口响应平均耗时的一半（目前浏览表有百万数据）
我们实现了物化视图的能力，能显著提高性能，不过对应的技术难点和流程复杂度会提高很多
确实是比较复杂。 请问您是使用的什么数据库？目前我这还是mysql，没有对物化视图的支持，我想参考下，看看是换数据库还是通过其它手段在mysql实现物化视图？
目前刚刚整合，出现比较严重的问题就是聚合性能问题，请问您是怎么调整优化的？ 场景：新建app浏览量图表（按用户汇总），开启聚合功能、视图缓存 问题：直接执行sql的平均耗时都是接口响应平均耗时的一半（目前浏览表有百万数据）
我们实现了物化视图的能力，能显著提高性能，不过对应的技术难点和流程复杂度会提高很多
确实是比较复杂。 请问您是使用的什么数据库？目前我这还是mysql，没有对物化视图的支持，我想参考下，看看是换数据库还是通过其它手段在mysql实现物化视图？
支持的数据库还挺多，但是能物化的数据库只有impala
自定义了写图表配置项 自定义了图表 增加了移动端控制器：[多选]/下拉列表，日期，日期范围， 增加了装饰 ：@jiaminghi/data-view-react 合计修改成后端合计 想升级antd但能力有限。
确实是比较复杂。
用doris吧， 支持mysql协议， 支持mysql，支持物化视图，对你们这种改造很小， 就是改一下链接， doris建立个实时同步任务
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
增加了一种新的图表类型-group，增强了图表跳转能力
数据： 物化视图（缓存数据，加快访问），变更追踪（数据比对，显示差异样式）
接口请求： 缓存、可取消等
AI: done：AI分析图表和报表、操作和用户手册指引。待开发：AI生成变量、AI生成SQL、AI生成图表
其余功能都有很多优化，不一一列举
大佬，二开的难度大嘛？
为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
增加了一种新的图表类型-group，增强了图表跳转能力
数据： 物化视图（缓存数据，加快访问），变更追踪（数据比对，显示差异样式）
接口请求： 缓存、可取消等 AI: done：AI分析图表和报表、操作和用户手册指引。待开发：AI生成变量、AI生成SQL、AI生成图表 其余功能都有很多优化，不一一列举
大佬，二开的难度大嘛？
为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
建议重新做，datart有些硬伤，比如编辑路径需要从报表展示页 -> 布局页面 -> 图表编辑页，光数据加载就是俩次以上，还比如数据结构很难支持带子层级的，做一些需要子层级的图表或者控制器就很难，比如树筛选器，矩形图，甘特图等，就不一一举例了
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
大佬，二开的难度大嘛？
为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
但是如果你们的使用场景不复杂，是问题不大的，要看未来的规划
已回复
------------------ 原始邮件 ------------------ 发件人: @.>; 发送时间: 2024年12月28日(星期六) 下午4:06 收件人: @.>; 抄送: @.>; @.>; 主题: Re: [running-elephant/datart] [纯好奇]现在还有哪些公司在做自定义报表，做成什么样了 (Issue #2345)
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
增加了一种新的图表类型-group，增强了图表跳转能力
数据： 物化视图（缓存数据，加快访问），变更追踪（数据比对，显示差异样式）
接口请求： 缓存、可取消等
AI: done：AI分析图表和报表、操作和用户手册指引。待开发：AI生成变量、AI生成SQL、AI生成图表
其余功能都有很多优化，不一一列举
大佬，二开的难度大嘛？
为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
大佬，二开的难度大嘛？ 为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
但是如果你们的使用场景不复杂，是问题不大的，要看未来的规划
收到，感谢大佬！
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
大佬，二开的难度大嘛？ 为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
建议重新做，datart有些硬伤，比如编辑路径需要从报表展示页 -> 布局页面 -> 图表编辑页，光数据加载就是俩次以上，还比如数据结构很难支持带子层级的，做一些需要子层级的图表或者控制器就很难，比如树筛选器，矩形图，甘特图等，就不一一举例了
第一个问题，属于设计的角度不同问题，不能说是硬伤。作为报表开发人员拿需求做报表，所以习惯大屏上直接做图，但这不是数据分析人员的工作习惯。datart试图可以兼顾数据分析人员和报表开发人员的工作场景，所以有了这个设计。你自己内部重做想做成什么样都行，但如果想做为通用产品尽量去照顾多方视角需求，就不得不面对取舍和平衡问题。而且不管怎么设计，一定不会满足所有人的需求。所以这不叫硬伤，顶多算是通用产品与个性化需求之间的矛盾。比如说下图是datart商业版大屏编辑页面，可以看到已经很饱和了，用这个页面给数据分析人员来做分析，噪音太大了
第二个数据结构问题，我们商业版可以支持树筛选器，矩形图，甘特图等，如果对控制器有定制化需求我们也可以支持
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
大佬，二开的难度大嘛？ 为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
建议重新做，datart有些硬伤，比如编辑路径需要从报表展示页 -> 布局页面 -> 图表编辑页，光数据加载就是俩次以上，还比如数据结构很难支持带子层级的，做一些需要子层级的图表或者控制器就很难，比如树筛选器，矩形图，甘特图等，就不一一举例了
第一个问题，属于设计的角度不同问题，不能说是硬伤。作为报表开发人员拿需求做报表，所以习惯大屏上直接做图，但这不是数据分析人员的工作习惯。datart试图可以兼顾数据分析人员和报表开发人员的工作场景，所以有了这个设计。你自己内部重做想做成什么样都行，但如果想做为通用产品尽量去照顾多方视角需求，就不得不面对取舍和平衡问题。而且不管怎么设计，一定不会满足所有人的需求。所以这不叫硬伤，顶多算是通用产品与个性化需求之间的矛盾。比如说下图是datart商业版大屏编辑页面，可以看到已经很饱和了，用这个页面给数据分析人员来做分析，噪音太大了
第二个数据结构问题，我们商业版可以支持树筛选器，矩形图，甘特图等，如果对控制器有定制化需求我们也可以支持
你是datart官方还是二开的商业版？
官方已经停止迭代了，大家自行维护的自定义报表迭代成什么样子了呢？ 首先，十分感谢官方开源，替我们走出了重要的第一步。 简单说一下我们的。 可视化： 编辑和预览合为一体，不需要多次跳转和加载了，性能和值控制等都有很多迭代
大佬，二开的难度大嘛？ 为了降低使用复杂度，我们也想进行二次开发，但是有同事觉得二开难度太大，还不如从零到一开始做
建议重新做，datart有些硬伤，比如编辑路径需要从报表展示页 -> 布局页面 -> 图表编辑页，光数据加载就是俩次以上，还比如数据结构很难支持带子层级的，做一些需要子层级的图表或者控制器就很难，比如树筛选器，矩形图，甘特图等，就不一一举例了
第一个问题，属于设计的角度不同问题，不能说是硬伤。作为报表开发人员拿需求做报表，所以习惯大屏上直接做图，但这不是数据分析人员的工作习惯。datart试图可以兼顾数据分析人员和报表开发人员的工作场景，所以有了这个设计。你自己内部重做想做成什么样都行，但如果想做为通用产品尽量去照顾多方视角需求，就不得不面对取舍和平衡问题。而且不管怎么设计，一定不会满足所有人的需求。所以这不叫硬伤，顶多算是通用产品与个性化需求之间的矛盾。比如说下图是datart商业版大屏编辑页面，可以看到已经很饱和了，用这个页面给数据分析人员来做分析，噪音太大了
第二个数据结构问题，我们商业版可以支持树筛选器，矩形图，甘特图等，如果对控制器有定制化需求我们也可以支持
你是datart官方还是二开的商业版？
上面说了是商业版的
