- 博客(415)
- 收藏
- 关注
RSS订阅
原创 数据分析编程 - 从入门到精通
在当今这个数据驱动的时代，数据分析已成为各行各业不可或缺的核心能力。从商业决策到科学研究，从金融预测到医疗健康，数据中蕴藏的洞见正在重塑我们的世界。然而，面对海量数据和复杂分析需求，传统的数据处理工具已显得力不从心，编程能力正逐渐成为数据分析师的必备技能。
2025-08-20 13:58:58
813
原创 DQL 超维分析
而且情况复杂时这个表可能要被重复关联，比如查询北京号码打给上海号码的通话记录，这个表就要被关联两次，这个表还会有维表也会被复制多次，如果维表还有维表…针对这个特性，将关联运算进行了分类，在此基础上发明了 DQL（Dimensional Query Language）一种基于维度的查询语言，从根本上解决 SQL 处理关联问题面临的困境，进而为 BI/ 灵活查询提供服务。而 SQL 对关联运算（JOIN）的定义很简单，两个表关联时，给出对应的关联字段就可以了，除此之外没有更多的信息和约定。
2025-08-01 15:11:34
692
原创 SPL轻量级文件存储提速查询实践
摘要：针对传统数据库在分析计算中的性能瓶颈，提出使用轻量级esProc SPL列存文件存储历史数据，结合其强大计算能力提升查询性能。该方案无需复杂集群，可直接嵌入应用，并提供了系列实践方法解决典型性能问题（如COUNT DISTINCT、外键关联等）。文中详细说明了测试环境配置、数据准备和SPL连接MySQL的示例代码，为突破数据库查询瓶颈提供了实用解决方案。
2025-07-15 14:18:55
499
原创 SPL 轻量级多源混算实践
摘要：本文介绍了使用esProc SPL实现多源数据混合计算的技术方案。针对当前异构数据源混合计算的技术难题，SPL通过统一数据对象转换和轻量化设计，提供了比传统逻辑数据仓库更灵活的解决方案。文章详细说明了SPL的原生连接器（支持RDB、本地文件等）和外部连接器（支持MongoDB、Kafka等）的架构，并规划了7个实践案例，涵盖从基础查询到跨库JOIN等复杂场景。环境准备部分提供了SPL、MySQL和MongoDB的安装指引，以及配套数据文件的下载链接。该方案特别强调SPL的语法简洁性和嵌入应用的能力，使
2025-07-14 16:50:38
580
原创 引入 Copilot，AI 时代的报表开发新范式
AI 时代，软件开发相关工作正被全面重塑——从理解意图、自动生成代码，到补全逻辑、辅助调试错误、自动编写测试用例，AI 已深度融入开发的每一个环节，推动整个领域经历前所未有的生产力重构然而，在这场重构的浪潮中，报表开发，这一同样属于技术人员的开发环节，却像一个被遗忘的孤岛，迟迟未能迎来自己的智能时刻。
2026-03-30 15:03:06
331
原创 从 GUI 到 LUI 的进化，报表工具也有了 Copilot
从 GUI 到 LUI，报表工具 Copilot 的问世对于个人而言：是一场人机交互方式的深度进化——它把我们从繁琐的菜单点击和公式记忆中解放出来，让做报表真正变得简单对于企业而言：是一次技术路线与成本结构的双重革新：谁能率先拥抱 LUI、率先用上 Copilot，谁就能先一步拥有 AI 制表的能力，在技术赛道上抢占先机；同时，它还能省下大量的软件采购成本和人力投入，当别人还在用旧工具堆人力的时候，你已经用更低的成本、更高的效率跑在了前面，在这场残酷的竞争中，谁先掌握这项能力，谁就赢得了主动。
2026-03-25 16:01:43
344
原创 润乾 BI DBD Copilot 实践体验
地区销售折线图，其中包含 echarts 折线图，分类为时间，系列为大区，系列值为销售额。给报表数据集设置参数“大区”，该折线图要可以被大区参数过滤，我们可以在数据集中处理。我们再来做一个周期面板，包含一个订单明细表，和一组事件按钮，赋予表格交互能力，让我们可以通过点击快速切换日期间隔，查看周期内订单。按需摆放这些指标卡，这里我们选择在左侧竖排摆放摆放，右侧留出的空间仍然处于第一屏，有足够的空间展示更多信息。用标签展示，我们用标签来做这个例子，可以和其他结构结合，让走势图处于一个卡片内。
2026-03-24 11:39:08
342
原创 从同质化市场搅局的开源BI 到AI时代全链智胜的ChatBI
无论您的企业规模大小，无论您正处于数据应用的哪个阶段，润乾 BI 都可以胜任，用开源免费的 BI，和极低成本的 AI（ChatBI），共同探索数据的无限价值，让 ChatBI 人人都可用!
2026-03-23 11:01:27
421
原创 引入 Copilot，AI 时代的报表开发新范式
《AI时代报表开发的智能突围：润乾Copilot的创新实践》 摘要：在AI重构软件开发各环节的背景下，报表开发长期处于"数字化孤岛"状态。润乾报表Copilot通过自主研发的规则引擎，实现了报表开发从"人适应工具"到"工具理解人"的范式转变。该系统能理解自然语言指令，自动完成数据加载、复杂报表制作、样式调整等全流程操作，解决了传统报表工具对新手不友好的痛点。采用规则引擎而非大语言模型，确保了100%的执行精确度，同时支持与LLM协同工作，兼具灵活性
2026-03-19 14:33:43
355
原创 润乾报表与帆软报表评测对比报表
润乾和帆软是国内仅有的两款能流畅处理中国式复杂报表的产品。润乾在数据处理性能和灵活性上表现突出，尤其适合大数据量和复杂计算场景；帆软则在用户体验和可视化效果上更优，操作简便但部分高级功能需额外付费。两者在数据源支持、报表模型、统计图、填报等功能上各有特色：润乾采用类Excel设计，计算引擎高效；帆软提供丰富的向导和模板，降低开发门槛。商务策略方面，润乾价格透明性价比高，帆软采用模块化定价更灵活。企业应根据具体需求选择：追求性能和处理复杂报表选润乾，注重易用性和可视化效果选帆软。
2026-03-05 11:13:37
369
原创 亲测一个“野生”想法：用AI写量化策略，到底靠不靠谱？
当然，AI不是神，第一次生成的代码格式可能有小毛病。但关键是，你可以像训练助手一样，指着平台的规范文档对它说：“不对，买卖信号要写成一行。你不用懂Python，只需要用大白话告诉AI（比如千问、DeepSeek）你的想法，比如“帮我写一个5日线上穿10日线买入，下穿卖出的策略”。的工具，完全靠点选和AI对话，就搭出了一个完整的双均线策略，还能跑回测。代表的“AI+低代码”模式，确实为个人投资者打开了一扇新窗户。最近在乾学院读到一篇挺有意思的实战帖（《用 AIQT 实现双均线策略》），讲的是如何用一款叫。
2026-02-02 17:21:35
330
原创 这款 Text2SQL 技术为什么能对噩梦般的 JOIN 免疫
Text2SQL领域面临多表JOIN难题，当前主流方案在真实企业数据环境中准确率骤降。润乾NLQ采用确定性编译架构，通过语义层将复杂JOIN转化为规则执行，避免了LLM的"幻觉"风险。其核心DQL语言实现"外键属性化"和"按维对齐"机制，将自然语言分步转换为规范SQL，解决了跨表多维统计等复杂查询问题。相比依赖大模型的方案，该技术路径更稳定、成本更低，适合企业级应用场景。
2026-01-20 14:52:22
661
原创 史上门槛最低，AI 时代首款报表工具 Copilot 尝鲜
润乾报表推出Copilot功能，通过自然语言指令实现报表快速制作。该功能支持汉语命令完成数据集加载、交叉报表生成、外观调整等操作，大幅降低使用门槛。演示了多层交叉报表和不规则分组报表的制作流程，展示了Copilot在分组扩展、分段统计、条件格式等方面的智能化处理能力。系统采用轻量级规则引擎而非LLM，确保私有化部署可行性，同时提供实时命令提示辅助用户准确输入。该功能已内置在基础版本中，显著提升报表开发效率。
2026-01-15 14:25:32
576
原创 报表工具选型深度解析系列之一：润乾报表
润乾报表适合的场景：• 存在大量固定格式、结构复杂的中国式报表（如财务、统计、运营报表）需求的传统行业或大型企业。• 拥有稳定的 Java 技术团队，能够接受一定学习成本，追求对报表生成逻辑的深度控制。• 数据准备环节较复杂或困难的。• 预算有限，但需要处理高难度报表需求，追求极高的功能性价比。• 需要将报表能力作为模块深度集成到自有业务系统中。它可能不适合的场景：• 项目严重依赖厂商的现场贴身服务、快速响应和业务咨询。
2026-01-07 15:39:12
813
原创 ToB 软件降本过冬：破解报表环节的隐性成本，重构项目利润模型
ToB 软件企业面对当下的市场环境，变革已非选择，而是生存的必需，过去粗放的经营模式难以为继，报表环节正是审视自身成本结构、启动精细化运营的理想切入点成功的转型并非一蹴而就，它始于意识上的转变——认识到报表不仅是功能模块，更是贯穿项目始终、影响利润曲线的关键成本因子行动上，则需要遵循一套清晰的路径，首先，通过建立 TOC 总拥有成本模型，并采用固定授权模式，彻底锁定采购成本的不确定性，其次，通过引入高效率的报表工具，解决“中国式复杂报表”的效率瓶颈，杜绝“人工填坑”
2026-01-04 13:53:48
1006
原创 润乾 NLQ 课程
但是，大模型天生存在不可克服的幻觉，查询数据的“准确性”无法保证。业界用了很多辅助手段仍然难以消除幻觉，只能大幅限定查询范围，严重削弱 “复杂性”，结果以 Text2SQL 技术为基础的 chatBI 就只能沦为“玩具”。我们精心设计了这门培训课程，从润乾 NLQ 原理的细致解析，到手把手的实际操作讲解，助您掌握这个利器，建成真正实用、好用的 AI 式数据查询系统。大模型的出现带动了 Text2SQL 技术，数据查询貌似变得前所未有的简单，只要会打字、提问，就能轻松获得结果，具有很强的“灵活性”。
2025-12-29 11:11:41
333
原创 报表成本砍80%、开发效率翻倍：ToB寒冬破局关键
在当前经济寒冬与行业竞争加剧的背景下，企业愈发需要通过精细化管理成本与提升效率来维持竞争力，而报表环节存在的能力短板，往往迫使企业不得不持续投入人力来填补缺口，导致报表从本应赋能业务的“价值输出器”异化为吞噬利润的“成本黑洞”润乾报表则提供了全面的能力支撑，显著减少了因工具能力不足导致的无谓人力消耗，帮助客户走出“人工填坑”的循环，同时，其透明的采购模式彻底避免了按“装机量”计费带来的成本不确定性，从采购与开发两端协同降低总体投入。
2025-12-19 15:55:50
691
原创 让 BI 拥有‘领域大脑’：智能 BI 如何实现 AI 级精准数据查询
大模型因其概率本质难以担此重任，而润乾报表的 NLQ 组件通过规则引擎明确定义领域知识，是领域知识最完美的容器，从根本上确保了查询的准确性，让 AI 式数据查询从概念迈向实用，从而真正释放数据价值。对于能看懂代码的程序员来讲，这不是大问题。其实，无论用户输入怎样的问题，大模型永远都会给出一个结果，即使数据库中数据根本就无法计算这个任务目标，大模型也不会拒绝，不懂编程的业务用户根本没办法发现和纠正大模型的错误。实际上，大模型的本质是概率模型，它的训练目标是生成流畅、连贯的文本，而不是绝对精确的查询语句。
2025-12-15 16:17:06
920
原创 人人都能实施的智能问数，中小用户也能玩得转的 Text2SQL
AI 时代，到处都在说“智能问数”，用大白话直接问，数据就给你整得明明白白。理想很美好，可真要一探究竟，大家心里就打了鼓：这玩意儿是不是得养个 AI 科学家团队？是不是得买几十上百万的 GPU 服务器？查出来的数要是不准，谁敢拿来做决策？别急，润乾 NLQ 带来了一条不同的路——一条让中小企业、普通开发团队都能轻松上车、用得安心、花得明白的路。不依赖“黑盒”大模型去猜，而是用一套清晰的“规则翻译官”，把业务问题，精准无误地转换成数据库能听懂的指令。
2025-12-12 16:53:46
674
原创 工业 AI 监盘发现异常实践
基于以上实践，我们自研的工业 AI 监盘异常发现算法已在多种工业场景中得到有效验证。该算法立足于“异常即罕见”的核心思想，借助动态分布建模与多维度联合分析，实现了在无标注条件下的高精度异常识别。其主要优势可总结如下：1. 完全无监督，无需标注数据算法基于设备正常运行状态下数据模式相对稳定的假设，通过对历史数据分布的自主学习，自动识别偏离该分布的异常点，彻底摆脱了对人工标注数据的依赖，极大降低了实施成本与数据准备周期。2. 高实时性与低资源消耗。
2025-12-08 14:29:21
858
原创 Text2SQL 破局技术解析之二：MQL 实现与复杂性
在基于 "规范文本" 的 NLQ 架构中，MQL（Metrics Query Language）作为规范文本的确定性编译目标，承担着关键使命。本文作为 "规范文本" 篇的延续，将继续解析 MQL 的设计逻辑及其实现机制。
2025-12-03 14:07:22
1053
原创 万字长文解析 NLQ 破局 Text2SQL，值得收藏
润乾 NLQ 技术已解析完毕。我们从“规范文本”破局，用“MQL”实现复杂性，继而用“NLQ 词典”保证准确性。三者环环相扣，共同构成了一个同时满足灵活性、准确性、复杂性的 Text2SQL 架构。
2025-11-28 13:56:25
776
原创 Text2SQL 破局技术解析之一：规范文本与灵活性
自然语言转 SQL（Text2SQL）技术旨在降低数据查询的技术门槛，但一直面临 "灵活性"、"准确性" 与 "查询复杂性" 难以兼顾的技术困境。直接由大语言模型生成 SQL 存在语义 "幻觉" 会带来准确性问题，引入结构化中间层通过牺牲查询复杂性换来准确性的有限提升，仍然难以满足企业级 BI 场景的需求。润乾 NLQ 技术采用 "规范文本" 作为中间层，构建人机均可理解的中介语言，将不确定性限制在自然语言理解阶段，并通过。
2025-11-24 17:16:35
522
原创 AI 现在都这么强大了，为什么 chatBI 还像是个玩具？
NLQ 组件能做到像 chatBI 一样“好玩易用”，同时还避免了其“不可靠”的缺陷，让 AI 式数据查询告别“玩具”阶段，进入真正的商业应用场景。无论用户输入怎样的问题，大模型永远都会给出一个结果，即使数据库中数据根本就无法计算这个任务目标，大模型也不会拒绝，不懂编程的业务用户根本没办法发现和纠正大模型的错误。面对 chatBI 的这些局限，润乾报表团队基于多年 BI 领域的技术积累，推出了全新的 NLQ（自然语言查询）组件，能让 AI 式数据查询从“能玩的玩具”变成“好用的工具”。
2025-11-18 10:39:09
340
原创 另辟蹊径的 Text2SQL，不用大模型也能搞 chatBI
随着 AI 大模型的技术突破，用自然语言与数据进行对话的 ChatBI 概念也变得火热起来，人们普遍认为这件事终于具备了可行性。于是，业界很自然地沿着大模型（LLM）这条技术路线进行探索，期待它能理解业务人员的随意提问并直接返回数据结果。然而，理想很丰满，现实却有点骨感：LLM 方案始终存在“幻觉”问题，而且成本高昂、部署与调优过程也相当复杂。我们注意到，在 BI 这个特定场景下，业务人员用于查询数据的自然语言，其实并没有日常对话那么随意和复杂。
2025-11-11 11:02:04
960
原创 AI 提效报表困难SQL开发？不好说，但SPL肯定可以
对于难题以及新题，更有效的做法是用简单的 SQL 取数，再用 SPL 实现业务逻辑。SQL 难以解读，还是 SQL 本身的原因，不符合自然思维，缺乏过程性，通常要用多层的嵌套结构，需要积累多年的 "秘密小技巧"，编码思路与现代编程语言格格不入，也比现代编程语言更难解读。用 stackoverflow 上的 SQL 问题对 AI 提问，会发现一个似乎是意料之外的现象：对于有一定年头的旧题通常能给出较满意的答复，但对新出现的问题往往会乱答一气，问题越新，答案就越乱，很多问题难度并不高，AI 给出的答案也不对。
2025-11-10 15:05:09
1051
原创 5 个 JOIN vs 1 行 DQL：维度查询语言的降维打击
江湖之中，凡我辈数据库修习者，谁不曾拆解过数百存储过程，优化过万行 SQL 脚本？然则，当你面对接连五个 JOIN，而业务方仍在追问“可否再添一维”时，可曾感到一股内力滞涩，呼吸为之一窒？
2025-11-06 15:21:34
843
原创 DQL 超维分析 - 5 集算器 DQL
虚表是定义在数据文件（组表）上的逻辑表，由于组表具有更高的 IO 性能、更高效的存储方式，创建虚表时可以根据组表特性进行设置。比如为内存表建立索引，使用枚举 / 二值维度等。在工具栏中选择“增加虚表”，选择对应的组表文件虚表就创建完成了。虚表名会根据组表文件名命名，其中的主键信息也会随组表设置。虚表定义也可以通过集算器 ETL 工具生成，在将数据表转储成 CTX 的同时生成虚表定义。在 ETL 工具菜单 - 新建 ETL，拖入要导出的表，再生成虚表定义。
2025-11-04 11:20:39
698
原创 DQL 超维分析 - 4 应用集成
配置完成后就可以启动 DQL 服务（润乾报表 [安装根目录]\report\bin 下：startDQLSERVER.bat / startDQLSERVER.sh）。每个目录代表一个 DQL 服务，从应用角度可以将 DQL 服务看成逻辑数据库，如这里的 datalogic，目录名就是服务名称。然后部署 service 目录。service 目录是 DQL Server 的主文件目录，可包含多个 DQL 服务。应用集成 DQL（JDBC）就可以访问 DQL 服务，这里需要先部署 DQL 服务。
2025-10-30 17:07:59
344
原创 DQL 超维分析 - 3 生成 DQL 元数据
我们可以一次性把这个数据库的表间关系都描述清楚，这样就能查询所有数据了。月和年都可以通过日期经过计算获得，这样月和年就都附加到日期字段上，我们想根据什么维度的年月层次查询就都可以了。表名可以修改，并设置每个表的主键。为每个有关联的表指定外键和关联字段，整个建模过程需要对数据结构熟悉的技术人员来完成。这里将签单日期、发货日期都与假表的日字段进行了关联，其他日期时间字段也同样处理。在菜单栏 新建 - 元数据，然后 导入数据库表，将要使用的表都导入。这里增加了日、月、年 三个假表，记住假表是单主键字段的逻辑表。
2025-10-29 11:27:09
181
原创 DQL 超维分析 - 2 DQL 概念和语法
前面说过，DQL 定义的 JOIN 都与主键有关，外键表、同维表、主子表都可以通过主外键关系来描述，这样我们就可以通过外键建立起各类表间关系，一次性把表间关系表述清楚以后就不用再动了，这就是 DQL 倡导的一次建模，也称为非按需建模（与宽表等按需建模相对）。有了假表，对于所有日期维度，就都可以按照假表定义的各种维度进行分析了，页面上看到的每个日期字段都有这些维度，很容易构建出下面的界面，使用非常清晰。前面的日期假表，也是通过外键与日期时间字段进行关联，每个字段都关联日期假表就能获得上面页面查询的效果。
2025-10-28 17:22:37
738
原创 DQL 超维分析 - 1 DQL 原理
把外键字段理解成维表的记录后，维表的字段就相当于外键的属性了，department.manager 即是“所属部门的经理”，而这个字段在 department 表中仍然是个外键，那么它对应的维表记录字段可以继续理解为它的属性，也就会有 department.manager.nationality，即“所属部门的经理的国籍”。这是很常规的表结构设计。同维表之间是对称的，两个表的地位相同。还要注意的是，说过外键关联是不对称的，即事实表和维表是不对等的，只能基于事实表去找维表字段，而不会有倒过来的情况。
2025-10-22 14:18:23
678
原创 2025 年 BI 产品选型：传统 BI、敏捷新贵还是破局产品？
如果追求集团级管控，且不计成本，传统 BI 可选。如果针对敏捷分析，且报表格式简单，敏捷 BI 也算是好工具。但如果想追求极致的性价比，方便集成和改造，实现随处可做灵活的 BI 分析且兼顾复杂报表，那么润乾 BI 无疑是当时市场上最具竞争力的解决方案。
2025-10-15 15:37:33
542
原创 报表没完没了做不完，可能并不是程序员的问题
项目中的报表开发没完没了达不到客户预期，以至于影响到合同收款——这种现象在软件公司经营过程中并不少见。出现类似状况时，管理者的第一反应往往是把板子打到开发团队身上。
2025-10-11 14:38:09
907
原创 难倒所有 BI 的“女经理的男员工”问题
这种多种关联的情况在企业数据系统中一点也不罕见，而且常常还会关联多层，这会导致途经的每一层表都有多种关联，还会形成圈状。如果是单表，那直接拖拽需要的字段就可以了，但遇到多表时，就要指定关联关系，这就超出许多业务人员的理解能力了。技术人员也没办法一次性把宽表做完善，就只能一次次改，所以，用宽表来做 BI 分析，就等于绑架了技术人员！这时候，BI 就晕掉了，不知道该用哪个关联，更不知道还要把员工表起个别名关联两次才能解决问题了。现在，大家应该都明白了，宽表要把关联信息都抄过来，表变得很宽，所以叫宽表。
2025-09-28 14:23:44
398
原创 DQL 超维分析课程
而且情况复杂时这个表可能要被重复关联，比如查询北京号码打给上海号码的通话记录，这个表就要被关联两次，这个表还会有维表也会被复制多次，如果维表还有维表…针对这个特性，将关联运算进行了分类，在此基础上发明了 DQL（Dimensional Query Language）一种基于维度的查询语言，从根本上解决 SQL 处理关联问题面临的困境，进而为 BI/ 灵活查询提供服务。而 SQL 对关联运算（JOIN）的定义很简单，两个表关联时，给出对应的关联字段就可以了，除此之外没有更多的信息和约定。
2025-09-26 13:51:44
685
原创 TOB 软件寒冬，三招减掉最隐形的那笔开支
用润乾的开源自助报表，把业务人员能做的表转出去，降低厂商人工成本，还提升了用户体验，回款更快了用专业的报表工具，高效制作复杂报表，省出不少人工成本，而且润乾报表本身也便宜，软件成本也可以省出很多用简易的数据准备脚本去代替大段的 SQL 和 JAVA，普通人员也能做好，释放更多更高级的工程师，又能大幅度降低人工成本润乾报表，帮 TOB 软件开发商把看的见的，看不见的成本都降下来了！
2025-09-23 14:54:09
665
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人