3.4 关键技术

在房屋全生命周期平台系统建设过程中，系统开发涉及的相关关键技术包括为实现GIS功能使用的ArcGIS API for JavaScript，实现数据共享功能使用的Web服务技术，为构建数据中心的ETL技术和数据仓库技术，以及为实现各类统计报表和决策支持的商业智能等技术。

3.4.1 GeoWeb 2.0与ArcGIS API for JavaScript

GeoWeb概念的首次提出是在1994年，是指在互联网上部署GIS，旨在解决冗余数据、昂贵数据的整合以及分布处理能力，将利用新的技术、市场和决策系统来开启我们的世界。GeoWeb是一个分散式的地理信息网络服务，可让地理信息通过OGC标准和W3C的界面互相沟通存取，凭借良好的互操作性达成以往需要庞大数据量才能实现的功能，使用者可以随意使用在GeoWeb里的地理空间数据。GeoWeb可让各个符合国际标准的地理信息数据库之间通过API方式沟通，从而保证数据不再局限于单一数据库中，可形成网格数据库。GeoWeb是GIS未来的发展趋势，是人类社会团体、结构和民众协同合作所建立的信息架构，摆脱以往GIS只适用于专业人士的情况，真正地让使用者搜索生活中的各种信息。

早期的Web GIS虽然拥有技术上的先进性，但是推广至一般民众较为困难，然而由于近几年Web 2.0 Mapping系统的发展，出现了崭新的应用，让以往需要大量数据才能实现的Web应用，现在只需要使用Web 2.0网站提供的API即可实现。Google、Yahoo! 、Microsoft等公司纷纷推出属于自己的地图API，降低以往开发电子地图的门槛，让许多以Google Map、Bing Map等电子地图为显示底图的应用网站如雨后春笋般诞生，例如有显示性侵害犯罪的MapSexOffenders.com、芝加哥犯罪的www.chicagocrime.org；结合照片与影像的Flickr与Panoramio；或是让使用者创造属于自己的地图，并让Google Map和其他网页结合的My Map+；也有提供爱好旅游的使用者通过系统机制和blog分享旅游经验，期望建立起旅游社群的MyTripBook；提供飞机航班即时信息的fboweb.com；结合天气信息的Weather Underground；租房信息的housingmaps.com。ProgrammableWeb（http://www.programmableweb.com/tag/mapping）中罗列了2000多个这类融入式地图应用，这些应用显示了目前电子地图正受到大家的重视，相信未来GeoWeb 2.0会更加蓬勃发展。

为了帮助用户构建GeoWeb 2.0应用程序，访问ArcGIS Server提供的各类服务，ESRI推出了一系列的API，包括ArcGIS Server JavaScript API、ArcGIS API for Flex ArcGIS API for Microsoft Silverlight™/WPF™等。ArcGIS Server JavaScript API是ESRI推出的地图API，可以帮助用户运用ArcGIS Server提供的服务去搭建轻量级的高性能客户端GIS应用程序，将一幅交互式的地图或一个地理处理任务（例如查询空间数据）嵌入到网络应用程序中。ArcGIS API for Flex是ArcGIS Server的扩展开发组件，可以在使用ArcGIS Server构建GIS服务的基础上，开发富因特网应用（RIA）。它的优点在于可以使ArcGIS提供的各种资源（如Map、GP模型）和Flex提供的组件（如Grid、Chart）相结合，构建表现出色、交互体验良好的Web应用。ArcGIS API for Microsoft Silverlight™/WPF™可以帮助应用软件开发人员将ArcGIS Server和微软Bing的服务与功能集成在Silverlight/WPF的应用程序中，通过网络发布ArcGIS Server的地图、地理信息系统服务以及应用程序。

ArcGIS Server JavaScript API又包括ArcGIS JavaScript API、ArcGIS Google地图JavaScript扩展与ArcGIS微软Bing地图JavaScript扩展三大部分。通过ArcGIS JavaScript API可以实现基于自己的数据开发一个交互式的地图、在服务器上执行一个GIS模型并显示出结果、在ArcGIS在线提供的底图上叠加自己的数据、搜索GIS数据的某些特征及属性以及地址匹配等功能。两个JavaScript扩展分别扩展了Google地图API与微软Bing地图API，从而可调用ArcGIS Server提供的各种服务。也可以把它们与ArcGIS Server的资源整合在一起，实现融入式（Mashup）Web应用程序。

3.4.2 ETL技术

ETL原本是构建数据仓库的一个环节，负责将分布的、异构数据源中的数据（如关系数据、平面数据文件等）抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。现在ETL被越来越多地应用于一般信息系统中数据的迁移、交换和同步。

ETL过程中的主要环节就是数据抽取、数据转换和加工、数据装载。为了实现这些功能，各个ETL工具一般会进行一些功能上的扩充，例如工作流、调度引擎、规则引擎、脚本支持、统计信息等。

1．数据抽取

数据抽取是从数据源中抽取数据的过程。实际应用中，数据源较多采用的是关系数据库。从数据库中抽取数据一般有以下几种方式。

（1）全量抽取

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

（2）增量抽取

增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。在ETL使用过程中，增量抽取较全量抽取应用更广。如何捕获变化的数据是增量抽取的关键。对捕获方法一般有两点要求：准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到；性能，不能对业务系统造成太大的压力，影响现有业务。目前增量数据抽取中常用的捕获变化数据的方法有以下4种。

触发器：在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除3个触发器，每当源表中的数据发生变化时，相应的触发器就将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据抽取的性能较高，缺点是要求业务表建立触发器，对业务系统有一定的影响。

时间戳：它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。有的数据库的时间戳支持自动更新，即表的其他字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新时间戳字段。同触发器方式一样，时间戳方式的性能也比较好，数据抽取相对清楚简单，但对业务系统也有很大的侵入性（加入额外的时间戳字段），特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获对时间戳以前数据的delete和update操作，在数据准确性上受到了一定的限制。

全表比对：典型的全表比对的方式是采用MD5校验码。ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据所有字段的数据计算出来的MD5校验码。每次进行数据抽取时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。MD5方式的优点是对源系统的侵入性较小（仅需要建立一个MD5临时表），但缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动地进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。

日志对比：通过分析数据库自身的日志来判断变化的数据。Oracle的改变数据捕获（Changed Data Capture, CDC）技术是这方面的代表。CDC特性是在Oracle 9i数据库中引入的。CDC能够帮助识别从上次抽取之后发生变化的数据。利用CDC，在对源表进行insert、update或delete等操作的同时就可以提取数据，并且变化的数据被保存在数据库的变化表中。这样就可以捕获发生变化的数据，然后利用数据库视图以一种可控的方式提供给目标系统。CDC体系结构基于发布者/订阅者模型。发布者捕捉变化数据并提供给订阅者。订阅者使用从发布者那里获得的变化数据。通常，CDC系统拥有一个发布者和多个订阅者。发布者首先需要识别捕获变化数据所需的源表。然后，它捕捉变化的数据并将其保存在特别创建的变化表中。它还使订阅者能够控制对变化数据的访问。订阅者需要清楚自己感兴趣的是哪些变化数据。一个订阅者可能不会对发布者发布的所有数据都感兴趣。订阅者需要创建一个订阅者视图来访问经发布者授权可以访问的变化数据。CDC分为同步模式和异步模式，同步模式实时地捕获变化数据并存储到变化表中，发布者与订阅者位于同一数据库中。异步模式则是基于Oracle的流复制技术。

ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下次抽取时进行比对，若相同则可忽略本次抽取。

2．数据转换和加工

从数据源中抽取的数据不一定完全满足目的库的要求，例如数据格式的不一致、数据输入错误、数据不完整等，因此有必要对抽取出的数据进行数据转换和加工。

数据的转换和加工既可以在ETL引擎中进行，也可以在数据抽取过程中利用关系数据库的特性同时进行。

（1）ETL引擎中的数据转换和加工

ETL引擎中一般以组件化的方式实现数据转换。常用的数据转换组件有字段映射、数据过滤、数据清洗、数据替换、数据计算、数据验证、数据加解密、数据合并、数据拆分等。这些组件如同一条流水线上的一道道工序，它们是可插拔的，且可以任意组装，各组件之间通过数据总线共享数据。有些ETL工具还提供了脚本支持，使得用户可以以一种编程的方式定制数据的转换和加工行为。

（2）在数据库中进行数据加工

关系数据库本身已经提供了强大的SQL、函数来支持数据的加工，如在SQL查询语句中添加where条件进行过滤，查询中重命名字段名与目的表进行映射，substr函数，case条件判断等。与在ETL引擎中进行数据转换和加工相比，直接在SQL语句中进行转换和加工更加简单清晰，性能更高。SQL语句无法处理的可以交由ETL引擎处理。

3．数据装载

将转换和加工后的数据装载到目的库中通常是ETL过程的最后步骤。装载数据的最佳方法取决于所执行操作的类型以及需要装入多少数据。当目的库是关系数据库时，一般有以下两种装载方式。

① 直接SQL语句进行insert、update、delete操作。

② 采用批量装载方法，如bcp、bulk、关系数据库特有的批量装载工具或API。

大多数情况下会使用第一种方法，因为它们进行了日志记录并且是可恢复的。但是，批量装载操作易于使用，并且在装入大量数据时效率较高。使用哪种数据装载方法取决于业务系统的需要。

ETL工具从厂商来看分为两种，一种是数据库厂商自带的ETL工具，如Oracle warehouse builder、Oracle Data Integrator；另外一种是第三方工具提供商，如Kettle。开源世界也有很多的ETL工具，功能各异，强弱不一。

（1）Oracle Data Integrator（ODI）

ODI的前身是Sunopsis Active Integration Platform，在2006年底被Oracle收购，重新命名为Oracle Data Integrator，主要定位于在ETL和数据集成的场景里使用。和Oracle原来的ETL工具OWB相比，ODI有一些显著的特点，比如和OWB一样是ELT架构，但是比OWB支持更多异构的数据源，ODI提供了call web service机制，并且ODI的接口也可以暴露为web service，从而可以和SOA环境进行交互。ODI能够检测事件，一个事件可以触发ODI的一个接口流程，从而完成近乎实时的数据集成。

（2）SQL Server Integration Services（SSIS）

SSIS是SQL Server 2005的新成员，在SQL Server的早期版本中，其实就已经有了它的雏形，那时的名称为数据转换服务（DTS）。在SQL Server 2005的前两个版本SQL Server 7.0和SQL Server 2000中，DTS主要集中于提取和加载。通过使用DTS，可以从任何数据源中提取数据以及将数据加载到任何数据源中。在SQL Server 2005中，对DTS重新设计和改进形，成了SSIS。SSIS提供了数据相关的控制流、数据流、日志、变量、event、连接管理等基础设施。控制流也称为工作流或者任务流，且更像工作流。在工作流中，每个组件都是一个任务。这些任务是按预定义的顺序执行的。在任务流中可能有分支。当前任务的执行结果决定沿哪条分支前进。数据流是新的概念。数据流也称为流水线，主要解决数据转换的问题。数据流由一组预定义的转换操作组成。数据流的起点通常是数据源（源表）；数据流的终点通常是数据的目的地（目标表）。可以将数据流的执行认为是一个流水线的过程。在该过程中，每一行数据都是装配线中需要处理的零件，而每一个转换都是装配线中的处理单元。SSIS的体系结构如图3.7所示。

3.4.3 Web服务

Web服务是用于实现SOA的最常见技术标准。Web服务从本质上来说是一种基于对象/组件模型的分布式计算技术。Web服务的基础是XML（可扩展标记语言）及基于其上的SOAP（Simple Object Access Protocol，简单对象访问协议）。Web服务的基本结构是：客户端和服务端之间把请求和数据结果以XML的形式进行SOAP包装，以HTTP等形式进行传送，从而实现相应交互。Web服务技术的一大特点是，通过使用Web服务定义接口，可以掩盖各种不同实现之间的区别以及各相互联结的系统之间的异构性。在Web服务技术中，整个网络成为一个开放式的组件平台，通过组合不同的Web组件，应用程序很容易就能得到近乎无限的扩展，从而满足用户的各种功能需求。将Web服务应用于GIS，则可以使传统的地理信息系统由独立的C/S结构或B/S结构，实现到基于Web服务体系的GIS的跨越。

北京市房屋全生命周期管理信息平台是基于SOA的，不是传统的B/S或C/S结构。平台的核心是房屋信息服务，其中包含一系列的Web服务。这些服务可以供公共服务门户使用，更重要的是为市住建委业务系统以及其他应用调用，将来在条件允许的情况下，还可以供其他委办局的系统调用，实现数据、信息与功能的共享。

Web服务是用于实现SOA的最常见技术标准。Web服务又有几种不同的风格。从基本原理层次上说，REST风格和SOAP风格Web服务的区别取决于应用程序是面向资源的还是面向活动的。面向资源服务集中于明确的数据对象，一些基本、标准的操作可以依据这些数据对象而执行。

REST风格的Web服务是面向资源的服务，可以通过统一资源标识符（Universal Resource Identifier, URI）来识别和定位资源，并且针对这些资源而执行的操作是通过HTTP规范定义的。

在面向活动服务中，对客户端请求执行的每个活动的单一操作来说，操作是关注的中心。SOAP风格的Web服务通常是面向活动的。WSDL文档定义并描述特定于服务的操作。操作由特定于服务的消息交换组成。每一个操作都是一个可以执行的活动。那些正在被执行的操作所针对的内容通常是不相关的。正如Web服务资源框架系列规范所描述的，资源可以隐含在活动之中，但是这种隐含与活动的定义不相关，并且只是为了改进执行活动所依赖的上下文。与针对资源而执行活动的面向资源服务相比，它和用来访问资源的服务接口互不相关。

如上所述，REST是网络软件的构架风格，而SOAP则是具体的实现（协议），两者并不是完全对立的。基于SOAP的Web服务广为人知，SOAP、WSDL、UDDI等规范几乎成为Web服务的代名词。而构建符合REST原则的Web服务与SOAP Web服务有很大不同，有必要对两者分别进行研究。

首先，REST Web服务与SOAP使用的寻址模型、接口、对中间媒介和安全性的支持不同。两者交互机制的差异导致REST和SOAP在对互操作的支持、与Web体系结构的关系等方面的区别，如表3-1所示。

（1）耦合度

松散耦合是Web服务声称的一个特点。虽然新的SOAP规范中也支持基于消息传递的交互机制，但是绝大部分SOAP实现仍是基于RPC调用方式。RPC方式是紧密耦合的表现，而紧密耦合的系统是无法适应Web级的规模可伸缩性的。REST Web服务则继承了Web松散耦合的特点，客户应用通过逻辑URL访问服务，服务的实现对客户来说是完全透明的，客户程序可以对服务的实现技术、方法毫无所知。

（2）对互操作的支持

标准化是互操作的关键。万维网上无数资源间之所以可以互操作，是因为WWW建立在下列标准（这些标准也是REST的核心组成部分）之上。

• URI：用于资源的定位与命名。

• 操作资源的通用接口：HTTP协议的GET、POST、DELETE和PUT。

• 资源表示：HTML、XML、GIF、PNG、JPEG等。

• 媒体类型：MIME类型（如text/plain、text/html、image/gif等）。

基于SOAP的Web服务则依赖于定制。每个SOAP消息使用独特的命名资源的方法，或使用UUID，或使用URN；每个SOAP应用需要定义自己的接口。SOAP的这些特点对于服务间互操作的实现十分不利。

（3）与Web体系结构及语义Web的关系

Web的体系结构建立在3个概念的基础上，而且这些概念都与资源有关：资源的确定、与资源的交互、和资源的表示。这些概念分别与Web标准协议相关：URI是定位资源的方法，HTTP协议用于软件代理与资源间的交互，HTML、XML、PNG、PJG、RDF等用于资源的表示。

REST是对Web最成功要素的总结，它建立在一系列标准Web协议之上，跟Web的关系密不可分。万维网的创始人Tim Berners-Lee提出的万维网的远景——语义网，也建立在HTTP、URI、XML、RDF等核心协议之上，这些技术都是这一远景的重要组成部分。基于SOAP、WSDL、UDDI等技术的Web服务并没有根据Web体系结构使用基础的Web协议。例如，HTTP是一个Web应用层协议，但是在Web服务技术中，HTTP却只被用作可选的传输机制，将其本身可作为应用协议的特点置之不顾，而要求每个SOAP应用都定义独特的接口。URI是URL（统一资源定位符）和UNR（统一资源名称）的超集，并能由两者分别或共同表示；URL是最常用的URI之一。URI是Web上资源定位的首要方式，Tim Berners-Lee甚至认为URI是Web体系结构的公理，并认为不管任何地方的任何资源都可得到一个URI，任何重要的资源都应该分配一个URI。

REST的观点与此相吻合：每个资源都应有一个逻辑URI。而在SOAP服务中，URI的角色被定制的寻址方式（如UUID、URN等）替代；URI只是用来定位SOAP服务器，与资源不是一一对应的关系，所有对资源的访问都通过一个URI指向的SOAP服务器进行；这种做法与语义Web的远景也是不相适应的。因此有学者对此颇有批评，认为SOAP Web服务不依赖Web协议，并不是真正意义上的“Web”服务。

3.4.4 数据仓库技术

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

数据仓库层是专门针对企业数据整合和数据历史存储需求而组织的集中化、一体化的数据存储区域。数据仓库由覆盖多个主题的企业信息组成，这些信息主要是低级别、细粒度数据，同时可以根据数据分析需求建立一定粒度的汇总数据。它们按照一定频率定期更新，主要用于为数据集市提供整合后的、高质量的数据。数据仓库一般很少直接面向最终用户。数据仓库侧重于数据的存储和整合，通常采用轻量级索引。

数据仓库的架构如图3.8所示。

① 数据源是数据仓库的基础，位于数据仓库构架的最底层，是数据仓库的数据源泉，包括各个业务处理子系统的信息。

② ETL是数据仓库的核心。数据仓库如何高效管理数据是区别于面向操作数据库的主要标准。完成按照主题管理数据，聚合数据存放于多维数据库中。

③ 数据存储与管理是整个数据仓库系统的核心。

④ OLAP服务器对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。

⑤ 前端展现主要包括各种报表、查询、OLAP分析、数据挖掘等。

数据处理大致可以分成两大类：联机事务处理OLTP（On-Line Transaction Processing）与联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLAP是一类使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取，从而对数据有更深入了解的软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求，它的技术核心是“维”这个概念。“维”是人们观察客观世界的角度，是一种高层次的类型划分。“维”一般包含着层次关系，这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维（dimension），使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。

OLAP的基本多维分析操作有钻取（roll up和drill down）、切片（slice）、切块（dice）以及旋转（pivot）等。钻取是改变维的层次、变换分析的粒度，包括向上钻取（roll up）和向下钻取（drill down）。roll up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而drill down则相反，它从汇总数据深入到细节数据进行观察或增加新维。切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，就是切片；如果有3个，就是切块。旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

3.4.5 商业智能

商业智能（Business Intelligence, BI）通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。而商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策。为了将数据转化为知识，需要利用数据仓库、联机分析处理（OLAP）工具和数据挖掘等技术。

因此，从技术层面上讲，商业智能不是什么新技术，只是数据仓库、OLAP和数据挖掘等技术的综合运用，将其看成是一种解决方案应该比较恰当。商业智能的关键是从许多来自不同的企业运作系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取、转换和装载，即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图，在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识），最后将知识呈现给管理者，为管理者的决策过程提供支持。

商业智能产品及解决方案大致可分为数据仓库产品、数据抽取产品、OLAP产品、展示产品和集成以上几种产品的针对某个应用的整体解决方案等。

实施商业智能系统是一项复杂的系统工程，整个项目涉及企业管理、运作管理、信息系统、数据仓库、数据挖掘、统计分析等众多门类的知识。因此用户除了要选择合适的商业智能软件工具外，还必须按照正确的实施方法才能保证项目得以成功。商业智能项目的实施可分为以下几步。

① 需求分析：需求分析是商业智能实施的第一步，在其他活动开展之前必须明确地定义企业对商业智能的期望和需求，包括需要分析的主题、各主题可能查看的角度（维度）；需要发现企业哪些方面的规律。用户的需求必须明确。

② 数据仓库建模：通过对企业需求的分析，建立企业数据仓库的逻辑模型和物理模型，并规划好系统的应用架构，将企业各类数据按照分析主题进行组织和归类。

③ 数据抽取：数据仓库建立后必须将数据从业务系统中抽取到数据仓库中，在抽取的过程中还必须将数据进行转换、清洗，以适应分析的需要。

④ 建立商业智能分析报表：商业智能分析报表需要专业人员按照用户制订的格式进行开发，用户也可自行开发（开发方式简单、快捷）。

⑤ 用户培训和数据模拟测试：对于开发、使用分离型的商业智能系统，最终用户的使用是相当简单的，只需要直接操作就可针对特定的商业问题进行分析。

⑥ 系统改进和完善：任何系统的实施都必须是不断完善的，商业智能系统更是如此。在用户使用一段时间后可能会提出更多、更具体的要求，这时需要再按照上述步骤对系统进行重构或完善。