数据工程面试：如何把遗留日志迁移到 OpenTelemetry Logs Data Model？

题干与适用场景

公司同时产生应用文本日志、容器标准输出和旧 JSON 事件，字段名称、时间精度和严重性写法各不相同。团队希望迁移到 OpenTelemetry Logs Data Model，保留历史可检索性，并让 TraceId 关联不误导排障。请设计离线回填与实时双写方案。

OpenTelemetry 将 Timestamp、ObservedTimestamp、TraceId、SpanId、SeverityNumber、Body、Resource 和 Attributes 分开定义。迁移的核心是可追溯的数据契约，而非简单把整行字符串塞进 Body。高质量回答还要处理解析失败、时区、重复、敏感字段和回放水位。

面试官考察点

• 能否区分事件发生时间、采集时间、资源属性和事件属性。
• 是否设计 schema 映射、版本、未知字段保留和解析失败路径。
• 是否保持 TraceId、SpanId 和请求标识的真实性与可选性。
• 是否处理租户隔离、脱敏、重复、乱序和历史回填成本。
• 是否给出可重放、可对账和质量门槛，而不是只描述 ETL 工具。

回答前需要澄清的问题

1. 旧日志的时间是本地时间、UTC 还是混合格式？精度能到毫秒还是纳秒？
2. 哪些来源有稳定 schema，哪些来源需要正则或样本驱动解析？
3. TraceId、SpanId、请求 ID 是由应用生成还是由采集器猜测？
4. 是否需要保留原始载荷，保留多久，谁可以读取？
5. 历史回填与实时双写是否共用目标存储和索引，允许多大查询差异？

30 秒回答框架

我会先建立版本化映射表，并保留原始载荷和解析状态。Timestamp 表示事件发生，ObservedTimestamp 表示被观察到的时间；Resource 放服务、主机和租户等稳定来源，Attributes 放事件实例字段，Body 保留结构化业务内容。TraceId 和 SpanId 只在有可信上下文时填入。迁移采用离线回填加实时双写，按来源和时间分区对账，失败记录进入可重放死信。质量门槛包括解析成功率、字段完整性、时间偏差、重复率、脱敏命中率和查询等价性。

分步骤深入解答

1. 先固定数据契约

为每种来源定义 parser 版本、必填字段、默认值和未知字段策略。原始行生成稳定事件 ID，记录来源、文件偏移或消息位点。未知字段可暂存于 Attributes 或原始载荷，但不能悄悄丢弃；字段含义变化必须升级映射版本。

{
  "timestamp": "2026-08-02T02:00:00.123Z",
  "observedTimestamp": "2026-08-02T02:00:00.800Z",
  "severityNumber": 17,
  "severityText": "ERROR",
  "body": {"message": "payment declined", "code": "CARD_DECLINED"},
  "resource": {"service.name": "checkout", "tenant.id": "t-7"},
  "attributes": {"region": "us-east-1"}
}

2. 处理时间语义

解析带时区的时间为统一时区，并保留原始字符串和解析状态。Timestamp 是事件发生时间；ObservedTimestamp 是采集器观察到它的时间。缺少事件时间时可以使用观察时间作为降级值，但必须打标，避免把采集延迟误当业务延迟。对未来时间、过旧时间和精度截断设定校验规则。

3. 映射 Resource、Attributes 与 Body

Resource 描述产生日志的实体，例如服务名、版本、主机、集群和租户；Attributes 描述单条事件的区域、请求类型或实验分组；Body 保存结构化消息或未拆解内容。字段放错位置会影响聚合、索引和成本，因此映射表要记录理由与下游使用者。

4. 处理严重性与上下文

把旧系统的 WARN、ERR、数字等级映射到 SeverityNumber，并保留原始 SeverityText。TraceId、SpanId 和 TraceFlags 只接受符合格式且来自可信注入点的值；缺失时保留空值和缺失原因，不能随机生成链路 ID。请求 ID 可以作为普通 Attribute，但不要把它冒充 TraceId。

5. 设计双写与回填

实时路径在采集器中同时写旧存储和新目标，使用同一事件 ID；离线回填按文件、分区或消息位点切片，记录 checkpoint。两条路径共用 parser 和脱敏规则，但允许不同批大小。回填完成后按来源、时间窗口和事件 ID 对账，再逐步把查询流量切到新模型。

6. 失败、重复与乱序

解析失败写入包含原始数据、错误码和 parser 版本的死信，可在修复后按 checkpoint 重放。重复由事件 ID、来源位点和内容哈希组合去重；乱序不应修改事件时间，查询索引按事件时间与观察时间分别支持。无法去重时宁可标记不确定，也不要静默覆盖。

7. 隔离、脱敏与成本

租户 ID 应来自受信资源属性，不能接受客户端任意覆盖。密钥、令牌和个人数据在落盘前按字段规则脱敏，同时保留脱敏版本与命中计数。原始载荷单独加密、限权和设定较短保留期；高基数 Attributes 需要索引预算，避免统一模型带来成本爆炸。

8. 质量验收与回滚

抽样对比旧查询与新查询的事件数、严重性分布、时间差和关键字段。设置解析成功率、必填字段完整率、重复率、时间偏差、脱敏漏报和查询等价性门槛。灰度期间保留旧写入，发现字段错位或租户泄露时按 checkpoint 停止新写入并回滚查询路由，不删除可回放原始数据。

高质量示范回答

我会把迁移拆成契约、解析、双写、回填、对账和切流六层。每个来源有版本化 parser 和稳定事件 ID；Timestamp 表示事件发生，ObservedTimestamp 表示采集时间。Resource 放服务、主机和租户等稳定属性，Attributes 放事件字段，Body 保留结构化业务内容；SeverityNumber 从旧等级映射，TraceId 只接受可信上下文。

实时阶段旧、新存储双写，离线阶段按位点回填，失败进入带原始数据和错误码的死信。用事件 ID 与位点对账，分别监控乱序和重复。落盘前脱敏，原始载荷单独加密限权。灰度比较事件数、字段完整性、时间偏差和查询结果；门槛不达标就停写新模型并切回旧查询。

常见错误

• 把所有内容放进 Body → 下游无法按资源和属性聚合 → 按数据模型分层映射并保留未知字段。
• 用采集时间覆盖事件时间 → 无法分析业务延迟 → 同时保留 Timestamp 与 ObservedTimestamp。
• 为缺失上下文随机生成 TraceId → 产生虚假链路 → 保留空值并记录缺失原因。
• 只做实时双写不做回填对账 → 历史和实时结果无法证明一致 → 用位点、事件 ID 和时间窗口对账。
• 解析失败直接丢弃 → 无法修复 parser 后补偿 → 写入可重放死信。
• 先落盘再脱敏 → 原始数据扩大泄露面 → 在受控入口执行字段级脱敏并隔离原文。

追问及应对

没有事件时间怎么办？

使用 ObservedTimestamp 作为明确降级值，同时设置缺失标记；不要把它伪装成业务发生时间，并在质量报表中单独统计。

如何验证 TraceId 没有被伪造？

只信任应用 SDK 或受控代理注入的上下文，校验格式与关联范围；客户端日志中的同名字段只能作为普通 Attribute。

双写产生重复如何处理？

生成稳定事件 ID，结合来源位点和内容哈希做幂等写入；如果无法确定是否同一事件，保留重复标记并让查询层解释。

迁移期间字段含义变化怎么办？

升级 parser 和 schema 版本，保留旧字段映射与版本信息，允许新旧字段并存一段时间，并对下游查询做兼容测试。

原始载荷为什么不能全部删除？

它支持解析修复、争议核验和重放，但应单独加密、限权、审计访问并缩短保留期，不能与标准化索引混存。