Hadoop如何通过IT审计(下)？
内容：
1. 决策摘要
2. IT和企业风险环境
3. 越来越多的IT规范
4. Hadoop的职能
a. 安全
b. 灾难恢复和业务连续性
c. 资料管理：监督和法律要求
5. 额外要求
6. 关键要点
接上文：
在企业IT中，与植根于存储环境的企业数据管理相关的风险控制和法规遵从是非常普遍的。在该情况下，一些基本功能可以直接应用于数据之上。这些基本功能包括：
1. 数据保护。在主要存储设备或更多得是在二级存储设备上创建并维护备份文件，以保证导致数据丢失或损坏之后的恢复。
2. 本地数据复制。克隆和快照被用于从不良事件中恢复和传播数据到其他应用程序和测试环境。
3. 远程数据复制。数据在城域网（MAN）和广域网（WAN）距离上直接复制到其他存储设备（也就是说，没有通过服务器之间进行数据传输）。这被用于类似本地数据复制的同样用途，以及建立在企业整体灾难恢复计划中的灾难恢复站点。
4. 归档。不可更改的数据副本被保留在存储设备中（比如存储系统），以满足上述所涉及到的法规遵从性要求和服从涵盖了联邦民事诉讼规则（FRCP）中所要求的以电子格式保存证据进行管理的规则。
对于Hadoop集群，这些功能通常被执行的地方是Hadoop分布式文件系统（HDFS）。然而，在只依靠自身且没有其他实体（比如拥有此功能的可共享的存储系统）的辅助下，HDFS只能满足这些功能的如下一部分：
1. 克隆复制和快照副本。Hadoop生成数据的本地副本（默认设置为3份），这意味着对于导入的每一份文件，将创建额外的全完拷贝并存储在集群内。从本质上而言，这是Hadoop管理员用于减少簇处理延迟并从集群中不同类型故障中恢复所进行的整个文件系统的克隆。
然而，维持整个文件系统三个副本的做法并不能提供完整的数据保护。举例来说，如果原文件因为无法纠正的读取错误（UREs）而损坏，磁盘检测在一次读取中检测出许多（如果不是大多数）读取错误的话，这些是不能被重新创建或传播的。尽管在统计上，UREs并不常见，它们在Hadoop的环境下仍然由于两个原因而值得关注。首先，大型Hadoop集群可以使用数千个磁盘，这将增加在给定一个时间段内未被检出的错误事件的概率。其次，RAID控制器可以被用于检测那些在磁盘检测中无法发现的错误，但由于磁盘通常是以JBOD（简单磁盘捆绑）形式实现的，RAID控制器将不能发现它们。错误将传播到其他副本中，而导致副本失效。
Hadoop2支持创建数据的逻辑（快照）副本而不是完整的物理拷贝的功能。使用快照为HDFS提供了在集群内备份数据，从用户错误中恢复，和有限的灾难恢复方案中所产生的完整的数据拷贝的一种替代恢复机制。然而，由于使用的元数据拷贝机制，HDFS快照并不能用于恢复上述提及的事件所引起的数据损失。
2. 使用Hadoop DistCp复制。所谓的DistCp（分布式复制）是土生土长的Hadoop功能，可用于从一个Hadoop集群复制数据到另一个，而无视是在本地或是在城域网/广域网的距离上进行。它采用MapReduce的流程实现从源文件到目标文件的只读镜像复制。默认情况下，DistCp流程会跳过那些已经存在的目标文件和那些当DistCp作业运行时正在被写入目标的文件。只有这些被跳过文件的计数会在每个DistCp任务完成后报告给管理员。而且这类最低水平的报告在当DistCp对其文件的某些子集运行失败，但又在其后的尝试中成功的情况下，都甚至有可能出现错误。因此，管理员必须人工运行一系列的DistCp任务来收集和复制文件更新并交叉核对目标文件和源文件以判定拷贝是否成功。即便如此，因为打开的文件不能被复制，除非当DistCp运行时集群里没有写操作发生，否则源文件集和目标文件集将不一致。
此外，源集群和目标集群间的其他一些问题将对拷贝产生不利企且难以发现的影响，进而导致源集群和目标集群的不一致。其他一些源文件和目标文件的难以察觉的不匹配也由于DistCp并不涉及到文件内容而发生。DistCp仅根据文件名和大小来决定复制与否。如果文件名和大小都匹配，它并不考虑文件内容是否不同（举例来说，一个DistCp之前的任务被后续更新）。DistCp将不通过远程只读镜像来复制此类文件。
联合能够提供本地镜像，快照和远程复制功能的Hadoop集群（这些集群已经成功被使用了几十年来提供企业生产级别的数据保护和灾难恢复流程的）来共同使用共享的存储系统是有可能的。这些可以替代或是作为额外的Apache HDFS所提供的数据拷贝和复制功能的补充，因为在IT管理员眼中，Apache HDFS所提供的功能是不足的。
但是，与Hadoop一起使用共享的存储系统是罕见且富有争议的。至少在短期内，一个更可以接受的途径也许是使得HDFS在本地和远程复制的功能上更加强大。这样做包括可用于LAN（本地网），MAN（城域网）和WAN（广域网）距离上双主机数据复制的实现，这样一种方式可以保证源文件和目标副本之间的一致性而不需要Hadoop管理员的人工干预。这也将允许单一的Hadoop集群“延伸”至城域网和广义网的距离。该解决方案也必须避免使用能够同时导致单点故障和性能瓶颈的集中式交易协调器。
记录管理：监管及法律规定
许多针对金融服务，医疗保健和药品产业的法规都包含解决电子记录的储存和保留的条款。对电子记录的要求，保留期限以及构成的定义是多样化的，但美国证券交易委员会17a-4条法案是一个经常被引用的例子。在该法案中，记录被定义为有关商业活动的所有文件。今天，这一定义还包括了电子邮件，短信，报告和交易记录。用于储存记录的电子媒体必须用不可重写且不可擦除的格式（如一写多读--WORM--技术）来保存这些数据。 这些记录还必须易于检索和取回。许多记录必须保留不少于三年，而且在前两年中需便于美国证券交易委员会使用。一些记录需要更长时间的保留。
额外的要求
尽管有许多规定– 其中一些已在上文中指出 – 按照管理当局（比如SEC）的要求，需要对记录长期保留及检索，还有另外一种实现数据保留和取回要求的类型，通常被称为电子化搜寻。在美国，该术语意味着IT拥有寻找和取回那些从法律的角度而言的敏感记录的机制。
事实上，大多数影响企业IT的电子化搜寻的要求根本不是从监管中产生的。相反，它们来源于有关FRCP中所概述的证据发掘的法律指令。在诉讼的准备阶段，所有的企业都需要遵从FRCP要求披露以电子格式所记录的证据的规定。这适用于所有的公司，无论公私属性与规模。
这些要求之一被称为“法律保留”，即认定为电子化搜寻过程结果的记录，现在必须被作为证据保存。法律保留要求机构收集和保存整个信息资源的数据，其中包括档案，数据库，电子邮件和其他信息库。此外，该数据可能不会被删除或改变，而且这些数据的保留有效期限必须予以搁置，直到法律保留被撤销。法律保留是保全包括那些以电子形式存储的证据的隐性要求。对违规的处罚可以相当严重。由于不遵守搜寻过程的时效性（FRCP准则为48小时内生成可用信息的列表），以及/或者删除或未能根据要求出示信息将会导致数百万美元的罚款。
不幸的是，ApacheHadoop的开发者并没有预计到能够支持企业级别的法规遵从和电子化搜寻要求的数据管理和电子化记录管理功能方面的发展需要。这些功能在目前的版本1和2中并不存在。它们的缺失已经成为阻碍Hadoop向企业生产IT环境发展的一大绊脚石。例如，Hadoop用户通常希望使用客户数据进行分析，但是其使用往往受到公司审计员，安全人员，和那些工作任务就是确保这些数据的用户遵守公司有关消费者数据的管理政策的律师们的严格审查。
一种能够满足这些要求的有效方式是在HDFS中实施一个双层次的存储机制，该机制支持一个高性能的主存储层，辅之以一个高容量的二级存储层作为备份。这么做可以允许需要记性管理控制的用户在二级存储层上实施任务，并保留主存储层不被占用使其能支持MapReduce进程。两种方法可以实现这一目标：
1. 创建由HDFS管理的Hadoop集群内的一级和二级存储层。我们可以预见用分布在节点上的固态硬盘（SSD）作为主存储层，而用同样分布在几点上的高容量硬盘作为二级存储层。主存储层的数据既可以复制也可以迁移到二级存储层。其中，数据基本上是作为存档，而有些敏感数据也可以被保护，锁定或以任何形式来满足管理政策的要求。
2. 创建一个不由HDFS管理的Hadoop以外的次级存储层。尽管在现实中并不普遍，Hadoop用户在某些情况下也已利用共享的存储系统来创建存储层。这使得列阵（文件索引，WORM等）中的数据服务功能可以被应用，而无需等待Apache社区开发这些功能或是编写一个HDFS的自定义功能。
要点概述
1. 很显然，Hadoop正在从互联网或网络规模的数据中心发展成为企业数据中心。这一过程中，其开发者和支持者会遇到一系列新的法规和不同的管理体制的挑战。
2. Hadoop也在从一个100%的批处理平台逐步成熟为一个同时支持OLTP的平台。然而，为了让Hadoop从试点项目的地位发展成为生产应用环境，它不能增加企业的风险状况。
3. 随着这些进展逐步显现，Hadoop还需要证明其不仅能够满足负责生产运行和利用Hadoop执行可能的关键任务的IT管理员的要求，也能够应对企业级别的审计，安全和合法监管者（在此指股东）的要求。
4. 虽然我们已经注意到一些安全，数据保护和法规遵从措施业已存在或是能够添加到Hadoop上，但企业用户更偏好能够满足要求的内在的实现。我们相信，这样做会产生双重结果：
a. 首先，由于该功能是内置到Hadoop中的，这将更易于IT管理员部署和支持。例如，他们将不会被要求做整合Kerberos与多节点的Hadoop集群来影响安全性的复杂工作。因此，对他们而言，将有一个使用内置函数的好机会。
b. 其次，Hadoop环境无法被轻松地保护，无法被置入灾难恢复计划，也无法响应数据管理政策，这些缺陷经常被认为是阻碍Hadoop在企业内发展，阻碍其从概念验证项目成长为IT管理员像应用其他生产程序一样可支持的应用平台的主要问题。实施针对这些问题的解决方案则消除了这些障碍。