- 博客(402)
- 收藏
- 关注
RSS订阅
原创 数据分析编程 - 从入门到精通
在当今这个数据驱动的时代，数据分析已成为各行各业不可或缺的核心能力。从商业决策到科学研究，从金融预测到医疗健康，数据中蕴藏的洞见正在重塑我们的世界。然而，面对海量数据和复杂分析需求，传统的数据处理工具已显得力不从心，编程能力正逐渐成为数据分析师的必备技能。
2025-08-20 13:58:58
785
原创 DQL 超维分析
而且情况复杂时这个表可能要被重复关联，比如查询北京号码打给上海号码的通话记录，这个表就要被关联两次，这个表还会有维表也会被复制多次，如果维表还有维表…针对这个特性，将关联运算进行了分类，在此基础上发明了 DQL（Dimensional Query Language）一种基于维度的查询语言，从根本上解决 SQL 处理关联问题面临的困境，进而为 BI/ 灵活查询提供服务。而 SQL 对关联运算（JOIN）的定义很简单，两个表关联时，给出对应的关联字段就可以了，除此之外没有更多的信息和约定。
2025-08-01 15:11:34
663
原创 SPL轻量级文件存储提速查询实践
摘要：针对传统数据库在分析计算中的性能瓶颈，提出使用轻量级esProc SPL列存文件存储历史数据，结合其强大计算能力提升查询性能。该方案无需复杂集群，可直接嵌入应用，并提供了系列实践方法解决典型性能问题（如COUNT DISTINCT、外键关联等）。文中详细说明了测试环境配置、数据准备和SPL连接MySQL的示例代码，为突破数据库查询瓶颈提供了实用解决方案。
2025-07-15 14:18:55
485
原创 SPL 轻量级多源混算实践
摘要：本文介绍了使用esProc SPL实现多源数据混合计算的技术方案。针对当前异构数据源混合计算的技术难题，SPL通过统一数据对象转换和轻量化设计，提供了比传统逻辑数据仓库更灵活的解决方案。文章详细说明了SPL的原生连接器（支持RDB、本地文件等）和外部连接器（支持MongoDB、Kafka等）的架构，并规划了7个实践案例，涵盖从基础查询到跨库JOIN等复杂场景。环境准备部分提供了SPL、MySQL和MongoDB的安装指引，以及配套数据文件的下载链接。该方案特别强调SPL的语法简洁性和嵌入应用的能力，使
2025-07-14 16:50:38
558
原创 报表成本砍80%、开发效率翻倍：ToB寒冬破局关键
在当前经济寒冬与行业竞争加剧的背景下，企业愈发需要通过精细化管理成本与提升效率来维持竞争力，而报表环节存在的能力短板，往往迫使企业不得不持续投入人力来填补缺口，导致报表从本应赋能业务的“价值输出器”异化为吞噬利润的“成本黑洞”润乾报表则提供了全面的能力支撑，显著减少了因工具能力不足导致的无谓人力消耗，帮助客户走出“人工填坑”的循环，同时，其透明的采购模式彻底避免了按“装机量”计费带来的成本不确定性，从采购与开发两端协同降低总体投入。
2025-12-19 15:55:50
659
原创 让 BI 拥有‘领域大脑’：智能 BI 如何实现 AI 级精准数据查询
大模型因其概率本质难以担此重任，而润乾报表的 NLQ 组件通过规则引擎明确定义领域知识，是领域知识最完美的容器，从根本上确保了查询的准确性，让 AI 式数据查询从概念迈向实用，从而真正释放数据价值。对于能看懂代码的程序员来讲，这不是大问题。其实，无论用户输入怎样的问题，大模型永远都会给出一个结果，即使数据库中数据根本就无法计算这个任务目标，大模型也不会拒绝，不懂编程的业务用户根本没办法发现和纠正大模型的错误。实际上，大模型的本质是概率模型，它的训练目标是生成流畅、连贯的文本，而不是绝对精确的查询语句。
2025-12-15 16:17:06
862
原创 人人都能实施的智能问数，中小用户也能玩得转的 Text2SQL
AI 时代，到处都在说“智能问数”，用大白话直接问，数据就给你整得明明白白。理想很美好，可真要一探究竟，大家心里就打了鼓：这玩意儿是不是得养个 AI 科学家团队？是不是得买几十上百万的 GPU 服务器？查出来的数要是不准，谁敢拿来做决策？别急，润乾 NLQ 带来了一条不同的路——一条让中小企业、普通开发团队都能轻松上车、用得安心、花得明白的路。不依赖“黑盒”大模型去猜，而是用一套清晰的“规则翻译官”，把业务问题，精准无误地转换成数据库能听懂的指令。
2025-12-12 16:53:46
604
原创 工业 AI 监盘发现异常实践
基于以上实践，我们自研的工业 AI 监盘异常发现算法已在多种工业场景中得到有效验证。该算法立足于“异常即罕见”的核心思想，借助动态分布建模与多维度联合分析，实现了在无标注条件下的高精度异常识别。其主要优势可总结如下：1. 完全无监督，无需标注数据算法基于设备正常运行状态下数据模式相对稳定的假设，通过对历史数据分布的自主学习，自动识别偏离该分布的异常点，彻底摆脱了对人工标注数据的依赖，极大降低了实施成本与数据准备周期。2. 高实时性与低资源消耗。
2025-12-08 14:29:21
781
原创 Text2SQL 破局技术解析之二：MQL 实现与复杂性
在基于 "规范文本" 的 NLQ 架构中，MQL（Metrics Query Language）作为规范文本的确定性编译目标，承担着关键使命。本文作为 "规范文本" 篇的延续，将继续解析 MQL 的设计逻辑及其实现机制。
2025-12-03 14:07:22
951
原创 万字长文解析 NLQ 破局 Text2SQL，值得收藏
润乾 NLQ 技术已解析完毕。我们从“规范文本”破局，用“MQL”实现复杂性，继而用“NLQ 词典”保证准确性。三者环环相扣，共同构成了一个同时满足灵活性、准确性、复杂性的 Text2SQL 架构。
2025-11-28 13:56:25
740
原创 Text2SQL 破局技术解析之一：规范文本与灵活性
自然语言转 SQL（Text2SQL）技术旨在降低数据查询的技术门槛，但一直面临 "灵活性"、"准确性" 与 "查询复杂性" 难以兼顾的技术困境。直接由大语言模型生成 SQL 存在语义 "幻觉" 会带来准确性问题，引入结构化中间层通过牺牲查询复杂性换来准确性的有限提升，仍然难以满足企业级 BI 场景的需求。润乾 NLQ 技术采用 "规范文本" 作为中间层，构建人机均可理解的中介语言，将不确定性限制在自然语言理解阶段，并通过。
2025-11-24 17:16:35
463
原创 AI 现在都这么强大了，为什么 chatBI 还像是个玩具？
NLQ 组件能做到像 chatBI 一样“好玩易用”，同时还避免了其“不可靠”的缺陷，让 AI 式数据查询告别“玩具”阶段，进入真正的商业应用场景。无论用户输入怎样的问题，大模型永远都会给出一个结果，即使数据库中数据根本就无法计算这个任务目标，大模型也不会拒绝，不懂编程的业务用户根本没办法发现和纠正大模型的错误。面对 chatBI 的这些局限，润乾报表团队基于多年 BI 领域的技术积累，推出了全新的 NLQ（自然语言查询）组件，能让 AI 式数据查询从“能玩的玩具”变成“好用的工具”。
2025-11-18 10:39:09
307
原创 另辟蹊径的 Text2SQL，不用大模型也能搞 chatBI
随着 AI 大模型的技术突破，用自然语言与数据进行对话的 ChatBI 概念也变得火热起来，人们普遍认为这件事终于具备了可行性。于是，业界很自然地沿着大模型（LLM）这条技术路线进行探索，期待它能理解业务人员的随意提问并直接返回数据结果。然而，理想很丰满，现实却有点骨感：LLM 方案始终存在“幻觉”问题，而且成本高昂、部署与调优过程也相当复杂。我们注意到，在 BI 这个特定场景下，业务人员用于查询数据的自然语言，其实并没有日常对话那么随意和复杂。
2025-11-11 11:02:04
916
原创 AI 提效报表困难SQL开发？不好说，但SPL肯定可以
对于难题以及新题，更有效的做法是用简单的 SQL 取数，再用 SPL 实现业务逻辑。SQL 难以解读，还是 SQL 本身的原因，不符合自然思维，缺乏过程性，通常要用多层的嵌套结构，需要积累多年的 "秘密小技巧"，编码思路与现代编程语言格格不入，也比现代编程语言更难解读。用 stackoverflow 上的 SQL 问题对 AI 提问，会发现一个似乎是意料之外的现象：对于有一定年头的旧题通常能给出较满意的答复，但对新出现的问题往往会乱答一气，问题越新，答案就越乱，很多问题难度并不高，AI 给出的答案也不对。
2025-11-10 15:05:09
1014
原创 5 个 JOIN vs 1 行 DQL：维度查询语言的降维打击
江湖之中，凡我辈数据库修习者，谁不曾拆解过数百存储过程，优化过万行 SQL 脚本？然则，当你面对接连五个 JOIN，而业务方仍在追问“可否再添一维”时，可曾感到一股内力滞涩，呼吸为之一窒？
2025-11-06 15:21:34
822
原创 DQL 超维分析 - 5 集算器 DQL
虚表是定义在数据文件（组表）上的逻辑表，由于组表具有更高的 IO 性能、更高效的存储方式，创建虚表时可以根据组表特性进行设置。比如为内存表建立索引，使用枚举 / 二值维度等。在工具栏中选择“增加虚表”，选择对应的组表文件虚表就创建完成了。虚表名会根据组表文件名命名，其中的主键信息也会随组表设置。虚表定义也可以通过集算器 ETL 工具生成，在将数据表转储成 CTX 的同时生成虚表定义。在 ETL 工具菜单 - 新建 ETL，拖入要导出的表，再生成虚表定义。
2025-11-04 11:20:39
678
原创 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
323
原创 DQL 超维分析 - 3 生成 DQL 元数据
我们可以一次性把这个数据库的表间关系都描述清楚，这样就能查询所有数据了。月和年都可以通过日期经过计算获得，这样月和年就都附加到日期字段上，我们想根据什么维度的年月层次查询就都可以了。表名可以修改，并设置每个表的主键。为每个有关联的表指定外键和关联字段，整个建模过程需要对数据结构熟悉的技术人员来完成。这里将签单日期、发货日期都与假表的日字段进行了关联，其他日期时间字段也同样处理。在菜单栏 新建 - 元数据，然后 导入数据库表，将要使用的表都导入。这里增加了日、月、年 三个假表，记住假表是单主键字段的逻辑表。
2025-10-29 11:27:09
166
原创 DQL 超维分析 - 2 DQL 概念和语法
前面说过，DQL 定义的 JOIN 都与主键有关，外键表、同维表、主子表都可以通过主外键关系来描述，这样我们就可以通过外键建立起各类表间关系，一次性把表间关系表述清楚以后就不用再动了，这就是 DQL 倡导的一次建模，也称为非按需建模（与宽表等按需建模相对）。有了假表，对于所有日期维度，就都可以按照假表定义的各种维度进行分析了，页面上看到的每个日期字段都有这些维度，很容易构建出下面的界面，使用非常清晰。前面的日期假表，也是通过外键与日期时间字段进行关联，每个字段都关联日期假表就能获得上面页面查询的效果。
2025-10-28 17:22:37
720
原创 DQL 超维分析 - 1 DQL 原理
把外键字段理解成维表的记录后，维表的字段就相当于外键的属性了，department.manager 即是“所属部门的经理”，而这个字段在 department 表中仍然是个外键，那么它对应的维表记录字段可以继续理解为它的属性，也就会有 department.manager.nationality，即“所属部门的经理的国籍”。这是很常规的表结构设计。同维表之间是对称的，两个表的地位相同。还要注意的是，说过外键关联是不对称的，即事实表和维表是不对等的，只能基于事实表去找维表字段，而不会有倒过来的情况。
2025-10-22 14:18:23
652
原创 2025 年 BI 产品选型：传统 BI、敏捷新贵还是破局产品？
如果追求集团级管控，且不计成本，传统 BI 可选。如果针对敏捷分析，且报表格式简单，敏捷 BI 也算是好工具。但如果想追求极致的性价比，方便集成和改造，实现随处可做灵活的 BI 分析且兼顾复杂报表，那么润乾 BI 无疑是当时市场上最具竞争力的解决方案。
2025-10-15 15:37:33
513
原创 报表没完没了做不完，可能并不是程序员的问题
项目中的报表开发没完没了达不到客户预期，以至于影响到合同收款——这种现象在软件公司经营过程中并不少见。出现类似状况时，管理者的第一反应往往是把板子打到开发团队身上。
2025-10-11 14:38:09
881
原创 难倒所有 BI 的“女经理的男员工”问题
这种多种关联的情况在企业数据系统中一点也不罕见，而且常常还会关联多层，这会导致途经的每一层表都有多种关联，还会形成圈状。如果是单表，那直接拖拽需要的字段就可以了，但遇到多表时，就要指定关联关系，这就超出许多业务人员的理解能力了。技术人员也没办法一次性把宽表做完善，就只能一次次改，所以，用宽表来做 BI 分析，就等于绑架了技术人员！这时候，BI 就晕掉了，不知道该用哪个关联，更不知道还要把员工表起个别名关联两次才能解决问题了。现在，大家应该都明白了，宽表要把关联信息都抄过来，表变得很宽，所以叫宽表。
2025-09-28 14:23:44
381
原创 DQL 超维分析课程
而且情况复杂时这个表可能要被重复关联，比如查询北京号码打给上海号码的通话记录，这个表就要被关联两次，这个表还会有维表也会被复制多次，如果维表还有维表…针对这个特性，将关联运算进行了分类，在此基础上发明了 DQL（Dimensional Query Language）一种基于维度的查询语言，从根本上解决 SQL 处理关联问题面临的困境，进而为 BI/ 灵活查询提供服务。而 SQL 对关联运算（JOIN）的定义很简单，两个表关联时，给出对应的关联字段就可以了，除此之外没有更多的信息和约定。
2025-09-26 13:51:44
666
原创 TOB 软件寒冬，三招减掉最隐形的那笔开支
用润乾的开源自助报表，把业务人员能做的表转出去，降低厂商人工成本，还提升了用户体验，回款更快了用专业的报表工具，高效制作复杂报表，省出不少人工成本，而且润乾报表本身也便宜，软件成本也可以省出很多用简易的数据准备脚本去代替大段的 SQL 和 JAVA，普通人员也能做好，释放更多更高级的工程师，又能大幅度降低人工成本润乾报表，帮 TOB 软件开发商把看的见的，看不见的成本都降下来了！
2025-09-23 14:54:09
642
原创 Micronaut 集成 SPL 实现微服务
通过本案例可以看出，将SPL融入Micronaut微服务架构，能够有效解决传统Java微服务在复杂业务逻辑处理方面的诸多痛点。得益于SPL的解释执行特性，业务计算逻辑可以实现热更新，无需重启服务即可动态调整计算规则，极大提升了系统的灵活性与运维效率。相比之下，传统Java实现将规则硬编码于服务中，任何调整都需重新编译和部署，导致开发成本高、响应周期长，不利于快速变化的业务场景。
2025-09-19 11:17:53
920
原创 为什么一直没啥好用的开源 BI
润乾开源 BI 的出现，不仅弥补了国内开源 BI 的空白，更好改造，更适合国人使用，也更安全，功能也完胜国外开源 BI，甚至超越商用 BI，有需要的同学可以去试试了，免费开源的产品，也有完善的服务体系以及全面的教程培训哦~基本每个页面都得改，但语言不同，修改的难度就会倍增，而且文档也是英文的，又不全面，也会增加修改的难度，每个用户的需求也都不同，就得每个用户都改一次，人工成本就会多出很多。几十万的商用 BI 有的功能，润乾 BI 全都有，列表、分组、交叉，还有各种旋转、切片、下钻、上卷等都支持。
2025-09-16 16:00:41
249
原创 用 SPL 编写阿里云 FC2.0 函数
在数字化转型持续加速的背景下，企业越来越多地将业务逻辑以服务化方式部署至云端。阿里云函数计算（Function Compute，简称FC）作为一种无服务器计算平台，屏蔽了底层资源运维的复杂性，使开发者能够专注于核心逻辑的开发与交付。只需上传代码，即可通过HTTP请求或事件驱动灵活触发函数执行，实现弹性伸缩、按需计费的函数式计算能力。在实际应用中，函数计算往往需要处理复杂的数据处理任务，如多源数据的汇聚、清洗与分析。
2025-09-04 16:48:35
919
原创 数据分析编程第八步：文本处理
情感词典 sentiment_lexicon.csv字段名含义Word单词情感打分，正面情绪最高 5 分，负面情绪最低 -5 分。
2025-09-01 14:59:09
914
原创 数据分析编程第七步：分析与预测
利用历史销售数据统计月销售额，计算季节化因子，获取去季节化销售数据，然后进行线性拟合，最后预测接下来的某个月的销售额。第一步：读数，统计月销售额A2 month(orderDate) 中选项表示返回的是这样格式的数据第二步：统计月销售额的总均值第三步：计算去季节化因子A4 YMonth100 表示 YMonth 除以 100 的余数，这样返回的就是 MM 这样格式的整数，按这样的月份数据分组汇总，可以分别统计 1 月的均值、2 月的均值……，用当前月份的均值除以 A3(总均值)，即可获得当前月份的季节因子。
2025-08-29 14:22:29
1085
1
原创 数据分析编程第六步：大数据运算
直接打开集算器运行 createEventsAndUsers.splx 文件，就可以得到如下两张表（也可以根据代码中的注释，修改起止日期以及每天的数据量）：电商数据表 events.csv字段名含义eventID事件编号, 从 1 开始流水号userID用户编号eTime事件的发生时间eType事件类型，取值 login,viewProduct,placeOrder,completePayment。
2025-08-29 14:20:13
1223
原创 数据分析编程第五步：数据准备与整理
列名含义productID产品 ID成本价listPrice列表价产品描述product.csv 和前面章节介绍过的销售数据表 sales.csv 的关系图：列名含义orderID订单 ID服务期限服务类型联系人联系电话服务授权号。
2025-08-27 14:08:53
1137
原创 数据分析编程第四步：时间统计
打开集算器，直接运行 createOrders.splx，即可得到如下数据表：列名含义orderID订单号userID用户 IDorderTime订单时间amount订单金额此表包含 2022-2024 年共三年的商超订单记录，共计 600 万条，由于字段数少，一般的笔记本电脑均能全内存装下，因此本章依旧按全内存计算来介绍算法。
2025-08-26 14:20:40
919
原创 数据分析编程第三步：分组统计
这里需要强调的是，当分组不是按字段而是表达式时，可以直接用表达式分组，并不需要先用 derive 给序表添加计算列，如本例中的。将上例中每年排名前三的销售数据按销售、年份排序，然后进行计数累加，如果是同一个销售且年份递加 1，则累加值加 1，否则从 1 重新计数，最后从结果中选出累加值等于 3 的记录。第二步：添加计算列，从 1 开始计数，如果当前行的销售和上一行的销售相等且当年行的年份等于上一行的年份加 1，则计数值加 1，否则从 1 开始重新计数。这里 if 函数的参数规则和前面介绍过的不太一致，
2025-08-25 14:18:13
895
1
原创 数据分析编程第二步： 最简单的数据分析尝试
第一行是标题，解释每一列存了什么东西。第二行开始每一行是一条数据，对应一个订单。这种数据有个专业的术语，叫结构化数据。这是现代数据处理中最常见的数据类型。整个表格的数据统称为一个数据表，其中的每一行（除了标题）称为一条记录，列称为字段，标题中的字符串称为字段名。上面这个表中能看见的部分有 12 条记录，对应着这个 Excel 的第 2 到第 13 行；
2025-08-22 15:24:28
888
原创 1. 准备工作---数据分析编程 - 从入门到精通
SPL 中可以在单元格里展现 =[A1:B4] 这样的数据集合，且该数据集合是有次序的，上图红框里的 Index 列就是数据的序号，在 SPL 中将这样有序的数据集合称为。在 SPL 的网格界面中，每个单元格的代码和计算结果可以同时呈现。SPL 的网格式编程重新定义了数据处理的体验，将编程的精确性与电子表格的直观性完美结合，为您提供了一种更高效、更可控的数据计算解决方案。：在网格中，每个单元格右侧会直接显示该单元格的计算结果，包括标量值、表格数据或图形输出，可以一目了然地掌握每个计算步骤的输出状态。
2025-08-21 14:36:48
1048
原创 编程实现--当年销售额占到一半的前 n 个客户
将合同表按客户分组，算出每个客户的总金额并按其降序排列，而后算出总销售额的一半值，最后扫描这个表，途中不断累积销售额，直至达到一半销售额，之前的客户就是“大客户”了。A5先定义累计销售额a的初始值为0，half为全部客户销售总额的一半，然后对A4的结果查找，同时累计销售总额，直至累计总额刚好超过全部总和的一半。某年内按销售额排名的客户，达到一半销售额的前 n 个客户称为该年的“大客户”，请列出 1998 年该企业的大客户名单。A3做外键关联，将合同表的客户字段替换成客户记录，以便于查找客户的名称。
2025-08-19 15:31:29
348
原创 用编程---征婚匹配
Romeo（罗密欧）是一个 NS GSOH M Veronian（不抽烟，生活在维罗纳，很有幽默感的男性）。根据Juliet（朱丽叶）的WLTM（Would like to meet）条件判断，Romeo 适合吗？SPL中，用A.pos(B)!=null可以判断在两个序列中判断A是否包含B中的所有成员。A1读出每个人的个性特征，A2读出他们的需求条件。请找出所有符合 Juliet 的要求的征婚者。
2025-08-18 15:17:44
390
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人