如何设计适合数字化转型需要的数据架构

现代组织需要一个模块化的数据架构来支持复杂的企业环境，同时为业务用户提供数据访问。以下是一些关键考虑因素。

一重视元数据的管理

数据架构不断发展以提供由元数据支持的数据自助服务

过去几十年来，数据分析架构最佳实践已经经历了多个时代，数字化转型强调了实现数据战略现代化和利用数据使用机会的必要性。这些时代包括：

2000年之前的时期—企业数据仓库时代：以企业数据仓库(EDW)的成功为中心的数据架构。
2000-2010—后EDW时代：这一时期的特点是碎片化的数据分析，数据集市依赖于数据仓库。根据你问的是谁，你得到的事实版本不同，因为每次数据集市整合都会导致另一个数据孤岛，从而导致分析碎片化和不一致。
2010-2020年—逻辑数据仓库(LDW)时代：这一时期通过通用语义层对数据进行更加统一的分析，从而可以访问数据仓库、数据集市和数据湖。这是当前的最佳实践。
2020年未来—活跃元数据时代：未来将看到使用所有相关数据源对数据进行增强分析，通过高级分析、推荐引擎、数据和人工智能编排、自适应实践和元数据分析来访问和启用。

数据访问和自助分析的广泛化正在推动当前从LDW时代向主动元数据时代的演变。首席数据和分析官(CDAO)同样希望将数据用例扩展到LDW无法处理的范围。其中包括主数据管理、企业间数据共享、B2B数据集成、合作伙伴数据共享、应用程序数据集成等。

但什么是元数据，它在这一演变中扮演什么角色？

元数据描述数据的不同方面，例如数据的上下文。它是作为数据在企业系统中移动的副产品而产生的。元数据有四种类型：技术元数据、操作元数据、业务元数据和社交元数据。这些类型中的每一种都可以是组织收集但不主动分析的“被动”元数据，也可以是使用相同数据识别两个或多个系统之间的操作的“主动”元数据。

主动元数据可以实现自动化、提供见解并优化用户参与度，并且是自助分析的关键推动者。然而，要实现其潜力，需要一个能够平衡可重复性、可重用性、治理、权威、来源和优化交付等要求的数据架构。

数据分析领导者看到了两种选择，可以将其数据架构从目前大多数运营的LDW时代发展到主动元数据时代。这些选项是数据编织或数据网格。这些独立概念的共同目标是为使用数据的每个人（包括数据科学家、数据分析师和数据工程师以及数据消费者）提供更轻松的数据访问。尽管许多数据领导者将数据编织和数据网格视为相互竞争的数据架构方法，但更准确地说，它们被视为互补。

二关注数据编织技术

DataFabric利用逻辑数据仓库时代的现有资产。

数据编织是一种新兴的数据管理和数据集成设计概念。其目标是实现灵活、可重用和增强的数据集成，以支持整个企业的数据访问。

对于许多组织来说，数据编织是逻辑数据仓库模型的自然演变，因为它利用现代化数据架构中的现有技术和元数据。数据编织设计不存在“淘汰和替换”。相反，它利用沉没成本，同时为新的数据管理支出提供优先级和成本控制指导。

数据编织从不同角度提供优势：

业务视角：使技术含量较低的业务用户（包括分析师）能够快速查找、集成、分析和共享数据
数据管理团队观点：数据工程师的自动化数据访问和集成带来的生产力优势，以及敏捷性的提高，达到每天/每周/每年更多地关闭数据请求
整体组织视角：更快地从数据和分析投资中获得洞察；提高组织数据的利用率；通过分析所有参与系统的元数据并提供有关有效数据设计、交付和利用的见解来降低成本

决定数据编织设计是否适合组织的两个因素是：元数据完整性和组织中的数据编织主题专业知识。具体来说，元数据太少的组织将看不到数据编织的好处。缺乏元数据还增加了对主题专家(SME)的依赖，他们可以帮助发现、推断甚至创作元数据，这可能会抵消数据编织设计相对较低的SME要求。

三关注数据网格技术

数据网格虽然有吸引力，但需要严格的方法

数据网格是一种允许分散数据管理的架构方法。其目标是支持定义、交付、维护和管理数据产品的工作，使数据消费者能够轻松查找和使用数据产品。数据网格架构基于将数据责任分散和分配给最接近数据的人并将该数据作为服务共享的概念。

数据网格最常见的驱动因素是：业务线(LOB)具有更多的数据自主权、减少对中央IT的依赖以及利用数据去中心化来打破孤岛（尽管可能需要在网格架构内进行一些数据集中化）。尽管其吸引力显而易见，但请注意以下先决条件和挑战。

数据网格架构尚未成为既定的最佳实践。

该术语与因组织模式、数据管理和技术实施而异的各种方法相关。组织驱动因素也各不相同。其中包括消除IT瓶颈，以及合理化由LOB主导的数据管道创建或由云现代化数据管理计划触发的孤立数据集。

数据分析领导者不应采用数据网格架构作为解决数据管理挑战的看似简单的解决方案。尽管它正式化了常见做法，但它放弃了LOB专家的数据责任，这可能会导致孤立数据使用激增。

数据网格的成功取决于LOB中的组织模式和数据技能。

如果各个部门的数据素养、自主性和数据技能差异很大，并且组织缺乏实施数据管理活动的能力，那么中央IT将需要提供更多支持——至少在一开始是这样。LOB可以通过创建新角色（例如数据产品所有者）来管理数据产品的定义、创建和治理，从而在数据网格环境中实现更大的自主权。然而，缺乏构建分布式数据技能承诺的组织应该避免数据网格。

数据网格架构、设计和技术实现差异很大。

数据网格架构实现通常基于云并使用共享存储和处理。然而，每个LOB用于数据交付、维护和治理的工具将根据用例以及生产者和消费者之间的合同而有很大差异。这些合同定义了数据产品的范围、SLA和运营成本，例如可用性、计算成本、访问并发性、治理和质量策略、上下文和语义。没有明确合同的组织通常会面临共享性和可重用性限制，这违背了开发数据网格架构的目标。

组织需要联合治理模型。

数据网格将数据治理的责任转移给领域应用程序设计者和用户。对于要自主构建和公开数据产品的LOB，它必须定义符合首席信息安全官(CISO)和首席数据官(CDO)或中央治理委员会的中央指导的本地数据治理和数据管理。在成熟的数据网格组织中，业务组织通过中央IT支持来实施自己的治理策略，而不是相反。

对于元数据不完整的组织来说，数据网格是一个可行的选择。只要他们拥有具有主题专业知识的数据架构师，他们就可以从数据网格开始并并行构建其活动元数据存储。

四构建灵活的数据架构

现代环境的复杂性需要灵活的数据架构

使用本地、云、多云、云间和混合部署进行运营的数据领导者将需要修改其现有的数据架构策略，以支持其当前和未来的复杂性。精心规划且强大的数据架构可确保新技术与现有基础设施相一致，并能够支持未来的需求，包括跨云提供商、SaaS解决方案和本地资源部署等的集成和互操作性。数据架构制定重点围绕以下方面考虑：

制定解决整个数据生态系统的策略。即使对于最初进行云部署的组织来说，随着时间的推移，发展成为混合和多云环境也是很常见的。建立优先考虑提供商的总体云战略可以管理其他云部署。这将减轻未经批准的云部署可能的数据架构带来的风险。
使数据要求与用例保持一致。分布式和复杂的用例现在正在推动可提供业务价值的更新创新，特别是通过启用自助数据访问。云的成功将取决于满足企业消费者用例的能力，这些用例很可能本质上是分布式的、靠近数据源并在边缘网络和设备上运行。
评估集成模式。快速的数据增长和自助数据访问加剧了以适当的带宽、延迟和吞吐量跨不同云和本地系统移动数据的挑战。评估集成模式，以确定可靠且高效的数据架构，该架构可以服务于不断发展的业务用例并满足数据合规性和主权需求。
采用开源和开放标准来进行面向未来的数据投资。熟悉云中的开源定价模型，包括计算和存储资源的费用。使用开放或提供商中立的标准，并了解开源数据存储的选项，以及使元数据可在企业环境中跨平台共享的开源元数据标准。最后，制定支持计划来解决开源解决方案的问题。