- By : 郭, 健
片场数据管理最重要的目标之一是维护拍摄过程中记录、生成所有数据的完整性（integrity）和完全性（completeness）。这是你作为数字影像工程师（DIT）或数据管理员的责任，所以熟悉一些核心概念是很有用的。
本文是包含两部分的系列文章的第一部分，这个系列对数据管理的技术层面进行了基本介绍。我们会细看一下数据完整性究竟意味着什么，可能威胁数据完整性的潜在问题有哪些，以及校验和和哈希值算法如何协助保护数据完整性。
在后面的文章中，我们会接着讨论成功进行数据管理的第二个关键点，聊一聊清单文件以及如何使用它们来维护数据的完整性。但在本文中，我们先来谈谈数据完整性！
数据完整性
保持完整性（或“数据完整性”）意味着确保数据在整个工作周期内都是“正确的”。对于已录制的媒体文件，这意味着文件不会无意中遭到修改，并且包含和摄影机录制时相同的内容。
不过，理论上听起来很简单的事情，在现实中可能会变得棘手。试想一下，当把一个文件从摄影机卡传输到外部硬盘时，需要协同工作的硬件和软件名单会有长长的一串：
·可插拔线缆连接的不同设备
·自身带控制器和连接器的读卡器
·固态硬盘或磁盘控制器组件和缓存
·USB或雷电接口组件
·可能需要一个阵列系统（硬件或软件）
·几套文件系统（可能属于不同类型），有时需要一套虚拟文件系统（如Codex VFS），在需要的时候为卷创建文件数据
·一套带文件读写程序的操作系统，一套访问权限管理系统，RAM中的文件缓存机制，多线程支持
·……以及执行数据传输的应用程序，如Pomfort Silverstack或Offload Manager。
好消息是：文件遭到不必要的意外更改并不常见。但这也不是不可能。实体和交互设备组件的数量、实体连接器和线缆连接、独立电源供应以及不同供应商的固件和软件版本都增加了在某些情况下出错的可能性。那么，潜在的后果是什么？让我们看一些在文件传输或存储过程中可能出现问题的例子：
·空文件：这可能发生在复制期间，创建文件时，写入其内容不成功。可能的原因：存储媒介满了、访问权限不足或创建文件后进程中止。
·文件被缩短：这可能由复制过程中不完整的写入进程导致。可能的原因：拷贝中止、存储媒介满了、电源或连接失败、未能恢复进程。
文件内容错误：出现这种问题有几种不同的可能原因：这可能发生在数据块写入过程中出现混乱的时候，比如多线程问题或错误。数据块被分配到卷上但没被写入时也会发生这种情况。此时格式化摄影机卡前已经写入的旧内容就可能“喧宾夺主”，显示为错误内容。另一种可能性是在传输或存储过程中出现位错误，比如组件或存储/内存出现故障或不可靠。文件的内容也可能完全错误或损坏，比如文件系统结构损坏。
·编辑时改了文件：比方说，软件打开文件时覆盖了整个文件或文件的部分内容，此时文件可能会被编辑改动，这可能是用户的无心操作，或用户没能发现这些变动。
如何实现数据完整性
好，咱不提那些“恐怖场景”了。你现在可能会问自己，为了协助维护数据完整性，自己已经做了哪些工作。下面我们将向你介绍有助于检测上述问题的核心概念：独立文件校验和的计算和验证。
首先，让我们看看校验和是什么，如何使用哈希值算法来创建校验和，以及如何使用它们来检查文件内容的完整性。
为了在传输或存储过程中检测文件中的错误，你通常需要创建校验和。此处的理念是用一套算法（校验和函数），从任意大小的数据块（比如校验的文件本身）创建一小块数据（校验和）。好的校验和函数能实现这一点：在给定文件内容任意部分发生变化时，其校验和会有非常（非常、非常）高的概率变得不同。校验和函数也是确定性的，因此你可以随时重新计算校验和。
换句话说：
当你在文件被传输或复制后计算校验和，你可以通过比较此时算出的校验和和之前为该文件（比如在源卷上）算出的校验和，以非常（非常、非常）高的概率确保其内容保持不变。如果两个校验和不相等，则可以肯定文件内容出现了变更。如果校验和相等，则可以认为文件内容未被修改。
这是在软件内以校验和检测文件更改以检查文件完整性的基本原则。
校验和方式很多样，有些用于非常小的数据片段，有些甚至用于错误校正。但确保文件数据完整性最适合和最常用的校验和函数是哈希值算法。
哈希算法
哈希函数会将任意大小的数据块（即文件内容）映射为一个短的（固定的）大小值。这完全符合我们对校验和函数的要求。哈希函数创建的值便称为“哈希值”。用于创建哈希值的哈希算法的名称有时也称为“哈希类型”（例如，文件可能具有哈希类型MD5的哈希值 f5b96775f6c2d310d585bfa0d2ff633c）。
根据维基百科的说法，“一个好的哈希函数满足两个基本属性：1. 它的计算速度应非常快；2. 它应尽量减少输出值的重复（冲突）”。
当两个不同的数据文件产生相同哈希值时，就会发生“冲突”。这种情况发生的可能性应尽可能小。相反，输出范围内的每个哈希值应该以大致相同的概率生成。因此，哈希算法已能很好地满足我们的使用目的——当给定的数据不同时，它会产生不同的哈希值。
下面是一些带有示例值的哈希算法示例，它们通常用于媒体管理进程：
·MD5（128位，示例值：f5b96775f6c2d310d585bfa0d2ff633c）
·xxhash64（64位，示例值：f409b64875d02fa1）
·C4（512位，示例值：c45TH1egbyWxtjgFmisoPypYXcizxPbywFzkbhevak2NgQr3HND5j99HR8UQDwT8pQoS8k3yxhLRGJPoNgR1zUin31）
冲突概率
我们来考虑一种会生成完全均匀分布值的哈希算法。随后在两次查看某个文件（即修改后的文件会产生相同的哈希值）时，冲突的几率可以由哈希的长度决定，如下所示：
冲突概率（即理想哈希算法导致两个不同文件内容有相同哈希的概率）为
其中l是哈希的位长。
因此，对于具有64位长度哈希值（例如xxhash64）的哈希算法，这个概率是1/2^64，大约是1/18,446,744,073,709,551,616或5.42101086×10^-20。换句话说，你需要尝试185,395,973,344,368,338（185千万亿）次随机更改同个文件，才会让你所有比较的总冲突概率超过1%。这相当于用5,878,867（590万）年每秒尝试对给定文件进行1000次更改——仍然没有发生冲突的可能性为99%。
针对那些对数学原理感兴趣的人：这是上面例子里对于一个文件中要使理想64位哈希算法超过1%的给定冲突概率所需的必要随机变化量的公式
即使哈希算法不能完全均匀地分布值，你也能想象得到，对哈希值来说，64位已经是一个很合适的大小，可用来检测文件中的任意更改。
速度
哈希算法可能是数据传输的限制因素，因为我们总想在传输过程中创建哈希。因此，除了传输实际数据之外，还需要计算数据的哈希值——当然，这需要额外的CPU运行时间。xxhash哈希算法家族的网站提供了不同哈希算法速度的概览。
不同哈希算法的基准 https://cyan4973.github.io/xxhash/，有简化调整
第一个要点是长度（即哈希值的位数）并不一定对应算法的速度。另一个要点是，最高速度的差异可能很巨大（例如，在同样的计算机硬件上，XXH3和MD5之间的差异可能高达50倍）。这是因为哈希需要按顺序逐字节地计算，而且不容易实现多线程。这意味着单个CPU核的速度限制了哈希的计算过程——并且将一个哈希进程切换到更多核的CPU也不会使哈希变得更快（当然，你的软件可能会一次独立地给多个文件生成哈希以提高整体吞吐量）。
结论与展望
本文中，我们讨论了校验和的创建如何帮助检测数据完整性的问题。我们还讨论了哈希算法的使用和将哈希值作为校验和的使用，并展示软件如何检测出数据在其生命周期内是否发生了变化并相应地警告用户。
在接下来的一篇文章中，我们将研究数据完全性的那个方面，以及在数据管理过程中可以采取哪些措施来确保没有文件被遗漏。请继续关注本系列的第二部分！
出处：Ben Mehlman | postPerspective
编译：LorianneW | 盖雅翻译小组
相关文章
