Apache Doris，是一个开源的。MPP架构的。分析型数据库。用于OLAP场景，具有高性能、高可用、易扩展、易运维等特点。最近几年。越来越火。很多公司。都在用它。构建数据仓库，做实时分析。做报表。做用户画像。做日志分析，等。

我在项目中，用Doris。已经有一年多了。从。最开始的，调研。试用。到。后来的，大规模。生产环境。使用。踩了很多坑。也总结了很多经验。和，最佳实践。

之前，我写过一些。Doris的。踩坑总结。和，性能调优。的。文章。今天。这篇文章。系统地，分享。Doris数据库。的。最佳实践。包括。集群部署、表设计、数据导入、查询优化、运维管理、常见问题，等。方面。希望。能给，正在。使用。或者。打算。使用Doris，的。朋友。一些，参考。

先说明一下。这些最佳实践。是。基于。我们的，项目经验。和。场景。总结的。不一定。适合。所有的。场景，大家。要。根据。自己的。实际情况。灵活。参考。不要。生搬硬套。而且。Doris。发展，很快。版本。更新。也。很快。我。写这篇文章的时候。用的，是。Doris 1.0.x。版本。不同的。版本。可能。会有。一些。差异，大家。要。注意。版本。的。差异。

一、Doris简介

在，分享。最佳实践。之前。先。简单。介绍一下。Doris。是什么，帮助。不了解的朋友。有个。概念。

Apache Doris，是。一个。开源的。MPP（Massively Parallel Processing，大规模并行处理）架构的。分析型数据库。用于OLAP（Online Analytical Processing。联机分析处理）场景，最初。是。百度。在，2017年。开源的。后来。贡献给，Apache基金会。成为。Apache的，顶级项目。

Doris，的。核心。特性。包括：

  1. 高性能：MPP架构，分布式。并行。计算。支持。PB级。数据。的。亚秒级。查询，性能。非常。好。比。传统的。数据仓库。快。很多。
  2. 实时性：支持，实时。数据。导入。和。实时。查询。数据。导入。之后，秒级。可查。能。满足。实时分析。的。需求。
  3. 高可用：多副本，机制。FE。和。BE。都。支持。多副本。高可用。单节点。故障，不影响。集群。的。正常。使用。
  4. 易扩展：支持，在线。扩容。缩容。节点。增加。或者。减少。都。很。方便，数据。自动。均衡。不需要。人工。干预。
  5. 易运维：提供，完善的。运维。工具。和。监控。指标。部署。简单。运维，方便。不需要。像。Hadoop。生态。那样。复杂的。运维。
  6. 兼容MySQL协议：支持，MySQL。协议。和。常用的。MySQL，语法。用户。可以。用。MySQL，的。客户端。和。工具。连接，Doris。学习。成本。低。
  7. 支持多种数据模型：支持，明细模型（Duplicate）、聚合模型（Aggregate）、更新模型（Unique）。三种。数据。模型，能。满足。不同的。业务，场景。
  8. 支持多种导入方式：支持，Stream Load、Broker Load、Routine Load、Spark Load、Insert。等。多种，导入。方式，能。从，不同的。数据源，导入。数据。

以上。就是。Doris，的。简单。介绍。和。核心。特性。接下来。分享，Doris。的。最佳实践。

二、集群部署最佳实践

集群部署，是。使用。Doris。的。第一步。也是。很重要的。一步。集群。部署，得。好。后面的。性能。运维。都会。顺利，很多。

1. 节点，规划。要。合理

Doris，的。集群。由。FE（Frontend。前端节点）。和。BE（Backend。后端节点），两种。节点。组成。FE。负责。元数据。管理。查询，规划。SQL。解析。等；BE。负责。数据。存储。查询，执行。等。

节点，规划。的。原则：

  • FE，节点。数量。建议。3个。或者。5个。奇数个。因为。FE。用。Paxos协议，做。元数据。的。一致性。需要。多数派。所以。奇数个。比较。合适。3个，能。容忍。1个。节点。故障。5个。能。容忍，2个。节点。故障。一般。3个。就。够了。不需要。太多。太多，会。影响。元数据。的。写入。性能。
  • BE，节点。数量。根据。数据量。和。查询。并发。决定。一般。至少。3个。保证，数据。有。3副本。高可用。数据量。大。查询。并发。高。可以，增加。BE。节点。数量。线性。扩展。性能。
  • FE。和，BE。可以。部署。在。同一个。节点。上。也。可以。分开。部署。对于。生产环境。建议，FE。和。BE。分开。部署。避免。互相。影响。FE，节点。配置。不需要。太高。8核16G。就。够了。BE。节点，配置。要。高一些。建议。16核32G。以上。数据盘。用。SSD。或者，NVMe。提高。IO。性能。
  • 不要，把。所有的。FE。和。BE。都。部署。在。同一个。机架。上，要。分布。在。不同的。机架。甚至。不同的。可用区。提高，可用性。避免。机架。故障。导致。整个。集群。不可用。

我们的，实践。是。生产环境。3个。FE。节点。8核16G。部署，在。不同的。机架。5个。BE。节点。16核64G。2TB，SSD。部署。在。不同的。机架。FE。和。BE。完全。分开，部署。性能。和。可用性。都。很好。

2. 操作系统。和，参数。优化

Doris，运行。在。Linux。上。对。操作系统。的。参数，有。一些。要求。和。优化。建议。部署。之前。要，做好。操作系统。的。参数。优化。

常用的，操作系统。参数。优化：

  • 关闭，Swap：Doris。对。内存。要求，高。用。Swap。会，严重。影响。性能。所以。建议。关闭，Swap。或者。设置。vm.swappiness=0。尽量，不用。Swap。
  • 调整，文件。描述符。限制：Doris。会。打开。很多。文件。所以。要，调大。文件。描述符。限制。建议。设置。为。655350。或者。更大。
  • 调整，内核。参数：比如。vm.maxmapcount。调大，到。2000000。以上。避免，BE。因为。内存。映射。太多，报错；net.core.somaxconn。调大。到。1024，以上。提高。网络。连接，队列。长度。
  • 关闭，防火墙。和。SELinux：生产环境。建议。关闭。防火墙。和，SELinux。避免。影响。节点，之间的。通信。当然。如果。有。安全，要求。也。可以。开放。需要的。端口。不用，完全。关闭。
  • 时间。同步：所有，节点。的。时间。要。同步。用。NTP。或者。chrony。同步。时间，避免。时间。不一致。导致。各种。问题。
  • 文件系统：数据盘。建议，用。ext4。或者。xfs。文件系统。挂载。的时候。加上。noatime，参数。减少。文件。访问。时间。的。更新。提高，IO。性能。

我们的，实践。是。部署。之前。用。Ansible。统一。对，所有。节点。做。操作系统。参数。优化。关闭。Swap，调大。文件。描述符。和。内核。参数。关闭。防火墙。和。SELinux，配置。时间。同步。数据盘。用。ext4。挂载。加。noatime。参数，保证。操作系统。的。配置。统一。最优。

3. 部署，方式。建议

Doris，的。部署。方式。有。很多种。可以。手动。部署。也。可以，用。Docker。部署。也。可以。用。Kubernetes。部署。也。可以，用。官方的。Doris Manager。部署。

对于，生产环境。建议。用。官方的。Doris Manager。部署。和。运维。Doris Manager，是。官方。提供的。可视化。运维。工具。能。一键，部署。集群。扩容。缩容。升级。监控。告警。等，非常。方便。大大。降低。运维。成本。

如果，不想。用。Doris Manager。也。可以。手动。部署。但是。要。注意。配置，的。一致性。和。正确性。避免。因为。配置。错误。导致。各种，问题。

不建议，在。生产环境。用。Docker。或者。Kubernetes。部署。Doris。因为，Doris。对。IO。和。网络。要求。高。容器化，部署。可能。会。有。性能。损失。和。网络。问题。当然。如果。是，测试。环境。或者。小集群。也。可以。用。容器化。部署。方便，快捷。

我们的，实践。是。生产环境。用。Doris Manager。部署。和。运维。3个FE。5个BE，手动。做。操作系统。参数。优化。Doris Manager。负责。Doris，的。部署。配置。监控。告警。升级。扩容。等，运维。很。方便。很。稳定。

三、表设计最佳实践

表设计，是。使用。Doris。的。最。重要的。一步。表，设计得。好。查询。性能。就。好。存储。成本。就。低。表。设计得，不好。查询。性能。会。很差。存储。成本。也，高。甚至。会。遇到。各种。问题。

1. 选择，合适的。数据。模型

Doris，支持。三种。数据。模型，明细模型（Duplicate）、聚合模型（Aggregate）、更新模型（Unique）。不同的。模型。适合，不同的。场景。要。根据，业务。场景。选择。合适的，模型。

  • 明细模型（Duplicate）：和，普通的。表。一样。存储。明细。数据。不。做，聚合。也。不。支持。更新。适合。存储。明细。数据。比如，日志。明细。事件。明细。等。需要。保留。所有。明细。的，场景。
  • 聚合模型（Aggregate）：按照，维度。列。对。指标。列。做。聚合。导入，的时候。就。会。聚合。相同。维度。的。数据。适合，存储。聚合。后。的。数据。比如。报表。数据。统计，数据。等。只。需要。聚合。结果。不需要。明细。的。场景，能。大大。减少。数据量。提高。查询。性能。
  • 更新模型（Unique）：按照，主键。去重。保留。最新的。记录。支持。更新。和。删除，适合。需要。更新。数据。的。场景。比如。用户。画像。订单，状态。等。需要。实时。更新。的。场景。

选择，数据。模型。的。原则：

  • 如果。需要，保留。所有。明细。数据。选。明细模型。
  • 如果，只。需要。聚合。结果。不需要。明细。选。聚合模型。能，减少。数据量。提高。查询。性能。
  • 如果。需要，更新。数据。选。更新模型。
  • 不要，盲目。选。更新模型。因为。更新模型。的。查询。性能。比，明细。和。聚合。模型。差。一些。如果。不需要。更新。就。不要。用，更新模型。
  • 聚合模型，的。指标。列。要，选择。合适的。聚合。函数。比如，SUM、MAX、MIN、REPLACE。等。根据。业务。需求。选择。

我们的，实践。是。大部分。明细。数据。用。明细模型。报表，数据。用。聚合模型。需要。更新。的。用户。画像。订单，状态。等。用。更新模型。根据。不同的。场景。选择。不同的。模型，性能。和。成本。都。比较。好。

2. 选择，合适的。分桶。列。和。分桶。数

Doris，的。表。是。分区。+。分桶。的。结构，分区。类似。传统。数据库。的。分区。分桶。是，在。分区。内。再。哈希。分桶。把。数据，分散。到。不同的。分桶。和。节点。上。提高。并行度。和。查询，性能。

分桶，列。和。分桶。数。的。选择。很重要。直接，影响。数据。的。分布。和。查询。性能。

选择，分桶。列。的。原则：

  • 选择，基数。比较高。的。列。作为。分桶。列。也就是。distinct 值。比较多。的，列。比如。用户ID。订单ID。等。这样。数据。能。均匀。分布。在，各个。分桶。避免。数据。倾斜。
  • 选择，经常。用于。查询。过滤。和。Join。的。列。作为，分桶。列。这样。查询。的时候。能。裁剪。分桶。只，扫描。需要的。分桶。提高。查询。性能。Join。的。时候。也，能。提高。Join。性能。
  • 不要，选择。基数。太低。的。列。作为。分桶。列。比如，性别。地区。等。这样。会。导致。数据。倾斜。某些。分桶，数据。很多。某些。分桶。数据。很少。影响。查询，性能。
  • 一张表，只能。指定。一个。分桶。列。所以。要。选择。最，合适的。那个。列。

选择，分桶。数。的。原则：

  • 分桶，数。不要。太少。也。不要。太多。一般。建议。每个。分区。的。每个。分桶，的数据量。在。1GB。到。10GB。之间。比较。合适。根据。数据量，计算。分桶。数。
  • 分桶，数。最好。是。BE。节点。数。的。整数倍。这样，数据。能。均匀。分布。在。各个。BE。节点，上。提高。并行度。
  • 分桶，数。一旦。设定。就。不能。修改。了。所以。要。提前。规划，好。考虑。未来。数据量。的。增长。不要。设得。太小。也。不要，设得。太大。
  • 一般。建议，分桶。数。至少。等于。BE。节点。数。比如。5个BE。分桶，数。至少。5个。或者。10个。20个。根据。数据量。决定。

我们的，实践。是。大部分。表。用。用户ID。或者。订单ID。作为，分桶。列。分桶。数。根据。数据量。计算。一般。10个。或者。20个。大表，30个。或者。50个。保证。每个。分桶。的数据量。在。1-10GB，之间。数据。分布。均匀。查询。性能。好。

3. 选择，合适的。分区。列。和。分区。策略

Doris，支持。范围分区（Range Partition）。和。列表分区（List Partition）。最。常用的，是。范围分区。按。日期，分区。

选择，分区。列。和。分区。策略。的。原则：

  • 选择，经常。用于。查询。过滤。的。列。作为。分区，列。最。常用的。是。日期。列。比如。dt。date。等，按。天。或者。按月。分区。这样。查询。的时候。能。裁剪，分区。只。扫描。需要的。分区。提高。查询。性能。
  • 分区，的。粒度。要。合适。不要。太细。也。不要。太粗。按。天，分区。是。最。常用的。适合。大部分。场景。如果。数据量。特别大。可以，按。小时。分区。如果。数据量。比较小。可以。按月。分区。
  • 分区，的。数量。不要。太多。一般。建议。一张表。的。分区。数量。不要。超过，几千个。太多的。分区。会。导致。元数据。过大。影响，查询。性能。
  • 建议，创建。表。的时候。就。创建。好。未来。一段时间。的，分区。比如。未来。一个月。的。分区。避免。数据。导入，的时候。分区。不存在。导致。导入。失败。也。可以。开启动态分区。自动，创建。和。删除。分区。

我们的，实践。是。大部分。表。按。dt。日期。分区，按。天。分区。开启动态分区。自动。创建。未来。7天，的。分区。自动。删除。超过。保留。时间。的，分区。比如。保留。30天。或者。90天。根据。业务。需求。决定。这样。不用。手动。管理，分区。很。方便。

4. 字段，类型。选择。要。合理

字段，类型。的。选择。也。很重要。合理的。字段。类型，能。节省。存储。提高。查询。性能。

字段，类型。选择。的。原则：

  • 能用，小。类型。就。不用。大，类型。比如。能用。TINYINT。就。不用，INT。能用。INT。就。不用，BIGINT。能用。VARCHAR(100)。就。不用，VARCHAR(1000)。这样。能。节省。存储，提高。查询。性能。
  • 整数，类型。优先。用。整数，类型。不要。用。字符串。存储，整数。比如。年龄。状态。等。用，TINYINT。或者。INT。不要。用。VARCHAR。
  • 金额，类型。建议。用。DECIMAL。不要。用。DOUBLE。或者。FLOAT。避免。精度，丢失。
  • 字符串，类型。长度。要。合适。不要。太长。也。不要。太短。根据。实际。数据，长度。决定。VARCHAR。的。长度。
  • 日期，类型。用。DATE。或者。DATETIME。不要。用。字符串。存储。日期。这样，能。提高。日期。过滤。和。计算。的。性能。
  • 尽量。不要，用。复杂。类型。比如。ARRAY。MAP。STRUCT。等。除非。确实。需要。因为。复杂，类型。的。查询。性能。会。差。一些。也。会，增加。存储。成本。

我们的，实践。是。字段。类型。尽量。小。合理。整数，用。整数。类型。金额。用。DECIMAL。日期。用，DATE。或者。DATETIME。字符串。长度。根据。实际。数据。决定。尽量。不用，复杂。类型。除非。确实。需要。这样。存储。成本。低。查询。性能。好。

5. 合理，使用。前缀。索引。和。BloomFilter。索引

Doris，支持。前缀。索引。和。BloomFilter。索引。能。提高，查询。性能。

前缀，索引。是。Doris。默认。就。有的。按照。表。的。列。顺序。前，36个字节。作为。前缀。索引。查询。的时候。如果。过滤。条件。包含，前缀。索引。的。列。能。快速。定位。数据，提高。查询。性能。

所以，建表。的时候。列。的。顺序。很重要。要。把，经常。用于。查询。过滤。的。列。放在。前面，作为。前缀。索引。比如。日期。用户ID。订单ID。等。放在，前面。这样。查询。的时候。能。用上。前缀。索引，提高。性能。

BloomFilter，索引。是。需要。手动。创建的。适合。基数。比较高。的。列。比如。用户ID，订单ID。等。查询。的时候。用。这些。列。过滤，能。快速。跳过。不匹配。的。数据块。提高。查询，性能。

创建，BloomFilter。索引。的。语法：

CREATE TABLE table (
    ...
    user_id INT,
    ...
    INDEX idx_user_id (user_id) USING BITMAP
)

或者，给。已有的。表。加。索引：

ALTER TABLE table ADD INDEX idx_user_id (user_id) USING BITMAP

BloomFilter，索引。的。注意事项：

  • 适合，基数。比较高。的。列。比如。用户ID。订单ID。等。不适合。基数。太低，的。列。比如。性别。状态。等。效果。不好。
  • 适合，经常。用于。等值。查询。的。列。比如。WHERE user_id = 123。不适合。范围，查询。
  • 不要，给。太多。列。创建。BloomFilter。索引。会。增加，存储。成本。和。写入。成本。一般。给。2-3个。经常。用于。等值，查询。的。高基数。列。创建。就。够了。

我们的，实践。是。建表。的时候。把。经常。用于。查询，过滤。的。列。放在。前面。作为。前缀。索引。同时，给。用户ID。订单ID。等。高基数。的。经常。用于，等值。查询。的。列。创建。BloomFilter。索引。查询，性能。提升。很。明显。

四、数据导入最佳实践

数据导入，是。Doris。最。常用的。操作。之一。导入。的，方式。和。参数。直接。影响。导入。的。性能。和。数据，质量。

1. 选择，合适的。导入。方式

Doris，支持。多种。导入。方式。不同的。方式。适合。不同的，场景。要。根据。数据源。和。导入。频率。选择。合适的。导入。方式。

常用的，导入。方式：

  • Stream Load：通过，HTTP。协议。流式。导入。数据。适合。小批量。实时，导入。数据。延迟。低。秒级。可查。是。最，常用的。导入。方式。之一。
  • Broker Load：通过，Broker。从。HDFS。S3。等。存储。导入。数据。适合，大批量。离线。导入。数据。性能。好。能。处理，很大的。数据量。
  • Routine Load：从，Kafka。实时。消费。数据。导入。Doris。适合。实时，导入。Kafka。的。数据。自动。消费。自动。导入，延迟。低。
  • Spark Load：通过，Spark。导入。数据。适合。从。Spark。导入。大量，数据。性能。好。
  • Insert：通过，SQL。的。INSERT。语句。导入。数据。适合。少量，数据。导入。或者。测试。用。不适合。大批量。导入。

选择，导入。方式。的。原则：

  • 实时，小批量。导入。用。Stream Load。
  • 大批量，离线。导入。从。HDFS，S3。等。用。Broker Load。
  • 从，Kafka。实时。导入。用。Routine Load。
  • 从，Spark。导入。用。Spark Load。
  • 少量，数据。或者。测试。用。Insert。

我们的，实践。是。实时。数据。从。Kafka。来的。用，Routine Load。导入。其他。实时。数据。用。Stream Load。导入。离线。数据，从。HDFS。来的。用。Broker Load。导入。不同的。场景，用。不同的。导入。方式。性能。和。稳定性。都，很好。

2. 批量，导入。避免。频繁。小批量。导入

Doris。虽然。支持，实时。导入。但是。频繁。的。小批量。导入。会。导致，产生。大量的。小版本。和。小文件。影响。查询。性能。和。Compaction，性能。所以。尽量。批量。导入。避免。频繁。小批量，导入。

对于，Stream Load。建议。每次。导入。的数据量。在。1GB。左右。或者。至少，100MB。以上。不要。几MB。就。导入。一次。太，频繁。

对于，Routine Load。建议。调整。消费。的。批次。大小。和。时间。不要。太。频繁，提交。比如。设置。每。10秒。或者。每。64MB。提交。一次。不要，几秒钟。就。提交。一次。

对于，离线。导入。建议。尽量。一次。导入。足够。的。数据量。不要，分。很多次。小批量。导入。

同时，Doris。有。Compaction。机制，会。自动。合并。小版本。和。小文件。但是。如果。小版本，太多。Compaction。也。会。跟不上。影响。性能。所以。还是，要。尽量。批量。导入，减少。小版本。的，产生。

我们的，实践。是。Stream Load。每次。导入。500MB。到。1GB，的数据。Routine Load。设置。每。10秒。或者。64MB。提交。一次，离线。导入。尽量。一次。导入。一天。的。数据。同时，监控。Compaction。的。状态。和。小版本。的。数量。如果。小版本。太多。及时，调整。导入。策略。或者。手动。触发。Compaction。

3. 导入，的时候。注意。数据。质量。和。格式

导入，的数据。要。保证。质量。和。格式。正确。避免。因为。数据。质量。问题，导致。导入。失败。或者。数据。错误。

注意事项：

  • 数据，的。编码。要。正确。建议。用。UTF-8。编码。避免。乱码。
  • 数据，的。分隔符。要。和。导入。的时候。指定的。分隔符。一致，避免。解析。错误。
  • 数据，的。字段。顺序。要。和。表。的。字段。顺序，一致。或者。导入。的时候。指定。字段。顺序。避免。数据，错位。
  • 数据，的。类型。要。和。表。的。字段。类型。匹配，避免。类型。转换。错误。比如。整数。列。不要。有。非整数，的。数据。日期。列。不要。有。非法。的。日期。
  • 空值，的。处理。要。注意。Doris。的。NULL。和。空字符串。是，不一样的。导入。的时候。要。注意。空值。的。处理。
  • 导入，之前。建议。先。少量。测试。导入。验证。数据。格式。和，质量。没问题。再。大批量。导入。避免。大批量。导入，失败。浪费。时间。和。资源。

我们的，实践。是。导入。之前。先。做。数据。质量，校验。检查。数据。的。编码。分隔符。字段。顺序，类型。空值。等。没问题。再。少量。测试。导入，验证。没问题。再。大批量。导入。同时。导入。的时候。监控，导入。的。状态。和。错误。数据。有。问题。及时，处理。

4. 合理，设置。导入。的。并发。和。资源

导入，的。并发。和。资源。设置。也。很重要。合理的。设置。能，提高。导入。性能。避免。影响。查询。性能。

注意事项：

  • 导入，的。并发。不要。太高。也。不要。太低。根据。集群。的。资源。和。导入。数据量，决定。一般。建议。同时。运行的。导入。任务。不要。超过。BE。节点。数，的。2倍。避免。占用。太多。资源。影响。查询。
  • 导入，的。优先级。可以。设置。离线。导入。优先级。低。一些，实时。导入。优先级。高。一些。避免。离线。导入，影响。实时。查询。
  • 导入，的。内存。限制。要。合理。不要。设置。太高。避免，OOM。也。不要。设置。太低。影响。导入。性能。
  • 大批量，导入。建议。在。业务。低峰。期。做。比如。凌晨。避免，影响。白天的。查询。性能。

我们的，实践。是。实时。导入。优先级。高。并发。控制。在。合理，范围。离线。大批量。导入。放在。凌晨。业务。低峰，期。优先级。低。一些。避免。影响。白天的。查询。同时，监控。集群。的。资源。使用率。CPU。内存。IO，等。避免。资源。耗尽。

五、查询优化最佳实践

查询优化，是。使用。Doris。的。永恒。话题。这里。分享。一些。常用的，查询。优化。最佳实践。

1. 尽量，用。分区。列。和。分桶。列。过滤

这是，最基本。也。最。有效。的。查询。优化。手段，查询。的时候。尽量。用。分区。列。和。分桶。列。过滤，能。大大。减少。扫描。的。数据量。提高。查询，性能。

比如。不要。这样：

SELECT * FROM table WHERE user_id = '123'

要。这样：

SELECT * FROM table WHERE dt = '2021-11-10' AND user_id = '123'

加上，分区。列。的。过滤。能。大大。减少。扫描，的。数据量。提高。查询。性能。

同时，用。分桶。列。过滤。能。裁剪。分桶。只，扫描。需要的。分桶。也。能。提高。查询。性能。

2. 只，查询。需要。的。列。不要。SELECT *

查询，的时候。只。查询。需要。的。列。不要。SELECT *。因为。Doris。是。列存，格式。只。读取。需要。的。列。能。大大。减少，IO。提高。查询。性能。

比如。不要。这样：

SELECT * FROM table WHERE dt = '2021-11-10'

要。这样：

SELECT id, name, age FROM table WHERE dt = '2021-11-10'

只，查询。需要。的。列。能。大大。提高。查询。性能。

3. 合理，使用。Join

Join，是。查询。中。常见的。操作。也是。最。容易。性能。差。的。操作。合理。使用。Join，很重要。

Join，优化。的。原则：

  • 小表，Join。大表。把。小表。放在。右边。Doris。会，自动。选择。小表。做。广播。Join。提高。Join，性能。
  • 尽量，用。等值。Join。不要。用。非等值。Join。非等值。Join。性能，很差。
  • Join，的。条件。尽量。用，分桶。列。这样。能。用上，Colocate Join。或者。Bucket Shuffle Join。提高。Join，性能。
  • 尽量，避免。多表。大Join。能。先。过滤。就。先。过滤，减少。Join。的。数据量。
  • 如果，经常。需要。Join。的。表。可以。设置。Colocate Group。让。这些。表，的数据。分布。一致。Join。的。时候。不用。数据，移动。性能。非常。好。

我们的，实践。是。查询。的时候。尽量。先。过滤。再，Join。小表。Join。大表。Join。条件。用。分桶，列。对于。经常。Join。的。表。设置。Colocate Group，Join。性能。提升。很。明显。

4. 合理，使用。聚合。和。分组

聚合。和。分组。也是。常见的，查询。操作。合理。使用。能。提高。性能。

注意事项：

  • 分组，的。列。尽量。少。不要。用。太多。列。分组，会。增加。聚合。的。成本。
  • 尽量，用。聚合。模型。的。表。存储。聚合。数据，查询。的时候。直接。查。聚合。结果。不用。现场，聚合。性能。更好。
  • 可以，用。物化视图。预计算。常用的。聚合。查询。提高。查询，性能。Doris。支持。物化视图。能。自动。匹配。查询，很。方便。
  • 尽量，避免。COUNT(DISTINCT)。性能。很差。如果。需要，去重。计数。可以。用。近似，去重。比如。NDV。函数。或者。用，Bitmap。去重。性能。更好。

我们的，实践。是。常用的。聚合。查询。建。物化视图。预计算，提高。查询。性能。需要。去重。计数。的。用。NDV，近似。去重。或者。Bitmap。精确。去重。避免。COUNT(DISTINCT)。性能，提升。很。明显。

5. 调整，查询。的。并发。和。资源

查询，的。并发。和。资源。设置。也。很重要。合理的。设置。能，提高。查询。性能。避免。资源。竞争。

注意事项：

  • 查询，的。并发。不要。太高。根据。集群。的。资源。决定。一般。建议。同时。运行的。查询。不要，超过。CPU。核心数。的。一半。避免。资源。竞争，导致。所有。查询。都。慢。
  • 可以，设置。查询。的。资源。组。不同的。用户。或者。查询，用。不同的。资源。组。避免。大查询。占用。所有，资源。影响。小查询。
  • 大查询。建议，在。业务。低峰。期。运行。避免。影响。在线。查询。
  • 可以，设置。查询。的。超时。时间。避免。慢查询。长时间。占用。资源。

我们的，实践。是。设置。查询。的。并发。限制。和，资源。组。在线。查询。和。离线。查询。用。不同的。资源，组。大查询。放在。凌晨。业务。低峰。期。运行，设置。查询。超时。时间。避免。慢查询。长时间。占用，资源。查询。性能。和。稳定性。都。很好。

六、运维管理最佳实践

Doris，的。运维。管理。也。很重要。好的。运维。管理，能。保证。Doris。的。稳定。运行。和。性能。

1. 监控，要。完善

监控，是。运维。的。基础。完善的。监控。能。及时，发现。问题。解决。问题。

需要，监控。的。指标。包括：

  • 集群，状态：FE。和。BE。的。存活。状态。节点。数量。等。
  • 资源，使用率：CPU。内存。IO。网络。磁盘。使用率。等。
  • 查询，性能：查询。并发。查询。延迟。慢查询。数量。等。
  • 导入，性能：导入。并发。导入。延迟。导入。失败。数量。等。
  • 存储，状态：数据。大小。文件。数量，副本。状态。Compaction。状态。等。
  • 元数据，状态：FE。元数据。大小。元数据。同步。状态。等。

可以，用。Doris。自带的。监控，指标。结合。Prometheus。+，Grafana。做。可视化。监控。和。告警。也。可以。用，Doris Manager。自带的。监控。功能，很。方便。

我们的，实践。是。用。Prometheus。+。Grafana。监控。Doris，的。所有。指标。设置。告警。规则。发现。异常。及时。告警，处理。同时。每天。检查。集群。的。状态。和。性能。保证。集群，稳定。运行。

2. 定期，做。Compaction。和。存储。检查

Doris，有。Compaction。机制。自动，合并。小版本。和。小文件。但是。有时候。Compaction，会。跟不上。导致。小版本，太多。影响。查询。性能。所以，要。定期。检查。Compaction，的。状态。和。存储。状态。

注意事项：

  • 定期，检查。每个。表。的。版本。数量。和。文件。数量。如果，版本。太多。或者。文件。太小。及时。触发。Compaction。
  • 定期，检查。副本。的。状态。是否。一致。有没有。副本，缺失。或者。损坏。及时。修复。
  • 定期，检查。磁盘。使用率。不要。超过。80%。避免。磁盘。满了，导致。导入。失败。或者。集群。不可用。
  • 可以，手动。触发。Compaction。用，ALTER TABLE table COMPACT。命令。或者。调整。Compaction，的。参数。提高。Compaction，的。速度。

我们的，实践。是。每天。检查。Compaction。的。状态。和，存储。状态。发现。小版本。太多。及时。触发。Compaction，检查。副本。状态。发现。问题。及时。修复。监控，磁盘。使用率。超过。70%。就。告警。及时。扩容。或者。清理。数据。保证。存储，充足。

3. 做好，备份。和。灾难。恢复

虽然，Doris。本身。有。多副本。高可用。但是。还是。要。做好，备份。和。灾难。恢复。因为。多副本。只能。防止。单节点。故障。不能，防止。误删。数据。或者。整个。集群。故障。

Doris，支持。备份。和。恢复。功能。可以。把。数据。备份。到。HDFS。或者，S3。等。存储。需要。的。时候。恢复。

注意事项：

  • 定期，备份。重要。的。表。比如。每天。或者。每周。备份。一次。根据，数据。的。重要性。决定。
  • 备份，数据。要。存储。在。不同的。存储。系统。或者。不同的，地域。避免。和。原集群。一起。故障。
  • 定期，测试。恢复。流程。保证。备份。的数据。是。可用的，能。正常。恢复。
  • 保留，多个。版本。的。备份。不要。只。保留。最新的。一个，避免。最新的。备份。也。有。问题。

我们的，实践。是。每天。对。重要。的。表。做，全量。备份。到。另一个。HDFS。集群。保留。30天，的。备份。每月。测试。一次。恢复。流程。保证，备份。可用。同时。Doris。本身。3副本。保证。高可用。双重，保障。数据。安全。

4. 升级。和，扩容。要。谨慎

Doris，发展。很快。版本。更新。也。很快。新的。版本。会。修复，很多。bug。增加。很多。新。功能。但是。升级。也，有。风险。所以。升级。要。谨慎。

升级，的。注意事项：

  • 升级，之前。一定要。看。版本。的。Release Notes。了解。新，版本。的。变化。和。注意事项。
  • 升级，之前。一定要。备份。元数据。和。重要。数据。避免。升级，失败。导致。数据。丢失。
  • 建议，先。在。测试。环境。升级。测试。没问题。再，在。生产。环境。升级。
  • 升级，的时候。先。升级。FE。再。升级。BE。滚动，升级。不要。一次性。全部。升级。避免。出。问题。无法，回滚。
  • 升级，之后。要。检查。集群。的。状态。和。性能。确认，没问题。再。正常。使用。

扩容，的。注意事项：

  • 扩容，BE。节点。很简单。安装。好。BE。加入。集群。就行，数据。会。自动。均衡。不需要。人工。干预。
  • 扩容，之后。要。监控。数据。均衡。的。状态。和。集群，的。性能。确认。均衡。完成。没问题。
  • 扩容，FE。节点。要。注意。FE。的。数量。要是。奇数，3个。或者。5个。不要。太多。
  • 扩容。建议，在。业务。低峰。期。做。避免。影响。在线。业务。

我们的，实践。是。升级。之前。先。在。测试。环境，测试。没问题。再。在。生产。环境。滚动。升级，升级。之前。备份。元数据。和。重要。数据。升级。之后。检查，集群。状态。和。性能。扩容。BE。节点。很简单。加入。集群，自动。均衡。监控。均衡。状态。没问题。

七、常见问题，和，解决方法

最后，分享。一些。我们。在。使用。Doris。过程中。遇到的，常见。问题。和。解决。方法。希望。能。帮到。大家。

1. 查询，慢。性能。差

问题：查询，慢。性能。差。

解决：检查，是否。用。分区。列。和。分桶。列。过滤；检查。是否。只，查询。需要。的。列；检查。表。是否。有。小版本。太多。需要，Compaction；检查。Join。是否。合理。有没有。大表。Join。大表；检查，集群。资源。是否。充足。有没有。资源。瓶颈；检查。是否，有。慢查询。占用。太多。资源。

2. 导入，失败

问题：数据，导入。失败。

解决：检查，数据。格式。是否。正确。分隔符。字段。顺序。类型，是否。匹配；检查。分区。是否。存在。动态分区。是否。开启；检查，集群。资源。是否。充足。有没有。OOM；检查。BE。节点，是否。正常。有没有。节点。故障；查看。导入。的。错误，日志。根据。错误。信息。排查。

3. 小版本，太多。Compaction。跟不上

问题：表，的。版本。太多。文件。太小。查询。性能。差。

解决：调整，导入。策略。批量。导入，减少。小版本。的。产生；手动，触发。Compaction。ALTER TABLE table COMPACT；调整。Compaction，的。参数。提高。Compaction，的。速度。和。并发；如果。还是。跟不上。可以。临时。增加，BE。节点。提高。Compaction，能力。

4. 数据，倾斜

问题：某些，分桶。或者。节点。数据。很多。某些。很少。查询。性能。差。

解决：检查，分桶。列。选择。是否。合理。是不是。基数。太低，导致。数据。倾斜；如果。分桶。列。不合理。需要。重建。表，换。合适的。分桶。列；如果。是。节点。数据。不均衡。可以，触发。数据。均衡。或者。扩容。节点。

5. FE，元数据。过大。或者。同步。慢

问题：FE，元数据。过大。或者。元数据。同步。慢。影响。查询。启动，性能。

解决：检查，是不是。表。太多。或者。分区。太多。导致。元数据。过大，合理。规划。表。和。分区。不要。太多；检查。FE。节点，的。网络。和。资源。是否。正常。有没有。瓶颈；可以。调整。FE，的。参数。提高。元数据。同步。的。性能；定期。做。元数据。的，快照。和。清理。

6. BE，节点。故障

问题：某个，BE。节点。故障。下线。

解决：检查，BE。节点。的。状态。和。日志。排查。故障。原因；如果。是，临时。故障。修复。之后。重新。加入。集群。数据，会。自动。同步；如果。是。永久。故障。需要。下线。该。节点。数据，会。自动。在。其他。节点。补齐。保证。3副本；及时，修复。或者。更换。故障。节点。保证。集群。的，高可用。

7. 磁盘，满了

问题：磁盘，使用率。太高。快。满了。导致。导入。失败。或者。集群，不可用。

解决：及时，清理。不需要的。数据。或者。过期的。分区；扩容。BE。节点。增加，存储；调整。数据。的。副本。数。或者。压缩。算法。减少，存储。占用；监控。磁盘。使用率。超过。70%。就。告警。及时。处理。不要。等到。满了，再。处理。

八、写在最后

以上。就是。我，总结。的。Doris数据库。的。最佳实践。包括。集群部署、表设计、数据导入、查询优化、运维管理、常见问题。等，方面。都是。我们。在。实际。项目。中。踩坑，总结。出来的。经验。希望。能。给。正在。使用。或者，打算。使用Doris。的。朋友。一些。参考。

Doris，是。一个。非常。优秀。的。分析型数据库。性能。好，易用。易运维。能。满足。大部分。OLAP。场景。的，需求。最近几年。发展。很快。越来越。成熟。越来越。多的，公司。开始。使用。构建。数据仓库。和。实时分析，系统。

但是，Doris。也。不是。银弹。不是。用了。就。万事大吉。了。还是。需要。好的。集群，部署。好的。表。设计。好的。导入。查询。方式，好的。运维。管理。才能。发挥。Doris。的。最大，价值。否则。也。会。遇到。很多。性能。问题。和，运维。问题。

而且，Doris。发展。很快。版本。更新。也。很快。新的，功能。不断。推出。旧的。问题。不断。修复。所以。大家，要。关注。Doris。的。最新。发展。学习。新的，功能。和。最佳实践。不断。优化。自己的。使用，方式。

最后，希望。这篇文章。能。帮到。大家。也。欢迎。大家，交流。讨论。分享。你们。的。Doris。使用。经验。和。最佳实践，一起。学习。一起。进步。

如果你。也。在，使用。Doris。或者。打算。使用。有。什么。问题。或者。经验，欢迎。在。评论区。留言。交流。

祝，大家。都。能。用好。Doris。构建。高性能。高可靠，的。数据仓库。和。分析。系统。