HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道

这篇具有很好参考价值的文章主要介绍了HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

HTAP与时俱进

在线联机事务处理(OLTP)和在线联机分析处理(OLAP)这两类数据处理分析场景,是公司日常工作中不可不说的内容,尤其是在大数据时代的当下,说它们决定了公司的成败也不为过,因此诞生了各类成熟且高效地分布式计算、存储系统,如计算侧的MapReduce、Spark、Flink、Trino等,存储侧的Oracle、RocksDB、Clickhouse等。

但正是各类计算和存储系统的遍地开花,也导致了在实际中很难将不同的系统归一、数据统一,导致各类负担,尤其是流系统、批系统的天然隔阂,因此近年来大家都是力求找到或开发出一个系统,能够同时很好应付日常工作中的绝大部分OLTP/OLAP的业务就行了,就像Snowflake那样,实现一个相对完善的HTAP系统

但要想做好一个HTAP系统,不可避免地需要要结合计算、存储这两个层面的特性来进行设计,虽然我们在实际的工作中经常强调要存算分离,保证集群系统能够至少满足BASE(Basically Available、Soft States、Eventually Consistent原则,也可以说是AP原则吧)原则,但这仅仅是强调使用上的注意事项,而要实现这样的系统,却不能分开计算而谈存储,反之亦然。

人都是“贪婪”的,一旦有了开发了一个工具,不管是使用者还是开发者,都希望随着技术的进步,这个工具能够变得更好,比如说时间,为别人/自己节省了多少时间,实时性达到秒级等,说到这里,这篇博客也就随着这篇论文Real-Time LSM-Trees for HTAP Workloads来看看学习和思考前人的成果,以帮助解决当下或未来的问题。

LASER中的存储

关键知识

LSM(Log-Structured Merge Tree)

很多文章都介绍这个概念了,大家可以自行查找一下,当然也有不少系统基于此原理实现了自己的存储,如Google LevelDB、Clickhouse、Flink Table Store等

SkipList(跳表)

这个概念也有不少的大佬分析了其理论与实践,例如Redis中的应用,还有Real-Time LSM-Trees for HTAP Workloads论文中的提到的LASER系统。

CDC(Changed Data Capture)

实际上对应了数据库中的INSERT、DELETE、UPDATE操作,更细节知识自行查阅吧。

SST(Sorted Sequence Table)

可以认为就是持久化到磁盘上的数据文件,文件中的数据行都是按排序KEY有序的。

特性

列组(Column Group)

为了兼并行存和列存的优势,LASER在不同的存储等级(LEVEL)上定义不了同列组规则,一个列组就是一个数据行中的部分或全部字段,对应一个单独的存储文件,例如在下面的图中显示的,在Level 0层,文件是按行存储的,文件中的一行就对应了一条完整的Record;而在Leve 1层,会存储两个文件,分别保存(A, B)列以及(C, D)列;在Level 3层,一个列,就是一个单独的文件。(这里说一个文件并不准确,实际上应该是一类文件,毕竟文件一般会按大小被切分成多个)
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER
图-1 列组的定义与组织

部分列更新

LASER存储的实现

数据插入流程

下图展示了LASER中的基本存储流程,图中也展示了一些配套的索引技术,如BLOOM FILTERS用于加速文件的查找、SkipList查找新记录的待插入位置。
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER
一条新数据记录(Record)完整地经历CDC过程的简单描述如下:

  1. 决定Record的操作类型:Server接收到Record后,根据指定的排序Key、唯一Key,在内存中的SKIPLIST以及磁盘中的LEVEL文件(这里指SST文件)查找,看是否存在相同的数据记录。如果存在则更新这条RECORD的操作类型为UPDATE,否则为INSERT
  2. 插入到内存中的MUTABLE SKIPLIT:通过跳表可以很快地确认这条新的数据记录的插入位置,因此就将其插入到内存。
  3. Flush到磁盘:如果新的数据记录插入后,到达了一定的阈值,则系统会尝试将MUTABLE的数据刷新到磁盘,但在Flush之前,需要将新记录插入的内存数据表标记为IMMUTABLE,以保证数据写出时,不会发生 变更。
  4. 写出数据到Level0Level 0只定义了一个文件,因此会首先尝试将新的RECORD,按行格式,插入到此文件中。
  5. Compaction数据文件:如果新的RECORD插入Level 0后,导致文件的大小超过了阈值,则会触发Compaction行为,将Level 0的文件,下沉到更下层,达到优化存储的目的,因此这里会首先将Level 0的文件,转存到Level 1。文件由Level 0插入到Level 1的过程,实际上是一个归并排序的过程,需要保证文件的有序性,因此这里可以采用二分查找来确认需要合并Level 1中的哪些文件,例如Level 0文件的SORT KEY值范围为[22, 66],那么需要与Level 1中的21-5051-88的两个SST文件进行合并。
  6. 列组映射:上面的图只显示了文件的插入过程,但没有展示出列出的合并逻辑,这里简单说一下:

图-1可以知道每一个Level的列组划分是不同的,而Level 0中的文件中的一行可能包含了所有列值(如A、B、C、D四个列),而在Level 1中数据文件只有两类(A, B)和(C, D),因此需要将0层的文件中的数据行按列拆分成两个文件,分别以前两个列为一行和后两个列为一行,再分别进行合并,最终生成两类文件。

部分列更新流程

一般地,SQL中的UPDATE语句会更新部分列的历史值,因此LASER也需要有能力支持。

初始化LEVELs

Level 0:数据文件行式存储,因此文件中的一行,包含了全部列,A、B、C、D。
Level 1: 两个文件,即两人上Column Group,左边文件包含A、B列;右边文件包含C、D列
注意到每一行记录之前有一个特殊的整数,例如106: a6, b6, c6, d6中的106,表示的是数据记录排序键对应的值,可以看到在每一个文件中,所有的数据记录都是按此值有序。

HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER

插入一条新记录并更新一条旧记录(合并L0和L1)

插入一条新记录:99: a9, b9, c9, d9
更新一条旧记录:107: -, -, c9, d9,其中-表示不更新,即保留A, B列的原有值
注意到,这里插入新记录后,导致LEVEL 0超过存储阈值,因此会触发L0的文件下沉到L1,因此下面的图展示的是合并后的结果。
在合并L0和L1的过程中,可以看到,原本在L0的行文件中的记录106: a6, b6, c6, d6,下沉到L1后,被纵向拆分到了两个Column Group文件中;而新的更新记录107: -, -, c9, d9最终只会在CG:<C, D>有值,而不会添加记录107: -, -到CG:<A, B>中,节约了存储空间。

HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER

插入一条新记录并更新一条旧记录(不合并)

插入一条新记录:50: a0, b0, c0, d0
更新一条旧记录:108: a1, b1, -, -,其中-表示不更新,即保留C, D列的原有值
可以看到由于新插入的数据后,被首先Flush到Level 0,但Level 0的数据大小没有达到阈值,因此不会发生Compaction,新的数据就以行格式保留在L0中。
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER

范围查询

ColumnMergingIterators:用于合并ColumnGroup,一个Iterator实例只会作用于同一个Level,因此不会真正的合并新旧数据,而是将要所有要检索的列(这里是A、B、C、D列)拼接在一起。
LevelMergingIterators:用于合并来自不同Level的数据,这些数据经过ColumnMergingIterators后返回了一个"临时表",包含了所有要检索的列,同时会进行新、旧列值的覆盖
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER
查询流程简述如下:

  1. SQL解析:接收SELECT * FROM tbl WHERE sort_key >= 50 and sort_key <= 108,产生要返回的结果列的投影信息,即返回A、B、C、D。
  2. 确认数据所有层级:发现sort_key的取值范围是[50, 108],在3个Level中都存在数据,因此需要遍历每一层的数据文件。
  3. 遍历每一层的数据文件:为每一个LEVEL创建ColumnMergingIterators实例,遍历满足条件的数据文件,返回的结果是一个临时表且它们的Layout相同,均为A、B、C、D,例如对于sort_key = 107的数据记录,通过列拼接,最终得到在临时表中的对应行107: -, -, c9, d9
  4. 合并每一层的临时表:通过LevelMergingIterators实例,合并每一层的返回结果,同时进行数据记录的更新/删除动作,例如对于sort_key = 107的数据记录,发现它的旧值为107: a7, b7, c7, d7,新值为107: -, -, c9, d9,因此通过覆盖后的最终结果为107: a7, b7, c9, d9
  5. 返回最终结果:最终结果集包含了所有要检索的列,以及包含了旧记录中的列的最新值。

部分列的Compaction

通过后台的Compaction线程,可以并行地在不同的ColumnGroup上进行Compaction,因为在数据下沉的过程中,越往向,列组越小,并且互相不影响。

如下图所示,当前一共有两个Compaction任务在执行,第一个任务是合并L1和L2中的CG:<A, B>;第二个任务是合并L2和L3中的CG: <C>
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER
但这里有一个潜在的问题:为什么选择L1中的<A, B>下沉,以及L2中的<C>下沉?

简单来说,LASER为每一个Level配置了不同的Quota,例如为L1配置了上限记录数为2,而当前L1中一共存在3条记录,因此需要合并L1和L2;同时注意到CG: <A, B> 的占比最多,因此优先选择此CG下沉,故就对应了任务1,同理生成任务2

最终,经过部分列上的下沉,可以避免对它列的影响,在一定程度上能够减缓由于数据下沉,导致在这些列上的检索时间变长的问题,当然也可以结合一些冷热策略可以更精细地控制正常过程。

LASER存储的性能

rocksdb:行存
rocksdb-col:列存
HTAP-simple:行、列混合存储,25%数据行存,其它列存。
Postgress:行存
MySQL:行存
MyRocks:行存
MonetDB:列存
Hyper:全内存列存

整体性能

如下图所示,在同时进行INSERT、UPDATE、SELECT操作时,LASER的整体性能是最好的,尤其是在设置了ColumnGroup的大小为6(6列)、15(15列)的场景下,而次强的则是HTAP-simple和rocksdb-col(它们完全是基于内存的)
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER

插入性能

如下图所示,当仅执行INSERT操作时,LASER表现最好,尤其是设置CG的大小为2和3时,而HTAP-simple和rocksdb将之。
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER

检索性能

𝑄1: INSERT INTO R VALUES (𝑎0, 𝑎1, …, 𝑎𝑐 )
𝑄2: SELECT 𝑎1, 𝑎2, …, 𝑎𝑘 FROM R WHERE 𝑎0 = 𝑣
𝑄3: UPDATE R SET 𝑎1 = 𝑣1, …, 𝑎𝑘 = 𝑣𝑘 WHERE 𝑎0 = 𝑣
𝑄4: SELECT 𝑎1 + 𝑎2 + … + 𝑎𝑘 FROM R WHERE 𝑎0 ∈ [𝑣𝑠 , 𝑣𝑒 )
𝑄5: SELECT 𝑀𝐴𝑋 (𝑎1), …, 𝑀𝐴𝑋 (𝑎𝑘) FROM RWHERE𝑎0 ∈ [𝑣𝑠 , 𝑣𝑒 )

如下图所示,分别执行不同Query时的延迟统计图,从中可以看到当前执行Q1、Q2、Q3时,LASER能够达到其它优势引擎的最好性能;而执行Q4的算术运算时,Hyper表现最好,比LASER快5倍(而MonetDB比LASER慢20倍);而执行Q5的聚合运算时,MonetDB和Hyper比LASER快5倍,这是由于Hyper和Monet存储的数据记录都是按列连续的,因此不需要像LASER那样需要先合并数据。
HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道,大数据,数据存储,HTAP,HTAP,LSM,Real-time,LASER
因此整体上看,在高负载,和能用场景下,LASER的表是所有列式引擎、行式引擎中综合表现最好的,也更加活动地通过CG的大小来适配不再的场景。

LASER存储的问题

下面提到的这些问题,都是论文中有提到的,同时也给出了估算公式,但是着实需要细致分析每一个算法才能更好地理解架构设计的精妙,这里就不展开分析了,也怕功力不够,引发解读错误,那就栽了!!!

写放大

不难想象,当我们更新更新或插入数据时,至少需要读取索引数据、旧的的数据记录,以确定当前数据行的操作类型;当发生数据合并(Compaction过程)时,需要将新旧数据写出到一个新的数据文件,同时保证旧的数据文件依然在此期间可以为查询作业提供服务,因此这么大的倍数与写入或更新的数据模型有关。

为了缓解此问题,可以基于ColumnGroup机制,同时为每一个Level制定不同的数据下沉策略。

点查放大

仅仅是等值查询,最坏情况下,需要在内存遍历,同时需要检查所有Level中的数据范围,以确定数据是否存在。

范围查询放大

比点查更坏,最坏情况下,要查询的数据在每一个Level中都存在,因此遍历记录每一层的数据文件的信息,来确定要读取的数据。

更新放大

在点查放大问题的基础之上,需要将新数据写出到Level 0,同时很可能会引发Compcation过程。

总结

Real-Time LSM-Trees for HTAP Workloads介绍了一个支持实现写入的、基于LSM的、支持HTAP场景的存储系统,LASER。论文提出了ColumnGroup存储规范,能在兼并行存、列存的优点,以相对最好的性能同时支持OLTP和OLAP事务,为打造流批一体计算&存储系统提供了借鉴,非学值得我们细细口味。文章来源地址https://www.toymoban.com/news/detail-809982.html

思考

  1. 使用什么的索引或算法,能够快速定位范围所包含的数据文件?
  2. 时间旅行?
  3. 并发写事务的支持?
  4. 如何支持插入入新的列?
  5. 。。。

到了这里,关于HTAP(Hybrid Transactional/Analytical Processing)系统之统一存储的实时之道的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 目标级联分析法( Analytical Target Cascading , ATC )理论matlab程序

    目标级联分析法( Analytical Target Cascading , ATC )理论matlab程序 目标级联分析法(Analytical Target Cascading,ATC)是一种采用并行思想解决复杂系统的设计方法,最初由密执安大学研究人员提出,主要用于汽车、飞机等设计领域。其原理如下: 如图a所示,ATC 的基本思想是将设计

    2024年02月05日
    浏览(36)
  • HTAP应该是一种需求 而不是一种产品

    作者 : 石臻臻 , CSDN博客之星Top5 、 Kafka Contributor 、 nacos Contributor 、 华为云 MVP , 腾讯云TVP , 滴滴Kafka技术专家 、 LogiKM PMC(改名KnowStreaming) 。 LogiKM(改名KnowStreaming) 是滴滴开源的Kafka运维管控平台, 有兴趣一起参与参与开发的同学,但是怕自己能力不够的同学,可以联系我,当你导

    2024年01月19日
    浏览(47)
  • HTAP for MySQL 在腾讯云数据库的演进

    摘要:MySQL在充分利用多核计算资源方面比较欠缺,无法同时满足在线业务和分析型业务的客户需求,而单独部署一套专用的分析型数据库意味着额外的成本和复杂的数据链路。本次主题将介绍腾讯云数据库为满足此类场景而在HTAP for MySQL产品方面进行的尝试。 2023首届云数据

    2024年02月03日
    浏览(37)
  • HTAP 还可以这么玩?丨TiDB 在 IoT 智慧园区的应用

    作者:某物联网公司设施云平台负责人 用户简介:我们是一家提供全链智慧园区整体解决方案的物联网公司,致力于打造可持续发展的智慧园区。 基础设施平台是集团一线作业人员日常工作中高度依赖的重要系统,涵盖了各类基础设施的管理、报修、保养等一系列数字化办

    2024年02月19日
    浏览(39)
  • WRF模型教程(ububtu系统)-WPS(WRF Pre-Processing System)概述

          WRF 预处理系统 (WRF Pre-Processing System,WPS) ,集成了基于 Fortran 和 C 编写的程序,这些程序主要用于处理输入到 real.exe 的数据。WPS主要有三个程序和一些辅助程序。       主要的程序为 geogrid.exe、ungrib.exe、metgrid.exe ,输入到这些程序的配置在“ namelist.wps ”中,每个主

    2024年04月12日
    浏览(33)
  • 百度云原生数据库GaiaDB的HTAP与多地多活技术实践

    摘要:云原生数据库在使用存算分离技术后,可以在完全兼容MYSQL协议和语法的情况下,极大提升单实例所能承载的数据规模与吞吐能力上限。但除了对客户端兼容外,对整个数据生态(地域容灾,数据分析,备份恢复)的适配同样需要大量的设计优化工作。本次分享GaiaDB在

    2024年02月06日
    浏览(50)
  • 指纹统一身份认证系统系统安全设计

    2.10.1 身份认证 系统是为广大工作人员提供服务的,为了区分各个用户以及不同级别的用户,需要对他们的 身份和操作的合法性进行检查。体系应该规定实现身份认证与权限检查的方式、方法以及对 这些用户的管理要求。 2.10.2 权限管理 权限管理系统是保证业务系统安全的一

    2024年02月10日
    浏览(52)
  • 指纹统一身份认证系统功能特点

     实现用户单点登录 对于 B/S 结构应用系统,用户只需通过浏览器界面登录一次,即可通过统一身份认证系统 访问后台的多个用户权限内的 Web 应用系统,无需逐一输入用户名、密码登录。对于 C/S 结构应用系统,通过 Active 控件或客户端 Plugin 来实现对 C/S 系统客户端的单点

    2024年02月11日
    浏览(45)
  • 分布式各系统时间统一程序

    使用场景是在一个大型分布式系统下,对时间有一个较高的水平要求。因为需要矫正每台运行服务的主机时间。 Cristian\\\'s algorithm 算法是一种时钟同步算法, 用于通过客户端进程与时间服务器同步时间。此算法适用于低延迟网络, 其中往返时间与准确性相比, 它是短的, 而易于冗

    2024年02月09日
    浏览(37)
  • 手机App防沉迷系统 - 华为OD统一考试

    OD统一考试(C卷) 分值: 100分 题解: Java / Python / C++ 智能手机方便了我们生活的同时,也侵占了我们不少的时间。“手机Ap防沉迷系统” 能够让我们每天合理的规划手机App使用时间,在正确的时间做正确的事。 它的大概原理是这样的: 1、在一天24小时内,可注册每个App的允

    2024年01月24日
    浏览(54)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包