陈 斯 洁

(复旦大学附属华山医院　上海 200040)

0　引　言

随着计算机应用的普及，各行各业的计算机信息化系统建设重点已从早期的事务信息管理逐渐向数据应用方向转变。传统的信息管理系统主要为联机事务处理OLTP(On-Line Transaction Processing)，实现数据采集与存储、业务流程管理等功能，技术关注点在于事务、流程与数据之间的依存与表达。当通常意义的信息管理系统已基本建成后，必定来临的是信息应用即大数据时代。计算机信息系统主要完成在线分析处理OLAP(On-Line Analytical Processing)功能，计算机信息系统设计与开发的重心更关注于数据的清洗、比对与交换，查询、统计与分析，注重于系统的性能、效率和扩展性，偏重于海量远程用户的高可用访问性能[1]。

在当前大数据时代，信息处理技术飞速进步，数据存储从典型的集中式Oracle关系数据库发展到现今代表性的Hadoop分布式文件系统。然而不论从保护前期投资还是现实可操作性观点出发，都不可能一夜之间将目前广泛使用的关系型数据库如Oracle、SQL Server等关系型数据库产品替换成NoSQL数据库，这既无必要也不可行。因此，放在广大主要从事计算机信息管理与应用领域技术人员面前的是如何快速、有效且低成本解决SQL类关系数据库从原本的OLTP强项进化到最大程度地满足与适用于OLAP应用的问题。

SQL型关系数据库产品大多采用的都是行存储数据结构，相应的软件开发也是通过行搜索的方式进行，即将一个个完整的数据行存储在数据页中，在搜索应用时找到相应的表，逐行取出符合条件的数据以形成数据集。在一些OLAP应用场景中，特别是在海量数据表构成的档案数据库如人口资源库、信用记录库、医疗过程数据库等应用场合中，采用通常多表行搜索的方式就会导致系统不能满足实际应用需求，数据库性能急剧下降甚至瘫痪的事件时有发生。

为此，本文针对传统关系型档案数据库的多表存储与搜索问题，提出了一种基于MapReduce思想的构建数据解析抽取函数表的搜索方法，以解决OLAP应用场景中关系数据的查询和系统维护问题。

1　传统档案数据处理方法分析

1.1　传统数据搜索方法简介

一对多及多对多的数据交换和抽取是计算机信息管理系统的基本功能，采用传统多表存储的方法是在关系型数据库中建两张同构数据(库)表。系统按照数据来源的数据结构进行映射，目标表和原始表一一对应，不对表结构进行任何变化，以此完成数据的无损抽取与汇集。

这样的档案数据共享应用场景比比皆是，如在智慧医疗系统中，将各医院的每个病人医治记录汇集到大数据共享平台通常都采用此方法。由此大数据平台中存储的是各医院每位病人的医疗记录，然而当数据共享时，主治医生需要的是当前患者曾经在各医院治疗过程的检测和用药记录汇总，以此减少不必要的重复检查和提高医疗质量。

针对上述需求，通常的系统搜索汇总工作机制流程是：系统软件按照需查找信息对象的ID号，在所有相关数据(库)表扫中描每一张数据表，逐个比对这些表中的主键与输入条件匹配的ID数据记录，将其抽取出来，并把这些数据记录关联汇总成数据集，推送到系统页面进行展示。该行搜索方法示意如图1所示。

图1　行搜索模式示意图

在这种传统行搜索的场景下，软件系统需要扫描多张表，若系统庞大到有上万张表时，按此方法，系统性能和效率将是无法承受的。且一旦有新的资源目录事项加入时，需要不断地在数据库中新建表。为此相应的底层适配读写的查找软件功能代码都需要重新开发，由此造成数据管理和开发成本高居高不下，软件代码的可扩展性和兼容性不能满足实时应用的需求。因此，该方法在小容量档案数据库中可使用，对于海量数据平台是无法应用的。

1.2　档案数据特征分析

为了解决绝大多数目前活跃使用的档案数据库的快速信息查找与抽取问题，需要对此类数据库进行分析，以便从中发现解决问题的方法。经对常见的关系型档案数据库表结构解析，社会公共信息档案数据具有如下主要特征：

(1) 主键编码稳定且唯一根据国家有关法律法规，法人和自然人均使用全国统一赋码的18位代码作为身份识别的编码，一个主体只能拥有一个统一代码，一个统一代码只能赋予一个主体。并且，统一代码一经赋予，在其主体存续期间，主体信息即使发生任何变化，统一代码均保持不变[1]。

(2) 以结构化数据信息为主社会公共信息档案数据源于各个主管部门已有的信息管理系统，如工商部门的企业注册登记信息、公安部门的行驶证登记信息以及医疗单位的治疗记录信息等。这些数据均是关系型数据库的产品，通常情况下都是结构化的数据信息。

(3) 数据来源繁多类别与结构复杂档案数据归属于多头采集且部门繁多，各领域、各系统都具有不同的业务规范和数据标准，导致档案数据资源目录的元数据名称、格式、标准、长度、类型千差万别，本质上具有分布式数据库的主要特征。

以上海市某资源目录为例，资源目录共有5 198个事项，字段最多的资源目录事项有34个字段，最少的有8个字段。另外，除国家制定的少量特殊数据之外，没有一个资源目录事项的字段是一致的。

2　数据映射归约函数表的构建方法

针对前节结构化数据中数据标准不一致的问题，本文采用构建数据映射归约(MapReduce)函数表方式予以解决，其中map和reduce提供的是所需对象数据抽取的计算框架。可以把MapReduce过程简单理解为把一堆互不关联的数据(表)按照某种特征归纳起来，然后处理并得到最终需要的结果。本质上是一种用函数程序语言来实现泛数据归集[2]。

采用MapReduce函数表方式后，在档案数据查询抽取程序设计中就较为简单了，只要构建两张函数表，一张为map表，另一张为reduce表。Map函数表实现将源数据表中的数据名称、类型、长度以及该数据字段在目标显示系统的展示顺序、宽度和名称等数据结构(属性)信息列入表中。而Reduce函数表的作用是将数据(属性)结构中对应的各数据内容提供一个存储空间。用计算机编程语言来讲，Map表中记录的key，Reduce表中存储的是value。

为了便于理解MapReduce函数程序语言编程方法，本文提供了Map表T_HEADER(表1)与Reduce表T_DATA(表2)的示意结构。所有档案的元数据统一在“数据名称表T_HEADER”中存储，所有数据记录在“数据内容表T_DATA”中存储。

表1　数据名称表T_HEADER表结构

表2　数据内容表T_DATA表结构

数据内容表T_DATA统一管理所有的数据记录，这些数据记录是严格按照T_HEADER的元数据标准进行存储的，分别用A1至A50存放每个元数据字段所对应的具体数据。法人统一代码和单位名称、自然人的身份证号码和姓名单独用两个字段“CREDITCODE”和“NAME”单独存放。其与各原始表的映射关系如图2所示。

图2　列搜索表结构与原始表结构映射关系图

从图2中可以看到，任意多张源数据表的数据(属性)结构映射到Map表中，而任意多张源数据表的数据内容归集到Reduce表中。MapReduce表中的A1、A2、…即为函数代码，具体含义由系统实际需求确定。

档案数据的映射归集如图2示意，在实际应用中，最终需要的是相关数据的展现，其工作机制流程示意如图3所示。

图3　列搜索模式示意图

图3的工作流程为，以查找对象的统一代码为主键，软件系统首先在数据内容表T_DATA中进行匹配，将CREDITCODE字段中所有符合条件的数据记录全部找到，以ZYMLID为外键，在数据名称表T_HEADER中找到这些数据记录对应的表头名称信息、类型信息、长度信息、信用档案中展示的先后顺序、展示的宽度、展示的别名等。然后将这些数据记录关联起来进行展示。

通过举例说明，可以清楚地认识到，Map实现的是对数据表中每个结构元素Key独立处理，且这些数据表中可以是互补关联的。而Reduce实现的数据key后面所属的若干内容(value) 归集，这些value是有相关性的，至少它们都在一个key下面。这是典型的函数式语言Map和Reduce基本思想方法：Map表示对一个列表(List)中的每个元素Key做计算，Reduce表示对一个列表中的每个元素Value做迭代计算。它们具体的计算是通过传入的函数来实现的[3]。

3　应用实践与分析

通过对资源数据的MapReduce整合，可以实现应用系统数据ETL成本大幅降低，因为采用该方法，数据整合应用系统只需针对两张表进行开发。不需要在关系数据库中对各张数据表进行关注，不需要为每张表单独建立实体类进行读写维护的开发，简化了数据整合软件开发，降低了应用系统软件的开发时间和维护成本。

其次，数据易于维护与扩展。随着未来新的部门不断接入，新的信用信息资源目录事项不断增加，在基于MapReduce的数据管理模式下，只需要在数据内容标T_DATA中新增数据记录，并把对应数据记录的元数据信息插入数据名称表T_HEADER中即可。不需要修改软件程序，也不需要新增表实体或修改表结构就可以完成扩展，并保持来源部门的原始数据结构不变。

第三，提高了查询应用的效率。在此模式下，软件系统不需要扫描几千张表，只需要对两张表进行操作即可。大大提高了应用系统的查询效率。

在上海相关的医疗信息资源交互平台项目中进行了试验与实践，截止2017年1月，该方法通过整合医疗系统近20多家机构的相关数据，实现了病人相关治疗信息的交互与整合，避免了病人重复检查的成本支持，取得了良好的社会效益。

4　数据搜索与归集方法的分析与讨论

各类数据的搜索、查询与归集可以理解为通常意义上的数据ETL过程，主要环节就是数据抽取、数据转换和加工、数据装载。在目前的实际应用中，从关系数据库中抽取数据一般有以下几种方式：

1) 全量抽取。全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动地从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式并加载到目标数据库。

2) 增量抽取。增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。在ETL 使用过程中，增量抽取较全量抽取应用更广。如何捕获变化的数据是增量抽取的关键。

3) 日志表方式。在业务系统中添加系统日志表，当业务数据发生变化时，更新维护日志表内容，当作ETL 加载时，通过读日志表数据决定加载那些数据及如何加载。

优点：不需要修改业务系统表结构，源数据抽取清楚，速度较快。可以实现数据的递增加载。

缺点：日志表维护需要由业务系统完成，需要对业务系统业务操作程序作修改，记录日志信息。日志表维护较为麻烦，对原有系统有较大影响。工作量较大，改动较大，有一定风险。

4) 全表比对方式。全表比对的方式是ETL 工具事先为要抽取的表建立一个结构类似的临时表，该临时表记录源表主键以及根据所有字段的数据计算出来。每次进行数据抽取时，对源表和临时表进行的比对，如有不同，进行Update 操作，如目标表没有存在该主键值，表示该记录还没有，即进行Insert 操作。

优点：对已有系统表结构不产生影响，不需要修改业务操作程序，所有抽取规则由ETL完成，管理维护统一，可以实现数据的递增加载，没有风险。

缺点：ETL 比对较复杂，设计较为复杂，速度较慢。与触发器和时间戳方式中的主动通知不同，全表比对方式是被动地进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，全表比对方式的准确性较差。

本文提出的档案数据快速查询方法从原理上属于数据转换和加工ETL方法。因为在现实应用场景中，数据源中抽取的数据不一定完全满足目标库的数据要求，例如数据格式的不一致、数据输入错误、数据不完整等，所以有必要对抽取出的数据进行数据转换、选取和加工，与前述的覆盖式数据ETL有极大的差别。

数据的转换和加工可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。通过对各种数据抽取机制的对比分析发现，没有

一种机制具有绝对的优势，不同机制在各种因素下的表现大体上都是相对平衡的。

ETL实施过程中究竟选择哪种抽取机制，要根据实际的数据源系统环境进行决策，需要综合考虑源系统数据库的类型、抽取的数据量(决定对性能要求的苛刻程度)、对源业务系统和数据库的控制能力以及实现难度等各种因素，甚至结合各种不同的数据类型及不同环境的数据源系统进行ETL实施，合适的才是最好的。本文提出的利用key-value语言函数抽取及归集数据的方法相比较适合与分布式数据源的重点关注数据抽取，也是当前海量数据挖掘与应用的热点课题，在此提出以供各位借鉴与参考。

5　结　语

本文提出的MapReduce实时异构数据存储技术是一项面向对象的分布式数据库存储技术，具有良好的实时读写性能和可扩展性及查询能力。但该技术和所有 NoSql 非关系型数据存储系统一样， 都面临着一个共性问题。其存储与检索效率受限于各节点的服务器磁盘性能影响，如磁盘的寻道时间、盘片转速、碟片密度以及接口速度等都对本技术的读写速率产生一定的影响。上述局限性需要今后不断的探索与优化[4]。

同时在应用过程中，发现MapReduce存储模式下的一些问题，如统计报表和专题分析等应用的开发相对SQL模式无明显优势。下一步工作是如何兼容SQL与NoSQL的混合存储模式，以兼顾分布式大数据架构下的存储与分类查询的系统性能和效率。

[1] 马建光, 姜巍. 大数据的概念、特征及其应用[J]. 国防科技, 2013,34(2):10-17.

[2] 周枫. 大数据时代档案馆的特征及发展策略[J]. 档案与建设, 2013(8):6-9.

[3] 库俊平. 大数据环境中企业文书档案的信息化管理及利用[J]. 创新科技,2013(9):50-51.

[4] 李斌. 大数据及其发展趋势研究[J]. 广西教育,2013(35):190-192.

[5] 杜方, 陈跃国, 杜小勇. RDF数据查询处理技术综述[J]. 软件学报, 2013(6):1222-1242.

[6] 冷泳林, 鲁富宇. 基于MapReduce的SimRank算法在图聚类中的应用[J]. 电子设计工程, 2015(6):9-11.

[7] 李彬, 刘莉莉. 基于MapReduce的Web日志挖掘[J]. 计算机工程与应用, 2012,48(22):95-98.

[8] 应毅, 任凯, 曹阳. 基于改进的MapReduce模型的Web挖掘[J]. 科学技术与工程, 2013,13(5):1205-1209.