达观数据对于大规模消息数据处理的系统架构

达观数据是为企业提供大数据处理、个性化推荐系统服务的知名公司,在应对海量数据处理时,积累了大量实战经验。其中达观数据在面对大量的数据交互和消息处理时,使用了称为DPIO的设计思路进行快速、稳定、可靠的消息数据传递机制,本文分享了达观数据在应对大规模消息数据处理时所开发的通讯中间件DPIO的设计思路和处理经验(达观数据架构师 桂洪冠)

一、数据通讯进程模型

q1在设计达观数据的消息数据处理机制时,首先充分借鉴了ZeroMQ和ProxyIO的设计思想。ZeroMQ提供了一种底层的网络通讯框架,提供了基本的RoundRobin负载均衡算法,性能优越,而ProxyIO是雅虎的网络通讯中间件,承载了雅虎内部大量计算节点间的实时消息处理。但是ZeroMQ没有实现基于节点健康状态的最快响应算法,并且ZeroMQ和ProxyIO对节点的状态管理,连接管理,负载均衡调度等也需要各应用自己来实现。

达观科技在借鉴两种设计思路的基础上,从进程模型、服务架构、线程模型、通讯协议、负载均衡、雪崩处理、连接管理、消息流程、状态监控等各方面进行了开拓,开发了DPIO(达观ProxyIO的简写,下文统称DPIO),确保系统高性能处理相关数据。

在DPIO的整个通讯框架体系中,采用集中管理、统一监控策略管理节点提供服务,节点间直接进行交互,并不依赖统一的管理节点(桂洪冠)。几种节点间通过http或者tcp协议进行消息传递、配置更新、状态跟踪等通讯行为。集群将不同应用的服务抽象成组的概念,相同应用的服务启动时加入的相同的组。每个通讯组有两种端点client和server。应用启动时通过配置决定自己是client端点还是server端点,在一个组内,每个应用只能有一个身份;不同组没要求。

  • 监控节点,顾名思义即提供系统监控服务的,用来给系统管理员查看集群中节点的服务状态及负载情况,系统对监控节点并无实时性及稳定性要求,在本模型中是单点系统。
  • 在上图的架构中把管理节点设计成双master结构,参考zookeeper集群管理思路,多个master通过一定算法分别服务于集群中一部分节点,相对于另外的服务节点则为备份管理节点,他们通过内部通讯同步数据,每个管理节点都有一个web服务为监控节点提供服务节点的状态数据。
  • 服务节点即是下文要谈的代理服务,根据服务对象不同分为应用端代理和服务端代理。集群中的服务节点根据提供服务的不同分为多个组,每个代理启动都需要注册到相应的组中,然后提供服务。

二、DPIO消息传递逻辑架构

DPIO服务节点内/间的通讯及消息传递模型见下图:q2

  • clientHost和serverHost间使用socketapi进行tcp通讯,相同主机内部的多个进程间使用共享内存传递消息内容,client和clientproxy、server和serverproxy之间通过domain socket进行事件通知;在socket连接的一方收到对端的事件通知后,从共享内存中获取消息内容。
  • clientproxy/serverproxy启动时绑定到host的一个端口响应应用api的连接,在连接到来时将该api对应的共享内存初始化,将偏移地址告诉给应用。clientproxy和serverproxy中分别维护了一个到应用api的连接句柄队列,并通过io复用技术监听这些连接上的读写事件。
  • serverproxy在启动时通过socket绑定到服务器的一个端口,并以server身份注册到一个group监听该端口的连接事件,当事件到达时回调注册的事件处理函数响应事件。
  • 在serverproxy内部通过不同的thread分别管理从本地应用建立的连接和从clientproxy建立的连接。thread的个数在启动proxy时由用户指定,默认是分别1个。每个clientproxy启动时会以client身份注册到一个group,并建立到同组的所有serverproxy的连接,clientproxy内部包含了连接的自管理能力及failover的处理(将在下面连接管理部分描述)。 DPIO实现了负载均衡,路由选择和透明代理的功能。

三、线程模型

DPIO的线程模型:

q3

App epoll thread检测从api来的请求信息,并将请求信息转发到待处理队列中。从已处理队列中获取应答包,并将处理结果转发给api

Io epoll thread检测从远端的proxy来的可写事件,并将请求包转发到远端的proxy。检测从远端的proxy的可读事件,并将应答包放在已处理队列中

Monitor thread检测DPIO的工作状态请求,将DPIO的工作状态返回。并将决定Io epoll thread和app epoll thread的负载均衡(桂洪冠)。

四、通信协议

q4

  1. Api与DPIO通信协议
  • 共享内存存储消息格式
字段 含义 长度
protocol len 协议包的总长度 4bytes
protocol head len 协议头的长度 1byte
Version_protocol_id 协议的版本号和协议号 1byte
Flag 消息标志,标志路由模式,是否记录来源地址,有二级路由,所以这个字段一定要Eg,末位表示要记录src,倒数第二位表示按roundrobin路由,倒数第3位表示按消息头路由,xxx 1byte
Proxy 来源/目的 proxy 2bytes
Api 来源/目的 api 2bytes
ApiTtl 协议包的发送时间 2Bytes
ClientTtl 消息存活的时间,后面添加,增加路由策略,选择app_server 2Bytes
ClientProcessTime 客户端处理所用时间 2Bytes
ServerTtl 消息存活的时间,后面添加,增加路由策略,选择app_client 2Bytes
timeout 协议包的超时时间 2 byte
Sid 消息序列号 4bytes
protocol body len Body长度 4bytes
protocol body 消息体 Size
  • 请求协议包
字段 含义 长度
protocol head len 协议头的长度 1byte
Version_protocol_id 协议的版本号和协议号 1byte
Flag 消息标志,标志路由模式,是否记录来源地址,有二级路由,所以这个字段一定要Eg,末位表示要记录src,倒数第二位表示按roundrobin路由,倒数第3位表示按消息头路由,xxx 1byte
ApiTtl 协议包的发送时间 2bytes
Timeout 协议包的超时时间 2bytes
Api 来源/目的 api 2bytes
Sid 消息序列号 4byte
Begin_offset 协议包的起始偏移 4bytes
len 协议包长度 4bytes
  • 响应协议包
字段 含义 长度
protocol head len 协议头的长度 1byte
Version_protocol_id 协议的版本号和协议号 1byte
Flag 消息标志,标志路由模式,是否记录来源地址,有二级路由,所以这个字段一定要Eg,末位表示要记录src,倒数第二位表示按roundrobin路由,倒数第3位表示按消息头路由,xxx 1byte
Result 处理结果 1byte
sid 消息序列号 4bytes
begin_offset 协议包的起始偏移 4bytes
len 协议包长度 4bytes

 

  1. Proxy与监控中心的监控信息
  • 请求协议包
字段 含义 长度
protocol len 协议包的总长度 4bytes
protocol head len 协议头的长度 4bytes
Version 协议的版本号 4bytes
protocol id 协议的协议号 4bytess
status_version 当前状态版本 4bytes
Proxy_identify_len 该proxy标识长度 4bytess
Proxy_identify 该proxy 标识 4bytes
protocol body 消息体 Size
  • 应答包
字段 含义 长度
protocol len 协议包的总长度 4bytes
protocol head len 协议头的长度 4bytes
Version 协议的版本号 4bytes
protocol id 协议的协议号 4bytess
protocol body len Body长度 4bytes
protocol body 消息体 Size

五、负载均衡

q5

DPIO的负载均衡基于最快响应法

DPIO将所有的统计信息更新到监控中心,监控中心通过处理所有的节点的状态信息,统一负责负载均衡。

DPIO从监控中心获取所有连接的负载均衡策略。每个连接知道只需知道自己的处理能力。

以上图为例,有三个proxy server处理程序。处理能力分别为50、30、20,一次epoll过程能够同时探测多个连接的可写事件。

假设:三个proxy server的属于同一epoll thread,且三个proxy server假设都处理能力无限大。

限制:如果刚开始时待处理队列的数据包个数为100个,多次发送轮回后proxy server A≥proxy server B≥proxy server C, 每个发送的最多发送协议包数为待处理队列协议包个数 * 该连接所占权重

六、雪崩处理

大型在线服务,特别是对于时延敏感的服务,当系统外部请求超过系统服务能力,而没有适当的过载保护措施时,当系统累计的超时请求达到一定规模,将可能导致系统缓冲区队列溢出,后端服务资源耗尽,最终像雪崩一样形成恶性循环。这时系统处理的每个请求都因为超时而无效,系统对外呈现的服务能力为0,且这种情况下不能自动恢复。

我们的解决策略是对协议包进行生命周期管理,现在协议包进出待处理队列和已处理队列时进行超时检测和超时处理(超时则丢弃)。

proxy client:

当app epoll thread将协议包放入待处理队列时,会将该协议包的发送时间、该协议包的超时时间,当前时间戳来判断该协议包是否已经超时。

当app epoll thread将协议包从已处理队列中移除时,会将该协议包的发送时间、该协议包的超时时间,已经当前时间戳来判断该协议包是否已经超时。

当Io epoll thread将协议包从待处理队列中移除时,会将该协议包的发送时间、该协议包的超时时间,当前时间戳,该连接的协议包的平均处理时间移除。

当io epoll thread将协议包放入已处理队列时,会将将该协议包的发送时间、该协议包的超时时间,已经当前时间戳来判断该协议包是否已经超时。

proxy server:

当App epoll thread将协议包从待处理队列中移除时,会将该协议包在客户端的处理时间、该协议包的超时时间、该协议包的proxy server接收时间戳、当前时间戳来判断该协议包是否已超时。

当app epoll thread将协议包放入已处理队列时,会将该协议包的发送时间、该协议包的超时时间,已经当前时间戳来判断该协议包是否已经超时。

当io epoll thread将协议包从已处理队列中移除时,会将该协议包的发送时间、该协议包的超时时间,已经当前时间戳来判断该协议包是否已经超时。

当io epoll thread将协议包放入待处理队列时,会将该协议包的发送时间、该协议包的超时时间来判断该协议包是否已超时。

七、连接管理

红黑树:

q6

红黑树:保存所有连接的最近的读/写时间戳。

当epoll_wait时,首先从红黑树中获取oldest的时间戳,并将当前时间戳与oldest时间戳的时间差作为epoll_wait的超时时间,当连接中有可读/写事件发送时,首先从红黑树中删除该节点,当可读/写事件处理完毕后,再将节点插入到红黑树中,当处理完所有连接的可读/写事件时,再从红黑树中依次从移除时间戳小于当前时间戳的连接,并触发该连接的timeout事件。

八、消息处理流程

q7

  1. apiclient通过调用api的接口,将消息传给
  2. api接受消息体,从共享内存中申请内存,填写消息头size(协议总长度)、Offset (协议版本号和协议号)、Headsize (协议头的总长度)、flag(路由策略),ApiTtl (协议包的发送时间)、timeout (协议包的超时时间)、sid(序列号),size(消息体长度)字段,封装成协议包,将协议包写入共享内存。
  3. api通过socket发送请求给proxy。
  4. app epoll thread通过检测api的可读事件,接受请求。通过解析请求内容,获取请求协议包所在的共享内存的偏移、请求协议包的长度和api连接index加入到处理队列。
  5. proxy client的io epoll thread通过检测对端DPIO连接的可写事件,从发送队列中获取请求包,将api的index加入到协议包的api index字段。
  6. proxy client的io epoll thread从共享内存中读取协议包,释放由请求包中所标识的内存空间。
  7. proxy server的io epoll thread通过检测对端DPIO的可读事件,接受请求。
  8. proxy server的io epoll thread从共享内存中申请空间,将proxy的index加入到协议包的proxy index字段。将请求内存写入到申请的空间中。
  9. proxy server的io epoll thread 将协议包在共享内存的偏移和协议包的长度加入的待处理队列中。
  10. app epoll thread从待处理队列中获取请求包,将协议包转发给相应的api进行处理。
  11. api通过检测DPIO的可读事件,解析请求内容。
  12. api通过解析请求内容,获取请求协议包在共享内存中的偏移和请求协议包的长度。从共享内存中读取请求内容,并释放相应空间。
  13. api将请求协议包返回给应用层进行处理。
  14. 应用层将应答包传给api。
  15. Api从共享内存中申请空间,将应答包写入到共享内存中。
  16. Api将应答包在共享内存中的偏移和应答包的大小写入到共享内存中。
  17. App epoll thread通过检测可读事件,将应答包写入到已处理队列中。
  18. proxy server的Io epoll thread通过检测对端的DPIO的可写事件,将已处理队列中获取应答包。
  19. proxy server的Io epoll thread从共享内存中读取应答包。
  20. Proxy client的Io epoll thread检测可读事件,读取应答包。
  21. Proxy client的Io epoll thread通过解析应答包,从共享内存中申请空间,将应答包写入到申请的内存中。
  22. Proxy client的Io epoll thread将应答包移入到已处理队列。
  23. App epoll thread通过检测api的可写事件,将已处理队列中获取应答包。
  24. App epoll thread发送应答包。
  25. Api通过检测可读事件,获取应答包,通过解析应到包,获取应答包在共享内存中的偏移和应到的大小,从共享内存中读取应到包。
  26. Api将应答包返回给应用端。(桂洪冠 陈运文)。

九、状态监控

q8

连接池中存在:当前可用连接个数

连接池中再分别获取每个连接的状态

每个可用连接分别维护以下信息:

连接处理的数据包个数、连接send失败次数、连接协议包的平均处理时间。

连接的连接状态(当重连失败达到一定次数时,定义为连接失败)。

连接的重连次数、连接的超时次数。

当监控线程accept到client的连接时,解析请求内容,然后调用连接池对象的statistics方法,连接池对象首先写入自己的统计信息,然后分别调用每个连接的statistics方法,每个连接分别填写自己的统计信息

本文小结

大规模消息传递会遇到很多可靠性、稳定性的问题,DPIO是达观在处理大数据通讯时的一些经验,和感兴趣的朋友们分享,期待与大家不断交流与合作

发表在 数据挖掘 | 标签为 , | 留下评论

在微信公众号里使用LaTeX数学公式

因为有同学在微信后台咨询这个问题,所以这里简单记录一下,其实自己之前也摸索了一些方法,不是太完美,目前所使用的这个方法算是折中后比较好的。

这段时间在鼓捣“NLPJob”这个公众号,特别是微信公众号支持“原创声明”后,就很乐意将52nlp上积攒的一些文章搬上去,但是逐渐会遇到一些数学公式的问题。目前在52nlp上用的是mathjax完美支持LaTeX数学公式展现,但是微信公众号的编辑器没有这个支持,另外mathjax支持的公式形式不是图片形式,所以不能直接将文章拷贝上去,但是如果是数学公式图片,微信编辑器可以直接拷贝,所以最直接的想法就是将mathjax支持的LaTeX公式转换为公式图片保存在文章中,然后再全文拷贝到微信公众号编辑器中。

其实在mathjax之前,网页上的很多数学公式都是用这种折中的方式,包括很多wordpress数学公式插件,当年我也因为52nlp上的公式问题还自己动手写了一个小的wordpress插件,但是当mathjax出现之后,之前的方案就显得很一般了。所以就开始尝试找一下支持img缓存的LaTeX公式插件,不过多数都不满意或者有瑕疵,甚至自己又开始动手修改代码,然后blablabla….,最终发现 quicklatex这个神器和它的wordpress插件QuickLaTeX,几乎完美支持和兼容Mathjax所支持的LaTeX数学公式。方法很简单,只要在wordpress中安装quicklatex,然后在文章的开头添加一个:[latexpage] ,然后文章中所有的latext公式都会转换为图片形式,类似昨天发出的rickjin的这篇文章:LDA数学八卦:神奇的Gamma函数(1)。当然需要先在wordpress中完成编辑转换,再全文拷贝到微信公众号中,微信会自动的将这些图片上传到它自己的图片服务器上。不过依然希望微信公众号编辑器能早日支持LaTeX公式编辑甚至Mathjax。

发表在 随笔 | 标签为 , , , , , , , , | 留下评论

斯坦福大学深度学习与自然语言处理第四讲:词窗口分类和神经网络

斯坦福大学在三月份开设了一门“深度学习与自然语言处理”的课程:CS224d: Deep Learning for Natural Language Processing,授课老师是青年才俊 Richard Socher,以下为相关的课程笔记。

第四讲:词窗口分类和神经网络(Word Window Classification and Neural Networks)

推荐阅读材料:

  1. [UFLDL tutorial]
  2. [Learning Representations by Backpropogating Errors]
  3. 第四讲Slides [slides]
  4. 第四讲视频 [video]

以下是第四讲的相关笔记,主要参考自课程的slides,视频和其他相关资料。
继续阅读

发表在 机器学习, 深度学习, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 一条评论

出门问问宣布完成由Google投资的C轮融资,累计融资7500万美金

注:出门问问是我们的老朋友,创始人李志飞也是NLP和机器翻译领域的大牛,今天出门问问拿到了Google的C轮融资,志飞兄第一时间和我分享了这条新闻,太牛了。

人工智能创业公司出门问问(Mobvoi),于近日完成了由Google投资的C轮融资,累计融资7500万美金。现有投资方包括红杉资本、真格基金,SIG海纳亚洲、圆美光电、及歌尔声学。此轮投资Google并不控股,出门问问团队依旧有绝对控制权。

此次由Google投资的C轮融资,能够保证出门问问在人工智能领域长期持续深耕,专注核心技术上的进一步研发,在可穿戴、车载以及机器人领域拓展新的人机交互产品形态,更深入地完善用户体验,在吸引全球顶尖技术与商务人才上更具优势。对于海外市场的扩展,此次融资也将发挥非常重要的作用。

Google 企业发展部副总裁Don Harrison 说到选择投资出门问问的原因:“出门问问研发了非常独特自成体系的语音识别与自然语言处理技术。我们被他们的创新科技与发展潜力打动,所以我们很迅速地决定用投资的方式帮助他们在未来快速成长。”

红杉资本全球执行合伙人沈南鹏评价:“出门问问一直处于高速的不断创新过程中,从移动app到硬件产品到语音搜索平台,不同形式的产品背后是团队长期以来形成的强大技术核心,获得Google的投资是对这种中国原创能力的最好肯定。我很高兴Google这样的巨头看好出门问问,并和我们一起投入到这支高速创新的团队中。”

真格基金创始人徐小平说:“我第一次遇见谷歌科学家李志飞博士,是三年前。那时候,他的语音搜索创业计划,真是一个“异想天开”的梦。志飞相信自己的梦,相信自己的技术,相信市场对这个技术产品的需求,历经万难,终于“搜索”到了属于他自己的那片天空。志飞的创业历程,是又一个中国好故事,会激励更多人追求并实现自己的好梦。”

志同道合是此次融资达成的最重要的原因。扎实做技术和产品,运用科技的力量改变人们的日常生活,是出门问问一直笃信的价值观。

出门问问CEO 李志飞表示:“引入Google的投资,不仅意味Google对于我们技术的认可,更是源于双方持有共同的价值观,通过对人工智能技术的极致追求,打造毫不妥协的用户体验。”

与Google相似,出门问问也是信仰“工程师文化”的团队,强大的研发团队由Google前科学家、人工智能专家领衔,团队成员来自哈佛、MIT、斯坦福、剑桥、清华等名校名企。

此次融资是中国人工智能创业公司首次获得像Google这样的国际技术巨头的投资与认可。这在某种程度上说明,在人工智能领域,中国的创业公司不容小觑。
继续阅读

发表在 自然语言处理 | 留下评论

用MeCab打造一套实用的中文分词系统(四):MeCab增量更新

最近在处理NLPJob的一些数据,发现之前训练的Mecab中文分词工具包还有一些问题,所以想到了为NLPJob定制一个MeCab中文分词器,最简单的方法就是整理一批相关的词条,可以通过词条追加的方法加到原有的Mecab中文分词词典中去,这个可以参考《日文分词器Mecab文档》中介绍的“词条追加”方法,既可以放到系统词典中,也可以放到用户词典中,很方便。不过这个还不是最佳方案,之前有用户在《用MeCab打造一套实用的中文分词系统》中留言:

你好, 我在win7上训练的时候mecab-cost-train的时候会崩溃,请问下我能每次只训练一小部分,然后最后一起发布嘛?

google了一下,发现MeCab的作者Taku Kudo在google plus上给了一个增量更新的方案:

https://plus.google.com/107334123935896432800/posts/3g83gkBoSYE

当然这篇文章是用日文写得,不过如果熟悉Mecab的相关脚本,很容易看懂。增量更新除了可以解决在小内存机器上分批训练模型外,也可以很容易在一个已有的基准分词模型上定制特定领域的分词器,既更新词典,也更新模型,这才是我理想中NLPJob中文分词器的定制之路。
继续阅读

发表在 中文信息处理, 中文分词, 文本处理演示系统, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , , , , , , | 7 条评论

斯坦福大学深度学习与自然语言处理第三讲:高级的词向量表示

斯坦福大学在三月份开设了一门“深度学习与自然语言处理”的课程:CS224d: Deep Learning for Natural Language Processing,授课老师是青年才俊 Richard Socher,以下为相关的课程笔记。

第三讲:高级的词向量表示(Advanced word vector representations: language models, softmax, single layer networks)

推荐阅读材料:

  1. Paper1:[GloVe: Global Vectors for Word Representation]
  2. Paper2:[Improving Word Representations via Global Context and Multiple Word Prototypes]
  3. Notes:[Lecture Notes 2]
  4. 第三讲Slides [slides]
  5. 第三讲视频 [video]

以下是第三讲的相关笔记,主要参考自课程的slides,视频和其他相关资料。
继续阅读

发表在 机器学习, 深度学习, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 5 条评论

斯坦福大学深度学习与自然语言处理第二讲:词向量

斯坦福大学在三月份开设了一门“深度学习与自然语言处理”的课程:CS224d: Deep Learning for Natural Language Processing,授课老师是青年才俊 Richard Socher,以下为相关的课程笔记。

第二讲:简单的词向量表示:word2vec, Glove(Simple Word Vector representations: word2vec, GloVe)

推荐阅读材料:

  1. Paper1:[Distributed Representations of Words and Phrases and their Compositionality]]
  2. Paper2:[Efficient Estimation of Word Representations in Vector Space]
  3. 第二讲Slides [slides]
  4. 第二讲视频 [video]

以下是第二讲的相关笔记,主要参考自课程的slides,视频和其他相关资料。
继续阅读

发表在 机器学习, 深度学习, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 9 条评论

斯坦福大学深度学习与自然语言处理第一讲:引言

斯坦福大学在三月份开设了一门“深度学习与自然语言处理”的课程:CS224d: Deep Learning for Natural Language Processing,授课老师是青年才俊 Richard Socher,他本人是德国人,大学期间涉足自然语言处理,在德国读研时又专攻计算机视觉,之后在斯坦福大学攻读博士学位,拜师NLP领域的巨牛 Chris ManningDeep Learning 领域的巨牛 Andrew Ng,其博士论文是《Recursive Deep Learning for Natural Language Processing and Computer Vision》,也算是多年求学生涯的完美一击。毕业后以联合创始人及CTO的身份创办了MetaMind,作为AI领域的新星创业公司,MetaMind创办之初就拿了800万美元的风投,值得关注。

回到这们课程CS224d,其实可以翻译为“面向自然语言处理的深度学习(Deep Learning for Natural Language Processing)”,这门课程是面向斯坦福学生的校内课程,不过课程的相关材料都放到了网上,包括课程视频,课件,相关知识,预备知识,作业等等,相当齐备。课程大纲相当有章法和深度,从基础讲起,再讲到深度学习在NLP领域的具体应用,包括命名实体识别,机器翻译,句法分析器,情感分析等。Richard Socher此前在ACL 2012和NAACL 2013 做过一个Tutorial,Deep Learning for NLP (without Magic),感兴趣的同学可以先参考一下: Deep Learning for NLP (without Magic) – ACL 2012 Tutorial – 相关视频及课件 。另外,由于这门课程的视频放在Youtube上,@爱可可-爱生活 老师维护了一个网盘链接:http://pan.baidu.com/s/1pJyrXaF ,同步更新相关资料,可以关注。
继续阅读

发表在 机器学习, 深度学习, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 8 条评论

用MeCab打造一套实用的中文分词系统(三):MeCab-Chinese

我在Github上发布了一个MeCab中文分词项目: MeCab-Chinese , 目的是提供一个用于中文分词和词性标注的MeCab词典和模型数据,类似MeCab日文IPA词典(mecab-ipadic),并且提供一些我自己用到的特征模板和脚本,方便大家从源头开始训练一个MeCab中文分词系统。

自从上次在愚人节的时候发布了一个mecab中文词典和数据模型之后(《用MeCab打造一套实用的中文分词系统(二)》), 收到了一些反馈,而这些反馈又促使我深入的review了一下mecab,重新设计特征及特征模板,加入了一些新的词典数据,重新训练模型,感兴趣的同学可以先试试这个0.2版本: mecab-chinesedic-binary (链接: http://pan.baidu.com/s/1gdxnvFX 密码: kq9g)
注:目前所有发布的版本均默认utf-8编码,并且在Mac OS和Linux Ubuntu下测试有效,windows没有测试,感兴趣的同学可自行测试)

了解和安装mecab仍请参考:
日文分词器 Mecab 文档
用MeCab打造一套实用的中文分词系统

这里再补充一点,由于google code废弃的缘故,MeCab这个项目已经搬迁至github,但是一些资源反而不如之前那么好找了,可参考两个MeCab作者维护的页面:
MeCab日文文档: http://taku910.github.io/mecab/
MeCab github 页面:https://github.com/taku910/mecab

MeCab目前最新的版本是2013-02-18更新的MeCab 0.996,我在Mac OS和Linux Ubuntu下用的是这个版本,在MeCab-Chinese下,做了一个备份,感兴趣的同学可以从这里下载: MeCab 0.996
继续阅读

发表在 中文信息处理, 中文分词, 文本处理演示系统, 标注, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , , , | 6 条评论

用MeCab打造一套实用的中文分词系统(二)

虽然是愚人节,但是这个不是愚人节玩笑,最近花了一些时间在MeCab身上,越发喜欢这个来自岛国的开源分词系统,今天花了一些时间训练了一个更适用的模型和词典,打包提供给大家使用,因为数据和词典涉及到一些版权问题,所以打包文件里只是mecab用于发布的二进制词典和模型文件,目前在mac os和linux ubuntu系统下测试无误,其他系统请自行测试使用:

链接: http://pan.baidu.com/s/1sjBfdXr 密码: 8udf

了解和安装mecab请参考:
日文分词器 Mecab 文档
用MeCab打造一套实用的中文分词系统

使用前请按上述文档安装mecab,下载这个中文分词模型和词典之后解压,解压后得到一个mecab-chinese-data目录,执行:

mecab -d mecab-chinese-data
扬帆远东做与中国合作的先行
扬帆 v,*,*,*,*,*,扬帆,*,*
远东 ns,*,*,*,*,*,远东,*,*
做 v,*,*,*,*,*,做,*,*
与 p,*,*,*,*,*,与,*,*
中国 ns,*,*,*,*,*,中国,*,*
合作 v,*,*,*,*,*,合作,*,*
的 u,*,*,*,*,*,的,*,*
先行 vn,*,*,*,*,*,先行,*,*
EOS

上述第二列提供了词性标注结果。

如果想得到单行的分词结果,可以这样执行:

mecab -d ./mecab-chinese-data/ -O wakati
扬帆远东做与中国合作的先行
扬帆 远东 做 与 中国 合作 的 先行

如果想直接对文件分词,可以这样执行:

mecab -d ./mecab-chinese-data/ INPUT -o OUTPUT

具体可以参考上述两个文档,另外我在mac下测试了一下中文维基百科语料的切分速度,大概700多M的语料,不到90秒切分完毕,大概7M/s的切分速度完全达到了工业届的使用标准。另外Mecab还支持Nbest输出,多种输出格式,全切分模式,系统词典和用户词典定制等等,同时通过SWIG提供了perl, ruby, python, java的调用接口,非常方便。

以下是在backoff2005 人民日报语料库上的测试结果:

=== SUMMARY:
=== TOTAL INSERTIONS: 3803
=== TOTAL DELETIONS: 1981
=== TOTAL SUBSTITUTIONS: 5004
=== TOTAL NCHANGE: 10788
=== TOTAL TRUE WORD COUNT: 104372
=== TOTAL TEST WORD COUNT: 106194
=== TOTAL TRUE WORDS RECALL: 0.933
=== TOTAL TEST WORDS PRECISION: 0.917
=== F MEASURE: 0.925
=== OOV Rate: 0.058
=== OOV Recall Rate: 0.482
=== IV Recall Rate: 0.961
### pku_test.result 3803 1981 5004 10788 104372 106194 0.933 0.917 0.925 0.058 0.482 0.961

召回率93.3%,准确率91.7%, F值为92.5%, 虽然还没有一个单纯针对这个测试语料比赛的分词结果好,但是测试了一些其他语料后觉得这个版本完全可以作为一个基准版本使用,另外mecab也提供了用户定制词典接口,方便用户按自己的需求定制使用。

最后提供一个demo仅供测试使用: 中文分词Demo

注:原创文章,转载请注明出处“我爱自然语言处理”:www.52nlp.cn

本文链接地址:http://www.52nlp.cn/用mecab打造一套实用的中文分词系统二

发表在 中文信息处理, 中文分词, 文本处理演示系统, 自然语言处理 | 标签为 , , , , , , , , , , , , , , , , , , , | 20 条评论