Pallas--唯品会统一检索平台的演进和探索
2020-02-23 290浏览
- 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.