在大数据和数据科学的新时代，企业拥有与业务流程一致的集中式数据架构至关重要，该架构随着业务增长而扩展，并随着技术进步而发展。成功的数据架构可以清楚地了解数据的各个方面，从而使数据科学家能够有效地处理可信赖的数据并解决复杂的业务问题。它还使组织准备好通过利用新兴技术快速利用新的业务机会，并通过管理整个企业的复杂数据和信息交付来提高运营效率。与信息架构、系统架构和软件架构相比，数据架构相对较新。数据架构师的角色也很模糊，落在了高级业务分析师、ETL 开发人员和数据科学家的肩上。尽管如此，我们认为数据架构师是指那些为组织设计数据架构的数据管理专业人员。
在谈论架构时，我们经常会想到与建筑架构的类比。传统的建筑架构师计划、设计和审查建筑物的建造。设计过程涉及与客户合作以充分收集要求，了解该地点的法律和环境限制，并与工程师、测量师和其他专家合作，以确保设计符合实际并在预算范围内。这项工作的复杂性确实与数据架构师的角色非常相似。但是，这两个架构师角色之间存在一些根本区别：
■建筑架构是自上而下设计的，而数据架构通常是可能已经存在的组件或系统的集成过程。
■建筑架构师在建造建筑物之前必须了解全部要求并定义整个范围。数据架构的范围可以很广泛并且很容易改变。因此，一个成功的数据架构应该被设计成灵活的并且能够预测未来的变化。
■建筑架构师具有明确的教育和专业要求，应具备商业、艺术、结构物理和建筑材料方面的深入知识。大多数数据架构师来自 IT 背景，在少数公司或行业拥有专业经验，并且对业务的了解有限。因此，他们应该意识到他们的设计可能存在偏差，并且他们需要根据组织中业务和技术专家的反馈进行调整。
建筑设计几乎总是针对从零开始建造的新建筑。因此，建筑架构师可以完全根据新要求和新材料进行规划和设计。数据架构师没有这种奢侈的环境，他们很少能从头开始，但在为未来设计时需要了解现有的平台和数据库。
鉴于所有这些差异，数据架构师仍然可以向建筑架构师学习，特别是采用自上而下的方法来改进数据架构设计。在许多组织中，缺乏系统的、集中的、端到端的数据架构设计。下面列出了一些主要原因：
■大型集团有多个 IT 部门，他们各自独立地使用自己的数据标准和架构。
■应用程序和流程是根据个人业务需求构建的，没有可遵循的数据架构标准。■数据架构师的角色只关注有限数量的技术领域，并且对数据拥有有限的业务知识。
■IT 项目的管理不考虑数据架构作为设计阶段的一部分；数据科学家和工程师在没有一致的数据管理流程的情况下自行编写代码。
由于这些不足，我们经常看到一家公司的数据系统脱节，团队和部门之间存在差距。这些差异导致系统性能不佳，出现生产数据问题时需要很长时间才能进行故障排除，缺乏跨系统达成正确解决方案的责任感，以及缺乏评估影响的能力改变。最后，当迁移或重新设计到下一代平台时，脱节的系统可能会导致分析和研究工作量巨大。
鉴于所有这些，成功的企业需要有一个基于业务流程和运营设计的自上而下的连贯数据架构。特别是，就像建筑架构师所做的那样，企业数据架构师需要首先在概念和逻辑级别构建蓝图，然后再将技术应用于详细的应用程序设计和实现。
1. 基于业务流程和运营的概念级数据架构设计
在现代 IT 中，业务流程由数据实体、数据流和应用于数据的业务规则支持和驱动。因此，数据架构师需要具备深入的业务知识，包括财务、营销、产品以及业务流程的行业特定专业知识，例如电信、金融、制造和零售等。然后，可以通过设计代表每个业务领域的数据实体和分类以及业务流程下的数据流，在企业级别正确构建数据蓝图。特别是，在这个概念阶段需要考虑和规划以下领域：
■核心数据实体和数据元素，例如关于客户、产品、销售的数据。
■用户和客户需要的输出数据。
■要收集和转换或引用以生成输出数据的源数据。
■每个数据实体的所有权以及应如何根据业务用例使用和分发数据实体。
■应用于每个数据实体的安全策略。
■数据实体之间的关系，例如引用完整性、业务规则、执行顺序。
■标准数据分类和分类。
■数据质量、操作和服务水平协议 (SLA) 的标准。
此概念设计级别由支持每个业务功能的底层数据实体组成。蓝图对于成功设计和实施企业和系统架构及其未来的扩展或升级至关重要。在许多组织中，这种概念设计通常嵌入到由单个项目驱动的业务分析中，而没有从企业端到端解决方案和标准的角度进行指导。
2. 逻辑级数据架构设计
通过考虑使用哪种类型的数据库或数据格式，这种设计水平有时被称为数据建模。它将业务需求连接到底层技术平台和系统。但是，鉴于数据建模者的角色，大多数组织仅在特定数据库或系统中设计数据建模。通过考虑适用于每个数据库或系统的标准以及这些数据系统之间的数据流，应使用集成方法开发成功的数据架构。特别是需要以协同方式设计以下5个领域：
■命名约定和数据完整性
数据实体和元素的命名约定应该一致地应用于每个数据库。此外，如果相同的数据必须驻留在多个数据库中，则应强制执行数据源及其引用之间的完整性。最终，这些数据元素应该属于数据架构中概念设计中的一个数据实体，然后可以根据业务需求进行协同准确的更新或修改。
■数据归档/保留政策
数据归档和保留策略通常直到数据生产的每个后期才考虑或建立，这导致资源浪费、不同数据库之间的数据状态不一致以及数据查询和更新的性能不佳。为了加强数据完整性，数据架构师应根据运营标准在数据架构中定义数据归档和保留策略。
■隐私和安全信息
隐私和安全成为逻辑数据库设计的重要方面。虽然概念设计已经定义了哪些数据组件是敏感信息，但逻辑设计应该在数据库中保护机密信息，访问受限、数据复制受限、特定数据类型和安全数据流以保护信息。
■数据复制
数据复制是三个目标需要考虑的一个关键方面：
1）高可用性；
2) 避免通过网络传输数据的性能；
3) 解耦以最小化下游影响。但是，过多的数据复制会导致混乱、数据质量差和性能低下。任何数据复制都应由数据架构师检查，并按照原则和规则加以应用。
■数据流和管道
应该在这个级别明确定义不同数据库系统和应用程序之间的数据流动方式。同样，此流程与业务流程和数据架构师概念级别中说明的流程一致。此外，数据摄取的频率、管道中的数据转换以及针对输出数据的数据访问模式应在逻辑设计的集成视图中考虑。例如，如果上游数据源是实时的，而下游系统主要用于索引繁重的聚合信息的数据访问（例如，频繁更新和插入的成本很高），则需要在两者之间设计数据管道以优化性能。
3. 数据治理是数据架构持续成功的关键
由于数据架构反映并支持业务流程和流程，因此无论何时更改业务流程，它都会发生变化。随着底层数据库系统的变化，数据架构也需要调整。因此，数据架构不是静态的，而是需要持续管理、增强和审计。因此，应采用数据治理来确保在启动每个新项目时正确设计和实施企业数据架构。
小结
在成功的数据架构中，基于业务流程的概念设计是最关键的要素，其次是强调所有数据库和数据管道的一致性、完整性和效率的逻辑设计。一旦建立了数据架构，组织就可以查看哪些数据驻留在何处，并确保数据得到保护、有效存储和准确处理。此外，当一个数据库或一个组件发生变化时，数据架构可以让组织快速评估影响并指导所有相关团队进行设计和实施。最后，数据架构是企业系统的实时文档，保证是最新的，并提供清晰的端到端视图。
