大数据项目管理：从规划到实现

确保数据完整性

｜

123



复杂性

实现越是简单、越是集中，测试和维护就越容易。记住，越简单越好。



性能依赖

摄取性能会受到最慢的存储系统的约束。



系统性故障风险

存储系统故障意味着所有数据都将停止流入其中的任何一个系统。



不同的批次大小

不同的存储系统按照不同的写入方式进行优化。

HDFS

和

Amazon S3

需要较大的批次，

而其他类型的系统在采用较小批次时表现更好。



难以回滚

假设存储系统出现问题，需要从一个检查点恢复。如果这个时候向所有系统写入数据，

那么恢复过程将会变得非常复杂。



版本升级

升级到一个存储系统可能需要重新启动所有摄取节点。

7.2

　验证数据管道

如果仔细阅读，你会注意到，

7.1

节描述的所有路径都涉及某种转换。



摄取

将原始格式转换为目标系统使用的格式。



增强

以某种方式转换或添加数据。

但是，在这些步骤中发生的转换可能会引入一些错误，破坏数据完整性。那么，应该如何

通过测试来确认可以信任系统呢？来看看

4

个选项：行数、唯一计数、全字节比较以及校

验和（

checksum

）比较。

7.2.1

　行数

计算行数可能是最快也是最简单的确认方法。它只需要在写入结果数据时对数据行进行简

单的统计，确认结果记录的数量与预期的数量相匹配。问题是它只在一个维度上确定保真

度，它验证了输出行数是否与预期的行数相匹配，但并没有验证记录中的内容。有时候行

数是匹配的，但由于转换失败，导致其中一列为空，或者一个数被四舍五入，丢失了精

度。因此，可以将这种方法视为一种初查，不能只依赖它来验证数据完整性。