Doris 行列混存原理、优势与应用场景全解析

PowerData

编者荐语：

来自PowerData-徐振超同学的精彩文章！

以下文章来源于数据极客圈，作者徐振超

[

数据极客圈 .

一入大数据深似海？别怕！“数据极客圈” 就是你的救生圈，走对圈子跟对人，趣析数据、畅聊趋势，快进圈子！

](#)

1. 什么是 Doris 的行列混存

Doris 是一款基于 MPP（大规模并行处理）架构的分布式分析型数据库，其行列混存模式允许在同一数据存储中，针对不同数据部分采用行式存储和列式存储两种方式。简单来说，就是可以根据数据的使用特点，将适合按行处理的数据按行存储，适合按列处理的数据按列存储。Doris 默认采用列式存储，在分析场景（如聚合，过滤，排序等）中有出色性能，因为只需读取所需列，减少了不必要的 I/O。但在点查场景（如SELECT *）下，若列数众多，每个列都需一次 I/O，会导致 I/OPS 成为瓶颈，尤其是宽表（上百列）情况更为突出。为解决此问题，Doris 从 2.0.0 版本开始支持行列混存。用户在建表时指定开启行存后，点查操作每一行仅需一次 I/O，在宽表且列数多的场景下，性能有数量级提升。

2. 实现原理

数据组织：

行式存储部分：对于更新、插入操作频繁，且需频繁访问整行数据的场景，如小范围的 OLTP（在线事务处理）类操作，Doris 会以行的形式存储相关数据。在此存储方式下，一行数据的所有列值连续存储，类似传统关系型数据库，便于快速读取整行数据，一次磁盘 I/O 操作就能获取整行信息。

列式存储部分：当面对大量数据的聚合、分组、过滤等 OLAP（在线分析处理）场景时，Doris 会将相关列数据单独存储。例如，在包含用户信息（姓名、年龄、性别、地址等）的表中，若经常要统计不同年龄段的用户数量，年龄列就适合以列存储方式存放。列存储中，一列的数据值连续存储，在进行只涉及某一列或几列的查询时，能极大减少磁盘 I/O，因为只需读取相关列数据，无需读取整行数据。

行存实现细节：行存的原理是在存储时增加一个额外的列，该列将对应行的所有列拼接起来，采用特殊的二进制格式存储。这种方式使得在点查时，能够通过一次 I/O 操作获取整行数据，有效解决了宽表点查时 I/OPS 瓶颈问题。

3. 优势

查询性能优化：

对于 OLAP 查询：在处理复杂分析查询，如统计不同地区、不同产品类别的销售总额时，列存储特性使数据库能快速定位相关列数据进行计算，无需读取大量无关列数据，显著提高查询效率。例如，在包含百亿条销售记录的表中，若使用传统行存储，可能需扫描大量无用数据，而列存储能精准定位到 “地区”“产品类别”“销售额” 等相关列，极大减少数据扫描量，查询时间可能从数小时缩短到几分钟甚至更短。

对于 OLTP 类查询：当需要对某条记录进行快速更新或读取整行数据时，行存储部分能快速响应，因其数据组织方式适合按行操作场景，能高效获取所需整行数据，满足对实时性要求较高的业务操作。特别是在开启行列混存后，对于宽表的点查操作，性能得到了极大提升。

4. 应用场景

互联网数据分析：互联网公司常需分析用户行为数据，如浏览记录、点击行为、购买记录等。在分析用户一段时间内的整体行为轨迹（类似 OLTP 场景）时，行存储部分能快速获取用户整行行为数据；在统计不同地区、不同年龄段用户的某种行为（如点击特定广告的次数）时，列存储部分可高效对相关列进行聚合计算，满足互联网公司对海量用户行为数据的实时分析需求。

金融行业报表生成：金融机构生成各类财务报表时，既需快速查询某笔交易的详细信息（涉及整行数据，如交易时间、金额、交易对手等），依靠行存储保证速度；又需对大量交易数据进行统计分析，如按不同业务类型统计交易总额、按时间段统计利润等，利用列存储提高分析效率。Doris 的行列混存能很好支持金融行业这种复杂业务需求，确保报表生成的准确性和及时性。

电信行业数据处理：在电信行业的数据集市、经营分析和地市公司 BI 场景中，Doris 的行列混存也能发挥重要作用。例如在数据集市场景中，可替代 Oracle 数据库，实现秒级查询效率；经营分析场景中，能替代原有的 Impala + Redis 架构，提高报表生成效率，扩大查询数据范围，且组件更稳定，运维更便捷；地市公司 BI 场景中，可替代原有的 PostgreSQL 数据库，实现秒级查询性能提升。

5. 如何使用

使用语法：建表时在表的PROPERTIES中指定是否开启行存、哪些列开启行存以及行存的存储压缩单元大小page_size。

是否开启行存：默认为false不开启，若要开启，设置为"store_row_column" = "true"。

哪些列开启行存：若"store_row_column" = "true"，默认所有列开启行存。若需指定部分列开启行存，设置row_store_columns参数，格式为逗号分割的列名，如"row_store_columns" = "column1,column2,column3"。

行存 page\_size：默认为 16KB，设置方式为"row_store_page_size" = "16384"。page是存储读写的最小单元，page_size越大，压缩效果越好，存储空间占用越低，但点查时 I/O 开销越大，性能越低（因为一次 I/O 至少读一个 page）；反之，page_size越小，存储空间占用越高，点查性能越好。默认值 16KB 在大多数情况下是比较均衡的选择，若更偏向查询性能，可配置较小的值，如 4KB 甚至更低；若更偏向存储空间，可配置较大的值，如 64KB 甚至更高。

使用示例：以下例子创建一个 8 列的表，其中"key,v1,v3,v5,v7"这 5 列开启行存，为实现高并发点查性能，配置page_size为 4KB。

CREATE TABLE `tbl_point_query` ( `key` int(11) NULL, `v1` decimal(27, 9) NULL, `v2` varchar(30) NULL, `v3` varchar(30) NULL, `v4` date NULL, `v5` datetime NULL, `v6` float NULL, `v7` datev2 NULL ) ENGINE=OLAP UNIQUE KEY(`key`) COMMENT 'OLAP' DISTRIBUTED BY HASH(`key`) BUCKETS 1 PROPERTIES ( "enable_unique_key_merge_on_write" = "true", "light_schema_change" = "true", "row_store_columns" = "key,v1,v3,v5,v7", "row_store_page_size" = "4096" );

查询示例：

SELECT key, v1, v3, v5, v7 FROM tbl_point_query WHERE key = 100；