多云 VM 活动日志平台

问题

虚拟机分布在三朵云上，每朵云都按自己的格式写活动日志，而且字段随时会变。以前每出现一个新字段，就要有人手动改 Schema；一旦忘了，管道就会出错。

我做了什么

在 Databricks 上搭建了一套可复用的摄取框架：从 Azure Blob Storage 和 AWS S3 读取原始日志（GCP 沿用同一框架），写入 Medallion 架构。核心是一个四层 Schema 注册表：

1. 发现——一次 spark.read.json 推断出最宽的 Schema，类型冲突统一回退为字符串。
2. 比对——与上一次的快照对比，把每个变化分成三级：新增标量字段静默合并；新增嵌套结构合并并告警；类型冲突直接阻断，等待人工审核。
3. 展平——嵌套字段展开成安全命名的平铺列，原始行始终保存在 raw_json 中。
4. 校验——一次聚合算出所有列的空值率，发现异常就停止写入。

← 左右滑动查看完整架构图 →

关键设计决策

1. 1结构稳定时跳过发现：直接用注册表里的快照展平。
2. 2宁可拦截，不猜：类型冲突或空值率异常就停下，交给人工。
3. 3保留原始行：raw_json 让展平逻辑可以随时重放。
4. 4一次完成校验：全部空值率在一次 agg() 里算完，耗时不到 5%。

Azure 和 AWS 日志（GCP 规划中）依次经过发现、比对、漂移判断、展平和校验。新字段合并后写回 Schema 注册表；类型冲突或空值率异常会停止写入、交给人工审核；结构没有变化时跳过发现，直接使用注册表快照。校验通过的数据写入 Bronze，再进入 Silver、Gold 和 Power BI。

结果

• 40 多个 Azure 和 AWS 日志源，通过同一套框架落成 60 张 Bronze Delta 表。
• 不再需要手动维护 Schema：安全的变化自动合并，有风险的变化在进表之前就被拦下。
• 得益于单次聚合和“无变化时跳过发现”，Schema 校验只占不到 5% 的管道运行时间。

关键决策

• 保留原始行。 每一行 Bronze 数据都带着原始 JSON，展平逻辑出错时可以直接重放，不必重新摄取。
• 宁可拦截，也不猜测。 类型冲突本质上是一个审计问题，而不是工程问题：管道停下来，交给人判断。
• 一次完成校验。 所有空值率检查放在一次 agg() 里完成，而不是每列跑一次查询。