数据库选型：时序库与 OLAP

为什么历史行情可以放在数据湖里，但线上 API 还需要专门的数据库？数据 API 常见的是按代码和时间范围查询、全市场聚合和高并发读取，这些请求不适合每次打开对象存储文件完成。

• OLTP：面向频繁的小事务和单行更新，重视事务一致性。
• OLAP：面向大范围扫描、聚合和分析，通常读多写少。
• 时序数据库：围绕时间戳、标签和数值设计，常提供时间切片、降采样或 ASOF JOIN 等能力，具体功能依产品而异。
• 列式数据库：按列存储和压缩，适合只读部分字段并扫描大量记录。

ClickHouse 的 MergeTree 系列表引擎会把每批写入形成数据片段，后台再合并片段。建表时的 ORDER BY (code, ts) 决定磁盘上的排序键，稀疏主键索引按数据颗粒记录标记，不是每行一个索引。查询条件与排序键匹配时，能减少需要读取的数据范围。

ASOF JOIN 用“不晚于某时刻的最近记录”做时间关联，例如把成交配上当时最新快照。使用它仍要检查时区、证券映射、可用时间和陈旧度。

常见分工是“湖存全量、库存热数据”：数据湖保留完整历史供批量分析，数据库保存近期或高频访问数据服务 API。也可以采用单库方案，但要用真实访问模式验证。

不要只凭数据量或一次跑分决定技术栈，还要评估写入批次、更新和删除、备份恢复、高可用、监控、人才和授权成本。

CREATE TABLE ticks
(
    code String,
    ts DateTime64(3, 'Asia/Shanghai'),
    price Float64,
    volume UInt32
)
ENGINE = MergeTree
PARTITION BY toDate(ts)
ORDER BY (code, ts);

SELECT toStartOfMinute(ts) AS minute,
       argMin(price, ts) AS open,
       max(price) AS high,
       min(price) AS low,
       argMax(price, ts) AS close,
       sum(volume) AS volume
FROM ticks
WHERE code = '600001.SH'
GROUP BY minute
ORDER BY minute;

这里的 argMin 和 argMax 是按时间取价格的聚合写法。实际使用要确认同一时间戳的并列处理、价格单位、数据排序和迟到修订规则。

频繁小批量插入会产生很多数据片段，后台合并压力升高。对外部数据库写入时，流处理的“精确一次”也不能自动保证外部系统没有重复，仍需事务、幂等键或版本去重。

• ClickHouse MergeTree
• ClickHouse 稀疏主键索引
• ClickHouse JOIN
• DuckDB 文档