Search on Tech Explorer

倒排索引求交算法相关资料调研

Sun, 14 Jun 2020 00:00:00 +0000

1. IR-book 经典教材中的思路
#

Faster postings list intersection via skip pointers 通过跳指针，实现更快的 posting list 求交 https://nlp.stanford.edu/IR-book/html/htmledition/faster-postings-list-intersection-via-skip-pointers-1.html

首先有个最 trival 的算法，两个 posting list，各一个指针，谁不匹配，就把谁右移一个，

跳表方法，思路类似 skip list，是要在建索引的时候，额外构建 skip list，这样就不是右移一个，而是按照跳表来右移。

2. lemire 教授的 SIMDCompressionAndIntersection 库中有多种算法
#

https://github.com/lemire/SIMDCompressionAndIntersection/blob/master/src/intersection.cpp

可以看到实现了这些求交算法，并且还有个 benchmark 程序 benchintersection 可以做对比

“simd”
“galloping”
“scalar”
“v1”
“v3”
“simdgalloping”
“simd_avx2”
“v1_avx2”
“v3_avx2”
“simdgalloping_avx2”
“highlyscalable_intersect_SIMD”
“lemire_highlyscalable_intersect_SIMD”

其中根据输入数据的规模，会选用不同的算法，并且还有 avx2 指令集的优化算法。

其中提到的 sse 优化的 fast-intersection-sorted-lists-sse https://highlyscalable.wordpress.com/2012/06/05/fast-intersection-sorted-lists-sse/

3. “The magic of Algorithms! " 中的算法
#

Chap. 6, Algorithm 6.1 Intersection based on Mutual Partitioning

http://didawiki.di.unipi.it/doku.php/magistraleinformaticanetworking/ae/ae2019/start#books_notes_etc

pdf 是 https://www.dropbox.com/s/dqttqigvuf4ydkd/main.pdf?dl=0

思路很简单，就是嵌套的 binary search，实测效果不错，而且实现简单，可以直接递归实现。

我实测效果还不错，提了个 issue https://github.com/lemire/SIMDCompressionAndIntersection/pull/29

4. List Intersection for Web Search: Algorithms, Cost Models, and Optimizations
#

http://www.vldb.org/pvldb/vol12/p1-kim.pdf 微软的文章，搞了个 cost model，来评估各种 list 求交集算法的性能，但是不开源。

本文提出一种基于代价的模型，来估算各种算法组合的代价，并使用代价模型来搜索代价最低的算法，得到的计划通常是 2-way 算法的一个组合，并且比传统的 2-way 和 k-way 算法性能都好。

并列举了常见的 List Intersection 算法： 2-way:

2-Gallop
2-Merge
2-SIMD

k-way:

k-Gallop
k-Merge

2-way vs. k-way 本文断言，对 k-list 求交，通过 k-1 次重复 2-way 求交算法，比通过单次 k-way 求交算法，更快。

结论，通过本文 cost model optimizer 规划出来的 2-way 求交计算，通常比 k-way 求交更快。

https://arxiv.org/pdf/1401.6399.pdf

We demonstrated that combining unpacking and differential coding resulted in faster decompression speeds, which were approximately 30 % better than the best speeds reported previously [3]. To match the performance of these fast compression schemes, we additionally vectorized and optimized the intersection of posting lists. To this end, we introduced a family of algorithms exploiting commonly available SIMD instructions (V1, V3 and SIMD GALLOPING). They are often twice as fast as the best non-SIMD algorithms. Then, we used our fast SIMD routines for decompression and posting

Efficient set intersection for inverted indexing

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.415.2636&rep=rep1&type=pdf

Intersection in integer inverted indices https://pdfs.semanticscholar.org/db30/9935b512ef4d0c8941c96e987ad70400ebde.pdf

lookup 算法最快，非常简单，两层存储，按位分成两层。首层直接定位，二层直接遍历。二层可以压缩。

基于 ElasticSearch 开发垂直搜索系统

Sun, 29 Mar 2020 00:00:00 +0000

一，背景介绍
#

ElasticSearch 是由 Lucene 包装上分布式复制一致性算法等附加功能，构成的开源搜索引擎系统。

近两年在业界热度大增，主要有 3 种应用场景：

全文搜索引擎
NOSQL 数据库
日志分析数据库 ELK

很多垂直领域搜索需求，都可以基于 ElasticSearch 来设计架构。

ElasticSearch 能大幅度提升相关业务的迭代开发速度，实现类似 sql 数据库增删改查一样的快速开发。并在相对高 qps 的在线业务中，保证毫秒级的延迟，提供极高的可用性和稳定性。

经过持续的研读官方文档，调研业界经验，并在实践中应用反思后，总结出一套架构方案。供参考，欢迎意见建议。

二，架构方案
#

一个 ElasticSearch 集群 cluster ，配套：

转发代理 proxy
队列

1. 转发代理 proxy
#

proxy 的功能是：

协议转换，做 rpc 协议如 protobuf 和 ElasticSearch REST json 之间的协议转换，对文档更新等请求，定义了 rpc 协议，便于队列做各种处理。
引入 RPC 框架成熟的负载均衡，容灾，故障屏蔽等功能，到对 ES 的 RPC 中，比如如果单机 ES 进程挂了，通过返回码让调用方自动换机器重试。
统一监控告警系统，监控各种请求失败，延迟分布等，并监控 ElasticSearch java 进程状态，集群状态
转发文档更新请求给本机的队列。用队列做削峰填谷，自动合并批量，做限流。
提供双写能力，便于索引升级切换
proxy 到本机 ES 做了 http 连接池，避免频繁的 HTTP tcp 建连接。

2. 队列
#

队列实现了出队限流，请求合并，削峰填谷 3个功能。

在实际业务中，常常会定期做文档全量更新，会出现短时间内写请求高峰，

如果直接写 ES，请求高峰时，经常出现 ES write 线程池占满，导致部分写请求失败。

另外部分业务每次请求只更新1个文档，导致 ES cpu 高，影响 ES 的写性能，不符合官方推荐做法。

为此，引入队列:

配置限制了出队的 QPS ，确保集中高峰被抹平，以匀速稳定地写入 ES，彻底消除了更新失败。
并用配置自动把多个请求合并成批量（比如 5000个文档一个批量），优化了 ES 的写入性能。
请求高峰中超出配置 QPS 的请求，队列自动暂存在文件中，随后处理，保证了 ES 服务平稳。

3. 其他工具
#

另外，繁荣的 ES 开源生态中，周边工具非常丰富便捷，我们常用的两种周边工具：kinana 和 bin/elasticsearch-sql-cli，极其方便快捷，大幅度提升了开发效率。

三，搜索应用开发优化指南
#

垂直搜索系统的在线检索部分，一般流程如下

ES 用来实现召回和粗排环节，和部分自动补全环节。

基于 ES 开发的优点：

ES/Lucene 的 Query DSL 极其强大全面灵活，业务逻辑代码大幅度简化，开发简单便捷，业务迭代开发速度大大提高。
有商业公司维护的高质量官方文档，网上也有海量资料，新人几天就可以上手，快速形成生产力，提升团队效率。
成熟稳定，就目前经验看没有遇到过 bug
业务如果扩展，后续伸缩性，扩展性，分 shard ，多副本等，都有比较成熟方案。

1. query DSL 语法
#

基于 ES 的开发，首先需要学习常见的几种 query，

ES 的 query 简单分成 4 类:

term query，对单个词的 query，包括 term/terms/range/exists/missing/ids/regexp 等
full text query ，全文检索query，对多个词（即句子）的query，包括 match/multi_match/common 等
compound query 复合 query，包括 bool/dis_max/function_score 等
match_all ，简单匹配所有文档

建议先学习 term/match/range/bool ，就可以实现大部分业务逻辑。

网上资料较多，就不转述了。

可以先看看这些中文资料，在 test 环境的 kibana 做做实验，快速上手：

https://www.elastic.co/guide/cn/elasticsearch/guide/current/search-in-depth.html

https://my.oschina.net/yumg/blog/637409

https://www.cnblogs.com/yjf512/p/4897294.html

当然最好的还是官方英文文档：

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html

2. 分词
#

中文搜索的一个核心议题，就是分词。

ElasticSearch 常用的中文分词是 ik analyzer。ik 是开箱即用，便于小型业务快速开发的。

但是作为对分词可定制性要求较高的业务，我们实际测试，发现 ik analyzer :

不支持本地自定义词典文件的热加载；
无法针对不同 index 配置不同自定义词典；
另外对一些分词的 bad case ，比如没有正确切分的词，没法简单 fix。

因此推荐不用 ik ，而是在更新文档和搜索的时候，在外部做分词，然后用空格拼起来，传给 ES 做索引/搜索。这种方案中，在 ES mapping 中配置成 whitespace 分词器。

外部分词可以用 cppjieba 等，索引分词还可以合并多种分词算法结果提高召回率。

对 cppjieba ，我之前做过内存优化，将内存优化到了 1/100。

另外，索引之前，也有必要做 UTF8 的 normalize，全角转半角，英文大小写统一，和英文的词干提取， mapping 中常用

"cjk_width", "lowercase", "porter_stem"

这些filter

具体可以参考已有业务代码。

3.关系型搜索
#

实际开发遇到典型的 one-many 关系型数据上的 query，

比如在某业务中，就遇到这种逻辑，经过调研发现常见有 4 种方案：

分开2 个 index : one + many ，分开2次串行 search，问题: 需要2次延迟大
反范式，完全展开，one 的数据追加到每一个 many 文档中，问题：数据量变大，更新 one 需要用 _update_by_query 如果 one 数据更新频繁，可能导致大量写操作
nested ，比如 one 嵌套 many 子文档问题是：nested 嵌套文档更新需要更新整个 root 文档，即要把整个 one 文档和含有的 many 文档 select 出来，修改，再写回。对热门 one 文档，更新会操作大量数据，并发写还可能 data race。
join, has_parent, has_child 把 one 和 many 的所有字段合并到一个 index 中， one 和 many 分别独立更新。

经过实际数据测试 join field 方案，发现当 one:many = 1:1000万时，延迟在 5ms 可以接受，因此目前采用了这种方案。

当然，官方文档指出 join 性能是会慢的，后续也有待实践检验。

4. 粗排相关性打分
#

Lucene 从 2016年的 6.0 版本开始，默认的相关性算法切换成了 bm25 ， bm25 是一种调整过的 tf idf 算法。

这里可以做一简单举例介绍，更深入的介绍可以参见下面文章，以及官方文档：

https://farer.org/2018/09/10/practical-bm25-part-1-how-shards-affect-relevance-scoring-in-elasticsearch/

https://www.cnblogs.com/richaaaard/p/5254988.html

ES 的 explain 对 bm25 算分的过程有详尽的解释，推荐自行实验。

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-explain.html

4.1. BM25 例解
#

比如某业务的真实数据中，我们在所有文档的 title 这个 field 搜索 “牛奶 ” 这个词，

explain 可以看到，这个 bm25 分数的是这样得来的：

sum( weight(title:牛奶 in 77341) [PerFieldSimilarity] ) ，
weight(title:牛奶 in 77341) [PerFieldSimilarity] = idf * tfNorm

首先，如果某 field 被多个 term 命中，分别算每个 term 的分数 (PerFieldSimilarity)，然后求和，本例子只有1个 term “牛奶”。

每个 term 的分数 PerFieldSimilarity

PerFieldSimilarity = idf * tfNorm

而 idf 表征词的重要程度，与具体文档无关。

idf = log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))

其中 docFreq 就是本shard 中，有多少个文档含有 “牛奶”， docCount 就是本shard 一共有多少个文档。

tfNorm = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength))
termFreq=1.0
k1=1.2
b=0.75
avgFieldLength=14.456173
fieldLength=2 //比如如果 title 是 "牛奶 醪糟" ，那就是 2个 term

freq 即该 field 中，“牛奶”这个词出现了几次 k1 和 b 都是固定常数。 fieldLength 是当前文档的当前field ，一共有多少个 term。 avgFieldLength 即本 shard 中的所有文档的本 field 的 fieldLength 的平均值

4.2. BM25 shard 调整
#

实际业务发现，当 index 内文档太少(比如 10w 量级就算少) 时，有的词在多个 shard 内，词频分布会出现严重不均匀，可能会导致 bm25 分数产生较大偏差，

实践中的解决办法：

Search 的 url_parameters 参数填 “&search_type=dfs_query_then_fetch”
减少 shard 数

4.3. BM25 similarity 参数调整
#

如上计算过程可见，bm25 中的 b 参数，是用来给短文档做加权的，即 b 越大，越倾向于给短文档更高的 score，实际中，和算法同学一起分析后，发现针对我们的某业务，不应该对短文本有太高偏向，所以我们把 b 调整成了 0.3 ，实测发现解决了一批 bad case，用户体验有明显改善。

四，性能优化
#

计算机程序的性能取决于数据结构和算法， ES/Lucene 中主要有几种数据结构:

FST
Posting List ，著名的倒排索引，PForDelta 压缩，支持 SkipList 方式跳跃
BKD Tree，用来实现 int 和 geo 查询
DocValues , 以 DocID 为 Key 的列存储

https://zhuanlan.zhihu.com/p/47951652

https://www.elastic.co/blog/elasticsearch-query-execution-order

更深入的理解，我目前也在探索中。

在垂直搜索引擎业务中，用户对延迟非常敏感，一般业界经验认为，良好的用户体验应该是在 ** 200毫秒 ** 内返回搜索结果，这就意味着 ES 延迟最好控制在 100毫秒之内。

经过我们实际业务发现，决定 ES 延迟的因素主要有：

内存是否足够， page cache 是否 cache 了检索过程用到的文件数据
具体 query 的优化，类比 mysql query 优化

1. page cache 内存优化
#

page cache 是决定 ES 延迟的首要因素，用作在线检索服务的 ES ，实际中在线检索的代码路径不能有硬盘 io 访问 (实践证明， SSD也不行)

当 ES 用作在线垂直搜索引擎时，

《查询亿级数据毫秒级返回！牛逼哄哄的ElasticSearch是如何做到的？》 https://zhuanlan.zhihu.com/p/68706615

《ElasticSearch在数十亿级别数据下，如何提高查询效率？》 https://zhuanlan.zhihu.com/p/60458049

实践中，某 index 发现延迟非常高，达到了 1-2秒，用户体验很差。调查发现，iostat 看下 io util 很高，经常到 80% 90%，单机索引数据文件是 page cache 可用内存的 4倍，于是降低了副本数，单机数据量减少到 page cache 可用内存2倍后，硬盘 io 降到了 0 ，延迟一下降低到了 150ms 。

2. int 字段查询优化
#

业务中常会有一些 int 型的字段，存一些枚举性质的值。在 10亿以上文档的情况下，实际发现有的会出性能问题。

比如比如前述业务有1个 int 类型的 filter 字段，实际只有 {0,1} 2种取值，

借助 ES 的 profile ，我们发现搜索 query 93% 的耗时在 filter 字段的 PointInSetQuery 中，

随后发现，针对该业务，只需要返回 filter 为 0 的文档，于是我们在更新文档时，发现 filter 非0 的文档，直接把所有字段都清空，并随后在 query 中去掉了 filter 字段的过滤。

之后发现耗时从 150ms 降到了 20ms。

3. 副本数 replicas num
#

确定副本数的思路：

副本数越小越好。越小，单机数据越少，文件被 cache 的比例越高，性能越好。
副本太少会影响可用性。因此必须大于最大能容忍故障单机个数 max_failures 。

综合起来就是：

max(max_failures, ceil(num_nodes / num_primaries) - 1).

num_primaries 是 primary shards 的数量，就是一个 index 有多少个 shards，一般都 > num_nodes

replicas_might_help_with_throughput_but_not_always

对数据量特别少的 index，可以每台机都存一个副本 “auto_expand_replicas”: “0-all”,

4. 多 SSD
#

在 elasticsearc.yml 的 path.data 配置多个路径，ES 会自动把 shard 均分到多个路径上，如果有多个硬盘，可以充分利用多设备的 io 带宽，当然对在线业务意义不大。

5. 内存配置
#

最开始我们使用 16G 内存机型，后来发现出现大量 Elasticsearch Data too large Error 错误，随后发现，解决办法就是换到 64G 内存机型，

改 jvm.options 加大 jvm 的 heap 解决，从 10G 加大到 30G 解决 -Xms30g -Xmx30g

需要注意的是，不建议大于 32G，避免 jvm 的指针压缩优化失效。可以看 ES 的启动 log 确定

[2019-05-22T12:29:16,961][INFO ][o.e.e.NodeEnvironment ] [node_xxx] heap size [29.7gb], compressed ordinary object pointers [true]

https://www.elastic.co/cn/blog/a-heap-of-trouble

6. refresh_interval
#

如网上众多文章所说， refresh_interval 一般都设成了 30秒。

一些参考资料：

滴滴 Elasticsearch 多集群架构实践 https://cloud.tencent.com/developer/article/1405404
京东到家订单中心 Elasticsearch 演进历程 https://cloud.tencent.com/developer/article/1377194
从平台到中台：Elaticsearch在蚂蚁金服的实践经验 https://new.qq.com/omn/20190117/20190117A09ADY.html
美团点评旅游搜索召回策略的演进 https://tech.meituan.com/2017/06/16/travel-search-strategy.html
eBay 的 Elasticsearch 性能调优实践 https://www.infoq.cn/article/elasticsearch-performance-tuning-practice-at-ebay
有赞搜索系统的架构演进 https://tech.youzan.com/search-tech-1/
有赞搜索引擎实践(工程篇) https://tech.youzan.com/search-engine1/
全面理解搜索Query：当你在搜索引擎中敲下回车后，发生了什么？ https://zhuanlan.zhihu.com/p/112719984
elasticsearch初学终极教程: 从零到一 https://kalasearch.cn/blog/elasticsearch-tutorial/

Python 自动翻译成 C++ ，彻底保证离线在线特征一致

Fri, 29 Nov 2019 00:00:00 +0000

一，问题背景
#

随着深度学习的广泛应用，在搜索引擎/推荐系统/机器视觉等业务系统中，越来越多的深度学习模型部署到线上服务。

机器学习模型在离线训练时，一般要将输入的数据做特征工程预处理，再输入模型在 TensorFlow PyTorch 等框架上做训练。

1.常见的特征工程逻辑
#

常见的特征工程逻辑有：

分箱/分桶离散化
log/exp 对数/幂等 math numpy 常见数学运算
特征缩放/归一化/截断
交叉特征生成
分词匹配程度计算
字符串分隔匹配判断tong
缺省值填充等
数据平滑
onehot 编码，hash 编码等

这些特征工程代码，当然一般使用深度学习最主要的语言 python 实现。

二，业务痛点
#

离线训练完成，模型上线部署后，同样要用 C++ 重新实现 这些 python 的特征工程逻辑代码。

我们发现，“用 C++ 重新实现” 这个步骤，给实际业务带来了大量的问题：

繁琐，费时费力，极容易出现 python 和 C++ 代码不一致
不一致会直接影响模型在线上的效果，导致大盘业务指标不如预期，产生各种 bad case
不一致难以发现，无法测试，无法监控，经常要靠用户投诉反馈，甚至大盘数据异常才能发现

1. 业界方案
#

针对这些问题，我调研了这些业界方案：

《推荐系统中模型训练及使用流程的标准化》 https://www.infoq.cn/article/2E6LCqb1GeqFRAjkkjX3

《自主研发、不断总结经验，美团搜索推荐机器学习平台》 https://cloud.tencent.com/developer/article/1357309

《京东电商推荐系统实践》 https://www.infoq.cn/article/1OkKmb_gEYNR3YqC9RcW

“模型线上线下一致性问题对于模型效果非常重要，我们使用特征日志来实时记录特征，保证特征的一致性。这样离线处理的时候会把实时的用户反馈，和特征日志做一个结合生成训练样本，然后更新到模型训练平台上，平台更新之后在推送到线上，这样整个排序形成了一个闭环。”

总结起来，有几种思路：

在线特征存储起来给离线用
在线 C++ 代码编译成 so 导出给离线用
根据一份配置生成离线和在线代码
提取公共代码，加强代码复用，等软件工程手段，减少不一致

2. 自动翻译方案
#

(1) .已有方案的缺点
#

但这些思路都有各种缺点：

所有在线请求的所有特征，这个存储量数据量很大
算法改代码需要等待后台开发，降低了算法同学的工作效率
特征处理代码的复杂度转移到配置文件中，不一定能充分表达，而且配置格式增加学习成本
就这边真实离线特征处理代码来看，大部分代码都无法抽取出公共代码做复用。

(2). 翻译器
#

回到问题出发点考虑，显而易见，这个问题归根结底就是需要一个 “ python 到 c++ 的翻译器 ” 。

那其实 “翻译器 Transpiler ” ，和编译器解释器类似，也是个古老的热门话题了，比如 WebAssembly, CoffeeScript ，Babel , Google Closure Compiler，f2c

于是一番搜索，发现 python 到 C++ 的翻译器也不少，其中 Pythran 是新兴比较热门的开源项目。

于是一番尝试后，借助 pythran，我们实现了：

一条命令 全自动把 Python 翻译成等价 C++
严格等价保证改写，彻底消除不一致
完全去掉重新实现 这块工作量，后台开发成本降到 0 ，彻底解放生产力
算法同学继续使用纯 python，开发效率无影响，** 无学习成本 **
并能推广到其他需要 python 改写成后台 C++ 代码 的业务场景，解放生产力

三，pythran 的使用流程
#

(1). 安装
#

一条命令安装：

pip3 install pythran

(2). 写 Python 代码
#

下面这个 python demo，是 pythran 官方 demo

import math
import numpy as np

def zero(n, m):
 return [[0]*n for col in range(m)]

#pythran export matrix_multiply(float list list, float list list)
def matrix_multiply(m0, m1):
 new_matrix = zero(len(m0),len(m1[0]))
 for i in range(len(m0)):
 for j in range(len(m1[0])):
 for k in range(len(m1)):
 new_matrix[i][j] += m0[i][k]*m1[k][j]
 return new_matrix

#pythran export arc_distance(float[], float[], float[], float[])
def arc_distance(theta_1, phi_1, theta_2, phi_2):
 """
 Calculates the pairwise arc distance
 between all points in vector a and b.
 """
 temp = (np.sin((theta_2-theta_1)/2)**2
 + np.cos(theta_1)*np.cos(theta_2) * np.sin((phi_2-phi_1)/2)**2)
 distance_matrix = 2 * np.arctan2(np.sqrt(temp), np.sqrt(1-temp))
 return distance_matrix


#pythran export dprod(int list, int list)
def dprod(l0,l1):
 """WoW, generator expression, zip and sum."""
 return sum(x * y for x, y in zip(l0, l1))


#pythran export get_age(int )
def get_age(age):
 if age <= 20:
 age_x = '0_20'
 elif age <= 25:
 age_x = '21_25'
 elif age <= 30:
 age_x = '26_30'
 elif age <= 35:
 age_x = '31_35'
 elif age <= 40:
 age_x = '36_40'
 elif age <= 45:
 age_x = '41_45'
 elif age <= 50:
 age_x = '46_50'
 else:
 age_x = '50+'
 return age_x

(3). Python 转成 C++
#

一条命令完成翻译

pythran -e demo.py -o demo.hpp

(4). 写 C++ 代码调用
#

pythran/pythonic/ 目录下是 python 标准库的 C++ 等价实现，翻译出来的C++ 代码需要 include 这些头文件

写个 C++ 代码调用

#include "demo.hpp"
#include "pythonic/numpy/random/rand.hpp"
#include <iostream>

using std::cout;
using std::endl;

int main() {
 pythonic::types::list<pythonic::types::list<double>> m0 = { {2.0, 3.0},
 {4.0, 5.0} },
 m1 = { {1.0, 2.0},
 {3.0, 4.0} };
 cout << m0 << "*" << m1 << "\n=\n"
 << __pythran_demo::matrix_multiply()(m0, m1) << endl
 << endl;

 auto theta_1 = pythonic::numpy::random::rand(3),
 phi_1 = pythonic::numpy::random::rand(3),
 theta_2 = pythonic::numpy::random::rand(3),
 phi_2 = pythonic::numpy::random::rand(3);
 cout << "arc_distance " << theta_1 << "," << phi_1 << "," << theta_2 << ","
 << phi_2 << "\n=\n"
 << __pythran_demo::arc_distance()(theta_1, phi_1, theta_2, phi_2) << endl
 << endl;

 pythonic::types::list<int> l0 = {2, 3}, l1 = {4, 5};
 cout << "dprod " << l0 << "," << l1 << "\n=\n"
 << __pythran_demo::dprod()(l0, l1) << endl
 << endl;

 cout << "get_age 30 = " << __pythran_demo::get_age()(30) << endl << endl;

 return 0;
}

(5). 编译运行
#

g++ -g -std=c++11 main.cpp -fopenmp -march=native -DUSE_XSIMD -I /usr/local/lib/python3.6/site-packages/pythran/ -o pythran_demo 

./pythran_demo

四，pythran 的功能与特性
#

(1). 介绍
#

按官方定义，Pythran 是一个 AOT (Ahead-Of-Time - 预先编译) 编译器。给科学计算的 python 加注解后，pythran 可以把 python 代码变成接口相同的原生 python 模块，大幅度提升性能。

并且 pythran 也可以利用 OpenMP 多核和 SIMD 指令集。

支持 python 3 和 Python 2.7 。

pythran 的 manual 挺详细： https://pythran.readthedocs.io/en/latest/MANUAL.html

(2). 功能
#

pythran 并不支持完整的python，只支持 python 语言特性的一个子集:

polymorphic functions 多态函数(翻译成 C++ 的泛型模板函数)
lambda
list comprehension 列表推导式
map, reduce 等函数
dictionary, set, list 等数据结构
exceptions 异常
file handling 文件处理
部分 numpy

不支持的功能：

classes 类
polymorphic variables 可变类型变量

(3). 支持的数据类型和函数
#

pythran export 可以导出函数和全局变量。支持导出的数据类型，BNF 定义是：

 argument_type = basic_type
 | (argument_type+) # this is a tuple
 | argument_type list # this is a list
 | argument_type set # this is a set
 | argument_type []+ # this is a ndarray, C-style
 | argument_type [::]+ # this is a strided ndarray
 | argument_type [:,...,:]+ # this is a ndarray, Cython style
 | argument_type [:,...,3]+ # this is a ndarray, some dimension fixed
 | argument_type:argument_type dict # this is a dictionary

 basic_type = bool | byte | int | float | str | None | slice
 | uint8 | uint16 | uint32 | uint64 | uintp
 | int8 | int16 | int32 | int64 | intp
 | float32 | float64 | float128
 | complex64 | complex128 | complex256

可以看到基础类型相当全面，支持各种整数，浮点数，字符串，复数

复合类型支持 tuple, list, set, dict, numpy.ndarray 等，

对应 C++ 代码的类型实现在 pythran/pythonic/include/types/ 下面，可以看到比如 dict 实际就是封装了一下 std::unordered_map https://pythran.readthedocs.io/en/latest/SUPPORT.html 可以看到支持的 python 基础库，其中常用于机器学习的 numpy 支持算比较完善。

五，pythran 的基本原理
#

和常见的编译器/解释器类似， pythran 的架构是分成 3 层：

python 代码解析成抽象语法树 AST 。用 python 标准库自带的的 ast 模块实现
代码优化。在 AST 上做优化，有多种 transformation pass，比如 deadcode_elimination 死代码消除，loop_full_unrolling 循环展开等。还有 Function/Module/Node 级别的 Analysis，用来遍历 AST 供 transformation 利用。
后端，实现代码生成。目前有2个后端，Cxx / Python， Cxx 后端可以把 AST 转成 C++ 代码（ Python 后端用来调试）。

目前看起来，pythran 还欠缺的：

字符串处理能力欠缺，缺少 str.encode()/str.decode() 对 utf8 的支持
缺少正则表达式 regex 支持
缺少 json 支持

看文档要自己加也不麻烦，看业务需要可以加。

六，相关文章
#

《京东电商推荐系统实践》 https://www.infoq.cn/article/1OkKmb_gEYNR3YqC9RcW

《自主研发、不断总结经验，美团搜索推荐机器学习平台》 https://cloud.tencent.com/developer/article/1357309

《推荐系统中模型训练及使用流程的标准化》 https://www.infoq.cn/article/2E6LCqb1GeqFRAjkkjX3

numba http://numba.pydata.org

用 DAT 重实现 CppJieba 中文分词算法，降低 99% 内存消耗

Mon, 25 Nov 2019 00:00:00 +0000

一，问题背景
#

中文分词应用比较广泛的开源算法，是 jieba 结巴分词，结巴分词较高性能的实现是 C++ 版本的 CppJieba : https://github.com/yanyiwu/cppjieba

在实际使用 CppJieba 的过程中，我们发现 CppJieba 的内存占用比较高。

比如对一个 76W 词大小 11MB 的词典，加载 2份（比如为了支持平滑改动用户词典）就需要耗费 505MB内存。

这对一些多进程的后台服务，浪费大量内存，难以接受，因此这里希望削减内存耗费。

经过初步调查，确定改进方法，然后动手改造，最终把 505MB 缩减到了 4.7MB ，实现了 99% 内存降低。

此处也有 issue 讨论 https://github.com/yanyiwu/cppjieba/issues/3

代码在 https://github.com/byronhe/cppjieba 。

二，实现过程
#

二.1 查内存分布
#

第一步先用 jemalloc 的 memory profiler 工具查看内存耗费在哪里，

改一下 CppJieba 的 test/demo.cpp，链接 jemalloc，编译成二进制 jieba_test
然后设置环境变量 export MALLOC_CONF="prof:true,prof_prefix:mem_prof/mem_profile_je.out,lg_prof_interval:20,lg_prof_sample:20"
然后 mkdir mem_prof，并运行测试程序
jeprof –pdf ./jieba_test mem_prof/mem_profile_je.out.xxx.heap > mem_profile.pdf

打开 mem_profile.pdf ，就可以看到内存分布了

二.2 优化方案
#

显而易见，内存主要耗费在:

Trie.hpp 中的 Trie 树构建
KeywordExtractor.hpp 加载 idf 词典文件。

因此方案:

1. Double Array Trie 代替 cppjieba::Trie
#

引入 Double Array Trie (简称 DAT ,https://github.com/s-yata/darts-clone) , 代替 Trie.hpp 中的简单内存 Trie，并把 darts 生成的 DAT 保存到文件中，在启动时，如果已经有和词典对应的 DAT ，直接 mmap() attach 上去，即可启动。

经过实测发现，75万词词典，dart-clone 生成的 DAT 文件，大小只有 24MB，而且可以 mmap 挂载，多进程共享。

2. KeywordExtractor
#

KeywordExtractor 是个不常用功能，直接改成支持传入空的 idfPath 和 stopWordPath, 此时不加载数据即可。

二.3 其他问题
#

1. 支持热更新，保证词典和DAT一致
#

这里一个问题是，词典可能热更新，那怎么知道 DAT 文件和当前词典的内容对应？

我的做法是，对默认词典文件+自定义词典文件，用文件内容算 MD5，写入 DAT 文件头部，这样打开 DAT 文件发现 MD5 不一致，就知道 DAT文件过时了，即可重建 DAT 。

实测发现算 MD5 还是很快的，启动时间都在 1秒左右。

2. 代码清理
#

另外，清理了一下代码，删掉了 Unicode.hpp 中的无用代码。清理了 FullSegment.hpp HMMSegment.hpp MixSegment.hpp MPSegment.hpp QuerySegment.hpp 等中的重复代码。

3. 不兼容改动
#

由于 Double Array Trie 无法支持动态插入词，删除 InsertUserWord() 方法
FullSegment.hpp 中 maxId 的计算有 bug，做了 fix。
为了节省内存，改成允许传入空的 idfPath 和 stopWordPath 。
会生成 Double Array Trie 临时文件，临时文件名默认会自动生成，也可以传 dict_cache_path 指定
改成自定义词典中重复的词，保留权重最大的。
删除 Unicode.hpp 中的无用代码

整体改造后，代码量比原来减少 100 多行。

上线后效果显著。

当内存降低到 2-3MB 的水平后，这意味着 75W 词这种规模的大词典，可以用在手机环境。

比如可以在 ios 或者 Android 上做中文/英文的切词，这意味着可能在客户端实现体验相当良好的搜索引擎。

ios 上也有可用于中文的分词器 CFStringTokenizer ，但貌似不开源。

GB 规模语料上的高性能新词发现算法

Wed, 18 Sep 2019 00:00:00 +0000

分词是中文搜索的重要环节，目前分词算法已经比较成熟，分词错误的主要是由于未登录词。

因此发现业务领域语料库中的新词，减少未登录词，对改善搜索引擎的用户体验有重要意义。

新词发现的一种常用算法，是 matrix67 大神 2012 年提出的《互联网时代的社会语言学：基于SNS的文本数据挖掘》 https://www.matrix67.com/blog/archives/5044

其主要思路，是统计语料中出现的所有 ngram 子字符串的凝固度，自由度，信息熵。

算法中需要统计所有 ngram 子字符串的左熵右熵，实现该算法时，一般以子字符串为 key，用哈希表来存。

但随着语料库变大时，内存消耗变大，

比如之前的 python 版本实现，对 200MB 的语料，就需要约 30G 内存来存哈希表，

导致单机内存不足无法运行，而且对这样规模的语料库，算法需要跑一两天才能出结果。

这里我应用一些工程实现方面的技巧，把用哈希表统计左熵右熵的计算，拆分成多个子哈希表，分批计算，并利用多核并行，大幅度优化了算法的性能。

最终实现了 GB 大小语料上的新词发现，并把运行时间缩减到了 30 分钟左右。

https://github.com/hankcs/HanLP/wiki/%E6%96%B0%E8%AF%8D%E8%AF%86%E5%88%AB

Search on Tech Explorer

倒排索引求交算法相关资料调研

1. IR-book 经典教材中的思路 #

2. lemire 教授的 SIMDCompressionAndIntersection 库中有多种算法 #

3. “The magic of Algorithms! " 中的算法 #

4. List Intersection for Web Search: Algorithms, Cost Models, and Optimizations #

基于 ElasticSearch 开发垂直搜索系统

一，背景介绍 #

二，架构方案 #

1. 转发代理 proxy #

2. 队列 #

3. 其他工具 #

三，搜索应用开发优化指南 #

1. query DSL 语法 #

2. 分词 #

3.关系型搜索 #

4. 粗排相关性打分 #

4.1. BM25 例解 #

4.2. BM25 shard 调整 #

4.3. BM25 similarity 参数调整 #

四，性能优化 #

1. page cache 内存优化 #

2. int 字段查询优化 #

3. 副本数 replicas num #

4. 多 SSD #

5. 内存配置 #

6. refresh_interval #

Python 自动翻译成 C++ ，彻底保证离线在线特征一致

一，问题背景 #

1.常见的特征工程逻辑 #

二，业务痛点 #

1. 业界方案 #

2. 自动翻译方案 #

(1) .已有方案的缺点 #

(2). 翻译器 #

三，pythran 的使用流程 #

(1). 安装 #

(2). 写 Python 代码 #

(3). Python 转成 C++ #

(4). 写 C++ 代码调用 #

(5). 编译运行 #

四，pythran 的功能与特性 #

(1). 介绍 #

(2). 功能 #

(3). 支持的数据类型和函数 #

五，pythran 的基本原理 #

六，相关文章 #

用 DAT 重实现 CppJieba 中文分词算法，降低 99% 内存消耗

一，问题背景 #

二，实现过程 #

二.1 查内存分布 #

二.2 优化方案 #

1. Double Array Trie 代替 cppjieba::Trie #

2. KeywordExtractor #

二.3 其他问题 #

1. 支持热更新，保证词典和DAT一致 #

2. 代码清理 #

3. 不兼容改动 #

GB 规模语料上的高性能新词发现算法

1. IR-book 经典教材中的思路
#

2. lemire 教授的 SIMDCompressionAndIntersection 库中有多种算法
#

3. “The magic of Algorithms! " 中的算法
#

4. List Intersection for Web Search: Algorithms, Cost Models, and Optimizations
#

一，背景介绍
#

二，架构方案
#

1. 转发代理 proxy
#

2. 队列
#

3. 其他工具
#

三，搜索应用开发优化指南
#

1. query DSL 语法
#

2. 分词
#

3.关系型搜索
#

4. 粗排相关性打分
#

4.1. BM25 例解
#

4.2. BM25 shard 调整
#

4.3. BM25 similarity 参数调整
#

四，性能优化
#

1. page cache 内存优化
#

2. int 字段查询优化
#

3. 副本数 replicas num
#

4. 多 SSD
#

5. 内存配置
#

6. refresh_interval
#

一，问题背景
#

1.常见的特征工程逻辑
#

二，业务痛点
#

1. 业界方案
#

2. 自动翻译方案
#

(1) .已有方案的缺点
#

(2). 翻译器
#

三，pythran 的使用流程
#

(1). 安装
#

(2). 写 Python 代码
#

(3). Python 转成 C++
#

(4). 写 C++ 代码调用
#

(5). 编译运行
#

四，pythran 的功能与特性
#

(1). 介绍
#

(2). 功能
#

(3). 支持的数据类型和函数
#

五，pythran 的基本原理
#

六，相关文章
#

一，问题背景
#

二，实现过程
#

二.1 查内存分布
#

二.2 优化方案
#

1. Double Array Trie 代替 cppjieba::Trie
#

2. KeywordExtractor
#

二.3 其他问题
#

1. 支持热更新，保证词典和DAT一致
#

2. 代码清理
#

3. 不兼容改动
#