框架之外：数据、研究与展示如何组合

Ⅳ · 研究与可视化 — 4.1

NautilusTrader 或 LEAN 是交易引擎，不等于全部系统。数据、研究、展示与运维是可按需求组合的外围能力。

第二章描述的是交易引擎内部如何运行。实际工作中还会有数据落地、研究查询、图表展示、日志与运行监控等能力，但它们不天然属于某一个引擎，也不需要在第一天全部建设。

这张图刻意不把组件画成一条必须按顺序建设的路线。它说明边界和可交换关系，具体组合留给后续需求与交付约束决定。

这不是一张预设的产品架构图。它只说明四类职责之间常见的数据关系：一套经过校验的数据与事件约定，可以被研究工具、交易引擎和展示层分别消费；具体是否需要服务端数据库、实时推送或浏览器界面，取决于后续场景。

层	可能的组件	首先回答的问题
数据	数据源适配、Parquet、数据目录、质量校验	数据从哪里来，时间、价格和品种口径是否可追溯？
研究	DuckDB、Jupyter、Plotly	某个假设如何被检验，结论能否被复查？
交易运行时	NautilusTrader、LEAN、策略与执行适配器	数据如何驱动策略，订单如何发送并形成状态事件？
展示与运维	API、事件流、KLineCharts、日志与告警	运行中哪些状态需要被人或其他系统读取？

其中 Parquet 是文件格式，DuckDB 是查询引擎，KLineCharts 是浏览器渲染库。把名字和层次分开，讨论“是否采用”时才不会把数据格式、计算引擎和前端图表当成同一种技术选择。

研究阶段常使用批量查询与向量化计算，运行时则常按 bar、tick 或订单事件增量推进。两侧不必强制共用同一个文件或同一段实现，但只要它们声称表达的是同一个规则，就应保留一组固定输入与期望输出进行对照。

固定行情片段 + 固定参数
        │
        ├─ 研究实现 → 标注 / 信号 / 统计中间结果
        └─ 运行实现 → 标注 / 信号 / 事件中间结果
                         │
                   比对定义一致的输出

一致性检查验证的是规则表达，不要求把 notebook 写法原封不动搬进策略运行时。对于简单指标可以复用计算核心；对于批量研究与事件驱动实现不同的情形，应保留可复现的对照样本。