临时起意的 HTAP想法，HTAP 是不是伪需求？

原创于 2025-09-25 06:00:22 发布 · 951 阅读

CC 4.0 BY-SA版权

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

HTAP到底有没有需求，这个问题大部分情况之前的我的想法是，还好吧，不是强需求。最近业务一次深入，直接打脸。 HTAP是强需求，且开发和架构大部分对于数据库陌生的还认为数据库无法做到这点，因为认知的缺失，导致数据，业务，开发，大数据等部门在这里“撞天婚”。

当前Saas行业已经内卷到报表的部分已经答应客户要进行即席查询，也就是数据写进去了，客户就要查出来。整体的业务架构因为这些许诺，做了很多的努力，但在做努力，缺陷是存在的，最近就遇到了这样的问题。

1 修改表的字段结构，导致数据传输量骤增的场景，让数据链路瞬间增加流量导致数据无法进行实时大数据的计算的问题。

在业务的迭代中，我们会遇到字段的扩展，这里无论是MySQL，PostgreSQL都会遇到修改字段类型导致的表重建的问题。比如你的表的字段从decimal(2,2) 修改成decmial(7,2)的情况下，表是要重建的，如果是一堆的表，一些大表已经到了30多G一张的情况，且一个实例中存在多个逻辑库，每个逻辑库都有这样的表，每张表都这么大，而业务要求一次性把这些表都要修改，那么问题就来了。

1 修改必然锁表，业务必然受到影响，客诉就没法避免了。

2 修改时，这些表都是同时触发，CPU IOPS 内存都在承受压力

通用的做法

就是分批来操作，新建表把要的表结构做好，然后通过数据同步的方式来进行数据重新灌入，在预定的时间来切换表，将老表下线，新表上线的处理方式，这和gh-ost，pt-osc 的方式类似，但实际上这样的新的方式更自由，切换的时间更灵活。

但是这产生了另一个问题，一个数据库实例会新增N个修改字段的临时表，且这些表都是大表，在这样的情况下，无论是 PG 还是 MYSQL 都会瞬间多出很多的日志涌向大数据的数据复制通道，在这样的情况下，数据延迟，大数据数据处理延迟等问题就出来了。

因为我们在做表字段的修改的情况下，都会遇到类似的问题，这里就会产生一个HTAP的需求，如果我们把数据传输的中间环节去掉，且数据就在源库上进行大数据处理，那么修改字段通过临时表的方案就不会影响到大数据的处理。

但为什么很多架构师对于这个在源库进行数据分析的想法都持否定观点。我们可以继续追根溯源。因为传统数据库的“无能”。

很多架构师在设计系统时，都会把 “分析” 和 “交易” 分开，形成一条标准的数据链路：业务库 → 数据同步 → 大数据处理平台 → 报表查询。在纸面上，这个模型看起来优雅又高可用，但现实是——链路长、环节多、数据一致性弱、延迟不可控。但是环节越长，产生的问题点就会越多。以数据库为例

表结构改动触发表重建

产生巨量写入和日志

日志一股脑挤爆数据同步通道

大数据那边全线延迟

客户那端只看到——“怎么刷新不出来了？”

然后就是投诉，投诉，投诉！！！

如果数据库本身可以进行HTAP中的数据分析，那么就可以达到

去掉复制延迟的中间环节数据落盘即查询，不用等数据复制到大数据平台后再跑 ETL。

架构简化少了一套同步服务，少了日志堆积点，少了中间层调度的锅。

灵活应对业务，突发表结构变更时，临时表的写入压力不会挤爆同步链路，因为分析和交易读取同源。

缩短问题排查链路，除了延迟问题，直接在源库查就知道是写入瓶颈还是计算瓶颈，不用在三套系统之间甩锅。

同时还存在另一个疑问主要是系统的资源的隔离，在运行OLTP的数据库上运行OLAP的分析，会大量消耗系统的资源，OLAP的资源消耗又要引起OLTP的资源不足，营销业务，所以这两个部分的资源隔离也是一个实现在一个数据库上进行TP AP的关键。

那为什么之前没有发现有强HTAP的需求，只能说一叶障目没有深入到业务当中，体会业务的真实需求。

但HTAP也要解决一些棘手的问题，比如资源隔离，多种索引的建立应对不同的需求，数据节点的临时扩展和收缩，满足HTAP的一些临时性能需求，与成本的最小化的要求。

这篇文章是是临时所想，先把问题记录下来，后续就是寻找解决方案，逐步满足业务需求，将数据库往HTAP的道路上引导，最后HTAP是不是潮流我不知道，但这一定是新型数据库的趋势，我要的价值是真正的价值不在于“技术多先进”，而在于它帮你少掉几个容易出事的环节，让你在凌晨三点的客户投诉电话里，能平静地说：“你现在查一下，数据已经在了。”

在写完这篇文章后，后续又遇到一些问题，在这里我更坚定的认为，对于中小企业HTAP完全是一个必需品，数据链路过长，导致个各种问题，小道限制你修改一个字段的类型，修改字段类型导致重建表，而重建大表会导致大数据消费的拥塞，最终影响业务，所以如果我们有一个HTAP的强力数据库产品，减少数据链路的长度，那么一连串的问题也就不存在了。