跳转到主要内容

常见错误

授权测试失败,或与权限相关的操作失败

错误消息:
**原因:**Fivetran 用户没有所需的权限。该连接器需要在 *.* (所有数据库和表) 上拥有 ALTERCREATE DATABASECREATE TABLEINSERTSELECT 授权。
授权检查会查询 system.grants,且只匹配直接授予用户的授权。通过 ClickHouse 角色分配的权限无法被检测到。更多详情,请参阅基于角色的授权部分。
解决方案: 直接向 Fivetran 用户授予所需权限:

等待所有变更完成时出错

错误消息:
**原因:**已提交 ALTER TABLE ... UPDATEALTER TABLE ... DELETE 变更,但连接器在等待该变更在所有副本上完成时超时。错误中的“initial cause”部分通常会包含原始的 ClickHouse 错误 (常见为代码 341,即“Unfinished”) 。 这通常发生在以下情况下:
  • ClickHouse Cloud 集群负载过重。
  • 在变更执行期间,一个或多个节点发生故障。
解决方案:
  1. 检查变更进度:运行以下查询,检查是否存在待处理的 mutation:
  2. 检查集群健康状态:确保所有节点都处于健康状态。
  3. 等待并重试:集群恢复健康后,变更最终会完成。Fivetran 会自动重试同步。

列不匹配错误

错误信息: 如果列不匹配是由 source 中的 schema 变更引起的,可能会出现不同的错误。例如:
或者:
原因: ClickHouse 目标端表中的列与正在同步的数据中的列不一致。出现这种情况的原因可能是:
  • 手动在 ClickHouse 表中添加或删除了列。
  • 来源端的 schema 变更未正确同步过来。
解决方案:
  1. 切勿手动修改由 Fivetran 管理的表。 请参见最佳实践
  2. 将列改回原来的类型:如果你知道该列应是什么类型,请参考type transformation mapping,将该列改回预期类型。
  3. 重新同步该表:在 Fivetran 仪表板中,为受影响的表触发一次历史重新同步。
  4. 删除并重新创建:作为最后的手段,删除目标端表,并让 Fivetran 在下一次同步时重新创建它。

AST 过大 (代码 168)

错误信息:
原因: 大批量的 UPDATE 或 DELETE 批次会生成抽象语法树非常复杂的 SQL 语句。这在宽表或启用历史模式时很常见。 解决方案: 高级配置文件中调低 mutation_batch_sizehard_delete_batch_size。两者的默认值均为 1500,可接受的取值范围为 2001500

内存超限 / OOM (代码 241)

错误信息:
原因: INSERT 操作所需内存超过可用内存。通常发生在大规模初始同步、宽表场景或并发批次操作期间。 解决方案:
  1. 减小 write_batch_size:对于大表,尝试将其调低到 50,000。
  2. 降低数据库负载:检查 ClickHouse Cloud 服务的负载情况,确认是否过载。
  3. 扩容 ClickHouse Cloud 服务 以提供更多内存。

意外 EOF / 连接错误

错误消息:
或者在 Fivetran 日志中出现 FAILURE_WITH_TASK,且没有堆栈跟踪信息。 原因:
  • IP 访问列表未配置为允许 Fivetran 流量。
  • Fivetran 与 ClickHouse Cloud 之间存在暂时性的网络问题。
  • 损坏或无效的源数据导致目标端连接器崩溃。
解决方案:
  1. 检查 IP 访问列表:在 ClickHouse Cloud 中,前往 Settings > Security,添加 Fivetran IP addresses,或允许来自任意位置的访问。
  2. 重试:较新的连接器版本会自动重试 EOF 错误。零星出现的错误 (每天 1–2 次) 很可能只是暂时性问题。
  3. 如果问题仍然存在:向 ClickHouse 提交支持工单,并提供错误发生的时间范围。同时请 Fivetran 支持团队协助调查源数据质量问题。

无法映射 UInt64 类型

错误信息:
原因: 该 连接器 会将 LONG 映射为 Int64,不会映射为 UInt64。当在由 Fivetran 管理的表中手动修改列类型时,就会出现此错误。 解决方案:
  1. 不要在 Fivetran 管理的表中手动修改列类型
  2. 如需恢复:将该列改回预期的类型 (例如 Int64) ,或者删除该表并重新同步。
  3. 对于自定义类型:可在由 Fivetran 管理的表上创建 materialized view

表没有主键

错误信息:
原因: 每个 ClickHouse 表都必须指定 ORDER BY。当源端没有主键时,Fivetran 会自动添加 _fivetran_id。如果源端定义了 PK,但数据中并不包含该 PK,就可能在某些边缘情况下触发此错误。 解决方案:
  1. 联系 Fivetran 支持团队,排查源管道。
  2. 检查源 schema:确保数据中包含主键列。

基于角色的授权失败

错误信息:
原因: 该连接器使用以下语句检查授权:
这只会返回直接授权。通过 ClickHouse 角色分配的权限会显示为 user_name = NULLrole_name = 'my_role',因此此检查无法识别这些权限。 解决方案: 直接向 Fivetran 用户授予权限

最佳实践

Fivetran 专用 ClickHouse 服务

在摄取负载较高时,建议使用 ClickHouse Cloud 的计算-计算分离,为 Fivetran 写入工作负载创建专用服务。这样可将摄取与分析查询隔离开来,避免资源争用。 例如,可采用以下架构:
  • 服务 A (写入端) :Fivetran 目标端 + 其他摄取工具 (ClickPipes、Kafka 连接器)
  • 服务 B (读取端) :BI 工具、仪表盘、临时查询

优化读取查询

ClickHouse 对 Fivetran 目标端表使用 SharedReplacingMergeTree,它是 ClickHouse Cloud 中 ReplacingMergeTree 表引擎 的一个版本。具有相同主键的重复行属于正常现象——去重会在后台合并过程中异步进行。读取时,你需要注意避免返回重复行,因为有些行可能尚未完成去重。 使用 FINAL 关键字是避免重复行的最简单方法,因为它会在读取时强制合并所有尚未去重的行:
有一些方法可以优化这个 FINAL 操作——例如,通过 WHERE 条件对键列进行过滤。更多详情,请参阅 ReplacingMergeTree 指南中的 FINAL performance 部分。 如果这些优化还不够,你还有其他方法可以在不使用 FINAL 的情况下正确处理重复项:

主键与 ORDER BY 优化

Fivetran 会将源表的主键复制为 ClickHouse 的 ORDER BY 子句。当源表没有主键时,_fivetran_id (一个 UUID) 会成为排序键。由于 ClickHouse 会基于 ORDER BY 列构建其稀疏主索引,这可能会导致查询性能较差。 如果其他优化手段仍无法满足需求,建议采取以下做法:
  1. 将 Fivetran 表视为原始暂存表。 不要直接对其进行分析查询。
  2. 如果查询性能仍然不够理想,可使用可刷新materialized view创建该表的副本,并根据你的查询模式优化其 ORDER BY。与增量materialized view不同,可刷新materialized view会按计划重新运行完整查询,因此能够正确处理 Fivetran 在同步期间发出的 UPDATEDELETE 操作:
对于由 Fivetran 管理的表,应避免使用增量 (不可刷新) materialized view。由于 Fivetran 会发出 UPDATEDELETE 操作来保持数据同步,增量materialized view无法反映这些变更,因此会包含过时或错误的数据。

不要手动修改由 Fivetran 管理的表

避免对由 Fivetran 管理的表手动执行 DDL 更改 (例如 ALTER TABLE ... MODIFY COLUMN) 。连接器 依赖其创建的 schema。手动更改可能会导致type mapping 错误以及 schema 不匹配问题。 使用 materialized views 进行自定义转换。

调试操作

排查故障时:
  • 检查 ClickHouse system.query_log,查看服务端是否存在问题。
  • 如属客户端问题,请向 Fivetran 寻求帮助。
如果是 连接器 的缺陷,请创建 GitHub issue或联系 ClickHouse 支持团队

调试 Fivetran 同步

使用以下查询来诊断 ClickHouse 侧的同步失败问题。

查看近期与 Fivetran 相关的 ClickHouse 错误

查看最近的 Fivetran 用户活动

最后修改于 2026年6月12日