近年来, 随着移动互联网和云服务等信息技术的迅猛发展, 个人知识环境日趋泛在化 (Ubiquity) 。这种泛在知识环境在为人们提供信息便利的同时, 也带来一些“副产品”, 个人数据分散于不同的系统中是最为突出的问题之一。为了解决这种泛在个人数据的一体化管理问题, 国内外学者提出了一系列相关的泛在个人知识服务模型, 典型的如:Schwarz[ 1]提出的EPOS模型、Maus等[ 2]提出的PIMO模型和乐小虬等[ 3]提出的EUPKS模型等。个人数据同步是这些模型实施过程中的重要环节, 用于保持不同设备间的数据一致性及完整性, 从而解决知识碎片整合问题。
本文在比较分析当前个人数据同步方法的基础上, 根据系统具体应用的特点, 采用交换操作日志的策略实现了个人数据同步, 以下具体阐述同步原理、基本框架及技术流程, 并简述其在e划通[ 4]系统中的应用实践。
数据同步是指在一段时间内维持不同地点的多个数据库间数据一致性的处理过程[ 5]。个人数据同步以泛在
设备中的个人数据为同步对象, 同步过程需解决三个关键问题:
(1) 数据复制策略选择。主要是决定系统何时进行同步, 通常有实时复制和异步复制两种方式。前者用于数据时效性高的系统, 如在线游戏[ 6]、传感器融合系统[ 7]、数据集成系统[ 8];后者用于时效性低的系统, 如移动设备的数据同步[ 9, 10, 11]。
(2) 数据变化捕捉。它是指识别和记录个人数据发生的变化, 据此决定需要复制的部分数据[ 12], 主要方法有:快照法、触发器法、时间戳法、日志法、API法、影子表法及摘要法[ 13, 14, 15]。
(3) 数据冲突处理。数据冲突因多个设备对数据执行不同的操作而产生, 常用的解决方法有:时间戳法、规则法[ 9, 14]、事务回滚法[ 16]。
从数据变化捕捉的角度上看, 个人数据同步通常采用以下几种方法:
(1) 触发器法:当发生变化时唤醒同步程序, 将变化数据复制到其他数据库[ 8];
(2) 影子表法:为数据表建立一个初始状态的表, 通过比较该表与更新后的表来获得变化数据, 并将其复制到其他数据库;
(3) 时间戳法:为每个数据记录一个时间戳, 用于识别变化数据和解决数据冲突;
(4) 摘要法:它是影子表法的优化, 摘要一般为数据的散列值, 通过比较不同版本的摘要识别变化数据, 同步时交换净变化数据;
(5) 日志法:为每条数据操作记录日志, 其他数据库根据相应日志进行数据更新。该方法能快速识别变化数据, 并保存不同时间的多个数据版本, 同步失败时可依此进行事务回滚。
各方法对比如表1所示:
![]() | 表1 个人数据同步方法比较 |
由于单一方法存在一定的局限性, 往往多种方法结合使用, 如触发器法与摘要法结合[ 13]、触发器法与影子表法结合[ 17]、触发器法与日志法结合[ 18]等。
从实现方式上看, 个人数据同步的实现常采用标准同步协议、使用中间件、基于SOA服务和自定义4种方法。
(1) 标准同步协议定义了数据表示规范、数据同步过程描述及数据同步系统框架, 包含数据变化捕捉方法及冲突处理方案,并提供多个备选数据复制策略。目前成熟的协议有HotSync[ 19]、ActiveSync[ 20]、OMA SyncML DS[ 21]等, 前两者分别应用于Palm Co.和Microsoft中移动端与桌面端个人数据同步, 后者为开放数据同步协议, 可用于不同设备的数据同步。
(2) 数据同步中间件位于平台与应用程序之间负责跨平台的文件与数据同步的独立应用程序, 实现了包括同步协议、数据通信、数据变化捕捉与冲突处理等大部分功能, 泛在系统只需调用相关API即可实现同步功能, 可用的中间件有Rsync[ 22]、One.World[ 23]、XMIDDLE[ 24]、Aura[ 25]、Wukong[ 26]、Polyjuz[ 27]、Syxaw[ 11]、UAAM[ 28]等。
(3) 基于SOA服务的同步方法是通过ESB、Web Services 和 JMS等技术架构将数据服务开放, 客户端通过访问服务接口完成同步, 如Su等[ 29]、Zhu 等[ 30]的研究。
(4) 自定义方法是针对具体系统需求设计的数据同步方案, 有不同的侧重点:以提高数据变化识别效率为目的, 如Yang[ 8]采用数据库触发器识别变化数据并实时引发数据同步, Liu等[ 31]通过优化数据操作日志提高同步效率;以优化同步系统架构为目的, 如Khan等[ 32]为减少数据系统复杂性, 将同步功能构建成可重用组件;针对特殊的系统应用, 如Choi等[ 20]针对个人云存储提出Ad Hoc数据同步框架。
各实现方法的对比如表2所示:
![]() | 表2 个人数据同步实现方式比较 |
基于日志的泛在个人数据同步 (Logs-based Ubiquitous Personal Data Synchronization, LUPDS) 主要是解决泛在环境下个人知识碎片的一体化管理问题。通过不同环境下系统间的数据交换, 保证各设备拥有一致、完整的个人知识空间。LUPDS将泛在设备间的数据同步分解为客户端-服务器数据同步:服务器存储一个数据基本集, 客户端与服务器同步, 将其所有数据更新写入服务器, 同时获得与服务器一样的数据集。通过系统中的所有泛在设备与服务器同步, 各设备均可获得包含其他不同设备中的数据的统一数据集, 实现知识数据整合。其同步模式如图1所示:
LUPDS采用日志进行数据变化捕捉及同步数据交换, 并结合时间戳方法解决数据冲突。在进行任何数据库操作的过程中, 将操作的类型、时间戳、变化后的内容写入日志。同步时, 客户端和服务器双方交换日志, 执行对方日志的所有操作以更新数据库, 达到数据统一。更新过程中如遇到冲突, 将比较多个冲突操作的时间戳, 只执行最新时间戳的操作。通过这种方式, LUPDS保证同步双方的数据集完整一致。
考虑到泛在系统同步的效率及扩展性问题, 采用自定义同步方法实现。实现框架分为服务器和客户端两部分。服务器及客户端都包括数据管理、日志生成、日志解析、更新执行、同步配置、授权认证等模块, 客户端增加同步发起模块, 用于发起数据同步。整体框架如图2所示:
(1) 数据管理
数据管理是底层数据操作模块, 其他模块的所有数据操作都通过调用该模块完成。通过在执行数据库操作时记录相应数据的操作日志, 实现数据变化捕捉。
(2) 日志生成
日志生成模块将数据操作日志按照指定规则组合起来, 用于同步时数据交换。得到的数据格式要求:数据量少, 减轻数据通信负担;复杂度低, 提高日志解析效率;数据透明, 需按照通信协议要求将数据转义, 以免因特殊字符产生数据截断。
(3) 日志解析
日志解析是日志生成的逆过程, 需要将接收到的日志数据解包, 并转换为数据更新事务集。解析规则与生成规则相对应, 解析效率由数据格式的复杂度决定。
(4) 更新执行
解析后的数据更新事务由该模块执行。首先, 验证数据记录的完整性, 如遇到不完整的数据记录, 则按照指定的策略处理, 如:忽略该数据更新;为缺失部分信息填写默认值。然后, 通过验证的数据事务集由该模块调用数据管理模块执行相应数据库操作。
(5) 同步配置与授权认证
同步配置用于管理同步状态数据, 如同步成功时间、同步类型标识 (全量同步或增量同步) 、数据最大ID等。授权认证模块用于确认设备身份的合法性, 包括两方面功能:对发出的同步数据附加授权信息;对接收的同步数据进行授权检查, 排除非法数据。
LUPDS技术流程包含两个阶段。第一阶段是记录操作日志, 由数据管理模块执行数据操作时记录。第二阶段是数据同步, 分三个步骤:客户端发起同步, 将日志、配置信息、授权信息发送给服务器;服务器接收数据, 检查授权及配置信息, 更新数据库并向客户端返回需更新的日志;客户端更新数据库及配置信息。详细流程如图3所示:
数据变化捕捉、数据冲突处理是同步的关键环节, 前者通过记录日志获得同步所需数据和控制信息, 后者保证同步的安全性和鲁棒性。
(1) 基于操作日志的数据变化捕捉方法
该方法利用操作日志识别需要同步的数据项。日志记录数据操作的类型 (新增、删除、修改等) 和更新后的数据内容, 同时, 为了保证数据操作顺序的正确性, 记录每个操作的时间戳。日志由数据管理模块管理, 当发生数据操作时, 该模块分析数据变化并将上述信息记录到日志表中。随着多个数据操作的执行, 日志表存储了数据项在不同时间点上的状态序列, 这个序列反映了整个数据库的变化。同步时, 双方交换日志, 按时间戳顺序重做所有操作即可获得与对方一样的数据集。若同步失败, 双方可按日志进行事务回滚, 恢复某个约定时间点的数据。
(2) 数据冲突处理方法
有两种情况导致数据冲突:同步时发生意外导致数据不能正常更新和回滚, 称为全局冲突;由于采用异步复制策略, 各个设备的数据库变化没有马上反映到其他的数据库中, 同步时同一个数据需要执行多个设备不同的操作导致产生错误, 称为数据记录级冲突。
LUPDS通过配置同步类型标识和时间戳来解决全局冲突。初始状态时, 客户端同步配置模块给出一个全量同步标识;服务器收到该标识后, 将所有数据组装成新增数据日志并生成一个时间戳, 一同返回到客户端;客户端写入这些数据, 并记录该时间戳。在下次同步时, 客户端将增量同步标识和上次同步完成记录的时间戳, 连同日志一起发送给服务器;服务器检查时间戳, 若与服务器端配置记录一致, 则继续执行增量同步, 否则返回服务器所有数据及全量同步标识, 让客户端覆盖所有数据。
对于数据记录级冲突, 参考Choi等[ 14]总结的16种数据操作, 分析可能发生的冲突情况如表3所示:
![]() | 表3 数据记录级冲突分析表 |
在表3中, 有两个主要数据记录级冲突需要解决:ID冲突, 如情况6, 双方新增数据, 导致不同数据占用同一个ID;同一数据不同操作的冲突, 如情况11、12、15、16。
LUPDS对每条数据记录采用两个ID标识来解决ID冲突:CID为客户端数据标识;SID为服务器数据标识。对于一条新增数据, 只记录当前一方的ID, 另一方的ID为空。同步时, 客户端向服务器发送一个MaxID, 服务器从该MaxID开始递增填充所有服务器端新增数据的CID, 然后将客户端新增已包含CID的数据添加到服务器中, 至此, 服务器上已有一个完整的数据集, 所有的数据均有CID与SID。最后将服务器端新增及修改CID的数据返回到客户端, 客户端据此更新数据得到与服务器一样的数据集。
为解决同一数据不同操作的冲突, LUPDS在数据表和日志表中均记录一个时间戳。执行更新时, 比较日志的时间戳与数据的时间戳, 若日志的时间戳较新, 则更新数据库, 否则丢弃该操作。另外, 若日志要更新的数据不存在, 则丢弃该更新, 避免出现更新已删除数据的错误。
目前国家科学图书馆e划通系统[ 4]已采用LUPDS实现了桌面客户端与服务器间的数据同步。系统中的个人知识空间用主题 (Channel) 和知识单元 (Item) 表示[ 3], 一个主题下有多个知识单元, 不同的主题按其之间的语义关系 (如上、下位等) 组成一个层级结构。数据同步操作可使客户端和服务器端的所有主题和知识单元保持一致。以知识单元数据同步为例介绍LUPDS的具体实施过程。
e划通系统中已有数据管理、配置管理、授权认证等模块, 数据同步中与这三个模块相关的功能通过托管或嵌入的方式实现。数据同步需要同步时间戳、设备ID、数据ID等配置信息及用户授权认证信息, 均由e划通原有的配置管理模块和授权认证托管管理, 同步时调用相关API进行读写。日志操作通过编写相应代码嵌入数据管理模块实现, 这些代码实现的功能主要是数据库操作分析和日志表读写。
e划通数据同步采用HTTP协议作为底层通信协议, LUPDS包装好的数据经过加密, 然后由HTTP通信模块与服务器进行数据交换。
e划通数据操作日志存储在数据库中, 为了减少数据量, 日志以自定义格式存储:先用指定规则将数据内容的特殊字符转义, 再用“las_字段名=”+“内容”表示各个字段及其内容。一个数据样例如下:
las_dotype=add &las_locitemid=27848&las_title=新摘录条目&las_content=猴子侦察兵:大数据时代不需要福尔摩斯2013-05-13\工作与思维的大变革》中前瞻性地指出, 大数\据带来的信息风暴正在变革我们的生活、工作和思维, 大数据开启了一次重大的时代转型, \并用三个部分讲述了大数据时代的思维...\^暂无评价|\!|共1页|\!|下载:0次|\!|贡献者:iqbstz1588
在实际应用环境中, 同一数据因用户多次编辑而产生冗余操作日志。针对这个问题, 在LUPDS的基础上, 设计了一套日志合并规则, 将同一数据的所有日志合并成一个, 减少同步的系统开销, 提高效率。该日志合并规则如表4所示:
![]() | 表4 日志合并规则表 |
e划通的数据同步由按钮事件触发, 依次调用相应模块获取数据日志、配置信息、授权信息, 然后通过HTTP协议与服务器通信, 服务器更新数据后返回待更新日志, 最后更新客户端数据。同步时, 程序相应依次报告“准备数据→交换数据→分析数据→更新数据→更新配置→完成”等状态。同步结果如图4所示:
本文基于操作日志实现了泛在个人数据同步。该方法以服务器为中心, 通过各个设备与服务器进行日志交换和执行日志相应操作, 保持个人知识空间中数据的一致性。这种方法各模块之间松耦合, 易于嵌入已有的离散数据系统, 同时, 可根据实际的应用环境进行扩展或修改, 具有较好的适应性, 适用于多设备异构数据库之间的数据同步。目前LUPDS已应用在e划通系统中, 实现了客户端与服务器之间的知识数据同步, 有效促进个人知识数据的一体化管理。不足之处在于, 目前仅限于Windows桌面平台的客户端与服务器之间的同步, 在移动终端上未得到验证。后续工作将在移动终端上进行实践和验证。
[1] |
|
[2] |
|
[3] |
|
[4] |
|
[5] |
|
[6] |
|
[7] |
|
[8] |
|
[9] |
|
[10] |
|
[11] |
|
[12] |
|
[13] |
|
[14] |
|
[15] |
|
[16] |
|
[17] |
|
[18] |
|
[19] |
|
[20] |
|
[21] |
|
[22] |
|
[23] |
|
[24] |
|
[25] |
|
[26] |
|
[27] |
|
[28] |
|
[29] |
|
[30] |
|
[31] |
|
[32] |
|