数据桥接子系统将慢慢退出舞台

随着电子政务建设的深入，加快政务信息资源开发利用建设，解决政务部门间信息资源的查询和共享，促进跨行业跨部门跨地区面的互连互通已成为政务建设的热点。国务院信息化工作办公室 2005 年发布的《政务信息资源交换体系》已为政务资源交换体系给出了参考，其中提出了全国政务信息资源交换体系的总体框架、概念模型、交换模式、交换结点基本功能、应用参考模型。

在《政务信息资源交换体系》中包括一个政务资源交换系统，它由交换桥接子系统、前置交换子系统、交换传输子系统和交换管理子系统等几个部分组成。

其中，交换桥接子系统主要实现部门前置交换信息库与部门业务库或虚拟业务库之间的在线、实时数据交换，可在完全隔离的两个网络之间实现信息资源的交换与共享。一般来说，交换桥接子系统部署在部门交换前置机上。

交换桥接在部门网络与省政务网络之间架起了一座数据交换桥梁，通过数据层面的桥接配置及管理，而非网络层面的连通，来实现部门业务库与部门交换前置库之间的指定表的双向在线、实时数据交换。

从业务场景上来看，之所以会提出交换桥接子系统，是出于数据安全考虑。通过一个前置机的前置数据库，将整体数据集成平台和业务数据库隔离开，能够有效地保障政务部门的业务数据的安全性。政务部门根据实际的业务需求，对外提供数据，具体提供哪些数据，将根据具体的业务需求，通过配置交换桥接子系统来完成和实现。

从上面的业务场景和功能结构来看，我们可以得出交换桥接子系统的具体的功能特性：

1、          能够针对各种关系数据库进行两个或多个关系数据库之间的数据同步

2、          能够分析数据的增量变化，并且针对增量数据进行数据同步

3、         能够实现数据的转换、影射等操作

4、         能够满足日志、权限等非功能性需求

接下来重点分析第二个功能特性，增量数据分析。

增量分析，指的是能够侦听部门内业务数据库或者前置交换数据库的数据变化，这些变化可能是 Insert 、 Update 或者 Delete 操作，能够记录下这些变化数据，以供数据双向同步的时候使用。

那么增量分析如何实现？目前存在多种方式，下面来逐个分析。

1、          数据库触发器方式

数据的增量分析，大家首先想到的就是触发器。可以在需要侦听数据变换的表上面，建立触发器。触发器能够在数据发生 Insert 、 Update 、 Delete 的时候，被激活。触发器可以将操作类型（ Insert 、 Update 、 Delete ）记录下来，可以将发生变换的数据记录下来。

通过触发器的方式，进行增量分析的实现，有一些关键点的需要注意：

u 需要定义哪些字段的数据发生了变化，才算是发生了增量变化。

u 当发生增量变化的时候，哪些字段的数据是需要同步的

目前，很多作数据集成的厂商的产品，没有严格的区分这两个逻辑上的概念，这是不合理的。这是逻辑上一定需要区分的两个步骤，一个用来说明什么才算增量，一个用来说明，发生增量的时候，同步那些数据。

明确了这两个步骤之后，在实现上，也就意味着，针对那些需要进行同步的字段，当“数据变化”这个事件被确认后，必须将这些字段的值同步地在临时表或采用其他的方式进行持久保存，以供数据同步时使用。也就是说，当增量数据同步的时候，增量数据是从这些临时表中或者持久介质中获取。而不能从原始的数据表中获取。

同样，在某些场景下，可能还会有额外的条件，例如某个整形字段值超过了 1000 才算变化数据等。

触发器是一种非常有效的数据增量分析的方式，从技术特性本身来说，没有缺陷。但是在可使用的场景上，受到较大的限制。有些政务部门考虑自身数据库的安全和性能问题，对于数据桥接来说，只公开数据库的访问权限，不公开任何的可操作权限。这时候，触发器是无法建立的，只能采取其他的手段。

 

2、          时间戳分析方式

另外一种比较有效的增量分析方式，是根据时间戳来分析增量。每一次同步之后，数据桥接组件记录数据同步的时间。然后下一次同步时，根据这个时间和记录中的一个时间戳字段所记录的时间进行比对，晚于上次同步时间的记录，被认为是增量记录。

这样的分析方式和触发器相比，不是非常可靠。这样的增量分析方式，对应用系统本身的设计有要求：

u 必须存在一个时间戳字段

u 这个时间戳字段时一个 LastState 时间戳

同时，对于 Delete 操作，时间戳比对无法分析。必须辅以其他的分析方式，例如记录的 checksum 的方式，才能处理 Delele 的数据变化。

3、          记录 checksum 方式

在进行第一次数据同步的时候，将所有记录的 checksum 值计算并缓存下来。当进行下一次数据同步的时候，获取全部的记录集，然后逐条逐条根据主键信息进行记录的 checksum 的比对，从而分析和判断得出 Insert 、 Update 和 Delete 增量。

当数据库被设计成没有主键的时候（很不合理，不是吗？非常不幸的是，很多政务应用的后台数据库设计，偏偏就是没有主键的），这样的比对计算会非常的繁琐。

这样的方式，从理论上，可以完整地得出详细的数据增量变化，但是无法真正的在工业应用中使用――对于性能的损耗实在无法让人接受。在十万级、百万级数据量的时候，这种 checksum 的计算以及比较会非常的耗时。

4、          利用数据库特性分析增量方式

针对于特定的数据库，可以利于数据库本身的特性，来进行增量数据的分析。例如针对 Oracle 9i 和 Oracle 10g ， 提供了 FlashBack 这样的技术。通过这个技术，可以分析出来，针对某张表，曾经有哪些操作，并且在操作执行之前的值，也可以查询得到。通过 FlashBack 技术，可以达到和触发器一样的非常可靠的增量分析效果。

但是，不是每个数据库都提供这样的特性，普遍的数据库产品，能够提供操作日志。但是仅仅提供操作日志，是不够的，针对 Delete 的场景，还必须能够提供操作之前的记录值。

举个简单的例子，业务数据库和前置数据库的主键类型不一致。业务数据库的主键是 sequence ，前置数据库的主键是 UUID 。当业务数据库中删除了一个记录，仅仅通过日志得到什么时候执行了一个 ”delete from T where f1 = 132” 是不够的，无法完成数据的增量分析。必须要知道在执行这个 SQL 之前，原来的记录值是多少。

这样的增量分析方式，取决于数据库本身，无法形成统一的方案。  

上述几种数据增量分析的方式，各有优缺点。一个好的数据集成产品，应该能够支持这样多种的数据增量分析方式，提供多种途径解决不同的业务场景下的业务需求。

但是，从业务角度和整体架构上来看，通过数据桥接组件这样的被动方式来完成部门的业务数据库和前置数据库之间的数据同步，不是非常的合理。

比较合理的体系应该是，由部门的应用系统，在修改自身业务数据库数据的同时，决定这个数据是否需要同步到前置数据库中。这样的方式，无论是从业务角度，还是从数据安全性角度来说，都是最为合理的。

但是目前，我们国家的现状就是这样，政务部门的应用已经搭建起来了，对这些应用系统进行改造，需要大量的工作量和时间、人力、资源成本。从这个角度来看，数据桥接子系统，是一个临时性的方案，随着我们国家的信息化建设逐步的完善，最终，这个组件将会慢慢退出舞台。

本文出自 “javafans 日记” 博客，转载请与作者联系！