客户说｜长桥科技引入阿里云ClickHouse重构行情分析业务，性能提升10倍 ...

admin 发表于 2025-1-13 17:28

专栏客户案例

业务挑战

长桥的行情业务通过APP、Web、桌面端和OpenAPI接入，为用户提供全球市场的极速稳定行情服务。多区域的实时行情链路确保了快速的数据传输，但多市场和多品种的数据带来了历史数据存储和清洗的挑战。为及时准确地展示行情数据，对底层数据库提出了以下要求：

支持大量数据的快速写入和同步：各市场行情成交数据、计算后的 K 线数据，需要能在短时间（1s ）内完成高达百万标的数据写入，以保证推送数据和查询数据的一致性。
简单快速的批量查询：行情业务主要需要对历史数据进行批量查询和分析，并进行简单的聚合分析来计算关键指标，要求查询实时性达到ms级。因此，底层数据库必须支持多种聚合函数，并能在ms级时间内返回聚合查询结果。
支持计算函数和Decimal类型：由于不同股票交易市场对数据精度的要求不同，数据库需支持原生的Decimal类型以适应数据存储。此外，由于证券交易属于时序数据，还需提供丰富的时间函数支持。

早期技术架构痛点

在早期，长桥为了满足不同阶段的业务需求和市场数据，引入了文件存储、PostgreSQL、Redis、DynamoDB等多种存储产品。随着业务扩展，用户对历史数据的需求增加，原有存储模型的问题逐渐显现，包括性能差、成本高和通用性差等，促使长桥对行情业务进行了重构。

3.1 原有存储模型

最初，长桥在香港、中国A股和新加坡市场的数据存储上使用PostgreSQL。然而，随着美股和期权业务的发展，PostgreSQL的并发写入性能不足的问题显现。为应对美股和期权数据的高读写需求，长桥分别引入了Redis和DynamoDB数据库。虽然Redis提升了性能，但为了降低成本压力选择仅存储日内行情数据，又带来了美股数据定期转储的问题，增加了业务复杂性。

最终形成了下图所示的由PostgreSQL、Redis和DynamoDB构成的复杂行情交易存储架构：使用PostgreSQL进行历史行情数据存储、 Redis进行实时行情数据存储、 DynamoDB承载高 IO 的读写场景，主要是大量的数据写入场景。在这个架构下，不同股票市场的数据写入不同的数据库，由于各市场的数据特性和质量要求不同，每个市场和存储模型都需单独清洗，导致运维和开发成本极高。

3.2 存在问题

随着业务发展、接入更多国际市场和夜盘交易数据的需求增加，终端用户也需要更早的行情数据进行策略分析，使得原系统的性能、成本、扩展性及运维负担问题更加明显：

Redis存储成本高，数据模型不通用，数据清洗和修复需定制工具，且查询分析能力弱。
PostgreSQL写入性能差，无法支持美股和期权数据的写入，其他市场数据清洗后写入时，也会导致CPU负载升高、查询变慢。
ETL操作复杂度大，各市场的数据清洗、分析和存储模型差异扩大，需要独立开发和适配。

为优化存储系统的效率和通用性，长桥决定对存储系统架构进行重构。

3.3 新架构选型对比

决定进行架构重构后，考虑到行情业务本身的时序特征和对性能的要求，以及存量业务迁移到新架构的改造工作量，长桥对市面上几款常见的时序数据库进行了调研，包括ClickHouse、TimeScaleDB、TDengine，并从功能支持、性能、成本三个方面对三款数据库进行了比较，如下表所示。

从图中可以看出，相比TimescaleDB和TDengine，ClickHouse不仅满足证券分析的功能需求，支持150+种聚合函数和时间窗口的原生Decimal类型，还支持按PostgreSQL建表，这意味着长桥可以直接将原有存储在PostgreSQL、S3或OSS上的数据迁移到ClickHouse，实现历史业务数据的统一整合。

除了功能支持和迁移兼容性，ClickHouse在性能上，尤其在批量写入方面，有显著优势，可以轻松应对长桥美股每秒百万标的交易数据写入压力。其列式存储提供5+倍的高压缩率，适合存储重复率高的A股低频交易K线数据。由于其高效的数据处理和云原生运维便利，长桥选择阿里云ClickHouse进行架构重构。

3.4 ClickHouse的性能验证

在正式做技术栈切换前，长桥利用A股13年的数据对ClickHouse的批量写入性能进行了测试，测试使用的实例规格是 4C16G 的单节点实例，考虑到不同的交易场景下，标的活跃度不同，长桥分别针对按单标写入的场景和批量写入的场景进行了测试，测试均采用先向数据库内插入11亿条数，后将50万条数据分十次批量写入并测试数据库的写入平均耗时，可以看到整体的平均耗时均在7秒左右，效果提升显著，明显优于PostgreSQL。从验证测试结果来看，阿里云ClickHouse完全能够支撑长桥行情业务，满足美股和期权数据写入性能要求和时效要求。

架构升级到阿里云ClickHouse

经过批量写入的验证后，长桥决定对原有的架构进行重构与升级，使用ClickHouse替代DynamoDB、PostgreSQL、Redis+定时任务的业务模式，实现各市场数据的统一存储。

4.1 数据迁移

在数据迁移的过程中，长桥使用ClickHouse的OSS外表能力实现了对DynamoDB中存储的历史数据的迁移，使用阿里云瑶池旗下的数据传输服务DTS(Data Transmission Service)实现了从PostgreSQL到ClickHouse的数据迁移，并利用DTS内置的多表合并等能力，在同步过程中直接完成了部分业务改造，整体使用下来DTS迁移性能优秀、链路稳定，迁移后经校验数据完全一致，很好的保障了业务的迁移及数据同步：

▶︎ 无需业务改造：DTS通过创建全量+增量同步链路，将阿里云PolarDB MySQL作为中转，实现了数据从AWS Aurora PostgreSQL同步至阿里云ClickHouse的效果，整个过程DTS会自动在目标端创建同名表，无需用户进行建表语句的改造。

▶︎ 链路稳定高效：DTS全量迁移可以达到275MB/s，137W RPS；增量迁移可以达到50MB/s，20W RPS，帮助用户对源端多年、多市场的海量历史行情数据进行稳定高效的迁移。

▶︎ 支持多表合并：通过DTS内置的多表合并能力，可以在迁移过程中完成将PostgreSQL中128张分表中的历史交易数据，合并存储到目标端ClickHouse中的1张表中。

▶︎ 支持字段类型转换：DTS同步过程中支持对源库字段格式的修改，借助这一能力实现了PostgreSQL中varchar类型到ClickHouse的Decimal类型的升级。

4.2 基于阿里云ClickHouse的新架构

改造后的架构如下图所示，可以看到除了原来在PostgreSQL中的新加坡、香港和A股的数据全部迁移到了ClickHouse之外，原本存放在Redis和DynamoDB的美股和期权数据也都被统一进了ClickHouse当中，得益于数据存储技术栈的统一，不同市场数据写入的目标端和数据查询的源端都得到了统一，上游的数据写入和数据清洗业务也因此得到了大幅度的简化，具体改动如下:

▶︎ 历史行情数据的存储统一进了ClickHouse当中：原先存储在PostgreSQL中的沪深市场、中国香港交易所、新加坡交易所数据，和存储在DynamoDB和Redis中的美股期权数据、美股历史数据，都迁移到了阿里云ClickHouse，利用ClickHouse的列存优势，提升存储压缩率约5倍，降低存储成本；利用写入性能优势，在未优化攒批逻辑的情况下，单表写入速度较PostgreSQL可提升10倍，轻松支持美股和美股期权百万标的并发写入量。

▶︎ 日内行情数据的存储利用ClickHouse实现了成本优化：从单Redis存储升级为Redis+ClickHouse共同存储， Redis仍作为实时行情数据的主要存储介质，ticker级别的数据写入则升级为使用ClickHouse，降低了实时行情数据的存储成本

▶︎ 行情数据分析业务使用ClickHouse降低了开发工作量：利用ClickHouse引擎内置的聚合函数，代替统计计算代码的定时任务，满足所有市场成交明细的写入、数据回测和简单计算分析，降低数据分析和清洗的复杂度。

业务价值

目前长桥已经使用ClickHouse替代原有的DynamoDB、PostgreSQL、Redis+定时任务的业务模式，可同时满足数据高并发写入、低成本存储、支持简单分析回测三类诉求，简化了技术栈，大大降低了开发运维的压力，同时性能上也有了大幅度的提升，具体表现为：

▶︎ 存储成本降低4+倍：原PostgreSQL实例数据量在不含美股和期权时已达到500GB，而迁入ClickHouse后，由于与国内交易不活跃的股票k线图相同的特性，ClickHouse的列式存储和多种压缩算法的优势得以充分发挥，仅仅100GB就可以满足所有市场的数据存储，存储成本降低4+倍。

▶︎ 写入性能提升10+倍：在未进行任何攒批逻辑优化的情况下，ClickHouse的原始单表数据写入速度相比PostgreSQL已经提升了10倍，能够轻松支撑美股期权百万标的的并发写入量，预期后续在进行攒批逻辑优化后还可以进一步提升。

▶︎ 业务复杂度大幅降低：利用 ClickHouse 内核预置的丰富窗口函数和多样聚合函数，用ClickHouse的单表查询替代了原架构中对128张PostgreSQL表点查再结合代码的统计计算任务的形式，进行数据回测和简单计算分析，数据管理复杂度降低128倍，单次查询数据量增加到原来的300%+，数据存储技术栈从3个减少至1个。