百度海量商品库存储优化实践

羽遇雨

?作者简介：李文伟 百度商业平台研发部资深研发工程师，主要负责百度商品广告系统架构设计研发。?导语在百度商业生态中有大量平台类的广告主，如京东、阿里、点评、安居客等等，这些广告主往往具备海量的商品服务能力。百度作为流量分发方，希望能够将广告主的商品服务精准的推送到百度用户，从而实现连接人和商品服务的能力。为了实现这个目标，百度打造了一套完整的商品广告投放系统，一方面能够存储和处理全网十亿级商品服务（百度商品库），另一方面能够将海量商品和用户实现精准的连接匹配（商品广告算法）。下面笔者将主要从工程的角度，为大家详细的介绍下百度商品库的核心挑战与架构实践。百度商品库面临的挑战百度商品库作为百度的结构化数据存储中心，存储了十亿级广告主结构化商品数据。由于百度广告主覆盖了几乎全部的行业，导致不同行业的结构化数据有很大的差异，同时即使在同一个行业的商品，往往有不同子品类，商品数据无法简单的使用一套Schema标准进行定义：为满足不同行业数据异构的存储需求，商品库1.0 版本采取了MySQL行+列的商品存储方式，同时当商品量持续提升之后，我们根据uid对商品库进行了分库分表设计，最后的数据存储结构如下：这样的一套行+列的数据结构加上分库分表的商品存储方案，在业务初期较长一段时间内表现了较好的灵活性，保障了业务快速发展。但是随着业务发展，商品数量不断提升，当商品量达到亿级规模的时候，商品库逐渐暴露了一系列性能、可维护性问题：「扩容困难」 在业务发展高峰期的时候商品总量在一年时间内翻了接近4倍，一般在运维的时候，MySQL容量只会提供一倍的存储冗余，这样导致每过一段时间，我们就要手动为MySQL进行扩容，MySQL扩容需要停机停服，MySQL扩容操作成本相当高。「读写压力大」 为了保证商品数据的高时效性，广告主商品每天都要进行一次全量更新，尽管通过调度的调配已经做到不同广告主直接错峰更新，但动辄上千万商品的全量读写，对MySQL造成了严重的负担，尤其是行+列存储的商品属性表，导致1个商品的更新，会造成几十行MySQL记录的读写操作，加剧了数据库超负荷运行状态。「商品时效性差」 商品从客户写入到线上生效，还需要经过包括转储、审核、匹配、优化等多道处理工序，商品库每天需要处理上亿的商品更新，尤其峰值期间大客户批量导入，导致整个数据处理流程堵塞，线上出现客户价格不一致，商品已下架等时效性问题。「商品筛选困难」 商品广告的投放场景，允许广告主根据投放意图从海量商品中灵活筛选出全量商品进行投放。为满足客户全量筛选商品的需求，我们设计了一套分布式内存计算的商品筛选架构，但当要筛选的数据量超过1000w的时候就出现筛选堵塞，计算慢，数据截断等问题。为解决商品库遇到的这些问题，我们对商品库存储、时效性、筛选能力进行一次全面的改造。商品存储基于商品库场景及未来发展考虑，在本次存储改造选型中我们主要考虑以下几个诉求：「易扩展」可预期的时间内，商品库存储还将继续快速增长，我们希望尽可能降低存储扩容成本。「schema free」商品库具备跨行业特性，商品属性字段具备较大的不确定性，原本的行+列存储虽然对商品属性字段提供了灵活性，但带来的额外读写开销也很大，我们希望新的DB能提供更优雅的解决方案。「写能力强」为满足广告数据时效性要求，商品库每天都需要对商品进行全量的更新，对DB写库能力提出很大挑战为此我们主要对比了MongoDB和度厂的表格存储TableStorage（内部代号table2）方案：存储易扩展Schema Free写能力成熟度MongoDB弱，自动扩容不成熟强，支持文档动态存储强中，主要是度厂内缺少MongoDB运维较不成熟TableStorage强，自动扩容无感知强，支持动态加列强中，度厂版的HBase，有比较专业的开发运维团队协助综合考虑之后最终我们采用了TableStorage作为底层存储方案，一方面TableStorage的列模型存储能天然满足商品库Schema Free的场景，另一方面TableStorage集群有很强的扩展性，系统扩容对应用无感知，同时基于LSM的读写方案，有很强的写能力，在商品库多写少读场景下性能表现更优。「TableStorage」系统是百度自研的大规模分布式表格系统。采用了类似BigTable的稀疏表数据模型，提供Schema Free、数据多版本、数据过期失效、快照等等NoSQL数据库的普遍特性。TableStorage系统中，有以下数据模型：Column Family（CF）：考虑到表格的value列的个数可以变动，有必要把value列分组管理，CF是列的逻辑分组。Locality Group（LG）：LG是数据列的物理分组，将不同列存放到不同LG，可以减少查询导致的I/O操作，提高性能。商品库基于TableStorage的列存储特性，将原本多套MySQL业务数据表改造到了1套Table表中，通过productid作为rowkey来统一管理商品的上下线，这样大大方便了商品数据的流转和统一管理。通过这样一套底层存储结构，我们实现了商品库数据总线的能力。商品在各个处理环节都能方便快捷的获取到最新的商品信息，同时当商品出现上下架时，各个处理环节都能第一时间感知到，避免了数据冗余。基于TableStorage的商品库提供了良好的数据读写能力，如下图统计，商品库读写的99线峰值达到了QPS16w，同时在商品总量从亿级别提升到十亿级别的过程中，商品库不再需要停机扩容，TableStorage实现了平滑的扩容能力。商品时效性商品时效性问题表现在两方面：商品上下架、价格变更等敏感信息能够准实时的线上生效商品内容变更如何高效的在线上生效针对敏感信息的快速生效，一方面需要外部能够第一时间通知商品库变更消息，同时商品库内部需要有一条高速通路直达线上。为此一方面我们对外提供了一套标准的商品易变信息更新接口，能够提高包括但不限价格、库存敏感信息的实时推送能力；另一方面，我们基于TableStorage多Column Family逻辑隔离的特性，开辟了单独的易变字段CF，实时监听敏感信息变更并推送线上。而针对商品普通内容变更，我们采取商品分级处理策略，以商品审核场景为例：「中小管道」少商品量广告主由于往往对投放变更有更高的时效性要求，由于商品量少，我们可以提供更高的时效性处理能力；「大广告主热商品」由于商品处理的主要目的是为下游广告投放展现使用，广告展现概率越高的商品，商业价值也往往越高，实际上广告主投放的商品，每天在线上有展现的只占10%左右，为此我们基于商品展现概率实现了一套商品商业价值打分机制，更具商品的商业价值进行分管道独立审核，为高商业价值商品提供优势资源。通过这样一套分级机制，商品审核的堵塞延迟95线从原来12h左右，提升到了10min内，时效性得到了很大改观。商品筛选类似京东等大广告主在商品投放的时候，往往需要从海量商品中挑选出符合当次投放诉求的商品。这类筛选有两个特征：规则筛选：有别于文本匹配，广告主往往基于规则精准的投放商品，比如京东自营&价格>200元&品类=运动鞋。全量筛选：区别于网页浏览只需要查看前面几页数据，广告主投放希望将符合规则的成百上千万商品全部投放，需要产出全部筛选结果。为提升筛选计算能力，起初我们设计了一套分布式的内存筛选计算框架，将全库商品分为32内存分片，当有计算请求过来时，由master调度各分片上的jvm实例进行计算，最后由master进行结果的merge。这套系统涉及了内存加载、内存优化、失败重试等一系列的优化措施，能够基本满足100w以内的商品筛选能力。但随着商品总量的增长，内存命中率越来越低，商品计算耗时也线性增长，商品筛选堵塞问题日趋严重，同时自建的商品索引筛选系统的维护成本也越来越高，为此我们将目光放到了业内开源产品，希望使用更业内更成熟的开源方案来解决这个问题。考虑到商品库筛选场景，新方案需要支持灵活的筛选能力，易扩展（满足数据量高速增长的需求），高性能（同时支持商品的全量检索），我们主要考察了以下几种方案：技术方案灵活性扩展性高性能Elastic Search同时支持精准+模糊查询任意组合强，支持不停服扩容通过snapshot方案实现全量数据快速导出MongoDB不支持任意筛选条件组合强，支持不停服扩容全量数据导出性能较低通过商品筛选的灵活性，以及针对全量商品筛选性能对比，我们最终采用了ES作为底层技术方案。在使用ES的过程中，索引如何构建非常讲究。如果我们将所有商品放到了1个index，那么单个索引大小需要20T以上，这对每次商品检索无疑是增加了性能开销。考虑到商品库使用场景，广告主往往只能对自家商品进行检索，因此我们首先考虑对商品使用user进行索引拆分。然而我们发现光不行，由于不同user商品体量差异很大，少到几个，大到上亿，在索引的分片（shard）设置上需要根据索引的大小进行分配。考虑到ES性能优化，我们知道1个shard的大小最好不要超过30G，同时shard过于分散也会增加索引计算量，为此我们制定了一套基于商品量大小动态建立索引的方案：中小user通过取模的方式分布在32个索引中，使用统一的分片数=2*实例节点数，为每个大广告主单独建立索引，分片数=索引大小/20G，同时为了实现索引分片均匀的分布到各个实例节点，可以充分的将请求分散到不同节点上计算，分片数根据实例数向上取整倍数。经过这样索引拆分，相比单索引的方案，索引的读写性能都提升了1倍以上。结语百度商品库从产品伊始到现在，已经快走过8个年头。没有最好的技术，只有最合适的技术，当业务起步期，我们需要考虑的是如何用最简单快速的技术方案，解决产品业务需求；而当随着业务成长，原有技术方案逐渐出现瓶颈的时候，我们更不能固步自封，敏锐的找到优化方案，勇敢的突破现状，实现系统的自我更新。