读数据质量管理：数据可靠性与数据质量问题解决之道05数据尺度化 ...

1. 批处理

1.1. 批处理在一段时间内收集数据，然后将大量数据“批处理”在离散的数据包中
1.2. 直到20世纪10年代中期，批处理都是处理分析型数据最常用的方法
1.3. 批处理比流处理要自制得多，即使是对时间要求最苛刻的处理需求也足以满足
1.4. 批处理是经过时间考验的尺度，并且仍然是公司接收大量数据最为流行且常见的方式
1.5. 当构造想要获得实时的洞察时，批处理就显得力有未逮了
1.6. 批处理关注的是尽可能多地收集数据，即使这会带来滞后
1.7. 批量流系统的数据质量（也就是数据管道中给定阶段的数据健康状况）往往更高，但是当数据在举行实时流传输时，产生错误的空间和数据质量低落的情况都会增长
2. 流处理

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. Apache Hadoop

3.1. 用于分布式存储和处理大型数据集的最流行的开源批处理框架之一
3.2. 通过将文件拆分为更小的数据包，然后将这些更易于管理的数据块分布在集群中的节点上来运行
3.3. Hadoop的托管替代品包罗Google BigQuery、Snowflake​、Microsoft Azure和Amazon Redshift
4. 流处理的数据质量

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%
  

1. >  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. AWS Kinesis

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. Apache Kafka

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. 用户具有更强的可配置性，包罗手动指定数据的保存限期
  

1. >  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. 数据尺度化

7.1. 第一个事务型数据转换层称为数据尺度化阶段
7.2. 数据转换指的是将数据从一种或多种源格式转换到目标格式的程序
7.3. 尺度化通常是你的数据在管道中经过的诸多此类转换中的第一个
7.4. 尺度化发生在噪声、模糊性和异构性最大的入口点数据上
7.5. 处理异构数据源

• 7.5.1. 数据从业者都会从不同的来源收集数据，试图为他们的用户、产物或应用程序描绘一个团体的画像
  
• 7.5.2. 关键特征
  
• 7.5.2.1. 针对耽误举行了优化
  

1. >  7.5.2.1.1. 流式端点的数据在经过优化后，可以一经创建就立即使用
3. >  7.5.2.1.2. 优化是以吞吐量为代价的，而这实际上决定了数据的完整性
5. >  7.5.2.1.3. 意味着不要期望批数据是完整的，因为无论其最终状态如何，它们都会立即通过数据管道进行推送

复制代码

• 7.5.2.2. 不具层级结构的格式
  

1. >  7.5.2.2.1. 经过标准化的数据可能会以不具层级结构的“平面”存储格式来进行存储，以提高效率和易用性
3. >  7.5.2.2.2. 将数据“转储”到某个中央存储库中

复制代码

• 7.5.2.3. 原始文件格式
  

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

复制代码

• 7.5.2.4. 可选数据字段
  

1. >  7.5.2.4.1. JSON等原始文件数据都具有可选字段
3. >  7.5.2.4.2. 任何内容都可能是默认值，并且该字段的缺失可能会（也可能不会）成为上游处理的问题

复制代码

• 7.5.2.5. 异构性
  

1. >  7.5.2.5.1. 数据来自各种不同的来源，采用各种原始的文件格式，并且与此前相同格式的数据相比，其完整性可能不同
3. >  7.5.2.5.2. 在数据管道的这个阶段，学习如何根据可预测的异构性来让数据有意义非常关键
5. >  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. 在语义上是模棱两可的
  

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

复制代码

• 7.8.3.3. 可能会导致数据错误地体现构造的关键指标
  
• 7.8.3.4. 文档是避免发生此类情况的一项关键工具，而且该文档应该具有一定的前瞻性
  
• 7.8.3.5. 歧义会以一种难以根除的方式迅速伸张，尤其是在团队快速扩张的情况下
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。