谈谈企业需要什么样的数据架构

在大数据和数据科学的新时代，企业拥有一个与业务流程保持一致的集中式数据架构至关重要，该架构可以随着业务增长而扩展，并随着技术进步而发展。一个成功的数据架构可以清晰地展示数据的各个方面，从而使数据科学家、数据分析师、业务人员能够高效地处理可信赖的数据并解决复杂的业务问题。它还使组织能够通过利用新兴技术快速应对新的商业机会，并通过管理整个企业的复杂数据和信息交付来提高运营效率。

与信息架构、系统架构和软件架构相比，数据架构相对较新。数据架构师的角色也一直模糊不清，落在了高级业务分析师、ETL 开发人员和数据科学家的肩上。尽管如此，Data Architect 主要指那些为组织设计数据架构的数据管理专业人员。

在谈论架构时，我们通常会想到与建筑架构的类比。传统的建筑架构师计划、设计和审查建筑物的建造。设计过程涉及与客户合作以充分收集要求，了解当地的法律和环境限制，并与工程师、测量师和其他专家合作以确保设计切合实际并在预算范围内。这项工作的复杂性确实与数据架构师的角色非常相似。但是，这两个架构师角色之间存在一些根本差异：

• 建筑架构是自上而下设计的，而数据架构通常是可能已经存在的组件或系统的集成过程。
• 建筑架构师在建造建筑之前必须了解全部要求并定义整个范围。数据架构的范围可以很广并且很容易改变。因此，一个成功的数据架构应该被设计成灵活的并且能够预测未来的变化。
• 建筑架构师具有精确的教育和专业要求，应具备商业、艺术、结构物理和建筑材料方面的深入知识。大多数数据架构师来自 IT 背景，在少数公司或行业拥有专业经验，对业务的接触有限。因此，他们应该意识到他们的设计可能存在偏差，并且他们需要根据组织中业务和技术专业知识的反馈对其进行调整。
• 建筑设计几乎总是针对从头开始建造的新建筑。因此，建筑设计师可以完全根据新要求和新材料进行规划和设计。数据架构师没有这种奢侈。他们很少能从头开始，而是在为未来设计时需要了解现有的平台和数据库。

尽管有这些差异，数据架构师仍然可以向建筑架构师学习，特别是采用他们自上而下的方法来改进数据架构设计。在许多组织中，一直缺乏系统的、集中的、端到端的数据架构设计。下面列出了一些主要原因：

• 一家公司有多个 IT 部门，他们使用自己的数据标准和架构在孤岛中工作。
• 应用程序和流程是根据个人业务需求构建的，没有可遵循的数据架构标准。
• 数据架构师的角色只关注有限的技术领域，并且数据业务知识有限。
• IT 项目的管理没有将数据架构作为设计阶段的一部分；数据科学家和工程师在没有一致的数据管理流程的情况下按照自己的方式进行编码。

由于存在这些不足，我们经常会看到一家公司的数据系统脱节，团队和部门之间存在差距。这些差异导致系统性能不佳，有很多交接，出现生产数据问题时需要很长时间进行故障排除，缺乏跨系统达成正确解决方案的责任感，以及缺乏评估影响的能力变化。最后，当迁移或重新设计到下一代平台时，脱节的系统可能会导致分析和研究的巨大努力。

鉴于所有这些，一个成功的企业需要有一个基于业务流程和操作设计的自上而下的连贯数据架构。特别是，就像建筑架构师所做的那样，企业数据架构师需要先在概念和逻辑层面构建蓝图，然后再将技术应用到详细的应用程序设计和实现中。

1. 基于业务流程和运营的概念级数据架构设计

在现代 IT 中，业务流程由数据实体、数据流和应用于数据的业务规则来支持和驱动。因此，数据架构师需要具备深入的业务知识，包括财务、营销、产品以及业务流程的行业特定专业知识，例如健康、保险、制造商和零售商。然后，可以通过设计代表每个业务领域的数据实体和分类法以及业务流程下的数据流，在企业级别正确构建数据蓝图。特别是，在这个概念阶段需要考虑和规划以下领域：

• 核心数据实体和数据元素，例如有关客户、产品、销售的数据。
• 客户和顾客需要的输出数据。
• 要收集和转换或引用以生成输出数据的源数据。
• 每个数据实体的所有权以及如何根据业务用例使用和分配它。
• 应用于每个数据实体的安全策略。
• 数据实体之间的关系，如引用完整性、业务规则、执行顺序。
• 标准数据分类和分类法。
• 数据质量、操作和服务水平协议 (SLA) 的标准。

此概念设计级别由支持每个业务功能的底层数据实体组成。蓝图对于企业和系统架构的成功设计和实施及其未来的扩展或升级至关重要。在许多组织中，这种概念设计通常嵌入到由单个项目驱动的业务分析中，而没有从企业端到端解决方案和标准的角度进行指导。

2. 逻辑层数据架构设计

通过考虑使用哪种类型的数据库或数据格式，这种设计级别有时称为数据建模。它将业务需求连接到底层技术平台和系统。然而，考虑到数据建模者的孤立角色，大多数组织只在特定的数据库或系统中设计数据建模。一个成功的数据架构应该通过综合方法开发，考虑适用于每个数据库或系统的标准，以及这些数据系统之间的数据流。特别是以下5个领域需要协同设计：

命名约定和数据完整性

数据实体和元素的命名约定应该一致地应用于每个数据库。此外，如果相同的数据必须驻留在多个数据库中，则应强制执行数据源及其引用之间的完整性。最终，这些数据元素在数据架构的概念设计中应该属于一个数据实体，然后可以根据业务需求进行协同和准确的更新或修改。

数据归档/保留政策

数据归档和保留策略往往直到生产的每个后期才考虑或建立，这造成了资源浪费、不同数据库之间的数据状态不一致以及数据查询和更新性能不佳。为了加强数据完整性，数据架构师应根据操作标准在数据架构中定义数据归档和保留策略。

隐私和安全信息

隐私和安全成为逻辑数据库设计的重要方面。虽然概念设计已经定义了哪些数据组件是敏感信息，但逻辑设计应该在数据库中保护机密信息，并通过有限访问、受限数据复制、特定数据类型和安全数据流来保护信息。

数据复制

数据复制是实现三个目标需要考虑的一个关键方面：1) 高可用性；2) 避免数据通过网络传输的性能；3) 解耦以最小化对下游的影响。但是，过多的数据复制会导致混乱、数据质量差和性能差。任何数据复制都应由数据架构师检查并应用原则和纪律。

数据流和管道

数据如何在不同的数据库系统和应用程序之间流动应该在这个层次上被明确定义。同样，此流程与业务流程和数据架构师概念级别中说明的流程一致。此外，数据摄取的频率、管道中的数据转换以及针对输出数据的数据访问模式应在逻辑设计的集成视图中加以考虑。例如，如果上游数据源是实时进来的，而下游系统主要用于聚合信息的数据访问，索引繁重（例如，频繁更新和插入的代价高昂），则需要在两者之间设计数据管道以优化性能。

3. 数据治理是数据架构持续成功的关键

由于数据架构反映并支持业务流程和流程，因此只要业务流程发生变化，它就会发生变化。随着底层数据库系统的改变，数据架构也需要调整。因此，数据架构不是静态的，而是需要持续管理、增强和审计。因此，应采用数据治理来确保在启动每个新项目时正确设计和实施企业数据架构。

结论

在成功的数据架构中，基于业务流程的概念设计是最重要的组成部分，其次是强调所有数据库和数据管道的一致性、完整性和效率的逻辑设计。建立数据架构后，组织可以查看哪些数据驻留在何处，并确保数据安全、高效存储和准确处理。此外，当一个数据库或组件发生变化时，数据架构可以让组织快速评估影响并指导所有相关团队进行设计和实施。最后，数据架构是企业系统的实时文档，保证是最新的，并提供清晰的端到端视图。