为了让更多的数据库从业者了解数据库领域的最新研究成果，了解行业更前沿的发展趋势，腾讯云数据库计划举办一场“DBInsights”系列活动，搭建数据库技术交流平台，邀请学术界和腾讯技术专家解读数据库基础技术创新趋势，分享数据库技术创新成果。此次为大家带来“DBInsights”系列活动第一期的部分内容。腾讯云数据库专家工程师朱跃安解读HTAP系统存在的问题与争议。以下为分享实录：问题与主义之争上世纪初胡适与李大钊的争论。胡适提倡改进，提倡解决每一个问题，即少讲主义，多研究问题；而李大钊主张改革，认为只有解决了这个根本问题，其他的问题才能解决。两者代表着两条完全不同的路线。事实上，围绕HTAP体系的演进，有两条相似的路线，一是完善，二是通过改革创建新的体系。今天给大家分享一下HTAP系统的技术实现路线。HTAP的定义和挑战我们先来解释一下HTAP的定义和挑战是什么。下图是一个经典的数据处理框架，其中我们将数据库系统分为两类：一种是事务型系统，是数据的来源产生的地方；另一个是分析系统，就是我们的数据仓库。数据会通过ETL的方式，有规律地从事务型数据库流向数据仓库，然后在数据仓库中进行分析处理，生成相应的报表和报表。企业的经营决策者可以通过分析报告和决策报表来观察企业的经营行为，从而观察未来的发展趋势。这是数据的珍贵性的体现之一。许多企业在数据基础设施上投入了人力物力，期望在数据变现中获得更好的回报。研究表明，这些样本公司每投资13，就有1用于数据分析，74%的公司希望成为数据驱动型公司。如果一家公司采用更先进的数据分析方法，那么它胜过竞争对手的可能性将增加一倍。数据分析具有巨大的商业价值。但是在目前的数据处理框架中，OLTP和OLAP系统是分离的，主要是通过ETL将数据从事务型数据库导入到分析型数据库中，ETL的延迟比较大，可以达到几十分钟到几小时，甚至几天.上图右下角的图表显示，数据的商业价值随着时间的推移而递减。数据通过ETL生成并导入数据仓库，在数据仓库中进行分析，然后做出决策并执行相应的动作。这时候，数据的商业价值就会大大降低。因此，理想情况下，数据可以在生成后快速进行分析。为了解决这个问题，HTAP系统应运而生。其初衷是打破交易处理和分析处理的界限，让企业通过HTAP系统更好地发现市场反馈，获得更好的创新。为什么如此先进的数据处理技术在近几年引起了人们的关注呢？我个人认为这主要得益于现代列存储技术的发展，HTAP系统的出现成为可能。以前客户用SQLServer做查询分析处理，需要十几个小时。在这种技术能力下，不可能满足实现HTAP系统的要求。后来SQLServer采用了列存储技术，原来需要十几个小时的分析可以缩短到几分钟，甚至可以秒级出结果。列存储技术及其背后的向量查询引擎的发展，让HTAP登上了历史舞台。HTAP让数据生成后立即进入分析场景。但它面临的最大问题是如何在一个系统上更好地运行OLTP和OLAP两种类型的工作负载。毕竟，这两种类型的工作负载在本质上是相互排斥的。Transactional交易为短交易，以书面形式为主；分析事务是长事务，主要是读取。他们经常需要进行全表扫描，并在扫描的基础上进行统计、聚合等操作。在这种情况下，OLAP事务往往需要独占系统资源，这就降低了事务性事务的吞吐量。研究表明，如果将OLTP和OLAP调度在一个系统中，OLTP的吞吐量可能会下降到原来的1/3到1/5。因此，如何在系统运行过程中尽量减少OLTP和OLAP之间的相互干扰，成为HTAP系统设计中的一个难题。从近十年的发展来看，HTAP的实现主要有两种解决方案：第一种是改进方法，对现有业务系统进行扩展和扩展，创建满足业务需求的HTAP系统；第二个是从头开始设计一个颠覆性的系统。当然，第二种方式会产生更多有价值的技术，也会涉及到更多的技术问题，包括技术突破、业务适配等。目前来看，很难说哪个更好，我们不回答哪条路线更适合今天的分享。我们将从这两条路线中选取具有鲜明技术特点的典型系统与大家分享，同时最后给出近十年来HTAP系统技术的演进过程和发展趋势。HTAP系统架构实践2.1HTAP系统的种类总的来说，HTAP系统架构的实践可以分为两类：一类是改革，一类是改进。前者采用Onesizefitsall的策略，用大而全的系统同时满足OLTP和OLAP的需求。后者采用Onesizedoesn'tfitallmodel，将OLTP和OLAP两个系统结合起来，采用CDC的方式将OLTP上产生的数据增量导入数据仓库进行分析。第一类又分为两个子类。第一个子类是单副本系统，在一个系统中使用一种数据格式满足两种业务需求，通常使用PAX存储。整个系统使用行存储，但是当它把数据打包到某个页面时，它会把它转换成列存储。另一种是双副本系统，行存和列存存在于一个系统中，行存的更新周期性的导入到列存中，转换成列存格式。分析在列存储上执行，更新在行存储上执行。这在一定程度上减少了他们的竞争。第二类又可以分为两个子类：共享存储和独立存储。四类系统在实现HTAP特性时的对比可以从两个维度来描述，一是数据的新鲜度，二是工作负载的干扰程度。Onesizefitsall策略将OLTP和OLAP工作负载放在一个系统上，如图1左上角所示。从干扰程度来看，OLTP和OLAP相互干扰最大，单系统单副本方法特别明显，其次是单系统双拷贝的方法。这两种实现的缺点是OLTP/OLAP的干扰会导致事务工作负载的吞吐量严重下降，但优点是数据可见性高，因为不需要同步导入导出数据或数据转换。一种尺寸并不适用于所有情况有两种类型的松散耦合模型。橙色椭圆表示共享存储下的松散耦合系统。好像还没有商用产品。只有IBM发布了DEMO；另一种是类似代理模式，是一个松耦合的系统，结合了TP和AP两个独立的系统。在这两类系统中，OLTP和OLAP是在两个独立的系统上进行的，这样可以最大限度地减少干扰，但是需要同步数据。事务数据库的更新数据必须通过CDC同步到分析系统。延迟会比较大。系统监控延迟20毫秒，网络游戏、个性化广告推荐、商品价格监控延迟在100-200毫秒之间。2.2Hyperwithsinglesystemandsinglecopy下面我们从四类系统的实践中选取一些具有代表性的系统，看看HTAP技术是如何实现的。第一个是超级。Hyper是一个典型的系统。它最初是德国慕尼黑工业大学ThomasNeumann教授团队开发的原型产品。但是它的性能和创新性太好了，以至于被美国的tableau公司收购，从学术产品变成了商业产品。产品在技术和经验上都具有很强的代表性。Hyper的查询执行模式非常复杂。OLTP是串行执行的，不需要加锁。这是因为典型的OLTP数据库将大部分时间花在锁定、缓冲区管理和日志管理上。这些操作消耗了大约80%的系统资源。在Hyper中没有这样的开销，事务是串行执行的，并且去除了维护事务隔离等开销。一个事务的串行执行时间只有微秒级，可以接受。VoltDB是一个类似的系统。事务执行也不需要加锁，串行执行（通过分片达到并行执行的效果）。OLAP使用fork生成子进程以在事务一致的副本上运行查询。更新时，复制相关的数据页，这样事务性事务就可以在不同的数据页上更新（Copy-on-Write）。另外，通过区分冷热数据，将数据分为热数据、冷数据和温数据。上图右下角，数据的访问热度是通过硬件来区分的，即MMU的内存管理单元。热数据放在普通页，即小页，冷数据压缩存储在4M大页。这种方式的好处是更新成本比较小，同时在做OLAP查询的时候，在大页面上会有更好的性能。Hyper的查询引擎也相当不错。它使用矢量化查询引擎并使用LLVM生成可执行机器代码。这个技术很有代表性，就连大名鼎鼎的Spark也提到了它的代码生成技术。2.3单系统单副本SAPHANAHANA也是采用单系统单副本来实现HTAP。它不太像一个数据库系统，更像是一个支持多种引擎和多种工作负载类型的统一数据管理平台。HANA系统的层次结构做得很好。一般来说，可以分为编译层和执行层。上层可以分为查询解析，生成抽象语法树AST，然后映射到计算图模型，再对计算图模型进行物理优化。之后，分布式执行框架构建实际的数据流，将具体的物理执行算子分发给具体的引擎执行。由于HANA支持数据仓库的查询引擎、文本引擎、图引擎等多种工作引擎，它为这些特定的引擎提供了物理算子，例如关系运算符和图计算算子。在执行引擎下，有一个统一的表模型。它向上提供了一个统一的接口，类似于MySQL下的handler接口。下面的存储引擎负责实现具体的存储。上面的查询执行器只要实现了处理程序接口就可以连接到系统。里面的存储分为三个层次：第一，L1-delta，对应热点数据和未压缩的行存储；其次是L2-delta，对应轻量级的压缩列存储，比如字典压缩；最后，L3-主存储对应高度压缩的列存储。更新发生在L1-delta，数据会量化导入Mainstore。Mainstore是一个读友好的实现，满足AP类型的查询，而L1-delta是一个写优化的实现。这样就满足了HTAP的需求。它会周期性的执行merge操作，周期性的将数据merge到Mainstore中。Main2和Delta2是在merge操作时产生的，读操作是在Main1、Delta1和Delta2上进行的。复制完成后，Main1和Delta1最终会合并到Main2中，最后切换过来，读操作发生在Main2上，写操作发生在Delta2上。数据锁定的行为只发生在缓冲区切换阶段。L1-delta使用redologs保持持久化，mainstore使用shadowpage技术减少log写入，保持一致性和持久化。2.4单系统双副本SQLServerSQLServer是双副本系统，将数据按行分组，定期转换成列存储。具体来说，就是将每百万条数据分成一组，然后将每一列转换成列存储，称为一个段。每列使用单独的压缩算法，比如有的适合字典压缩，有的适合数值压缩，所以不同的列使用不同的压缩算法。转换后的列存储额外的字典表（如果有）并将它们存储在Blob类型中。外部目录跟踪这些段的存储位置。SQLServer还为列存储提供批处理执行算法，以加速分析操作。2.5单系统双拷贝OracleOracle是另一种以双拷贝方式实现HTAP的系统。在每个系统中，对于需要的表，都会有一个行存和一个列存，分析操作是在列存上进行的；更新在存储上执行，并定期同步到列存储。系统可以灵活指定需要使用行存和列存的表，也可以在系统运行时改变表的特性。Oracle使用RAC集群进行水平扩展。下面通过两个例子来介绍Oracle是如何使用列存储来加速staging操作的。如果我们查询所有店铺类型Outlet的销售额，首先扫描维度表，根据“type”获取Outlet类型的店铺ID，并生成map，然后在外键列中取出商品ID的事实表。这个地图是搜索的，如果找到了，可以累加Amount。它可以通过只扫描某些特定的列并生成相关映射来找出要访问的数据，即将关联操作简化为表扫描操作以提高性能。还有一个比较复杂的事情就是扫描二维表生成两个vector，然后去事实表里面找相关的外键列，然后直接定位到相关的vector。如果满足条件，则分类写入对应的Temporary表。优点是可以将表关联操作转化为表扫描操作，只需要访问查询中涉及的列。2.6松耦合共享存储的Wildfire目前，还没有商用的HTAP产品采用松耦合共享存储架构，但IBM开发了一个名为Wildfire的原型。从技术细节来看，其系统分为两类节点：一类是有状态节点，一类是无状态节点。有状态节点处理事务性请求，无状态节点处理OLAP类型的请求。OLAP类型的请求可以容忍一定的延迟。OLTP类型的数据不会直接写入共享文件系统，而是写入私有集群，数据按照分表方式快速写入，然后周期性导入共享文件系统，然后用于执行分析查询。分析查询将自定义一个引擎来连接spark执行器。该引擎是无状态的，可以定制和修改。也是数据分析领域比较强大的引擎。它叫做BLU，是IBM自己的分析执行引擎。总体来说，系统分为两个集群：一个是OLTP，一个是OLAP。国内一些产品的技术类似这种架构。Spark的能力和生态用于执行分析查询。比如使用spark的queryoptimizer和machinelearning能力来构建OLAP能力，OLTP能力是自己构建的。这样，数据在一定程度上已经和这两个系统融合在一起，成为了HTAP。2.7松耦合独立存储的F1Lightning松耦合独立系统是近年来流行起来的。典型代表有两个，一个是Google的F1Lightning，一个是IBM的IDAA。让我们从F1Lightning开始。F1Lightning将系统分为三个模块：OLTP数据库、Lightning和查询执行引擎。Lightning通过Changepump捕获OLTP数据库的更新，将数据以订阅的方式分发给订阅者。Lightning内部也开发了一个adapter，将CDC模式转换成内部统一的格式。内部有两级存储：内存存储和磁盘存储。内存存储以行存储方式存在，使用B-tree索引，这里不转换为列存储，只有在数据写入磁盘时才将行存储转换为列存储。上层查询通过快照机制读取可见范围内的相关数据。F1Lightning将抓取的日志分为两层存储，为日志维护全系统的检查点时间戳，适配不同的数据库。客户端接口主要是从Databus借来的。此实现的问题是查询延迟。根据Google的测试，查询延迟在8-10分钟之间。因为采用CDC方式，OLTP数据必须在CDC内部转换成统一格式，然后分批提交，所以延迟会比较大。2.8松耦合独立存储的IDAA接下来介绍一下IBM的IDAA。最初，IBM也开发了类似的松耦合HTAP架构。下图中左边是Db2，右边是他们的Warehouse，挂载到事务引擎上，事务引擎会定时更新同步。不过，IBM系统设计人员认为，CDC解决方案需要大量的时间和背景知识来维护额外的流程，而且延迟比较大。为此，他们对其进行了改进，通过轻量级的集成同步方案规避了上述问题，将时延降低了180倍。CDC方案在源头需要经过6个步骤：读取数据，解密；过滤不相关的日志，按照LSN排序；之后，将数据转换成行和列；暂存数据，将数据转换为内部统一的CDC格式；批量等待commit或rollback，发送前去掉rollback数据。这种情况下源头的压力比较大，延迟也会比较大。IDAA建议将这些步骤移动到目标端执行。目标端可以本机识别从Db2传输的数据。当然，这是一个更个性化的解决方案。通用性没那么好，但是延迟可以大大降低，只有原来的1/180。现在读取最新数据的延迟只有1-2秒左右。2.9HTAP技术发展概况这一部分，我们将梳理HTAP在过去10年的发展历程。图中直线的方向表示后者的技术是借鉴前人或从本产品演变而来。从图中可以看出，2015年和2016年之前，HTAP技术主要是基于Onesizefitsall策略，2015年和2016年之后，主要是基于松耦合架构。近年来，如F1Lightning、IDAA等都采用了松耦合的方式来实现HTAP，甚至SAP也采用了松耦合的技术方案来实现HTAP。从Onesizefitsall的演进趋势来看，大部分都是由双副本转为单副本，由行存储转为单列存储来应对OLTP/OLAP请求。从原来磁盘上的列存，到内存中的行存，现在统一改为列存。这是近10年来HTAP技术的演进趋势。云原生对HTAP系统的启示这一部分，我们来看看云原生架构是否可以帮助HTAP系统的落地。以下是三个值得思考的问题：第一，云原生架构，即存储计算分离的架构，能否为HTAP的设计带来便利？其次，存储计算分离架构和弹性算力能否缓解资源竞争？因为这两种技术下的系统在资源竞争、数据可见性等方面各有优缺点，所以不能说哪个产品的性能最好。它是数据延迟和资源争用之间的权衡。此外，云环境中丰富的计算资源池和存储资源池，能否根据不同的计算、不同的业务特点进行划分，以降低用户的成本，也是一个值得思考的问题。一般来说，理想的情况是在云原生架构中，Share存储和Query处理分层，在查询入口采用多租户设计，在此处进行查询解析和查询优化，然后查询执行推送到查询执行层。查询执行层分为有状态和无状态两种，分别处理OLTP和OLAP相关的请求。共享存储层共享存储针对工作模式和工作负载采用不同的存储设计策略。在OLAP方面，可以关注性价比，使用对象存储和纠错编码方式来降低成本。AWSRedshift团队的研究也表明，OLAP类型的用户会更加关注成本，因此共享存储中的OLAP可以偏向于成本效益的权衡。OLTP数据存储采用高性能存储，优化交易提交关键路径，实现最佳用户体验。比如高性能Nvme加速事务提交速度，然后定时从OLTP存储导入数据到OLAP存储。.https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...https://zhuanlan.zhihu.com/p/...[定义]希望在不久的将来，相关厂商或数据库开发商能够实现这样的解决方案或技术特性。4.总结总的来说，HTAP存在的问题是如何在一个系统中同时存在OLTP和OLAP这两个相互排斥的属性，同时干扰越少，数据可见延迟越短。目前有两种架构实践：一种是Onesizefitsall，用一个数据库系统来满足OLTP和OLAP多样化工作负载的要求；针对系统相关的架构创新，更好地适应两种工作负载的特点进行配置优化。另一种是用松耦合的方式，通过CDC把两类系统绑定在一起，在上面建立一个类似代理的东西，把一个系统的样子呈现给用户，让用户感知不到OLAP系统的存在。这种方案可以更好的减少两类工作负载的资源竞争，但是由于需要跨系统进行数据同步，所以延迟比较大。前一种方案虽然资源竞争比较高，但是不需要跨系统同步数据，所以延迟比较小，数据可见度和新鲜度高，可以满足紧急任务的需要。
