背景及要求

需要将数据提供方(对方)的数据同步到本地(我方)
目的是在本地维护一个与数据提供方一致的本地数据库(ORACLE)
数据提供方提出的方案就是我方开发一个Web接口供其调用
数据方给出其发送数据的格式等信息,即给出了接口规范

交互情景

对于实时数据,数据方在收集后每隔十分钟调用一次接口推送过来这些数据
我方接口对其推送数据进行解析并入库
对于先前历史数据,直接以文件方式提供给我方
我方直接用本地程序解析后入库,不通过接口

推送数据的具体规范

原始数据采用的是XML格式的文本,先后经过base64编码和DES加密,之后对方推送至我方
原始数据是格式化且规范的,XML共分四级,第三级标签开始代表每一次操作的表数据
原始数据包含CLOB和BLOB类型的数据 - 插入Oracle时要额外处理
原始数据包含的字段每次都是不确定的
一次推送包含若干原始数据段,即本地入库时对表的操作也是不确定的
推送的数据量可能很大,一次推送纯文本大约20MB - 构造SQL语句时要额外处理,否则SQL语句会过长(超过4000)
数据对应表有5张,每个表平均100个字段左右

对于历史数据

数据就是一堆编码并加密了的字符串 - 对其处理与处理推送数据的逻辑差不多
此字符串非常长,文本大小约500MB - 在解密解码时只要加大内存限制就可以完成,但解析XML时需要SAXReader方式,dom方式的话要爆炸了
原始数据包含CLOB和BLOB类型的数据 - 插入Oracle时要额外处理
原始数据包含的字段每次都是不确定的
一次推送包含若干原始数据段,即本地入库时对表的操作也是不确定的

我方开发接口的情况

接口参数包括验证信息,和数据,就这两个参数
接口采用JAX-WS实现,原因是其实现比较简单且轻便,可以参照:真正的轻量级WebService框架 - 使用JAX-WS(JWS)发布WebService
接口任务一,DES解密并base64解码推送来的数据
— 解密方式一定要和对方的一致,这里直接用对方提供的加解密代码,并且对方告知了DES秘钥
— 解码就比较随意,base64解码都大同小异
接口任务二,用dom4j包来解析XML树,这里采用SAXReader的方式,原因上面说了
接口任务三,映射表名字段名,原始推送数据字段均为汉字,Oracle库中存的都是首字母大写
接口任务四,构造SQL语句,具体思想就是解析XML到第三级标签,这一级会包含所有<插入字段名>和<插入字段值>

整个流程大致如下

此处为博客中出现的关于Spark、Hadoop、Java、IDEA、Js及html相关内容的图片

下面是上述叙述中遇到的问题:

  • 如何按原始数据中的汉语字段建立数据表
  • 如何监控接口的情况也是问题,生成日志是解决之道
  • 乱码问题!!服务器?编译时?原数据?UTF-8?GBK?到底是谁的锅
  • 如何将原始字段快速映射成我即将将其插入到表中的对应字段
  • Oracle字段的符号要求,废了很多时间
  • 大量字段中含少量CLOB字段时,对CLOB类型的数据使用jdbc插入数据库
  • 大量字段中含少量BLOB字段时,对BLOB类型的数据使用jdbc插入数据库,这个费了一番功夫
  • 整明白插入时,涉及大量字段操作时,对数据的增量更新也是问题
  • SQL语句如何执行,批量还是单独,这是个问题
  • 程序循环过多导致Oracle连接游标数超出限制的问题

以上问题先放着,抽空再逐个分析,如果上述包括了您急需解决的问题,请@我我会尽快回复我的解决办法,或许对您会有帮助。

对于接口的传输性能

  • 开始时错误的以为历史数据也要通过接口方式调用,就对JWS发布的这个接口进行了一下测试,发现接口的极限是200M左右
  • 也就是说调用接口时,传入参数的字符串大小可以为200M没问题
  • 上述都是废话,正常是不允许出现上述情况的