数据架构的基础作用（在以分析为中心的世界中）

军队里有这样一句话： “业余人士讨论战术，但专业人士研究后勤。” 当想到李将军在钱瑟勒斯维尔战役的辉煌表现，或汉尼拔在布匿战争中表现出的天才表现时，这个想法乍一看可能会让一些人感到惊讶；然而，历史表明李将军和汉尼拔都没有赢得各自的战争。 主要原因是后勤：在正确的时间和地点为军队提供食物、衣服和武器的能力。 尽管战术十分出色，但后勤才是最终决定胜利的因素。 换句话说，战术可以让你充分利用你在战场上的资产，但后勤则能让你首先留在战场上。

我喜欢军事类比，因为我相信它与当今数据驱动解决方案的描述有相似之处。 这些“战术”——深度学习、随机森林分类、梯度提升等先进的人工智能技术——的魅力常常会掩盖那些支持这些先进技术的数据架构基础的不那么性感的“逻辑”。

讨论数据架构的第一步是定义“数据架构”的概念包含什么。 毫不奇怪，答案是微妙的——它是层次分明和多面的。 为了帮助讨论奠定基础，首先从收集遥测数据的历程的角度来思考这个问题是很有帮助的。 下图显示了高级数据管道，突出显示了管道和数据架构基础之间的接触点。

每个数据元素的旅程始于其创建，通常经过一定程度的预处理，然后被序列化并传输到数据收集器/聚合器（通常位于云中）。 接下来，数据收集器本身可以（在反序列化和摄取之后）执行一些额外的处理和丰富，然后才将数据传送到持久数据存储和/或提供数据分析管道。 最后，丰富/分析的结果可通过可视化平台供人类使用，甚至可以以反馈输入的形式被自动化系统使用，用于自我调节或自我修复的闭环系统。

建立了数据管道上下文后，我们现在可以回到理解“数据架构”含义的问题。 从最肤浅的层面来看，第一个答案集中于数据表示和序列化语法。 例如，如果数据事件包含标题为“客户”的对象字段，则语法视图确定该数据是否表示为字符串、整数 UUID 或其他内容。

然而，如果我们深入挖掘，第二个答案不仅仅是关于语法；它还涉及数据的语义——对数据内容有明确定义和一致的解释。 再次以“客户”字段为例，假设语法问题已经得到解答——事实上数据元素已被定义为字符串字段。 接下来，数据架构必须能够回答含义/解释问题：语义是个人姓名的语义，还是公司名称的语义？ 如果是人名，是<last-name>还是<first-name>，或者两者兼有？  当与统一的语法相结合时，一致的语义允许数据管道基于对数据内容的一致逻辑解释，通用且稳健地执行数据过滤和聚合等功能。 此外，只要创建的数据遵循一致的语法和语义，数据存储还可以轻松地跨不同的数据创建管道实例执行联合数据查询。

最后，进一步深入挖掘，在许多情况下，数据架构中拥有第三种功能非常重要：用于将遥测和数据本身推理情境化的词汇表——元数据词汇表。 这在企业数据治理要求的背景下尤其重要，无论是对于合规性、审计，还是对于需要全面了解数据仓库中管理的数据的内部工作流。 元数据通常以数据注释的形式出现，注释遵循与数据本身相同的句法和语义一致性。 例如，元数据字段可能用于记录数据源的身份、任何收集数据的数据处理时间表，以遵守合法的数据保留要求。

元数据字段在数据描述模式的词典中的另一种使用方式是推理数据字段本身的各个方面，例如数据元素的序数或隐私敏感性。 再次回到我们的“客户”数据字段示例，数据模式中的元数据注释可能将数据元素标记为唯一，而在数据流上下文中（例如零售购买交易），其他注释可以将数据元素标记为必需和单例 -换句话说，元数据将用于表示customerID字段必须是唯一的（可用作数据库主键），并且每个购买事件必须有一个（且只有一个）相关联的customerID 。 在数据管道上下文中，元数据功能整体的实用性在于，它们可以用来添加数据合规性的注释，提供数据丰富词典，并为数据仓库提供灵活的治理工作流程。

总而言之，这个问题的答案是： “什么是数据架构？”至少是提供一个框架，使收集的数据在句法和语义上保持一致性。 此外，强大的数据架构还应包含足够强大的元数据策略，该策略不仅可以指定数据的约束，还包括对数据本身进行推理的能力。 

因此，当被视为明确的重点领域并得到良好执行时，数据架构很像良好的军事后勤基础设施。 正如在军事环境中一样，它提供了一个基础，可成倍提高建立在其上的系统的所有组件的效率和稳健性，从而使那些更可见的系统发挥最大效用。 在数据处理系统的背景下，数据架构基础为更灵活、更强大的数据治理模型、使用强大的数据仓库更轻松地跨数据源共享数据以及更具响应能力的方法获取新的数据源以实现业务敏捷性提供了基础。