可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载本篇技术指南以 highlight.io 仓库内部 RFC 002-feed-clickhouse-migration.md 为主体结合配套 PRD 与后端 ClickHouse 源码深入讲解如何将 Session Feed 与 Error Feed 从 OpenSearch 迁移到 ClickHouse并彻底停用 OpenSearch、逐步剥离 InfluxDB 依赖。读完本文你将掌握这次迁移的四个实施阶段、三种候选数据库建模方案、跨数据库数据迁移路径以及当前仓库中已落地的 ClickHouse 表结构与查询实现可直接用于规划同类可观测性数据的存储引擎迁移。一、迁移背景OpenSearch 为什么需要被替换在 highlight.io 的产品架构中Session Feed会话列表与 Error Feed错误列表长期由 OpenSearch 驱动其 query-builder 过滤能力是快速定位会话与错误的关键。然而随着数据规模增长这套方案暴露了两个核心问题依据 PRD: Session/Error Feeds ClickHouse Migration 的 User Feedback 章节查询性能差OpenSearch 查询存在明显的冷启动问题最坏情况下一次查询启动耗时超过 5 秒存储成本高将全部 Session / Error 元数据写入 OpenSearch存储与查询成本持续增长。同时RFC 还附带了一个长期目标Error Group 的指标将不再使用 InfluxDB 存储并以逐步移除 InfluxDB 依赖为最终方向。因此这次迁移本质上是把会话/错误的过滤与聚合分析统一收敛到 ClickHouse形成日志、指标、会话、错误在同一存储引擎上的标准化能力——这一点在 RFC 中明确提到Logs are already stored in ClickHouse and are associated with sessions. We should consider how to standardize the metadata stored in ClickHouse across the three products.二、迁移总体蓝图四个实施阶段RFC 将整次迁移拆分为四个阶段Proposed Implementation每个阶段独立交付、可验证替换 Error Group feed 查询将错误组的列表查询从 OpenSearch 切换到 ClickHouse替换 Error Group metrics错误组的聚合指标迁移到 ClickHouse这一步同时替代 InfluxDB 的职责替换 Session feed 查询将会话列表查询切换到 ClickHouse实现 CommandBar 改进基于 ClickHouse 增强命令栏的搜索体验。RFC 特别强调了一个数据模型层面的设计要点error groups 与 error instances 的元数据都会存储在 ClickHouse 中其中 error instance 的元数据将用于填充 error group 的聚合统计——例如浏览器分布指标、受影响用户数等。这意味着迁移不是简单的搬表而是要对实例级明细数据做聚合建模为阶段 2 的指标替换奠定基础。目标功能清单来自 PRD配套 PRD 给出了迁移完成后需要保持并增强的功能清单是各阶段验收的功能基线Error feed展示所有可搜索的属性attributes选中某个搜索属性后展示该属性的所有可能取值支持属性的精确匹配与 like 模糊匹配以及属性之间的 and/or 组合逻辑对当前查询展示错误随时间分布的直方图对每个 error group 展示组内 instance 的分布情况新增展示组内 error instance 列表并支持按属性过滤 instance预设属性集中选中一个属性后展示其所有可选值。Session feed展示所有可搜索属性及其取值支持精确/模糊匹配与 and/or 逻辑展示当前查询的会话时间直方图并支持按属性分组默认分组为 has/no-has errors新增对每个会话展示事件随时间分布的预览按 errors、track events 等事件类型分组。Command bar基于 email、identifier、url、os、browser 等预定义属性搜索 sessions、errors、logs新增根据输入内容预测更合适的查询类型session vs error vs log。三、数据库建模三种候选 Schema 方案RFC 指出迁移的起点是参考当前 Postgres 中 sessions/errors 的 schema 结构但必须对不同查询建模方案做性能基准测试。RFC 给出了三种候选方案方案一保持 Postgres 式三表结构查询时在 ClickHouse 中做 join。最贴近现有模型迁移成本最低但 join 在高基数、大时间窗场景下的表现需要验证方案二反范式化字段将字段值随每条 session/error 冗余存储——这正是此前 OpenSearch 的做法denormalize fields and save a copy of their values with each session/error方案三把可查询的列也建模成字段采用(field_type, field_name, field_value, id)格式的字段表先在 ClickHouse 中查出匹配的 id 集合再回 Postgres 查询完整的 session/error 对象。RFC 对方案三给出了明确的倾向性判断它的好处在于Postgres 可以继续作为 error group 数据的 source of truth数据权威源但同时值得评估ClickHouse 是否可以作为只写一次write-once元数据的长期权威源——即利用 ClickHouse 对追加写入场景的高吞吐优势让权威数据与查询数据分库承载。当前仓库的建模落地方案二与方案三的融合从当前仓库的 ClickHouse 实现看实际落地采取了主表反范式化 独立字段表 物化视图的组合正是对 RFC 方案二与方案三的折中验证会话主表反范式化方案二迁移文件 000012_create_sessions_table.up.sql 创建的sessions表将浏览器、操作系统、城市、国家、长度、活跃时长等高频查询字段直接内联为普通列同时通过FieldKeys Array(String)与FieldKeyValues Array(String)两个数组列冗余保存全部用户自定义字段天然支持按字段名/字段值过滤的查询独立字段表方案三雏形WriteSessions在写主表的同时会把每个 session 的字段拆成(ProjectID, Type, Name, Value, SessionID, SessionCreatedAt, Timestamp)行写入fields表见 sessions.goQueryFieldNames、SessionsKeyValues均直接基于fields表做DISTINCT与分组统计sessions.go物化视图查询层使用sessions_joined_vw视图常量SessionsJoinedTable sessions_joined_vwsessions.go将主表与字段聚合结果 join 成带RelevantFields的宽行供统一查询入口使用。这种主表冗余高频列 字段表兜底 视图封装的结构使 Session 查询无需在每次请求时都 join 全量字段表同时保留了任意字段过滤的能力。四、数据迁移路径PostgreSQL 到 ClickHouse 的跨库迁移RFC 认为数据迁移本身should be straightforward应可直截了当地完成其技术路线是clickhouse 官方的跨数据库 INSERT 工作流cross-db insert先在 ClickHouse 中建好目标表然后通过 ClickHouse 的表函数直接读取 Postgres 数据完成搬运。RFC 给出的起步步骤是先复制当前 PostgreSQL 的 schema确定替换 OpenSearch 查询的 ClickHouse SQL 形态创建 error groups 表的 ClickHouse 副本将字段反范式化为map 列类型对更新后的查询做基准测试再创建第二份副本验证方案三字段表 回查 Postgres的性能是否更优。该方案在当前仓库的 ClickHouse 客户端中已有直接佐证GetPostgresConnectionString()生成了postgresql(host:port, database, table, user, password)形式的连接字符串clickhouse.go这正是 ClickHouse 内置postgresql表函数用于跨库读写的形态同时RunMigrations通过 golang-migrate 的 clickhouse 驱动从仓库内clickhouse/migrations目录自动执行 SQL 迁移clickhouse.go其中 293 个迁移文件backend/clickhouse/migrations的演进历史本身就记录了复制 Postgres schema → 迭代调整的过程。五、当前仓库中的 ClickHouse 落地实现尽管 RFC 状态仍为 In Progress但从仓库源码看其核心设想已大量落地为可运行代码。以下按 RFC 的四个阶段逐一对照阶段 1/3会话与错误的查询实现backend/clickhouse/sessions.go 是 Session feed 查询的核心包含了 RFC 方案二所需的全部要素字段映射fieldMap把查询键如os_name、browser_name、has_errors、created_at映射到表列sessions.go并定义了ReservedSessionKey到列的完整映射SessionsJoinedTableConfig.KeysToColumnssessions.go查询构建GetSessionsQueryImpl从sessions_joined_vw FINAL读取自动注入ProjectID、NOT Excluded、WithinBillingQuota、保留期与时间范围过滤并通过 ANTLR 解析器parser.GetSearchFilters将自然语言查询翻译为 ClickHouse SQLsessions.go分页与统计QuerySessionIds使用窗口函数一次返回 id、总数与总时长count() OVER() AS total, sum(Length) OVER() ...sessions.go直方图QuerySessionHistogram按时间桶聚合会话数、有无错误、活跃/非活跃时长并用WITH FILL ... STEP 1补齐空桶sessions.go字段建议SessionsKeys返回可搜索键列表含defaultSessionsKeys兜底SessionsKeyValues返回某键的热门取值按count() DESC排序sessions.go——这正是 PRD 中展示所有可能取值功能的后端实现。阶段 2错误组指标替代 InfluxDBError Group 的聚合指标同样落到 ClickHouse。以error_groups表为例迁移文件 000023_use_error_group_updated_at.up.sql 定义了(ProjectID, CreatedAt, UpdatedAt, ID, Event, Status, Type)结构并采用ReplacingMergeTree(UpdatedAt)引擎、以(ProjectID, CreatedAt, ID)为排序键——ReplacingMergeTree配合FINAL读取正是 ClickHouse 对行级更新语义的标准妥协方案。指标与 OTel 生态backend/clickhouse/metrics.go 展示了更完整的 OTel 指标建模按 Sum / Histogram / Summary 三种类型拆分到metrics_sum、metrics_histogram、metrics_summary表并支持 Exemplarssecure_session_id、trace_id、span_id关联会话与链路为 CommandBar 跨产品搜索session / error / log提供了统一元数据基础。写入路径数据写入通过 ClickHouse 原生批处理完成WriteSessions并行向sessions与fields两表PrepareBatchAppendStructSendsessions.goBatchWriteMetricRows则按指标类型路由到三张指标表metrics.go。客户端层面NewClient同时维护读写与只读两套连接池各 10 空闲 / 100 最大连接并周期性上报连接数指标clickhouse.go保证查询与写入的资源隔离。六、成功指标与验收标准RFC 定义了四条可量化的成功指标Success Metrics功能完整性PRD 中列出的全部功能含所有new:前缀的新特性均实现查询性能session、error、command bar 搜索性能优于当前 OpenSearch所有最坏情况查询耗时低于 1 秒对比现状OpenSearch 冷启动单次查询可能超过 5 秒成本目标OpenSearch 集群关停且同一批数据在 ClickHouse 中的存储与查询成本低于 OpenSearch 现状依赖收敛减少 InfluxDB 的使用量并以彻底移除 InfluxDB 依赖为长期目标。七、风险、权衡与开放问题Drawbacks已知代价RFC 坦诚列出了这次迁移的主要风险工程量大迁移本身需要大量工程投入且团队尚不确定哪种 schema 方案最适合自身场景能力短板ClickHouse 查询性能调优对团队仍较新且需要编写此前不熟悉的新型 ClickHouse 聚合查询机会成本在迁移完成前sessions/errors feed 及搜索能力上的其他增强可能被阻塞或需要投入日后需返工的重复工作量。作为回报迁移完成后可以弃用 OpenSearch节省团队排查其性能问题所花费的时间。开放问题高频更新的处理RFC 指出了一个关键的设计矛盾ClickHouse 不支持高容量的行级更新high-volume updates因此不适合作为 session 更新/处理状态updated / processed这类频繁变更数据的权威源。RFC 提出的解决思路是重新架构 session 处理逻辑——把频繁修改的状态放入Redis最终记录final records落盘 ClickHouse。而当前仓库的落地给出了另一条互补路径sessions与error_groups表均采用ReplacingMergeTree引擎以UpdatedAt作为版本列查询时用FINAL修饰符读取最新版本见 sessions.go 的From(sessions FINAL)与 000012_create_sessions_table.up.sql。这套机制使 ClickHouse 能以追加 后台合并去重的方式近似支持更新语义配合 Redis 承载超高频状态可以同时兼顾查询性能与一致性。八、Rollout 与落地节奏RFC 给出的落地顺序是先迁移数据、再定义 schema——具体为使用跨数据库 INSERT 工作流cross-db insert将 sessions 与 error groups 从 PostgreSQL 迁入 ClickHouse为该数据定义一套适配 PRD 功能清单的 ClickHouse schema参照前文的三阶段基准测试Postgres 式三表 → map 反范式化 → 字段表方案逐步确定最终模型。从当前仓库状态看这套节奏已经推进到了schema 已落地、查询已实现、数据持续写入的阶段sessions、fields、error_groups、metrics 系列表与视图齐备查询、直方图、字段建议、批写入与只读连接池均已就绪剩余的核心工作集中在 OpenSearch 查询的完整替换、性能基准达标以及最终关停 OpenSearch 集群。结论highlight.io 的 Session/Error Feed ClickHouse 迁移 RFC 是一个典型的可观测性数据存储收敛案例以 ClickHouse 统一承载日志、会话、错误与指标替代 OpenSearch 与 InfluxDB 两套独立系统。其价值不仅在于单点查询提速目标最坏情况 1 秒与存储成本下降更在于让三种产品的元数据在同一引擎上标准化从而支撑 CommandBar 这类跨产品搜索能力。对于计划迁移自身可观测性数据栈的团队本文梳理的四阶段推进 三方案建模基准测试 跨库 INSERT 迁移 ReplacingMergeTree 折中更新语义可以作为一套可复用的执行框架。赞分享可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载相关推荐从 Graphcool Framework 迁移到 Prisma迁移总览与两层 GraphQL 架构解析从 Graphcool Framework 迁移到 Prisma迁移总览与两层 GraphQL 架构解析 导读 本指南是 Prisma 官方迁移指南Mig后端数据库GraphQL如何从MVC迁移到现代iOS架构完整迁移策略如何从MVC迁移到现代iOS架构完整迁移策略 MVCModel View Controller作为iOS开发的经典架构模式曾为无数应用提供了稳定的基础。教程文档移动开发终极UE4本地化工具5分钟实现游戏多语言支持终极UE4本地化工具5分钟实现游戏多语言支持 你是否在为Unreal Engine 4游戏的多语言支持而烦恼面对复杂的引擎本地化流程想要轻松编辑游戏文本却上一篇PDF-Extract-Kit 表格识别算法指南基于 StructEqTable 的结构解析与 LaTeX/HTML 输出下一篇Laravel Markable 实战教程构建社交应用点赞收藏系统的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
