结构化数据设计策略为何如此重要： 一个例子
背景
在之前的两篇文章中，我们重点讨论了数据驱动设计的考虑因素；具体来说，围绕业务数据如何代表潜在的业务价值。 关键信息是：结构化数据架构是提取固有价值的技术基础。 但这些文章主要集中在概念层面上介绍相关主题。 今天，我想通过一个更加具体、更加相关的例子来解释这些概念；一个关于如何思考构建一个符合数据优先思维的应用的故事。
但首先——我为什么要关心？
不过，在直接进入正题之前，让我们先回顾一下为什么数据在今天比过去更重要。 从历史上看，许多企业都会收集和存储数据，主要是为了自身利益，出于治理的原因，例如审计和合规。 因此，数据收集和存储历来被视为对商业运营的一种“税收”，几乎没有直接的运营商业价值。
现在的变化是，人们更加充分地认识到可以挖掘收集到的数据来优化业务流程并改善客户体验。 例如，根据最近对数字零售企业的调查，57% 的受访者表示，这两个目标（升级业务流程和客户体验）是数字化转型的主要驱动力企业。 关键的观察，即“为什么重要”的本质，是数据驱动的工作流程既影响面向外部的领域（例如客户体验），也影响面向内部的领域（即核心业务流程）。 这就是为什么深思熟虑的数据策略对于确保最重要的业务工作流程的质量和成本效益至关重要。 此外，当工作流程被设计用来将其观察到的数据传输到数据收集和分析基础设施时，工作流程本身就可以不断地进行分析和改进，从而不断适应和优化业务工作流程。
顺便说一句，这些企业在数字化转型方面最严重的担忧是确保这些数字化流程的网络安全——事实证明，这也是数据遥测和分析方法发挥关键作用的另一个领域——不过我将把它留到另一篇文章中讨论。
application： 餐厅订餐及配送
继续我们的思想实验，我选择了一个我们许多人在当今适应冠状病毒的生活方式中可能都有共鸣的故事——一个提供餐厅订餐和送餐在线服务的应用。 餐食是客户从指定的餐厅在线订购的，用户可以选择直接让客户自取订单，或者让服务人员一起配送。
在这个故事中，我们将扮演application所有者的角色。 在这一角色中，我们需要解决许多不同的问题，我们将这些问题分为两类：第一，所需的运营活动；第二，前瞻性的战略问题。
第一组是必需的运营活动，包括以下方面：
- 寻找并描述餐馆，包括其位置和营业时间
- 整理菜单项目和价格的数据
- 通知餐厅订单
- 处理付款
- 保存有关人力资源接收和运送订单的可用性的数据
- 跟踪订单准备情况和交付状态
第二组关注的问题不太涉及日常运作，但同样重要。 这些问题——如果提前考虑——将使企业变得敏捷、适应性强并持续改进。 此类担忧的例子有：
- 如何预测需求？ 这可能只是按一天中或一周内的时间汇总需求，或者可能是更细粒度的需求，例如按每个餐厅汇总需求。
- 什么样的工具、流程或工作流程可以为我的供应商（餐馆）提供商业洞察？
- 如何动态调整食品和配送的价格？
- 假设我的应用托管在公共云中，如何优化我的运营基础设施成本？
当然，这只是我们所关注的全部内容的一个子集，但即使是这个较小的集合也足以进行良好的讨论，强调结构化数据架构在支持可扩展数据处理管道方面的重要性。
数据架构或数据管道/先有鸡还是先有蛋
在我们想象的application所有者的角色中，当我们考虑我们的整体数据策略时，我们可以首先枚举我们的业务工作流程，确定每个工作流程的数据处理需求。 一个例子是查找附近营业的餐馆，然后为每家餐馆提供菜单选择和菜品价格的工作流程——它需要根据位置和营业时间筛选餐馆，然后查找特定餐馆的菜单选择，或许还需要根据送货司机的空闲情况进行筛选。 我们可以为每个工作流程执行此操作——付款处理、匹配司机和送货等等。
或者，同样合理的是，我们可以从基本数据“原子”——所需的数据构建块开始考虑。 我们将识别和列举重要的数据原子，特别注意这些数据原子的统一表示和一致的语义以及支持我们的业务工作流所需的任何元数据词汇。 我们的示例应用中数据原子的示例包括：餐馆、顾客和司机的位置数据；菜单和发票所需的食品；用于过滤和跟踪交付质量的时间；以及与顾客和司机支付工作流相关的支付信息。
这两个潜在的起点（工作流的数据处理管道，或者数据“原子”）中的哪一个用于我们的数据策略，是一个先有鸡还是先有蛋的问题。 这两种观点都很有用，而且更重要的是，它们是相互依存的。 如果不考虑底层数据原子，我们就无法推理数据处理管道；如果不考虑处理管道的需求，我们就无法开发数据架构。 尽管如此，总的来说，我建议采用一种方法，首先遍历工作流来枚举数据原子，然后在进行数据管道的详细设计之前进行数据架构的结构化设计。 这是因为工作流程更加动态；随着业务的发展，工作流程会被添加和修改，而底层数据具有更多的历史和惯性，因此数据架构从深思熟虑中受益更多。
将整体数据架构和管道方法应用于具体示例
回到我们的例子，让我们假设，作为application所有者，我们对关键业务关键工作流和支持它们所需的数据原子有一个相当发达的了解。 在本次讨论的早些时候，我们已经确定了工作流程所需的一些基础数据元素：位置、时间、食品和付款信息。 并且，回顾之前的文章，数据架构应该实现 3 个关键目标：语法的统一性、语义的一致性以及用于推理和管理数据的元数据词汇表。 所以现在，我们可以应用这些原则来讨论今天的例子中列举的特定数据原子的数据架构考虑因素。
放大位置数据原子，考虑 3 个关键数据架构目标中的每一个。
- 首先，什么是统一数据表示语法？
最初的想法可能是用街道地址来表示位置，因为餐馆和顾客通常这样表示他们的位置。 然而，考虑跟踪送货司机的位置需求——他们经常在移动，可能在主要高速公路上，或者在街道地址无法很好描述的位置。 相反，纬度和经度规范可能是表示该工作流程位置的更好方式，并且这种格式仍然适用于餐厅和顾客位置。 但由于司机通常必须导航到餐厅或顾客位置，因此仍然必须有一种方法将司机（纬度/经度）位置与顾客（街道地址）位置联系起来。 因此，更加慎重的选择可能是将所有位置数据标准化为纬度和经度（所需的“规范”表示），但能够在首次提供街道地址时将街道地址转换为纬度/经度（“摄取”工作流程）。 - 第二个考虑是语义的一致性。
假设位置被标准化为纬度/经度，这相对简单，因为这是一个具有明确解释的完善的标准。 然而，一致语义的另一个方面是精度——数据隐含的准确性。 鉴于 GPS 和地图数据的隐含精度限制，我们可以选择以恒定精度（例如，精确到角秒，大约 100 英尺）或可变精度指定位置，具体取决于数据源的质量。 如果我们为了灵活性而选择后者，我们必须使用接下来描述的元数据来注释每个位置数据实例的精度。 - 数据架构的第三个目标是具有注释和丰富收集的数据元素的能力。
就位置而言，这可能包括数据的精度，如前所述。 此外，为了人性化，我们可能还想用街道地址注释位置，特别是为了能够保存提取的地址数据。 这对于多个街道地址可能映射到相同纬度/经度的情况（例如公寓大楼）尤其重要。 另一个丰富的功能可能是收集位置数据字段时的时间戳，这可能与行驶中的驾驶员有关，因为位置数据很快就会过时。
我们只讨论了位置的要求，现在可以对其他每个数据字段进行类似的练习。 然而，我不会列举每个数据原子的所有关注领域，而是会强调一些值得注意的观察结果：
- 关于时间数据原子： 时间值的表示是出了名的棘手。 它可能在句法上有所不同（例如，24 小时格式与。 12 小时加 AM/PM）和语义上（例如时区概念和夏令时观察的变化）。 因此，时间的表示可能需要规范化（例如通过规范化为 GMT，或对于 Unix/Linux 用户来说“自纪元以来”的秒数）。
- 食品项目数据实例可能非常多样化，具有独特的需求。 由于数据原子通常是自由形式的，因此规范的元数据词汇比尝试统一的语法更有用。 一些元数据字段用于每个项目的静态属性，例如“需要保持冷藏”或“包含坚果”，但其他元数据字段则需要用于每个实例（每个订单）的食品信息，例如“辣度”或“首选调味品”。 无论哪种情况，设计目标都要求元数据字段具有统一的语法和一致的语义，以便它们可以在整个菜单项中共享。
- 其他关键考虑因素是数据合规性和治理。 其中一个方面是数据保留策略，其中一些字段（例如客户的 IP 地址或驾驶员的位置历史记录）只能保留短时间。 另一个常见的考虑因素是某些字段可能有安全或隐私限制；例如支付信息。 元数据增强是这两种情况的解决方案。 元数据应用于注释 IP 地址或位置值以及数据保留的数据过期时间。 对于支付信息来说，元数据可用于传达安全要求——例如静态数据加密的需要，或指定持久数据存储的地理位置约束。
虽然这个例子还只是浮于表面，但它凸显了许多与现实场景相关的问题。 然而，在现实世界中，思考数据策略的过程不会就此结束，而是会不断迭代、持续进行。 随着数据元素被输入到体现业务工作流的数据处理管道中，数据架构会进行迭代调整和增强。 随着现有工作流程的增强和新工作流程的添加，我们会发现现有数据原子和新数据原子的额外数据架构要求。
结束语
尽管此示例已简化以简洁起见，但它仍然展示了将工作流映射到其数据架构含义的关键原则。 该过程总是从考虑业务需求开始——客户体验和满足这些需求所需的业务流程。 反过来，业务流程又定义了业务词汇的元素。 在下一个具体级别，流程映射到数据管道，该管道利用数据词汇。
关键原则是，强大的数据架构（定义语法、语义和注释的架构）构建了一个基础，允许有效增强数据管道并轻松添加新的工作流程。 在业务层抽象上，这意味着可以轻松修改现有的业务流程，并且新的或新兴的业务流程可以快速上线。 相反，如果在数据词汇、数据架构框架或将其与业务需求联系起来等任何领域都未能做出深思熟虑的决定，最终将导致系统脆弱不堪，无法灵活应对新的业务需求。