1.1. 批处理在一段时间内收集数据，然后将大量数据“批处理”在离散的数据包中

1.2. 直到20世纪10年代中期，批处理都是处理分析型数据最常用的方法

1.3. 批处理比流处理要便宜得多，即使是对时间要求最苛刻的处理需求也足以满足

1.4. 批处理是经过时间考验的标准，并且仍然是公司接收大量数据最为流行且常见的方式

1.5. 当组织想要获得实时的洞察时，批处理就显得力不从心了

1.6. 批处理关注的是尽可能多地收集数据，即使这会带来滞后

1.7. 批量流系统的数据质量（也就是数据管道中给定阶段的数据健康状况）往往更高，但是当数据在进行实时流传输时，产生错误的空间和数据质量降低的情况都会增加

2.1. 流处理是一个较长的过程，但几乎可以立即处理数据

2.2. 随着各行各业的公司越来越依赖实时数据，Apache Kafka和Amazon Kinesis等技术让流数据相对以前来说更易于大规模访问，价格也更实惠

2.3. 实时访问数据将改变游戏规则，这也为依赖数据而不断更新的产品和服务带来了更高的投资回报

2.3.1. 流处理可以填补空白的地方

2.4. 流处理的一个简单示例是实时拼车应用程序的请求

2.4.1. 使用实时流数据，这些拼车应用程序可以将实时位置、价格和司机数据拼凑在一起，从而立即将用户与行程联系起来

2.5. 最常见的开源技术包括来自Apache的解决方案

2.5.1. Spark、Kafka、Flink、Storm、Samza和Flume

2.6. 使用最广泛的还是Apache Spark和Apache Kafka

2.6.1. Apache Spark采用微批处理方法，将传入的流拆分成更小的数据包

2.6.2. Apache Kafka以近乎实时的方式分析事件

2.6.3. 托管替代方案包括Databricks、Cloudera和Azure

3.1. 用于分布式存储和处理大型数据集的最流行的开源批处理框架之一

3.2. 通过将文件拆分为更小的数据包，然后将这些更易于管理的数据块分布在集群中的节点上来运行

3.3. Hadoop的托管替代品包括Google BigQuery、Snowflake、Microsoft Azure和Amazon Redshift

4.1. 批处理和流处理之间的主要区别在于每个批处理所包含的数据量和处理速度

4.2. 流处理关注的是尽可能快地收集数据，尽管这会导致一些损失

4.3. 传统来说，数据质量是通过测试来强制执行的

4.3.1. 你分批接收数据，并希望数据按照你认为必要的时间间隔到达

4.3.2. 根据其对数据的假设编写测试，但其实不太可能通过编写测试来解释所有可能的结果

4.4. 数据质量往往会出现新的错误，而工程师会急于在问题影响下游表格和用户前进行根因分析

4.4.1. 编写一个测试以防止该问题再次发生

4.4.2. 测试很难扩展

4.4.2.1. 测试仅仅涵盖了潜在数据质量问题的20%

4.4.2.1.1. “已知的未知”

4.4.3. 从任何地方的数十到上百个内部和外部数据源中获取数据，而传统的处理和测试方法已经开始过时

4.5. 如果确保批处理数据的可靠性都很困难的话，你可以想象一下对每分每秒都在演变的数据运行和扩展测试会多么难以实现

4.6. 虽然单元测试、功能测试和集成测试等传统数据质量框架可能包含了一些基础功能，但它们无法在难以进行预测和实时演变的数据集中进行扩展

4.6.1. 为了确保提供给这些实时用例的数据是可靠的，数据团队在处理流处理时需要重新考虑所使用的数据质量方法

4.7. 流式解决方案可以将数据直接实时传输到分析系统中或传输到数据仓库进行存储、处理和转换

4.8. 当你在AWS Kinesis和Apache Kafka之间进行选择时，实际上还是要取决于数据团队的需求

4.8.1. AWS Kinesis等托管解决方案易于设置，寻求快速实现价值的小型数据团队将受益于这种软件即服务(SaaS)的产品

4.8.2. 拥有更具体需求的大型数据团队可能会发现Apache Kafka更符合要求

5.1. 亚马逊的Kinesis服务是一种流行的无服务器流处理工具，适用于依赖实时数据的应用程序

5.2. 容量可“按需”扩展，从而减少了在数据量增加前预置和扩展资源的需要

5.3. 可以被配置为从其他AWS服务、微服务、应用程序日志、移动数据和传感器数据等来源捕获数据

5.3.1. 该服务可以扩展到每秒流式传输千兆字节（GB级）的数据

5.4. 优势

5.4.1. 按需可用性

5.4.1.1. 按需预置设定了行业标准，这意味着资源组可以在负载增加时进行扩展

5.4.2. 成本效益

5.4.2.1. 付费方案与资源使用量成正比

5.4.2.2. 流式服务的数据吞吐量可能会随着时间的推移而急剧变化

5.4.3. 完善的软件开发工具包(Software Development Kit，SDK)

5.4.3.1. 支持Java、Android、.NET和Go等多种编程语言的开发

5.4.3.2. Kafka仅支持Java

5.4.4. 与AWS基础设施的集成

5.4.4.1. 与Amazon S3、Amazon Redshift和其他亚马逊数据服务的集成要容易得多

6.1. 一个开源事件的流式平台

6.1.1. 一个具有高学习曲线的应用程序

6.1.2. 意味着它为给定应用程序中的Kafka流、生产者和消费者提供了大量的颗粒度设置

6.2. 模式注册表

6.3. Kafka Streams是支持流式数据进出Kafka集群的客户端库

6.4. 服务提供数据流和集成层以及流式分析

6.5. Kafka流式服务针对低延迟进行了优化

6.5.1. 宣称其延迟低至2ms，但会受限于网络吞吐量

6.6. 优点

6.6.1. 开源社区

6.6.1.1. 该工具可以免费使用

6.6.2. 增加可定制性

6.6.2.1. 比Kinesis等集成度更高的流式解决方案具有更陡的学习曲线

6.6.2.2. 用户具有更强的可配置性，包括手动指定数据的保留期限

6.6.2.2.1. Kinesis将其固定为7天

6.6.3. 高吞吐量

6.6.3.1. 已被证明支持高达每秒30000条记录的吞吐量

6.6.3.2. Kinesis仅支持每秒数千条记录

6.7. Apache Kafka流通过JMX（Java管理扩展规范）报告流式指标

6.7.1. 使用JConsole等图形工具对JMX数据进行可视化

6.8. 在事务型转换中执行检查的优先级需要与该步骤中延迟超过吞吐量检查的优先级保持一致

6.8.1. 在这个阶段避免进行吞吐量密集型的聚合检查

6.8.2. 将历史模式与传入模式进行比较，或者跟踪随时间的推移所扫描的字节量的变化情况

6.8.3. 确保传入的数据不会超过现有容量、存储和内存的限制

7.1. 第一个事务型数据转换层称为数据标准化阶段

7.2. 数据转换指的是将数据从一种或多种源格式转换到目标格式的程序

7.3. 标准化通常是你的数据在管道中经过的诸多此类转换中的第一个

7.4. 标准化发生在噪声、模糊性和异构性最大的入口点数据上

7.5. 处理异构数据源

7.5.1. 数据从业者都会从不同的来源收集数据，试图为他们的用户、产品或应用程序描绘一个整体的画像

7.5.2. 关键特征

7.5.2.1. 针对延迟进行了优化

7.5.2.1.1. 流式端点的数据在经过优化后，可以一经创建就立即使用

7.5.2.1.2. 优化是以吞吐量为代价的，而这实际上决定了数据的完整性

7.5.2.1.3. 意味着不要期望批数据是完整的，因为无论其最终状态如何，它们都会立即通过数据管道进行推送

7.5.2.2. 不具层级结构的格式

7.5.2.2.1. 经过标准化的数据可能会以不具层级结构的“平面”存储格式来进行存储，以提高效率和易用性

7.5.2.2.2. 将数据“转储”到某个中央存储库中

7.5.2.3. 原始文件格式

7.5.2.3.1. 除了以“平面”形式存储外，入口点数据还可能反映流式传输的原始文件格式

7.5.2.4. 可选数据字段

7.5.2.4.1. JSON等原始文件数据都具有可选字段

7.5.2.4.2. 任何内容都可能是默认值，并且该字段的缺失可能会（也可能不会）成为上游处理的问题

7.5.2.5. 异构性

7.5.2.5.1. 数据来自各种不同的来源，采用各种原始的文件格式，并且与此前相同格式的数据相比，其完整性可能不同

7.5.2.5.2. 在数据管道的这个阶段，学习如何根据可预测的异构性来让数据有意义非常关键

7.5.2.5.3. 要确保数据一旦被存储和处理就能轻松地进行转换，以最大化其价值

7.5.3. 数据湖通常是入口点数据的首选存储解决方案，因为它们对可接受数据类型的严格限制要小得多

7.5.3.1. 数据转储为数据湖格式，然后依靠初始级别的事务型转换将这些数据提升为数据仓库中的结构化形式

7.5.3.2. 定期将数据移动到数据仓库中，那么像AWS Glue之类的转换层在这一阶段会很有帮助

7.6. 模式检查

7.6.1. 模式检查是指验证数据结构是否符合我们预期的步骤

7.6.1.1. 是否存在必要的字段

7.6.1.2. 所包含的数据是不是我们所需要的格式

7.6.2. 模式让我们知道第一次“解包”数据时会发生什么

7.6.3. 改变模式是数据损坏的一个主要原因

7.6.4. 主动检查这类错误，这通常意味着保持对预期模式的记录，并且在它们发生变化时以某种可见的方式进行记录

7.7. 类型强制转换

7.7.1. 类型强制转换是在数据不符合格式要求并且必须“强制”转换为新格式时去执行的过程

7.7.2. 注意类型强制转换和一般转换中的问题，它们听起来很简单，但一定会产生一些“恶意”漏洞和错误

7.8. 数据中的句法歧义与语义歧义

7.8.1. 数据可能是模棱两可的，每个人都知道这一点，但这种模棱两可的表现形式却各不相同

7.8.2. 句法歧义指的是数据呈现方式的混乱

7.8.2.1. 数据中的句法歧义，可能给数据团队带来摩擦

7.8.3. 语义歧义指的是系统中数据用途的混淆

7.8.3.1. 更有害

7.8.3.2. 在语义上是模棱两可的

7.8.3.2.1. 无法就该字段的用途达成一致

7.8.3.3. 可能会导致数据错误地表示组织的关键指标

7.8.3.4. 文档是避免发生此类情况的一项关键工具，而且该文档应该具有一定的前瞻性

7.8.3.5. 歧义会以一种难以根除的方式迅速蔓延，尤其是在团队快速扩张的情况下