# 实时数仓简介
实时数仓在大规模数据查询和分析能力基础上，提供高并发、高性能、低时延、低成本的事务处理能力。
![](https://support.huaweicloud.com/devg-911-dws/public_sys-resources/note_3.0-zh-cn.png)
- 如需使用实时数仓能力，请在DWS控制台创建集群时，选择**存算一体1:4云盘规格** ，了解更多参见[存算一体规格](https://support.huaweicloud.com/productdesc-dws/dws_01_00018.html)。
- 创建DWS集群选择**1:8云盘规格** 为标准数仓，**1:4云盘规格**为实时数仓，以下内容描述的"实时数仓"、"标准数仓"即通过以上规格区分。
 
实时数仓需要支持将insert+upsert+update等操作实时快速入库，数据来源于上游的其他数据库或者应用，同时要求入库后的数据要能及时查询，对于查询的效率要求很高。
目前DWS传统数仓已有的行存表或者列存表都无法同时满足实时入库和实时查询两个诉求。其中行存表实时入库能力强，支持高并发更新，但是磁盘占用高，查询效率低；列存表数据压缩率高，AP查询性能好，但是不能很好的支持并发更新，并发入库存在严重的锁冲突。
为了解决上面的问题，需要在使用列存储格式尽量降低磁盘占用的同时，支持高并发的更新操作入库以及高性能的查询效率。DWS的实时数仓中的HStore表就是针对这种情况设计和实现的，面向对于实时入库和实时查询有较强诉求的场景，同时拥有处理传统TP场景的事务能力。
DWS提供的实时数仓中实现了一种全新的HStore表，可以做到单条或者小批量IUD操作的高并发实时入库，也可以支持大批量的定期入库。数据入库提交后即可查询，无任何时延。支持主键等传统索引能力去重和加速点查，也支持分区、多维字典、局部排序等方式进一步加速AP查询，也可以在TPCC这种强事务压力场景下保证数据强一致性。
![](https://support.huaweicloud.com/devg-911-dws/public_sys-resources/note_3.0-zh-cn.png)
- 实时数仓的HStore表仅8.2.0.100及以上集群版本支持。
- 实时数仓为一库两用，生产即分析；适用于交易、分析混合型业务场景。关于如何创建实时数仓请参见[创建DWS存算一体集群](https://support.huaweicloud.com/mgtg-dws/dws_01_0019.html)。
- HStore表支持冷热数据管理，具体可参考[冷热数据管理](https://support.huaweicloud.com/bestpractice-dws/dws_05_0094.html)，该功能仅8.2.0.101及以上集群版本支持。
- HStore表是实时数仓中设计的一种表类型，与SQL参数hstore没有任何关系。
 
#### 与标准数仓的区别
实时数仓与标准数仓是DWS的两种规格不一样的数仓，在使用上也存在一定差异，具体可参考[表1]进行对比分析。
 表1实时数仓与标准数仓的差异 
| 数仓类型    | 标准数仓（存算一体1:8云盘规格） || 实时数仓（存算一体1:4云盘规格） ||
|:---|:--|---|:--|---|
| 适用场景   | 融合分析业务，一体化OLAP分析场景。主要应用于金融、政企、电商、能源等领域。 || 实时入库+分析混合业务，上游数据实时入库+数据入库后实时高效查询场景。主要用于电商、金融等实时入库要求高的场景。 ||
| 产品优势    | 性价比高，使用场景广泛。 支持冷热数据分析，存储、计算弹性伸缩，无限算力、无限容量等。 || 混合负载，入库性能强。 提供与列存相当的高性能查询效率与高压缩率的数据压缩能力。同时拥有处理传统TP场景的事务能力。 ||
| 功能特点      | 支持海量数据离线处理和交互查询，数据规模大、复杂数据挖掘具有很好的性能优势。 || 支持海量数据高并发的更新操作入库以及高性能的查询效率。在数据规模大、入库并发高、查询要求高的场景下具有很好的性能优势。 ||
| SQL语法   | SQL语法兼容性高，语法通用，易于使用。 || 兼容列存语法。 ||
| GUC参数 | 丰富的GUC参数，根据客户业务场景适配最适合客户的数仓环境。 || 兼容标准数仓GUC参数，同时支持实时数仓调优参数。 ||
   
#### 技术特点
- 完整的事务一致性 体现在数据插入或者更新后提交即可见，不存在时延；并发更新后数据保证强一致，不会出现乱序导致的结果预期不一致。
  
- 查询性能好 多表关联等复杂AP查询场景下，更完善的分布式查询计划与分布式执行器带来的性能优势，支持复杂的子查询和存储过程。
  
- 入库快 彻底解决列存CU锁冲突问题，支持高并发的更新入库操作，典型场景下，并发更新性能是之前的百倍以上。
  
- 高压缩 数据在MERGE进入列存主表后，按列存储具有天然的压缩优势，能极大地节省磁盘空间与IO资源。
  
- 查询加速 支持主键等传统索引能力去重和加速点查，也支持分区、多维字典、局部排序等方式进一步加速AP查询。
  
 
#### 行存、列存、HStore表对比
表2行存、列存、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无关。                                                                                                                                                                             |
| 适用场景  | 1. 更新删除操作频繁的TP事务场景。  2. 点查询（基于索引的、返回数据量小的简单查询）。   || 1. 查询分析为主的AP场景。  2. 数据量大，存入后的更新删除操作少。   || 1. 实时并发入库场景。  2. 需要支持高并发的更新入库操作以及高性能的查询效率。   |
   
