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

1. 数据库直连

1.1. 数据可以通过网络连接直接从数据库中通过查询和读取的方式来获取

1.2. 使用ODBC或JDBC进行的

• 1.2.1. JDBC和ODBC长期以来是数据库数据获取的黄金标准，但对于许多数据工程应用程序来说，这些连接标准已经开始显示出它们年头已久

• 1.2.2. 许多数据库现在支持本地文件导出，绕过了JDBC和ODBC，直接以Parquet、ORC和Avro等格式导出数据

• 1.2.3. ODBC使用一个部署在客户端的驱动程序，将标准的ODBC API翻译成向不同数据库发出的命令

• 1.2.4. 利用ODBC驱动的应用是一个数据获取工具

  • 1.2.4.1. 数据获取工具可以通过许多小的查询或单一的大查询来拉取数据

• 1.2.5. ODBC驱动程序是基于操作系统和计算机架构提供的原生二进制文件

• 1.2.6. 一个Java驱动程序作为标准JDBC API和目标数据库的本地网络接口之间的转换层连接到一个远程数据库

• 1.2.7. JDBC提供了非凡的数据库驱动程序可移植性

• 1.2.8. Python生态系统提供翻译工具，允许Python代码与运行在本地JVM上的JDBC驱动程序通信

2. 变更数据捕获

2.1. 面向批处理的变更数据捕获

• 2.1.1. 根据最后一次从表中捕获变更的行的时间来设置过滤器的时间戳

• 2.1.2. 这个过程允许我们拉取数据变更并增量更新目标表

2.2. 连续变更数据捕获

• 2.2.1. 连续变更数据捕获捕获表的所有历史，并可以支持近实时数据获取，无论是用于实时数据库复制还是为实时流分析提供数据

• 2.2.2. 连续变更数据捕获不是通过运行定期查询来获取一批表的变化，而是将每一次对数据库的写入作为一个事件

• 2.2.3. 基于日志的变更数据捕获

  • 2.2.3.1. 数据库的二进制日志按顺序记录了数据库的每一次变化

  • 2.2.3.2. 一个变更数据捕获工具可以读取这个日志并将事件发送到一个目的地，比如Apache Kafka Debezium流平台

2.3. 变更数据捕获和数据库的备份

• 2.3.1. 变更数据捕获可以用来在数据库之间进行备份：事件被缓冲到一个数据流中并异步地写入第二个数据库

• 2.3.2. 同步复制通常要求主数据库和副本是同一类型的

  • 2.3.2.1. 同步复制的优点是从数据库可以通过作为一个读副本来分担主数据库的负载，读查询可以被重定向到副本

  • 2.3.2.2. 查询会返回与主数据库相同的结果

  • 2.3.2.3. 读副本通常用于批量数据获取模式，以允许大量扫描运行的同时不使主生产数据库过载

• 2.3.3. 异步变更数据捕获复制的优势在于松耦合的架构模式

  • 2.3.3.1. 虽然副本可能比主数据库稍有延迟，但对于分析应用程序来说通常不是问题，而且事件现在可以写入不同的目的地

  • 2.3.3.2. 运行变更数据捕获复制的同时将事件引导到对象存储和流分析处理器

2.4. 考虑因素

• 2.4.1. 变更数据捕获也不是没有代价的

• 2.4.2. 消耗各种数据库资源，如内存、磁盘带宽、存储、CPU时间和网络带宽

• 2.4.3. 在生产系统上开启变更数据捕获之前，数据工程师应该与业务开发团队合作进行测试，以避免出现操作问题

• 2.4.4. 要么只在非工作时间运行这类查询，要么使用读副本以避免给主数据库带来负担

3. API

3.1. API是一个重要性和受欢迎程度不断提高的数据

3.2. 趋势

• 3.2.1. 许多供应商为各种编程语言提供API客户端库，消除了API访问的大部分复杂性

• 3.2.2. 现在有许多数据连接器平台可以作为SaaS、开源或托管开源的形式存在

• 3.2.3. 数据共享的出现​，即通过标准平台（如BigQuery、Snowflake、Redshift或S3）交换数据的能力

3.3. 当无法使用数据共享且必须直接使用API访问的时候，不要重复发明轮子

4. 消息队列和事件流平台

4.1. 消息队列和事件流平台是从网络和移动应用程序、物联网传感器和智能设备获取实时数据的普遍方法

4.2. 消息是在单个事件层面上处理的，并且是短暂的

• 4.2.1. 一旦消息被消费，它就被确认并从队列中删除

4.3. 流将事件获取到一个有序的日志中

• 4.3.1. 日志会在你期望的时间内一直存在，允许在不同的范围内对事件进行查询、聚合，并与其他流结合，以创建可以发布给下游消费者的新的变换

4.4. 批量获取通常涉及静态工作流（获取数据、存储数据、转换数据和提供数据服务）​，而消息和流是动态的

4.5. 获取可以是非线性的，数据被发布、消费、重新发布和重新消费

4.6. 当设计你的实时获取工作流时，请记住数据如何流动

4.7. 实时数据管道的吞吐量

• 4.7.1. 消息和事件的流动应该有尽可能小的延迟，这意味着你应该提供足够大的分区（或分片）带宽和吞吐量

4.8. 管理你的流平台可能需要大量的开销

• 4.8.1. 考虑为你的实时获取管道使用托管服务，将你的注意力集中在如何从你的实时数据中获得价值

5. 托管数据连接器

5.1. 建议使用托管连接器平台，而不是自建和管理连接器

6. 使用对象存储移动数据

6.1. 对象存储是一个公有云中支持存储海量数据的多租户系统

• 6.1.1. 使得对象存储成为在数据湖、团队之间、组织之间转移数据的理想选择

6.2. 对象存储是处理文件交换的最理想和最安全的方式

6.3. 公有云存储实现了最新的安全标准，具有强大的可扩展性和可靠性，接受任意类型和大小的文件，并且提供高性能的数据移动

7. 电子数据交换（EDI）

7.1. 有些古老的文件交换方式，如通过电子邮件或闪存驱动器

7.2. 一些数据源由于IT系统过于老旧或人类过程限制，不支持更现代的数据传输手段

8. 数据库和文件导出

8.1. 导出查询可以按照查询键值范围或一次查询一个分区分解成若干个较小的导出

8.2. 读副本也可以减轻数据库负载

• 8.2.1. 如果导出每天发生很多次，并且与源系统的高负载时间段相吻合，那么读副本就特别合适

8.3. 主要的云数据仓库对直接文件导出进行了高度优化

9. 常见文件格式的问题

9.1. CSV不是一种统一的格式

• 9.1.1. CSV的默认分割符是英语中最常见的字符——逗号

• 9.1.2. CSV也没有对模式信息进行原生编码或直接支持嵌套结构

• 9.1.3. 自动检测是许多云环境中提供的便利功能，但不适合用于生产环境的获取

• 9.1.4. 工程师应该在文件元数据中记录CSV编码和模式细节

9.2. 更加强大的导出格式包括Parquet、Avro、Arrow和ORC或JSON

• 9.2.1. 对模式信息进行原生编码，并且可以无须特别干预地处理任意字符串数据

9.3. 对于列式数据库，列式格式(Parquet、Arrow、ORC)允许更有效的数据导出，因为列可以在格式之间直接转码

9.4. Arrow文件格式被设计为直接将数据映射到处理引擎内存中，在数据湖环境中提供高性能

10. 命令行

10.1. 命令行(shell)是一个你可以通过执行命令来获取数据的接口

10.2. 命令行可以用来为几乎所有的软件工具编写工作流，而且命令行脚本仍然被广泛用于数据获取过程

10.3. 云供应商通常提供强大的基于CLI的工具

11. SSH

11.1. SSH不是一种获取策略，而是一种与其他获取策略一起使用的协议

11.2. SSH可以与SCP一起用于文件传输

11.3. SSH隧道被用来允许安全、隔离地连接到数据库

11.4. 应用程序数据库不应该直接暴露在互联网上

• 11.4.1. 工程师可以设置一个堡垒主机，即一个可以连接到相关数据库的中间主机实例

• 11.4.2. 这台主机暴露在互联网上，只能从指定的IP地址到指定的端口进行最小的访问

12. SFTP和SCP

12.1. SFTP对许多企业来说仍然是一个实际的选择

12.2. SCP是一个通过SSH连接运行的文件交换协议

• 12.2.1. 在配置正确的情况下，SCP可以成为一个安全的文件传输选项

• 12.2.2. 建议增加额外的网络访问控制（深度防御）来加强SCP的安全性

13. Webhook

13.1. 使用Webhook时，数据提供者定义了一个API请求规范，但是数据提供者进行API调用，而不是被调用

13.2. 数据消费者负责提供一个API服务端供数据提供者调用

13.3. 消费者负责获取每个API请求中的数据，并对数据进行聚合、存储和处理

13.4. 基于Webhook的数据获取架构可能很脆弱，难以维护且低效

13.5. 使用适当的工具，数据工程师可以建立更强大的Webhook架构，并降低维护和基础设施成本

14. 网络接口

14.1. 用于数据访问的网络接口对数据工程师来说仍然是一个现实的选择

15. 网络抓取

15.1. 网络抓取通过梳理网页的各种HTML元素自动从网页上抽取数据

15.2. 网络抓取对数据工程生命周期的处理阶段有着有趣的影响

15.3. 问问你自己，你是否应该进行网络抓取，或者是否可以从第三方获得数据

15.4. 要注意你行为的法律影响

15.5. 网页会不断地改变HTML元素结构，更新你的网络抓取程序会变得很麻烦

16. 用于数据迁移的传输设备

16.1. 对于海量的数据（100TB或更多）​，直接通过互联网传输可能是一个缓慢而高成本的过程

16.2. 最快最有效的数据传输方式不是通过网络，而是通过卡车来移动数据

16.3. 通过物理的“装硬盘的箱子”发送数据的能力

• 16.3.1. 只需订购一个存储设备（称为传输设备）从你的服务器上加载数据，然后把它送回可以帮你上传数据的云供应商

16.4. 如果你的数据规模在100TB左右，那么建议你使用一个传输设备

• 16.4.1. 用半挂车送来的传输设备

16.5. 传输设备对于创建混合云或多云很方便

16.6. 当数据量很大时，物理传输设备是一个更便宜的选择

16.7. 请记住传输设备和数据迁移服务是一次性的数据获取，不建议用于持续的获取工作

17. 数据共享

17.1. 数据共享已经变成了消费数据的一种流行方案

17.2. 数据提供者会向第三方用户免费或有偿提供数据

17.3. 以只读方式共享，这意味着你可以将这些数据集与你自己的数据（以及其他第三方数据集）整合，但你没有数据的所有权