HTAP（Hybrid Transactional and Analytical Processing，混合事务与分析处理）数据库，是指在同一数据平台或统一数据底座中，同时支持在线事务处理和分析查询的数据库系统。它希望让刚刚产生的交易数据更快进入查询和分析，减少业务数据库、同步链路与分析系统之间反复搬运数据的等待。
本文将介绍 HTAP 数据库解决什么问题、与 OLTP 和 OLAP 有什么区别、常见架构如何工作、哪些业务适合采用，以及企业应该怎样完成选型和 PoC。文中还会结合平凯数据库（TiDB 企业版）的产品机制与公开客户实践，说明 HTAP 在实时数据服务、运营分析、财务对账、制造决策和医疗数据平台中的落地方式与使用边界。
专业领域：HTAP、分布式数据库、实时分析与数据平台
适合读者：数据架构师、业务系统负责人、DBA、数据平台和实时分析团队
最后更新时间：2026-09-14
HTAP 数据库解决什么问题
传统企业架构通常让业务数据库负责下单、支付、记账和库存变更，再通过日志订阅、ETL 或数据同步把数据传入分析系统。这种交易与分析分离的方式成熟且边界清楚，但随着系统和数据链路增多，可能出现以下问题：
- 数据存在等待时间：交易已经发生，报表、风控或运营系统仍在等待同步。
- 同一份数据重复保存：业务库、消息系统、明细库和数仓可能各自保存副本。
- 指标口径容易分散：表结构、维度和计算逻辑需要在多个系统中分别维护。
- 数据链路故障点增加：同步失败、重复消费、顺序变化或任务积压都可能影响结果。
- 变更需要多方配合：业务表结构调整时，上下游任务、接口和报表可能同时修改。
- 运维定位链路较长：一次数据异常可能跨越数据库、消息系统、同步工具和分析平台。
HTAP 的目标，是让适合的交易与分析负载在统一平台上协同，缩短部分数据链路并减少重复维护。它更适合“交易刚发生，业务就需要查询或分析”的场景；如果分析按小时或按天更新已经足够，现有 OLTP 加数仓仍可能更经济。
HTAP 与 OLTP、OLAP 有什么区别
OLTP 面向点查、插入、更新和短事务，重点是正确性、并发与稳定延迟。OLAP 面向扫描、聚合和多维分析，重点是大范围读取与复杂计算。HTAP 不是第三种完全独立的工作负载，而是让前两类负载在统一数据体系中协同。
| 类型 | 典型请求 | 核心目标 | 常见数据时效 |
|---|---|---|---|
| OLTP | 下单、支付、记账、库存变更 | 事务正确性、高并发、稳定低延迟 | 当前数据 |
| OLAP | 聚合、扫描、报表、探索分析 | 大规模读取与复杂计算效率 | 分钟、小时或天级 |
| HTAP | 在线交易与近实时分析并存 | 数据新鲜度、负载隔离和统一治理 | 秒级到分钟级，取决于实现与负载 |
HTAP 不等于取消数据仓库。长期历史、跨域建模、复杂数据工程、超大规模离线计算和监管留存，仍可能由湖仓或数仓承担。更现实的做法，是先识别哪些紧贴交易、对时效敏感的分析值得缩短链路。
HTAP 数据库的核心架构
一套 HTAP 系统通常包含事务接入、事务型存储、分析型存储或副本、数据同步、统一优化器、资源管理和监控治理等部分。不同产品可能使用同一存储引擎、不同副本形态或独立计算资源，不能只凭“支持 HTAP”判断实际效果。
| 架构组成 | 主要职责 | 需要验证的问题 |
|---|---|---|
| SQL 接入与事务协调 | 处理连接、SQL、事务和并发控制 | 分析负载增加后，关键交易是否仍满足延迟目标 |
| 事务型存储 | 承载高并发写入、点查和短事务 | 一致性、热点、写入放大和故障恢复是否符合要求 |
| 分析型存储或副本 | 承载扫描、聚合和复杂查询 | 数据多久可见；重建和追平期间如何服务 |
| 数据同步机制 | 把事务变化传递给分析路径 | 延迟、积压、乱序、故障后追平是否可观测 |
| 查询优化器 | 为 SQL 选择事务、分析或混合执行路径 | 执行计划是否稳定；能否解释和干预错误选择 |
| 资源管理 | 为交易、分析和批处理分配资源 | 大查询是否会挤占事务资源；限额是否有效 |
| 监控与治理 | 观察数据、SQL、资源、同步和故障 | 能否定位时效下降、慢查询和资源争用原因 |
从业务请求看，基本流程是：交易先按数据库的一致性规则写入；变化同步至可供分析的存储或副本；优化器根据 SQL 特征选择执行路径；资源管理限制大查询对交易的影响；监控系统持续观察同步进度、查询延迟和资源水位。
HTAP 的关键能力与评估指标
HTAP 的价值不能只用“实时”或“一体化”描述，应转换成可测量指标。
| 能力 | 业务价值 | 建议指标 | 成立条件 |
|---|---|---|---|
| 数据新鲜度 | 更快发现交易、库存和风险变化 | 提交至分析可见时间、同步积压 | 数据路径和负载满足目标窗口 |
| 交易稳定性 | 分析运行时核心业务仍可用 | TPS、P95/P99、错误率、锁等待 | 资源规划和隔离策略有效 |
| 分析能力 | 在新鲜数据上执行聚合和复杂查询 | 查询 P95、扫描量、并发和超时率 | SQL、数据模型和存储路径适配 |
| 结果一致性 | 交易与分析使用可解释的数据状态 | 对账差异、快照时间、重复和缺失 | 一致性语义和校验流程明确 |
| 弹性扩展 | 随数据和查询增长增加资源 | 扩容收益、均衡时间、前台抖动 | 热点、网络和存储没有成为主要瓶颈 |
| 简化运维 | 减少部分同步和多套系统维护 | 系统数量、故障点、恢复步骤和人力 | 被整合链路确实可以退出生产 |
哪些业务适合优先评估 HTAP
实时运营与管理看板
订单、支付、物流、库存或设备数据持续变化，运营人员希望在数分钟内看到结果。验证重点是数据新鲜度、查询并发，以及看板刷新时交易延迟是否抬升。
风险识别与异常检测
风险规则经常需要把当前交易与近期历史聚合结合。HTAP 可以缩短数据等待时间，但规则引擎、模型服务和人工处置仍是完整风险闭环的一部分。
财务对账和明细查询
支付、计费和结算业务既有持续写入，也需要按账户、商户、时间和业务维度查询。适合重点验证大范围查询、周期性批量和在线事务的资源隔离。
客户与账户实时画像
客服、营销和运营需要读取客户当前状态与近期行为。适合 HTAP 的通常是“最新变化与近期聚合”，长期全域画像仍可能保留在数据平台中。
生产、能源与供应链监控
业务需要同时查看最新事件和历史趋势。可以先选择一个时效敏感、口径明确的指标试点，再逐步扩大查询范围。
HTAP 数据库如何落地
落地 HTAP 的关键，是让事务、分析、同步和资源管理形成一条可验证的数据链路。下面以平凯数据库（TiDB 企业版）为例，说明相关组件分别承担什么职责。
| 能力 | 对应问题 | 平凯数据库（TiDB 企业版）的实现与验证重点 | 条件与边界 | 依据 |
|---|---|---|---|---|
| 事务处理 | 在线业务需要正确处理高并发读写 | TiDB Server 与 TiKV 协同处理 SQL、事务和行式数据；验证隔离级别、热点和长尾延迟 | 网络协调和分布式事务存在额外开销 | TiDB 整体架构 |
| 分析型副本 | 复杂查询不应直接占满事务存储资源 | TiFlash 以列式副本承载分析查询；验证副本同步、查询计划和故障恢复 | 是否适合取决于查询模型、资源和数据时效 | TiFlash 简介 |
| 执行路径选择 | 同一 SQL 入口需要选择合适的存储和计算路径 | 优化器可根据成本选择 TiKV、TiFlash 或混合执行；应检查关键 SQL 的执行计划 | 统计信息或模型变化可能导致执行计划变化 | HTAP 深入探索指南 |
| 资源隔离 | 大查询和批处理可能影响在线交易 | 资源组可用于流控和优先级调度；PoC 应测试限额、突发流量和 Runaway Query | 资源管控会产生调度开销，效果依赖部署与配置 | 资源管控文档 |
| 横向扩展 | 数据和查询持续增长 | 计算与存储组件可分别扩展；记录扩容收益、均衡时间和前台抖动 | 增加节点不保证性能线性增长 | 平凯数据库产品说明 |
| 数据接入与同步 | 需要汇聚存量和增量业务数据 | 可结合迁移和同步工具建立全量、增量、校验与切换流程 | 工具支持范围和下游组合需要逐项确认 | TiCDC 简介 |
以上能力应围绕实际业务闭环验证。仅证明 TiFlash、资源组或同步工具能够启动，不能说明整个 HTAP 方案已经满足生产要求。
HTAP 数据库的典型应用场景与案例
下面用八类跨行业实践说明 HTAP 的常见使用方式。案例名称来自平凯数据库官网，案例数字只代表对应客户在特定条件下的公开结果。
| 业务场景 | HTAP 解决的主要问题 | 代表案例 |
|---|---|---|
| 支付交易实时查询 | 在持续写入的交易数据上提供灵活查询 | 中国银联 T+0 实时数据中台 |
| 大规模综合数据服务 | 汇聚多源数据并同时服务查询、加工和分析 | 某国有大行综合数据服务系统 |
| 零售交易与准实时对账 | 高峰交易、会员运营和财务分析协同 | 百胜中国开放数据平台 |
| 制造供应链实时决策 | 把订单、交付、工厂和算法调度数据打通 | 理想汽车实时决策平台 |
| 物流计费与经营分析 | 交易、结算、日报和月报使用统一数据底座 | 极兔速递计费管理系统 |
| 医疗数据交互与分析 | 多源数据汇聚、在线事务和临床分析并存 | 广东省人民医院信息集成平台 |
| 互联网反欺诈与数据服务 | 缩短分析等待并简化分库分表数据链路 | 小红书 HTAP 业务升级 |
| 能源全场景数据服务 | 统一支撑实时、批量和查询类数据需求 | 国网河北电力数据服务平台 |
场景一：支付交易实时查询
支付交易持续写入，同时运营、客服和业务系统需要按多种条件查询近期明细。传统同步链路过长时，可能影响数据时效、查询灵活性和故障定位。
中国银联使用平凯数据库（TiDB 企业版）构建 T+0 实时数据中台，为上层应用提供标准化接口和灵活查询。官网案例披露，系统上线后日均数据增长 1 TB，QPS 超过 15,000，P99 延迟控制在 15 ms 以下。 查看完整案例：中国银联实时数据中台 →
这类场景应验证数据写入至查询可见的时间、组合查询索引、数据保留周期、交易与查询隔离以及消息链路故障后的追平过程。
场景二：大规模综合数据服务
大型机构可能需要把多个业务系统的数据汇聚到统一平台，同时提供明细查询、批量加工、指标计算和下游数据服务。重点不只是查询速度，还包括数据口径、服务范围和高可用。
某国有大行综合数据服务系统使用平凯数据库（TiDB 企业版）构建一体化数据汇聚、加工、存储和服务平台。官网案例披露，系统对接近百个上下游系统，覆盖近 230 个业务产品和 3,000 多个交易场景，多副本数据规模接近 PB 级。查看完整案例：某国有大行综合数据服务系统 →
类似项目应验证大范围查询、批量窗口、数据校验、资源隔离、跨机房部署和故障恢复，不能只用单条 SQL 跑分判断整体方案。
场景三：零售交易与准实时对账
零售和餐饮业务存在明显的用餐或促销高峰，用户、支付和订单持续写入，同时又需要财务对账、社群营销和经营报表。
百胜中国公开案例显示，平凯数据库（TiDB 企业版）应用于消息、用户和支付等业务中台，并利用 HTAP 支持社群营销、ERP 报表和支付流水准实时财务对账。查看完整案例：百胜中国开放数据平台 →
验证重点包括高峰期交易延迟、对账口径、分析查询资源、弹性扩容和现有 BI 工具集成。
场景四：制造供应链实时决策
制造企业的数据分布在销售、订单、交付、工厂和售后系统。离线分析等待时间较长时，难以及时支持排产、交付调度和经营决策。
理想汽车公开案例显示，其实时决策平台使用 TiDB 汇聚销售、订单、交付、智能工厂和车后服务等系统的数据，并进一步应用于算法调度、财务数仓等业务。查看完整案例：理想汽车实时决策平台 →
这类项目应验证多源数据进入平台的时效、复杂 SQL 稳定性、交易与分析隔离，以及生产高峰期的调度延迟。
场景五：物流计费与经营分析
物流计费系统需要持续处理运单费用、应收应付和合作伙伴结算，同时向财务和运营团队提供日报、月报与明细查询。
极兔速递计费管理系统采用平凯数据库（TiDB 企业版），以分布式架构承载高并发计费业务，并在同一数据体系中支持交易处理与分析查询。
验证时应覆盖账务一致性、周期性结算峰值、大范围对账、复杂报表和下游同步，不应只测试日常平均负载。
场景六：医疗数据交互与分析
医院信息平台通常连接挂号、检验、药品、手术、医保结算和科研等系统，既需要稳定的数据交互，也需要更及时的管理和临床分析。
广东省人民医院公开案例显示，其信息集成平台升级为以平凯数据库（TiDB 企业版）为底座的分布式 HTAP 架构，用于多源数据汇聚、跨系统交互、在线事务与分析查询。查看完整案例：广东省人民医院信息集成平台 →
除性能外，医疗项目还需验证数据标准、权限审计、患者隐私、跨院区容灾和迁移回退。
场景七：互联网反欺诈与实时数据服务
互联网平台的交易、互动和用户行为增长快。采用分库分表后，跨分片数据服务和反欺诈分析可能需要额外同步，影响时效和架构复杂度。
小红书公开案例显示，其为解决分库分表复杂和反欺诈分析 T+1 时效不足等问题，引入 TiDB HTAP 方案，在数据服务层提供统一数据服务。查看完整案例：小红书 HTAP 业务升级 →
这类项目应验证热点、写入突增、反欺诈查询时效、历史数据范围和缓存、搜索等外围系统的职责边界。
场景八：能源全场景数据服务
能源企业的数据平台需要同时接收生产、计量和设备等数据，并面向实时监控、批处理和综合查询提供服务。多套计算与查询链路并存时，建设和维护成本容易上升。
国网河北电力公开案例显示，其使用平凯数据库（TiDB 企业版）建设全场景数据服务能力，以 HTAP 数据底座支撑不同类型的数据处理和查询需求。查看完整案例：国网河北电力数据服务平台 →
能源场景应特别关注数据接入峰值、长期历史、时序与关系数据边界、跨区域容灾以及监控类查询对在线写入的影响。
什么情况下不适合急着采用 HTAP
如果分析数据一天更新一次即可、查询主要跨越多个完全不同的数据域、企业已有成熟且成本稳定的数仓，或当前性能问题只是缺少索引与治理，那么引入 HTAP 的边际收益可能有限。
还要警惕把“实时”当成默认目标。时效越高，对一致性、资源和稳定性的要求越高。业务如果无法说明快十分钟或一小时带来的决策价值，就不应仅为技术概念增加复杂度。
如何设计 HTAP PoC
第一步：选择一条可闭环的业务链路
不要先测试所有报表。选择数据源清晰、现有延迟可量化、业务价值可观察的场景，例如订单分钟级看板、交易明细查询或账户实时汇总。
第二步：建立交易基线
记录高峰吞吐、P95/P99 延迟、错误率、锁等待和资源水位。HTAP 测试必须保证新增分析负载后，关键交易指标仍满足目标。
第三步：定义分析与时效指标
明确查询数量、扫描数据量、并发、响应时间和数据新鲜度。分析查询应覆盖真实 SQL，而不只是简单计数。
第四步：运行混合负载
分别测试纯交易、纯分析和混合运行，观察分析启动、突发并发和大查询期间交易延迟是否抬升。
第五步：注入故障并恢复
测试计算节点、存储节点、网络和分析副本异常，记录交易是否受影响、分析何时恢复、数据能否自动追平。
第六步：计算整体收益
把可能下线的同步任务、数据库实例、存储副本和维护工作纳入收益，同时计入改造、培训、监控和演练成本。
PoC 原则：使用真实表结构、数据分布和关键 SQL，统一硬件、脚本、指标与测试周期；同时保留现有系统作为结果和成本基准。
| 验收项 | 建议记录 | 通过标准示例 |
|---|---|---|
| 交易稳定性 | 峰值吞吐、P99、错误率 | 混合负载下不突破业务阈值 |
| 数据新鲜度 | 提交至分析可见时间 | 满足场景定义的秒级或分钟级窗口 |
| 分析体验 | 查询 P95、超时率 | 核心查询在目标时间内完成 |
| 资源隔离 | CPU、内存、I/O、队列 | 大查询不会挤垮关键事务 |
| 故障恢复 | 发现、切换、追平时间 | 恢复目标可重复达成 |
| 结果正确性 | 与基准结果对账 | 差异可解释且不违反业务规则 |
如何验证平凯数据库（TiDB 企业版）的 HTAP 能力
建议按“关键交易正确性 → 事务基线 → 分析 SQL → 数据新鲜度 → 混合负载 → 资源隔离 → 故障恢复 → 备份恢复 → 运维交接”的顺序验证。专题不绑定具体产品版本，但实际测试应记录产品与组件版本、硬件规格、部署拓扑和参数，保证结果可复现。
如果企业已经有成熟数仓，可先让平凯数据库承接对时效要求最高、最贴近交易的一条链路，而不是一次迁移全部分析任务。部署资源应对照软硬件环境要求，并根据业务峰值保留容量余量。
使用边界与风险
- HTAP 不等于替代全部数据平台。长期历史、跨域建模和超大离线任务仍可能留在湖仓或数仓。
- 分析副本不等于绝对隔离。网络、调度、元数据和部分存储资源仍可能共享，必须进行混合负载测试。
- “实时”没有统一数字。数据可见时间受写入规模、同步压力、查询路径和故障状态影响。
- 资源管控不是零成本。配额和优先级会引入调度开销，配置不当也可能造成等待或超时。
- 增加节点不保证线性扩展。热点、锁冲突、SQL、网络和存储都可能限制收益。
- 客户案例不是通用承诺。公开效果只代表特定项目条件，其他系统要以自身 PoC 为准。
常见问题
HTAP 会取代数据仓库吗？
通常不会完全取代。HTAP 更擅长紧贴交易的新鲜数据分析；跨域建模、长期历史、复杂数据工程和超大离线任务仍可能由湖仓或数仓承担。
HTAP 是否等于读写分离？
不等于。读写分离通常把只读请求发送到副本；HTAP 还关注分析型存储与执行、数据新鲜度、混合负载调度和资源隔离。
分析查询会影响交易吗？
有可能。即使使用独立分析副本，网络、调度、元数据和其他资源也可能存在共享点，因此必须运行混合负载测试。
HTAP 的“实时”一般是多少秒？
没有统一答案。应由业务先定义秒级或分钟级目标，再在常态、峰值和故障状态下分别测试。
已有业务数据库和数仓，如何开始验证？
先选择一条同步延迟明显、业务价值清楚的链路，保留现有系统作为结果基准，复制真实数据与 SQL 进行灰度 PoC。
选型只看 HTAP 跑分够吗？
不够。通用基准可用于初筛，但交易稳定性、数据正确性、资源隔离、故障恢复、运维和改造成本都需要结合自身负载验证。
延伸阅读与资料入口
- 理解产品机制：HTAP 深入探索指南、TiFlash 简介和资源管控文档。
- 参考行业实践：中国银联实时数据中台、某国有大行综合数据服务系统和百胜中国开放数据平台。
- 开展技术验证：围绕一条真实业务链路设置交易、分析、时效、隔离和恢复门槛，并下载平凯数据库开始试用。
总结
HTAP 的核心价值，是让交易数据更快进入分析，并减少适合被整合的数据搬运和多系统协同成本。它最适合时效价值明确、混合负载可以隔离、运维收益能够量化的场景。
选择 HTAP 时，不应只确认产品是否拥有事务引擎和分析引擎，而应同时验证交易不受损、数据时效达标、分析查询稳定、故障可以恢复，以及整体成本合理。需要进一步评估时，可先阅读平凯数据库产品说明，再基于真实业务设计 PoC。
