读数据工程之道：设计和构建健壮的数据系统21数据获取

1. 数据获取

1.1. 数据获取是将数据从一个地方移动到另一个地方的过程

1.1.1. 数据获取与系统内部获取是不同的

1.2. 数据获取是数据工程生命周期中将数据从源系统移入存储的一个中间步骤

1.3. 数据集成则是将来自不同来源系统的数据组合到一个新的数据集

1.4. 数据获取的核心是数据管道，将管道连接到其他管道，确保数据持续安全地流向目的地

1.5. 在你作为数据工程师>数据工程师的工作中，数据获取可能会消耗你很大一部分的时间和精力

2. 数据管道

2.1. 数据管道从源系统开始，但获取是数据工程师>数据工程师开始投入精力设计数据管道的最初阶段

2.2. 数据管道是在数据工程生命周期的各个阶段用来移动数据的架构、系统和过程的组合

2.2.1. 一个传统的ETL系统，数据从本地事务处理系统中获取，通过单一的处理器，然后写入数据仓库中
2.2.2. 一个基于云的数据管道，从100个数据源提取数据，将其合并到20个宽表，训练5个机器学习模型，然后再将它们部署到生产环境中，并持续监控性能

2.3. 数据管道应该足够灵活，以适应数据工程生命周期中的需求

3. 上游利益相关者

3.1. 负责生成数据的人（通常是软件工程师）与为分析和数据科学准备这些数据的数据工程师>数据工程师之间往往存在着明显的脱节

3.2. 数据工程师>数据工程师可以通过邀请软件工程师成为数据项目成果的利益相关者来提高数据质量

3.3. 绝大多数的软件工程师都很清楚分析和数据科学的价值，但不一定有动机直接为数据工程工作做出贡献

3.4. 简单地改善沟通是关键的第一步

3.5. 数据工程师>数据工程师还可以向团队成员、管理层，特别是产品经理强调软件工程师的贡献

3.6. 将稀缺的软件工程师分配到与数据工程师>数据工程师的合作中来

4. 下游利益相关者

4.1. 数据工程师>数据工程师专注于数据从业者和技术领导者，如数据科学家、分析师和首席技术官

4.2. 将数据工程视为一项业务，并认识到你的客户是谁

4.3. 获取过程的自动化具有重要的价值，特别对于像市场营销这样控制大量预算并处于业务收入核心的部门

4.4. 数据工程师>数据工程师和其他数据从业者还是应该为高管提供关于数据驱动业务的最佳结构指导

4.5. 要强调降低数据生产者和数据工程师>数据工程师之间的障碍的价值，同时支持高管们打破孤岛，建立激励机制，形成更统一的数据驱动文化

4.6. 坦诚地与利益相关者尽早并且频繁沟通，将很大程度上为你的数据获取增加价值

5. 底层设计

5.1. 安全

5.1.1. 移动数据会带来安全风险，因为你必须在不同地点之间传输数据
5.1.2. 最不希望的就是在移动过程中破坏数据
5.1.3. 在VPC内移动的数据应该使用安全的终端，并且永远不要离开VPC的范围
5.1.4. 如果你需要在云和本地网络之间发送数据，请使用虚拟专用网络或专用私人连接
5.1.5. 安全是一项好的投资。如果你的数据需要经过公共互联网，请确保传输是加密的
5.1.6. 在网络上对数据进行加密始终是一个好的实践

5.2. 数据管理

5.2.1. 数据管理自然地从数据获取开始
5.2.2. 这是数据血缘和数据目录的起点
5.2.3. 数据工程师>数据工程师需要考虑模式变化、道德、隐私和合规
5.2.4. 将不可避免地遇到敏感数据
- 5.2.4.1. 在确实有必要跟踪敏感的个人信息的时候，通常的做法是在模型训练和分析中应用令牌化对敏感信息做匿名处理
- 5.2.4.2. 数据工程师>数据工程师在某些情况下会不可避免地与高度敏感的数据打交道
- 5.2.4.3. 工程师在处理敏感数据时必须按照最高的道德标准行事
- 5.2.4.4. 在涉及敏感数据的情况下，尽可能实现无接触生产环境
  
  5.2.4.4.1. 意味着工程师可以在开发和预生产环境中用模拟或脱敏的数据来开发和测试代码，然后用自动化的方式将代码部署到生产中
- 5.2.4.5. 工程师应该努力实现无接触生产环境的目标，但在开发和预生产环境中难免会出现问题无法完全解决的情况
  
  5.2.4.5.1. 对生产环境中敏感数据的访问至少需要两个人批准
  
  5.2.4.5.2. 种访问应严格限制在特定问题上，并附有截止日期
- 5.2.4.6. 对人为问题的技术解决方案要保持警惕
- 5.2.4.7. 加密和令牌化往往被当作处理隐私数据的灵丹妙药
  
  5.2.4.7.1. 单字段加密存在合规的用例，但要防止形式主义的加密
  
  5.2.4.7.2. 在令牌化方面，使用常识并评估数据访问情况

5.3. DataOps

5.3.1. 可靠的数据管道是数据工程生命周期的基石
5.3.2. 确保你的数据管道得到合适的监控是实现可靠性和有效的故障响应的关键步骤
5.3.3. 如果说在数据工程的生命周期中，有一个阶段的监控是至关重要的，那就是获取阶段
5.3.4. 监控是关键，了解你所依赖的上游系统的行为以及它们如何生成数据也是关键
- 5.3.4.1. 正常运行时间、延迟和处理的数据量是很好的开始
- 5.3.4.2. 你应该知道你关注的每个时间间隔产生的事件数量（事件数/分钟，事件数/秒，等等）以及每个事件的平均大小
- 5.3.4.3. 你的数据管道应该同时满足所获取的事件的频率和大小的要求
5.3.5. 并不存在对于第三方故障的通用的响应计划
- 5.3.5.1. 如果你可以做故障转移，最好将服务放在另一个区域或地域
5.3.6. 数据质量测试
- 5.3.6.1. 数据称为无声的杀手
- 5.3.6.2. 如果优质且有效的数据是当今企业成功的基础，那么使用糟糕的数据来做决策比没有数据要更糟糕
- 5.3.6.3. 糟糕的数据给企业带来了难以计数的损失，这有时被称为数据灾难
- 5.3.6.4. 数据是有熵力的，它经常在没有警告的情况下以意想不到的方式变化
- 5.3.6.5. DevOps和DataOps之间的内在区别之一是软件回归只有在部署变更时才会遇到，而数据经常因为我们无法控制的事件而出现回归现象
  
  5.3.6.5.1. DevOps工程师通常能够使用二元条件来检测问题
  
  5.3.6.5.2. 在数据空间，回归往往表现为微妙的统计异常
  
  5.3.6.5.2.1. 一些数据故障是立即可见的
  
  5.3.6.5.2.2. 真正危险的数据故障是悄无声息的，可能来自企业内部或外部
  
  5.3.6.5.2.3. 应用程序开发人员可能会改变数据库字段的含义，而不与数据团队进行充分的沟通
  
  5.3.6.5.2.4. 统计数据测试是一个新领域，但在未来五年内可能会急剧增长
- 5.3.6.6. 只要有可能，就与软件工程师一同从源头上解决数据质量问题
  
  5.3.6.6.1. 许多数据质量问题可以通过遵从软件工程中的基本最佳实践来处理，如记录数据变化的历史，检查（空值等）和异常处理（尝试、捕获等)

5.4. 编排

5.4.1. 所谓编排工具，指的是一个能够编排完整任务图而不是单个任务的系统
5.4.2. 编排系统可以在适当的计划时间启动每个数据获取任务
- 5.4.2.1. 当获取任务完成时，下游的处理和转换步骤会开始
- 5.4.2.2. 再往下走，处理步骤会触发更多的处理步骤
5.4.3. 获取通常位于大且复杂的数据流图的起始位置
5.4.4. 由于获取是数据工程生命周期的第一阶段，获取的数据将流入更多的处理过程，来自许多数据源的数据将以复杂的方式组合在一起
5.4.5. 处于数据成熟度早期阶段的组织可能会选择将获取过程部署为简单的cron任务
5.4.6. 随着数据管道复杂性的增加，编排工具是必要的