大数据管理：数据集成的技术、方法与最佳实践 读书笔记四

这次简单的了解了下数据转换和数据归档，以及批处理数据集成架构和元数据

什么是数据转换

在实现一个新的应用系统，或者将操作从某个应用系统改变到另外一个应用系统时，就有必要搞清楚新应用
系统的数据结构。某些情况下，新应用系统的数据结构是空的。其他一些情况下，当合并应用程序时，新的数据
结构中早已经有了一些数据，因此需要将数据增加到新系统。这里需要用到所有在抽取、转换和加载以及在第7章
中所讨论的技术、策略。

什么是数据归档

到目前为止，在数据管理中还没有重点强调的就是数据生命周期的末端，即数据被归档或者归档之后被删
除。这样做的原因在于，通常人们希望在技术方案的能力范围之内存储尽可能多的数据，如果没有办法保存所有
的数据时，就只有备份旧数据之后删除。现在，在大数据时代，所产生的数据以指数级增长，因此，将数据进行
归档并恢复的能力就尤为重要。而且，更加重要的是，由于通常不能提供选择性恢复的功能，数据备份通常并不
能完全承担数据归档的责任，同时，在当前数据结构发生改变或者应用系统及技术栈被淘汰时，备份的数据将失
去其有效性。
数据归档假设将数据移动到成本低廉（可能访问也受限）的平台上，并且这个平台可以提供数据的后继恢复
或者访问——要么将数据恢复到原来的应用程序，或者在归档环境下直接访问数据。
对于所有的组织来说，数据归档都是一个需要关注的重要领域。而在发生合并和并购、系统整合，以及应用
程序替换的场合下，数据归档就更显得特别重要。对于部分数据不能被转换到新环境的那些数据转换，数据归档
也是比较重要的，特别是那些高度监管的行业。
非结构化数据，如电子邮件和文档，通常需要大量使用归档技术，这是因为，大量数据一旦过期之后就很少
会被再次访问，同时也没有一个数据删除的策略。电子邮件和文档管理系统通常都内置了数据归档和恢复功能，
也有一些第三方工具致力于归档非结构化数据。

归档数据选择

识别出哪些数据需要归档，通常是基于包含了法规要求的组织策略而自动做出的。选择的条件可能和数据的
年龄有关系，例如数据何时创建，或者更有可能的是近一次更新或者访问发生在何时。法规的要求一般规定了
数据需要保持的短时间。例如，客户贷款数据必须在某次贷款被拒绝或者完成之后的7年以内可用，如果组织的
策略是保持数据的在线时间比较短，那么可能要求将数据归档。
在为某个数据集确定了适当的策略之后，选择和归档数据通常由归档系统自动去调度并执行。如同其他的自
动化业务规则一样，数据归档规则也应当经过业务人员的评审，这些业务人员通常负责保持数据与组织及法规政
策要求的同步。这些规则还应当经过测试，以确保正确归档数据。

灵活的数据结构

非常关键的一点就是将要归档的数据，以及对数据的含义和历史进行解释的元数据一起归档。
在以独立于应用程序的访问方式去访问归档数据的情况下，好使用一种可以同时保存数据和元数据的数据
结构或者存储方案，这样可以比较灵活地修改数据结构。基于XML的方案允许修改数据结构、相关的元数据，同时
依然可以允许对来自于同一个应用的归档数据进行查询，即使源数据结构发生了变化。

数据集成（即移动和转换数据）是如何与数据归档相关联的？
在我做数据归档的时候，从来都是开始于对数据使用进行分析，根据这个分析结果再结合风险、法规符合
性、数据访问需求、成本，以及价值建立数据归档的不同场景。这些场景自然而然地发展成大量不同类别的归档 模式。这些模式中关键的一部分（“活动”归档可能是唯一例外）就是抽取、转换和加载（ETL）活动。在大型 项目中，ETL通常是项目成败的决定性因素，从项目管理的角度看，这些活动经常占据最长的项目开发时间，并 且极容易产生错误，虽然是很基础性的。
归档的定义可以归纳为以下形式：归档就是数字内容的存储、检索以及恢复。很多情况下，归档用于协助迁 移系统和数据；保护知识产权；提高系统的健壮性和性能；支持法律诉讼及其他法务相关的需求。简而言之，归 档的三个部分（存储、检索以及恢复）如果没有数据集成是不可能发生的，无论什么情况下总存在源系统和目标 系统。
为什么以及如何为数据归档迁移数据？
“如何”通常是一个比较大的问题，但我们不会忘记“为什么”。
数据通常经过ETL平台和（或）底层数据库结构的数据转出机制从源系统迁移到目标归档系统。关于非结构 化数据迁移、存储在文件中的数据、可能有一定的编码格式（如微软的Office）或者非编码的、图像格式（如扫描 的TIF图像），以及底层操作系统或者存储系统中的数据，可能使用关键字来对这些数据进行标识和追踪。很多情 况下，可以使用简单的操作系统提供的复制工具。对于任何为了归档而进行的数据迁移来说，关键依赖前面提到 的归档的三个部分中的两个部分：检索和恢复。如果移动的数据没有经过适当索引和恢复，那是没有任何用处 的。
我曾经看到很多数据归档项目，花费无数时间，迁移了兆兆兆字节的无用数据。作为ETL或者迁移活动很重 要的一部分，就是去理解在归档状态下如何使用数据，以及实际上需要保存哪些信息。
由这个讨论就引出了问题的另外一部分，即“为什么”的问题。依我看来，了解哪些数据需要归档至关重 要。我的公司采取了“保存全部数据”的策略。乍看起来，这是可行的，因为谁也没法预料未来需要保存什么数 据，并且如今的磁盘价格相对便宜。但是，经验告诉我们，从责任的角度，以及某些时候从法规的角度看，存储 超出需求的数据并不是一个最好的业务选择。通常，旧的数据会让一个公司暴露于一定的法律风险中，而这些并 不是由法律、法规以及公司本身的保留策略所赋予的。作为我个人数据归档方法的一部分，任何目标应用和源数 据都需要经过“为什么”这个问题的检验。我需要理解到底是哪些法律、法规以及业务实践要求归档这些数据。 这个分析最终归结到以下这些问题，即是不是省钱或者赚钱；是否合规（即远离牢狱之灾）；或者是否极大地提 高效率。在理解并评估了这些问题之后，就可以继续数据归档了。
在数据归档时，需要进行哪些转换？（如压缩不同的数据结构等。）
取决于不同的归档平台，可以对归档数据进行任意数量的转换。典型情况下，在数据沉寂之后，至少可以对 底层的数据存储进行一些压缩。某些情况下，可以利用压缩工具进行手工压缩，或者利用底层硬件提供的复杂压 缩算法以及磁盘条带化方法进行压缩。
另外一种通用的、行业无关的数据转换方法就是将数据转换为一种持久的数据格式。所谓持久格式包含了数
据存储媒介的标准（即WORM、COLD媒介类型、光盘等），以及数据被封装、抓取为XML或者PDF文件时实际 的数据存储格式。最后两种格式体现了当前数据归档最通用的趋势，因为它们被业界认可为更标准并且可信的数 据格式。基于XML的封装/转换，以及其自描述的特性，导致了大量采用XML数据库而不是传统关系数据库的数 据归档工具。
数据归档中的数据集成与备份和恢复有什么不同？
归档需要考虑的是保存系统中的数据和信息，而不一定必须是源系统。归档的格式数据可以不是其源系 统“应用上下文”的镜像。
结构化数据（关系数据库和XML）与非结构化数据的归档有什么不同？
最主要的不同在于数据分析和工具。如前所述，归档中两个重要部分就是检索和恢复数据。结构化数据，不 管是关系数据库还是XML，都是为了检索和恢复而设计的。非结构化数据的特性是格式自由。典型的情况是，只 有通过全文索引才能对这类数据进行检索。而为了确保开发的工具和代码能够读取各种不同的非结构化数据中的 内容（多种Office格式、PDF、文本、工作表、专有数据库和图像），需要引入另外一种完全不同的复杂性。考虑 到大量的图像格式和压缩技术，图像可以带来一组特殊的问题。在我的某些项目中，仅仅是因为需要处理多种不 同的数据格式这个问题，就让项目停滞不前，因为我们需要开发特定的代码来处理这些不同。

在数据归档过程中可以使用的用以支持数据集成的工具和技术有哪些？
技术包括ETL工具和平台、脚本语言（例如Perl）、基于操作系统的命令行工具、XML应用程序、转换器，以 及解析器。所有这些工具中一个关键的方面就是支持现存的多种不同数据库和数据格式的驱动程序。我有不止一 个项目被搁置，原因就在于所选择的工具没法处理或者没法高效地处理某种特定的数据库。
结构化数据和非结构化数据使用的工具是否不同？
是不同的。归档结构化数据一个很关键的部分就是数据分析。为了确保归档用户可以得到他们所需要的信 息，就必须理解那些将要被归档的数据。这需要借助于各种不同的工具集，以便可以完成实体关系图解以及更为 复杂的数据分析。对于结构化数据来说，这是没有问题的，因为有一些比较容易使用的工具集。而当需要处理非 结构化或者半结构化数据时，主要的工具则集中于如何往数据中注入有序和结构化的信息。非结构化的数据分析 工具一般寻找以下这些信息，即对象之间的模式、对象中的文字、文件存储位置、最近访问者、数据的位置、文 件名字、大小等。这看起来更像一个鉴定分析科学，而不仅仅是对数据本身的检视。
你认为数据归档领域正在发生什么变化？发展方向是什么？
绝大部分公司都专注于构建合理的应用系统组合，通常的结果是把数据/应用归档作为主要由法规符合性需求 所驱动的一种补偿。根据弗雷斯特研究公司（Forrester Research）的估计，平均来说，大型应用中，结构化数据库 中的数据每年增长50%，存储在数据库中的数据85%处于不活跃状态。
你认为用来实施数据归档的技术，特别是有关数据集成的技术，是否正在发生变化？
是的。多种不同类型的数据仓库（包含结构化和非结构化数据），以及在数据归档中使用基于XML的数据库 和其他非关系数据库技术越来越引人注目。

批处理数据集成架构和元数据

元数据有三个基本的类别：业务元数据、技术元数据以及操作元数据。业务元数据包含了业务用户特别感兴
趣的信息，通常由业务人员开发，例如和数据相关的术语的业务定义。技术元数据包含了程序正确运行所需要的
信息，例如数据库中某个字段的技术名称，或者在将某部分数据转换成另外一部分数据时所需要进行的计算。操
作元数据则是指对实际发生的事情的日志记录，例如将某个特定部分的数据装载到目标数据结构的日期和时间。
技术环境中的每个层次及其用途都有元数据，包括网络、服务器、数据库、文件、程序，以及哪些人可以有
权限访问这些不同的层次。对于数据集成来说，还有些新的特别重要的元数据，即数据转换信息和世系。数据转
换元数据描述了数据是如何从一个环境中转换到另外一个环境中的。数据转换的通用说法就是映射，这既是一个
名词也是一个动词。它定义了数据转换应该是什么样的动作，结果即转换的规格说明书，也称为映射。世系就是
指数据的发展变化历史，即它来自哪里，是如何一路被转换过来的。世系也是有关源数据的操作元数据。世系元
数据带来了一些固有的挑战，因为它基于在数据上执行过的技术元数据映射，即使业务用户可能有极大的兴趣，
也是比较难以理解的。通常需要创建额外的业务元数据，用业务术语来对数据的世系进行解释。

数据集成（即移动和转换数据）是如何与元数据关联的？
将数据从源系统移动到另外一个系统，并进行转换，是基于底层的元数据的。元数据描述了每个源的物理结 构。简单说来，就是元模型的“内容”描述了“数据”，这个“内容”定义了整个转换过程。
就数据移动和转换而言，需要保存哪些元数据（业务、技术、操作型）？
所有这些信息都应当保存。为了移动数据，我们就必须知道源（技术型的），数据的含义（业务型的），将 会对数据进行什么处理（业务和技术型的），以及数据的去向（技术型的）。将数据从一处移动到另一处的过程 信息是操作型的。
你有没有经历过一些数据集成项目，在其中由于元数据的问题而导致重大问题？
实际上我曾经工作过的每个项目都没有给予“业务”元数据以足够的重视。即使技术元数据是完备的，也没 有足够的业务元数据与之关联，例如分类信息以及业务规则等，因此容易被最重要的人即业务拥有者所误解，而 他们正是需要和使用集成数据的人。
你是否有过这样的经验，即在数据集成中给予元数据以特别的关注？
我总是强调在数据集成的所有过程中都需要获得业务相关的足够信息。例如，大部分ETL工具并不需要对相 关的转换逻辑加以描述，但优秀的分析人员则总是会确保填上这些信息。
你是否经历过一些忽略了元数据的数据集成项目？
经常遇到。但是，在我曾经工作过的一个数据集成项目中，并没有忽视元数据。大多数项目参与者没有意识 到元数据的价值，因为他们相信，关于数据本身，每一个人所拥有的知识都是一样的。
如果某些人早已知道了答案，他们通常难以理解为什么还需要花费时间用文档去记录这些答案。我总是听到 没有时间，或者非常紧张的项目期限等诸如此类的理由。
哪些工具和技术可以用来支持数据集成元数据？
ETL工具有类似“定义”和“描述”的字段，通常可以用来获取数据集成元数据的“业务”属性。当然，每 个工具的元模型都具有存储元数据的能力，这些元数据涵盖了集成的所有方面（业务、技术、操作）。
集中式元数据库支持所有类型的元数据，并且借助于可能早已存在于库中的关于源和目标的信息，以及围绕 着整个世系的业务元数据，中央元数据可以整合“集成”元数据的某些特殊方面。
当然，遗憾的是，支持数据集成元数据最流行的工具是Excel电子表格。
你认为除了在每个独立的工具库中存储元数据外，是否还需要一个中央元数据库？为什么是或不是？
中央存储库包含了整个企业所关注的唯一视图。数据集成必须基于早已存在的源系统，或者早已在其他集成 项目中使用的源系统。除非一个集成项目知晓另外一个集成项目的相关信息，否则，组织就会面临我称之为“批 入-批出”的架构风险。如果没有贯穿整个组织的一个视图，那么没有人会真正地了解主要的数据源都在发生什么 事情——即使主要数据源的数据转换工作的文档记录都很好。
将数据集成的元数据移入一个中央元数据库或者数据仓库时有哪些特别的考虑？还有其他哪些场合需要数据
集成元数据？
每一个源都必须被一致命名，以避免同一个源被重复标识两次。但是物理源通常都是被“扫描”进中央存储 库的，这个问题可以通过数据库管理系统实例内部的标识加以解决。当使用手工标识的时候会出现问题，例如源 系统相关信息来自电子表格。
结构化数据和非结构化数据的数据集成有什么不同？
通过将数据的类型与固定的分类信息相关联，就可以将非结构化的数据与结构化数据进行集成。
你认为元数据领域正在发生怎样的变化？发展方向是什么？
元数据不再被看做一个“领域”，与此相反，它被公认为IT行业独具特色的生活之一。这个概念正在演变
成“治理”的概念和元数据内容更为相关，例如什么时候应该填充数据，为什么，如何填充，以及应该使用哪些 有效的数据等。
你认为元数据技术，特别是关于数据集成的是否在发生变化？
元数据本身正在日益成为一种自动化的过程。从业务方面看，元数据则在某些时间点上总需要一些手工的干 预。理想情况下，关键字搜索可以帮助对数据进行识别和分类，但有关的定义和关联则总要相关人员的参与。