军界有句名言：“外行谈战术，内行研究后勤。”乍看之下，这一观点可能会让一些人感到意外。毕竟，李将军在钱斯勒斯维尔战役中展现了卓越的指挥才能，汉尼拔也在布匿战争中尽显军事才华。然而，历史表明，两人最终都未能赢得各自的战争。主要原因在于后勤，也就是在适当的时间和地点持续为军队供应食物、衣物和武器的能力。尽管战术出色，最终决定胜负的却是后勤。换言之，战术能让您充分利用战场上的现有资源，而后勤则是让您能够进入战场并持续作战的基础。
我喜欢这个军事类比，因为它与当今数据驱动型解决方案通常呈现的方式有相似之处。“战术”光鲜亮丽，也就是深度学习、随机森林分类和梯度提升等高级AI技术，往往会掩盖不那么引人注目的“后勤”，即支撑这些高级技术的数据架构基础。
讨论数据架构，首先需要明确“数据架构”这一概念的涵盖范围。不出所料，答案并非三言两语可以概括，因为数据架构具有多个层次和维度。为了让讨论更具体，不妨先从所收集遥测数据的流转过程入手。下图展示了一个高层级数据管道，并重点标出了该管道与数据架构基础之间的衔接点。
每个数据元素的旅程都始于创建，通常会先经过一定程度的预处理，然后进行序列化，并传输到通常位于云端的数据收集器或聚合器。接下来，数据收集器本身可能会在反序列化和摄取后执行一些额外的处理和扩充，再将数据传送到持久性数据存储，和/或输入数据分析管道。最后，扩充或分析后的结果会通过可视化平台呈现，供用户查看；自动化系统甚至也可以将这些结果作为反馈输入，用于自调优或自修复闭环系统。
明确数据管道的背景后，现在可以回到“数据架构”含义这一问题。最表层的答案侧重于数据表示和序列化语法。例如，如果某个数据事件包含名为“customer”的对象字段，语法视角将确定该数据是表示为字符串、整数UUID，还是其他形式。
不过，如果进一步深入探讨，第二种答案所涉及的内容不只是语法，还包括数据的语义，即对数据内容作出明确且一致的解释。仍以“customer”字段为例，假设语法问题已经解决，也就是说，该数据元素已定义为字符串字段。接下来，数据架构必须能够回答含义或解释方面的问题：其语义表示个人姓名，还是公司名称？如果是个人姓名，表示的是<last-name>、<first-name>，还是两者兼有？统一的语法与一致的语义相结合后，数据管道便可基于对数据内容连贯一致的逻辑解释，以通用且稳健的方式执行数据筛选和聚合等功能。此外，只要所创建的数据遵循一致的语法和语义，数据存储还可以轻松地跨不同的数据创建管道实例执行联合数据查询。
最后，再深入一层，在许多情况下，数据架构还需要具备第三种能力：使用一套词汇为遥测数据提供上下文，并对数据本身进行分析推理，也就是元数据词汇。这对于满足企业数据治理要求尤为重要，无论是合规、审计，还是需要全面了解数据仓库中所管理数据的内部工作流。元数据通常以数据注释的形式呈现，这些注释与数据本身遵循同样一致的语法和语义。例如，为满足法定的数据保留要求，元数据字段可能用于记录数据源的身份信息，以及所收集数据的处理时间线。
在数据描述模式的词汇体系中，元数据字段还可用于描述数据字段本身的特征，例如数据元素的序数或隐私敏感性。再次以“客户”数据字段为例，数据模式中的元数据注释可能会将该数据元素标记为唯一；而在数据流（例如零售购买交易）的上下文中，其他注释可将数据元素标记为必填且单值。换言之，元数据可用于说明customerID字段必须唯一（可用作数据库主键），并且每个购买事件都必须关联一个且仅一个customerID。在数据管道中，完整的元数据功能可用于添加数据合规性注释、提供数据扩充词汇体系，并为数据仓库支持灵活的治理工作流。
综上所述，对于“什么是数据架构？”这一问题，答案是：数据架构至少应提供一个框架，确保所收集的数据在语法和语义上保持一致。此外，健全的数据架构还应包含一套功能强大的元数据策略，不仅能够指定数据约束，还应具备对数据本身进行推理的能力。
因此，如果将数据架构作为一个明确的重点领域并妥善实施，它就很像完善的军事后勤基础设施。正如在军事领域一样，数据架构能够奠定基础，提升构建于其上的所有系统组件的效率和稳健性，使那些更直观可见的系统充分发挥作用。在数据处理系统中，数据架构基础有助于构建更灵活、更强大的数据治理模型，利用稳健的数据仓库更轻松地跨数据源共享数据，并以更敏捷的方式接入新的数据馈送，从而提升业务敏捷性。
相关博客文章
2023年应用策略现状：成本与复杂性是推动多云网络发展的首要因素
多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联，为解决当今混合IT面临的挑战提供支持，因而备受业界关注。