KDB+/q : How to implement an aggregation table for features?

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

然后你不断地扩大这张 table 。如果您需要旋转表格以使特征成为列，那么您可以事后进行。

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