读数据工程之道：设计和构建健壮的数据系统02数据工程师

1. 背景和技能

1.1. 数据工程是一个快速发展的领域，关于如何成为一名数据工程师仍然存在很多问题

1.2. 进入数据工程领域的人在教育、职业和技能方面有着不同的背景

  • 1.2.1. 每个进入该领域的人都应该投入大量的时间进行自学

1.3. 从一个邻近的领域转到数据工程是最容易的

  • 1.3.1. 软件工程

  • 1.3.2. ETL开发

  • 1.3.3. 数据库管理

  • 1.3.4. 数据科学

  • 1.3.5. 数据分析

  • 1.3.6. 这些学科倾向于“数据感知”​，并为组织中的数据角色提供良好的背景

1.4. 数据工程师还必须了解数据消费者（数据分析师和数据科学家）的需求以及数据对整个组织的更广泛影响

1.5. 数据工程是一种整体实践，最好的数据工程师通过业务和技术视角来看待他们的职责

2. 业务职责

2.1. 宏观职责并不是数据工程师独有的，而是对于任何在数据或技术领域工作的人来说都至关重要的职责

2.2. 知道如何与非技术人员和技术人员交流

  • 2.2.1. 沟通是关键，你需要能够与整个组织的人建立融洽的关系和信任

  • 2.2.2. 关注组织层次结构、谁向谁报告、人们如何互动以及存在哪些孤岛

2.3. 了解如何界定并收集业务和产品需求

  • 2.3.1. 你需要知道要构建什么，并确保你的利益相关者同意你的评估

  • 2.3.2. 培养对数据和技术决策如何影响业务的意识

2.4. 了解敏捷、DevOps和DataOps的文化基础

  • 2.4.1. 许多技术专家错误地认为这些实践可以通过技术解决

2.5. 控制成本

  • 2.5.1. 当你能够在提供巨大价值的同时保持低成本，你就会成功

2.6. 持续学习

  • 2.6.1. 数据领域让人感觉像是在以光速变化

2.7. 一个成功的数据工程师总是会放大视野以了解大局，并探索如何为企业实现巨大价值

2.8. 经常看到数据团队的成功基于他们与其他利益相关者的沟通，成败很少取决于技术

3. 技术职责

3.1. 数据工程生命周期的底层设计

  • 3.1.1. 安全

  • 3.1.2. 数据管理

  • 3.1.3. DataOps

  • 3.1.4. 数据架构

  • 3.1.5. 编排

  • 3.1.6. 软件工程

3.2. 数据工程师应该具有生产级软件工程能力

3.3. 工程师现在使用托管开源和简单的即插即用软件即服务(Software-as-a-Service，SaaS)产品

3.4. 即使在一个更抽象的世界中，软件工程最佳实践提供竞争优势，而能够深入研究代码库的深层架构细节的数据工程师在出现特定技术需求时可为他们的公司提供优势

  • 3.4.1. 无法编写生产级代码的数据工程师将受到严重阻碍，而且我们认为这种情况不会很快改变

3.5. 数据工程的主要语言

  • 3.5.1. SQL

  • 3.5.1.1. 数据库和数据湖最常用的接口

  • 3.5.1.2. SQL是一个强大的工具，可以快速解决复杂的分析和数据转换问题

  • 3.5.1.3. SQL的不合理有效性

>  3.5.1.3.1. 可以通过使用声明式、集合论SQL语义来处理海量数据

>  3.5.1.3.2. 鉴于时间是数据工程团队吞吐量的主要限制因素，工程师应该采用兼具简单性和高生产率的工具

>  3.5.1.3.3. 专业的数据工程师可以识别SQL何时不是适合该工作的工具，并且可以选择合适的替代方案并编写代码

>  3.5.1.3.4. SQL专家可能会编写查询以在自然语言处理(Natural Language Processing，NLP)管道中对原始文本进行词干化和标记化，但也会认识到使用本机Spark进行编码是这种受虐练习的更好替代方案

  • 3.5.2. Python

  • 3.5.2.1. 数据工程和数据科学之间的桥梁语言

  • 3.5.3. JVM语言

  • 3.5.3.1. Java和Scala

  • 3.5.3.2. 流行于Apache开源项目，例如Spark、Hive和Druid

  • 3.5.3.3. JVM通常比Python性能更高

  • 3.5.3.4. 可以提供对比Python API（例如，Apache Spark和Beam就是这种情况）更低级别的功能的访问

  • 3.5.4. bash

  • 3.5.4.1. Linux操作系统的命令行接口(Command Line Interface，CLI)

  • 3.5.5. R、JavaScript、Go、Rust、C/C++、C#和Julia

  • 3.5.5.1. 事实证明，JavaScript作为云数据仓库中用户定义函数的语言很受欢迎

  • 3.5.5.2. C#和PowerShell对于利用Azure和Microsoft生态系统的公司来说是必不可少的

3.6. 关注基本面以了解不会改变的东西

3.7. 关注持续的发展，了解该领域的发展方向

3.8. 新的范式和实践一直在被引入，你有责任与时俱进

3.9. 努力了解新技术将如何在生命周期中发挥作用

4. 角色的连续性

4.1. 数据工程师并非都从事相同类型的工作或拥有同样的技能组合

4.2. 数据成熟度是一个了解公司在提高数据能力时将面临的数据挑战类型的有用指导

4.3. A型数据科学家

  • 4.3.1. A代表分析(Analysis)

  • 4.3.2. 专注于理解数据并从中获得洞察力

4.4. B型数据科学家

  • 4.4.1. B代表构建(Building)

  • 4.4.2. 与A型数据科学家有着相似的背景，并拥有强大的编程技能

  • 4.4.3. B型数据科学家建立使数据科学在生产中发挥作用的系统

4.5. A型数据工程师

  • 4.5.1. A代表抽象化(Abstraction)

  • 4.5.2. 在这种情况下，数据工程师避免了无差别的繁重工作，保持数据架构尽可能抽象和直接，而不是重新发明轮子

  • 4.5.3. A型数据工程师主要通过使用完全现成的产品、托管服务和工具来管理数据工程生命周期

  • 4.5.4. A型数据工程师在各行各业、各种等级的数据成熟度的公司中工作

4.6. B型数据工程师

  • 4.6.1. B代表构建(Build)

  • 4.6.2. B型数据工程师建立数据工具和系统，以扩展和利用公司的核心竞争力和竞争优势

  • 4.6.3. 在数据成熟度范围内，B型数据工程师更常见于处于第2阶段和第3阶段（通过数据扩展和领先）的公司，或者当初始数据用例非常独特且关键以至需要自定义数据工具来开始时

5. 组织内部的数据工程师

5.1. 数据工程师不是在真空中工作

5.2. 根据他们从事的工作，他们将与技术人员和非技术人员互动，并面对不同的方向（内部和外部）​

5.3. 面向内部与面向外部的数据工程师

  • 5.3.1. 面向外部的数据工程师通常与面向外部的应用程序的用户保持一致

  • 5.3.1.1. 社交媒体应用程序、物联网(Internet of Things，IoT)设备和电子商务平台

  • 5.3.2. 面向外部的数据工程带来了一系列独特的问题

  • 5.3.2.1. 面向外部的查询引擎通常比面向内部的系统处理更大的并发负载

  • 5.3.2.2. 工程师还需要考虑对用户可以运行的查询进行严格限制，以限制任何单个用户对基础设施的影响

  • 5.3.2.3. 安全性对于外部查询来说是一个更为复杂和敏感的问题，尤其是当查询的数据是多租户

  • 5.3.3. 面向内部的数据工程师通常关注对业务和内部利益相关者的至关重要的需求活动

  • 5.3.3.1. 为BI仪表板、报告、业务流程、数据科学以及ML模型创建和维护数据管道与数据仓库

  • 5.3.4. 面向外部和面向内部的职责经常混合在一起

  • 5.3.4.1. 在实践中，面向内部的数据通常是面向外部的数据的先决条件

  • 5.3.5. 数据工程师有两组用户，他们对查询并发性、安全性等有着截然不同的要求

6. 其他技术角色

6.1. 数据工程生命周期跨越许多责任领域

6.2. 数据工程师直接或间接（通过经理）与许多组织单位互动，担任着各种角色的纽带

  • 6.2.1. 数据工程师是数据生产者[如软件工程师、数据架构师和DevOps或站点可靠性工程师(Site Reliability Engineer，SRE)]与数据消费者（如数据分析师、数据科学家和机器学习工程师）之间的枢纽

  • 6.2.2. 数据工程师将与运营角色的人员（如DevOps工程师）进行交互

6.3. 上游利益相关者

  • 6.3.1. 数据架构师

  • 6.3.1.1. 数据架构师的功能在抽象级别上与数据工程师相差无几

  • 6.3.1.2. 数据架构师设计组织数据管理的蓝图，规划流程、整体数据架构和系统

  • 6.3.1.3. 还充当组织技术和非技术方面之间的桥梁

  • 6.3.1.4. 成功的数据架构师通常有丰富的工程经验所带来的“战斗伤痕”​，使他们能够指导和协助工程师，同时成功地将工程挑战传达给非技术业务利益相关者

  • 6.3.1.5. 实施跨孤岛和业务部门管理数据的政策，指导数据管理和数据治理等全球战略，并指导重大举措

  • 6.3.1.6. 通常在云迁移和未开发云设计中发挥核心作用

>  6.3.1.6.1. 云数据架构比本地系统更具流动性，因此传统上涉及广泛研究、较长交付周期、购买合同和硬件安装的架构决策现在通常在实施过程中做出，只是更大战略中的一个步骤
  • 6.3.1.7. 根据公司的数据成熟度和规模，数据工程师可能会与数据架构师的职责有重叠，或者承担数据架构师的职责
>  6.3.1.7.1. 数据工程师应该对架构最佳实践和方法有好的理解
  • 6.3.1.8. 数据架构师通常帮助设计作为数据工程师源系统的应用程序数据层
>  6.3.1.8.1. 还可以在数据工程生命周期的各个其他阶段与数据工程师进行交互

  • 6.3.2. 软件工程师

  • 6.3.2.1. 构建运行业务的软件和系统

  • 6.3.2.2. 主要负责生成数据工程师将使用和处理的内部数据

  • 6.3.2.3. 数据工程师应该与软件工程师一起工作，了解产生数据的应用程序、生成数据的数量、频率和格式，以及任何其他会影响数据工程生命周期的因素

  • 6.3.3. DevOps工程师和站点可靠性工程师

  • 6.3.3.1. DevOps和SRE通常通过运营监控来生成数据

  • 6.3.3.2. 将他们归类为数据工程师的上游，但他们也可能是下游，通过仪表板使用数据或直接与数据工程师交互以协调数据系统的操作

6.4. 下游利益相关者

  • 6.4.1. 数据科学家

  • 6.4.1.1. 建立前瞻性模型来进行预测和提供建议，然后根据实时数据评估这些模型，以各种方式提供价值

>  6.4.1.1.1. 具有前瞻性
  • 6.4.1.2. 根据常见的行业传说，数据科学家花费70%～80%的时间来收集、清洗和准备数据
>  6.4.1.2.1. 这些数字通常反映了不成熟的数据科学和数据工程实践

>  6.4.1.2.2. 许多流行的数据科学框架如果没有适当地进行扩展，可能会成为瓶颈

>  6.4.1.2.3. 只在单一工作站上工作的数据科学家强迫自己对数据进行下采样，这使得数据准备变得更加复杂，并可能影响他们制作的模型的质量

>  6.4.1.2.4. 数据工程师应该尽可能地将这项工作自动化
  • 6.4.1.3. 对生产就绪数据科学的需求是数据工程专业兴起的重要驱动力
>  6.4.1.3.1. 数据工程师应该帮助数据科学家实现一条生产路径

  • 6.4.2. 数据分析师

  • 6.4.2.1. 寻求了解业务绩效和趋势

  • 6.4.2.2. 通常关注过去或现在

  • 6.4.2.3. 通常在数据仓库或数据湖中运行SQL查询

  • 6.4.2.4. 利用电子表格进行计算和分析，以及各种BI工具

  • 6.4.2.5. 数据分析师是数据领域的专家，他们经常处理数据并且非常熟悉数据的定义、特征和质量问题

  • 6.4.2.6. 数据分析师的典型下游客户是业务用户、管理层和高管

  • 6.4.2.7. 数据工程师与数据分析师合作，为业务所需的新数据源构建管道

>  6.4.2.7.1. 数据分析师的主题专业知识对于提升数据质量非常有价值，他们经常以这种身份与数据工程师合作

  • 6.4.3. 机器学习工程师和人工智能研究人员

  • 6.4.3.1. 机器学习工程师（ML工程师）与数据工程师和数据科学家重叠

  • 6.4.3.2. ML工程师开发先进的ML技术、训练模型以及设计和维护在规模化生产环境中运行ML流程的基础设施

  • 6.4.3.3. ML工程师通常具有ML和深度学习技术及框架（如PyTorch或TensorFlow）的高级工作知识

  • 6.4.3.4. ML工程的世界正在滚雪球般发展，并且与数据工程中发生的许多相同的发展并行

  • 6.4.3.5. AI研究人员致力于新的、先进的ML技术

>  6.4.3.5.1. AI研究人员可能在大型科技公司、专门的知识产权初创公司(OpenAI、DeepMind)或学术机构工作
  • 6.4.3.6. 在资金充足的组织中，AI研究人员高度专业化，并与支持型工程师团队一起合作

7. 业务领导

7.1. 数据工程师还作为组织连接器在更广泛的范围内运作，通常以非技术身份

  • 7.1.1. 数据工程师要么作为集中式团队处理各种传入请求，要么作为资源被分配给特定的经理、项目或产品

7.2. 产品经理

  • 7.2.1. 产品经理监督产品开发，通常拥有产品线

  • 7.2.2. 数据工程师的背景下，这些产品被称为数据产品

  • 7.2.3. 数据产品要么是从头开始构建，要么是对现有产品的逐步改进

  • 7.2.4. 随着企业界聚焦以数据为中心，数据工程师与产品经理的交互更加频繁

  • 7.2.5. 与项目经理一样，产品经理平衡技术团队的活动与客户和业务的需求

7.3. 企业决策层数据

  • 7.3.1. C级高管越来越多地参与到数据和分析中，因为这些被认为是现代企业的重要资产

7.4. 首席执行官

  • 7.4.1. 非技术公司的首席执行官(Chief Executive Officer，CEO)通常不关心数据框架和软件的细节

  • 7.4.2. 他们与技术最高管理层角色和公司数据领导层合作定义愿景

  • 7.4.2.1. 数据工程师为了解数据的可能性提供了一个窗口

  • 7.4.2.2. 数据工程师和他们的经理维护着一张地图，说明在什么时间范围内组织内部和第三方可以使用哪些数据

7.5. 首席信息官

  • 7.5.1. 首席信息官(Chief Information Officer，CIO)是负责组织内信息技术的高级管理人员

  • 7.5.2. 一个面向内部的角色

  • 7.5.3. CIO经常与拥有良好数据文化的组织中的数据工程领导层合作

  • 7.5.3.1. 如果一个组织的数据成熟度不是很高，CIO通常会帮助塑造其数据文化

  • 7.5.3.2. CIO将与工程师和架构师合作制定重大举措，并就采用主要架构元素做出战略决策

  • 7.5.3.3. 企业资源规划(Enterprise Resource Planning，ERP)和客户关系管理(Customer Relationship Management，CRM)系统、云迁移、数据系统和面向内部的IT

7.6. 首席技术官

  • 7.6.1. 首席技术官(Chief Technology Officer，CTO)与CIO类似

  • 7.6.2. 面向外部

  • 7.6.3. CTO拥有面向外部应用程序的关键技术战略和架构，这些应用程序包括移动、Web应用程序和物联网

  • 7.6.3.1. 这些都是数据工程师的关键数据源

7.7. 首席数据官

  • 7.7.1. 首席数据官(Chief Data Officer，CDO)于2002年在Capital One创立

  • 7.7.2. 负责公司的数据资产和战略

  • 7.7.3. 专注于数据的商业效用，但应具备强大的技术基础

  • 7.7.4. 负责监督数据产品、战略、计划和核心功能，如主数据管理和隐私

  • 7.7.5. 会管理业务分析和数据工程

  • 7.7.6. 专注于交付数据所需的技术和组织

7.8. 首席分析官

  • 7.8.1. 首席分析官(Chief Analytice Officer，CAO)是CDO角色的变体

  • 7.8.2. 负责业务的分析、战略和决策制定

  • 7.8.3. 可以监督数据科学和ML，但这在很大程度上取决于公司是否有CDO或CTO角色

7.9. 首席算法官

  • 7.9.1. 首席算法官(Chief Algorithms Officer，CAO-2)是最高管理层最近的创新

  • 7.9.2. 一个高度技术性的角色，专注于数据科学和ML

  • 7.9.3. CAO-2通常具有在数据科学或ML项目中作为个人贡献者和团队领导的经验

  • 7.9.4. 具有ML研究背景和相关的高级学位

posted @ 2024-10-08 06:34  躺柒  阅读(29)  评论(0)  编辑  收藏  举报