操作相关问题

最近更新时间:2022-03-30 11:19:53

Doris 是否支持修改列名?

不支持修改列名。
Doris 支持修改数据库名、表名、分区名、物化视图(Rollup)名称,以及列的类型、注释、默认值等。但遗憾的是,目前不支持修改列名。
因为一些历史原因,目前列名称是直接写入到数据文件中的。Doris 在查询时,也是通过类名查找到对应的列的。所以修改列名不仅是简单的元数据修改,还会涉及到数据的重写,是一个非常重要的操作。我们不排除后续通过一些兼容手段来支持轻量化的列名修改操作。

Unique Key 模型的表是否支持创建物化视图?

不支持。
Unique Key 模型的表是一个对业务比较友好的表,因为其特有的按照主键去重的功能,能够很方便的同步数据频繁变更的业务数据库。因此,很多用户在将数据接入到 Doris 时,会首先考虑使用 Unique Key 模型。
但遗憾的是,Unique Key 模型的表是无法建立物化视图的。原因在于,物化视图的本质,是通过预计算来将数据“预先算好”,这样在查询时直接返回已经计算好的数据,来加速查询。在物化视图中,“预计算”的数据通常是一些聚合指标,例如求和、求 count。这时,如果数据发生变更,如 udpate 或 delete,因为预计算的数据已经丢失了明细信息,因此无法同步的进行更新。例如一个求和值5,可能是 1+4,也可能是2+3。因为明细信息的丢失,我们无法区分这个求和值是如何计算出来的,因此也就无法满足更新的需求。

show backends/frontends 查看到的信息不完整?

在执行如show backends/frontends 等某些语句后,结果中可能会发现有部分列内容不全。例如 show backends 结果中看不到磁盘容量信息等。
通常这个问题会出现在集群有多个 FE 的情况下,如果用户连接到非 Master FE 节点执行这些语句,就会看到不完整的信息。这是因为,部分信息仅存在于 Master FE 节点。例如 BE 的磁盘使用量信息等。所以只有在直连 Master FE 后,才能获得完整信息。
当然,用户也可以在执行这些语句前,先执行 set forward_to_master=true; 这个会话变量设置为 true后,后续执行的一些信息查看类语句会自动转发到 Master FE 获取结果。这样,不论用户连接的是哪个 FE,都可以获取到完整结果了。

如何正确阅读 FE/BE 日志?

很多情况下我们需要通过日志来排查问题。这里说明一下 FE/BE 日志的格式和查看方式。

  1. FE
    FE 日志主要有:
    • fe.log:主日志。包括除fe.out外的所有内容。
    • fe.warn.log:主日志的子集,仅记录 WARN 和 ERROR 级别的日志。
    • fe.out:标准/错误输出的日志(stdout和stderr)。
    • fe.audit.log:审计日志,记录这个FE接收的所有SQL请求。
      一条典型的 FE 日志如下:
      2021-09-16 23:13:22,502 INFO (tablet scheduler|43) [BeLoadRebalancer.selectAlternativeTabletsForCluster():85] cluster is balance: default_cluster with medium: HDD. skip
    • 2021-09-16 23:13:22,502:日志时间。
    • INFO:日志级别,默认是INFO
    • (tablet scheduler|43):线程名称和线程 id。通过线程 id,就可以查看这个线程上下文信息,方面排查这个线程发生的事情。
    • BeLoadRebalancer.selectAlternativeTabletsForCluster():85:类名、方法名和代码行号。
    • cluster is balance xxx:日志内容。

通常情况下我们主要查看 fe.log 日志。特殊情况下,有些日志可能输出到了 fe.out 中。

  1. BE
    BE 日志主要有:
    • be.INFO:主日志。这其实是个软连,连接到最新的一个 be.INFO.xxxx上。
    • be.WARNING:主日志的子集,仅记录 WARN 和 FATAL 级别的日志。这其实是个软连,连接到最新的一个 be.WARN.xxxx上。
    • be.out:标准/错误输出的日志(stdout和stderr)。
      一条典型的 BE 日志如下:
      I0916 23:21:22.038795 28087 task_worker_pool.cpp:1594] finish report TASK. master host: 10.10.10.10, port: 9222
    • I0916 23:21:22.038795:日志等级和日期时间。大写字母 I 表示 INFO,W 表示 WARN,F 表示 FATAL。
    • 28087:线程 id。通过线程 id,就可以查看这个线程上下文信息,方面排查这个线程发生的事情。
    • task_worker_pool.cpp:1594:代码文件和行号。
    • finish report TASK xxx:日志内容。

通常情况下我们主要查看 be.INFO 日志。特殊情况下,如BE宕机,则需要查看 be.out。

FE/BE 节点挂了应该如何排查原因?

  1. BE
    BE 进程是 C/C++ 进程,可能会因为一些程序 Bug(内存越界,非法地址访问等)或 Out Of Memory(OOM)导致进程挂掉。此时我们可以通过以下几个步骤查看错误原因:
    1. 查看 be.out。
      BE 进程实现了在程序因异常情况退出时,会打印当前的错误堆栈到 be.out 里(注意是 be.out,不是 be.INFO 或 be.WARNING)。通过错误堆栈,通常能够大致获悉程序出错的位置。
    2. dmesg。
      如果 be.out 没有堆栈信息,则大概率是因为 OOM 被系统强制 kill 掉了。此时可以通过 dmesg -T 这个命令查看 Linux 系统日志,如果最后出现 Memory cgroup out of memory: Kill process 7187 (palo_be) score 1007 or sacrifice child 类似的日志,则说明是 OOM 导致的。
      内存问题可能有多方面原因,如大查询、导入、compaction 等。Doris 也在不断优化内存使用。
    3. 查看 be.INFO 中是否有 F 开头的日志。
      F 开头的日志是 Fatal 日志。如 F0916。表示9月16号的Fatal日志。Fatal日志通常表示程序断言错误,断言错误会直接导致进程退出(说明程序出现了Bug)。
  2. FE
    FE 是 Java 进程,健壮程度要由于 C/C++ 程序。通常FE 挂掉的原因可能是 OOM(Out-of-Memory)或者是元数据写入失败。这些错误通常在 fe.log 或者 fe.out 中有错误堆栈。需要根据错误堆栈信息进一步排查。

Unique Key 模型查询结果不一致?

某些情况下,当用户使用相同的 SQL 查询一个 Unique Key 模型的表时,可能会出现多次查询结果不一致的现象。并且查询结果总在 2-3 种之间变化。
这可能是因为,在同一批导入数据中,出现了 key 相同但 value 不同的数据,这会导致,不同副本间,因数据覆盖的先后顺序不确定而产生的结果不一致的问题。
例如表定义为 k1, v1。一批次导入数据如下:

1, "abc"
1, "def"
那么可能副本1 的结果是 1, "abc",而副本2 的结果是 1, "def"。从而导致查询结果不一致。
为了确保不同副本之间的数据先后顺序唯一,可以使用 Sequence Column功能。

目录