关于运维:得物榜单｜全链路生产迁移及BC端数据存储隔离

0次阅读

共计 7880 个字符，预计需要花费 20 分钟才能阅读完成。

榜单在经验了供给量迅速增长及 C 端散发场景多样化等迭代，数据量及峰值流量呈十倍百倍增长，这必然带来数据库的极大存储压力和 C 端查问性能升高。为满足将来各类简单定制化规定和亿万级数据甄选，综合疏导消费者的购物决策，得物商品榜单生产迁徙及 B / C 端数据存储隔离应运而生。

得物榜单作为 C 端外围导购场景之一，通过建设丰盛的规定矩阵，多维度提供用户购买参考倡议，帮忙用户疾速决策并实现商详转化。目前涵盖六种类型包含热销榜、新品榜、趋势榜、种草榜、好评榜及回购榜，次要入口包含商详、品牌主页、分类 tab、瀑布流、会场、频道等。

通过 圈品条件 圈选出一系列商品，再依据 排序规定 排名后取 TOP20 商品入选榜单。圈品范畴包含类目、品牌、系列、标签等，通过【6 类模型、N 项指标因子】综合计算排序后的总分代表商品的综合竞争力，分值越大，代表该商品体现越好。得物榜单基于上述算法模型严格把控上榜商品品质，从而帮忙用户依据本身诉求疾速决策。

通过对榜单排序逻辑优化可针对性晋升榜单承接效率，摸索一套最佳排序规定公式须要通过一直的尝试，因而整个试验周期较长，在设计上就须要反对试验的疾速推动。

来看下目前如何实现榜单的创立及生产。

 波及表 

根底表：记录榜单根底信息；
圈品条件表：记录榜单圈品维度信息包含类目 id、品牌 id、系列 id、标签 id、商品 ids 汇合等；
商品汇合表：记录榜单下关联的 top20 商品 id，以后榜单 B / C 端流量都是走了这个表的查问；

 如何绑定圈品范畴？

人工榜单 通过后盾新增榜单时绑定捞月规定或人工间接配置商品 ids 汇合，并同步写榜单圈品条件表；
半自动化榜单 通过后盾新增榜单时绑定类目 id、品牌 id、系列 id 等维度规定，并同步写榜单圈品条件表；
自动化榜单 通过事后设定的规定批量写榜单圈品条件表；

 数据流转？

商品后盾新增榜单根底信息至根底表，将圈品范畴信息（类目、品牌、系列、标签、spuIds 等）保留至圈品条件表，搜寻每两小时定时从库中捞取圈品条件表数据，获取最新数据刷到商品汇合表中。

搜寻数仓 H +1/T+1 dump：搜寻离线数仓通过离线计算排序因子数据，生成离线宽表；
搜寻离线圈品排序引擎：对照组榜单由搜寻生产。 每 2 小时定时调度 ，扫描圈品条件表全量数据，从宽表中筛选商品并进行排序，排序后果通过 DTS 数据同步回流榜单商品汇合表；
搜寻离线圈品排序引擎：实验组榜单由商品圈品排序引擎生成，底层实现和搜寻大致相同。

商品 / 搜寻存在双写榜单商品表场景，因为搜寻通过 dts 数据同步形式回流数据，导致数据互相笼罩甚至主键抵触，通过 id 隔离的形式能够临时解决。

目前榜单商品生产链路强依赖搜寻，由搜寻实现商品圈选及排序，搜寻榜单商品生产方式繁多，无奈满足榜单圈选 / 排序规定定制化供应。而 「捞月」 作为得物外围选品投放平台，曾经具备弱小的圈品排序能力。

海量选品指标维度（商品根底信息，流动信息，价格与库存，流量与转化等）撑持各业务，分钟级别选品实时指标数据；

odps 离线指标数据：商品 / 交易指标进行计算产出离线宽表。
实时交易指标：如流动期间 GMV，买家数等交易数据。

离线 DUMP：离线数仓通过离线计算指标对应值经由 datawork 同步工作将指标值同步至捞月 B 端 ES。

实时 DUMP：业务零碎 / 实时数仓或其余对接模式准实时的通过商品 Feature(一些业务逻辑性强的指标）、DB BinLog 或其余形式将数据告诉到捞月指标核心，再由捞月指标核心将数据落到捞月 B 端 ES。

分钟级别执行引擎更新选品后果。

反对个性化、统计字段、自定义权重配比等多维度简单升降序排序规定；也反对用户特色，进行举荐算法个性化排序。

 具体细节不在本文开展，重点关注捞月指标体系、选品及排序能力在本次迁徙中的利用。

针对第一个和第二个问题，咱们提出榜单迁徙捞月——通过复用捞月现有圈选 / 排序能力，实现榜单商品生产能力搭建，将榜单生产从搜寻侧迁徙至商品侧，移除榜单底层能力搭建对搜寻的依赖。

将来榜单需撑持类目下沉场景，“类目下沉”即针对目前以类目为维度的榜单，再按品牌、系列、标签等维度进行榜单延长。如：跑步鞋热卖榜下，再细分出耐克跑步鞋、入门跑步鞋、透气跑步鞋等榜单，更多维度裁减包含人群、格调等。依照笛卡尔积生成形式将任意维度与类目进行两两组合，将产生百万级甚至千万级别  海量数据 ，造成极大的存储压力。同时，榜单从生产到 C 端散发，经验榜单商品圈定、审批流及其他状态管制，最终可能在 C 端胜利散发的榜单数量无限，每次查问都会触发无效数据的实时过滤。随着榜单数量的快速增长，必然带来 C 端查问性能升高，如大 key、索引生效等，存在性能隐患。榜单在商详散发，必然随同着  高并发读 。

针对这个问题，尽管能够尽量地从优化 sql、优化索引、缓存等等方面进行优化，但总会有达到极限的时候。对于海量数据的存储选型曾经有十分宽泛的案例，该如何进行存储选型？存储选型的目标还是为了咱们的应用场景和用户服务，因而在选型前须要答复一些业务指标 & 技术指标方面的问题，以便于咱们分明存储选型的应用环境：

数据量及日增数据量：数据量在可控范畴内日增稳固；
读写偏好：榜单状态及上榜商品不频繁变更，读多写少；
运行性能要求：并发量峰值商详、首页，低谷像一些二级页面；
查问复杂度：简单条件查问、聚合查问、join 查问；
其余性能要求：实时性要求不高；

联合榜单业务特色以及海量数据和高并发的特点，可能的解决方案不限于

应用缓存的形式通过程序代码将数据间接保留到内存中，如 ConcurrentHashMap、Caffeine 等；或应用缓存框架如 Redis 等；
数据库优化：数据库优化的形式很多，常见的能够分为：数据库表构造优化、SQL 语句优化、分区、分表、索引优化、应用存储过程代替间接操作等；
应用 NoSql 技术：HBASE、MongoDB 等；
应用搜索引擎技术：ElasticSearch 等；

设计实际中，要基于需要、业务驱动架构，无论选用 DB/NoSQL, 肯定是以需要为导向，最终数据存储计划必然是各种衡量的综合性设计：

分库分表：垂直切分实用于表中存在业务耦合，且拆分后单表数据量仍旧很大；程度切分的关联查问性能差；
HBASE：列存储分布式数据库，适宜 TB 级别数据的实时入库和疾速随机拜访场景，毛病是查问仅能通过 rowkey 和 range 检索，不反对简单查问；
MongoDB：文档型 NoSql，适宜非结构化数据存储，表构造可随便变更，因而插入效率高，同样的也是不反对简单查问如多表查问等；
ElasticSearch：写入性能低，实时性低，然而通过为所有字段增加索引可反对简单的聚合查问和条件查问。

综合思考，B/ C 端数据存储隔离成为当下 性价比最高 的解决方案。

以下将论述本次实际的具体施行点。

整体革新将分为两个阶段进行：首先实现链路革新，即榜单生产迁徙捞月，待数据验证通过进行第二阶段的存储革新，即 B / C 端数据存储隔离。

捞月需反对榜单试验能力，因而 在榜单对照组通用指标的根底上新增实验组通用指标，同时预留对应的实验组排序规定 。可反对同类型榜单同时段进行一项试验，试验完结后依据试验后果批改通用算法模型。 试验指标可在屡次试验复用，不会造成捞月指标数量的递增。

对照组热销榜分数指标(best_seller_score)：依据 7 日内销量与成交金额计算综合排序
对照组新品榜分数指标(new_product_score)：依据上架工夫和珍藏人数等指标综合计算排序
对照组趋势榜榜分数指标(soare_score)：依据近 7 日销量和珍藏人数等指标综合计算排序
对照组种草榜分数指标(collect_score)：依据当日新增商品销量等指标综合计算排序
对照组好评榜分数指标(favorite_score)：依据商品好评率和好评数等指标综合计算排序
对照组回购榜分数指标(rebuy_score)：依据商品年度累计回购人数等指标综合计算排序
实验组热销榜分数指标(best_seller_score_test)：依据累计付款人数和珍藏人数等指标综合计算排序
实验组新品榜分数指标(new_product_score_test)：依据上架工夫、点击、珍藏、销量等指标计算综合排序
实验组趋势榜榜分数指标(soare_score_test)：依据近 7 日销量和珍藏人数等指标综合计算排序
实验组种草榜分数指标(collect_score_test)：依据当日新增商品销量等指标综合计算排序
试验组组好评榜分数指标(favorite_score_test)：依据商品好评率和好评数等指标综合计算排序
试验组组回购榜分数指标(rebuy_score_test)：依据商品年度累计回购人数等指标综合计算排序

对照组热销榜排序规定(sort_best_seller)=best_seller_score * 100% desc
对照组新品榜排序规定
(sort_new_product)=new_product_score * 100% desc
对照组趋势榜排序规定
(sort_soare)=soare_score * 100% desc
对照组种草榜排序规定
(sort_collect)=collect_score * 100% desc
对照组好评榜排序规定
(sort_favorite)=favorite_score * 100% desc
对照组回购榜排序规定
(sort_rebuy)=rebuy_score * 100% desc
实验组热销榜排序规定
(sort_best_seller_test)=best_seller_score_test * 100% desc
实验组新品榜排序规定
(sort_new_product_test)=new_product_score_test * 100% desc
实验组趋势榜排序规定
(sort_soare_test)=soare_score_test * 100% desc
实验组种草榜排序规定
(sort_collect_test)=collect_score_test * 100% desc
实验组好评榜排序规定
(sort_favorite_test)=favorite_score_test * 100% desc
实验组回购榜排序规定
(sort_rebuy_test)=rebuy_score_test * 100% desc

{"name": "best_seller_score",     "type": "long"}, 
{"name": "new_product_score",     "type": "long"}, 
{"name": "soare_score",     "type": "long"}, 
{"name": "favorite_score",     "type": "long"}, 
{"name": "rebuy_score",     "type": "long"}, 
{"name": "best_seller_score_test",     "type": "long"}, 
{"name": "new_product_score_test",     "type": "long"}, 
{"name": "soare_score_test",     "type": "long"}, 
{"name": "collect_score_test",     "type": "long"}
{"name": "favorite_score_test",     "type": "long"}, 
{"name": "rebuy_score_test",     "type": "long"}, 
{"name": "sort_best_seller",     "type": "long"}, 
{"name": "sort_new_product",     "type": "long"}, 
{"name": "sort_soare",     "type": "long"}, 
{"name": "sort_collect",     "type": "long"}, 
{"name": "sort_favorite",     "type": "long"}, 
{"name": "sort_rebuy",     "type": "long"}, 
{"name": "sort_best_seller_test",     "type": "long"}, 
{"name": "sort_new_product_test",     "type": "long"}, 
{"name": "sort_soare_test",     "type": "long"}, 
{"name": "sort_collect_test",     "type": "long"},
{"name": "sort_favorite_test",     "type": "long"}, 
{"name": "sort_rebuy_test",     "type": "long"}

革新后全链路数据流转如图所示：

榜单创立：圈品条件写入捞月选品规定数据表；
排序规定：超时核心调用排序引擎更新每个商品的排序分同步捞月 B 端 es；
实时选品：圈品引擎分钟级别扫描待执行的选品规定数据，从底表中筛选符合条件的商品并生成选品集 id 同步捞月 B 端 es；
实现绑定：捞月 es 将选品后果回流到榜单商品表，并将选品集 id 回流到榜单根底表， 榜单 id 和选品集 id 绑定实现 ；
商品更新：监听捞月选品集后果变更音讯。

在链路革新环节咱们曾经实现了榜单和捞月集的绑定，因而查榜单下的商品就等同于查捞月集下的商品。

具体逻辑如下：

 那么是否齐全能够复用捞月存储构造，开释榜单商品集独立存储的空间 ？首先依据 B / C 查问场景划分为 正向链路和反向链路 。正向链路，也就是从榜单 id 获取到捞月集 id，从捞月 es 依据捞月集 id 获取捞月商品后果集，B 端查问形式均为正向链路，因而能够复用捞月存储构造。反向链路，即从捞月 es 依据商品 id 获取其所在的捞月集 ids，从捞月集 ids 查问榜单 ids。因为捞月集 id 暂无场景打标，只能遍历捞月集 ids 判断是否属于某一个榜单，查问老本极高，榜单在 C 端的外围散发场景商详便是满足了这个链路特色，当然咱们能够通过建设捞月集场景打标体系、构建榜单商品 ES 大宽表的形式来解决问题，有没有 性价比更高的解决形式？

针对以后业务规模及 C 端查问复杂度，思考采纳 B / C 端查问隔离的形式进行实现。捞月选品后果变更、榜单显示 / 暗藏、审核通过 / 驳回、失效 / 生效都会影响榜单的散发状态。最终能在 C 端散发的榜单非常无限，为防止在 C 端做大量数据的实时过滤，升高索引生效和大 key 危险 ，原 B / C 端专用数据源榜单汇合表仅存储可散发榜单商品数据供 C 端查问，实现形式及其简略：在状态变更及捞月后果集变更时触发实时更新 / 删除榜单汇合表即可，整个革新过程无需改变 C 端代码， 仅通过几行业务代码，就将 DB 存储数据量量级降至原来的 40%，可撑持将来两至三年数据量的稳定增长。

绝对于性能完整性，如何实现平滑稳固的切流是整个我的项目中比拟重要的一环。

为了实现用户无感切换，升高切换过程中可能呈现的故障对系统的影响，通过 多个灰度读写开关保障切流过程的平滑和稳定性，整个过程可，做到“随切随停”。整体灰度 分阶段逐步推进，采纳：

“增量数据保护 - 数据验证 - 全量数据刷数 - 数据验证 - 灰度切流 - 数据验证”的形式
各个阶段均有弥补策略或回滚计划，危险可控性较高

即采纳先进行增量数据保护，待增量数据 check+fix 通过后，进行全量数据刷数，待全量数据 check+fix 实现后，施行灰度读切流，并进行双读 check，一旦呈现问题则开关敞开；写切流采纳先写长期表，长期表数据验证通过后切换写主表，一旦呈现故障或脏数据，预案启动，可保证数据一小时内回滚。具体来说，咱们关注以下四点：

首先进行危险评估，波及榜单需绑定捞月集数量为 N，以每个捞月集限度 M 个 SPU 为准，选品后果集总数量可达 N *M，写入高流量将造成 ES 实例整体性能急剧下降。另一方面，数据修复老本极高，绑定谬误只能从新绑定新的捞月集，需全量删除旧捞月集后再绑定新捞月集，两次写入老本极高。因而先进行增量数据保护，待增量数据 check+fix 通过后进行全量数据分批刷数。

读切流：读切流的外围是将 B 端数据源切换到捞月 ES。 这一步执行的节点非常要害，需放在链路革新实现，存储革新开始之前进行。起因是如果先进行了存储革新再执行切流，因为存储革新实现后 rank_list 表仅存储可散发榜单，那么切流后一旦呈现问题应立即切换回老链路，原 B / C 端专用数据源 rank_list 表数据曾经不残缺，齐全不能满足 B 端应用，无奈疾速止血，只能疾速定位问题并修复上线。 确定执行工夫节点后，写好开关并进行双读 check，发现问题切换回原链路即可。

写切流：搜寻更新榜单商品开关敞开后，捞月选品后果全量写入榜单汇合表的危险较大，通过建设榜单汇合长期表，待长期表数据验证通过后切换主表。

双读 check、不定时全量数据 check+fix、增量数据 check+fix、利用监控、日志告警埋点等；

针对灰度过程可能呈现的所有数据谬误准备对应数据勘误接口。多想一步，如果在写切流过程中切换写主表后呈现未辨认到的数据谬误，如何疾速止血？ 在迁徙的过程中咱们临时保留搜寻更新榜单商品的能力作为数据修复预案，可在一小时内实现数据修复。

具体灰度切流推动流程如下：

经验两个星期的灰度，已移除对搜寻的依赖实现全链路闭环，按照灰度计划通过切流开关及预案等伎俩确保“随切随停”，上线期间零故障。

综上所述，榜单通过生产迁徙彻底解决了始终以来榜单底层能力撑持有余的痛点。实现链路合并后，借助捞月圈品排序能力升高将来各类简单定制化供应场景的保护老本，性能上线后已晋升榜单各类业务迭代效率晋升 50% 以上。并通过 B / C 端数据存储隔离，以极低的革新老本升高表存储老本 60%。

在这个根底上，思考是否有更多的发力点：联合以后零碎现状和将来的可能性，联合业务布局，围绕用户对平台榜单预期，将来将演变出多维度（内容、品牌、sku、spu 等）榜单通用生产引擎，在供应短缺根底上实现场景化个性化散发。

以上就是咱们在得物商品榜单生产革新摸索实际中的一些教训和总结，分享进去心愿对浏览本文的你有一些帮忙！

文 / 希希

正文完

运维

发表至：运维

2023-03-15

0

关于运维:生产环境安装PrometheusGrafana

关于运维:阿里云的认证为什么那么多人考没基础的人能考吗

关于运维:Linux-配置服务器之间免密登录传输文件

关于运维:阿里大淘系模型治理阶段性分享

关于数据库:DockQuery-成为信创产业关键码

关于运维:得物榜单｜全链路生产迁移及BC端数据存储隔离

1. 业务背景

2. 概述

2.1“圈选”+“排序”是外围：

2.2 是否存在更优的排序？

3. 零碎缺点及解决思路

3.1 链路强耦合

3.2 反复造轮子

3.2.1 捞月指标体系

3.2.2 捞月实时选品引擎

3.2.3 捞月排序核心

3.3 无奈撑持海量数据的高并发读

4. 技术施行点

4.1 链路革新

4.1.1 捞月指标创立

4.1.2 排序规定创立

4.1.3 指标、排序规定同步 ES 供后续选品及排序

4.2 存储革新

4.2.1 B 端数据源 - 捞月 B 端 ES

4.2.2 C 端数据源 - 榜单汇合 mysql 表

4.3 灰度设计

4.3.1 数据保护

4.3.2 读 / 写切流

4.3.3 数据校验

4.3.4 数据勘误

5. 总结

站内搜索