大规模数据管理的路径

原作者：Piethein Strengholt，Working @Microsoft.

过去几年里，去中心化架构已经成为管理大数据的新范式。目的是扩大团队之间的数据分布，追求更高的价值和更快的上市时间。

在本文中，我想阐述如何实现这样的联合设计。我们涵盖许多不同的事情。首先简短反思您的数据策略，以及您是否应该从集中式或分散式方法开始。然后我们将经历实施数据架构的各个阶段，从设定战略方向到奠定基础再到专业化的能力。

对您的数据之旅的简要反思

在加入数据驱动的浪潮之前，请确保您制定了适当的数据策略。无论您是从小规模开始还是要实施大量用例，如果没有计划注定会失败。我看到无数企业失败是因为不包括业务用户或缺乏高层领导的支持，无法让每个人都参与进来或阐明他们的战略。在开始实施任何改变之前，请确保您拥有清晰的愿景和地图，引导您走向正确的方向。

下一步是传达您的愿景、建立合适的团队、优化架构、制定执行计划、定义流程和选择用例。同样，让每个人都一致并致力于实现您的目标非常重要。在开发的初始阶段，从小处开始实施，但同时要牢记大局，因为您的目标状态架构必须包含所有用例。您需要数据治理功能来实施角色、流程、策略、程序和标准，以管理最关键的数据；需要主数据和数据质量管理功能来确保一致性和信任；需要元数据来跟踪沿袭、捕获业务上下文以及链接到物理数据；需要集成和分析服务来构建数据产品并将数据转化为价值。实现所有这些目标的推荐方法是全面审视您所需的构建模块。这些构建模块将在您的整个旅程中保持稳定，而底层技术将在未来几年发生变化。

确定了关键要素后，您必须确保自上而下的承诺。与您的业务利益相关者进行沟通和互动：提高意识和兴奋度。确保您的预期方法、业务目标和目标在整个组织中清晰且易于理解。一个好的方法是首先编制一个简短具有最大影响潜力的用例列表。确保每个用例都符合您的数据策略以及业务策略。在复杂性、财务成本、商业附加值、风险和运营可管理性方面对每个用例的可行性进行基准测试。之后，选择最好的候选人，从容易实现的目标开始：您的第一个用例应该不会太难实现，但同时应该提供足够的价值来证明工作的合理性。它应该为组织的其他部门树立榜样。其余的用例将在稍后介绍。

集中式还是分散式？

在您准备好迎接潜在的挑战并确定您的第一个工作负载后，就可以开始实际实施了。此时，您需要决定选择集中还是分散的方法。

如果您的公司的数据管理成熟度较低，那么一开始就采用集中式方法更为合适。为什么？复杂的转型需要文化转变、技能提升、建立成熟的自助服务能力、打破孤岛和政治界限以及共享知识。不应低估这些活动的复杂性。因此，如果您的组织还不具备解决这些问题的成熟度或规模，请考虑集中化而不是分散化。随着您在旅程中取得进展，加入更多用例，并增强您的数据管理和自助服务功能，允许在集中化之后进行联合。

如果您的公司已经具有高水平的数据管理成熟度或者是分散式组织，那么您可以从分散的数据管理方法开始。然而，为了协调分散的团队，您需要制定标准和原则，并为共享功能做出技术选择。这些活动需要在中央层面进行，需要出色的领导者和优秀的架构师。在本章末尾讨论企业架构师的角色时，我将再次讨论这些要点。

除了出发点之外，集中和分散还需要考虑其他方面。首先，您应该确定旅程结束时的目标。如果您预期最终状态是分散式架构，但决定从集中式启动，则构建该架构的工程师应该从一开始就意识到这一点。考虑到更长期的愿景，工程师可以使功能的耦合更加松散，从而在以后的某个时间点更容易进行权力下放。其次，您应该确定哪些功能您打算保留在中央控制之下，哪些功能您计划稍后下放。预先明确这一点将避免以后的大量争论和政治内讧。

让它成为现实

在组织层面阐明数据战略和目标后，您的下一步活动旨在使事情成为现实！根据我的经验和客户的成功案例，我的建议是使用分阶段的方法并从小处开始：建立一个增值假设，从一个或有限的用例开始，获得一些构建什么的经验。

请注意，这里讨论的目标是描述一般数据旅程的主要阶段，让您了解会发生什么。

机会阶段：设定战略方向

加入第一个域，不一定要规划出所有业务能力、描述数据域并将其与组织结构保持一致。相反，您在此阶段的目标集中于学习概念如何运作以及如何转化为实践。为此，我建议选择一个相当简单的用例，以一个或两个源系统作为起点。您将使用这些来源作为数据产品开发的输入，然后将这些数据产品直接提供给消费者，将数据转化为价值。不过，您还不需要关注数据价值创造能力，这些稍后会出现。现在，您应该专注于新架构的源系统方面。

第一阶段是确定您的团队需要具备什么样的心态，才能获得数据所有权并构建第一批数据产品。在此阶段，中心团队负责监督其他团队，指导和提供专业知识，而领域团队则编写数据管道、调试问题并从源头修复数据质量问题。在此阶段，所有团队都需要密切合作，以了解共同的需求，因为必须就存储服务、ETL 工具、安全性、数据目录等做出许多集体决策。

此阶段的第一步如下：

• 选择第一个用例并确定一个业务团队，该团队是构建第一个数据产品的良好候选者。该业务团队最好能拥有开发第一个可交付成果所需的所有工程技能。如果没有，数据平台团队可以协助业务团队。
• 定义一个范围明确但有限的项目，最好可以在几个月内完成。成立一个由高级代表组成的小型计划委员会，以提供所需的自上而下的支持和协调。
• 确定数据平台团队的（潜在）成员，他们致力于整个流程。该团队将协助领域团队，该团队将负责构建用于生产数据产品的第一个数据管道。

从数据架构角度来看，我鼓励您从一个云基础设施着陆区和一个数据管理着陆区开始。接下来，仅提供捕获、存储、转换和编目数据所需的服务。放下不需要的东西，专注于重要的东西。

对于您的解决方案设计，请考虑采用 Lakehouse 架构。虽然这种设计最初可能看起来像集中化，但它带来了许多好处：它是一种经过验证的、常见的且易于理解的模式。易于设置，并且简化了基础设施的管理。下图显示了该架构最初的外观示例。它是一个小型架构，专为单个域而设计。

最初的Lakehouse架构

刚刚开始旅程时，该架构仅使用一些基本服务。在初始阶段，该领域的数据工程师与数据平台团队的成员进行交流。他们共同确定范围并分析构建第一个数据产品所需的服务。

这个设计的目的是为了创建一个基础，以便在规模上构建数据产品，支持计算数据治理的数据所有权和自助服务目标。首先，领域团队、产品所有者和数据工程师紧密合作，使数据可用。他们从源系统中提取数据并将其输入到铜层。团队使用中央平台团队提供的集成服务。接下来，他们选择相关数据并将其转换为几个用户友好的数据集，例如使用笔记本或数据转换服务。在这些活动中，数据可能会经过多个层次：银层用于中间数据；金层用于功能上协调且可消费的数据。在所有转换完成后，数据目录扫描所有数据。可选地，它还可以扫描集成服务以获取血统。扫描配置在中央级别进行，因此由中央平台团队或数据治理团队处理。最后一步是使数据可用。在此之后，其他团队可以将此数据用作其分析用例的输入。

数据目录的重要性

不要低估组织目录的复杂性。当您开始实施数据目录时，不要立即扫描所有源或域。相反，仅扫描新生态系统一部分的域。一次一个接一个地加入域。您将在实践中了解到，业务领域和应用程序领域之间的一致性，取决于业务功能是共享还是独占使用。要建立良好的结构，首先以逻辑方式对数据源和数据平台进行划分和分组。关键点是，来自每个数据源或应用程序的每个资产只能存储在目录中的单个位置。这意味着，在技术层面上，您需要将数据资产与应用程序域相关联。然后，在此应用程序域级别上，您可以调整职责，将管理员、数据源管理员和管理者角色分配给管理数据库、应用程序、数据产品、数据管道和其他服务的相应人员。接下来，需要对描述业务意义上的数据、应用程序和域含义的信息执行相同的分组和排序活动。通过研究业务能力并寻找能够实现共同业务目标的人员来确定您的业务领域。分配术语表所有者和数据管理员角色来管理元数据，例如描述和术语表术语。最后，调整应用程序和业务域，要求域用户在应用程序域级别管理的元数据和业务域级别管理的元数据之间创建关系。管理者角色分别分配给管理数据库、应用程序、数据产品、数据管道和其他服务的人员。接下来，您需要对描述业务意义上的数据、应用程序和域的含义的信息执行相同的分组和排序活动。通过研究业务能力并寻找能够共同实现共同业务目标的人员来确定您的业务领域。分配术语表所有者和数据管理员角色来管理元数据，例如描述和术语表术语。最后，调整应用程序和业务域，要求域用户在应用程序域级别管理的元数据和业务域级别管理的元数据之间创建关系。管理者角色分别分配给管理数据库、应用程序、数据产品、数据管道和其他服务的人员。

在初始阶段，你的能力不会有很高的成熟度，也可能会有许多手动流程，进入下一阶段时，您需要将这些流程自动化或提供自助服务。在下一阶段，元数据也变得更加重要，因为在 Excel 中有效的方法将不再适用。

在您自下而上地实施第一个用例后，是时候通过向组织的其他人员展示您的结果来征服您的第一批（业务）利益相关者了。不要羞于展示您的成功并展示使用数据的好处。这些活动不应被低估。它们对于确保高层管理人员自上而下的承诺至关重要。随着您的进步，计划应该成为一个角色模型，停用和清理遗留数据管理平台或系统，停止不符合新数据管理策略的类似项目。完成所有这些后，就可以收集第二阶段的新用例需求。

转型阶段：奠定基础

将第一个用例交付到生产中后，一切都与扩展、添加更多数据域和完善架构有关。在此阶段，清晰地了解全貌非常重要。现在您的业务能力应该很清晰，包括与人员、流程和技术的协调。您应该知道哪些域拥有哪些应用程序，以及它们负责什么。您还应该知道哪些潜在的新数据产品可以服务哪些新用例。在此阶段，您将制定预算计划、路线图、业务附加值和运营模式。逐渐扩大规模时，这些活动很重要。

考虑到高级目标状态，您的下一步是定义最适合您的组织的域和着陆区拓扑。我建议您协调包括处理、存储和编目数据服务的蓝图；发布元数据、执行政策等等。接下来应该研究域之间的数据流量。需要根据分析做出多项设计决策。例如，如果许多域需要来自许多其他域的数据，则不建议使用高度分散或细粒度的域拓扑，因为它会导致复杂性和管理开销。在这种情况下，使用集中位置来管理共享数据产品的受控拓扑通常是更好的选择。如果域之间流动的数据量差异很大，您还可以实施集中管理和点对点分布式数据的混合方法。在这种情况下：

在您的第一批域上线后，考虑从初始阶段学到的教训是很重要的。您可能会认为域团队想要更有能力和自主性。第一批数据产品并不太复杂：您从源系统中提取数据，通过几个数据管道将其转化为更易于消费者访问的数据。问题在于，必须反复执行这个过程，并在监管和控制的条件下进行。为了做到这一点，需要将自动化和更多的先进能力添加到数据产品开发过程中。例如，您可能想要添加一个数据质量框架，用于验证模式和数据质量，或者为 ETL 服务设定一个标准，您的域必须遵守，以便在构建新的数据产品时遵循。不需要编写更多的笔记本或使用一次性、无法重用的解决方案，而是需要提供实现这个标准功能的蓝图和模式。

下图展示了下一阶段架构的外观。在这个更新的架构中，您可以看到添加了实时数据摄取功能、元数据驱动框架、日志数据库和虚拟化访问。

更新的Lakehouse 架构

接下来，需要对数据管道进行类似的改进。最有效的扩展和灵活性方法是使用参数化、元数据驱动的管道。因此，您可以创建一个通用且可配置的管道，该管道将在运行时从数据库等检索配置，而不是使用硬编码值重新设计和手动创建新管道（具有自己的数据源、选择、转换和输出）或代码存储库。因此，参数化工作流程将使用领域团队提供的元数据输入和条件。中央平台团队的作用是通过将所有内容纳入基础设施蓝图，使用即服务模型提供所有这些功能。

团队之间的合作

您可能还会发现，领域团队正在寻求团队之间更主动的合作。他们不想依赖中央平台团队作为在提供者和消费者之间来回传递消息的中间人。例如，当新消费者想要使用提供者的数据时，或者当提供者存在数据质量问题或将延迟交付其数据。相反，平台团队应该实施中央监控服务和控制框架，以实现提供商和消费者之间以行动为导向的交互。您可能想要添加一个中央日志记录存储，或者一个良好的监控服务来检测问题并使用警报规则、通知或事件主动通知用户。下图中可以看到多域架构的示例。

为了支持添加新域，请使用数据可观测性、数据质量、数据转换和自动化的标准化服务来补充您的架构

添加域时建议的方法是先关注架构的源系统端一段时间，然后再扩展消耗端。为什么？通常，数据消费者比数据提供者多得多。此外，面向消费者的分析服务很复杂，也引起了更多的关注。因此，在添加大量消费者之前，保证新数据产品的稳定且可扩展的交付至关重要。如果过快地将注意力转移到消费端，可能会看到所有团队一次又一次地尝试解决相同的数据工程问题。导致整个组织失去对架构的信任。因此，采取的每一步都要确保正在增加业务价值，

在提高数据产品开发效率后，实施第一组计算数据治理控制。例如，在未先将数据链接到数据所有者的情况下，不允许共享数据。为此，您需要使用数据治理解决方案提供的工作流程。目标是设置护栏，让领域团队能够更加自我支持，而不会在不知不觉中造成伤害。在此阶段，中心团队的角色发生了变化。他们监督需要什么帮助，并在需要时介入。因此，中心团队不是自己执行所有与数据治理相关的活动，而是培训和指导其他团队。另外，这是中央团队需要开始思考的一点：“控制是好的；控制是好的；控制是好的”，信任更好。

迁移或遗留场景

在将新的用例和领域引入您的架构时，您可能会遇到迁移或遗留场景。例如，遇到消费者需要几年前的历史数据的情况。在构建新的数据产品架构时，您将了解到历史数据仅在将第一个数据产品加入新架构时才可用。因此，如果需要入职期之前的历史数据，那么您将有一个空白。要解决此问题，请从其他环境中提取或一次性复制历史数据。例如，如果数据仓库保留了过去七年的数据，您可以使用该数据构建遗留数据产品，然后将该遗留数据产品与输入到新架构中的传入数据相结合。这将为域名提供全面的信息。但请注意，将历史数据与新数据相结合并不总是那么容易。经常需要匹配字段、删除重复项、清理数据或编写业务逻辑。进一步扩展时，需要通过使域能够交换或直接共享数据产品来互连域。为此，需要设置互操作性标准并实现查询服务。考虑流行的文件格式（例如 Parquet 或 Delta）和（无服务器）SQL 服务，以允许其他域访问和浏览数据产品。需要通过使域能够交换或直接共享数据产品来互连域。为此，您需要设置互操作性标准并实现查询服务。考虑流行的文件格式（例如 Parquet 或 Delta）和（无服务器）SQL 服务，以允许其他域访问和浏览数据产品。您需要通过使域能够交换或直接共享数据产品来互连域。为此，您需要设置互操作性标准并实现查询服务。考虑流行的文件格式（例如 Parquet 或 Delta）和（无服务器）SQL 服务，以允许其他域访问和浏览数据产品。

优化阶段：能力专业化

基础建立后，就可以迭代优先的业务用例并进一步提升专业化能力。此阶段的关键目标之一是将中心团队的所有支持活动转移到领域团队。寻找效率低下的地方，并尝试通过自助服务和自动化来解决这些问题。为了加强您的组织，请指导团队，使他们能够更有效地管理数据和相应的数据管道。允许他们自行加入并自行订阅数据产品。部署允许自行注册和维护元数据的服务。例如，部署可以轻松与域的 CI/CD 流程集成的 API。

对于架构的下一次迭代，您将专注于实时数据处理、消费准备、安全性、MDM 和精选数据的分发。尝试使用蓝图和服务标准化架构的消费端。请记住，数据的使用是多种多样的：可能存在多种变化。为了保持控制力，请通过一次推出一项新服务来逐步扩展。对于每项新服务，请先评估其需求，然后再将其分发给您的域。

下图显示了更新设计的抽象示例。

随着架构的采用不断增长，将会添加新的服务

该解决方案架构的一个关键问题是许多服务尚不支持联合工作方式。中央团队必须专注于通过集成服务以及提供自助服务和自动化功能来缩小这些差距。他们是在偏差、工具和技术要求之间进行仲裁的人。他们拥有与编程框架、ETL 服务和存储相关服务相关的所有选择。

为了管理数据可重用性问题和一致性，请寻找使用率最高的数据产品。您最有可能遇到的是多个领域抱怨数据太难与其他领域的数据集成和组合。因此，寻找跨团队执行的重复协调和质量改进活动。如果您看到许多重叠的活动，则相关数据产品可能是主数据管理的候选者。或者，您可以分离出通用（可重复）集成逻辑，并要求一个数据产品团队使用客户/供应商模型获得数据的所有权。

作为数据共享体验的一部分，您的数据产品团队应该能够描述哪些数据产品可用于哪些目的。域应该能够与中央治理团队密切合作，管理对其拥有的数据的数据访问控制。不幸的是，在撰写本文时，我不知道有任何开箱即用的解决方案可以为您的团队带来良好的体验。如果想通过易于遵循的工作流程和自动创建策略来支持您的团队，请考虑自己构建一个小型数据契约框架，该框架使用工作流程部署面向消费者的（安全）视图。该框架可能包括指向业务语义以及数据质量和服务级别协议的指针。

当进一步扩大规模时，明确数据治理结构非常重要。因此，需要摆脱定义不明确的数据角色，转向具有协调一致的流程的清晰结构。根据组织的规模，可能有多个互动的管理机构和数据产品团队。

不同数据治理机构和领域团队如何协同工作的示例

在顶层，治理机构管理战略监督，共同努力推进企业的愿景和目标。因此，高层设计、路线图和大型项目的决策对新架构有很大的依赖性。在这些机构中，通常期望有首席数据官、首席架构师、高级领域所有者、其他执行管理成员（或代表）。

在底部，域团队在域主体中分组在一起，用于管理用例和依赖项、加入新数据和返工问题。在此过程中，他们可能会收到其他团队的反馈和要求。因此，所有物体之间都存在相互作用。例如，一个领域团队可能需要另一领域团队的调解或项目管理团队的战略决策。

在制定出治理结构并设置会议节奏以同步和协调规划和反馈循环后，就可以锦上添花了：智能数据结构和数据市场功能。这里还有一些空白需要填写，因此要么需要等待、遵守，要么自己使用本地应用程序组件来解决差距。

数据运营和治理

向数据运营和良好治理的转变主要是一种文化转变。对于这一转变，需要一个中央团队来牵头制定标准并开发配置模板和蓝图。该团队还负责设置辅导、创建培训材料、组织临时会议等。不要低估这些活动的重要性，他们可能需要额外的人员配备。

除了架构之外，所有这些变化都很重要。企业架构在协调所有这些活动方面发挥着重要作用。企业架构师必须被视为能够指导开发团队实施未来架构的领导者。他们必须务实、现实，同时提出愿景激励每个人追随。他们必须掌握技术并在安全、云基础设施、软件架构、集成和数据管理等不同领域表现出色。企业架构师还必须对业务边界有非常深入的了解，并知道如何使用现代集成模式和业务架构来解耦它们。

您的企业架构实践必须在长期目标和实用性之间找到平衡。这种需求导致了企业架构框架（例如开放组架构框架的 TOGAF 标准）的消亡，因为它们形式化长期存在的静态状态不太适合 DevOps 和 DataOps 的新世界。是的，你需要描绘大局，也需要放弃“监管”心态。现代企业架构师应该成为社区领导者，主动定义最小可行产品，组织设计和白板会议，并讨论和翻译客户需求。将细节留给团队，但在出现问题时成为权威专家。

最后的话

下一代企业数据环境将以全新的方式进行组织。在我看来，未来几年数据将更加分散——数据所有权也将更加分散。企业需要学习如何最好地平衡集中和分散的必要性。

最后的建议：不要紧张，飞行是最安全的旅行方式！在数据世界中可以发现很多乐趣。我们才刚刚开始。