如何高效执行KDB大查询 降低多中间表产生的额外资源消耗

核心疑问解答 #

首先明确：结构合理的单条嵌套/链式查询确实会大幅降低资源消耗，你当前创建多个全局中间表的方式才是不必要的资源消耗来源。
KDB的q语言采用惰性求值机制，未被赋值给全局变量的临时中间计算结果，会在使用完成后立刻被内存回收，不会持续占用内存。你创建7张全局中间表相当于把所有中间计算结果都持久化在了内存中，自然会带来不必要的资源开销。

具体最佳实践 #

• 优先用链式/嵌套查询替代全局中间表：过滤、列重命名这类预处理操作可以直接作为关联函数的入参，不需要单独赋值存储。只有当某份预处理结果需要被多个不同查询复用时，才有必要存储为中间表。
• 关联前提前裁剪数据量：在做aj/ajo关联前，先把右表（marketPrices、usdRates）中时间范围不在交易记录arrivalTime区间内的记录过滤掉，同时只保留关联需要用到的列，减少关联时的计算量。
• 保证关联键排序符合要求：aj/ajo要求右表必须按「公共匹配键升序、时间键升序」排序，如果你的原始行情、汇率表已经按规则排序，不需要每次关联前重新排序，可节省大量计算时间。
• 统一关联键命名可以直接在查询中完成，不需要单独做中间表转存。

演示场景示例代码 #

/ 单条链式查询实现需求，无全局中间表
aj[`sym`arrivalTime;
    / 交易表预处理：重命名关联键，仅保留需要的字段
    select sym:symbol, ccy, arrivalTime, nominal from trades;
    / 行情表预处理：裁剪时间范围、重命名关联键
    select sym, arrivalTime:dateTime, mktPrice:price from marketPrices where dateTime within (min max exec arrivalTime from trades)
    ]
/ 关联汇率表
|> aj[`ccy`arrivalTime;
    x;
    select ccy:currency, arrivalTime:dateTime, fxRate from usdRates where dateTime within (min max exec arrivalTime from trades)
    ]
/ 计算美元计价金额
|> update usdNominal:nominal * mktPrice * fxRate from x

如果你的kdb版本不支持|>管道符，也可以用嵌套写法实现同样逻辑，资源占用效果完全一致。

内容的提问来源于stack exchange，提问作者Chechy Levas