ORCA：定义一张流图，让实时行情“跑”起来

在实时行情处理、量化交易等数据密集型场景中，系统往往需要同时完成数据接入、清洗、聚合、K 线生成、指标计算和下游分发等多个环节。链路越长，模块依赖越多，开发和维护成本也越高。

因此，在系统设计初期，通常会先梳理一张行情数据处理链路图，明确数据从哪里来、经过哪些处理、最终流向哪些策略、风控或展示模块。

DolphinDB 的实时计算平台 ORCA，提供了将链路从“设计图”落地为“可运行系统”的能力。它将常见的数据处理能力封装为可组合的流式组件，开发者只需提交一张流图并做少量配置，ORCA 便可围绕这张图完成编排、调度与容错管理，让数据持续流动并实时产出结果。

业务逻辑示意图

Orca 计算链路示意图

从定义一张业务流图开始

要理解 ORCA 的实时链路构建机制，先要理解它的核心抽象——流图。

流图描述的不是某一个单独的计算函数，而是一条实时任务从输入、处理到输出的完整链路。它关注的是数据如何在系统中流动，而不是底层对象如何手动拼装；它把原本分散在脚本里的流表、引擎、订阅和输出关系统一抽象出来，让实时计算任务能够以更直观的方式被定义和管理。

开发者只需要关注业务链路，通过脚本把数据从哪里来、经过哪些处理、最终流向哪里表达清楚，ORCA 就可以基于这张逻辑图完成后续的部署、调度和运行。

以一个常见的 K 线场景为例：逐笔成交数据进入系统后，需要按 1 分钟窗口聚合出开盘价、最高价、最低价、收盘价和成交量（也就是常说的 OHLC），再在这份 K 线的基础上算一组滑动窗口指标，比如 5 分钟内的最高价、5 分钟成交量均值。

这条链路，用 ORCA 的链式脚本表示如下：

// 创建一张名为 graph1 的流图
g = createStreamGraph(`graph1)

// source 定义输入表 trade
// 中间计算引擎 timeSeriesEngine 和 reactiveStateEngine
// sink 指定输出表 output
g.source("trade", `symbol`datetime`price`volume, [SYMBOL, TIMESTAMP, DOUBLE, INT]) 
  .timeSeriesEngine(
       60*1000, 60*1000,
       <[first(price), max(price), min(price), last(price), sum(volume)]>,
       "datetime", false, "symbol")
  .reactiveStateEngine(
       <[datetime, first_price, max_price, min_price, last_price, sum_volume,
         mmax(max_price, 5), mavg(sum_volume, 5)]>,
       `symbol)
  .sink("output")

// 提交流图给系统
g.submit()

数据从 trade 进入，经过时间序列聚合引擎计算 OHLC 指标，然后流入状态引擎计算滑动窗口指标，最终输出到 output。开发者只需要定义这张图并提交，系统就会接管后续的执行和管理。

Hint：ORCA 封装了包含时序聚合、状态计算、截面计算、数据连接等不同计算场景的流计算引擎，可以直接调用；如果引擎无法满足需求，用户也可以自定义函数进行处理。更详细的教程，参考官方文档：https://docs.dolphindb.cn/zh/orca/orca.html

提交后，在 Web 管理器的 Stream Graph 板块中，定义好的流图会以可视化方式展示出来，节点之间的连接关系一目了然。开发者不仅可以直观看到数据从输入到输出的完整路径，还可以进一步查看每个节点的运行状态、上下游依赖和任务配置。

从跑通到跑稳，为计算提供生产级保障

对于这样一条实时计算链路来说，能够跑通往往只是第一步。更重要的是，运行起来之后能不能扛住实际业务的考验：性能不达标时怎么排查？某个环节报错怎么定位？节点突然故障，能不能不丢数据、不重复计算地恢复？

对于这些问题，ORCA 在流图提交的那一刻起就已经安排妥当：

流任务拆得开，卡点一目了然

ORCA 会先把用户提交的链式逻辑抽象成完整流图，再进一步拆分成子图和流任务。这样一来，原本隐藏在代码里的复杂链路，会被清晰地展开到图结构里：哪些算子是串行依赖，哪些位置会产生跨任务数据传递，哪些环节更容易形成处理瓶颈，都能更直观地识别出来。对排查性能问题来说，这种结构化拆解比直接看一段脚本更有效。

调度按资源来，负载不扎堆

在调度阶段，ORCA 不只是简单找一个空闲节点，而是会结合表位置、计算组、共享状态、节点负载等多个约束做综合决策，把任务放到更合适的执行位置上。这样既能减少不必要的跨节点开销，也能避免热点节点负载过高，提升整条链路的稳定性和吞吐表现。对生产环境来说，这种“按资源和约束调度”的方式，能显著降低性能波动带来的风险。

断点能对齐，故障恢复不丢

ORCA 通过 checkpoint 和 barrier 机制，把整张流图的处理进度对齐到统一的恢复点。无论是单个节点故障，还是局部任务异常，都可以基于最近一次成功检查点恢复状态，尽量保证数据处理的连续性和一致性。对于实时链路来说，这意味着恢复过程不只是“重新跑起来”，而是尽可能做到不丢数据、不重复计算，让故障处理真正具备生产可用性。

链路可追踪，问题定位更直接

从流图、子图到任务、节点、订阅和引擎，ORCA 都能纳入统一管理，问题出现后可以沿依赖链路逐层追踪，定位更直接。同时，系统在提交、启动、停止、销毁等生命周期操作上也遵循明确顺序，避免半启动、半销毁带来的隐患，让运行和运维都更稳定。

也就是说，ORCA 解决的不只是“能不能跑通”，更是“能不能长期稳定地跑”。

点击 https://docs.dolphindb.cn/zh/tutorials/orca_technical_principles.html，查看更多 ORCA 底层的设计细节。

从 K 线到实盘：一个更复杂的案例

前面的 K 线 OHLC 指标计算场景，展现的是 ORCA 处理“单一数据源”这类相对简单的链路。但实际的量化场景往往更复杂：不止一路数据，中间还要对齐合并，再接模型推理和交易执行。

在【从行情到模拟成交：DolphinDB 如何打通交易执行链路】的“性能与开发效率”章节中，我们介绍了 ORCA 在实时因子计算和模拟撮合交易脚本开发上的效率优势。

以其中的“降频 + 衍生因子合成”部分为例：成交和快照两路原始数据同时接入，各自经过时序聚合引擎和响应式状态引擎，算出分钟频指标；这一步之后，两路数据要按证券代码和时间对齐合并，才能算出综合两边信息的衍生因子。对应的 ORCA 脚本示意如下：

graphName = "snapTradeFrame"
g = createStreamGraph(graphName)
tradePipeline = (g.source(tradeStreamName, colNames1, colTypes1)
            .dailyTimeSeriesEngine(...)
            .reactiveStateEngine(...)
            .sink(factorDbname+"/"+tradeMinStreamTbname))

snapPipeline = (g.source(snapStreamName, colNames2, colTypes2)
            .dailyTimeSeriesEngine(...)
            .reactiveStateEngine(...)
            )
            
snapPipeline.equalJoinEngine(
                rightStream = tradePipeline,
                metrics = sqlCol(colNames[2:]),
                matchingColumn = `securityId,
                timeColumn = `tradeTime,
                maxDelayedTime = 1000 * 60 * 60 * 24
            )
            .reactiveStateEngine(
                metrics = facMetrics,
                keyColumn = `securityId,
                parallelism = parallel
            )
            .sink(stringFormat("demo.orca_table.%W", factorTbname))
            .sink(factorDbname+"/"+factorTbname)
g.submit()

快照流和成交流分别算完各自的分钟频指标之后，equalJoinEngine 负责把两条独立的链路按 securityId和tradeTime对齐拼接，maxDelayedTime则限定了等待另一路数据的最长时间——避免某一路因为延迟迟迟不来，导致下游一直卡住。合并完成后，因子再被推给下游模型做实时推理，生成交易信号，构造委托订单送入模拟撮合引擎，最终输出成交明细。

完整的流链路图示意如下：虽然链路变复杂了，但写法上的核心逻辑没有变：接入、计算、合并、输出，依然是链式声明；而具体哪些引擎放在哪个节点、合并时怎么等待对齐、故障后怎么恢复，交给 ORCA 底层自动化实现即可。

结语

对于实时行情处理、量化交易这类数据密集型场景来说，真正的挑战从来不只是“把链路写出来”，而是如何让链路长期稳定、可控地跑在生产环境中。

ORCA 实时计算框架的意义，就在于把原本需要开发者手动拼装、逐个维护的流计算对象，抽象成可组合、可编排、可恢复的业务流图，让复杂链路从设计、部署到运行和运维都形成统一闭环。

借助 ORCA，业务逻辑可以更自然地映射为实时计算链路，系统则负责完成后续的调度、执行和容错。这样一来，开发者不仅能更快搭建出从数据接入到结果输出的完整流程，也能在面对性能波动、节点故障和链路扩展时，获得更强的可观测性和生产稳定性。

对真正的实时业务而言，这种能力带来的，不只是开发效率的提升，更是系统持续产出业务价值的基础。