文档反馈
问问助手Q1：TTL 的设置是什么级别的粒度？
ByteHouse 企业版支持表级别、分区级别、行级别三种粒度的 TTL（生存时间）设置：
TTL 类型 | 说明 | 配置方式 |
|---|---|---|
表级别 | 对整个表的所有数据生效，适用于对整张表的数据设置统一过期规则的场景。 | 通过控制台配置，配置详情请参见新建数据库/表。 |
分区级别 | 可以针对表的特定分区进行设置，提供了更精细的数据生命周期管理能力，允许不同分区的数据拥有独立的过期策略。 | 需通过客户端（如 CLI、JDBC 等）连接 ByteHouse 后，手动编写 DDL 语句进行设置。 |
行级别 | 可以基于表中某列的时间值（例如 |
Q2：在使用社区版 ClickHouse 时，出现了 Kafka 数据导入节点后数据分配倾斜问题，ByteHouse 是否可以避免该问题，以及如何设置？
数据分配倾斜问题可能由于社区版 Kafka 引擎动态分配 Partition 导致：当 Kafka 分区与 ClickHouse 节点的映射关系动态变化时，容易导致部分节点处理过多分区数据，引发负载不均。而 ByteHouse 改造后的 HaKafka 引擎是根据 Partition 静态分配的，避免因动态分配导致的倾斜。
如果您需要将 Kafka 数据导入 ByteHouse，推荐您使用 ByteHouse 企业版控制台的流式导入功能，系统会默认启用 Partition 静态分配机制，无需额外配置即可有效规避节点数据分配倾斜。
注意
HaKafka 引擎的静态分配基于 Kafka 源端的分区数据分布。若上游 Kafka 本身存在 Partition 数据倾斜（如部分分区数据量远大于其他分区），则导入后仍可能出现节点负载不均。因此，建议在使用流式导入前，先确认上游 Kafka 的各 Partition 数据分布均衡。
Q3：通过 JDBC 进行 insert select 方式写入时，如果出现写入失败情况，是否会存在数据丢失？
是的，存在部分数据成功写入，导致数据丢失的风险。这是因为 ByteHouse 的 INSERT INTO ... SELECT ... 操作不保证与原子性。
如果出现写入失败，建议通过以下方式重试，以保证数据一致性：
- （推荐）方式一：使用 HaUniqueMergeTree 引擎创建目标表
建议使用 HaUniqueMergeTree 表。该引擎支持基于唯一键的自动去重机制，即使因重试导致重复写入，也能保证最终数据的准确性和一致性。因此，当使用 HaUniqueMergeTree 表出现写入失败时，直接重试即可，无需额外处理重复数据。
HaUniqueMergeTree 表创建方式请参见HaUniqueMergeTree。 - 方式二：清空目标表再重试
若目标表不适合使用 HaUniqueMergeTree，可清空目标表再重试。操作示例如下：在重试写入操作之前，先执行 TRUNCATE TABLE target_table 命令，清空目标表中的数据（包括失败时已写入的部分）。
TRUNCATE TABLE example_table;注意
此操作会清空目标表中已有的所有数据（包括可能已成功写入的部分数据），因此仅建议在确认数据可完全重新生成，且对中间状态无依赖的场景下使用。需谨慎评估其对业务的影响。
重新执行完整的 INSERT INTO ... SELECT ... 语句。
INSERT INTO example_table SELECT * FROM example_table