KDB + / q：如何为功能实现汇总表？

Question

我正在尝试实现一个汇总表，该表将来自多个不同表的数据整理到一个表中，以进行特征工程，预处理和规范化。我面临许多问题，第一个问题是我必须以某种方式构造此聚合表的架构而无需对其进行硬编码，这使我在添加其他数据源方面具有足够的灵活性。

trades
  - exch1
    - sym1
    - sym2
  - exch2
    - sym1
    - sym2
book
  - exch1
    - sym1
    - sym2
  - exch2
    - sym1
    - sym2
sentiment
   - sym1
   - sym2

正如我在前面的问题中已经指出的那样，当我想在kdb-tick体系结构中的聚合表中（在聚合之后）插入可能具有或没有其他模式的新聚合时，就会出现问题。

我已经注意到该uj操作似乎是一种适当的操作，好像输出速率将仅约为0.5-1赫兹，但是我被告知，由于它可能会引起反事实，因此可以将其视为反模式。持久性问题，不是有效的操作等。

我已经考虑过在执行插入/向上插入操作之前检查架构（如果架构不同，请更新架构，然后插入）。但是，这也可能效率不高。

我已经注意到了对先前问题的回答，但是似乎所有的消极观点都可能超过其积极方面。

聚合的性质意味着，我仅需要RTE订户/工作人员上大约1000行的表即可有效运行聚合，从而将较旧的记录清除到磁盘上。但是，列数可能会间歇性变化（添加了新的提要等），不一定在一天之内。

数据的性质还意味着聚合需要连续运行，即将数据分割成几天是无效的。

我还考虑过为每个新功能维护一个单独的表，但是表的数量也会导致效率低下。

当人们选择尝试将旧的/清除的聚合行发送给工作人员，然后定期保留这些聚合时，还会出现问题。如何修改kdb-tick发布者-订阅者体系结构以支持.u.upd[]聚合数据的列何时可能更改？问题不在于kdb-tick架构本身，而是如何在保持向后架构兼容性/效率的同时对其中的数据进行聚合？

我什至曾考虑在Rust中创建自己的特定于域的数据库，将数据划分为分片的平面文件。但是由于我能够进行/创建的高级查询操作，选择坚持使用kdb / q。

我认为，在线/实时运行这样的聚合对于将kdb +与ml结合使用而言是一项重要功能，但是我还找不到任何文档。

因此，我的问题可以总结如下：规范的实现是什么？如上kdb所述，如何有效地聚合来自多个源的数据？非常感谢您的建议。

Answer 1

您的tickerplant 应该为每个提要/表有一个固定/设置的架构。为此，您应该使用 vanilla/stock tick.q 代码。如果添加了新的提要，则您可以在tickerplant 中配置一个新表。

您的订阅者/聚合者应该订阅来自tickerplant的所有原始表，并且它应该聪明地根据表名称确定如何处理传入的记录。

您不必将不同的表/模式合并到一个表中。您的订阅者/聚合者（或者可能是您的模型流程）应该获取传入记录并生成功能。然后您可以将此功能插入到具有固定架构的表中：

source    time                          feature output
---------------------------------------------------------
trade     2019.09.06D08:47:56.525854000 f1      0.4707883
trade     2019.09.06D08:47:56.525855000 f10     0.6346716
book      2019.09.06D08:47:56.525856000 f3      0.9672398
trade     2019.09.06D08:47:56.525857000 f5      0.2306385
sentiment 2019.09.06D08:47:56.525858000 f2      0.949975

然后你不断地扩大这张桌子。如果您需要旋转表格以使功能成为列，那么您可以事后执行此操作。

这里的任何人都很难完全理解你的系统和你想要做什么。堆栈更多的是一个提出小问题的地方，而不是大的架构问题，因为这需要太多的附加信息。