实时数仓简介
实时数仓需要支持将insert+upsert+update等操作实时快速入库,数据来源于上游的其他数据库或者应用,同时要求入库后的数据要能及时查询,对于查询的效率要求很高。
目前GaussDB(DWS)传统数仓已有的行存表或者列存表都无法同时满足实时入库和实时查询两个诉求。其中行存表实时入库能力强,支持高并发更新,但是磁盘占用高,查询效率低;列存表数据压缩率高,AP查询性能好,但是不能很好的支持并发更新,并发入库存在严重的锁冲突。
为了解决上面的问题,需要在使用列存储格式尽量降低磁盘占用的同时,支持高并发的更新操作入库以及高性能的查询效率。GaussDB(DWS)的实时数仓中的HStore表就是针对这种情况设计和实现的,面向对于实时入库和实时查询有较强诉求的场景,同时拥有处理传统TP场景的事务能力。
GaussDB(DWS)提供的实时数仓中实现了一种全新的HStore表,可以做到单条或者小批量IUD操作的高并发实时入库,也可以支持大批量的定期入库。数据入库提交后即可查询,无任何时延。支持主键等传统索引能力去重和加速点查,也支持分区、多维字典、局部排序等方式进一步加速AP查询,也可以在TPCC这种强事务压力场景下保证数据强一致性。
- 实时数仓的HStore表仅8.2.0.100及以上集群版本支持。
- 实时数仓为一库两用,生产即分析;适用于交易、分析混合型业务场景;分为单机、集群两种模式。关于如何创建实时数仓请参见创建DWS 2.0集群。
- HStore表支持冷热数据管理,具体可参考冷热数据管理,该功能仅8.2.0.101及以上集群版本支持。
- HStore表是实时数仓中设计的一种表类型,与SQL参数hstore没有任何关系。
与标准数仓的区别
实时数仓与标准数仓是GaussDB(DWS)的两种不同类型产品,在使用上也存在一定差异,具体可参考表1进行对比分析。
数仓类型 |
标准数仓 |
实时数仓 |
||
---|---|---|---|---|
适用场景 |
融合分析业务,一体化OLAP分析场景。主要应用于金融、政企、电商、能源等领域。 |
实时入库+分析混合业务,上游数据实时入库+数据入库后实时高效查询场景。主要用于电商、金融等实时入库要求高的场景。 |
||
产品优势 |
性价比高,使用场景广泛。 支持冷热数据分析,存储、计算弹性伸缩,无限算力、无限容量等。 |
混合负载,入库性能强。 提供与列存相当的高性能查询效率与高压缩率的数据压缩能力。同时拥有处理传统TP场景的事务能力。 |
||
功能特点 |
支持海量数据离线处理和交互查询,数据规模大、复杂数据挖掘具有很好的性能优势。 |
支持海量数据高并发的更新操作入库以及高性能的查询效率。在数据规模大、入库并发高、查询要求高的场景下具有很好的性能优势。 |
||
SQL语法 |
SQL语法兼容性高,语法通用,易于使用。 |
兼容列存语法。 |
||
GUC参数 |
丰富的GUC参数,根据客户业务场景适配最适合客户的数仓环境。 |
兼容标准数仓GUC参数,同时支持实时数仓调优参数。 |
技术特点
行存、列存、HStore表对比
表类型 |
行存表 |
列存表 |
HStore表 |
||
---|---|---|---|---|---|
数据存储方式 |
以元组为单位,将每一条数据的所有属性值存储到临近的空间里。 |
以CU(Compress Unit)为单位,将单个属性的所有值存储到临近的空间里。 |
数据主要以CU形式存储在列存主表上,对于被更新的列、小批量插入的数据将被序列化后存储到新设计的Delta表上。 |
||
数据写入 |
行存压缩暂未商用,数据按原始状态存储,磁盘空间占用较大。 |
按列存储时,由于属性值类型相同具有天然的压缩优势。数据写入时能极大节省IO资源与磁盘空间占用。 |
批量插入的数据直接写入CU,具有与列存一致的压缩优势。 被更新的列、小批量插入的数据会序列化后压缩。同时定期merge到主表CU。 |
||
数据更新 |
数据按行更新,没有CU锁问题,并发更新(update/upsert/delete等)性能好。 |
即使更新单条数据,也要获取整个CU的锁,基本无法支持并发更新(update/upsert/delete等)。 |
彻底解决列存更新的CU锁问题,并发更新(update/upsert/delete等)的性能达到行存的60%以上。 |
||
数据读取 |
按行读取,即使只需访问某一列的数据,也需要将一整行的数据取出。查询性能较差。 |
按列读取时只需访问该列的CU,再加上CU的压缩优势导致需要占用的IO资源更少,读取性能很好。 |
对于列存主表的数据按列读取,对于被更新的列、小批量插入的数据会反序列化后取出,数据merge到主表后具有与列存一致的数据读取优势。 |
||
优点 |
并发更新性能好。 |
查询性能好,磁盘占用空间少。 |
并发更新性能好,数据MERGE后具有与列存一致的查询性能优势与压缩优势。 |
||
缺点 |
占用磁盘空间多,查询性能差。 |
基本无法支持并发更新。 |
需要后台常驻线程对HStore表进行merge清理操作。先merge到CU主表再进行清理,与SQL语法中的Merge无关。 |
||
适用场景 |
|
|
|