CN105183470B - 一种自然语言处理系统化服务平台 - Google Patents

Abstract

本发明公开了一种自然语言处理系统化服务平台，包括稳定的流式处理系统、非稳定的机器集群系统和分布式多副本下载系统；C‑API接口、Python接口和http服务端接口；多语言服务框架和分布式远程调用服务器；所述流式处理系统采用消息队列的设计方式，消息队列分为队头和队尾两个组件，算子从队尾组件中接收数据进行并行并消费，实现数据的传递。本发明利用了计算机多核并行计算的优势，充分均衡的利用高性能计算机的计算资源，构架出高效高可靠性的自然语言平台，本发明的HTTP接口、C++语言和python的接口，提供方便在接口方面的调用，支持多平台的调用，具有很好的工程应用价值。

Description

一种自然语言处理系统化服务平台

技术领域

本发明涉及语言处理技术领域，特别是涉及一种自然语言处理系统化服务平台。

背景技术

非实时计算几乎都基于 MapReduce 计算框架，但 MapReduce 并不是万能的。对于搜索应用环境中的某些现实问题，MapReduce 并不能很好地解决。特别是 Twitter 推出的 storm 在取得巨大成功之后，各大互联网公司，尤其是基于数据挖掘，搜索引擎开发的互联网公司都争先进入这一领域，各个公司都推出自己的流式计算系统，其中著名的公司有Google，Twitter，Facebook 等公司。

稳定的流式处理系统流式计算平台，面向大数据实时处理领域、实现拓扑式的流式计算模型，率先支持 dprc 等高级应用，并预期支持迭代式计算。系统采用 RP 自主研发的分布式消息队列 spinal 系统，实现数据的分布式拥塞控制与数据传输，以用户需求为核心，支持多语言调用，多实例并发，并作为独立的计算单元，满足多模式的运维层系统调度。从系统资源利用率的角度出发，其在满足系统运行的前提下，提升资源利用率，降低系统成本。对于海量数据运算，可完美结合公司非稳定的集群系统，实现量级部署与调度。该系统大胆进行创新工作，与公司nlp等部门进行基础架构合作，推出nlpc平台，支撑公司内基础算法的平台化工作。

现有调用 NLP 的方法主要是本身已经实现好的动态链接库，或者函数库之类的，可以进行调用，但是事实上这种做法存在如下缺点，一方面算法调用者需要添加和维护这个算法本身的文件，使用门槛比较高 ；另一方面算法升级比较麻烦。

而一个平台化的自然语言平台，算法的开发者本身只需要开发一个版本的动态链接库，不需要管算法调用实现，算法调用者只需要发送算法的名称和参数，则可以在低延时的情况下得到正确的结果。在扩展性和稳定性方面有更好的表现。采用插件式的设计方案，增强系统的可扩展性。经调研，目前适用于大规模集群，支持自然语言平台化的软件还没有。然而，paas（Platform-as-a-Service，平台即服务）已经是软件发展的必然趋势，因此，自然语言的平台化作为一个基础平台的服务已是必然趋势。

发明内容

本发明主要解决的技术问题是提供一种自然语言处理系统化服务平台，能够解决

现有自然语言处理存在的上述问题。

为解决上述技术问题，本发明采用的一个技术方案是 ：提供一种自然语言处理系统化服务平台，包括 ：

接入平台后台的稳定的流式处理系统、非稳定的机器集群系统和分布式多副本下载系统；

供用户访问的 C-API 接口、Python 接口和 http 服务端接口；

多语言服务框架，用于在本地客户端提供统一的接口，将远程访问和本地访问切换；

分布式远程调用服务器，用于逻辑服务并通过异步回调将结果返回给客户端；

所述流式处理系统采用消息队列的设计方式，所述消息队列分为队头和队尾两个组件，所述队头组件为数据的接受端，所述队尾组件为数据的发送端，算子从队尾组件中接收数据进行并行并消费，实现数据的传递。

在本发明一个较佳实施例中，所述平台还包括一个数据转存接口，用于将收集到的数据传输到其他应用程序进行再次处理，或是交给另一个程序作为输入。

在本发明一个较佳实施例中，所述其他应用程序包括 monoDB 或 reddies。

在本发明一个较佳实施例中，所述多语言服务框架通过开源框架 thrift 和protobuf 两个软件进行代码编辑，并在服务器端对多种语言统一处理。

在本发明一个较佳实施例中，所述流式处理系统包括消息队列的负载均衡和从消息队列消费消息的算子的负载均衡。

在本发明一个较佳实施例中，所述平台的通信方式为异步通信，发送消息的线程和消息处理的线程同时工作。

在本发明一个较佳实施例中，所述发送消息的线程和消息处理的线程的总数是core 线程数的 2 倍。

自然语言处理系统化服务平台将自然语言处理中的多个算法统一到算法平台上来，用户只需要方法名和待处理的数据，就可以方便的获取结果。针对目前流式系统都是静态固定路由，本发明的流式系统采用动态路由的方式，根据算子的 DAG 路由表动态地选择路由表信息。数据收集常用的单服务器架构，采用多服务器自动加入的方式来增强系统的负载能力，并消除单节点故障，让系统做到负载均衡。

本发明主要是提供各种自然语言处理的算法，可以直接在平台上使用，可以开发算子专注于算子本身的开发，不必关心算子的部署，而这些对于算子的使用方也是透明的，可以直接进行算子的使用。

本发明对大规模集群自然语言平台化的问题，如算子、算法的添加，集群在线和离线节点的应用进行研究并设计相应的解决方案，最终实现可扩展性强，可靠性高，部署灵活

的自然语言平台化的系统。该系统将用于公司内部的基础平台架构，对于 NLP 部门以及向所有需要用到自然语言处理算法的同学提供服务。其可定制化，高可扩展性和高可靠性的自然语言算法服务，作为集群或云计算平台管理和监控的一部分，将大大提高集群的可管理性。

本发明的有益效果是 ：本发明一种自然语言处理系统化服务平台，利用了计算机多核并行计算的优势，充分均衡的利用高性能计算机的计算资源，构架出高效高可靠性的自然语言平台，本发明对于特定情况下实现 HTTP 的接口，方便跨平台的调用，对于常用的接口数据 C++ 语言和 python 的接口，也直接提供方便在接口方面的调用，支持多平台的调

用，具有很好的工程应用价值。

附图说明

图 1 是本发明一种自然语言处理系统化服务平台的架构示意图；

图 2 是本发明一种自然语言处理系统化服务平台的整个系统示意图；

图 3 是本发明的稳定流式处理系统的设计流程图；

图 4 是所示日志收集体系的架构示意图。

具体实施方式

下面结合附图对本发明的较佳实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。

请参阅附图，本发明实施例包括：

本发明揭示了一种自然语言处理系统化服务平台，包括 ：接入平台后台的稳定的流式处理系统、非稳定的机器集群系统和分布式多副本下载系统；

供用户访问的 C-API 接口、Python 接口和 http 服务端接口；

多语言服务框架，用于在本地客户端提供统一的接口，将远程访问和本地访问切换；

分布式远程调用服务器，用于逻辑服务并通过异步回调将结果返回给客户端 ；

一个数据转存接口，用于将收集到的数据传输到其他应用程序，如 monoDB 或reddies进行再次处理，或是交给另一个程序作为输入。如图 1 和 2 所示，图 2 中，c++client：

c++ 客户端，其中 c++ 是一种静态数据类型检查的、支持多重编程范式的通用程序设计语言 ;python client ：python 客户端，其中，python 是一种面向对象、解释型计算机程序设计语言 ；other client ：其他语言的客户端（除了 c++ 和 python 之外的）；Communation Framefork ：通信框架，包括传输过程中得通讯协议，这里包括远程通讯和本地加载两部分；

Http Server ：超文本传输协议服务器，负责解析 client 请求成为 c++ 的请求后台的服务；

Local client ：加载本地服务的客户端 ；RPC（Remote Procedure CallProtocol）client：

远程过程调用协议客户端，负责远程通讯协议 ；Local arch ：本地计算架构，包括收到请求后服务的初始化、下载以及服务计算的工作 ；Qw （queue workers）arch ：消息队列、消费者的流逝计算架构 ；Online arch ：在线稳定实时处理消息的在线计算架构 ；Large scale arch：

大规模离线计算架构，专门针对于离线处理超大吞吐量。

所述稳定的流式处理系统，主要用于向稳定机器发送各种请求，获取稳定的自然语言处理的低延迟、高可用性的服务 ；该系统采用消息队列的设计方式，并通过消息队列负责接收和保存未被消费的消息。所述消息队列分为队头 linker 和队尾 subber 两个组件，其中，linker 为数据的接受端，subber 为数据的发送端，算子从队尾组件中接收数据进行并行并消费，实现数据的传递。由于每个算子可能会有多个实例分布式的情况，这样每一个实例算子都应该从对应某队尾用来取数据。如果这些算子都要从一个队列取数据，势必导致并行度和处理速度不够高，因此，为了提高处理速度，应分布式部署多个算子，即在设计队列的时候，将多个队尾打散，使每个算子从某一个队尾中取出数据。

Operator 就是算子开发者开发的在单机上跑的算子，实际上就是自然语言处理的算法，之所以会出现这样的流式系统，是存在某些算法，比如词性标注必须建立在分词之后的基础之上，然后才可以进行的一种算法，所以在计算的整体上是，首先进行分词处理，然后进行词性标注本身的处理，这两个整体的处理就是词性标注算法。

如图 3 是流式系统对整个软件的使用，本质上就是一种可扩展的网络模型。每个operator 就是一个具体的自然语言处理算子，比如分词和词性标注算子。每个算子都有部署的多个实例，每个算子的运行过程都是从上游的消息队列中取出数据，然后处理数据，检查数据是否结束，如果没有结束，将数据传输到对应算子的消息队列中，如果算子结束了，那么就将算子的运行结果直接返回给客户端。在图 3 中，各部件的中文名称及解释，Client: 客户端 ；Zookeeper: 简称 ZK，是 hadoop 的一个组件，是一个分布式的开源的分布式应用程序协调服 Drpc server ：分布式远程过程调用服务器 ；Queue1: 消息队列1，是分布式的；Worker1 ：消息队列 1 的消费者，也是分布式的 ；Queue2: 消息队列 2，是分布式的；Worker2 ：消息队列 2的消费者，也是分布式的。

在分布式处理的过程中，operator 其实是给算子开发者开发的动态链接库包装的一个壳，这个壳的操作很简单，在这里可以输出一些必要的统计信息，调用算子开发者开发的动态链接库。Operator 是从上游的消息队列中取出数据，并且插入到下游的消息队列中去，整个过程中，消息队列保证数据的可靠性，完整性和高效传输。

多个 operator 算子的实例，就是从不同的 subber 中接受数据进行并行同时消费数据，这样就可以实现数据的传递。数据的保存选用内存和磁盘两种模式的混合存储，由于消息队列是给 NLPC 使用的，对数据的实时性要求要高一些，所以存储形式以内存为主，只有在数据堆积以后才使用磁盘的持久化功能，如果超过一定时间数据仍未消费掉，那么支持过期删除的策略。整个请求如下，客户端将数据指定到某一个 linker，可以使用master进行系统调度，当数据进入 linker 根据可定制的 hash 规则，将一个 linker 的数据打散到多个子队列中去。考虑到下游有多个订阅组的情况，采用多路分发，将同一份数据分发到下游多个订阅组。每个订阅组内的数据根据第一次的 hash 值二次计算到指定的subber 中，

通过两次 hash 计算，一方面得到充分的打散，另一方面 operator 是多实例并发，对于多个operator 可以并行的从多个 subber 中获取数据，资源的竞争。

所述非稳定的机器集群系统，主要用于向后台的非稳定机器发送请求，并且获取极高吞吐量，但是对于单次的可用性不是特别高的服务 ；该系统充分利用现有机器，具体指利用现有机器本身的 cpu 和内存服务，但是当本身机器的计算服务请求增大的时候，为了保障机器原本服务的正常运作，机器会将现阶段的服务运作杀死，被杀死的服务会在其他负载相对较轻的服务上跑，这时候就需要保证数据故障恢复的策略。

所述分布式多副本下载系统，用于计算处理相对简单的服务系统，不是特别消耗资源的服务，可以同步到本地进行运算。

供用户访问的 C-API 接口、Python 接口和 http 服务端接口 ；对于前端 c++和python 的接口直接使用对应的语言实现，而 http Server，考虑的方案是使用 httpserver本地调用 C++ 的 client 的客户端直接作为代替的方案。后期可能会有后续的修改。部署http server 启用相同的端口后，使用 virtual IP 的服务奖多个 http server不同端口和 IP 绑定到一个虚拟 IP 上，并且这个 vip 会将请求通过 hash 均匀的分布在多台不同的http server 中去。

所述多语言服务框架，通过开源框架thrift和protobuf两个软件进行代码编辑，并在服务器端对多种语言统一处理，实现在客户端使用多种语言进行表述开发，用于在本地客户端提供统一的接口，将远程访问和本地访问切换 ；方便的通过延迟、吞吐量等一系列的要求，自动分配选择后台的调用方式。该多语言服务框架特有的客户端和接口，一方面可以正常的解决问题，另一方面，本身语言的客户端对于算法的使用更加灵活方便。

分布式远程调用服务器，首先是需要基于前面的服务多语言，服务框架，然后再后台通过前台的服务访问的参数的不同，通过既定的协议，动态的进行访问，同时这个服务器需要自动的进行负载均衡，使得客户端的尽可能轻量级，逻辑服务在这个分布式的远程调用服务器中，最后通过异步回调返回结果给客户端。

平台的信息统计和流量监控 ：涉及到信息统计，目前主要有两种方式进行日志收集，第一种是写一个通用的算子调用接口 CLI，对于算子的实现者而言，本身的 NLP 自然语言处理的算子只需要实现这个接口的动态链接库，在这个接口中完成统一的收集和统计的功能，使用中间件进行缓存，然后更新数据库 ；CLI 用于提供基本的数据搜索接口，管理员可以在服务器的终端上通过此接口来检索收集到的数据，启用或暂停集群中某个节点的数据收集任务。第二种是使用一种更为通用的日志收集方式，首先在每个代理的客户端配置一个代理的 agent，这个 agent 的主要功能是上传某些文件的增量，将上次读取的记录保存在内存里，然后定期扫描文件属性，发现变化的时候，从上次文件读取的地方继续向后读

取，由于日志都有自己的文件拆分策略，当发现日志突然变少的时候，重头读取文件，紧接着将日志上传到 server 中去，在 server 端对日志进行处理之后，实时将日志写入数据库。另外，CLI 接口用于提供基本的数据搜索，管理员可以在服务端的终端上通过此接口来检索收集到的数据，启用或暂停集群中某个节点的数据收集任务。日志收集系统的架构示意图如图 4 所示。对于算子以及流量的监控，采用两种方式监控，第一种是比较通用的方式，可以动态添加或者删除，对日志直接进行监控，分析处理之后进行上传 ；第二种是直接在包装的算子壳中配置，同时使用 redis 作为缓存数据持久化到 mysql 中。对于第一种监控方式，监控程序采用的是分布式的日志收集方式，首先在每个算子的机器上部署 rtlc 工具，目的是监控某些日志文件，对这些文件的增量实时上传到 scribe server中，server 的功能就是收集

定期的日志，然后通过自己的脚本存入到 mysql 当中，前端再从数据库中实时查询出来，展示报警和动态问题的追踪。同时通过观察计算机 cpu 的负载情况，动态的增加或者迁移算子。对于第二种方式，直接在包装的 operator 中进行统计，redis 每次对于算子的调用保存到临时变量中，每达到一定的数量就写入 redis，并且将临时变量同时置为0，然后定时将 redis 的数据持久化到 mysql 中。也可以采用两种方式混合使用的方法。

由平台化所带来系统 SLA 的达标 ：在 NLPC 这套平台完成的时候，由于自然语言处理的云平台自身是一套半在线的平台，需要有可用性延时的达标，所以必须有一套完整的实时信息统计的系统和信息的监控，从根本上来讲，在程序代码写的足够健壮、不存在任何内存泄露的情况下，必须对每个算子的成功失败方面的统计，还有流控方面的统计，这个一方面是对于异常的情况进行报警的处理，同时万一出现某些算子的计算大量失败，可以通过日志和结果及时对问题进行排查，另外一方面 Qos 也就是流量控制也是基于监控的，对于流量特别大的情况以某些负载过大的情况或者说防流量，可以直接把网卡打满，导致网络处于拥塞的情况。

平台的负载均衡 ：一般来说，对于分布式集群而言，通过监控自己机器的 CPU和内存的使用情况，在使用过载的时候向 ZK 传递信息通过某种算法进行迁移，对于负载均衡有几个方面的问题，首先从物理上来讲，是对多种计算分布在不同的计算机器上，但是从逻辑上来说，一个 queue+ worker 的流式系统的计算模型的负载均衡主要包括分布式消息队列的负载均衡和从消息队列消费消息的算子的负载均衡。

在通信过程中，在不能使用同步线程阻塞的方式进行通信的过程中，经常会有线程阻塞的情况，这样就需要开多个线程来维护 CPU 的正常运行，但是多个线程在进行调度的过程中，由于线程在 CPU 的切换也是非常消耗性能的，因此在运行的过程中最好使用异步通信的方式，也就是说，在通信的过程中，发送消息的线程和消息处理的线程是同步工作的，这样避免了线程的大量切换给带来的性能方面的损失。另外，同时最好合理的分配多个

线程的运行比例和总数，一般来说，发送消息的线程和消息处理的线程的总数是core 线程

数的 2 倍。

平台的故障恢复，传统的方式就是在两个节点传递的过程中保持多条路径，这种分组可以明显改善容错状况。在当前的 NLPC 自然语言的处理需要有自己的延时，但是实际上在计算的过程中，以消息队列为例，消息队列可以算是异步信息传输工具的一个中间件，在信息传输的过程中，如果某台机器或者消息队列的进程突然奔溃，后续的消息队列会把无用的故障机器从消息队列中删除，使用类似于一致性 hash 的方法把后续处理的数据均匀的打散到剩余的几台机器上，同时把故障机器添加到故障机器列表中，使用监控程序把故障的机器重新启动，然后添加到正常机器列表中，并且把持久化在磁盘的数据继续发送。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (7)

1.一种自然语言处理系统化服务平台，其特征在于，包括 ：

接入平台后台的稳定的流式处理系统、非稳定的机器集群系统和分布式多副本下载系统 ；

供用户访问的 C-API 接口、Python 接口和 http 服务端接口 ；

多语言服务框架，用于在本地客户端提供统一的接口，将远程访问和本地访问切换；

分布式远程调用服务器，用于逻辑服务并通过异步回调将结果返回给客户端 ；

所述流式处理系统采用消息队列的设计方式，所述消息队列分为队头和队尾两个组件，所述队头组件为数据的接受端，所述队尾组件为数据的发送端，算子从队尾组件中接收数据并对其进行并行消费，实现数据的传递。

2.根据权利要求 1 所述的一种自然语言处理系统化服务平台，其特征在于，所述平台还包括一个数据转存接口，用于将收集到的数据传输到其他应用程序进行再次处理，或是交给另一个程序作为输入。

3.根据权利要求 2 所述的一种自然语言处理系统化服务平台，其特征在于，所述其他应用程序包括 monoDB 或 reddies。

4.根据权利要求 1 所述的一种自然语言处理系统化服务平台，其特征在于，所述多语言服务框架通过开源框架 thrift 和 protobuf 两个软件进行代码编辑，并在所述分布式远程调用服务器端对多种语言统一处理。

5.根据权利要求 1 所述的一种自然语言处理系统化服务平台，其特征在于，所述流式处理系统的负载均衡包括消息队列的负载均衡和从消息队列消费消息的算子的负载均衡。

6.根据权利要求 1 所述的一种自然语言处理系统化服务平台，其特征在于，所述平台的通信方式为异步通信，发送消息的线程和消息处理的线程同时工作。

7.根据权利要求 6 所述的一种自然语言处理系统化服务平台，其特征在于，所述发送消息的线程和消息处理的线程的总数是 core 线程数的 2 倍。