第三章：设计您的数据团队-灵析社区

攻城狮无远

在设计数据平台时，有几个技术方面需要考虑：性能、成本、运营开销、运营卓越、整合新的分析和机器学习方法等。然而，如果不解决公司文化的问题，这些技术方面将无法发挥作用——采用新技术需要员工愿意改变他们的思维模式和工作方式。另一个需要记住的关键方面是现有员工目前具备的技能以及他们需要掌握的技能。在某些情况下，学习新技能并改变工作方式的员工最终可能会进入与数据平台实施之前不同的角色。

在本章中，我们探讨了组织如何规划和协调这些思维模式、工作流程、技术技能和角色的变化。每个组织都是独特的，因此构建数据平台将涉及为每个部门和其中的员工制定详细的计划。在本章中，我们描述了不同类型组织的这种详细计划会是什么样子。

分类数据处理组织

组织可以通过采用不同的策略基于其人才而取得成功。没有普遍适用的“最佳”方法。一支防守强大的体育队伍应该发挥他们的优势，专注于防守，而不是试图复制一支拥有技术出色进攻球员的球队的进攻。同样，如果你的组织拥有一支强大的数据分析团队，它应该专注于其人员，而不是试图转变为一个充满数据工程师的组织。

根据你的员工技能和用例的复杂性，为你的组织决定最佳策略。你是否需要一小组数据工程师，他们能力强但成本高？还是应该利用大型且已经存在的数据分析员团队来丰富和转换可行动的数据？这些工作者需要多少领域知识？培训现有工作人员执行更高价值的工作是否切实可行？还是应该投资于生成式AI或无代码工具，并使这些基础技术的重要部分对更大范围的工作人员可用？

最佳技术方法在组织内也会有所不同 - 销售团队和工厂车间之间的工作人员构成将有所不同。因此，详细的计划涉及为每个业务单元详细说明最佳的技术方法。从技术上讲，该计划还将在基于标准ETL的方法（需要ETL工具的硬技能）和基于ELT的现代方法之间做出选择（需要更通用的SQL技能）。

考虑图3-1中勾画的传统用户画像价值链。你可以看到组织中的每个数据用户都拥有一组小而专业的技术技能。如果一个组织希望扩大其数据分析团队的范围，它还必须扩大其数据工程和数据科学团队的规模，以确保有足够的人具备正确的技术技能来支持数据分析员。

公共云提供的新范式为数据处理、数据分析和算法开发提供了新的可能性。云技术现在使得新的工作方式成为可能 - 它们允许分析师执行曾由数据工程师管理的批处理或实时数据处理任务，同时还允许他们尝试使用现成的数据科学解决方案。此外，给定的任何用户画像的潜在范围 - 他们拥有的技能和他们负责的职责 - 已经增加。随着数据技术变得更加可访问，数据工作者能够承担新的任务，并在没有传统用户画像相关瓶颈的情况下处理数据价值链。这导致技能在角色之间的融合，使现有团队更容易扩展到其他职责。专注于使用SQL代码通过ELT方法解决问题的数据分析员和更倾向于使用ETL方法和通用代码（例如Python、Java、Scala等）的数据工程师/数据科学家之间的区别变得不那么明显。混合方法（如图3-2所示）变得越来越普遍，因为它们可以充分利用ETL和ELT模式的优势。我们今天看到的大多数组织都属于这种混合模型，尽管角色的平衡以及数据处理必须通过ETL或ELT的程度取决于组织的类型，存在一些变化。


以数据分析为驱动的组织

以数据分析为驱动的组织是在决策制定中数据分析师发挥核心作用的组织。值得注意的是，组织是否以分析师为主导不是一个非黑即白的问题，而是一系列重叠特征的谱系：

成熟行业： 这些组织是知名且经过时间验证的企业，拥有完善（也许是过时的）的系统。它们所处的行业通常是成熟且稳定的。主要工作涉及对各种产品或情况进行人工分析。数据分析为驱动的组织的典型例子包括零售商的商品单位（例如沃尔玛）和大型银行的商业贷款处理部门（例如摩根大通）。

企业数据仓库（EDW）和批处理ETL： 在技术层面上，中心信息枢纽是一个随时间建立起来的EDW，具有较高水平的技术债务和传统技术。在数据仓库内部的数据转换是通过定期的ETL过程进行的，比如夜间批处理。这种批处理过程增加了数据提供的延迟。

商业智能： 组织中的大多数数据专业人员习惯于通过对集中式数据仓库运行SQL查询、使用BI工具创建报告和仪表板，并使用电子表格来访问类似数据来回答业务问题。因此，内部人才储备最擅长于SQL、BI工具和电子表格。

请注意，即使在零售和金融等成熟行业中，新兴的数字组织（电子商务和金融科技）可能会寻求捕捉增长最快的数字领域和具有最大潜力的客户细分市场。这样的数字原住民可能与传统大公司（例如Etsy与沃尔玛；Paytm与摩根大通）有不同的员工组成；我们不会将数字原住民与传统公司放在同一类别中。

现在，您对我们所说的以分析为驱动的组织有了更清晰的了解，让我们讨论进行转型的主要手段。

简单来说，数据工作者现在能够更高效地处理其拥有的数据，并能够以更高效的方式执行更多任务。这是因为技术变得更加易于访问，而且数据工作者能够将他们的技能与其他数据专业人员的技能相融合。这导致了一种更高效和有效的数据处理方式。

组织可以广泛分为三种类型：以数据分析为驱动、以数据工程为驱动和以数据科学为驱动。在接下来的部分中，我们将介绍为每种类型构建数据处理组织的理想方式。在现实中，公司将包括属于这些类别的不同部门或业务单位，因此它们将发现自己应用所有这些策略。一些团队将是角色的组合，因此转型将涉及混合方法。在考虑将成为数据团队一部分的不同类型用户时，请记住在第二章学到的内容：“为了最大程度地发挥从数据中获得的优势，请应用产品管理原则。”您应始终使用产品管理原则来制定数据产品策略，以客户为中心，通过白板和原型发现产品，并在标准化和灵活性之间找到正确的平衡。

愿景

为在以分析驱动为特征的组织中普及云数据平台的使用，分析师应该能够通过熟悉的界面，如电子表格、SQL 和商业智能工具进行高级分析。这意味着提供易于使用的工具，将数据引入目标系统，并与分析和可视化工具实现无缝连接。

这在传统企业数据仓库中曾是常见做法。使用 SQL 对数据进行丰富、转换和清理，使用 ETL 工具进行编排。同样，物化视图和用户定义函数可用于在现代数据仓库中丰富、转换和清理数据。

然而，这假设分析师已经能够访问所有数据源。创建复杂的摄取管道曾经是昂贵且常常繁琐的。因此，由于资源和成本的限制，数据管道是在数据仓库之外管理的。

这在使用新的云数据仓库时已不再成立。摄取的角色现在仅仅是将数据带到云附近，而转换和处理部分则移回了云数据仓库。这导致数据被暂存在存储桶或消息系统中，然后被摄取到云数据仓库中。

所有这些不仅减少了使数据可用所需的时间，还使数据分析师能够专注于使用他们习惯的工具和界面寻找数据洞见。因此，在新世界中，ELT 应该取代 ETL 工具——数据分析师可以使用 SQL 编排工具，如 dbt 或 Dataform，串联 SQL 语句来进行 ELT。直接从源或暂存区摄取数据使分析师能够利用他们的关键 SQL 技能，并增加他们接收数据的及时性。他们无需等待繁忙的数据工程团队实施 ETL 管道。

总之，扩展云数据平台的使用最佳方法是为分析师提供易于使用的工具（如 dbt）和界面（如 Excel 或 Tableau），以便他们可以轻松掌握。这将使他们能够进行高级分析，而无需等待数据工程团队实施复杂的 ETL 管道。

一旦数据在云数据仓库中可用，就是开始分析的时候了。过去，许多数据分析是使用电子表格完成的，但电子表格通常难以处理新世界中需要分析的大量数据。尽管 Google Sheets 和 Excel 具有连接到数据仓库的实时功能，但仍然有些繁琐。我们建议为分析师提供使用现代商业智能工具创建可处理大型数据集的可视化和报告的权限（例如 Power BI、Tableau 或 Looker）。

人物角色

分析驱动型组织数据部门中的主要角色包括数据分析师、业务分析师和数据工程师。

数据分析师

数据分析师接收、理解并满足业务的请求，理解相关数据。数据分析师的目标是满足组织的信息需求。他们负责数据的逻辑设计和维护。他们的一些任务可能包括创建符合业务流程的表格布局和设计，以及重新组织和转换数据源。此外，他们负责生成能够有效传达业务请求的趋势、模式或预测的报告和见解。

为了构建分析驱动型组织的任务，有必要通过两种方式扩展数据分析师社区的经验和技能集。首先，推动数据分析师学习业务的趋势是至关重要的。数据分析师需要深入了解业务领域。其次，数据分析师需要获得分析和呈现数据的技术技能，无论数据的量或大小。幸运的是，现在可以使用 SQL 和 BI 工具来实现这一点。数据分析师技能的扩展，既包括业务领域，也包括大数据，如图 3-3 所示。

业务分析师

业务分析师是领域专家，利用数据进行分析洞察。

基于云的数据仓库和无服务器技术已经将业务分析师的责任扩展到传统领域专家的领域。这是因为分析师现在可以专注于通过分析数据为业务增值，而不是浪费时间在管理和技术管理任务上。此外，存储在数据仓库中的数据的数量和类型不再是限制因素，因此分析师现在可以更深入地了解业务以获取洞察。

数据仓库可以同时充当数据的着陆区域和结构化及半结构化数据的记录系统。这意味着业务分析师可以在一个地方获得所有需要分析的数据。总体而言，基于云的数据仓库和无服务器技术使业务分析师能够更加高效，为业务增加更多价值。 尽管业务分析师可以使用无代码和低代码的机器学习模型，但他们在涉及机器学习或自然语言文本的更复杂工作流方面可能会遇到困难。他们还没有实施复杂数据科学算法的技能，比如排名或推荐。因此，如果您的激活需求更为复杂，仍然需要一个数据科学团队。

数据工程师

数据工程师专注于下游数据管道和数据转换的前几阶段，如加载和集成新数据源。他们还负责管理数据治理和数据质量流程。

在以分析为驱动的组织中，数据工程师的数量将较少，因为数据分析团队基本上可以自给自足，能够构建简单的数据管道和机器学习模型。分析驱动的组织倡导ELT的概念，而不是传统的ETL。主要区别在于常见的数据处理任务是在数据加载到数据仓库后处理的。ELT广泛使用SQL逻辑来增强、清理、规范化、精炼和集成数据，使其准备好进行分析。这种方法有几个好处：它减少了行动时间，数据立即加载，并且可以同时提供给多个用户。因此，这样的组织的变更管理策略必须专注于诸如SQL、视图、函数、调度等方面。

即使在分析驱动的组织中，数据工程团队通常仍然掌控从源系统提取数据的过程。尽管可以通过使用基于SQL的工具简化此过程，使数据分析师能够执行其中的一些工作，但仍然需要一个强大的数据工程团队。仍然有一些批处理作业需要创建数据管道，更适合使用ETL。例如，从主机到数据仓库传输数据需要额外的处理步骤：数据类型需要映射，COBOL书籍需要转换等。

此外，对于实时分析等用例，数据工程团队将配置流数据源，如Pub/Sub、Kafka主题或Kinesis数据流。处理通用任务的方式仍然相同——它们可以被编写为通用的ETL管道，然后由分析师重新配置。例如，将来自各种源数据集的数据质量验证检查应用于目标环境将遵循由数据工程师设置的模板。

技术框架

有关面向分析驱动组织的高层参考架构，有三个基本原则：

  1. SQL 作为标准 技术应该根据当前的组织文化进行定制。应优先考虑提供 SQL 接口的组件，无论它们在数据处理流程的哪个阶段。
  2. 从企业数据仓库（EDW）/数据湖到结构化数据湖 信息系统基础设施及其数据应进行集成，以扩展对新的和多样化数据源进行分析处理的可能性。这可能涉及将传统的数据仓库与数据湖合并，以消除信息孤岛（有关 lakehouse 架构的详细信息，请参阅第 7 章）。
  3. 先读取后模式的模式 由于存储成本较低，组织在收到数据之前不再需要对数据结构施加严格的规则。从写入模式（schema-on-write）转向读取模式（schema-on-read）允许对数据进行实时访问。数据可以保留其原始形式，然后转换为最有用的模式。此外，数据平台可以管理保持这些副本同步的过程（例如，使用物化视图、变更数据捕获等）。因此，请不要害怕保留相同数据资产的多个副本。

将这些原则结合起来，我们可以定义一个高层架构，如图 3-4 所示。这个信息架构满足上述三个原则，并支持一些关键的数据分析模式：

  • “传统”商业智能工作负载，如创建仪表板或报告
  • 允许通过 SQL 进行数据管道管理的自发分析界面（ELT）
  • 使用机器学习技术实现数据科学用例
  • 将数据实时流入数据仓库并处理实时事件

这两种模式与传统的 SQL 数据仓库世界相当相似，但后两种则以 SQL 抽象的形式呈现更高级的分析模式。在 ML 领域，Redshift ML 或 BigQuery ML 允许数据分析师使用标准 SQL 查询在存储在数据仓库中的数据上执行 ML 模型。SQL 流扩展，如 Dataflow 和 KSQL，使得能够聚合具有无限制、实时源（如 Pub/Sub 或 Kafka）的数据流成为可能。即使无需投资于新的配置文件和/或角色，这项技术也能开启许多可能性。

在为面向分析驱动组织选择 ELT 和 ETL 时，数据准备和转换是关键考虑因素。应尽可能使用 ELT，因为它允许使用 SQL 在结构化数据湖中对数据进行转换。这种方法提供了与广泛的数据集成套件相同的功能，但无需牺牲数据质量或运营监控。诸如 dbt 之类的产品将软件工程方法引入数据建模和构建数据工作流程中；dbt 实际上允许构建类似于由代码构建的 ETL 工作流的 ELT 工作流，但是使用的是 SQL。这使得数据分析师（不是系统程序员）能够进行可靠而复杂的数据转换。

简而言之，对于面向分析驱动组织，ELT是比ETL更好的选择，因为它允许更灵活和更可控的数据转换。此外，dbt提供了数据建模和构建数据工作流的软件工程方法，有助于提高数据转换的可靠性和复杂性。

数据工程驱动型组织

一个以工程为驱动的组织专注于数据集成。有些公司（例如金融科技公司Plaid）的业务是为整个行业构建集成管道。更常见的情况是这是一个大型企业中的一个团队。例如，一家投资公司可能有一个团队的工作是从许多供应商那里获取、重新格式化并摄取金融数据（例如股市数据、公司的SEC文件等）和另类数据（例如信用卡支出、电子收据、零售客流等）。

愿景

当您的数据转换需求变得复杂时，您需要数据工程师在公司的数据战略中发挥核心作用，以确保您可以成本效益地构建可靠的系统。数据工程师位于数据所有者和数据消费者之间的交叉点。

业务数据所有者是业务团队与数据架构的联系人，了解业务并为数据架构提供数据。数据消费者专注于从架构中提取不同数据的洞察力。在这里，通常会找到数据科学团队、数据分析团队、商业智能团队等。这些团队有时会将来自不同业务单位的数据结合起来，并生成（机器学习模型、交互式仪表板、报告等）工件。在部署方面，他们需要数据工程团队的帮助，以确保数据是一致且可信的。

数据工程师有以下责任：

  • 在构建分析系统和操作系统之间的集成时，传输数据并丰富数据（如在实时用例中）。
  • 解析和转换来自业务单位和外部供应商的混乱数据，使其成为有意义且干净的数据，并具有详细的元数据。
  • 应用数据运营（DataOps），即将业务的功能知识与应用于数据生命周期的软件工程方法相结合。这包括监视和维护数据源。
  • 部署机器学习模型和其他数据科学工件，以分析或使用数据。 构建复杂的数据工程流水线是昂贵的，但可以提高能力：
  • 丰富 数据工程师创建了从不同来源收集数据并将其合并以创建更有价值数据集的过程。然后可以使用这些数据做出更好的决策。
  • 训练数据集 机器学习模型的质量很大程度上取决于用于训练这些模型的数据。通过从多个来源引入数据并统一它们以准备用于训练机器学习模型的数据集，数据工程师可以提高数据科学团队的生产力。
  • 非结构化数据 当机器学习模型需要使用非结构化数据（例如评论文本或图像）时，存在特殊的挑战。这些数据通常不遵循传统DWH将使用的严格模式。此外，它需要清除个人身份信息（例如聊天记录中的电话号码）和不适当的内容（尤其是图像），并进行转换（例如使用嵌入）。
  • 产品化 还需要数据工程工作来将临时数据科学工作产品化并从中获得价值。没有数据工程，数据科学家将被困在进行实验和为特定用例制作应用的困境中，但这些应用很少被产品化或概括。
  • 实时分析 应用程序，如异常检测和欺诈预防，需要立即做出响应。在这种用例中，数据消费者需要在数据即时到达时即时处理信息。他们必须以低延迟进行操作。这种实时分析需要在目标DWH之外进行转换。

通常所有这些都需要定制应用程序或最先进的工具。实际上，很少有组织的工程能力卓越到可以真正称之为工程组织。许多组织属于我们称之为混合组织的范畴（见图3-2）。

人物角色

数据工程师开发并优化所有获取数据所需的过程，以及执行相关分析和生成报告所需的解决方案。

知识

数据工程角色需要深入了解数据库和编程语言，同时具备在部门间合作所需的一定业务技能。无论他们在哪个规模的组织中工作，数据工程师都需要具备一些标准的技能才能取得成功。最有价值的知识包括：

  1. 数据仓库和数据湖解决方案 Cloudera Data Platform、Oracle Exadata、Amazon RedShift、Azure Synapse、Google BigQuery、Snowflake、Databricks、Hadoop生态系统等，数据工程师可以处理海量数据。
  2. 数据库系统 SQL 和 NoSQL 数据库系统。他们应该知道如何在关系数据库管理系统（RDBMS）中进行信息存储和检索。
  3. ETL 工具 传统工具如 Informatica 和 Ab Initio 以及现代框架如 Apache Beam、Spark 和 Kafka。
  4. 编程语言 Python、Java、Scala。
  5. 数据结构和算法 数据结构和算法允许组织和存储数据以便轻松访问和操作，这对于数据工程师是一项必不可少的技能。
  6. 自动化和脚本编写 数据工程师应该能够编写脚本以自动化重复性任务，因为他们必须处理大量数据（例如 bash、PowerShell、HashiCorp Terraform、Ansible 等）。
  7. 容器技术 将数据项目推向生产的事实标准。在本地机器上开发的项目可以“交付”到一个暂存和生产集群（通常）而无需问题。数据流水线和机器学习模型是可复制的，并且可以在任何地方以相同的方式运行。
  8. 编排平台 由于需要集成执行数据工程任务的各种解决方案和工具的增多，编排工具如 Apache Airflow 已成为必不可少的。

认证衡量了数据工程师的知识和熟练程度，确认个体具备必要的专业知识以为企业的数据战略做出贡献。例如 AWS Certified Data Analytics、Cloudera Certified Professional (CCP) Data Engineer、Google Professional Data Engineer 和 Microsoft Certified: Azure Data Engineer Associate。

责任

数据工程师负责确保不同业务部门生成和需要的数据被摄入到架构中。这项工作需要两种不同的技能：业务功能知识和数据工程/软件开发技能。这种技能组合通常被称为 DataOps（它起源于过去几十年中在软件开发领域发展起来的 DevOps 方法，但应用于数据工程实践）。

数据工程师还有另一个责任。他们必须帮助部署数据使用者生成的工件。通常，数据使用者没有足够的深度技术技能和知识来独自负责其工件的部署。对于非常复杂的数据科学团队也是如此。因此，数据工程师必须掌握其他技能：机器学习和商业智能平台知识。让我们澄清一下：我们不希望数据工程师变成机器学习工程师。机器学习工程是将数据科学家开发的机器学习模型部署到实时生产系统的过程。另一方面，数据工程师构建的基础设施是供他人用于处理数据的，比如数据存储和数据传输。数据工程师需要了解机器学习，以确保提供给模型的第一层数据（输入）是正确的。在推断路径中交付数据的第一层，数据工程技能在规模、高可用性等方面确实需要发挥作用。

通过负责解析和转换来自各个业务部门的混乱数据，或者实时摄取，数据工程师使数据使用者能够专注于创造价值。数据科学家和其他类型的数据使用者可以抽象出数据编码、大文件、旧系统和复杂的消息队列配置（用于流处理）的细节。将这种知识集中在一个高技能的数据工程团队中的好处是显而易见的，尽管其他团队（业务部门和使用者）也可能有自己的数据工程师，作为与其他团队进行接口的角色。最近，我们甚至看到了由业务部门成员（数据产品负责人）、数据工程师、数据科学家和其他角色组成的小组。这实际上创建了完整的团队，他们在数据流上拥有自治权，并对从传入数据到影响业务的数据驱动决策的整个过程负有全部责任。

技术框架

数据工程团队已经需要广泛的技能。不要让他们的工作变得更加困难，期望他们还要维护运行数据管道的基础设施。数据工程师应该专注于如何清理、转换、丰富和准备数据，而不是关注他们的解决方案可能需要多少内存或多少核心。

参考架构

摄取层由 Kinesis、Event Hubs 或 Pub/Sub 用于实时数据，以及 S3、Azure Data Lake 或 Cloud Storage 用于批处理数据组成（参见图 3-5、3-6 和 3-7）。它不需要任何预分配的基础设施。所有这些解决方案都可用于各种情况，因为它们可以自动扩展以满足输入工作负载的需求。

一旦数据被收集，我们提出的架构遵循传统的提取、转换和加载（ETL）的三步过程。对于某些类型的文件，直接加载到 Redshift、Synapse 或 BigQuery（使用 ELT 方法）也是可行的。

在转换层，我们主要推荐使用 Apache Beam 作为数据处理组件，因为它具有统一的批处理和流处理模型。Apache Beam 的运行器包括 GCP 上的 Cloud Dataflow，以及其他超大规模云提供商上的任何托管 Flink 或 Spark 实现。

在此架构中，Dataflow 的替代方案是使用基于 Spark 的解决方案，例如 Amazon EMR、Databricks、Azure HDInsight 或 Google Dataproc。然而，这些解决方案不是无服务器的，而且运行空闲的 Spark 集群是一项主要的成本。话虽如此，也有作为 AWS SageMaker/Glue 的一部分以及作为 GCP Serverless Spark 服务提供的无服务器 Spark 替代方案。主要用例是那些已经在 Spark 或 Hadoop 中拥有大量代码的团队。这些 Spark 解决方案使得可以直接将数据管道迁移到云端，而无需审核所有这些管道。

数据处理的另一种选择是使用无代码环境来创建数据管道，使用拖放界面，例如由 AWS Glue、Azure Data Factory 或 GCP Data Fusion 提供的界面。传统的 ETL 工具，如 Informatica、Ab Initio 和 Talend，也可以在云中以无服务器模式运行，并在底层使用 Kubernetes 集群。其中一些工具使用 Hadoop/Spark 解决方案或类似的专有计算引擎，在这种情况下，我们之前提到的所有内容也适用于 ETL 工具的情况。如果您的团队更喜欢在不编写任何代码的情况下创建数据管道，则图形化 ETL 工具是正确的选择。

参考架构的优势

图3-5、3-6和3-7中呈现的参考架构基于对无服务器NoOps技术和流水线的偏好。 通过使用无服务器技术，您可以将维护负担从数据工程团队中剔除，并为执行复杂和/或大型作业提供必要的灵活性和可伸缩性。例如，在零售商在黑色星期五期间规划交通高峰时，可伸缩性是至关重要的。使用无服务器解决方案使零售商能够查看他们在一天中的表现。他们不再需要担心在白天生成的大量数据的处理所需资源。

参考架构为数据工程团队提供了编写用于数据流水线的完全定制代码的可能性。这可能是因为解析要求可能很复杂，而没有现成的解决方案可行。在流处理中，团队可能希望以低延迟实现复杂的业务逻辑。然而，团队应尽力通过创建可重用的库和使用诸如Dataflow模板等技术来重用代码。这将两者的优势结合在一起（重用和重写），同时节省宝贵的时间，可以用于高影响代码而不是常见的I/O任务。

所呈现的参考架构还具有另一个重要特性：将现有的批处理流水线转换为流式处理的可能性。

数据科学驱动型的组织

以数据科学为驱动的组织是一种通过充分利用可用数据创造可持续竞争优势的实体。为此，该组织依赖自动化算法，通常（但并非总是！）采用机器学习（ML）。与以分析为驱动的组织依赖一次性报告和分析不同，以科学为驱动的组织试图以自动化方式做出决策。例如，一个以数据分析为驱动的银行可能会让数据分析师评估每个商业贷款机会，建立投资案例，并由高管签署。另一方面，以数据科学为驱动的金融科技公司可能会构建一个贷款批准系统，使用某种自动化算法对大多数贷款做出决策。

愿景

以科学为驱动的组织是一种从数据中提取最大价值，并利用机器学习和分析获得可持续竞争优势的实体。在构建这样一个数据科学团队时，应遵循一些原则：

  1. 适应性： 平台必须足够灵活，以适应所有类型的用户。例如，一些数据科学家/分析师更倾向于创建自己的模型，而其他人可能更喜欢使用无代码解决方案或在SQL中进行分析。这还包括提供各种ML和数据科学工具，如TensorFlow、R、PyTorch、Beam或Spark。该平台还应足够开放，能够在多云和本地环境中运行，同时在可能的情况下支持开源技术，以避免锁定效应。最后，资源不应成为瓶颈，因为平台必须能够迅速扩展以满足组织的需求。
  2. 标准化： 通过使平台更容易共享代码和技术工件，标准化提高了平台的效率。这提高了团队之间的沟通，并提升了他们的性能和创造力。标准化还使数据科学和ML团队能够以模块化的方式工作，这对于高效开发至关重要。标准化可以通过使用标准连接器连接到源/目标系统来实现。这避免了在ML和数据科学工作流中常见的“技术债务”。
  3. 责任： 数据科学和ML用例通常涉及诸如欺诈检测、医学成像或风险计算等敏感主题。因此，数据科学和ML平台帮助使这些工作流程尽可能透明、可解释和安全至关重要。透明度与运营卓越性相关。在数据科学和ML工作流的所有阶段收集和监控元数据是至关重要的，以创建一个“纸迹”，让您能够提出诸如： 用于训练模型的哪些数据？ 使用了哪些超参数？ 模型在生产中的表现如何？ 在最近的时期内是否发生任何形式的数据漂移或模型偏移？ 此外，以科学为驱动的组织必须深入了解其模型。虽然对于传统的统计方法来说这不是问题，但是ML模型（如深度神经网络）更加不透明。平台必须提供简单的工具来分析这些模型，以便自信地使用它们。最后，成熟的数据科学平台必须提供所有的安全措施，以在精细的层次上保护数据和工件的使用情况。
  4. 业务影响： 根据麦肯锡的说法，许多数据科学项目未能超越试点或概念验证阶段。因此，更重要的是预期或测量新举措的业务影响并选择回报率，而不是追逐最新的炫酷解决方案。因此，要识别何时购买、构建或定制ML模型，并将它们连接到单一集成堆栈是至关重要的。例如，通过调用API使用现成的解决方案而不是经过数月开发后构建模型，有助于实现更高的回报率并展示更大的价值。
  5. 激活： 将模型嵌入到最终用户使用的工具中的操作化模型的能力对于实现向广泛用户提供服务的规模至关重要。将小批量数据发送到服务，并在响应中返回预测的能力，使具有较少数据科学专业知识的开发人员能够使用模型。此外，促使灵活API的边缘推断和自动化流程的无缝部署和监控也很重要。这使您能够在私有和公共云基础架构、本地数据中心和边缘设备之间分发AI。

在构建以科学为驱动的组织时，会面临一些社会技术挑战。通常组织的基础设施不够灵活，无法适应快速变化的技术环境。平台还需要提供足够的标准化，以促进团队之间的沟通，并建立技术“通用语言”。这对于允许团队之间的模块化工作流程并建立运营卓越性至关重要。此外，安全地监控复杂的数据科学和ML工作流通常过于不透明。 以科学为驱动的组织应建立在技术开放度极高的平台上。因此，使广泛的人物能够在灵活且无服务器的方式中提供技术资源至关重要。购买还是构建解决方案是实现组织回报率的关键驱动因素之一，这将定义任何AI解决方案将产生的业务影响。同时，使大量用户能够激活更多的用例。最后，平台需要提供工具和资源，使数据科学和ML工作流具有开放性、解释性和安全性，以提供最大形式的责任。

人物角色

以数据科学为驱动的组织中的团队由拥有不同技能和经验的各种人员组成。然而，大多数团队包括四个核心角色：数据工程师、ML工程师、数据科学家和分析师。值得注意的是，这些角色并不总是清晰定义的，可能在一定程度上存在重叠。有效的组织结构将允许团队成员之间的协作，并充分利用所有团队成员的技能：

  1. 数据工程师： 数据工程师负责开发数据管道，确保数据符合所有质量标准。这包括清理、合并和丰富来自多个来源的数据，将其转化为可用于下游分析的信息。
  2. ML工程师： ML工程师创建和监督完整的ML模型。虽然ML工程师是这四种角色中最稀缺的，但一旦组织打算在生产中运行关键业务工作流程时，它们就变得至关重要。
  3. 数据科学家： 数据科学家是数据和ML工程师之间的桥梁。与业务利益相关者一起，他们将业务需求转化为可测试的假设，确保从ML工作负载中获得价值，并创建报告以展示数据的价值。
  4. 数据分析师： 数据分析师提供业务洞察，并确保实施业务正在寻求的数据驱动解决方案。他们回答临时问题，并提供定期报告，分析历史和最新数据。

关于公司是否应该建立集中式还是分散式的数据科学团队存在各种观点。还有一些混合模型，例如将数据科学家嵌入到集中式组织中的联邦组织。因此，更重要的是专注于如何使用前述原则来解决这些社会技术挑战。

技术框架

我们强烈建议在ML管道基础设施方面采用您的公有云提供商的标准化解决方案（即在Google Cloud上的Vertex AI，AWS上的SageMaker，或Azure上的Azure Machine Learning），而不是拼凑一些一次性的培训和部署解决方案。参考架构（参见图3-8）包括一个ML管道，用于自动化实验和训练。训练好的模型在一个管道中部署，其中通过容器化重复执行许多训练步骤。在特征需要按需计算成本过高或必须在服务器端注入时，请使用特征存储。将模型部署到端点。

总结

在本章中，您已经了解了设计数据团队以确保其在您所在的组织中取得成功的不同方式。最佳方法是找到一种合适的技能和经验组合，以补充您现有的团队并帮助您实现业务目标。主要要点如下：

  1. 云技术有助于获取新的工作方式。任何给定角色的潜在面积已经扩大。数据工作者现在能够更高效地利用他们拥有的数据，做更多的事情。
  2. 无论您的组织主要由数据分析师、数据工程师还是数据科学家组成，都可以建立数据文化。然而，通向数据文化的路径以及每种组织类型所需的技术是不同的。
  3. 确定哪种组织分类对您来说是正确的，然后开始建立支持其愿景、相关技能和技术框架的人物角色。
  4. 数据平台的愿景也因情况而异。在以分析为驱动的组织中，它应该使对数据的访问变得更加民主。在以工程为驱动的组织中，重点是以经济高效的方式确保可靠性。在以科学为驱动的组织中，它应该通过业务影响力提供竞争优势。
  5. 以以分析为驱动的组织为例，应专注于SQL技能；以以工程为驱动的组织为例，应专注于ETL和DataOps能力；以以科学为驱动的组织为例，应专注于MLOps和AI能力。
  6. 以以分析为驱动的组织为例，推荐的架构是基于数据仓库（或在数据仓库基础上建立的数据湖）；以以工程为驱动的组织为例，推荐的架构是基于数据湖（或在数据湖基础上建立的数据湖）；以以科学为驱动的组织为例，推荐的架构是与数据湖相连接的ML管道架构。这将在第5章至第7章中介绍。

阅读量：2036

点赞量：0

收藏量:0