读数据工程之道：设计和构建健壮的数据系统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的不合理有效性
  

1. >  3.5.1.3.1. 可以通过使用声明式、集合论SQL语义来处理海量数据
3. >  3.5.1.3.2. 鉴于时间是数据工程团队吞吐量的主要限制因素，工程师应该采用兼具简单性和高生产率的工具
5. >  3.5.1.3.3. 专业的数据工程师可以识别SQL何时不是适合该工作的工具，并且可以选择合适的替代方案并编写代码
7. >  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. 通常在云迁移和未开发云设计中发挥核心作用
  

1. >  6.3.1.6.1. 云数据架构比本地系统更具流动性，因此传统上涉及广泛研究、较长交付周期、购买合同和硬件安装的架构决策现在通常在实施过程中做出，只是更大战略中的一个步骤

复制代码

• 6.3.1.7. 根据公司的数据成熟度和规模，数据工程师可能会与数据架构师的职责有重叠，或者承担数据架构师的职责
  

1. >  6.3.1.7.1. 数据工程师应该对架构最佳实践和方法有好的理解

复制代码

• 6.3.1.8. 数据架构师通常帮助设计作为数据工程师源系统的应用程序数据层
  

1. >  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. 建立前瞻性模子来进行预测和提供建议，然后根据及时数据评估这些模子，以各种方式提供代价
  

1. >  6.4.1.1.1. 具有前瞻性

复制代码

• 6.4.1.2. 根据常见的行业传说，数据科学家花费70%～80%的时间来收集、洗濯和准备数据
  

1. >  6.4.1.2.1. 这些数字通常反映了不成熟的数据科学和数据工程实践
3. >  6.4.1.2.2. 许多流行的数据科学框架如果没有适当地进行扩展，可能会成为瓶颈
5. >  6.4.1.2.3. 只在单一工作站上工作的数据科学家强迫自己对数据进行下采样，这使得数据准备变得更加复杂，并可能影响他们制作的模型的质量
7. >  6.4.1.2.4. 数据工程师应该尽可能地将这项工作自动化

复制代码

• 6.4.1.3. 对生产停当数据科学的需求是数据工程专业兴起的紧张驱动力
  

1. >  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. 数据工程师与数据分析师互助，为业务所需的新数据源构建管道
  

1. >  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技能
  

1. >  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研究背景和相关的高级学位
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。