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.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 06:09
浙ICP备14020137号-1 $お客様$