《流式Data Mesh》第八章：构建一个去中心化的数据团队-灵析社区

第八章：构建一个去中心化的数据团队

公司需要一个合理的战略，以从本地架构转变为基于云的架构。大多数公司已经看到角色的发展和专业化程度提高，特别是与数据科学、数据工程和机器学习工程相关的角色。所有这些专业在云生态系统中处理数据方面起着关键作用。

此外，过去几年间对数据专业人员的需求急剧增加。加上新一代受过数据基础设施教育的专业人员数量稳步下降，导致了人才缺口，即没有足够的专业人员来满足这些角色的需求。这个缺口导致了对数据基础设施领域中的软件（在第7章中介绍）的持续需求，这些软件可以帮助自动化关键任务，减轻人才短缺的负担。技术能够解决一些现有的差距，但并非全部。

因此，企业需要寻找提高现有技能集生产力的替代方案。由于这些技能集需求量很大，通常不能通过额外的招聘和人员增补来解决。构建一个去中心化的数据团队有助于填补这个缺口，通过在组织内部调动资源，提供支持流数据网格方法所需的技能集。在本章中，我们将回顾传统的数据方法，以及其中的一些问题，并将其与一种将资源与数据对齐的新方法进行对比。这种新方法将业务和技术专长结合起来，形成支持开发与业务目标相一致的高质量数据产品的结构。

传统的数据仓库结构

数据工程角色传统上由熟悉数据库端的SQL、大数据生态系统中的MapReduce，并且通常了解如何将数据批量从操作层移动到数据仓库的人员承担。随着机器学习和数据科学在近年来变得更加普遍，数据工程师的角色变得更加繁重。这些角色变得更加庞大，并更加专注于DevOps、MLOps、数据科学和机器学习工程等领域。因此，“数据工程师”这个标准术语现在已经变得非常负荷过重，需要创建新的角色。在构建一个去中心化团队时，我们将介绍这些新角色，并讨论它们对团队的整体影响。

图8-1展示了一个典型的数据仓库环境中的组织结构。在C级管理层下面有两个团队：

支持日常运营的操作团队
负责管理数据平面中数据仓库的团队

在典型的数据仓库项目中，目标是将数据从操作源带入数据平面，然后将这些数据重构为另一种形式。行为洞察、数据科学和分析团队（此处未展示）从这个集中式数据仓库构建内容。

这种方法非常常见，但存在许多问题。最近的一项研究显示，大约80%的数据仓库未能实现其既定目标。一些原因涉及数据本身（脏数据、数据孤立、数据访问、监管限制等），但其中一个主要因素在于组织结构本身。简单来说，数据仓库组织将数据工程师和ETL开发人员引入，从操作存储中获取数据，并使用新技术将其加载到新的表结构中。这些人经常发现自己处理的是他们不熟悉的数据，最初缺乏了解数据用途的业务背景，以及原始事务系统的工作原理的知识。

这导致业务和操作团队之间进行许多会议，以确定将这些数据带入数据仓库的要求。数据工程团队，通常是数据平面团队的一个子集，随后承担起创建能满足所有用户需求的数据结构的负担，往往在孤立环境中做出关键设计决策，改变基数和分布，或者原始数据集的原始含义发生变化。这些数据结构可能过于泛化，不符合业务用户的确切需求。

随着数据仓库项目的进行，业务必须如常进行。这意味着操作报告仍然是从事务性操作数据库生成的，希望在数据仓库完成后将这些活动迁移到数据仓库中。数据科学家通常有自己的流程（通常也有自己的数据工程师），以获取满足其需求的数据。一旦数据仓库项目完成，用户常常会发现基数和分布发生了变化，数据形式也不再熟悉。此外，权限也开始发挥作用：曾经可以访问日常任务所需数据的团队由于“安全原因”无法查询数据仓库（或数据仓库中的表）。

这些问题以及其他问题导致团队寻找变通方法和替代数据源，以规避数据仓库。组织创建一个管理的、单一的数据真实版本的目标常常变得模糊和分散。实际上，一个组织开始创建许多真实源，每个源都有其自己的“独立”ETL和数据工程步骤。在更严重的情况下，团队还可能建立自己的基础架构来创建和维护事务数据的影子副本，进而引发更多关于安全性和数据质量的问题。

引入去中心化团队结构

在图8-2中，我们介绍了去中心化团队的概念。这个结构拥有与数据仓库组织相似的资源，但重新组织这些角色，使其更紧密地与三个领域相关联：(1) 数据专业知识，(2) 业务专业知识，以及(3) 基础架构专业知识和与控制平面相关的数据转换。

在这种新的网状结构中，整个组织更加紧密地与数据本身联系，使领域内的资源直接与提供给业务用户的数据相一致。在流式数据网格中，领域团队负责领域内数据的所有方面，包括创建、摄取、准备和提供数据。通过领域联合所有权，业务可以保持每个领域的原始上下文，因为团队对其数据非常了解。领域团队的责任从中央基础架构团队转移，并专注于为组织提供有价值的数据产品。

去中心化数据团队的一个关键特征是需要从传统的集中式方法转变为端到端的流程，其中数据产品成为多个组织技能集中的焦点，以实现有价值的成果。去中心化组织将为担任传统技术角色（架构师、分析师和数据工程师）的团队成员确定明确定义的能力归属。团队绩效将根据他们作为专注领域团队一部分的工作得到更合适的衡量和奖励。随着数据产品开发团队的形成，团队变得多学科，以满足关键组织需求（并在从一个团队转移到另一个团队时增加价值的能力）。这些去中心化领域团队虽然专注于其领域内的内容，但使业务能够从消费者的角度思考，确保优先考虑质量，并确保数据产品满足客户需求（在这种情况下，是其他领域的数据消费者）。

领域所有权原则进一步加强了数据网格的第二个原则：“将数据视为产品”。因为每个领域拥有自己的数据，并负责为其消费者生成和开发数据，所以这些数据应该具有高质量、接近实时和可信赖的特点。最重要的是，数据产品及其领域必须足够可靠和可信赖，以成为创建新数据领域和产品的领域互操作性的源头。组织的思维方式需要从创建一个集中式团队来为所有数据请求提供服务的模式转变为一个领域内生成的数据可以被其他领域使用的模式。让我们来看一下去中心化数据团队带来的四个主要优势领域：赋权人员、工作流程、促进协作和数据驱动的自动化。

赋权人员

发展一个去中心化的数据团队对组织的几乎所有方面都有重大影响，包括结构、角色、责任、业务词汇、流程、协作模式和技术。产品负责人确保领域消费者处于产品开发的中心位置。他们需要获得权威来做出关键决策，并直接与客户进行互动，避免不必要的障碍。直接与客户互动确保需求和优先事项能清晰地传达到领域开发过程中，进而推动敏捷性、提高生产力和客户满意度。

领导者需要适应变化，因为一些角色从项目的前线领导转变为由产品负责人领导的领域开发过程中增加价值的能力管理。团队成员需要了解自己的具体角色，并适应在多个项目中更灵活地工作，发挥核心技能，在所分配的领域内创造价值。

当采用去中心化团队方法时，高级领导层需要积极且明显地领导文化变革。一位优秀的领导者必须明确、达成共识并采纳数据聚焦文化所需的价值观和行为准则。领导者需要挑战和解决干扰传统集中化团队协作的行为，确保他们在领域内工作，为组织通过为消费者提供最大价值而服务其客户群体。

工作流程

在去中心化团队中，新产品和服务是与最终消费者（即客户）密切互动开发的，而想法和原型在开发过程的早期就进行了现场测试，这样团队可以迅速获得改进的反馈意见。这需要参与和建立关系的技能。在各个职能部门内部、跨多个地区，并使用通用的共同语言部署标准化流程，使团队能够清晰地相互沟通，增加了流动性和扩展性。当需求变化需要快速行动和解决方案时，通过将人员虚拟地转移到最需要的地理位置，可以产生全球影响。团队需要可衡量的流程绩效目标，以帮助追踪客户满意度并确定如何改进流程。鼓励团队成员进行实验和迭代，寻找改进流程和客户结果的方法。在整个组织中，鼓励“快速失败”，支持（并奖励）创业精神。

促进协作

在创建去中心化团队时，从一开始就需要着力促进团队之间的紧密协作。具备强大的产品负责人，能够围绕跨领域的价值主张调动多技能团队的能力是至关重要的。产品负责人需要具备足够的知识，能够与来自IT、销售、市场营销和数据交付等不同团队的成员合作，并理解他们提出的问题。如果要让自主管理的团队能够识别持续改进并在团队之间共享知识，信息和数据的透明性变得尤为重要。

于数据驱动的自动化

高级分析能够实现基于数据驱动的自动化。通过先进的技术，组织可以自动提取洞察并提供建议。这种技术为改善决策提供智能支持，可应用于业务的许多方面。数字工具可以通过重构将操作数据转化为数据产品的过程来实现。机器人流程自动化（RPA）是一种新兴技术，可在涉及从多个系统汇总数据的流程中取代人力。此外，由数据科学家和机器学习专家构建的模型现在可以实时开发、部署和维护。虽然这些工具可以在传统的数据架构中使用，但分散团队的方法允许域团队在这些主题领域内使用这些工具来改进产品交付。由于分散团队负责其服务的域的范围，自动化工具可以用于解决特定问题，而不是应用于整个数据集的更广泛范围。

在解释新角色之前，需要了解数据作为产品的几个方面。以下是对这些原则的简要概述。随着我们介绍新角色，我们将阐述这些作为数据产品的方面：

一个域可以拥有一个或多个数据产品。
数据产品需要实现互操作性。它们可以使用其他数据产品的输出并生成自己的输出。使用彼此之间的多个数据产品将形成一个数据产品网格。
技术实现，例如数据来源、数据建模和ETL，将在数据产品之下进行抽象。数据产品团队本身将有权在域级别设计和实施技术解决方案。
一些数据产品将与操作源系统对齐。一些数据产品将消耗来自与源对齐的数据产品以及其他数据产品的输出，以生成增值输出。
一些数据产品将与特定的业务需求对齐，例如行为洞察报告或数据科学。

数据领域中的新角色

在数据领域中，需要创建一些新的角色来适应组织对数据的新思维方式。其中最重要的角色是域产品负责人。该角色的职责包括：（1）制定数据产品的愿景和路线图，（2）确保数据产品在组织内满足消费者需求和实用性，（3）确保可用性、质量和可追溯性，并维护服务水平。

在数据网格中，数据工程师的角色是必需的，但与传统意义上的数据工程师不同。对于流式处理的用例，标准SQL和ETL被使用KStream API与Kotlin作为核心，或者使用像ksqlDB这样的工具进行转换。现在，数据工程师需要理解如何在这种范式下正确工作，将数据转换应用于流式数据集而不是关系表。在本节中，我们默认理解数据工程师是指域数据工程师。虽然数据工程师服务的源和目标不同，但角色本质上是相同的：可从流式数据源中消费操作源数据，并将转换后的数据发布为为消费者提供服务的数据产品。这需要具备数据转换技能，以及在设计和创建标准化、有版本控制的API方面的扎实背景，这些API可以作为数据产品发布到中央仓库。

数据平面中的新角色

数据网格和流数据网格的一个优势是将使数据可用的责任从中央基础架构团队转移到其他团队。这使得基础架构团队可以专注于创建可靠、可用和实用的自助服务资产，以赋予领域团队更多的权力。而领域团队则专注于访问数据及其转换，基础架构和自助服务工具由数据平面团队负责管理。

数据平面团队由数据专家和数据平面数据工程师组成，他们熟悉源系统，并能够通过连接器将其发布到流数据网格中进行管理。这个角色负责可靠、高性能和可扩展的连接，从事务源中提取数据，并将其发布到领域中。该角色创建来自源系统的标准输入和输出接口，可以是流或API的形式。

网格可靠性工程师的角色专注于网格的整体性能和可靠性。通过监控、维护和响应网格部署的性能和利用率指标来实现这一目标。该角色可能负责扩展或管理分层存储、水平扩展数据产品，并向领域经理和产品负责人报告使用指标。此外，该角色还负责整体部署的稳定性。例如，如果数据产品部署在Kubernetes上，流也可以部署在Kubernetes上。网格可靠性工程师确保处理过程可靠，并能在基于Kubernetes的集群上进行。

流数据网格是一个以人和工具为中心的自助服务平台。这引入了应用工程师的角色。需要新的工具，提供简单的用户界面来定义和注册事件和事件模式，提供流平台的配置，提供CLI接口来配置数据流管道，并测试转换脚本。此角色的人员将在一个高技能团队中工作，构建和维护领域团队使用的工具集，以及为支持控制平面的团队提供工具。通过创建这些工具，随着时间的推移，减少了对高技能控制团队的需求。需要指出的是，最终该团队可能主要由通才组成，只有少数专家。

此外，应用工程师的角色还负责维护和部署操作和分析应用程序底层的技术。这包括常用工具，如Jupyter笔记本，以及用于模型训练的TensorFlow、XGBoost、Keras和PyTorch等库。

数据科学和商业智能中的新角色

流数据网格旨在作为流技术和数据科学之间的中间层，以满足分析模型和特征存储的需求。因此，许多角色的出现是为了为数据科学提供支持。在定义了所有这些角色之后，数据科学团队将扮演重要角色，因为他们接触到统计学并能够正确应用统计学。数据科学家和软件工程专家Josh Wills将科学家定义为“在统计学方面比任何软件工程师更擅长，在软件工程方面比任何统计学家更擅长的人”。这个定义很好地捕捉了现代数据科学家日常工作的真实本质。数据科学家通常不是优秀的软件工程师，也不是百分之百的统计学家。然而，数据科学家需要了解整个过程的各个方面，以完成以下任务：

整合适当的数据以建立模型
将数据转换为构建模型所需的有用格式
对数据应用适当的统计预处理步骤
选择适当的算法来预测结果
理解目标部署平台

这是一个艰巨的任务。真正的数据科学家必须能够有效地（而非最佳地）在这些领域应用知识，以便将结果呈现给业务部门进行评估，并理解适用于数据科学这个整体概念下的所有操作组件。数据科学家需要了解如何有效地应用ETL技术来整合数据并将其转换为模型所需的有用格式。数据科学家执行的许多任务更适合由数据工程师来完成。然而，一位通用的数据工程师可能对数据科学家希望如何组织数据不太熟悉。这就引出了一种新的角色，即数据科学工程师或机器学习工程师。

数据科学家需要在首次整合和转换数据时对数据应用适当的统计预处理步骤。这需要一个比数据工程师更专业化但又不完全达到数据科学家水平的角色。这个角色可以由数据科学工程师担任，也可以分为新角色，即特征处理工程师。在数据科学家的指导下，这些特征处理工程师理解所需的数据转换，并在数据网格中具备技术能力来实现它们。模型的数据准备通常是整个过程中被忽视的一个方面，并且通常被视为一个不需要过多关注的神秘黑盒子。在大多数业务人员的想法中，数据输入模型，结果出现。实际上，这是一个复杂的过程，需要深思熟虑和关注。

分类变量通常被盲目地输入到一种独热编码转换中（将分类变量转换为每个组合出现的零和一的向量）。然而，这种方法常常被过度使用，既无法有效地预测结果，又在模型训练和推断中效率低下（有时甚至在计算上不可行）。对于分类变量，通常需要适当的降维处理，有许多可以应用于分类变量的技术，例如：

目标编码（Target encoding）
使用深度学习框架进行训练的嵌入（Embeddings）
主成分分析（PCA）

此外，任何类型的降维处理都需要用人类可理解的方式进行解释，以便供业务分析师和最终用户理解。

例如，PCA 在解释超过前两个主成分之后变得非常困难。训练的嵌入也很难解释（虽然较为容易）。目标编码在其最简单形式中是一个分类值与已知结果之间的概率关系。虽然能够解释这些转换很重要，但选择适合构建模型的正确方法也同样重要。当数据科学家确定模型需要哪种变量编码类型时，特征处理工程师必须了解如何实施这个解决方案。

就像分类变量需要适当处理一样，数值型输入也需要。连续变量中的数据通常需要进行标准化或归一化处理（这两个概念完全不同），以便正确训练模型。一些模型框架会自动处理这一点（例如XGBoost），而其他一些则不会。此外，地理坐标虽然是数值型的，但通常需要特殊处理，因为这些数据点之间存在已知的距离关系。在数据科学（通常还包括统计学）的指导下，可以对数据应用适当的转换，以最好地适应模型。

最后，在转换时还需要考虑输出变量，具体取决于模型的期望结果。例如，如果正在训练模型来发现异常的保险理赔，那么因变量（或结果变量）可能需要以标准化术语来表示，以便可以用标准偏差的单位来测量实际值和预测值之间的距离。此外，任何模型中的因变量通常需要代表高斯分布，以使模型不必在计算上努力寻找关系。在数据科学家的指导下，特征处理工程师可以最优地编排和应用适当的工程技术来生成所需的模型输入。

虽然数据科学家或机器学习实践者需要能够应用适当的模型，但另一个重要方面是扩展了DevOps的概念，创建了MLOps角色。该角色将模型及其在模型构建阶段产生的所有构件，创建一个流水线，以正确应用所有必需的转换，实现适当的实时推断和批处理推断。虽然由数据科学家和特征处理工程师开发的模型训练过程有责任将其转换与模型本身捆绑在一起（以及适应统计数据和其他相关值），但MLOps必须以与模型训练相等的方式应用这些转换。同时，在数据科学家的指导下，还需要适当处理以前从未见过的值。

最近，“流水线”这个术语在MLOps和数据科学中变得非常常见。在模型构建和推断的情况下，存在数据转换流水线和模型部署流水线。部署流水线本身通常可以使用标准的敏捷开发流程构建，并使用常见的工具（如Jenkins或Azure DevOps）进行部署。

在部署模型时，其相关转换必须发布到数据血统库，并记录为已知转换。这消除了对已应用的转换及其对结果的潜在影响的猜测。无论如何，了解模型所采取的步骤必须对任何使用模型的用户都是透明和可查看的。

业务智能工程师是另一个角色，需要结合来自操作平面的数据源知识以及由数据科学团队生成的分析数据产品的暴露。在这个角色中，需要结合数据科学和通用流数据工程师的技能。随着时间的推移，控制平面团队可能会创建一些自动化集成的工具，从而减少对专业角色的需求。

表8-1提供了这些角色的摘要。角色的对齐仅供参考。可以根据个体业务需求进行定制。

总之，通过将这些角色嵌入到领域团队中，领域团队能够自给自足地开发、部署和维护其数据产品。工程师、分析师、领域专家和技术专家能够共同合作创建世界级的数据产品和解决方案。一方面是技术专家，另一方面是业务背景的专家。一个赋权的数据产品文化将责任推给那些具有明确目标的赋权的自治团队。业务目标仍然由高级管理层确定，但决策和解决方案的过程变得更加地本地化，由自治团队来完成。