- 博客(262)
- 收藏
- 关注
RSS订阅原创 如何用 esProc 实现 Oracle 和 MySQL 的混合运算
先在 IDE 中打开脚本文件，选中有代码的单元格 A1-B3，再点击菜单 "Edit->Copy->Code copy"，这样就把多行多列的网格代码转成了单行的 SPL 代码，暂存在粘贴板里。esProc 支持的数据源非常丰富，除了 RDB，还有 NoSQL、BigData、云存储、消息队列、本地文件，都可以混合运算，感兴趣的可以去乾学院了解更多。上面代码把数据取到内存后再关联，适合数据量较小的情况，如果数据量较大，应该在 SQL 里排序，再一边取数一边进行关联计算，也就是归并关联。
2025-04-10 16:21:49
267
原创 这可能是支持数据源最多的计算技术
今天，企业的数据来源已经从原来的“就几张表”发展到数据库、文件、接口、流式数据、对象存储、NoSQL……五花八门。能不能搞定“多数据源混算”，已经成了数据计算技术的重要标准之一。说起多源混算，“逻辑数据仓库”大概是最主流的做法了。而且听起来很美：不用提前同步数据、不用折腾传统 ETL，还能用 SQL 跨库查询。但理想丰满，现实骨感。这些逻辑数仓，以为能连天接地，真落地用的时候，发现不过是支持几个主流关系库、几个文件格式，稍微冷门一点的数据源立马就抓瞎。想搞点跨源混算？
2025-04-07 17:00:39
738
原创 这样理解关联是不是耳目一新
小结一下，SQL 把关联运算都定义成笛卡尔积再过滤，看似简单，但没有体现关联运算的本质，复杂情况不易理解，还容易出错，而且关联结果不能复用。Python 的关联运算基本上延用了 SQL 方式，略有优势之处是关联结果可复用了，但这个结果是个宽表，很不灵活，继续做其他计算会很麻烦，也容易出错。但是，这些订单中其他产品的金额也被过滤掉了，结果当然是错的。但是，Python 的关联结果 merged 是两个表字段拼接成的宽表，灵活性较差，用来简单分组汇总没问题，但需求稍复杂些，继续计算就变得麻烦了。
2025-04-03 17:25:39
815
原创 不可或缺的相邻引用
Python 支持有序集合，实现相邻成员引用的优势要大得多，但仍有语法不一致问题，根据情况选择不同的函数，有时还要反转集合。比如这里，数据若按月份有序，只要用当前成员减去上一个成员，差值就是月增长额。rolling 创建了大小为 2 的窗口，apply 函数操作会作用于 sales 序列中相邻的两个成员，可以利用 lambda 求这两个成员的差。~ 表示当前成员，# 是当前成员的序号，~[i] 表示和当前成员距离为 i 的成员，这里的 ~[-1] 表示前一个成员，也就是上月销售额。
2025-04-02 16:02:22
714
原创 计算路由提升并发能力：SPL 实践
这样，前端提交的 SQL 语句有了统一的入口，可以很方便的将计算路由规则，写在这个 SPL 脚本中。或者写在其他脚本中，由这个脚本调用。希望改成最近 1 天的数据常驻内存，最近 2 到 4 天的存储在本地磁盘，最近一个月的存储在独立的 SPL 服务器上，其他数据还存放在后台数据库中。上线后，用调度工具每天晚间从数据库中导出当天的订单数据到文本文件中，再调用 SPL 的 ETL 代码，转换为 SPL 组表。实际应用中，计算路由的规则可能会很复杂和多变，通过配置来实现会非常困难，用编程的方式实现是最佳方案。
2025-04-01 17:39:40
622
原创 搞多层 json，SPL 才是专业的
SPL 表的字段可以是表，嵌套结构从上到下的数据组织都一致，都是对象，引用方法也一致，计算代码简洁、易懂，是最专业的多层嵌套结构计算语言。在稍复杂的情况下，DuckDB 和 Python 的语法不一致等问题带来的麻烦会更明显，比如找出总金额大于 200，而且还包含 Electronics 类产品的订单，取得 order_id、order_date。先纵向展开 order_details，再横向展开每行的字段，变成平面表后，再计算分组汇总，这也很绕。计算时，无论哪一层的表（记录），都是对象，都能一致运算。
2025-03-28 14:22:28
493
原创 海量灵活结构数据查询：SPL 实践
所有字段通常能分成为两部分，一部分是所有记录的共同字段，另一部分是各自不同的字段，其总数量可能多达数百种，但每条记录只占少数几种。本质上，这两个例子描述的数据结构，在逻辑上可以看作是一张大宽表，但是当属性和分类过多时，这张表的字段就会有几千列（共同字段 + 所有可能的属性 * 分类）。A5是个条件表达式，j将多序列字段合成一个序表，然后count出每条记录满足条件的个数，当数量与提的条件相等，说明这条记录需要被取出。（这里是篮球、足球）；所以，在用附表时，先只用条件相关的字段取出主键再找，很可能是更快的。
2025-03-26 15:14:39
891
原创 SQL写跑批要2小时，换SPL17分钟跑完：高性能代码的本质是数学！
但是，当运算任务足够复杂时，碰到几百上千行的嵌套 N 层 SQL（慢的 SQL 通常也不会太简单），几乎总能找到足够多可优化的环节，所以我们经历过的案子还没有失手过。这些被提速的场景都有一个共同点：原先都是用各种数据库（也有 HADOOP/Spark）上的 SQL 实现的，包括查询用的几百行 SQL 也有跑批用的几千行存储过程，然后我们改用集算器的 SPL 重新实现之后就有了这样的效果。而 SQL 却不可以。要读懂原来的逻辑重新实现，这个工作量还是很大的，不过能换来数倍数十倍的性能提升，常常还是值得的。
2025-03-24 16:44:05
894
原创 还在用SQL/Python折磨团队？顶尖数据科学家都在偷偷换装esProc
这些数据有些只是临时用一下，如果每次都需要装进数据库才能使用，不仅会占用数据库的空间，ETL 过程也需要消耗大量时间，数据库通常还有约束，有些不符合规范的数据无法写入，这就需要先花时间精力整理数据；虽然实现上并没有复杂太多，但此时大部分数据库的优化引擎就会犯晕了，猜不出这句 SQL 的目的，只能老老实实地执行按语句书写的逻辑去执行排序（这个语句中还是有 ORDER BY 的字样），结果性能陡降。Python 的并行是假的，想要利用多 CPU，还得用复杂的多进程并行，这超出了大部分数据科学家的能力范围。
2025-03-19 14:43:09
931
原创 漏斗分析：SPL 实践
电商业务中漏斗分析是常见的统计需求。用户使用智能设备购物时，系统会建立连接形成会话 session。每个会话又包含很多个操作事件 event，比如：访问（visit）类事件，浏览（view）类事件，详情页（detail）类事件等等。每个用户的操作事件，按照发生时间（简称事件时间）有一定的先后顺序。事件顺序越靠后，完成该事件的用户数量越少，就像是一个漏斗。漏斗转化分析先要统计各步骤操作事件的去重用户数量，在此基础上再进一步计算转化率等等。以三步漏斗为例，三个事件类型是访问，浏览，详情页。
2025-03-18 15:50:59
551
原创 告别数据库束缚！用esProc在 csv 文件上执行 SQL
不过问题也不大，窗口函数写起来本来也很繁琐，esProc 的原生 SPL 语法要来比窗口函数简单多了，也就没太大必要再支持窗口函数了。除了文本文件，esProc 的 SQL 还支持 XLS\MongoDB\restful json 等数据源，用法都差不多，感兴趣者可移步乾学院。esProc SPL 支持简单 SQL，可以直接在 csv 等结构化文本文件上执行 SQL 语句，这样，不用数据库也可以用 SQL 计算了。} 是 SPL 原生语法，表示读取文本文件，没有标题行，分隔符是逗号。
2025-03-17 16:17:24
342
原创 esProc SPL vs DuckDB：多源数据处理谁更胜一筹？
数据处理上，esProc 除了 SQL 语法还有 SPL，能应对更多复杂情况，一个体系就能搞定，不存在 SQL 和 Python 两个体系的割裂，尤其对 JSON 类多层数据的处理，SPL 更简单直观。esProc 使用数据源 Native 接口，所有关系库都可以用 JDBC 连接，能天然支持，而其他诸如 MongoDB、Kafka 等数据源也都是基于 Native 接口做简单封装即可，开发速度很高，因而提供了更丰富的 Connetor 库。简单情况用 SQL 查，复杂情况用 SPL，二者还可以混用。
2025-03-14 14:07:05
571
原创 客户画像:SPL 实践
IN 计算的性能较差，主要由于其中有太多的比较运算。对替换后的新数据做 IN 判断时，先要生成一个与列表等长的布尔值集合，其第 i 个值由列表的第 i 个成员是否在 IN 字段的值集合中决定，在其中就是 true，不在就是 false。这里可以看到客群号集合、枚举值集合中成员的个数都是可扩展的，比如三个或更多客群交集，只要增加字符串中逗号分隔的成员就可以了。SPL 提供了虚表对象，可以将组合二值标签的运算透明化，程序员可以继续操作单个的标签字段，实际上会被 SPL 转换成 16 位整数的某些位。
2025-03-13 15:51:57
521
原创 SPL 量化 获取数据
按上面例子，股价从 10 元变为 2 元，向前复权时，会维持今天的股价不变，而把昨天的股价由 10 元变成 2 元与当前价格保持一致，之前的股价也都一律按比例缩小，股价变为一条连续的曲线。日 K 线数据里，pfactor 为复权因子。需要注意的是：该复权因子为当日复权因子，而不是累计复权因子，这样的好处是更方便随意指定一个时间区间计算出和该区间相关的复权价格。发生拆股后，持有的 100 股变为 500 股，但是股价也会自动调整为原来的 1/5，变为 2 元，总资产还是 1000 元，并没有发生变化。
2025-03-12 16:22:22
811
原创 另类却不罕见的聚合运算
标准 SQL 中提供了五种最常用的聚合运算：SUM/COUNT/AVG/MIN/MAX，都是对集合计算出单值。语法上只是多了分组字段。看起来这两句代码风格是一致的，但分组聚合的计算结果却不是二维的 DataFrame。但这和全集聚合的语法风格又有点不一致了。和 SQL 一样，对象和语法风格都是一致的。不过，聚合运算并不总以这么基础的形式出现，情况更复杂时，SPL 就会显出优势了。
2025-03-11 16:53:58
622
原创 多指标实时计算：SPL 实践
这些页面还要满足几千人的查询，即使采用了缓存方案以避免相同内容的页面被重复计算，早高峰的集中访问期间仍会有数十个不同的页面任务要并发，相当于同时要计算出几千个指标。但实测证明，即使是优化引擎做的较好的 Oracle 数据库，对于比较简单的多种分组，也还是会对数据表遍历多次，显然没有实现遍历复用机制。取数结束后，计算也都完成，结果写入 A5、A7、A9 格。多指标计算主要是对外存大明细表进行遍历，假如每组指标的计算都要遍历一次大明细表，那么硬盘 IO 就会成为瓶颈，众多指标的计算就不可能做到秒级响应了。
2025-03-10 10:52:46
667
原创 高并发帐户查询：SPL 实践
这样做，同一个帐户 id 的数据会连续存储，从硬盘上读取出的数据块几乎全部都是需要的目标值，性能提升会相当明显。而列存的一条记录中，每个列都有各自的位置，不可能都记录下来，只能记录序号，查找时就会多一步动作，性能会下降。由于事实表中的 tcorp 已经预先完成序号化，两表关联时直接用事实表中的位置去维表中取记录，用不到维表的主键和索引，所以这里不需要建立维表主键、索引。不过，带值索引会比普通索引占用更大的存储空间，不太适合查找时涉及字段非常多的情况，且重建索引也很麻烦，需要根据项目的实际情况权衡选择。
2025-03-07 17:06:26
704
原创 万亿计算量时空碰撞三分钟搞定：SPL 实践
数据集A中有n个源对象A1,…,An的时空信息，每条信息有三个属性，分别是ID（iA）、位置（lA）、时间（tA），可以认为同一个Ai在A中不会同时出现两次，即没有两条信息的iA和tA都相同。与A同结构的数据集B中有m个待确认是否与A发生碰撞的目标对象B1,…,Bm（对应属性分别记为iB,lB,tB），也同样认为Bi不会在同一时刻出现两次。本文涉及很多集合运算，我们不使用术语“记录”表示数据集中的信息，而使用“成员”这个集合相关的术语。将A按iA分组得到n个子集，仍用A1,…,An命名。
2025-03-06 14:39:45
628
原创 SPL 和 SQL 能不能融合在一起？
理论上来讲，SPL 是 SQL 的超集，任何 SQL 实现的计算的确都可以使用 SPL 来完成，解释或移植 SQL 是可能的，虽然这也有不少工作量，但难度并不是非常大。高效的代码要针对运算模型的特征去编写，而 SQL 语句中通常并没这样的信息。SPL 则具备简洁高效的特点，提供了更加敏捷的语法可以简化复杂计算，同时支持过程计算天然支持分步编码，计算体系更加开放可以同时针对多种数据源混合计算，利用内置的高性能存储和高性能算法容易获得更高的计算性能，在使用时更加灵活既可以独立使用也可以嵌入应用集成使用。
2025-03-05 16:57:34
884
原创 搞死 MPP 的时空碰撞问题：SPL 实践
某时间区间（例如7天）被分成多个固定时长（如15分钟）的时间切片，对象a和对象b在同一时间切片内的相同位置出现过，称为一次碰撞。规则1：相同时间切片内，多次碰撞只记一次。规则2：相同时间切片内，最后出现位置不同的称为不匹配，不匹配的时间切片数量不超过20 时，（包括其它时间切片的）碰撞才被认为有效。要求：已知对象a，查找出指定时间区间内，满足两条规则下，与a发生有效碰撞次数最多的前20个对象b。
2025-03-04 11:10:24
731
原创 SPL 量化系列实践：MACD 背离策略
之前A6中，我们只增加了signal列，令其为0，A11、A12是在经过一系列操作后，用索引获取A6的数据后对A6中的signal修改，这是因为SPL中数据有离散型，记录可以游离于序表之外，对着游离记录修改后，原数据同样会修改，思路简单，代码可以按这种正常思路实现。A6：计算金叉和死叉，金叉时，gcross_or_dcross=1，死叉时，gcross_or_dcross=-1，其余时间为0，同时增加一个买卖信号标志signal，先令signal都为0。A12：同理，确定顶背离信号，signal=-1。
2025-03-03 17:33:50
790
原创 你能想象算24点的代码能如此短吗？
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。
2025-02-28 13:54:29
917
原创 SPL 量化系列实践：回测例程
持仓金额和收益都是简单的求和，需要的现金 = 手续费 - 现金数（这样算是因为手续费是正的，现金可能是负的）后再求和。用这些数据即可画出收益率走势图，trade_date 作为横轴，income_rate 作为纵轴，buy 为 1 的点是买入点（用红色圆点表示），sell 为 -1 的点是卖出点（用绿色方点表示）。其中 0.03% 是券商的最高佣金比例，5 是最低佣金，即佣金不到 5 时，按 5 元收取，0.001% 是过户费，0.05% 是印花税（仅卖出时收取）。A2：结束日期 end_date。
2025-02-27 17:17:36
707
原创 开发量化策略模型的神器 SPL
早期还有些人使用C++，Java开发量化交易的策略模型，但目前这个领域几乎被Python垄断了，原因大概有以下两点：Python的语法便捷，操作界面也简单易学，毕竟量化分析师还不是职业的程序员，去掌握架构复杂的企业应用开发技术（Java/C++）有点太麻烦了；Python的类库全面。数据分析处理有Numpy、Pandas；可视化工具Matplotlib、Seaborn；金融技术分析工具有TA-Lib；机器学习有scikit-learn；深度学习有TensorFlow 、Pytorch等等。
2025-02-26 15:47:09
533
原创 SPL 量化系列实践：海龟策略
如果要用Python完成相同的任务，需要shift(1).rolling(20)，shift(1)偏移索引，rolling(20)将之前20个成员打包成一个很难理解的对象，相较之下，SPL的写法更简单明了。)中每个新生成的字段都可以用到后续的计算中，比如taq_up和taq_down可以用在signal的计算中，signal又可以用在flag的计算中，而这是Python所不能的，它只能一个一个计算这些字段的值。据此生成下单信号（flag），flag=1为买入，flag=-1为卖出，flag=0为不操作。
2025-02-25 15:29:04
923
原创 全网最简单的八皇后代码(内含DEMO可调试)
B4循环行中的每一列，C4执行判断，如果与前面各行已经摆放的皇后出现在同一列或同一斜行，说明当前位置不正确，继续尝试下一个位置。B3判断，如果本行皇后的列位置大于N，说明本行所有位置均完成尝试，将本行皇后移除，并返回上一行继续调整皇后位置。第4行，对于仅有1行的情况，无需判断是否合理，直接继续去设置第2行的皇后，如果N为1则直接执行后续判断。,N，皇后必须放在不同的行中，每行1个。C1中调用子程序，从初始状态的第1行开始放置皇后，执行后，即可在B1中获得摆放结果，在D1中可得到共有多少种解法。
2025-02-21 17:13:16
505
原创 esProc SPL 分组运算史上最强，没有之一
分组是常见的结构化数据计算，SQL 和 Python 都有相应的语句和函数来处理。不过，和 esProc SPL 提供的分组运算相比，这些语言都弱得多了。和 SQL 差不多。
2025-02-21 15:11:18
928
原创 做量化模型用什么，试试 SPL？
量化交易是通过编程建模等方式，利用概率论、统计学等知识从庞大的历史数据中总结规律并建模量化模型，然后凭借计算机强大的计算能力来高效、快速地进行交易决策。编程语言可选择的语言很多，下图是来自于TIOBE统计的从2002年至今前十位编程语言的走势图，可以看出，之前很长一段时间内Java和C语言一直占据着统治地位，但从2018年起伴随着人工智能的兴起，Python的地位迅速上升，现在已经超过了Java和C。
2025-02-13 17:16:39
977
原创 Python 在企业级应用中的两大硬伤
来看下大数据分组汇总运算，数据库通常会使用 Hash 分组的方案，算法的性能没问题，但Python没有提供这种算法，硬编码实现很麻烦，这个任务的难度超出一般应用程序员的能力，结果常常是退而求其次，选择一个容易实现的算法。Python无法在进程内使用简单的多线程并行机制，很多程序员只能采用复杂的多进程并行，进程本身的开销和管理复杂得多，并行程度无法和多线程相提并论，加上进程间的通信也很复杂，有时只好不直接通信，用文件系统来传递汇总结果，这又导致性能大幅下降。可以独立存储，与前端应用服务耦合，维护简单；
2025-01-15 17:42:19
917
原创 自助关联查询难在哪里
举例来讲，我们想查询所有北京号码打给上海号码的通话记录，这就需要把通话记录表和电话帐户表做关联，而电话帐户表要被关联两次，分别使用通话记录表的主叫号码和被叫号码关联，才能分别取出主叫号码注册地和被叫号码注册地。就用这个地区表，随手可以再举出让人崩溃的查询例子：北京号码漫游到广东后打给上海号码的电话，这个查询在数据库中完全可以做出来的，通话记录表中可以有基站信息，基站表再和地区表关联可以获得打电话所在地点，但是这么复杂的关联关系，已经彻底无法在 BI 界面上让业务用户理解了。这就发生互相关联的情况，转圈了。
2025-01-08 18:35:21
850
原创 从 SQL 到 SPL：组内查找最近的匹配记录
A3：过滤每组数据，先找到 ConfirmationStarted 之前的记录，再从中过滤出 Closed，取倒数第 1 条。函数 select 用于条件过滤，过滤时支持与位置相关的计算，@c 表示从第一个使条件为真的记录开始取，直到遇到使条件为假的记录时停止，@1 表示取结果的第 1 条，@z 表示从后往前过滤。现在要在每个 ID 里，找到 ConfirmationStarted 之前的所有的 Closed 中，离 ConfirmationStarted 最近的那条记录，取出记录的 ID 和时间字段。
2025-01-08 18:30:27
833
1
原创 基于对象 - 事件模式的数据计算问题
而且，SPL 复组表的数据组织机制相当于把大排序拆成多次可实时进行的小排序，将排列时间分散到日常的数据维护中，除了第一次迁移系统时会有个较长时间的排序外，日后数据不断追加过程的排序时间基本无感，而获得的计算时间提升却是数量级的。有些聚合计算比较简单，不涉及事件发生的次序，只是统计满足某些条件的事件的发生次数或事件信息的合计值（次数本质上是在合计 1），比如银行账号的交易额超过 1 万元的交易次数、节假日发生的交易额，手机通话时间不超过 3 秒的次数，游戏用户购买某类装备的金额，…我们可以把这类任务称为。
2025-01-07 18:08:25
697
原创 Excel 做数据分析的好与不好
但是可惜的是大部分编程语言在解决 Excel 缺点的同时，也丧失了 Excel 的两大优点，容易上手和交互性强。作为编程语言，SPL 的格值比 Excel 要更丰富，除了可以是单值外，还可以是一组值如 [3,5,7,8]，也可以是一个表，比如前面班级成绩单的例子，如下图，A1 的结果就是一张表，SPL 里叫做序表。Excel 在面对 10 万以上的数据量时就会很卡，SPL 不存在这个问题，10 万、百万的数据都能跑的很顺畅，还提供简易的游标运算，可以用流式读取数据，这样无论多大的数据量都能处理了。
2025-01-07 18:00:32
1080
原创 有序归并（JOIN 简化和提速系列 8）
其实，追加数据再加入的过程也是个有序归并，把新增数据单独排序后和已有序的历史数据归并，复杂度是线性的，相当于把所有数据重写一次，而不象常规的大数据排序需要缓存式写出再读入。这些在乾学院上都有介绍。而且，执行归并算法需要的内存很少，只要在内存中为每个表保持数条缓存记录就可以了，几乎不会影响其它并发任务对内存的需求。使用有序归并实现并行计算时需要把数据分成多段，单个表分段比较简单，但两个关联表分段时必须同步对齐，否则归并时两个表数据错位了，就无法得出正确的计算结果，而数据有序就可以保证高性能的同步对齐分段。
2025-01-02 14:38:27
732
原创 计算帐户每月余额，补齐缺失日期：从 SQL 到 SPL
A5：当前账号与上一条记录相比不变时，当月余额=当月金额变化+上个月的余额；账号变化时，当月余额重置为当月金额变化。现在要统计从期初 2021 年 1 月到期末 2024 年 4 月每个账户每个月的余额，缺失的月份要补齐。A2：生成每月第一天组成的连续序列。SQL没有方便的方法生成月份序列，要用嵌套查询+窗口函数，代码非常复杂。A1：查询数据库，按账户、每月第1天的日期分组，统计每月金额变化。MSSQL 数据库有个资产账户的流水表，日期不连续。SPL提供了生成日期序列的函数，包括连续月份。
2025-01-02 14:35:22
584
原创 进一步的外键关联（JOIN 简化和提速系列 7）
SQL 使用了无序集合的概念，即使我们事先把外键序号化了，数据库也无法利用这个特点，不能在无序集合上使用序号快速定位的机制，只能使用索引查找，而且数据库并不知道外键被序号化了，仍然会去计算 HASH 值和比对。SQL 不区分维表和事实表，面对一大一小两个表时，优化过的 HASH JOIN 不会再做分堆缓存，通常会把小表读入内存而去遍历大表，这样仍然会有遍历大维表的动作，性能会比刚才说的外存查找算法差得多。我们仔细分析上面的算法会发现，过程中对于事实表的访问是连续的，但对于维表的访问则是随机的。
2025-01-01 14:00:00
1850
原创 从 SQL 到 SPL：分组后每组前面增加符合条件的记录
现在要找出上级层数大于等于 2 的那些节点的层级，以及最高层节点的区域，比如第 1 条记录的上级有 3 层，分别是 5-11-15，最高层是 15；只要找到各节点递归引用的所有层级，就可以方便地过滤出结果，但SQL没有直接可以用的函数，要用结构复杂的递归子查询+自关联join来实现，代码冗长难懂。MSSQL 数据库某表具有多层级的自关联结构，第 2 个字段父节点 ID 是指向本表的第 1 个字段节点 ID 的外键，第 3 个字段是区域。A4：选出递归引用的所有层级的层数大于等于2的节点。
2024-12-31 13:59:52
511
原创 Excel 后，我们需要怎样的数据分析软件
在现代商业环境中，数据分析已成为企业决策的重要工具。通过数据分析，企业可以更好地了解市场趋势、客户行为以及内部运营情况，从而制定出更科学的策略，提高竞争力。然而，数据分析并不是一项简单的任务，需要选择合适的工具和方法。很多人认为 BI 软件是数据分析的首选，因为 Business Intelligence 这个词听上去和数据分析的关系很密切，而且 BI 软件通常具有流畅的交互性和炫丽的界面，看上去很适合做这项工作。然而，BI 工具在技术上已经被狭义化成多维分析，主要用于基于预设的数据立方体的汇总和展示。
2024-12-31 13:51:58
2102
原创 外键预关联（JOIN 简化和提速系列 6）
将 HASH JOIN 算法参照外键地址化方案进行改造后，也能一定程度地改善多外键一次解析和并行能力，有些数据库能在工程层面上实施这种优化，不过通常只在只有两个表 JOIN 的情况时有效，在有很多表及各种 JOIN 混在一起时，数据库并不容易识别出应当把哪个表当作事实表去并行遍历、而把其它表当作维表建立 HASH 索引，优化并不总是有效的。A3 读出订单表，A4 的动作是将 A3 的外键字段 cid 转换成对应的 A1 的记录，执行完后，订单表字段 cid 将变成客户表的某条记录。
2024-12-30 15:24:16
568
原创 流计算需要框架吗？SPL 可能是更好的选择
流数据源通常是动态、无界的，看起来与静态、有限的批数据源区别较大，传统的数据库技术在架构上难以直接处理流数据源，只能让位于后来者。heron\samza\storm\spark\flink等计算框架最先完成突破，在流计算技术中占得先发优势。这些框架非常成功，以至于一说到流计算，应用程序员通常都会去转头寻找某种框架，而不宣称是某种框架的计算技术，则通常被认为不适合实现流计算。
2024-12-30 15:09:13
933
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人