读数据工程之道：设计和构建健壮的数据系统01数据工程概述

1. 数据工程

1.1. 自从公司开始使用数据做事，数据工程就以某种形式存在了

• 1.1.1. 预测性分析、描述性分析和报告

1.2. 数据工程师获取数据、存储数据，并准备数据供数据科学家、分析师和其他人使用

1.3. 数据工程是系统和流程的开发、实施和维护，这些系统和流程接收原始数据并生成支持下游用例（例如分析和机器学习）的高质量、一致的信息

1.4. 数据工程是安全、数据管理、数据运维(DataOps)、数据架构、编排和软件工程的交集

1.5. 数据工程师管理数据工程生命周期，从源系统获取数据开始，到为用例（例如分析或机器学习）提供数据结束

2. 数据工程生命周期

2.1. 生成

2.2. 存储

2.3. 获取

2.4. 转换

2.5. 服务

3. 数据工程师的演变

3.1. 旧的又成了新的

3.2. 早期

• 3.2.1. 1980年到2000年，从数据仓库到Web

• 3.2.2. 数据工程师的诞生可以说起源于数据仓库，最早可以追溯到20世纪70年代

• 3.2.3. 商业数据仓库在20世纪80年代初具规模，Bill Inmon于1989年正式创造了数据仓库一词

  • 3.2.3.1. 数据仓库开创了第一个可扩展分析的时代，新的大规模并行处理(Massively Parallel Processing，MPP)数据库使用多个处理器来处理市场上出现的大量数据并支持前所未有的数据量

• 3.2.4. 在IBM的工程师开发了关系数据库和结构化查询语言(Structured Query Language，SQL)之后，Oracle普及了该技术

3.3. 21世纪00年代初期

• 3.3.1. 当代数据工程的诞生

• 3.3.2. 雅虎、谷歌和亚马逊最初继续依赖20世纪90年代传统的单机关系数据库和数据仓库，将这些系统推向了极限

• 3.3.3. 一些创新允许在大规模计算集群上进行大规模分布式计算和存储

• 3.3.4. 数据的三个V

  • 3.3.4.1. 速度(velocity)

  • 3.3.4.2. 多样性(variety)

  • 3.3.4.3. 数量(volume)

• 3.3.5. 2003年，谷歌发表了一篇关于Google文件系统的论文

• 3.3.6. 在2004年发表了一篇关于MapReduce（一种超可扩展数据处理范式）的论文

• 3.3.7. 谷歌的出版物构成了数据技术的“大爆炸”和我们今天所知的数据工程的文化根基

• 3.3.8. Google的论文启发了Yahoo的工程师开发并于2006年开源了Apache Hadoop

  • 3.3.8.1. 随着各种规模和类型的公司看到他们的数据增长到数TB甚至PB，大数据工程师的时代诞生了

• 3.3.9. 亚马逊

  • 3.3.9.1. 创建了弹性计算环境（Amazon Elastic Compute Cloud，或EC2）​、无限可扩展的存储系统（Amazon Simple Storage Service，或S3）​、高度可扩展的NoSQL数据库(Amazon DynamoDB)和许多其他核心数据构建块

  • 3.3.9.2. 亚马逊选择通过Amazon Web Services(AWS)为内部和外部消费提供这些服务，成为第一个流行的公有云

  • 3.3.9.3. AWS通过虚拟化和转售巨大的商品硬件池创建了一个超灵活的即付即得资源市场

    3.3.9.3.1. 简单地从AWS租用计算和存储，无须为数据中心购买硬件

• 3.3.10. Google Cloud、微软Azure和DigitalOcean

  • 3.3.10.1. 公有云可以说是21世纪最重要的创新之一，它引发了软件和数据应用程序开发与部署方式的革命

3.4. 21世纪00年代和21世纪10年代

• 3.4.1. 大数据工程

• 3.4.2. 任何企业都可以使用顶级科技公司使用的相同的前沿数据工具

• 3.4.3. 从批处理计算到事件流的转变，开创了大“实时”数据的新时代

• 3.4.4. Hadoop、Apache Pig、Apache Hive、Dremel、Apache HBase、Apache Storm、Apache Cassandra、Apache Spark、Presto以及出现的许多其他新技术

• 3.4.5. 大数据工程师必须精通软件开发和底层基础设施黑客技术

  • 3.4.5.1. Hadoop、YARN、Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)和MapReduce在内的Hadoop生态系统

• 3.4.6. 大数据很快成为其自身成功的牺牲品

  • 3.4.6.1. 大数据抓住了试图理解不断增长的数据量的公司的想象力，以及销售大数据工具和服务的公司无休止的营销

  • 3.4.6.2. 没有足够的时间来提供业务的洞察力和价值

• 3.4.7. 大数据一词本质上是描述处理大量数据的特定时间和方法的遗留物

  • 3.4.7.1. 如今，数据的移动速度比以往任何时候都快，而且数据增长越来越大，但是大数据处理已经变得如此容易理解，以至于它不再是一个单独的术语

  • 3.4.7.2. 每家公司都旨在解决其数据问题而不用关心实际数据大小

  • 3.4.7.3. 大数据工程师现在只是数据工程师

3.5. 21世纪20年代

• 3.5.1. 数据生命周期工程

• 3.5.2. 包括现代数据栈，代表了一组现成的开源和第三方产品，这些产品组合起来可以让分析师的工作更轻松

• 3.5.3. 虽然数据工程师保持低级数据编程技能并根据需要使用这些技能，但他们越来越多地发现自己的角色侧重于价值链中更高层次

  • 3.5.3.1. 安全

  • 3.5.3.2. 数据管理

  • 3.5.3.3. DataOps

  • 3.5.3.4. 数据架构

  • 3.5.3.5. 编排

  • 3.5.3.6. 一般数据生命周期管理

• 3.5.4. 开源项目和服务不再关注谁拥有“最大数据”​，而是越来越关注管理和治理数据，使其更易于使用和发现，并提高其质量

• 3.5.5. 设计管道时，关心隐私、匿名化、数据垃圾收集和法规遵从性

• 3.5.6. 强调去中心化和敏捷性，这与传统的企业命令-控制型方法形成鲜明对比

• 3.5.7. 数据生命周期管理的黄金时代

  • 3.5.7.1. 管理数据工程生命周期的数据工程师拥有比以往更好的工具和技术

4. 数据工程与数据科学

4.1. 数据工程与数据科学和分析学是分开的

• 4.1.1. 数据工程位于数据科学的上游

  • 4.1.1.1. 意味着数据工程师提供数据科学家使用的输入（数据工程的下游）

• 4.1.2. 数据科学家将这些输入转化为有用的东西

4.2. 数据科学需求层次

• 4.2.1. 收集

• 4.2.2. 移动/存储

• 4.2.3. 探索/转变

• 4.2.4. 复合/标签

• 4.2.5. 学习/优化

4.3. 数据科学家通常没有接受过设计生产级数据系统的培训，他们最终会随意地做这项工作，因为他们缺乏数据工程师的支持和资源

• 4.3.1. 在理想情况下，数据科学家应该将90%以上的时间专注于金字塔的顶层：分析、实验和ML

• 4.3.2. 当数据工程师专注于层次结构的这些底层部分时，他们为数据科学家的成功奠定了坚实的基础

4.4. 随着数据科学推动高级分析和ML，数据工程跨越了获取数据和从数据中获取价值之间的鸿沟

• 4.4.1. 认为数据工程与数据科学具有同等的重要性和可见性，数据工程师在使数据科学在生产中取得成功方面发挥着至关重要的作用

5. 数据工程技能和活动

5.1. 数据工程师的技能集包含数据工程的“底层设计"

• 5.1.1. 安全、数据管理、DataOps、数据架构和软件工程

• 5.1.2. 该技能集需要了解如何评估数据工具以及它们如何在整个数据工程生命周期中相互配合

• 5.1.3. 必须沿着成本、敏捷性、可扩展性、简单性、复用性和互操作性等轴线不断优化

5.2. 数据工程师需要知道并理解如何使用少数强大的庞大技术（Hadoop、Spark、Teradata、Hive等）来创建数据解决方案

• 5.2.1. 他们的工作将致力于集群管理和维护、管理开销、写管道和转换作业，以及其他任务

5.3. 数据工程师现在专注于平衡能够为企业带来价值的最简单、最具成本效益的最佳服务

5.4. 数据工程师通常不直接构建ML模型、创建报告或仪表板、执行数据分析、构建关键绩效指标(KPI)或开发软件应用程序

5.5. 数据工程师应该对这些领域有很好的理解，以便更好地为利益相关者提供服务

6. 数据成熟度

6.1. 数据成熟度是指整个组织向着更高的数据利用率、功能和集成的方向发展，但数据成熟度不仅仅取决于公司的年龄或收入

6.2. 重要的是如何利用数据作为竞争优势

6.3. 三个阶段

• 6.3.1. 从数据开始

  • 6.3.1.1. 根据定义，一个开始使用数据的公司处于其数据成熟度的早期阶段

  • 6.3.1.2. 数据团队很小，人数通常只有个位数

    6.3.1.2.1. 在这个阶段，数据工程师通常是多面手，通常会扮演其他几个角色，例如数据科学家或软件工程师

  • 6.3.1.3. 数据工程师的目标是快速行动、获得牵引力并增加价值

  • 6.3.1.4. 从数据中获取价值的实用性通常不为人所知，但这种愿望是存在的

    6.3.1.4.1. 报告或分析缺乏正式的结构，大多数数据请求都是临时性的

  • 6.3.1.5. 没有办法以可扩展和可重复的方式将这些模型部署到生产中

  • 6.3.1.6. 主要来自在没有足够的数据成熟度或数据工程支持的情况下参与不成熟的数据科学项目的个人经验

  • 6.3.1.7. 数据工程师应该关注

    6.3.1.7.1. 获得包括执行管理层在内的主要利益相关者的支持

    6.3.1.7.1.1. 理想情况下，数据工程师应该有一个关键举措的发起人来设计和构建数据架构以支持公司的目标

    6.3.1.7.2. 定义正确的数据架构（通常是单独的，因为数据架构可能不可用）

    6.3.1.7.3. 识别和审计将支持关键举措的数据，并在你设计的数据架构内运行

    6.3.1.7.4. 为未来的数据分析师和数据科学家构建坚实的数据基础，以生成具有竞争价值的报告和模型

    6.3.1.7.4.1. 你可能还必须生成这些报告和模型，直到雇用该团队

  • 6.3.1.8. 如果数据没有带来很多可见的成功，组织的意志力可能会减弱

  • 6.3.1.9. 走出去与人交谈，避免孤岛工作

  • 6.3.1.10. 避免无差别的繁重工作

  • 6.3.1.11. 仅在可以创造竞争优势的地方构建自定义解决方案和代码

• 6.3.2. 用数据扩展

  • 6.3.2.1. 在这个阶段，一家公司已经摆脱了临时数据请求并拥有正式的数据实践

  • 6.3.2.2. 现在的挑战是创建可扩展的数据架构并为公司真正的数据驱动的未来做规划

  • 6.3.2.3. 数据工程角色从通才转变为专家，人们专注于数据工程生命周期的特定方面

  • 6.3.2.4. 数据工程师的目标

    6.3.2.4.1. 建立正式的数据实践

    6.3.2.4.2. 创建可扩展且健壮的数据架构

    6.3.2.4.3. 采用DevOps和DataOps实践

    6.3.2.4.4. 建立支持ML的系统

    6.3.2.4.5. 继续避免无差别的繁重工作，只有在产生竞争优势时才进行自定义

  • 6.3.2.5. 随着我们对数据的处理变得越来越复杂，人们很想采用基于硅谷公司社会证明的尖端技术

    6.3.2.5.1. 这很少能很好地利用你的时间和精力

  • 6.3.2.6. 扩展的主要瓶颈不是集群节点、存储或技术，而是数据工程团队

  • 6.3.2.7. 你会很想把自己定位成一名技术专家，一个可以提供神奇产品的数据天才

    6.3.2.7.1. 将你的注意力转移到务实的领导力上，并开始过渡到下一个成熟阶段，与其他团队就数据的实用性进行沟通

    6.3.2.7.2. 教会组织如何使用和利用数据

• 6.3.3. 以数据领先

  • 6.3.3.1. 在这个阶段，公司是由数据驱动的

  • 6.3.3.2. 数据工程师创建的自动化管道和系统允许公司内部的人员进行自助分析和ML

    6.3.3.2.1. 数据工程师实施适当的控制和实践，以确保数据始终可供人员和系统使用

    6.3.3.2.2. 数据工程角色比第2阶段更加专业化

  • 6.3.3.3. 引入新的数据源是无缝的，并且产生了有形的价值

  • 6.3.3.4. 数据工程师

    6.3.3.4.1. 创建自动化以无缝引入和使用新数据

    6.3.3.4.2. 专注于构建利用数据作为竞争优势的自定义工具和系统

    6.3.3.4.3. 专注于数据的“企业级”方面

    6.3.3.4.3.1. 数据管理（包括数据治理和质量）和DataOps

    6.3.3.4.4. 在整个组织中公开和传播数据的部署工具，包括数据目录、数据血缘工具和元数据管理系统

    6.3.3.4.5. 与软件工程师、ML工程师、分析师和其他人高效协作

    6.3.3.4.6. 创建一个人们可以在这里协作和公开发言的社区和环境，无论他们的角色或职位如何

  • 6.3.3.5. 需要注意的问题

    6.3.3.5.1. 在这个阶段，自满是一个重大危险

    6.3.3.5.1.1. 一旦组织达到第3阶段，他们就必须不断专注于维护和改进，否则就有退回到较低阶段的风险

    6.3.3.5.2. 与其他阶段相比，技术干扰在这里是一个更大的危险

    6.3.3.5.2.1. 追求昂贵的业余项目是一种诱惑，这些项目不会为企业带来价值

    6.3.3.5.2.2. 应该只在可提供竞争优势的情况下使用自定义技术