闲鱼商品理解数据分析平台—



 写点什么

引言

闲鱼是一个以 C2C 为主的平台，区别于 B 端的用户，C 端卖家在发布商品时更倾向于图+描述的轻发布模式，对于补充商品的结构化信息往往执行力和专业程度都不高，这为我们的商品理解带来了很大的困难。为了能够在发布侧获得更多的商品结构化信息，我们开始尝试在原有图+文的极简发布模式中加入商品关键属性的补充选项，事实证明，适当的结构化属性选项并不会影响用户的发布体验，却能极大地提升我们对商品理解的能力。然而存在以下问题：在设定结构化属性选项时，往往强依赖行业运营的经验，缺少实时的、多维度的数据分析手段。虽然离线产出的数据报表能够在一定程度上统计某些关键指标，但对于精细的、个性化的数据查询需求，离线报表扩展性和性能都不足。基于上述问题，我们搭建了龙宫数据分析平台。

龙宫数据分析平台的定位与总体框架

区别于数据报表，我们在设计龙宫数据分析平台时主要考虑了以下方面：

实时性要求，当运营上线新策略或因服务问题线上出现数据波动时，我们希望能够实时地分析出结构化类目属性在这段时间内的覆盖情况，以帮忙运营做进一步的决策。
多维度要求，闲鱼目前拥有 8000+的叶子类目，不同行业运营的侧重点各不相同，数据分析平台要能够满足个性化的数据分析需求。
数据管理要求，闲鱼的类目属性、SPU 数据、运营策略需要一个统一管理的地方。

我们希望以此实现结构化数据对运营的反哺，构成商品结构化数据生产与应用的闭环。

总体分层框架如下：

数据链路建设

构建数据分析平台的关键是数据链路的建设，在闲鱼，结构化数据主要分为在线数据（通过发布、编辑入口用户直接填写的数据）和离线数据（通过后置算法模型分析商品的图文获取的数据）。数据链路的建设存在以下关键难点：

• 存储数据量大（全量 20 亿+），访问 QPS 高（1.5 万+），服务稳定性要求高。

• 数据来源多（10 余种），各来源数据异构，存在重复、冲突的数据，数据实时性要求高（秒级延迟）。

• 数据分析场景复杂（QPS 小，但 sql 复杂度高），普通数据库查询难以支撑。

针对数据量大和 QPS 高的问题，我们选用 tableStore 作为存储商品结构化信息的数据库，它一种典型的列存储数据库，具有扩展性好、可用性高、单机可支撑 QPS 上万的特性，非常适合作为大数据的存储终端。其可用性可达 99.99%，同时具有主备双库能力。

同时我们在线数据存储在 mysql 的商品表中，通过在 java 应用中监听表的变更将数据写入数据源表；离线数据通过 ODPS+MQ 的方式将数据传入算法模块，并通过 blink 将算法结果写入数据源表。由于在线离线的多来源数据可能存在重复、冲突的问题（同一商品算法 A 识别为 iphone 12 而算法 B 识别为 iphone 11），所以在系统设计时我们使用源表来存储所有的原数据，使用终表来存储加工融合之后的数据，加工融合的策略是产品、运营可决策的。

分析数据我们使用的是分析型数据库 ADB，ADB 在存储容量、单机查询 QPS 方面都远不及 tableStore，但它在复杂 sql 的运行、实时索引创建、冷热数据隔离等方面拥有其他数据库不及的性能，是数据分析库的较好选择。

离线异构数据源的接入

在闲鱼，结构化数据不仅仅来自于发布时的卖家填写，正如前面所说，闲鱼的 C 端卖家在填写结构化属性的专业程度和执行力都远远不及淘宝天猫的卖家，所以我们通过图文多模态的算法，在发布的后置链路中为商品补充很多结构化的属性（这部分 cpv 目前占大盘覆盖率的一半左右，不同类目情况不同）。接入这些离线数据具有以下难点：

• 各个数据具有结构不同、产出时间不同、数据量级大的特征，难以复用相同模式，接入新数据源的成本高。

• 数据同步任务分散，难以做统一监控。

针对这些难点我们设计了一套离线异构数据源统一接入的方案：

null

各个算法的离线数据存储在 ODPS 中，各个算法的数据格式不一样，数据的分区也不同，所以先通过一个 ODPS 的同步任务将各数据源数据统一到一张结构化标准标签表 idle_kgraph_std_source 中。表结构如下：

表中 key 为主键信息，因为不同场景的数据主键不一样，所以这里设计为开放式的主键，数据为 json 格式，key 为主键列名，value 为主键值。结构化标准表 idle_kgraph_std_source 通过一个 Blink 任务实时同步到 tableStore 的各个场景的数据表中。在 Blink 任务中，根据 scene 和 source 字段将数据进行分发，根据 data 中的 key 将数据路由到 tableStore 表中的不同列。同时为了提升效率，减少在 Blink 任务中写数据库的次数，拿到数据后，先对数据进行合并操作，将同种场景（例如结构化属性数据）的多来源数据合并成一条，再进行写操作。

通过这套方案，我们成功解决了多数据源接入中数据难以收口，难以统一监控的问题，同时，数据标准表中开放式数据格式的设计使得新数据源能够快速接入，极大地降低了重复开发的成本。