下载掌阅APP，畅读海量书库
立即打开
数据工程师不是在真空中工作。根据他们从事的工作，他们将与技术人员和非技术人员互动，并面对不同的方向（内部和外部）。让我们探讨一下数据工程师在组织内部做什么以及他们都与谁互动。
数据工程师服务于多个终端用户，并面对许多内部和外部的方向（如图1—9所示）。并非所有数据工程的工作量和职责都是相同的，因此了解数据工程师为谁服务至关重要。根据终端用户的情况，数据工程师的主要职责是面向外部、面向内部或两者兼而有之。
图1—9：数据工程师面临的方向
面向外部 的数据工程师通常与面向外部的应用程序的用户保持一致，如社交媒体应用程序、物联网（Internet of Things，IoT）设备和电子商务平台。该数据工程师架构、构建并管理用于收集、存储和处理来自这些应用程序的事务和事件数据的系统。这些数据工程师构建的系统有一个从应用程序到数据管道，然后再回到应用程序的反馈循环（如图1—10所示）。
图1—10：面向外部的数据工程师系统
面向外部的数据工程带来了一系列独特的问题。面向外部的查询引擎通常比面向内部的系统处理更大的并发负载。工程师还需要考虑对用户可以运行的查询进行严格限制，以限制任何单个用户对基础设施的影响。此外，安全性对于外部查询来说是一个更为复杂和敏感的问题，尤其是当查询的数据是多租户（来自许多客户的数据并存放在一个表中）时。
面向内部 的数据工程师通常关注对业务和内部利益相关者的至关重要的需求活动（如图1—11所示）。例如，为BI仪表板、报告、业务流程、数据科学以及ML模型创建和维护数据管道与数据仓库。
面向外部和面向内部的职责经常混合在一起。在实践中，面向内部的数据通常是面向外部的数据的先决条件。数据工程师有两组用户，他们对查询并发性、安全性等有着截然不同的要求。
图1—11：面向内部的数据工程师系统
实际上，数据工程生命周期跨越许多责任领域。数据工程师直接或间接（通过经理）与许多组织单位互动，担任着各种角色的纽带。
让我们看看数据工程师可能会影响谁。在本节中，我们将讨论与数据工程相关的技术角色（如图1—12所示）。
图1—12：数据工程的关键技术利益相关者
数据工程师是 数据生产者 [如软件工程师、数据架构师和DevOps或站点可靠性工程师（Site Reliability Engineer，SRE）]与 数据消费者 （如数据分析师、数据科学家和机器学习工程师）之间的枢纽。此外，数据工程师将与运营角色的人员（如DevOps工程师）进行交互。
考虑到新数据角色流行的速度（分析和ML工程师），这绝不是一个详尽的列表。
上游利益相关者
作为一名成功的数据工程师，你需要了解正在使用或设计的数据架构以及生成你需要的数据的源系统。接下来，我们讨论一些熟悉的上游利益相关者：数据架构师、软件工程师和DevOps工程师。
数据架构师 。数据架构师的功能在抽象级别上与数据工程师相差无几。数据架构师设计组织数据管理的蓝图，规划流程、整体数据架构和系统 [10] 。他们还充当组织技术和非技术方面之间的桥梁。成功的数据架构师通常有丰富的工程经验所带来的“战斗伤痕”，使他们能够指导和协助工程师，同时成功地将工程挑战传达给非技术业务利益相关者。
数据架构师实施跨孤岛和业务部门管理数据的政策，指导数据管理和数据治理等全球战略，并指导重大举措。数据架构师通常在云迁移和未开发云设计中发挥核心作用。
云的出现改变了数据架构和数据工程之间的界限。云数据架构比本地系统更具流动性，因此传统上涉及广泛研究、较长交付周期、购买合同和硬件安装的架构决策现在通常在实施过程中做出，只是更大战略中的一个步骤。尽管如此，数据架构师仍将是企业中有影响力的远见卓识者，他们与数据工程师携手合作，确定架构实践和数据策略的大局。
根据公司的数据成熟度和规模，数据工程师可能会与数据架构师的职责有重叠，或者承担数据架构师的职责。因此，数据工程师应该对架构最佳实践和方法有好的理解。
请注意，我们已将数据架构师置于上游利益相关者部分。数据架构师通常帮助设计作为数据工程师源系统的应用程序数据层。数据架构师还可以在数据工程生命周期的各个其他阶段与数据工程师进行交互。我们将在第3章介绍“好的”数据架构。
软件工程师 。软件工程师构建运行业务的软件和系统。他们主要负责生成数据工程师将使用和处理的 内部数据 。软件工程师构建的系统通常会生成应用程序的事件数据和日志，这些数据本身就是重要的资产。此内部数据与从SaaS平台或合作伙伴企业提取的 外部数据 形成鲜明对比。在运行良好的技术组织中，软件工程师和数据工程师从新项目的开始就进行协调，以设计供分析和ML应用程序使用的应用程序数据。
数据工程师应该与软件工程师一起工作，了解产生数据的应用程序、生成数据的数量、频率和格式，以及任何其他会影响数据工程生命周期的因素，如数据安全和法规遵从。例如，这可能意味着对数据软件工程师完成工作所需的内容设定上游预期。数据工程师必须与软件工程师紧密合作。
DevOps工程师和站点可靠性工程师 。DevOps和SRE通常通过运营监控来生成数据。我们将他们归类为数据工程师的上游，但他们也可能是下游，通过仪表板使用数据或直接与数据工程师交互以协调数据系统的操作。
下游利益相关者
数据工程的存在是为了服务下游数据消费者和用例。本节讨论数据工程师如何与各种下游角色交互。我们还将介绍一些服务模型，包括集中式数据工程团队和跨职能团队。
数据科学家 。数据科学家建立前瞻性模型来进行预测和提供建议，然后根据实时数据评估这些模型，以各种方式提供价值。例如，模型评分可以确定响应实时条件的自动操作，根据客户当前会话中的浏览历史向客户推荐产品，或者进行交易员使用的实时经济预测。
根据常见的行业传说，数据科学家花费70%～80%的时间来收集、清洗和准备数据 [11] 。根据我们的经验，这些数字通常反映了不成熟的数据科学和数据工程实践。特别是，许多流行的数据科学框架如果没有适当地进行扩展，可能会成为瓶颈。只在单一工作站上工作的数据科学家强迫自己对数据进行下采样，这使得数据准备变得更加复杂，并可能影响他们制作的模型的质量。此外，本地开发的代码和环境通常难以在生产中部署，并且自动化的缺乏严重阻碍了数据科学工作流。如果数据工程师完成了他们的工作并成功地进行了协作，那么数据科学家不应该在最初的探索性工作之后花时间收集、清洗和准备数据。数据工程师应该尽可能地将这项工作自动化。
对生产就绪数据科学的需求是数据工程专业兴起的重要驱动力。数据工程师应该帮助数据科学家实现一条生产路径。事实上，我们在认识到这一基本需求后从数据科学转向数据工程。数据工程师致力于提供数据自动化和规模化，使数据科学更加高效。
数据分析师 。数据分析师（或业务分析师）寻求了解业务绩效和趋势。数据科学家具有前瞻性，而数据分析师通常关注过去或现在。数据分析师通常在数据仓库或数据湖中运行SQL查询。他们还可以利用电子表格进行计算和分析，以及各种BI工具，例如Microsoft Power BI、Looker或Tableau。数据分析师是数据领域的专家，他们经常处理数据并且非常熟悉数据的定义、特征和质量问题。数据分析师的典型下游客户是业务用户、管理层和高管。
数据工程师与数据分析师合作，为业务所需的新数据源构建管道。数据分析师的主题专业知识对于提升数据质量非常有价值，他们经常以这种身份与数据工程师合作。
机器学习工程师和人工智能研究人员 。机器学习工程师（ML工程师）与数据工程师和数据科学家重叠。ML工程师开发先进的ML技术、训练模型以及设计和维护在规模化生产环境中运行ML流程的基础设施。ML工程师通常具有ML和深度学习技术及框架（如PyTorch或TensorFlow）的高级工作知识。
ML工程师同时需要了解运行这些框架所需的硬件、服务和系统，包括模型训练和生产规模的模型部署。ML流通常在云环境中运行，ML工程师可以在云环境中按需（或依赖托管服务）启动和扩展基础设施资源。
正如我们所提到的，ML工程、数据工程和数据科学之间的界限是模糊的。数据工程师可能对ML系统负有一些运营职责，数据科学家可能与ML工程人员密切合作设计先进的ML流程。
ML工程的世界正在滚雪球般发展，并且与数据工程中发生的许多相同的发展并行。几年前，ML的注意力集中在如何构建模型上，而现在ML工程越来越强调结合机器学习运营（Machine Learning Operations，MLOps）的最佳实践以及以前在软件工程和DevOps中采用的其他成熟实践。
AI研究人员致力于新的、先进的ML技术。AI研究人员可能在大型科技公司、专门的知识产权初创公司（OpenAI、DeepMind）或学术机构工作。一些从业者致力于结合公司内部的ML工程职责进行兼职研究。那些在专门的ML实验室工作的人通常100%致力于研究。研究问题可能针对直接的实际应用或更抽象的AI演示。DALL-E、Gato AI、AlphaGo和GPT-3/GPT-4是ML研究项目的绝佳示例。鉴于ML的发展速度，这些例子很可能在几年后就会变得过时。我们将在1.5节中提供一些参考资料。
在资金充足的组织中，AI研究人员高度专业化，并与支持型工程师团队一起合作。虽然学术界的ML工程师通常资源较少，但可以依靠研究生、博士后和大学教职工团队提供工程支持。部分致力于研究的ML工程师通常依赖相同的支持团队进行研究和生产。
我们讨论了数据工程师与之交互的技术角色。但数据工程师还作为组织连接器在更广泛的范围内运作，通常以非技术身份。企业越来越依赖数据作为许多产品或产品本身的核心部分。数据工程师现在参与战略规划并领导超越IT边界的关键举措。数据工程师通常通过充当业务和数据科学/分析之间的黏合剂来支持数据架构师。
企业决策层数据
C级高管越来越多地参与到数据和分析中，因为这些被认为是现代企业的重要资产。例如，CEO现在关注的是曾经属于IT专属领域的举措，例如云迁移或新客户数据平台的部署。
首席执行官 。非技术公司的首席执行官（Chief Executive Officer，CEO）通常不关心数据框架和软件的细节。相反，他们与技术最高管理层角色和公司数据领导层合作定义愿景。数据工程师为了解数据的可能性提供了一个窗口。数据工程师和他们的经理维护着一张地图，说明在什么时间范围内组织内部和第三方可以使用哪些数据。他们还负责与其他工程角色合作研究主要的数据架构变化。例如，数据工程师通常大量参与云迁移、向新数据系统迁移或部署流技术。
首席信息官 。首席信息官（Chief Information Officer，CIO）是负责组织内信息技术的高级管理人员。这是一个面向内部的角色。CIO必须具备对信息技术和业务流程的深入了解，仅了解其中一项是不够的。CIO指导信息技术组织，制定持续的政策，同时还在CEO的指导下定义和执行重要举措。
CIO经常与拥有良好数据文化的组织中的数据工程领导层合作。如果一个组织的数据成熟度不是很高，CIO通常会帮助塑造其数据文化。CIO将与工程师和架构师合作制定重大举措，并就采用主要架构元素做出战略决策，如企业资源规划（Enterprise Resource Planning，ERP）和客户关系管理（Customer Relationship Management，CRM）系统、云迁移、数据系统和面向内部的IT。
首席技术官 。首席技术官（Chief Technology Officer，CTO）与CIO类似，但面向外部。CTO拥有面向外部应用程序的关键技术战略和架构，这些应用程序包括移动、Web应用程序和物联网——这些都是数据工程师的关键数据源。CTO可能是一位技术娴熟的技术专家，并且对软件工程基础知识和系统架构有很好的了解。在一些没有CIO的组织中，CTO或首席运营官（Chief Operating Officer，COO）扮演CIO的角色。数据工程师通常直接或间接通过CTO报告。
首席数据官 。首席数据官（Chief Data Officer，CDO）于2002年在Capital One创立，当时该公司认识到数据作为商业资产的重要性日益增强。CDO负责公司的数据资产和战略。CDO专注于数据的商业效用，但应具备强大的技术基础。CDO负责监督数据产品、战略、计划和核心功能，如主数据管理和隐私。有时，CDO会管理业务分析和数据工程。
首席分析官 。首席分析官（Chief Analytice Officer，CAO）是CDO角色的变体。在这两种角色同时存在的情况下，CDO专注于交付数据所需的技术和组织。CAO负责业务的分析、战略和决策制定。CAO可以监督数据科学和ML，但这在很大程度上取决于公司是否有CDO或CTO角色。
首席算法官 。首席算法官（Chief Algorithms Officer，CAO-2）是最高管理层最近的创新，这是一个高度技术性的角色，专注于数据科学和ML。CAO-2通常具有在数据科学或ML项目中作为个人贡献者和团队领导的经验。通常，他们具有ML研究背景和相关的高级学位。
CAO-2应该熟悉当前的ML研究，并有深入的技术知识以支持公司的ML计划。除了制定业务计划外，他们还提供技术领导、制定研发议程以及组建研究团队。
数据工程师和项目经理
数据工程师经常致力于重大举措，可能跨越多年。在我们撰写本书时，许多数据工程师正在致力于云迁移，将管道和仓库迁移到下一代数据工具。其他数据工程师正在启动未开发的项目，通过从数量惊人的同类最佳架构和工具选项中进行选择，从头开始组建新的数据架构。
这些大型计划通常受益于 项目管理 （与产品管理相反，将在下面讨论）。数据工程师在基础设施和服务交付能力中发挥作用，而项目经理则指挥交通并充当看门人。大多数项目经理根据敏捷和Scrum的一些变体进行操作，偶尔仍然会出现瀑布式管理。业务永不停息，业务利益相关者通常积压了大量他们想要解决的事情和他们想要启动的新举措。项目经理必须过滤一长串请求并确定关键可交付成果的优先级，以保持项目正常进行并更好地为公司服务。
数据工程师与项目经理进行交互，经常为项目规划冲刺，并随后召开与冲刺相关的站会。反馈是双向的，数据工程师将进度和障碍告知项目经理和其他利益相关者，项目经理平衡技术团队的节奏与不断变化的业务需求。
数据工程师和产品经理
产品经理监督产品开发，通常拥有产品线。在数据工程师的背景下，这些产品被称 为数据产品 。数据产品要么是从头开始构建，要么是对现有产品的逐步改进。随着企业界聚焦以数据为中心，数据工程师与 产品经理 的交互更加频繁。与项目经理一样，产品经理平衡技术团队的活动与客户和业务的需求。
数据工程师和其他管理角色
数据工程师与项目和产品经理以外的各种经理进行交互。但是，这些交互通常遵循服务或跨功能模型。数据工程师要么作为集中式团队处理各种传入请求，要么作为资源被分配给特定的经理、项目或产品。
有关数据团队及其构建方式的更多信息，我们推荐John Thompson的 Building Analytics Teams （Packt）和Jesse Anderson的 Data Teams （Apress）。这两本书都提供了强有力的框架和观点，说明数据管理人员的角色、聘请谁以及如何为你的公司构建最有效的数据团队。
公司不会仅为破解孤立的代码而雇用工程师。为了配得上他们的头衔，工程师应该深入了解他们要解决的问题、他们可以使用的技术工具以及他们一起工作和服务的人。