本文是High Frequency Trading Review（《高频交易评论》，以下简称HFTReview）对Kx公司首席战略家Simon Garland的一篇访谈。Simon Garland在访谈中谈到了kdb+/q在高频交易领域的优势及应用。应该注意的是，本访谈发生在十年前，但大部分内容仍是适用的。
最近，Kx公司首席战略家Simon Garland从瑞士来伦敦，我有幸与他见面交流。Kx公司的kdb+数据库被广泛用于高频交易，可以高速存储、分析、处理和检索大型数据集，因此我想借此机会了解更多关于该公司及其产品的信息。
HFTReview：Simon,你能否解释一下是什么使kx Systems和kdb+脱颖而出，以及为什么你们在高频交易（HFT）领域经历了这种增长吗？
SimonGarland：我们出名的原因就是我们产品的速度非常快，这也是为什么人们使用我们的产品。另一个没有得到广泛关注的是，我们实现了“一站式服务”。只要数据能够快速进入kdb+，无论你使用的数据源处理器（feed handlers）是我们的还是其他供应商的都无关紧要。交易所数据经过数据源处理器，以一个小表的形式流入kdb+，你可以立即对它执行SQL查询。再结合历史数据，你可以在流数据和历史数据上进行复杂事件处理（CEP，complex event processing）；可以对数据执行复杂的查询，例如，“这与一秒钟前，一分钟前，一周或一个月之前是否不同？”。
在分析完小表并完成了CEP（其中可能包括流分析）之后，该小表将被追加进日内数据库（IntradayDatabase）。然后，它成为大表的一部分，你可以在内存数据库、磁盘数据库或者两者上再次运行SQL查询。
随着新机器的上市，高端服务器支持TB级大内存。例如，你可以将需要的所有日内Level 2行情数据保存在一台服务器的内存数据库，并在其内存表上轻松地运行查询。你无须将数据折成几个部分分别存储在不同的服务器上，再想办法让它们一起工作。
HFTReview：你能告诉我更多关于q的信息吗？
SimonGarland：q是Kx的专有语言。它是一种强大、简洁、优雅的向量语言，这意味着一个生产系统可能只需要一页代码，而不是一页又一页的代码，冗长代码的维护就像噩梦一般。当然，学习q语言可能需要一些前期投入，但是它使你具备处理流数据、实时数据和历史数据的能力，这些初期投入是非常值得的。
HFTReview：将流数据、实时数据与历史数据整合在同一个数据库中的实际应用有哪些？
SimonGarland：最重要的是简单性，具体体现在数据分析的速度和简便性。例如，它允许你做复杂的、时间紧迫性高的分析，例如交易前风险分析。这意味着你可能会在那些使用与大多数人一样的现成解决方案的人之前看到有趣的交易机会。因此，你能够最先并且足够早到达那里，可以做全面的交易前风险分析，寻找过去曾发现的模式。
HFTReview：越来越多的公司正在讨论将交易前风险分析直接放在芯片上。他们实际上是直接在FPGAs或其他芯片上编程，能够在芯片级水平上运行交易前风险检查。你们有做什么特别的与芯片相关的事情吗？
SimonGarland：有也没有。我们认为将其作为标准进行建设还为时过早。我们已经提供了钩子（hooks）功能，我们的一些尖端用户已经在使用它们，但是我们迄今为止还没有正式构建它，因为目前还没有通用的标准。只有使用最新一代的GPU，你才能够进行64位浮点计算。这还处于“西部拓荒时代”。
HFTReview：这是个有趣的回答，因为Kx在64位、多线程和其他各种功能上，目前都处于领先地位，这会是下一个领先的领域吗？
SimonGarland：是的，我们目前已经使高级用户可以自行操作，并且确实有客户在生产中使用了此功能。目前，还有许多其他地方可以提高性能。
HFTReview：比如说？
SimonGarland：例如，在最新的机器上，CPU内核数量急剧增加，因此可以进行性能优化。与将代码运行在特定内核和插槽相比，代码随机地跨内核运行，将大大降低总体性能。例如，“此进程可以运行在8个内核，我们将强制其在第二个插槽上运行”。
HFTReview：你能否分享一下你们的技术在HFT领域有什么有趣、创新和不寻常的用途？
SimonGarland：可以。有趣的是，事情的变化是如此之快，但是我们的客户往往不愿意分享这类信息，因为这是他们的竞争优势所在。有人比我们预期的要早得多地将计算任务转移到FPGA和GPU上。尽管投入生产还需要做大量工作，目前生产系统中已经有成千上万个GPU是由kdb+驱动的。在这类应用程序中，业务逻辑是通过kdb+，使用解释性语言q进行管理的，从而可以轻松快速地查看系统情况。例如，你不必自行管理GPU内存。它使系统维护更加容易，系统变更更快。
HFTReview：但是，具有这种专业知识的kdb+程序员好找吗？
SimonGarland：我认为问题不在于找到kdb+程序员，你说的问题是寻找优秀人才通常都要面临的挑战。假设你是一家银行，并且需要使用GPU编写多线程、具备生产质量应用程序的Java程序员，那么银行内合适的候选人可能仅有少数几个，而且他们通常都会被各种项目提前预定。而且，你觉得找这样的人能有多容易：真正知道如何用GPU的人，一直跟踪最前沿SDK的人，以及那些知道哪些技术很酷、哪台机器好、哪些型号存在严重缺陷的人？
HFTReview：有没有什么特别的社区，让这些人聚集在网上讨论这类技术，特别是金融领域？
SimonGarland：虽然有一些，但仍然是“我们今晚见面喝啤酒吧”这样一种情况。目前这类社区还没有发展到能够真正在网上建立起来的程度。优秀的人非常优秀，他们自然知道在那个领域还有谁是优秀的。那些“有名”的人通常是那些在各种制造商中进进出出的人，他们知道那里有什么，正在生产什么，什么是好的，以及什么还没有解决。
HFTReview：你们的技术在特定资产类别中有什么有趣的应用吗，例如外汇？
SimonGarland：外汇的世界一直在变化。交易量大幅度增加，因此有更多的数据需要处理。另外，由于2008年的动荡，有大量的人涌入外汇市场，他们从其他资产类别的相关工作中获得了非常有趣的经验。例如，他们知道如何处理海量数据，并了解以实时速度分析数据以产生显着的竞争优势的不同方法。这个市场有很大的扩展潜力，但这是一个敏感的领域，因此我们的客户倾向于保守他们的商业秘密。
HFTReview：Kx将在哪些领域与其他CEP解决方案竞争或共存？
SimonGarland：嗯，这就是“一站式服务”的理念。CEP软件通常用于处理刚刚从交易所出来的数据。但是CEP软件并不是完整的解决方案，因为你需要将它与其他应用程序，例如与其他数据库混合使用。这意味着你将不得不与其他数据表示形式和SQL方言打交道。如果你要处理的数据多达1亿条记录，则此方法是可以的。但是，如果你要处理数十亿条记录，你不会想从一个应用程序中获取数据并将其发送到另一个应用程序，因为那样太慢了，数据需要花费不少时间才能完成移动。但是数据一旦进入kdb+，你可以马上使用。kdb+另一个优点是，它实在太快了，你可以在短短几分钟内回测数年的数据，而不必花费一整晚的时间进运行测试，然后在第二天早晨才能看到测试结果。我们有时会看到，CEP软件后台用的是kdb+。
HFTReview：我想kdb+与Matlab等语言可以很好地交互？
SimonGarland：是的，Matlab等很有用。在现成的统计函数方面，我们没有他们的广度。但同样地，Matlab无法以我们客户要求的那种速度处理5000亿条记录。
因此，当你需要这类东西时，你需要kdb+，例如“给我这个，这个，还有这个，然后把它汇总成一分钟K线，对于这些股票，请给我数万条具体记录及其最大值”。然后，你将数据导出到Matlab或者Panopticon之类的可视化软件中，你就可以对其进行绘图和分析，但仅凭这些软件无法完成这一系列繁重的工作。
HFTReview：那么Kx接下来要做什么呢？
SimonGarland：更快！但不只是速度更快，我们还将根据客户反馈、市场和技术发展来提高kdb+性能。我们意识到我们的系统在客户的业务中具有核心地位，所以我们专注于确保我们的解决方案可靠且稳定。
HFTReview：谢谢Simon。
(原文链接：https://web.archive.org/web/20181219134322/http://www.thetradingmesh.com/pg/blog/mike/read/5388/kx-systems-and-high-frequency-trading)
《kdb+中文教程》
全文链接
