面向现代分析团队的半结构化数据详解

同事发来一份 CSV 导出文件，但列的顺序和上周的文件对不上。某一行有促销字段，另一行有设备值，第三行则似乎缺少了一些细节。这些记录并非没用，只是固定的表格无法把它们整齐地描述出来。

对于处理 API 响应、应用日志和事件流的团队来说，这是个熟悉的难题。半结构化数据带有有助于解读内容的标签，但并不要求每条记录都具有相同的字段。这种灵活性让整合不同来源的数据变得更容易，但在需要生成一致的报表或预测时，也带来了新的工作量。

简单来说，关系型表格有一组固定的列；半结构化记录携带着能说明自身组织方式的线索；而非结构化文档（例如图像或自由格式文本）则可能完全没有内置的字段结构。了解自己拥有的是哪种数据，有助于决定如何对其进行摄取、校验、存储和保护。实际的挑战不仅仅在于识别一个 JSON 负载，更在于在上游数据发生变化后，依然能保持分析结果的可信度。

一种不肯安分的数据格式

假设你收到两个零售事件。一个记录了商品浏览，另一个记录了购买行为。第一个包含商品 ID 和渠道；第二个还包括价格和促销代码。用 JSON 表示，它们可能是这样的：

{"event": "view", "product_id": "P-42", "channel": "web"}
{"event": "purchase", "product_id": "P-42", "amount": 29.99, "promotion": "spring"}

每条记录都自行命名其字段。相比之下，传统表格先定义列，然后按照这一共同布局存储每条记录。JSON 保留了有用的标签，但允许记录之间有所不同。这种机器可读的结构与可变字段相结合的方式，正是半结构化数据的核心理念。IBM 关于数据结构的概述在结构化与非结构化信息的背景下，描述了这一中间形态。

当行与行之间存在差异，或字段被塞进单元格中时，一份杂乱的 CSV 文件也可以表现得像半结构化数据，尽管 CSV 本身是一种分隔文本格式，而非嵌套文档格式。XML 使用标签，而 JSON 使用键值对以及嵌套的对象或数组。无论哪种情况，标签或其他标记都传达了应如何解读内容的信息。

与非结构化内容的区别很有用。带标签的事件为软件提供了可编目、索引和分析的命名字段。而自由格式的图像或文档，可能需要经过单独处理，系统才能可靠地识别其内容。半结构化数据并不是模糊意义上的“半有组织”。它包含了足以被软件解读的元数据，同时又不强求每条记录都遵循一种僵化的设计。

随着数据库研究人员探索如何查询和整合那些不共享预定义模式的网络信息，这种灵活性变得愈发有用。读时模式（schema-on-read）方法允许系统在摄取或查询过程中解读字段，而无需事先对每个数据源进行重新设计。

JSON 和 XML 如何成为灵活数据的支柱

某个网络服务向分析管道发送一个购买事件。该负载包含带标签的值,接收系统无需依赖字段在表中的位置即可解析这些字段。正是这种基本设计,让 JSON 和 XML 成为网络服务和跨系统交换中为人熟知的基础构件。

万维网联盟于 1998年2月10日将 XML 1.0 发布为正式推荐标准(Recommendation),这是 XML 发展的一个正式里程碑。该标准描述了一种在整个 Web 上定义、验证和共享文档格式的方法。XML 通过层级化的元素和属性来表示信息,因此一份文档既能表达值,也能表达关系。ELECTE 解释了如何读取 XML,为希望了解解析该格式实用入门知识的读者提供指导。

JSON 走了一条更轻量的路径,使用由键值对构成的对象和数组来表示集合。其标准化的互联网规范 RFC 4627 于 2006 年发布。JSON 在网络应用和 API 中变得常见,因为紧凑的负载和简单直接的解析方式契合系统间信息交换的需求。而 XML 则在层级化文档和成熟的企业级交换场景中继续发挥作用。

这两种格式都不要求每条记录包含完全相同的字段。某个 API 响应可能包含客户的偏好语言,而另一个则可能省略它。随着应用程序的演进,一个事件可以新增一个属性,而不必让所有生产方同时做出更改。这种适应性使得这两种格式都适用于 API、应用日志、事件流以及跨系统集成。

这种权衡在分析人员查询数据时便显而易见。他们必须考虑嵌套路径、可选字段、不断变化的标签,以及以不同类型到达的值。JSON 和 XML 并不能消除使数据保持一致的必要性。它们让生产方可以更自由地演进,因此分析团队在下游需要明确的验证和转换做法。

让半结构化数据难以分析的四大挑战

即使每一条传入的记录都是有效的 JSON,零售仪表盘也可能出问题。问题往往在于:记录之间的差异虽然能被简单的解析器接受,却不符合报表的预期。有四个问题尤其值得关注。

• 字段名称发生变化:某个支付事件将某个值称为 amount;另一个则称之为 total。预期使用某一名称的查询可能会漏掉使用另一名称的记录,从而产生不完整的结果。
• 类型发生漂移:某个字段在一个事件中是数字,在另一个事件中却是字符串。聚合运算可能因此失败,或者管道可能在未明确说明原因的情况下,将意外值转换为空值(null)。
• 字段是可选的:一个没有促销或设备属性的事件未必是格式错误。但每一份下游报表都需要刻意处理缺失值,而不能假设每条记录都包含这些字段。
• 数组增加了一层复杂性:一笔购买可能包含一个产品数组。要在产品层面生成报表,团队可能需要展开该数组,或使用其 BI 系统难以轻松处理的查询函数。

这些都不是回避半结构化数据的理由。它们恰恰说明了工程投入的关键所在。如果某份报表缺失了收入数据，分析师需要弄清楚：是数据源停止发送了该字段、重命名了字段、更改了字段类型，还是将其嵌套到了新的位置。如果缺乏这种可见性，仪表盘看起来可能一切正常，实际上却遗漏了部分业务活动。

同样的问题也适用于金融事件流。如果风险报表只读取了一条交易路径而遗漏了另一条备用路径，可能会得出不完整的活动视图。正确的做法是对有效载荷进行画像分析，为重要字段定义可靠的映射关系，并在结果交给业务用户之前检查其合理性。

实用准则： 把可解析的有效载荷当作一项输入，而不是其字段已经一致到足以分析的证明。

今天就能用上的解析与预处理技巧

一个实用的数据管道，不需要在数据一到达就强行将所有来源统一成同一种形态。但它确实需要让每一次转换都变得可见、可测试。

从数据接入开始。像 Kafka 这样的流处理系统，或是面向 API 的托管连接器，都可以捕获事件并将其传递到数据湖或数据仓库中的落地区。在适当情况下保留原始有效载荷，这样工程师就能直接调查异常值，而不必从已转换的表中反推还原。

接下来，为到达的数据构建一个可用的工作模型。像 Apache Spark 这样的处理引擎中的模式推断（schema inference）可以帮助识别路径和可能的数据类型。JSON Schema 校验器可以检查关键字段是否符合约定规则。推断是一种有用的发现辅助手段，但不能替代你去判断业务究竟依赖哪些字段。

举例来说，一个零售数据管道可能会将 amount 和 total 映射到同一个共享的收入字段，同时明确转换可接受的数字字符串。遇到异常值应当被标记或隔离，而不是在无提示的情况下被强行转换。一个轻量级的处理流程可能是：

接入 → 解析 → 校验 → 规范化 → 测试 → 发布

最后要决定的是：保留嵌套记录，还是将特定路径展平为列。当团队需要灵活探索数据，或者数据源仍在变化时，应保留嵌套结构。当仪表盘、周期性预测或其他工作负载依赖稳定一致的访问方式时，应提取常用字段。把所有字段都展平，会让数据仓库更难维护；而把所有字段都保持嵌套，又会让日常报表工作变得繁琐。

对于需要跨营销系统规划活动数据的团队，doornoc 的数据管理指南就如何组织各平台间流转的信息提供了有价值的参考。无论数据来源是什么，在发布之前都要加入质量检查：校验重要字段，记录运行过哪些转换，并让异常情况对负责报表的人员清晰可见。

存储格式的选择如何影响查询速度

一旦数据管道完成了有效载荷的解析，存储方式就会决定查询引擎需要重复做多少工作。以普通文本字符串形式存储的 JSON 文档，在读取字段时必须重新解析。而采用带类型的半结构化表示方式，则可以保留可直接导航访问的数值，从而避免相关查询中重复的文本解析。

Databricks 使用 TPC-DS 衍生的半结构化数据进行的一项基准测试显示，Apache Parquet 的 Variant 表示法读取 JSON 的速度比普通字符串存储快达 8 倍。在同一基准测试中，将数据粉碎（shredding）为可查询列会使写入速度降低 20%–50%，而读取速度则提升约 30%。这些结果因工作负载而异，并不保证在每个数据仓库中都能获得相同的收益。Databricks 关于 Parquet 中 Variant 的说明介绍了该基准测试以及其中的架构权衡。

对于以数据摄取为主的数据流，尽量减少转换可能是一个合理的起点。而对于反复查询相同字段的仪表盘或异常检测场景，选择性提取可以在读取时节省工作量。请对团队实际运行的查询进行基准测试，包括它们的嵌套数组处理方式和过滤条件。这篇关于如何在数据湖和数据仓库之间做选择的指南有助于厘清更宏观的存储决策。

为什么读时模式（Schema-on-Read）仍然需要模式策略

读时模式可以减少每当数据源新增字段时就要重新设计表结构的需求。但这并不意味着分析师、报表或模型可以不对数据抱有任何预期。那些预期依然存在，只是转移到了下游。

当 API 在未经通知的情况下发生变化时，这种区别就显得尤为重要。一个新增的可选属性可能是无害的；而重命名一个用于库存预测的字段则可能并非如此。如果团队以同样的方式对待这两种变化，要么会阻碍有用的新增，要么会错过真正的破坏性变更。

一套可靠的数据漂移应对策略可以从以下四个习惯入手：

• 梳理路径与类型：追踪出现了哪些字段，以及它们的值是如何表示的。
• 为关键契约做版本管理：记录驱动业务指标的字段的预期名称和类型。
• 区分新增变化与破坏性变化：新增字段可能可以安全接受，而被重命名或移动位置的字段则需要刻意进行映射处理。
• 对异常情况发出警报：在数据到达仪表盘或模型之前，监控字段级别的空值率和类型变化。

针对半结构化数据的研究工作指出，更新、追加、流数据以及不断演变的模式一直是持续存在的难题。有些方法需要重新处理数据，才能推断出其当前结构。其中的实际启示很简单：自动发现可以帮助揭示变化，但它无法判定这种变化对你的业务意味着什么。

读时模式并不会消除模式本身。它只是让团队有责任在读取数据的报表和模型中对模式进行管理。

对于一个小型分析团队来说，一条清晰的警报往往比一次无声的类型转换更有价值。它能告诉对的人，哪个字段发生了变化，以及哪些下游输出可能需要关注。

嵌套记录中的隐私与安全问题

数据库权限可以保护一张表，却可能遗漏藏在嵌套对象、数组或新增字段中的敏感值。一个 API 数据负载可能在客户对象中包含一个电子邮箱地址，而某个自由文本字段中则可能包含数据源从未打算向每一位分析师公开的信息。

Cloud Security Alliance 的一项调查报告显示，在受访企业中，半结构化数据约占企业数据的 21%。该调查还显示，56% 的受访者只能部分掌握数据所在位置，安全、治理、隐私和合规是他们最关注的问题之一。Cloud Security Alliance 的研究公告提供了该调查的背景信息。

团队可以通过递归扫描嵌套内容，并将模式检查与上下文结合起来，而不是仅仅查找特定字段名称，来提升发现能力。他们还应追踪敏感字段的数据血缘，并根据数据的实际用途实施行级和字段级访问控制。规则需要同时兼顾风险和业务目的：过度脱敏会使运营分析无法使用，而遗漏数值则可能造成数据暴露。

要了解如何记录敏感信息流向的实用入门知识，合规性数据映射可以帮助团队梳理这项工作。可将其与面向分析团队的安全控制结合使用。隐私保护应在架构（schema）发生变化时重新检查，而不能当作一次性的数据库设置。

将半结构化数据源与 AI 分析平台集成

一个实用的端到端工作流程始于业务问题，然后沿着数据追溯到其来源。如果一家零售商想要改进库存预测，相关的输入可能包括库存记录、采购事件、促销详情，以及来自商务平台的 API 数据流。团队不仅需要了解如何解析这些数据源，还需要了解预测依赖哪些字段，以及如何捕捉变化。

AI 驱动的分析平台可以帮助团队连接数据源、预处理传入信息，并将结果纳入报告和预测中。具体功能取决于平台及其连接器，因此在依赖之前，请核实它如何处理你自己的 API、XML 数据流、事件日志以及变化的字段。询问它如何呈现类型变化、缺失值和意外路径，以及分析人员能否审查结果背后的转换过程。

数据治理还延伸到数据载荷格式之外。当企业使用外部或授权数据时，需要了解允许的使用方式、数据来源以及处理要求。评估这些问题的团队可以浏览企业数据授权选项，将其作为更广泛数据管理审查的一部分。

在向业务用户发布新数据源之前，请逐项核对以下清单：

• 数据接入：可靠地捕获负载数据，并保留足够的上下文以便排查问题。
• 模式策略：定义关键字段，并决定如何处理新增、重命名和类型变更。
• 存储：选择适合查询方式和数据接入模式的表现形式。
• 治理：识别敏感数据，并实施随数据流转的管控措施。
• 业务对齐：将最终分析结果与明确的关键绩效指标（如库存可用性或预测准确性）相关联，并让异常情况一目了然。

一条管理良好的数据管道能让灵活多变的数据更易于使用，同时不会忽视其对监管的需求。最终成果不应仅仅是一条已解析的记录，而应是团队能够解读、治理并用于决策的信息。

ELECTE 是一款面向中小企业的 AI 驱动数据分析平台，能够连接企业数据，并帮助团队将其转化为报告、预测和可执行的洞察。了解 ELECTE 如何帮助您的团队将半结构化数据源纳入更清晰的分析工作流程。