结构化数据设计策略为何重要：示例解析

Ken Arora

背景

在前两篇文章中，我们重点探讨了数据驱动设计需要考虑的因素，尤其是业务数据如何体现潜在的业务价值。核心观点是，结构化数据架构是挖掘这种内在价值的技术基础。不过，这些文章主要从概念层面介绍了相关主题。今天，我想通过一个更具体、更贴近实际的示例来阐释这些概念，讲述如何以数据优先的思维来设计应用架构。

不过，先说说这为什么值得关注？

不过，在直接进入正题之前，我们先回顾一下，为什么数据如今比以往更加重要。过去，许多企业收集和存储数据主要是出于审计和合规等治理要求，数据本身并没有明确的应用目的。因此，数据收集和存储历来被视为企业运营的一种“税负”，人们认为它几乎无法为业务运营带来直接价值。

如今的变化在于，人们更加充分地认识到，可以挖掘所收集的数据，以优化业务流程并改善客户体验。例如，近期一项针对数字零售企业的调查显示，在所有受访企业中，57%将升级业务流程和改善客户体验这两项目标视为数字化转型的主要驱动力。关键在于，数据驱动型工作流既会影响面向外部的业务领域（例如客户体验），也会影响面向内部的核心业务流程。这正是周密且审慎的数据战略对于提升关键业务工作流的质量和成本效益至关重要的原因。此外，如果对工作流进行检测配置，将观测到的衍生数据传输至数据收集和分析基础设施，就可以持续分析和改进工作流本身，从而使业务工作流不断适应变化并得到优化。

顺带一提，这些企业在数字化转型方面最担忧的是如何确保相关数字化流程的网络安全。事实证明，同样的数据遥测和分析方法也能在这一领域发挥关键作用，不过我会另撰文章探讨这个话题。

应用场景：餐厅点餐与配送

继续我们的思想实验。我选择了一个在如今适应新冠疫情的生活方式下，许多人可能都深有体会的场景：一款提供餐厅餐食在线订购和配送服务的应用。顾客可以在线向指定餐厅订餐，并选择自行取餐或由该服务配送。

在这个故事中，我们将扮演应用所有者。作为应用所有者，我们需要处理许多不同的问题。我们将这些问题分为两类：一是必要的运营活动，二是着眼未来的战略问题。

第一类是必要的运营活动，包括以下事项：

• 查找餐厅并了解其相关信息，包括位置和营业时间
• 汇总菜单菜品及价格数据
• 向餐厅发送订单通知
• 处理付款
• 记录可接单并配送订单的人力资源可用情况
• 跟踪订单备妥情况和配送状态

第二类关注事项与日常运营的关系较小，但同样重要。如果提前考虑这些问题，企业将能够保持敏捷、灵活应变并持续改进。此类关注事项包括：

• 如何预测需求？可以只按一天中的不同时段或一周中的不同日期预测总需求，也可以采用更细的粒度，例如按餐厅预测。
• 哪些工具、流程或工作流可以为我的供应商（餐厅）提供业务洞察？
• 如何动态调整餐品或配送的价格？
• 假设我的应用托管在公有云中，如何优化基础设施运营成本？

当然，这只是我们需要考虑的众多问题中的一部分，但即使是这个较小的集合，也足以展开深入讨论，并凸显结构化数据架构对于支持可扩展数据处理管道的重要性。

数据架构还是数据管道：先有鸡还是先有蛋

假设我们是应用所有者，在考虑整体数据策略时，可以先列出各项业务工作流，并确定每项工作流的数据处理需求。例如，在查找附近营业中的餐厅并显示各餐厅的菜单选项和菜品价格这一工作流中，需要根据位置和营业时间筛选餐厅，然后查询指定餐厅的菜单选项，还可能需要根据配送司机是否有空进一步筛选。我们可以对每项工作流采用这种方法，包括支付处理、为配送任务匹配司机等。

另一种同样合理的做法是，从基本数据“原子”，即所需的数据构建块入手。我们可以识别并列举重要的数据原子，尤其要确保这些数据原子的表示方式统一、语义一致，并确定支持业务工作流所需的元数据词汇。示例应用中的数据原子包括：位置数据，用于餐厅、客户和司机；食品项，用于菜单和账单；时间，用于筛选和跟踪配送质量；以及支付信息，与客户付款和司机收款工作流相关。

在工作流的数据处理管道和数据“原子”这两个潜在起点中，数据策略应从哪一个入手，是一个先有鸡还是先有蛋的问题。这两种视角都很有用，更重要的是，它们相互依存。分析数据处理管道时，不能不考虑底层的数据原子；设计数据架构时，也不能忽视处理管道的需求。尽管如此，一般而言，我建议先初步梳理各项工作流，列举其中的数据原子，然后先对数据架构进行结构化设计，再详细设计数据管道。这是因为工作流的动态性更强，会随着业务发展不断增加和调整；而底层数据具有更深的历史积淀和更强的惯性，因此，提前周密规划对数据架构更有帮助。

将整体性数据架构和管道方法应用于具体示例

回到前面的示例。假设作为应用所有者，我们已经对关键业务工作流及其所需的数据原子有了较为成熟的认识。在前文中，我们确定了工作流所需的几个基础数据元素：位置、时间、食品项目和支付信息。回顾之前的文章，数据架构应实现3个关键目标：语法统一、语义一致，以及建立用于分析和治理数据的元数据词汇体系。现在，我们可以运用这些原则，探讨今天示例中所列具体数据原子的数据架构注意事项。

具体来看位置这一数据原子，请分别考虑数据架构的3个关键目标。

• 首先，什么是统一的数据表示语法？
  最初可能会考虑使用街道地址来表示位置，因为餐厅和顾客通常都以这种方式表示其位置。但是，在跟踪配送司机时，还需考虑其位置需求。司机往往处于移动状态，可能正在主干道上，也可能位于难以用街道地址准确描述的地点。因此，对于该工作流，使用经纬度来表示位置可能更合适，而且这种格式同样适用于餐厅和顾客的位置。不过，由于司机通常需要导航至餐厅或顾客所在地，因此仍需通过某种方式，将司机的（经纬度）位置与顾客的（街道地址）位置关联起来。因此，经过更全面的考虑，可以选择将所有位置数据规范化为经纬度格式（所需的“规范”表示形式），同时支持在首次提供街道地址时将其转换为经纬度（即“摄取”工作流）。
• 第二个考虑因素是语义一致性。
  假设位置数据已统一为纬度和经度，这一点相对简单，因为这是一项成熟的标准，含义明确。不过，语义一致性还涉及精度，即数据所隐含的精确程度。鉴于GPS和地图数据本身的准确度有限，可以根据数据源的质量，选择以固定精度（例如精确到最接近的角秒，约合100英尺）或可变精度来指定位置。如果为了灵活性而选择后者，则必须使用下文所述的元数据，标注每个位置数据实例的精度。
• 数据架构的第三个目标是具备为采集的数据元素添加注释并进行丰富的能力。
  对于位置数据，这可能包括前文提到的数据精度。此外，还可以为位置数据添加街道地址注释，以便于理解，尤其是为了保留摄取的地址数据。当多个街道地址可能映射到同一经纬度时（例如公寓小区），这一点尤为重要。还可以添加位置数据字段的采集时间戳。对于行驶中的驾驶员，这可能很有意义，因为位置数据很快就会过时。

目前我们只讨论了位置方面的要求。接下来可以对其他各个数据字段进行类似分析。不过，我不会逐一列举每个数据原子的所有关注事项，而是重点介绍几个值得注意的方面：

• 关于时间数据原子：时间值的表示方式向来十分复杂。其语法形式可能有所不同（例如，24 小时制与带 AM/PM 的 12 小时制），语义也可能存在差异（例如，时区概念以及各地实行夏令时的差异）。因此，时间的表示方式可能需要进行规范化处理（例如，统一转换为 GMT；对于 Unix/Linux 用户，也可表示为“自纪元以来”的秒数）。
• 食品项数据实例可能差异很大，各有其独特需求。由于这些数据原子通常采用自由格式，因此，与其尝试统一语法，不如使用规范的元数据词汇表。部分元数据字段用于描述各食品项的静态属性，例如“需要冷藏”或“含坚果”；另一些元数据字段则用于描述各实例（各订单）的食品项信息，例如“辣度”或“偏好的调味品”。无论哪种情况，设计目标都要求元数据字段采用统一的语法和一致的语义，以便在完整的菜单项清单中共享。
• 其他关键考虑因素包括数据合规与治理。其中一项是数据保留策略，某些字段（例如客户的IP地址或驾驶员的位置历史记录）只能短期保留。另一个常见考虑因素是，某些字段可能受到安全或隐私限制，例如支付信息。元数据扩充可以解决这两类问题。对于数据保留，应使用元数据为IP地址或位置值标注数据到期时间。对于支付信息，可以使用元数据传达安全要求，例如要求对静态数据进行加密，或指定持久性数据存储的地理位置限制。

虽然这个示例仍只是浅尝辄止，但它已突显出现实场景中的许多相关问题。然而在实际应用中，数据策略的思考过程不会止步于此，而是需要持续迭代。随着数据元素输入承载业务工作流的数据处理管道，数据架构也会不断调整和完善。随着现有工作流得到增强并加入新的工作流，我们会发现，现有数据原子和新数据原子还会带来更多数据架构需求。

结语

尽管为简洁起见对本示例进行了精简，但它仍阐明了将工作流映射到相应数据架构时所涉及的关键原则。该过程始终从业务需求出发，即所需的客户体验，以及满足这些需求所需的业务流程。业务流程进而定义业务词汇表中的元素。进一步细化后，这些流程将映射到使用数据词汇表的数据管道。

关键原则是，稳健的数据架构通过定义语法、语义和注释，为高效增强数据管道和便捷添加新工作流奠定基础。在业务层抽象中，这意味着可以轻松修改现有业务流程，并快速上线新的或新兴的业务流程。反之，如果未能在数据词汇、数据架构框架或将二者与业务需求相关联等方面做出审慎决策，最终将导致系统缺乏稳健性，难以灵活适应新的业务需求。

关于作者

Ken Arora

Ken Arora 的更多博客文章