需求背景
在我们采集数据时,有些数据可以直接通过爬虫来获取,但有些数据出现在PDF,Excel,Word等文档中时,爬虫实现就有局限性了,我们必须编写很多自定义函数用来解析文档,并且脚本代码一多,就失去了可维护性和使用爬虫编写业务逻辑的初衷。所以我们需要建设一套解析流水线来实现提取文档数据的需求。甚至需要从PDF影印版中提取数据,总体需求简述:
可从任意格式文档中抓取所需的结构化数据;
如果文档中整页数据是图片,需要将其转换为文字;
建立可视化流程用来管控解析流程。
业务部支持人工核验;
解析数据支持质检规则;
解析的数据值支持格式化统一成统一格式(比如有亿元,万元,最终数据统一到万元);
设计思想
想要实现以上需求并不是一件容易的事,甚至有点复杂。我们将其分解成多个子任务来实现。
其中标橘色的功能模块是关键或主要的技术瓶颈点:
OCR处理程序:我们能有效识别文档中的图片转成文字并结构化,但表格单元格合并,无线表格,表格上印章去除等技术难点尚未突破,在无干扰情况下,文字识别率90%以上。
文档结构化SDK:就是将各种PDF,Word,Excel文档统一转成HTML的技术,这个目前有较成熟的商业SDK也不贵,我们也是花钱买的,自己做有一定的技术难度,特别是在无线表格,表格单元格识别上难度很大;
可视化建立字段抽取规则库:纯Java+JS即可实现,将业务剥离出来使用JS编写抽取规则即可;
解析流水线:根据历史经验,文档解析如果从 业务出发去制定通用流水线是不现实的,因为同类型的PDF文档(比如募集说明书)各家公司格式千奇百怪,比如募集资金字段,甚至名称都是不同的,所以要和业务部门充分沟通,建立可行的解析流水线也是一个难点;
统计审核信息:这个是从业务准确性出发的,解析流水线应能统计出对应的数据解集(因为抓取的文档可能有疏漏),应有机制明确告知业务部门该抓的文档都抓全了,该解析的字段也都解析出数据了,这也很关键。
另外,平台提供了在线调试规则的能力,这也很关键。
有了以上实现流程图后,那么想要实现文档解析平台就相对容易多了,以下,给出我们平台实现的完整实现过程的效果展示。
实现效果
爬取文档并智能归类
通过爬虫从各个数据源爬取文档并通过后台可配置的归类规则将文档归类,并从文档中分析出对应的对象ID(比如公司ID,债券ID等)
文档处理
这是一个难点,比如我们系统将影印版解析为HTML的效果:
可以看出,对于比较清晰的影印版PDF效果还是相当不错的,这个是所有工作的基础,如果这步效果不理想,那么解析数据就是扯淡了。
定义分类下的解析流水线
分类下可定义N条解析流水线
如下分类定义了两条流水线:
流水线下可以定义具体规则,要注意,这里规则可以是从正文中提取,也可以从表格中提取数据(在这里,我们可以知晓,通过将文档中表格标准化可大大提高解析速度,无需从整篇文档中去解析了,这就是KV库分库分表的意义),正文匹配可以定义数据从前N页中提取,以便加快提取速度。
接下去就是具体数据的提取规则了:
一个字段可以有N个规则,他们之间的提取规则是else if的关系,因为有些字段数据的提取是非常复杂的,规律少。这中间需要你调测提取数据的逻辑,系统支持在线调试。
数据审核控制台
这是一个显示当前流水线解析出来的数据的一个动态行(待解析的分页数据)动态列(所有解析字段)的表格,可以看到,解析效果还是不错的,个别标红的标识解析质检未过或质检数据与数据库中数据(原有这些数据都是手工录入的)有差异的。
整套系统还在逐渐磨合中,但大体实现思路本文以全文介绍,数据采集是一个非常有意思的工作,它不仅包含了大存储,大数据,人工智能,还涉及工作流程,业务,数据质检报警等,是一项非常有挑战性的工作。
你可以继续阅读:
一款自动生成后台代码的管理系统的设计与实现 | “大”中台,“小”前端的架构演变| 云服务平台中推送服务的设计与实现 | 对微服务的理解以及实现一套微服务对外发布API管理平台 | 项目开发中常用的设计模式整理 | 异构语言调用平台的设计与实现 | 大话正则表达式 | 云API平台的设计与实现 | 个税改了,工资少了,不要慌!文末附计算器
关注我们的公众号
长按识别二维码关注我们