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. 以只读姿首分享，这意味着你不错将这些数据集与你我方的数据（以过甚他第三方数据集）整合，但你没出奇据的总共权