Greenplum在HTAP场景下的优化和应用 yMatrix
大家早上好，我是四维纵横（https://www.ymatrix.cn)联合创始人高小明。创立四维纵横前我是Greenplum全球产品总监，领导Greenplum北京产品团队，并兼任Greenplum内核团队的产品经理。
今天非常荣幸和大家一起探讨HTAP和Greenplum（简称GP）。在2015年Gartner提出HTAP概念后，陆续有多款产品声称有HTAP能力。但技术圈也有一些声音，认为还没有一款数据库产品真正实现HTAP。Greenplum 6.0 于2019年发布后很受欢迎，一些客户在发布一两个月后就测试上线，吸引他们的特性就是Greenplum 6实现的企业级大规模HTAP能力。今年我和我们同事也写了一篇介绍Greenplum 6.0 HTAP的论文，已被数据库领域的国际会议SIGMOD接收。所以Greenplum的HTAP特性已被产业界和学术界所同时认可。接下来我就结合Greenplum 6 HTAP特性研发和应用的经历，分享下我们对数据库HTAP的认知。
我的分享主要包含这样四部分内容，首先讨论下HTAP的来龙去脉，接下来介绍下GP的AP特长和针对HTAP需求的优化，后总结下HTAP的适用场景和客户的实际案例。
这张图可能大家都比较熟悉，业务应用对接一个专门的交易型数据库，产生的数据通过ETL定期导入到分析型数据库，然后分析人员使用类似Tableau这样的BI软件访问数据库，生成各种报表，供企业管理者和决策者参考，制定企业发展的新目标和新措施，指导业务应用做相应的调整。这是上世纪90年代数据分析和分析型数据库崛起时，大家就在用的架构，到今天为止，很多企业依然在使用这样的TP和AP分离的模式。 与此对应的，TP和AP数据库因为专注在各自领域，所以发展出了许多不一样的特征，例如TP数据库需要高效处理数据的增删改查，AP数据库需要高效的批量加载能力，TP数据库需要快速的点查，AP需要扫描大量数据的使用多表关联和子查询的复杂查询。为了支持这些不同特征的查询，AP和TP数据库也各自应用了不同的技术，例如TP依赖索引实现高效点查，使用行存实现高并发增删改，AP使用列存和压缩技术处理大数据量下仅需要扫描部分列的需求，减少磁盘空间和IO。
不仅仅是TP数据库和AP数据库分离，在这种架构下，交易业务和数据分析也是分离的，分析本质上是交易后分析。业务、分析、和决策人员也是完全分离各司其职，形成一次分析-决策-业务变更的迭代需要较长时间。
三十年过去了，很多情况其实都发生了天翻地覆的变化。个大的变化是数据分析在应用的广度和深度上都有了质的提升，也对数据架构提出了新的需求。
第二个变化是服务器的价格下降，而存储和计算能力大幅提升。现在的PC服务器性能在某些方面开始接近2000年前后流行的小型机，而折算后价格却只有当时的1/100。如果用同样的成本搭建一个集群，那么计算能力可以达到小型机的数百倍。
第三个变化是数据库技术在大踏步发展，也在不断相互学习和融合。单机上利用多核并行、索引、物化视图、各种查询优化技术等提升性能，分布式技术和分布式事务也非常成熟。
基于这些需求、软件和硬件的变化，Gartner在2015年提出HTAP，倡导将AP和TP技术融合，利用充足的内存为交易应用提供低延迟的性能保证。类似，另一家知名咨询机构Forrester也提出了类似的概念称为Translytical数据平台。平时大家说的混合负载在狭义上也可以认为是讲同样的思路，这个提法更早，我在2010年ACM的论文中就看到混合负载的阐述。
Gartner提出的HTAP架构不仅是将AP和TP数据库合二为一，而且是提倡在单一数据库上TP和AP应用的融合。这种HTAP架构相对于传统AP和TP分离的模式，好处显而易见。个好处是不再需要ETL和相关的逻辑，这部分工作常常不显眼，但是开发和维护成本很高，需要处理各种情况支持多种异构系统。长久以来大家为了减少ETL的数据导入延迟，想了各种办法，包括实时数仓和流式加载，但都是治标不治本，将AP和TP合二为一将数据延迟降为0才是终极方案。第二个好处是业务和分析一体化，业务数据实时保存在数据库中，业务处理前、处理中和处理后都可以借助数据分析提升用户体验和降低风险，可以通过同一套语言在同一个事务中完成分析和交易。第三个好处是业务人员、分析人员和决策管理者共享同一份实时全量数据，这不仅可以加速业务创新和迭代的速度，也可以避免日常经营因为大家看到的是不同的数据、不一致的数据而引起的沟通协作困难。Gartner特别强调了内存的独特重要性和对延迟对分析的影响，这一点我不是完全认同。在我们的实际经验中，基于数据的缓存搭配索引、结合资源管理，完全可以把延迟控制在毫秒级，而分析性能的保证来自内存、计算包括优化多个方面，当然内存多多宜善。
看到HTAP这么好，那大家肯定也想到一个问题，究竟一个数据库能不能既有很好的TP能力也有非常卓越AP特性？在HTAP概念出现后，少说也有十几款产品宣称可以支持HTAP。大的类别上，有原来做TP的产品增加了AP能力，这一类比较多，有原来擅长AP的产品增强了TP能力，这一类比较少，也有产品宣称就是从零开始为HTAP场景开发。值得一提的是，许多NoSQL数据库和SQL on Hadoop产品如Hive/Impala也因为可以支持行级更新删除操作或者引入了事务支持，而宣传HTAP能力。
这是微软去年底宣传的一个产品叫Cosmos, 在增加了列存和可以对接Spark后，声称有很好的HTAP能力。有许多产品采用类似的思路，在存储层支持分析型数据库常用的列存方案后，借助Spark完成HTAP的转型，Spark像一个-钥匙，分析能力不足就用Spark来凑。我个人认为这种产品组合的方案，并没有很好的解决HTAP试图解决的问题。点，虽然减少了ETL相关的组件和工作，但是引入了Spark集群这个更复杂更庞大的组件，学习、使用和维护成本都很高。第二点，虽然数据在一起了，交易和分析操作需要通过不同的语法和系统，很难在同一应用或者同一事务中完成交易和分析，极大的限制了HTAP的应用和分析对业务的帮助。
这里列的是我认为一个HTAP数据库应该具有的能力和评测方法。我相信只有同一系统同一事务才能提供更好的HTAP特性，才能让分析成为业务逻辑的不可分割的一部分，成为影响业务路径帮助业务取得更大增长的关键环节。这是改变过去数据分析仅仅针对交易后数据的事后分析，而转变为可以针对交易前和交易中的数据进行事前事中分析的有效方式。评价HTAP数据库的性能，需要综合使用评价TP性能的TPC-B、TPC-C基准，评价AP性能的TPC-H、TPC-DS基准，以及评价混合场景的结合了TPC-H和TPC-C测试的CH基准（https://github.com/citusdata/ch-benchmark）。
所以总结下，HTAP是技术发展和需求变化的自然趋势。自然界有很多物质具有波动性，也有很多物质具有离子性，但同时具有波动性和离子性的物质少之又少，光是一种特殊的具有波粒二象性的物质。类似的，HTAP数据库在我看来，存在但不会很多，原因是挑战很大。做过数据库的人都了解，数据库本身是个复杂度高、技术难度大的产品，无论AP还是TP，想要做好做稳定都需要几年到几十年的持续投入。的TP，的AP，加上针对混合负载的的资源管理，才可以称的上是的HTAP数据库。
讲了这么多关于HTAP的话题，我们来看看Greenplum的故事以及它和HTAP的渊源。Greenplum是在2003年开发的基于PostgreSQL的MPP数据库，当时基于PostgreSQL 7。在2015年Greenplum开源，并持续升级PosrgreSQL的工作，到Greenplum 6发布的时候，内核版本已经升级到9.4.
在OLAP分析和数据仓库领域，Greenplum一直有着良好的口碑。这是Gartner在采访了大量数据仓库用户后发布的排名，可以看到Greenplum是全球排名第三的数仓产品，是前十名中的开源产品，仅次于老牌的Teradata和Oracle，而这两家公司都是在上世纪七八十年代就创立的，积累了大量存量用户。Gartner在给出排名的时候，也附加了一些评论，其中一个评论说Greenplum在四个类别中都评分很高， 这反映了今年数据分析市场的一个重要趋势: 重新发现。如果大家还记得前几年铺天盖地的Hadoop产品和技术宣传，就能体会这个评价的公允和价值，很多用户在折腾了一圈后忽然发现用了Greenplum又快又省心。类似于文艺复兴时期，大家在经历了中世纪的黑暗后，重新认识到经典的古罗马艺术和古典文献的价值，重新学习和发展，开启了人类文明的新篇章。第二个评论是说Greenplum的强大能力被很多客户所认可，进而也推动了MPP技术被业界的认可，虽然Impala和Presto等产品都是MPP架构，但Greenplum是这种架构的集大成者。第三个评论说，相比其他产品，Greenplum被更多的应用在了关键生产系统中。国家工信部下属的中国信息通信研究院专门制定了针对MPP架构分析型数据库评测标准，推动这一架构和技术的进一步发展。2019年的数据显示，在参与评测的14款产品中，有43%是基于开源Greenplum的。由此可见，无论是在国内还是国外，Greenplum已经成为OLAP数据分析领域的标杆产品。
左边这张图高度概括了Greenplum架构，集群被分为主节点层和数据节点层，主节点作为系统入口负责用户认证、元数据管理并接受用户查询请求，在对查询做了解析和生成执行计划后，把执行计划派发到相关数据节点，等到数据节点完成数据扫描和一系列计算后，主节点再收集结果做一些必要的汇总返回给客户端。无论是主节点还是数据节点，都可以通过添加和启用备份或者镜像实现高可用。这个架构逻辑清晰中间环节少，延迟低，是我们可以很好支持HTAP场景的一个重要因素。分布式数据库因为难度太大，用户场景多样，导致看似冲突的需求要同时满足，例如关系模型和半结构化非结构化模型、分布式可扩展与简单易用、还有我们今天着重讨论的事务能力与分析能力，很多数据产品在这里做了取舍，而Greenplum研发团队做了大量工作，可以同时支持这些对用户至关重要的特性。
我们专心在AP领域耕耘20年，让Greenplum在多个维度上都大幅领先其他类似产品。在列存的支持上，除了支持多级分区、列级自定义压缩外，我们支持对列存表的行级更新和删除，而且插入、删除和更新都支持严格的跨节点分布式事务一致性，这是很多列存数据库所欠缺的一大块功能。在SQL特性上，Greenplum支持丰富的类型、语法和从SQL92到SQL2016中各种功能，支持窗口函数、嵌套子查询和数据立方体等，许多从Oracle和Teradata迁移过来的用户都惊奇的发现, Oracle和Teradata的几乎所有语法和功能都可以在Greenplum找到对应的语法，足见Greenplum在SQL能力上的强大。不仅仅支持，还可以让复杂的分析查询跑的飞快，这主要归功于Greenplum在复杂的多表关联、相关子查询上的优化特长，再加上静态和动态的分区裁剪，让一些在其他数据库中需要几十分钟的复杂查询可以在这里一分钟内完成。Greenplum还支持数据库内机器学习，支持海量数据在本地完成分布式并行模型训练和应用，这几年越来越多的数据库都开始支持类似的特性，譬如BigQuery ML。Greenplum也支持丰富的数据格式和数据源，支持各种语言的交互和存储过程，生态完备，成熟稳定。所以Greenplum是一款全面、成熟而高效的分析型产品，这也是为什么GP是很多客户在AP场景下的首要考虑产品。
GP把强大的功能隐藏在系统内部，给用户提供了简单的交互接口。对于数据存储，在创建表时可以指定分布键，如果不指定系统会自动选择一列作为分布键，插入的数据就会按照分布键做哈希均匀分布到各个数据节点，这对数据插入和查询的速度都很重要。分布式系统的性能总是受限于反应慢的那个节点，慢可能是因为数据倾斜或者计算倾斜造成，但首先要避免数据分布不均匀而形成的数据倾斜。如果不指定分布键或者系统找不到合适的列做分布键，那么这张表就会是随机分布，随机分布的表没有数据倾斜问题，但对HTAP场景不友好，后面会讲到原因。这个建表语句将订单表按订单号分布了。
查询在进入GP主节点后，将根据所涉及的表的数据统计信息，按照代价模型生成优的查询执行计划。可以看到对于订单表和客户表，因为分布键的不同，在个数据节点上的订单表数据可能需要和第二个数据节点上的客户表数据关联，这就需要动态的把需要关联的数据分发到各个计算节点上，具体的分发方式可以是把这客户一张表重新哈希分布下，或者如果客户表较小，可以把完整的客户表广播到各个数据节点，具体的数据分发方式包括上面的关联方式，都是系统根据代价模型自动选择而用户不需要关心。这里我们为了演示自动数据分发，特意将订单表按ID分布，如果客户下单比较均匀，也可以考虑将订单表按照客户ID分布，这样需要关联的客户表数据就在同一个数据节点了，从而不需要这样的动态数据分发。
在执行模型上，GP会在各个节点上启动一系列进程来协同完成查询。系统会以查询计划中的数据移动算子为边界，将执行计划切分为一个一个slice, 执行同一个slice的不同节点上的进程称为一组gang。在查询执行结束后，这些进程会被缓存一段时间以便同一会话的下一个查询可以复用，减少启动开销。如果超过系统设置的一个空闲时间，这些进程就会被回收给新的会话或者其他会话使用。GP这种基于进程的执行模型是也为我们细粒度查询级别的资源管理提供了方便。
简单介绍两个GP的SQL特性。这个例子是制造领域常见的一个查询，想要找出一个产品所依赖的所有直接和间接零部件以及他们各自的数量。这里我们通过GP支持的递归CTE实现，它本质上将关系数据表动态转换成了一个树状结构输出。GP支持XML和JSON等层次嵌套数据类型，动态转换是对类型的更友好支持。据我所知，全世界也仅有少数几款分布式OLAP/HTAP产品支持这样的递归CTE查询。
窗口函数是分析场景中经常要用的一个功能，可以动态或者静态对数据集进行分组，然后在分组内进行排序、取平均值、大值等各种计算。这个例子是计算出每个员工在自己部门的工资排序。大家可以想象下如果没有这样的SQL特性，如果使用代码完成类似的功能，需要多少代码量，效率又会如何。
限于时间关系，我们对GP的AP能力就介绍到这里。简单来说，GP的AP能力很强是大家公认的，在世界各国用户也很多，几乎不分行业，泛金融、互联网、制造、能源、政府、医疗等各行各业都可以看到大规模部署应用。在成百上千的数据竞争产品中可以有这样的普及率和认可度，也是超过我们的预期。
接下来我们聊一下Greenplum在HTAP场景下的优化。针对前面分析的HTAP需求，我们着重在事务、并发、存储和资源管理四个方面做了优化和增强，以便GP可以更好的支持TP和HTAP场景。
关于分布式事务，一直有一些观点认为没那么重要，或者在AP等应用领域不重要。我个人认为这是一种误解。过去几十年信息产业飞速发展，各种应用方便了大家的生活改变了许多产业和商业模式。在这些应用背后都有数据库的贡献，数据库把数据共享、并发操作、数据相关的错误处理通过事务完美的解决了。除非你的应用场景没有并发，或者数据丢了错了重了无所谓，你可以使用没有事务支持的数据库。否则你好使用一个完整支持事务的数据库，HTAP场景更是如此，不然你只是在给你的明天或者你的同事找麻烦。
还有一个问题是很多产品都宣称支持分布式事务，但事实情况是什么呢。以微软收购的CitusDB为例，在2017年发布的7.1版本中就声称支持完整的分布式事务。我创建了一个表T3，数据按c1列分布，然后使用pgbench压测插入操作，每个事务插入两行，这两行c2列有着同样的值。在数据插入的过程中，新起一个会话不断查询同一c2值只有一行的情况。在有完整ACID事务支持的情况下，同一c2值只能是偶数行，不应该出现只有一行的情况，如右边greenplum所示。而CitusDB则不同，会出现一定量行数为1的情况，这说明并发执行的查询语句看见了插入事务的局部操作，事务没有隔离性，也不具有一致性，是一个只支持AD的事务模型。
类似的，CitusDB也不支持可重复读这样的隔离级别，这是TP场景常见的需求，甚至重要到被MySQL设为默认隔离级别。可以看到，在CitusDB中，即使你设置了可重复读这样的隔离级别，在同一事务中同一查询语句也可以看见其他事务的执行结果，破坏了可重复读的语义。更危险的是，你设置这个隔离级别的时候系统并没有报错，所以你可能在不知情的情况下造成不符合预期的结果。 形成鲜明对照，Greenplum是支持可重复读隔离级别。 可以说，Greenplum是分布式数据库中事务模型完整严格的数据库之一。
GP在保证事务完整和数据正确的前提下，也会对经典的2阶段提交进行优化。在分布式两阶段事务中，各个数据节点在完成各自操作后，主节点会协调完成PREPARE和COMMIT两步来确认事务的提交。对于只在一个数据节点上进行的增删改操作，我们将其简化为一阶段提交，避免了PREPARE过程。GP可以做到这一点的原因是主节点可以根据数据表的分布键定义，判断一条语句是否只涉及到保存在一个节点上的数据，对于这种情况，就直接派发到该节点，并根据一个还是多个数据节点有更改操作来确认是否可以安全避免两阶段提交，执行一阶段提交，通过减少一次网络交互提高TPS。许多TP场景根据主键的增、删、改操作都可以从这一优化中受益。
GP可以提供高并发的增删改查操作，得益于完整继承PostgreSQL HEAP表的特性并在分布式集群中拓展应用。从功能上既可以高效支持大批量的插入、更改和删除操作，也可以高效支持单行的操作。单行操作可以只持有行级锁，支持更新主键、分布键。可以创建各种索引加速查询，可以利用现代机器大内存提供的缓存减少磁盘IO尤其是随机IO。 每次事务提交都需要在各个节点把事务日志刷写到磁盘，借鉴上游PostgreSQL的优化思路，GP也在分布式事务中实现了一次刷新多个事务的组提交功能，减少持锁竞争和刷盘频率。借助这些特性和优化，GP可以很好的支撑TP场景所需要的高并发低延迟需求，GP也制定了长期兼容合并上游方针，可以预见，随着版本的迭代，TP特性会越来越强。
前面提到GP可以在更新删除时只持有行级锁，这在单机环境下很容易做到，但在分布式系统中比较麻烦。如左图所示，如果有两个事务同时运行，试图以相反的顺序更新同样的两行，当这两行数据恰好分别在两个数据节点上时，这两个事务就会形成分布式死锁，事务A会在1号数据节点上等待事务B完成，而事务B又会在0号数据节点上等待事务A完成，实际上两个事务因为互相等待都无法完成。在一个繁忙系统中，如何及时检测发现这样的死锁，不误报，不漏报，对运行中的查询包括很多毫秒级的小查询做到几乎零干扰，是一个很大的挑战。 我们在PostgreSQL提供的单机的局部死锁检测功能基础上，开发了轻量级分布式死锁检测功能。由主节点定期异步的从数据节点收集各个节点的超时锁等待关系，借助巧妙的算法判断系统是否存在分布式死锁。
我们将等待关系分为实等待和虚等待两类，实等待是持锁事务结束后才能释放锁并解除等待关系，虚等待是有可能在事务结束前随时变化或者消除等待。对于从各个数据节点收集上来的事务等待关系图，会拼接成一个全局的等待关系图，然后通过右边的算法尝试逐个将事务从等待关系中移除，如果后还有事务等待并且事务也没有结束，我们就知道这里有一个死锁，需要报告并终止其中一个事务来打破死锁。 在我们的实测中，这个算法可以检测出所有分布式更新删除而引起的全局死锁，同时对其他事务的延迟和TPS无影响。
GP对HTAP场景支持的重要方式是针对不同温度的数据提供多种存储格式，而在逻辑上通过分区表给终用户提供单一表的访问接口。具体来说，你可以建一个名字为Sales的分区表，对于当月或者近三个月的热数据创建为行存的子分区表，提供高效的增删改操作。待数据稳定后，将其转化为列存，并进行压缩。行存表和列存表在GP中是同样重要的一等公民，用户可以在一个查询或者一个事务中同时直接操作行存和列存表，也可以通过Sales表透明的访问底层行存和列存分区表，由优化器根据查询语句动态对需要访问的分区进行裁剪，既方便又保证性能。行存和列存可以互相转化，都可以收集全局的统计信息以被查询优化使用。
一旦有TP和AP负载同时在系统中运行，资源抢占和隔离是需要解决的一个关键问题。在GP6之前，部分用户反馈系统中每当出现大的分析型查询时，就会占用太多系统资源，导致小查询延迟变大为原来的十倍或者数十倍。 为此，我们开发了细粒度的资源管理特性，可以对CPU和内存资源进行有效管理，既能保证不同业务的查询满足特定的SLA需求，又可以在不冲突的情况下充分利用系统资源加快查询执行。如左边这张图所示，我创建了big和small两个资源组，分别分配了60%和20%的系统CPU。可以看到，在small组没有查询时，big组中的查询可以使用近80%的cpu资源，而当small组有查询运行时，big组的cpu使用量会回退到大约60%，让small占有近20%的CPU资源。类似的，当big组没有查询运行时，small可以使用多达80%的CPU来快速完成查询。右图是我们提供的另一个保证查询延迟的特性称为cpuset，cpuset可以将特定编号的cpu核分配给一个资源组，这样这个组的查询将可以独占使用这些核而不用和其他组共享。可以看到，无论是系统cpu繁忙还是空闲，在分配了两个cpu核后，总是可以保证测试组内查询延迟保持在20毫秒左右。
我们的CPU资源管理是建立在Linux的cgroup特性之上，使用与容器技术同样的内核特性，相当于为一组用户查询建立了一个容器化的环境，实现资源隔离，对于每一个数据库的资源组，都会建立一个对应的cgroup组，然后将相应的查询进程关联到cgroup组，由Linux在调度进程时按照设置的资源分配动态调整。GP和PG都是基于进程的查询模型，不同查询有独立的进程，刚好对cgroups的资源管理友好。我们也同时实现了在不中断查询执行的情况下，动态将查询从一个资源组移动到另一个资源组，以及在不影响现有查询继续执行的前提下，动态修改资源组的cpu和内存分配，让资源组的资源占用逐步达到修改后的设置。
内存是另一个重要的系统资源，有一些HTAP数据库对内存有很强的假设和依赖，这样的产品在数据小于内存时性能不错，但在原始数据或者中间数据大于可用内存时性能衰减的特别夸张，甚至引起系统奔溃。GP在内存的管理和使用上秉持充分利用但不依赖的原则，在系统资源充足时可以充分利用内存提高速度，但在内存资源不足时依然可以借助磁盘完成查询。在左边的例子中，通过调小statement_mem到125M，模拟内存不足的情况，查询使用磁盘完成外部排序，耗时6秒多。右边的例子中，通过调大statement_mem到512M，模拟内存充足，使用内存完成排序，查询变快点耗时减少1秒多.
GP提供的内存管理是全方位立体式的，可以在segment级、资源组和单个查询上限制内存用量。同时，为了充分利用资源避免一些组分配了资源但没有查询运行而浪费资源，在segment级和资源组内建立了两级内存共享机制。如右图所示，在创建了这样一个资源组后，系统的4个segment会均匀分配全局GUC memory_limit所分配给系统的内存。在一个segment内，sample组会有预定的额度，并分为组内共享和查询独占两部分，这样就可以避免先执行的查询占用全部资源，导致后来的查询没有一点内存而立即失败退出。
在实现了这么多功能和优化后，GP 6在TP性能上有了质的飞跃。在谷歌云 5台普通虚拟机上测试TPC-B，单条SELECT的TPS可以达到8万每秒，比GP5提升3.5倍，单条更新的TPS可以到近8000每秒，比GP5提升70倍。类似的，单条插入和多条语句的组合事务都有很大的提升。
在AP和TP混合场景的测试中，左边的图可以看出在有100个TP并发的时候，AP查询的吞吐被明显限制。右边的图，从上向下，显示了在为TP负载分配了不同的越来越多CPU资源时，查询的平均延迟明显降低。这都是资源管理有效发挥作用的例证，也说明HTAP负载在GP中可以和谐共存。
在很多场景下GP6的TP特性已经可以满足需求，如果你的业务需要更高的HTAP性能，可以考虑MatrixDB。MatrixDB是基于开源GP并为时序场景和HTAP增强优化的产品，为物联网、车联网、工业互联网等提供一站式数据平台，过去很多时序应用都同时需要关系数据库、时序数据库和分析型数据库，MatrixDB可以一个顶三个，在单一数据库中完成时序全场景功能。它提供了行列混合的新存储模式，也加入了一系列优化，可以在云端秒级部署大规模集群，也可以在边缘端1G的低配设备上部署运行。时序场景中经常需要管理设备，关心设备新值，类似带索引的点查，这些都属于TP型负载。与此同时，又需要针对收集的数据进行分析，帮助诊断问题和预测维护，属于典型的AP分析负载。 所以，时序在我看来就是一种HTAP应用场景。MatrixDB在TPC-B和TPC-H上都有很大增强，在我们的测试环境中，TPC-B单条查询的TPS已经可以到30多万每秒，是Greenplum的三倍多，超过了单机PG。TPC-H基准测试在Greenplum性能的基础上再提升4倍。
特别是对于HTAP场景中常见的单表聚合和带条件过滤聚集，即将在五月份发布的MatrixDB 4.0可以提升超过130倍以上，把一个3-5秒的查询的执行时间大幅度降低，只需要二三十毫秒。
后，我们来总结下，HTAP适用于哪些场景。我建议从这四个角度去考虑采用HTAP的架构。一是针对一些使用OLTP数据库的应用，例如MySQL、Oracle或者PostgreSQL，如果应用本身在使用一些复杂的偏分析型的查询，这些查询运行太慢，那么你就可以考虑使用HTAP数据库代替。在提供同样量级TP性能的同时，让这些分析型查询会运行的非常快。我们的一个用户在使用MySQL，一个查询需要10多分钟，试用MatrixDB后，只需要100多毫秒。另一种应用场景是OLAP领域，例如你在使用Hive或者Impala等数仓产品，希望支持高并发的即席查询，或者通过近实时的增删改实现实时数仓，这时候你实际上需要在OLAP数据库叠加OLTP特性，那么你可以考虑HTAP数据库。第三种情况是从应用的角度，分析应用的特征和相关的SQL特征，如果属于典型的AP和TP混合场景，那么不用犹豫可以直接使用HTAP数据库。后一个角度就是从资源利用率的角度分析，如果你有一个TP的集群，又有一个AP的集群，如果可以通过整合资源提高资源利用率，或者AP和TP的高峰时期刚好错开，让TP和AP都可以用更多的资源运行的更快，那么就是采用HTAP架构的很好场景。
这是我国一家大型交易所，采用GP实施合规和反欺诈的HTAP应用实例，在这个项目中，既有每秒近300万行、平均延迟在170毫秒的高速数据实时加载，也有秒级的短小查询，同时还有很耗费资源的复杂分析合规检查，这么多不同类别的TP和AP负载通过创建不同的资源组进行有效隔离，互不干扰，都可以满足业务需求。
这是AWS云上一个客户的情况。用户过去使用PostgreSQL，随着数据量的增加，用户的很多查询变的很慢，在Greenplum 6发布后，用户尝试从PostgreSQL迁移到Greenplum，一开始效果不理想，反馈应用的数据插入很慢。在我们连线分析后，发现用户使用了低版本的驱动，连接串也没有附加reWriteBatchInsert属性，导致用户的spring ORM代码对每一行都执行一次数据插入操作，在正确调整后，GP6可以提供和PostgreSQL同等量级的数据插入速度，从而顺利完成迁移，用户的Spring和ORM相关代码几乎不需要修改。
Greenplum和MatrixDB都有活跃的社区，欢迎大家关注，欢迎分享你们的使用体验和建议，我们研发团队也在扩充中，欢迎有志于从事数据库内核尤其是分布式内核研发和智能化数据管理平台的同学加入，与我们联系(hr@ymatrix.cn)。这里也有我们SIGMOD论文的链接（https://arxiv.org/pdf/2103.11080.pdf），对技术实现细节感兴趣的朋友可以下载阅读。无论是Greenplum还是MatrixDB在HTAP上都在持续投入，不断增强HTAP特性和提高性能，我相信在不远的将来，大家会发现越来越来的应用实际上属于HTAP这样的混合负载场景，而使用一款HTAP数据库是个事半功倍的选择。
谢谢大家。
相关文章