doris – gitweixin

doris 6月 10,2025

Doris FE配置中的自动恢复选项

Doris FE 的自动恢复功能主要通过 metadata_failure_recovery 配置项实现，用于在元数据异常或集群脑裂时恢复 FE 的元数据一致性。以下是具体配置和使用方法：

1. 配置参数说明

参数位置：在 FE 的配置文件 fe.conf 中添加或修改以下参数：properties复制metadata_failure_recovery=true
作用：
- 启用元数据恢复模式：清空本地 BDBJE 的元数据存储，尝试从其他节点恢复最新元数据。
- 适用场景：FE 无法正常启动（如元数据损坏、脑裂）、集群失去 Master 节点等。

2. 不同场景下的配置方法

场景 1：单节点 FE 故障

操作步骤：
1. 在 fe.conf 中添加 metadata_failure_recovery=true。
2. 重启 FE：sh bin/start_fe.sh --daemon。
3. 恢复成功后，移除该配置或设置为 false，避免后续自动触发恢复8。

场景 2：多节点 FE 故障（需手动选择 Master）

定位最新元数据节点：
- 检查所有 FE 的 meta_dir/image 目录，找到 image.xxxx 中数字最大的节点（元数据最新）8。
恢复 Master：
- 在最新元数据节点的 fe.conf 中添加 metadata_failure_recovery=true。
- 重启 FE，观察日志确认是否成功切换为 Master（日志中出现 transfer from XXXX to MASTER）6。
清理其他节点：
- 删除旧 Master 和其他 Follower：ALTER SYSTEM DROP FOLLOWER "IP:PORT";。
- 重新添加 Follower：ALTER SYSTEM ADD FOLLOWER "IP:PORT";8。

场景 3：Observer 节点恢复

特殊处理：
- 若 Observer 的元数据最新，需先修改 meta_dir/image/ROLE 文件，将 role=OBSERVER 改为 role=FOLLOWER。
- 按 Follower 恢复流程操作，避免角色不一致问题。

3. 版本差异

Doris ≥2.0.2：支持命令行参数直接启用恢复模式：bash复制sh bin/start_fe.sh --metadata_failure_recovery --daemon
Doris <2.0.2：需在 fe.conf 中添加 metadata_failure_recovery=true7。

4. 注意事项

仅限紧急恢复：恢复模式会清空本地元数据，需确保其他节点元数据可用。
恢复后操作：
- 恢复成功后必须移除 metadata_failure_recovery 配置，否则下次重启会再次触发恢复。
- 检查集群状态：SHOW FRONTENDS; 确认所有节点状态正常。
脑裂风险：恢复过程中可能产生脑裂，建议在操作前备份元数据目录（fe/doris-meta）4。

5. 预防措施

高可用部署：建议配置 3 个 Follower 或 1 Follower + 1 Observer，避免单点故障7。
定期备份：通过 BACKUP 命令或 Doris Manager 定期备份元数据。
监控告警：使用 Doris Manager 或第三方工具监控 FE 状态，及时触发恢复流程4。

作者 east

doris 5月 22,2025

doris的动态分区，可以yyyy-MM这种年月格式的日期格式来做为分区吗

Doris 的 动态分区（dynamic partition） 默认支持的分区字段格式是 标准的 DATE 或 DATETIME 类型，但你提到的 yyyy-MM（即只有年月，没有日）的格式属于不完整日期（非标准 DATE 类型），不能直接用作分区字段。

但可以通过 以下方法间接实现以年月为粒度的分区。

✅ 一、推荐方式：使用 `DATE` 字段 + 动态分区，按月分区

虽然不能直接用 yyyy-MM，但你可以用 DATE 类型字段（例如 2024-05-01），然后通过 动态分区的 granularity 为 MONTH 的方式实现「按月分区」。

示例：

CREATE TABLE example_table (
     id INT,
     event_time DATE
 )
 DISTRIBUTED BY HASH(id) BUCKETS 10
 PARTITION BY RANGE(event_time) ()
 PROPERTIES (
     "dynamic_partition.enable" = "true",
     "dynamic_partition.time_unit" = "MONTH",
     "dynamic_partition.start" = "-12",
     "dynamic_partition.end" = "3",
     "dynamic_partition.prefix" = "p",
     "dynamic_partition.buckets" = "10",
     "dynamic_partition.create_history_partition" = "true"
 );

效果：

会自动创建如下分区：

分区名	分区范围（event_time）
p202405	[2024-05-01, 2024-06-01)
p202406	[2024-06-01, 2024-07-01)

你在写入数据时，只需往 event_time 列写入标准的 DATE 类型值（如 2024-05-10），Doris 会自动路由到对应分区 p202405。

✅ 二、如果你的原始数据字段是 `yyyy-MM` 字符串格式

你需要：

在写入时用 SQL 转换成 DATE 类型；
或者使用视图或计算列。

示例：将 `yyyy-MM` 字符串转换为 `DATE`

-- 假设有个 staging 表字段是 "2024-05"
 SELECT STR_TO_DATE(CONCAT(partition_ym, '-01'), '%Y-%m-%d') AS event_time
 FROM staging_table;

然后写入主表中。

🚫 不推荐：直接使用字符串 `yyyy-MM` 作为分区字段

虽然技术上可以用 VARCHAR 字段做 RANGE 分区，但：

无法使用动态分区功能（只支持 DATE/DATETIME 字段）；
不能使用时间函数做范围推导、自动创建分区等操作；
写入和查询逻辑不直观、不易维护。

作者 east

doris 3月 6,2025

Apache Doris内存与超时参数配置详解

以下是根据你的需求整理的Apache Doris内存与超时参数配置详解，结合了相关技术文档和实践经验：

一、查询任务内存限制调整

1. 默认内存限制与问题定位

Apache Doris默认限制单个BE节点上的查询任务内存使用不超过2GB（即exec_mem_limit=2147483648字节）。当复杂查询或大规模数据操作超过此限制时，会触发Memory limit exceeded错误。通过以下命令可查看当前配置：

SHOW VARIABLES LIKE "%mem_limit%";

输出示例：

+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| exec_mem_limit | 2147483648 |  -- 默认2GB
| load_mem_limit | 0          |  -- 导入任务内存限制（0表示无限制）
+----------------+------------+

2. 调整内存限制的方法

临时调整（当前会话生效）
通过SET命令修改会话级参数，适用于单次查询优化：sqlSET exec_mem_limit = 8589934592; -- 设置为8GB
永久生效（全局配置）
添加GLOBAL参数以全局生效，需在FE节点配置中持久化：sqlSET GLOBAL exec_mem_limit = 8589934592;
注意事项：
- 若集群资源有限，需结合BE节点的总内存（通过mem_limit参数控制）合理分配，避免单任务占用过高导致节点OOM6。
- 高并发场景建议通过资源标签（Resource Label）隔离关键任务，防止资源争用6。

二、查询超时时间优化

1. 默认超时机制与配置查询

Doris默认查询超时时间为300秒（5分钟），可通过以下命令查看：

sqlSHOW VARIABLES LIKE "%query_timeout%";

输出示例：

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| query_timeout | 300   |
+---------------+-------+

2. 延长超时时间的操作

临时调整（当前会话生效）sqlSET query_timeout = 600; -- 设置为600秒（10分钟）
永久生效（全局配置）sqlSET GLOBAL query_timeout = 600;动态生效特性：与内存参数不同，超时参数修改后通常无需重启集群即可生效7。

三、关联参数与调优实践

1. 内存管理联动配置

BE节点总内存限制（mem_limit）
控制单个BE进程的最大内存使用，默认根据物理内存自动计算（如物理内存的90%或物理内存-6.4GB）。建议在be.conf中显式设置，避免资源竞争4。bashmem_limit = 80% # 或具体值如32G
Compaction内存限制（compaction_memory_bytes_limit）
控制数据合并任务的内存使用上限，默认值根据系统配置动态调整。若频繁因Compaction导致查询内存不足，可适当调低此参数5。

2. 高并发场景优化策略

并行度与资源分配
提升查询并行度（parallel_degree）可加速处理，但需平衡CPU和内存消耗。例如：sqlSET GLOBAL parallel_degree = 16; -- 根据CPU核心数调整
物化视图与分区优化
对高频查询创建物化视图或合理分区，减少单次查询的数据扫描量，间接降低内存需求6。

四、操作验证与监控

验证参数生效
修改后通过SHOW VARIABLES确认新值是否生效，并执行测试查询观察内存使用情况。
日志与监控工具
- FE日志：检查fe.log中内存超限或超时任务记录3。
- BE监控：通过curl http://BE_IP:8040/api/compaction/show?tablet_id=XXX查看Tablet状态3。
- 系统视图：使用SHOW PROC '/admin/stats'实时监控资源使用6

作者 east

doris 2月 7,2025

Doris更新某一列完整教程

通过临时表来更新
例如有下面的表结构

ods_t_iot (
pid varchar(255) NOT NULL,
ptime bigint NOT NULL,
pvalue decimal(38,9) NOT NULL,
ds varchar(30) NULL
) ENGINE=OLAP
UNIQUE KEY(pid, ptime, pvalue, ds)
需要把ds这一列更新为2025-02-07

创建一个新表并导入数据
由于不能直接使用 UPDATE，一种常见的方法是创建一个新表，然后通过批量插入的方式将数据导入，并修改 ds 列的值。下面是详细步骤：

步骤 1: 创建一个新表
首先，我们需要创建一个新的表，结构与原表一致，唯一的区别是我们会把 ds 列的默认值设置为 ‘2025-02-07’，并确保与原表的列顺序、类型保持一致。

CREATE TABLE ods_t_iot_new like ods_t_iot;
步骤 2: 使用 INSERT INTO SELECT 语句从原表导入数据
接下来，我们将原表的数据导入到新表中，同时确保 ds 列的值设置为 ‘2025-02-07’。可以使用以下 SQL：

INSERT INTO ods_t_iot_new (pid, ptime, pvalue, ds) SELECT pid, ptime, pvalue, IFNULL(ds, ‘2025-02-07’) AS ds FROM ods_t_iot;
在这里，IFNULL(ds, ‘2025-02-07’) 会将原表中 ds 列为 NULL 的数据替换为 ‘2025-02-07’。

步骤 3: 删除原表并重命名新表
导入数据完成后，我们可以删除原表并将新表重命名为原表名。这样，所有数据都已经更新，ds 列也被设置为 ‘2025-02-07’。

DROP TABLE ods_t_iot;

ALTER TABLE ods_t_iot_new RENAME ods_t_iot;

作者 east

doris 1月 14,2025

解决Navicat查看导入运行任务ROUTINE：1105 – errCode = 2, detailMessage = Please check your sql, we meet an error when parsing.

第一次通过 Doris Routine Load 导入方式持续消费 Kafka Topic 中的数据。按官方文档
Routine Load – Apache Doris

在navicat按照官方示例查看导入任务：

mysql> SHOW ROUTINE LOAD FOR testdb.example_routine_load\G

发现报错：

1105 – errCode = 2, detailMessage = Please check your sql, we meet an error when parsing.

刚开始很郁闷，以为doris官方团队开发的功能很敷衍，没具体提示具体是什么错误。

反复试验之后，才发现是\G 导致报错，修改为下面这样就正常了

mysql> SHOW ROUTINE LOAD FOR testdb.example_routine_load

作者 east

doris 9月 18,2024

Doris Unique模型用于离线数仓的ODS层的好处

在离线数仓的ODS（Operational Data Store，操作型数据存储）层使用 Doris 的 Unique 模型有多个好处。Doris 提供多种数据模型，其中 Unique 模型专门用于保证数据唯一性，适合一些有去重需求的场景。将 Unique 模型应用于 ODS 层的主要优点包括：

1. 保证数据的唯一性

ODS 层通常存储从源系统抽取的原始数据，这些数据可能存在重复问题。Doris 的 Unique 模型通过唯一键（Primary Key）确保数据的唯一性，避免重复数据的出现。这在整合来自多个源的相同实体时非常重要，比如处理重复的用户、订单、交易等。

2. 便于数据更新

ODS 层的数据可能会发生变化，数据会不断地被更新或增量加载。Doris 的 Unique 模型允许基于唯一键进行记录的更新和覆盖，这使得数据变更（如状态更新、数据修正等）能够方便地应用到表中，而不必执行复杂的删除和插入操作。

3. 提高查询效率

尽管 ODS 层主要用作数据存储的中间层，但在有需要时，也会进行数据查询或分析。Unique 模型通过主键索引提高查询效率，特别是针对带有唯一键的查询。在处理大规模数据时，索引结构可以加速数据检索和聚合查询。

4. 适合维度更新频繁的场景

ODS 层的数据源自多个系统，维度数据的更新可能非常频繁。Doris 的 Unique 模型允许在 ODS 层快速处理这种频繁更新的数据，从而保持数据的最新状态。

5. 简化数据清洗和预处理

在离线数仓的 ODS 层，数据清洗和预处理是重要的步骤。Unique 模型帮助通过去重和数据规范化简化这一过程，确保数据质量，并为后续 DWH 层（数据仓库层）或 DM（数据集市层）的构建奠定坚实基础。

6. 高并发性能

Doris 具有高性能的并行处理能力，支持高并发的数据写入和查询，这对于离线数据仓库中的批量数据处理非常重要。Unique 模型能够高效处理大规模数据的批量导入和更新操作。

7. 灵活的扩展性

ODS 层的数据量通常非常庞大，并且随时间逐步扩展。Doris 的分布式架构和 Unique 模型的设计，支持在集群中进行水平扩展，适应离线数仓 ODS 层的扩展需求。

作者 east

doris, Hive 9月 18,2024

Doris在离线数仓代替hive的理由

Apache Doris 是一个现代化的MPP（Massively Parallel Processing）数据库，特别适合数据分析和在线查询场景。Doris 在某些情况下可以替代 Hive 作为离线数仓，主要是因为以下几个关键原因：

1. 查询性能

高效的查询执行：Doris 专为高并发和低延迟的查询设计，支持秒级查询响应，特别适合高性能的实时分析需求。
列存储格式：Doris 使用列式存储，能够在查询时只扫描需要的列，大幅减少 I/O，优化了查询性能。相比之下，Hive 的查询速度通常较慢，尤其是对大规模数据集的多维分析。
向量化执行引擎：Doris 引入了向量化执行引擎，这种设计能高效利用 CPU 资源，在批处理数据时能加快计算速度。而 Hive 在执行复杂查询时，性能可能受到较大的开销影响。

2. 支持实时数据加载和更新

Doris 支持 流式数据导入，能够做到近实时的数据更新，这对于需要处理不断更新的业务数据的离线数仓场景非常有用。
Hive 通常依赖批处理方式更新数据，延迟较高，不能很好地处理实时数据需求。

3. 易用性和生态

SQL 兼容性高：Doris 提供丰富的 SQL 语法支持，接近 ANSI SQL 标准，开发人员可以轻松上手，不需要学习新的查询语言。
操作简便：Doris 集成度高，操作简单，支持集群自动容错、自动扩展、负载均衡等功能。而 Hive 的操作复杂度较高，通常依赖 Hadoop 生态中的多个组件（如 YARN、HDFS 等），维护难度较大。
轻量级部署：Doris 的架构更加轻量，不依赖像 Hadoop 这样复杂的集群，降低了基础设施和运维成本。

4. 支持复杂分析场景

多维分析：Doris 支持类似 OLAP（Online Analytical Processing）的多维数据分析，适合进行复杂的聚合和多维度的数据查询。通过并行处理和多种索引机制，Doris 可以在大规模数据场景下快速响应复杂查询需求。
Hive 的局限性：Hive 主要是批处理工具，虽然它支持复杂查询，但执行时间通常较长，尤其在需要多维分析和实时交互式查询时表现较差。

5. 数据模型和压缩

自动分区和索引：Doris 支持自动分区和多种索引方式，如倒排索引、位图索引等，极大优化了数据查询的效率。相比之下，Hive 的分区管理较为复杂且手动操作较多。
压缩和存储优化：Doris 采用高效的压缩算法，降低了存储成本。与之相比，Hive 对于数据的存储优化较为有限，依赖底层的 HDFS 文件系统，压缩和解压缩需要额外配置和操作。

6. 高可扩展性和分布式架构

Doris 拥有强大的分布式架构，支持大规模集群扩展，能够处理海量数据并保持良好的性能表现。
Hive 依赖 Hadoop 分布式文件系统（HDFS），尽管具备扩展性，但性能受限于 Hadoop 集群的配置和调度方式。

7. 统一的存算架构

Doris 提供存储和计算紧密耦合的架构，这让数据读取和处理变得更加高效。Hive 则是存算分离的架构，往往需要依赖外部的计算引擎（如 Tez 或 Spark）来执行查询，这带来了额外的计算和数据调度开销。

8. 社区和企业支持

Doris 拥有活跃的开源社区，并且在国内外的大型互联网公司中得到了广泛应用。它的发展速度快，更新频繁，支持企业级的使用场景。
Hive 作为 Hadoop 生态的一部分，虽然历史悠久，但其发展较为缓慢，主要适用于传统的批处理场景。

总结

Doris 在替代 Hive 作为离线数仓的过程中，主要依赖于其高性能查询、实时数据处理、易用性和更适合复杂多维分析的优势。Doris 对于需要实时响应的数仓场景或大规模多维分析的企业特别具有吸引力，而 Hive 由于其批处理的特性，更适合传统的离线批量计算场景。在新兴的数仓建设中，Doris 是更为现代化的选择。

作者 east

doris, Flink 9月 18,2024

流批一体化，Flink+Doris取代Spark+Hive来开发离线数仓

Flink + Doris 可以作为替代方案，用于开发离线数仓，替代 Spark + Hive 组合。这个架构能够实现更高的性能和实时性，同时简化了架构的复杂性。让我们详细分析一下 Flink + Doris 取代 Spark + Hive 的优点及适用场景：

1. 实时性与流处理能力

Flink 的优势：Flink 是一个分布式流处理框架，支持事件驱动和批处理模式，特别擅长处理实时数据流和复杂事件处理（CEP）。Flink 能够以低延迟处理海量数据，确保数据能够迅速进入下游系统。
Doris 的实时写入和分析：Doris 支持实时数据加载，能够高效处理来自 Flink 的流式数据，提供秒级查询的响应能力，适合实时数据分析场景。

Spark + Hive 的组合主要用于批处理，Hive 本身不擅长处理实时数据，Spark 的流处理能力也不如 Flink 专注且强大。因此，Flink + Doris 更适合有实时数据需求的场景，尤其是在需要低延迟的业务数据分析和展示时。

2. 查询性能和并发处理

Doris 的高效查询：Doris 作为一个专为分析设计的 MPP 数据库，擅长处理大规模数据查询，支持高并发的 SQL 查询并提供低延迟响应，适合在线分析型应用（OLAP）。
列式存储和向量化执行：Doris 使用列式存储和向量化执行引擎，在处理复杂查询时效率更高，能够大幅缩短查询时间。相比之下，Hive 在执行复杂查询时较慢，尤其是基于 HDFS 的查询，依赖磁盘 I/O，性能较差。

Spark + Hive 组合通常需要大量的计算资源来执行批量查询任务，且在查询复杂度上性能不如 Doris。

3. 简化架构与运维成本

Flink 和 Doris 的简洁架构：Flink 与 Doris 都具备较高的集成度和易用性，且不依赖于像 Hadoop 这样的复杂生态系统。Flink + Doris 的组合能够简化系统架构，减少数据流动中的延迟，且维护成本相对较低。
轻量级部署：Doris 作为轻量级 OLAP 数据库，部署和运维都较为简单，不需要 Hadoop 的支持。相比之下，Hive 依赖于 Hadoop 生态系统，需要更多的组件（如 HDFS、YARN 等）来保证其工作，这增加了架构的复杂度和运维难度。

Spark + Hive 架构复杂，需要更多的组件支持，部署和维护较为繁琐，Flink + Doris 在这一方面更具优势。

4. 批处理和流处理的统一

Flink 批流一体化：Flink 提供了统一的编程模型，能够同时处理批处理和流处理任务，使得离线数仓架构能够更灵活地应对各种数据处理需求。
批处理能力：尽管 Flink 主要以流处理见长，但它在批处理方面的表现也相当出色。通过批流一体化架构，开发人员可以更高效地处理历史数据和实时数据，极大简化了数据处理的开发和运维。

Spark + Hive 则主要关注批处理任务，对于流数据的处理能力相对弱一些。Spark 的流处理框架（Spark Streaming）比 Flink 在复杂流处理上的能力有限。

5. 灵活的数据集成

数据集成与传输：Flink 可以轻松集成各种数据源，包括 Kafka、文件系统、数据库等。它可以将流式和批量数据统一处理后，通过 Doris 实现实时分析和查询。
Doris 的多种导入方式：Doris 支持多种数据导入方式，能够高效地处理 Flink 输出的数据流（例如通过 HTTP、Broker、Stream Load 等方式），这使得两者之间的集成非常顺畅。

Spark + Hive 在数据集成的实时性上不如 Flink + Doris。Spark 处理数据后通常还需要依赖 Hive 进行存储和管理，数据查询和更新的延迟较高。

6. 高可扩展性

分布式处理：Flink 作为流处理框架具备出色的可扩展性，能够处理大规模的数据流。Doris 也是一个分布式架构，能够扩展到数百个节点，适应大规模数仓需求。
集群管理：Flink 和 Doris 都支持分布式集群管理，能够根据业务需求动态扩展计算和存储能力。

Spark + Hive 也具有可扩展性，但其扩展性受 Hadoop 生态的限制，复杂性更高。

适用场景

Flink + Doris 适用于需要实时数据处理、高性能查询以及复杂多维分析的场景，如：

实时数据流分析（用户行为分析、监控告警系统）
实时数据仓库（T+0 数据仓库）
多维度的在线查询（报表系统、BI 工具）
需要兼顾批处理和流处理的场景

Spark + Hive 更适用于需要处理大规模离线批量数据且对实时性要求不高的传统数仓场景。

作者 east

doris, Hbase 4月 13,2024

用Flink开发实时数仓,用hase还是doris存储维度表选型对比

在使用Flink开发实时数仓时，选择合适的存储方案对于保证数据的实时性、一致性和可用性至关重要。在这里，我们将对比Doris和HBase，以帮助您做出决策。

Doris

Doris是一个基于MPP（Massively Parallel Processing）架构的分布式列式存储数据库，具有高性能、高可用性和高扩展性。Doris适用于大规模数据分析和实时查询场景，特别是对实时性要求较高的场景。

优点：

高性能：Doris具有高性能的列式存储和向量化查询引擎，能够快速处理大量数据。
易用性：Doris提供了简单易用的SQL接口，支持标准SQL语法，方便用户进行数据查询和分析。
可扩展性：Doris支持水平扩展，可以根据业务需求动态调整集群规模。

缺点：

对实时性要求较高的场景，Doris的实时性可能不如HBase。
数据更新和删除操作相对较慢，不适合频繁更新的场景。

HBase

HBase是一个基于Hadoop的分布式、可扩展、大规模列式存储的NoSQL数据库。HBase适用于需要实时读写的场景，特别是对实时性要求较高的场景。

优点：

高实时性：HBase具有低延迟的读写性能，适用于实时数据处理和分析场景。
可扩展性：HBase支持水平扩展，可以根据业务需求动态调整集群规模。
数据一致性：HBase提供了强一致性保证，适用于对数据一致性要求较高的场景。

缺点：

查询性能相对较低，不适合大规模数据分析场景。
数据更新和删除操作相对较慢，不适合频繁更新的场景。

总结：

在选择存储方案时，需要根据实际业务场景和需求来权衡。如果实时性要求较高，可以选择HBase；如果需要大规模数据分析和查询，可以选择Doris。在实际应用中，也可以将两者结合使用，以满足不同场景的需求。

作者 east

doris 10月 24,2023

1、该命令用于安全删除 BE 节点。命令下发后，Doris 会尝试将该 BE 上的数据向其他 BE 节点迁移，当所有数据都迁移完成后，Doris 会自动删除该节点。
2、该命令是一个异步操作。执行后，可以通过 SHOW PROC ‘/backends’; 看到该 BE 节点的 SystemDecommissioned 状态为 true。表示该节点正在进行下线。
3、该命令不一定执行成功。比如剩余 BE 存储空间不足以容纳下线 BE 上的数据，或者剩余机器数量不满足最小副本数时，该命令都无法完成，并且 BE 会一直处于 SystemDecommissioned 为 true 的状态。
4、DECOMMISSION 的进度，可以通过 SHOW PROC ‘/backends’; 中的 TabletNum 查看，如果正在进行，TabletNum 将不断减少。
该操作可以通过:
5、CANCEL DECOMMISSION BACKEND “be_host:be_heartbeat_service_port”;
命令取消。取消后，该 BE 上的数据将维持当前剩余的数据量。后续 Doris 重新进行负载均衡。

没想到用了十几个小时， TabletNum 还没有变0，生产系统又需要使用了。

可以看重要表数据副本是否迁移完成。

ADMIN SHOW REPLICA DISTRIBUTION FROM  数据库名.表名

如果大部分表已经迁移完成，doris数据库是多副本，只有1个副本没迁移完成，这时可以考虑强制下线be端。手动修复数据。

#强制缩容
ALTER SYSTEM DROPP BACKEND "be_host:be_heartbeat_service_port";

手动修复表

ADMIN REPAIR TABLE  数据库名.表名

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典，回复“大数据”获取多本大数据电子书

作者 east

doris 10月 17,2023

doris手动添加分区自动消失的问题

在数据仓库开发指标时，需要回溯历史数据，对下面的表改为非动态表并添加更早时间的分区：

-- 改为非动态分区
ALTER TABLE test SET ("dynamic_partition.enable" = "false")
-- 手动添加更早的时间分区
ALTER TABLE test
ADD PARTITION p20230912 VALUES [("2023-09-12"), ("2023-09-13"));
  --改为动态分区
ALTER TABLE test SET ("dynamic_partition.enable" = "true")

CREATE TABLE `test` (
  `id` bigint(20) NOT NULL COMMENT '主键',  
  `dt` date NULL COMMENT '创建时间'
) ENGINE=OLAP
DUPLICATE KEY(`id`)
COMMENT 'olap'
PARTITION BY RANGE(`dt`)
PARTITION p20231010 VALUES [('2023-10-10'), ('2023-10-11')),
PARTITION p20231011 VALUES [('2023-10-11'), ('2023-10-12')),
PARTITION p20231012 VALUES [('2023-10-12'), ('2023-10-13')),
PARTITION p20231013 VALUES [('2023-10-13'), ('2023-10-14')),
PARTITION p20231014 VALUES [('2023-10-14'), ('2023-10-15')),
PARTITION p20231015 VALUES [('2023-10-15'), ('2023-10-16')),
PARTITION p20231016 VALUES [('2023-10-16'), ('2023-10-17')),
PARTITION p20231017 VALUES [('2023-10-17'), ('2023-10-18')),
PARTITION p20231018 VALUES [('2023-10-18'), ('2023-10-19')),
PARTITION p20231019 VALUES [('2023-10-19'), ('2023-10-20')),
PARTITION p20231020 VALUES [('2023-10-20'), ('2023-10-21')))
DISTRIBUTED BY HASH(`id`) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.time_zone" = "Asia/Shanghai",
"dynamic_partition.start" = "-7",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.replication_allocation" = "tag.location.default: 1",
"dynamic_partition.buckets" = "10",
"dynamic_partition.create_history_partition" = "false",
"dynamic_partition.history_partition_num" = "-1",
"dynamic_partition.hot_partition_num" = "0",
"dynamic_partition.reserved_history_periods" = "NULL",
"dynamic_partition.storage_policy" = "",
"in_memory" = "false",
"storage_format" = "V2",
"disable_auto_compaction" = "false"
);

然而奇怪的事情发生了，创建的p20230912 不见了，后来考虑到可能是动态分区搞的鬼，是由于没有正确动态分区的属性。

看到表结构的”dynamic_partition.start” = “-7”,这表示
动态分区的起始范围。表示从今天开始向前7天。而
p20230912 远远超过这个范围，后来把这个值调大后，果然不会凭空消失了。

ALTER TABLE test SET
(    "dynamic_partition.start" = "-75"
);

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典，回复“大数据”获取多本大数据电子书

作者 east

doris 8月 29,2023

druid连接不上doris有哪些可能原因

如果你在使用Druid连接池连接Doris时遇到问题，无法连接上数据库，可能有以下几个原因和解决方案：

网络配置问题：确保你的应用程序能够与Doris数据库所在的服务器进行通信。检查防火墙设置、网络配置以及Doris数据库的监听端口是否正确开放。
Doris JDBC驱动问题：确认你使用的是正确版本的Doris JDBC驱动程序。不同版本的驱动程序可能与特定版本的Doris不兼容。建议检查并使用与你所连接的Doris版本匹配的驱动程序。
连接参数错误：确认你在连接字符串中提供了正确的主机名、端口号、数据库名称以及用户名和密码。确保这些参数与Doris数据库的实际配置相匹配。
Druid连接池配置问题：检查你的Druid连接池配置是否正确。确保连接URL正确设置为Doris数据库的URL，并提供有效的用户名和密码。
数据库服务问题：确保Doris数据库服务正在运行，并且具有足够的资源来处理连接请求。检查Doris数据库的日志文件，查看是否有任何错误或异常信息。
数据库权限问题：验证你使用的用户名和密码是否具有足够的权限来连接Doris数据库。确保用户拥有所需的数据库访问权限。
依赖项问题：检查你的项目依赖项是否正确配置。确保在项目中包含了Druid连接池和Doris JDBC驱动的正确版本。

如果你仔细检查并解决了上述问题，应该能够成功连接到Doris数据库。如果问题仍然存在，建议进一步检查错误日志、调试信息和网络连接状态，以确定具体的故障原因，并考虑寻求更深入的技术支持。

作者 east

分类归档doris