Doris 查询正确性问题排查指南

编者荐语：

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

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

[

数据极客圈 .

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

](#)

在使用 Apache Doris 的过程中，Unique Key 的正确性问题可能会对数据查询结果和存储一致性产生影响。本文将为大家详细解析这些问题的分类、排查步骤以及解决方案。希望通过这篇文章，让大家对 Unique Key 的正确性排查有一个清晰的认识。

Unique Key 正确性问题分类

1. 查询问题 数据本身没有问题，但由于查询执行层的原因，导致多个副本结果不一致或查询结果不正确。

例 1： 倒排索引优化导致查询结果缺失。
问题描述：少读了一条 key，查询结果不正确。
相关案例：Unique表（mor）查询结果会变化，但是直接count 数据量是不变的。场景是同一条数据会更新多遍。这时候是有写入的，如果写入停了的话，等一会查询就没有问题了。
已经修复pr链接

2. 存储问题 存储层的问题更为复杂，常见的场景包括：

导入问题： INSERT INTO SELECT 写入 Unique 表时，可能会出现多副本行数相同但某些行内容不一致的现象。
MoW 正确性问题： 多副本行数不一致或查询表中出现重复 key。
Compaction 问题： 数据丢失（出现概率较低）。

排查 Unique Key 正确性问题的步骤

Step 1. 收集基本信息

获取用户表的 schema：

表类型（Dup 表 / Unique 表）。
如果是 Unique 表，判断是 MoR 还是 MoW。
是否使用了 sequence 列。

确认操作：

导入方式及参数
用户是否执行过删除操作（如 DELETE 语句或 delete sign 导入）。

确认问题类型及 SQL：

查询结果是否符合预期？
查询结果是否出现跳变？
数据条数是否少于预期？

Step 2. 定性问题类型

通过以下特征，确定是存储层还是查询层问题：

注：下文中➡️ 代表分支，🔴 代表终结点，如果走到了终结点，就不需要继续走了

存储层问题的判断条件：

执行 SELECT COUNT(*)（无 WHERE 条件），数据少于导入的数据量。
修改 use_fix_replica 的 session 变量为 0/1/2，若查询结果行数不同，则说明多副本不一致。
三副本行数一致，但某些 key 的内容在副本中不同。

查询层问题： 以上条件都不符合时，那就是查询层的问题了。

Step 3. 存储层问题细化

根据具体现象进一步定位：

注：下文中➡️ 代表分支，🔴 代表终结点，如果走到了终结点，就不需要继续走了

➡️ 直接count(*)，数据是否比预期的少？

🔴 行数少了，说明有丢数据的问题，联系社区同学处理

➡️ 行数不少，就将session变量use\_fix\_replica分别设置为0/1/2，查询select count(*)，确定三个副本行数是否不同

➡️如果行数不同

🔴 如果是MoR表，按照下面“多副本不一致问题分析”一节的步骤进行分析。

➡️ 如果是MoW表

🔴 如果存在重复key，跳转到下文的“MoW重复key问题分析”一节的步骤进行分析。

➡️ 执行以下查询判断是否存在重复keyselect ${keys}, count (*) a from ${table} group by ${keys} having a > 1

➡️ 如果不存在重复key，确认用户是否表schema中只包含key列

🔴 如果是，则说明这是个已知的compaction bug，升级到2.0.9之后可以解决

🔴 如果不是，按照下面“多副本不一致问题分析”一节的步骤进行分析。

➡️ 如果行数相同，看能否找到某些key，在多个副本中的数据不同

➡️ 确认是否使用了insert into select的方式进行导入，如果是，则采取如下方式处理

➡️ 如果使用的是2.1以下版本

🔴 如果没有使用sequence列，建议选一列能够区分相同key不同版本的列作为sequence列，再重新进行导入

🔴 如果用户使用了sequence列，应该是因为选择的se quence列无法区分两条相同的key，所以sequence列其实没有起作用

➡️ 使用的是2.1及以上版本，打开全局的session variable set global enable_strict_consistency_dml=true

➡️ 如果没有使用insert into select导入，说明不是个常见的问题导致的不一致，先找到某些key，在多个副本中的数据不同。然后联系社区同学进行处理。

MoW 重复 key 问题分析

如果确定是 MoW 表的重复 key 问题：

检查使用的版本：

版本 1.2.x：升级到 1.2最新版本。
版本 2.0.x：若低于 2.0.4，建议升级到2.0最新版本。
版本 2.1.x：若使用了列更新功能，建议升级到 2.1最新版本。

定位有问题的副本：

修改 use_fix_replica 为 0/1/2，分别执行查询：
SELECT ${keys}, COUNT(*) a FROM ${table} GROUPBY ${keys} HAVING a > 1;
找到有重复 key 的副本，记录问题数据和相关信息。

获取 Debug 数据：

获取有问题的 key 对应的导入版本：
SET show_hidden_columns = TRUE; SELECT ${keys}, __DORIS_VERSION_COL__ FROM ${table} WHERE ${keys} = xxx;
查找有问题的 tablet id：
EXPLAINSELECT ${keys}, __DORIS_VERSION_COL__ FROM ${table} WHERE ${keys} = xxx;

收集日志和 compaction 状态。

日志主要是fe.log 和 be.INFO
查看compaction状态
//查看某个 BE 节点总体的 compaction 状态 GET /api/compaction/run_status //查看指定 tablet 的 compaction 状态。 GET /api/compaction/show?tablet_id={int}

多副本不一致问题分析

如果确认多个副本行数不同但不存在重复 key，可以按照以下步骤排查：

找到有问题的 tablet。
确认 tablet 的两个副本是否一致：
SET use_fix_replica = 0/1/2; SELECTCOUNT(*) FROM ${table} tablet(${tablet_id});
导出不同副本的数据，进行 diff 比较：
SET use_fix_replica = 0; SELECT ${keys}, __DORIS_VERSION_COL__ FROM ${table} tablet(${tablet_id}) ORDERBY ${keys} INTOOUTFILE'file:///tmp/replica0';
对比数据差异，找出问题导入版本。
获取日志并分析问题导入的具体原因。