smilejingwei的博客

MYSQL 数据库中，订单表 orders 存储了 2024 年全年订单，主键是订单号 oid，字段有客户号 cid，日期 odate，数据量一千万。注意 A6 中 create 函数增加了 @p 选项，这是因为子表 details 中的关联字段 oid 值并不是唯一的，@p 表示第一个字段 oid 是分段键，这样可以防止分段读取时，把一个 oid 的明细记录拆分开。A3 把 7 号产品的订单明细，按照 oid 有序分组，每组只保留第一个 oid，这样不用生成分组子集，性能更好。

现在要将所有的重复值改成 null，换句话说，按前 2 个字段分组后（等价于按其中 1 个字段分组），只保留组内第一条不变，其他记录的前两个字段改成 null。A2：用 run 函数修改各组数据，当成员在组内的序号大于 1 时，将前两个字段改为 null。~ 表示当前组，# 表示组内序号。SQL分组后必须立刻汇总，不能保持分组子集继续计算，也没有天然的组内行号，代码比较难写。某库表的前两个字段会同时出现重复值，比如下面的前 3 条记录。每组是一个集合，可以通过点击展开，如图是前两组。

数据量大或者数据库繁忙都会导致数据库查询变慢，这时将数据用 esProc 导出存成文件再计算可以大幅提升性能。

某些数据库 SQL 缺失必要的能力，通常要编写大段的代码，才能间接实现类似的功能，有些情况甚至要改用存储过程，连结构都变了。先在 IDE 中打开例子 2 的脚本文件，选中有代码的单元格 A1-A3，再点击菜单 "Edit->Copy->Code copy"，这样就把多行多列的网格代码转成了单行的 SPL 代码，暂存在粘贴板里。如果缺少某窗口的数据，则用前一个窗口的最后一条代替。现在要找出每个账号下符合条件的一对事件，分别是：日期最早的事件 a、距 a 事件 30 天以上的事件中日期最早的事件 b。

这里只是以一个简单的分组汇总来说明 esProc 在 Java 应用中完成冷热混算的过程，esProc 的计算能力还远不止于此，尤其擅长复杂计算。任何数据源对 esProc 都是等同的，只要能访问到就能混算，同构异构都可以，这就意味着冷数据可以采用任意存储（比如文件系统）通过 esProc 都能实现冷热数据混算。esProc 是个不依赖数据库的计算引擎，支持各种数据源，有丰富的计算类库，还能嵌入 Java 使用，天然适合在应用中做冷热数据库混合计算。安装后，配下数据库连接，这里以 MySQL 为例。

先在 IDE 中打开脚本文件，选中有代码的单元格 A1-B3，再点击菜单 "Edit->Copy->Code copy"，这样就把多行多列的网格代码转成了单行的 SPL 代码，暂存在粘贴板里。esProc 支持的数据源非常丰富，除了 RDB，还有 NoSQL、BigData、云存储、消息队列、本地文件，都可以混合运算，感兴趣的可以去乾学院了解更多。上面代码把数据取到内存后再关联，适合数据量较小的情况，如果数据量较大，应该在 SQL 里排序，再一边取数一边进行关联计算，也就是归并关联。

今天，企业的数据来源已经从原来的“就几张表”发展到数据库、文件、接口、流式数据、对象存储、NoSQL……五花八门。能不能搞定“多数据源混算”，已经成了数据计算技术的重要标准之一。说起多源混算，“逻辑数据仓库”大概是最主流的做法了。而且听起来很美：不用提前同步数据、不用折腾传统 ETL，还能用 SQL 跨库查询。但理想丰满，现实骨感。这些逻辑数仓，以为能连天接地，真落地用的时候，发现不过是支持几个主流关系库、几个文件格式，稍微冷门一点的数据源立马就抓瞎。想搞点跨源混算？

小结一下，SQL 把关联运算都定义成笛卡尔积再过滤，看似简单，但没有体现关联运算的本质，复杂情况不易理解，还容易出错，而且关联结果不能复用。Python 的关联运算基本上延用了 SQL 方式，略有优势之处是关联结果可复用了，但这个结果是个宽表，很不灵活，继续做其他计算会很麻烦，也容易出错。但是，这些订单中其他产品的金额也被过滤掉了，结果当然是错的。但是，Python 的关联结果 merged 是两个表字段拼接成的宽表，灵活性较差，用来简单分组汇总没问题，但需求稍复杂些，继续计算就变得麻烦了。

Python 支持有序集合，实现相邻成员引用的优势要大得多，但仍有语法不一致问题，根据情况选择不同的函数，有时还要反转集合。比如这里，数据若按月份有序，只要用当前成员减去上一个成员，差值就是月增长额。rolling 创建了大小为 2 的窗口，apply 函数操作会作用于 sales 序列中相邻的两个成员，可以利用 lambda 求这两个成员的差。~ 表示当前成员，# 是当前成员的序号，~[i] 表示和当前成员距离为 i 的成员，这里的 ~[-1] 表示前一个成员，也就是上月销售额。

SPL 表的字段可以是表，嵌套结构从上到下的数据组织都一致，都是对象，引用方法也一致，计算代码简洁、易懂，是最专业的多层嵌套结构计算语言。在稍复杂的情况下，DuckDB 和 Python 的语法不一致等问题带来的麻烦会更明显，比如找出总金额大于 200，而且还包含 Electronics 类产品的订单，取得 order_id、order_date。先纵向展开 order_details，再横向展开每行的字段，变成平面表后，再计算分组汇总，这也很绕。计算时，无论哪一层的表（记录），都是对象，都能一致运算。

这些数据有些只是临时用一下，如果每次都需要装进数据库才能使用，不仅会占用数据库的空间，ETL 过程也需要消耗大量时间，数据库通常还有约束，有些不符合规范的数据无法写入，这就需要先花时间精力整理数据；虽然实现上并没有复杂太多，但此时大部分数据库的优化引擎就会犯晕了，猜不出这句 SQL 的目的，只能老老实实地执行按语句书写的逻辑去执行排序（这个语句中还是有 ORDER BY 的字样），结果性能陡降。Python 的并行是假的，想要利用多 CPU，还得用复杂的多进程并行，这超出了大部分数据科学家的能力范围。

不过问题也不大，窗口函数写起来本来也很繁琐，esProc 的原生 SPL 语法要来比窗口函数简单多了，也就没太大必要再支持窗口函数了。除了文本文件，esProc 的 SQL 还支持 XLS\MongoDB\restful json 等数据源，用法都差不多，感兴趣者可移步乾学院。esProc SPL 支持简单 SQL，可以直接在 csv 等结构化文本文件上执行 SQL 语句，这样，不用数据库也可以用 SQL 计算了。} 是 SPL 原生语法，表示读取文本文件，没有标题行，分隔符是逗号。

数据处理上，esProc 除了 SQL 语法还有 SPL，能应对更多复杂情况，一个体系就能搞定，不存在 SQL 和 Python 两个体系的割裂，尤其对 JSON 类多层数据的处理，SPL 更简单直观。esProc 使用数据源 Native 接口，所有关系库都可以用 JDBC 连接，能天然支持，而其他诸如 MongoDB、Kafka 等数据源也都是基于 Native 接口做简单封装即可，开发速度很高，因而提供了更丰富的 Connetor 库。简单情况用 SQL 查，复杂情况用 SPL，二者还可以混用。

B1中的枚举结果，如果不想手动去写，也可以类似写为=4.conj@r(4.(4.(4.([~,get(1),get(2),get(3)]).select(~.icount()==4).(~.concat()))))，与C1不同的是，需要选出用到了所有4张牌，即每张牌都只用1次的排列方案。对于给定了顺序和符号的一种组合：a#b#c#d，根据不同的运算顺序，有5种情况，分别用括号表示如下：a#(b#(c#d))，a#((b#c)#d)，(a#b)#(c#d)，((a#b)#c#d和(a#(b#c))#d。

比如数据分析师常用的 SQL 和 Python，都具有较强的计算能力，可以一定程度应对复杂的数据运算，满足分析过程中的计算需求。实施探索分析时，计算能力和交互性不可偏废——既要强大的计算能力支持复杂运算，又要足够的交互性来实现随时调整、随时反馈的分析过程，而强计算还能简化复杂运算，即用更简单的办法实现计算目标。SPL 还提供了 XLL 插件，用户可以在熟悉的 Excel 环境中，利用 SPL 强计算能力，在 Excel 内直接写 SPL 公式，同时发挥 SPL 和 Excel 优势。

分组是常见的结构化数据计算，SQL 和 Python 都有相应的语句和函数来处理。不过，和 esProc SPL 提供的分组运算相比，这些语言都弱得多了。和 SQL 差不多。

A3：过滤每组数据，先找到 ConfirmationStarted 之前的记录，再从中过滤出 Closed，取倒数第 1 条。函数 select 用于条件过滤，过滤时支持与位置相关的计算，@c 表示从第一个使条件为真的记录开始取，直到遇到使条件为假的记录时停止，@1 表示取结果的第 1 条，@z 表示从后往前过滤。现在要在每个 ID 里，找到 ConfirmationStarted 之前的所有的 Closed 中，离 ConfirmationStarted 最近的那条记录，取出记录的 ID 和时间字段。

但是可惜的是大部分编程语言在解决 Excel 缺点的同时，也丧失了 Excel 的两大优点，容易上手和交互性强。作为编程语言，SPL 的格值比 Excel 要更丰富，除了可以是单值外，还可以是一组值如 [3,5,7,8]，也可以是一个表，比如前面班级成绩单的例子，如下图，A1 的结果就是一张表，SPL 里叫做序表。Excel 在面对 10 万以上的数据量时就会很卡，SPL 不存在这个问题，10 万、百万的数据都能跑的很顺畅，还提供简易的游标运算，可以用流式读取数据，这样无论多大的数据量都能处理了。

在现代商业环境中，数据分析已成为企业决策的重要工具。通过数据分析，企业可以更好地了解市场趋势、客户行为以及内部运营情况，从而制定出更科学的策略，提高竞争力。然而，数据分析并不是一项简单的任务，需要选择合适的工具和方法。很多人认为 BI 软件是数据分析的首选，因为 Business Intelligence 这个词听上去和数据分析的关系很密切，而且 BI 软件通常具有流畅的交互性和炫丽的界面，看上去很适合做这项工作。然而，BI 工具在技术上已经被狭义化成多维分析，主要用于基于预设的数据立方体的汇总和展示。