Pallas--唯品会统一检索平台的演进和探索
如果无法正常显示,请先停止浏览器的去广告插件。
1. Pallas:
唯品会统一检索平台的演进和探索
薛珂
唯品会.基础架构部
2.
3.
4. 薛珂
高级架构师
• 互联网技术爱好者,曾参与主导多个大型互
联网产品的整体架构;
• 2016加入唯品会,现任基础架构服务化团队
负责人;主持唯品会服务化平台的建设(微服
务/检索平台/调度服务/函数服务/网关/配置
中心/授权服务等);
• 技术兴趣集中在分布式设计,高可用架构,
任务调度,搜索引擎,优雅设计,高性能服
务等领域;
5. 关于检索
Lucene
Solr
Elastic Search
5
6. Case1.商品搜索
文本分词检索,相似性算分
打分和重排逻辑复杂,更新频率
非常高
特征:文本搜索,打分
7. Case2.运营后台
10亿数据的表
每月增长1亿
多关键字复合查询
查询结果聚合统计
Mysql数据库一次查询
2分钟
特征:SQL慢查询
8. Case3.订单搜索
数十亿数据
分表分库,128个库
按商品名/品牌名/订单号搜索
特征:分表分库检索
9. Case4.财务系统报表
百亿级数据表
多维度查询及聚合
对响应时间有要求(秒级)
特征:大数据量,聚合
10. 关于平台
Pallas的成长之旅
11. 选型的思考 – Why ElasticSearch
社区活跃程度
代码质量 赏心悦目
架构合理性 简洁,主流(Gossip/Pacific-A/Primary-backup),无额外服务依赖
可扩展性 插件机制完备
基础功能完整性 强大的DSL支持,高可靠,分布式,弹性高可用
文档质量 准确,完备,更新及时
12. 如何管理我的ES集群?
Cerebro
Rest API
Kibana
• 太原始 • 偏数据处理
• 使用成本高 • 管理功能不强
• 权限问题 • License问题
统一
鉴权
Bigdesk
Sense
Pallas集群管理
13. Pallas集群管理-Cerebro
14. Pallas集群管理-Bigdesk
15. Pallas集群管理-Sense
16. 规范化查询的思考
DSL很强大,也很复杂
生产中复杂DSL可达上千行
几乎不可读
无法debug
性能问题
17. 规范化查询的思考 – 模板化
POST merchandise/_search POST merchandise/_search/template
{ {
"query":{
"bool":{"filter":[{"terms":{"sales_no":[1917309]}},{"ter
ms":{"_routing":[1917309]}},{"term":{"is_warmup":1}}
,{"term":{"is_deleted":0}}]}},"aggs":{"terms_by_sales_
no":{"terms":{"field":"sales_no","size":200,"order":{"_c
ount":"desc"}},
"aggs":{
"m_sn_count_warmup":{"filter":{"bool":{"filter":[{"ter
m":{"mer_item_no":"0"}},{"term":{"is_warmup":1}}]}}
},"m_sn_count_not_warmup":{"filter":{"bool":{"filter":[
{"term":{"mer_item_no":"0"}},{"term":{"is_warmup":0
}}]}},"aggs":{"count": {"value_count":{"field":
"merchandise_no"}}}}}}
}
}
使用前
"id": "merchandise_mcount_by_warmup",
"params": {
"sales_nos": 1917309
}
}
使用后
18. 规范化查询的思考 – ES模板管理
通过API创建
上传文件到ES服务器
19. Pallas Console – 模板管理
在线编辑
include语法支持
在线调试
版本管理,快速回滚
灰度验证 (高级功能)
上线审核
实时性能调优
20. DSL性能调优若干案例
{
"_source": [
"m_id", "brand_id", "brand_name"
],
"query":{
"match_all" : true
}
{
"range":{
"m_c3_show_to" : {
"gt" : "now+8h"
}
}
}
}
{
"range":{
"m_c3_show_to" : {
"gt" : "now+8h/m"
}
}
}
30% qps增长
{
"_source": false,
"docvalue_fields": [
"m_id", "brand_id", "brand_name"
],
"query":{
"match_all" : true
}
}
15% qps增长
{
"terms": {
"sales_no": [1917309, 1917307 ]
},
{
"term": {
"is_warmup": 1
}
}
{
"terms": {
"sales_no": [1917309, 1917307 ]
},
{
"script": {"script": {
"lang": "painless",
"params": {"warmup": 1},
"inline": “
return doc['is_warmup'].value == params.warmup"
}
}}
10倍提升(不是银弹)
21. 规范化查询的思考 – 用户视角
1 在线编辑(导入)模板
Pallas
2 审核上线
业务系统
3 查询请求
ES集群
ES集群
22. 索引更新机制的思考
方案1
1
业务系统
方案3
方案2
Mysql
Mysql
业务系统
1
Mysql
业务系统
1
2
2
ES
• 性能问题
• ES单点问题
• 事务问题
2
Kafka
3
• 事务问题
ES
ES
23. 索引更新机制的思考 – 我们的方案
Kafka Message
Kafka
全量同步
Job
Pallas Index
数据对帐
Job
增量同步
Job
Saturn
数据同步四步曲
1 启动增量同步(空转不写ES),消费堆积log
2 停增量同步Job,启动全量同步
3 全量同步结束,启动增量同步和数据对帐
RDP
4 数据对帐每隔一定时间(1天)做一致性比对
ES
Binlog
ES Cluster
Mysql
rdp
数据管道, 类似Canal
ES
Saturn
任务调度系统 (开源)
24. 索引更新机制的思考 – 分表分库的支持
Channel1
Channel2
ES
Pallas
Index
Channel3
db1 db2
db3 db4
RDP
业务系统
Channel4
增量同步数据流
25. 索引更新机制的思考 – 用户视角
创建索引
(输入数据源)
可支持同构多数据源
调整Schema
开始同步
26. 异地多活的思考
IDC-1
核心诉求
IDC-2
MHA
Mysql
Mysql
ES集群整体不可用时
自动切换到远端机房
同机房优先
Pallas Index
Pallas Index
ES集群
(主)
业务系统
ES集群
(备)
业务系统
27. 异地多活的思考 – 我们的方案
IDC-1
Pallas Index
Mysql
1%
Pallas Search
业务系统
MHA
Mysql
Pallas Index
ES集群
(备)
ES集群
(主)
99%
IDC-2
1%
99%
Pallas Search
业务系统
28. 异地多活的思考 – 我们的方案(故障切换)
IDC-1
Pallas Index
MHA
Mysql
Mysql
Pallas Index
ES集群
(备)
ES集群
(主)
100%
Pallas Search
业务系统
IDC-2
100%
Pallas Search
业务系统
29. 路由的思考 – 路由设计
1-1 1-2 1-3
1-4 1-5 1-6
1-7 1-8 1-9
1-1
索引名: merchandise
匹配规则:
99
1-7
结点集1
es-cluster-001
来源IP : 192.168.0.0/16
Header[Key] : Value
1-4
2-1
1
2-1 2-2 2-3
2-4 2-5 2-6
2-7 2-8 2-9
2-4
2-7
结点集2
Target Group
es-cluster-002
30. 集群规划的思考
m
m
专用集群
m
VS
专用集群
m
m
专用集群
小集群
m
专用集群
Master
ES公共集群-001
Data only node
Master only node
Data & Master node
大集群
31. 大集群按业务隔离 – 我们的方案
> 创建索引时设置索引include结点
m
PUT indexName/_settings
{"index.routing.allocation.include._ip": "192.168.2.*"}
> 配置路由规则,隔离访问请求
m
Master
Data Node
ES公共集群-001
规格:
3
+
200
业务组
Master Node
32. 恼人的超时毛刺
平均响应时间很短,
个别请求响应时间很长
QPS低时问题更加明显
查询优化失去意义
平均响应时间16MS
Query Cache
Data Cache
必定会有比例失效
个别请求响应时间超过300MS
33. 超时毛刺的斗争 – 重试
Rest Filter
Pallas Search
Initial
ES Cluster
Timeout: 300MS
100MS
Retry1
Retry2
Timeout: 100ms
Timeout: 200MS
100MS
Timeout: 100MS
Retry: 2
34. 超时毛刺的斗争 – 更多
凌晨时分Force Merge
流量高峰前做流量回放,强行预热
Schema优化,避免nested字段查询,
keyword代替int/long
尽可能使用routing
升级ES版本(5.3->5.5,商品搜索性能提升70%)
35. 插件升级的故事
业务系统
插件更新频繁(1周或1天一更)
Pallas Search
打分插件
排序插件
ES
线上业务,不允许服务中断
36. 插件升级的故事 – 升级是一场灾难
Q: 200个结点的集群,升级ES插件要多长时间?
逐个复制插件代码到各个结点
对每个结点重复以下动作(200次)
11分钟
摘流量 10秒
迁走分片 5分钟
重启 30秒
等集群状态恢复 5分钟
开放流量 10秒
A: 11 x 200 = 2200分钟 (36个小时)
37. 插件升级的故事 – 我们的方案
业务系统
上传
Pallas Console
Pallas Search
Pallas Plugin
ES
业务插件
可动态升级
Pallas 插件
与ES同步升级
打分插件
排序插件
线上动态升级
38. 插件升级的故事 – 核心技术实现
Usage
Pallas
Plugin
入口
Class
loader
Down
loader
Class
loader
{
下载
Pallas Console
升级至
V1.0.2
Before
}
打分插件 排序插件
{
打分插件
排序插件
V1.0.1
V1.0.2
"script_score" : {
"script": {
"inline": "real_stock ",
"lang": "native"
}
}
After
}
"script_score" : {
"script": {
"inline": "pallas",
"lang": "native",
"params": {
"_plugin": "real_stock“
}
}
}
39. Pallas的全貌
搜索系统
收藏系统
Pallas Platform
开发
运维
Data Source
ES集群
ES集群
40. Pallas的构成
搜索系统
收藏系统
Pallas Search(Java,独立进程)
开发
运维
Pallas
Index
(Job)
Pallas
Console
(web)
Data Source
Pallas
Plugin
ES
ES集群
41. Pallas特性概览
Pallas
Console
ü 集群申请和管理
ü 模板管理/发布
ü 路由/超时管理
ü 插件动态升级
ü 索引申请和管理
ü ES在线重启
ü 模板灰度验证
Pallas
Search
Pallas
Index
ü ES代理
ü 服务路由
ü 超时重试
ü 安全控制
ü 限流/熔断…
ü 流量记录
ü 数据同步
ü 数据对帐
ü 流量回放
42. Pallas在唯品会
过百亿索引数据
几百台物理机,东莞/佛山/顺德/南沙多IDC部署
承载着核心业务(商品搜索,收藏,运营后台,订单搜索)
数据写入TPS10万级别,检索QPS10万级别
43. 未来规划
Pallas预计2018年Q4开源
44.
45.
46.
47.