大数据管理两三事

社区•2017-07-27•媒体资讯•

什么是数据转换？
在实现一个新的应用系统，或者将操作从某个应用系统改变到另外一个应用系统时，就有必要搞清楚新应用系统的数据结构。

某些情况下，新应用系统的数据结构是空的。其他一些情况下，当合并应用程序时，新的数据结构中早已经有了一些数据，因此需要将数据增加到新系统。

什么是数据归档？
到目前为止，在数据管理中还没有重点强调的就是数据生命周期的末端，即数据被归档或者归档之后被删除。这样做的原因在于，通常人们希望在技术方案的能力范围之内存储尽可能多的数据，如果没有办法保存所有的数据时，就只有备份旧数据之后删除。

现在，在大数据时代，所产生的数据以指数级增长，因此，将数据进行归档并恢复的能力就尤为重要。而且，更加重要的是，由于通常不能提供选择性恢复的功能，数据备份通常并不能完全承担数据归档的责任，同时，在当前数据结构发生改变或者应用系统及技术栈被淘汰时，备份的数据将失去其有效性。

数据归档假设将数据移动到成本低廉（可能访问也受限）的平台上，并且这个平台可以提供数据的后继恢复或者访问——要么将数据恢复到原来的应用程序，或者在归档环境下直接访问数据。

对于所有的组织来说，数据归档都是一个需要关注的重要领域。而在发生合并和并购、系统整合，以及应用程序替换的场合下，数据归档就更显得特别重要。对于部分数据不能被转换到新环境的那些数据转换，数据归档也是比较重要的，特别是那些高度监管的行业。非结构化数据，如电子邮件和文档，通常需要大量使用归档技术，这是因为，大量数据一旦过期之后就很少会被再次访问，同时也没有一个数据删除的策略。电子邮件和文档管理系统通常都内置了数据归档和恢复功能，也有一些第三方工具致力于归档非结构化数据。

归档数据选择识别出哪些数据需要归档，通常是基于包含了法规要求的组织策略而自动做出的。选择的条件可能和数据的年龄有关系，例如数据何时创建，或者更有可能的是近一次更新或者访问发生在何时。法规的要求一般规定了数据需要保持的短时间。例如，客户贷款数据必须在某次贷款被拒绝或者完成之后的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的数据库和其他非关系数据库技术越来越引人注目。

文章关键词: Salesforce