1 引言
以C2C为主的平台，区别于B端用户，C端卖家在发布商品时更倾向 图+描述 的轻发布模式，对补充商品的结构化信息往往执行力和专业程度不高，为商品理解带来困难。为在发布侧获得更多的商品结构化信息，尝试在原有图+文的极简发布模式中加入商品关键属性的补充选项，适当的结构化属性选项并不影响用户发布体验，却能极大提升我们对商品理解的能力。然而
1.1 问题
设定结构化属性选项时，往往强依赖行业运营经验，缺少实时、多维数据分析手段。虽然离线产出数据报表能一定程度统计某些关键指标，但对精细的、个性化数据查询需求，离线报表扩展性和性能都不足。 为此，搭建数据分析平台。
2 数据分析平台定位与总体框架
区别于数据报表，设计数据分析平台
2.1 要求
- 实时性，当运营上线新策略或因服务问题线上出现数据波动，希望实时分析出结构化类目属性在这段时间内的覆盖情况，以帮忙运营进一步决策
- 多维度，目前拥有近万的叶子类目，不同行业运营侧重点不同，数据分析平台要能满足个性化数分需求
- 数据管理，类目属性、SPU数据、运营策略需统一管理
希望以此实现结构化数据对运营的反哺，构成商品结构化数据生产与应用的闭环。
2.2 总体分层框架
3 数据链路建设
构建数据分析平台关键是数据链路的建设，公司的结构化数据主要分为：
- 在线数据（通过发布、编辑入口用户直接填写的数据）
- 离线数据（通过后置算法模型分析商品的图文获取的数据）
3.1 难点
- 存储数据量大（全量20亿+），访问QPS高（1.5万+），服务稳定性要求高
- 数据来源多（10余种），各来源数据异构，存在重复、冲突的数据，数据实时性要求高（秒级延迟）
- 数分场景复杂（QPS小，但SQL复杂度高），普通数据库查询难支撑
针对数据量大和QPS高，用tableStore作存储商品结构化信息的数据库，一种典型的列存储数据库，扩展性好、可用性高、单机可支撑QPS上万，非常适合作大数据的存储终端。可用性达99.99%，支持主备双库。
- 在线数据存储在MySQL商品表，通过在Java应用中监听表的变更，将数据写入数据源表
- 离线数据通过ODPS+MQ，将数据传入算法模块，并通过blink将算法结果写入数据源表
由于在线、离线的多来源数据可能重复、冲突（同一商品算法A识别为iphone 12而算法B识别为iphone 11），所以系统设计时用：
- 源表存储所有原数据
- 终表存储加工融合之后的数据，加工融合的策略是产品、运营可决策的
分析数据
用分析型数据库ADB，其存储容量、单机查询QPS都远不及tableStore，但复杂SQL运行、实时索引创建、冷热数据隔离等有其他数据库不及的性能，是数分库较好选择。
4 离线异构数据源的接入
结构化数据不仅仅来自于发布时的卖家填写，C端卖家填写结构化属性的专业程度和执行力远不及淘宝天猫卖家，所以通过图文多模态算法，在发布的后置链路中为商品补充很多结构化的属性（这部分cpv目前占大盘覆盖率的一半左右，不同类目情况不同）。
接入这些离线数据的难点
- 各数据具有结构不同、产出时间不同、数据量级大的特征，难以复用相同模式，接入新数据源的成本高
- 数据同步任务分散，难做统一监控
为此，设计一套离线异构数据源统一接入方案：
各算法的离线数据存储在ODPS，各算法的数据格式不一样，数据分区也不同，所以先通过一个ODPS的同步任务将各数据源数据统一到一张结构化标准标签表idle_kgraph_std_source中。表结构如下：
表中key为主键信息，因不同场景的数据主键不一样，所以这里设计为开放式主键，数据为JSON格式：
- K为主键列名
- V为主键值
结构化标准表idle_kgraph_std_source通过一个Blink任务实时同步到tableStore的各个场景的数据表中。在Blink任务中，根据scene、source字段将数据分发，根据data中的key将数据路由到tableStore表中的不同列。为提升效率，减少在Blink任务中写数据库的次数，拿到数据后，先对数据进行合并，将同种场景（例如结构化属性数据）的多来源数据合并成一条，再进行写操作。
这套方案成功解决多数据源接入中数据难以收口，难以统一监控，同时，数据标准表中开放式数据格式的设计使得新数据源能够快速接入，极大降低重复开发成本。
5 数据加工融合
获取到多来源数据后，对数据进行加工融合，融合策略是由产品、运营共同决定，变更策略时，存量商品数据也要重新加工融合，所以数据加工融合链路必须具备增量处理稳定，全量处理快速的特点。
进行全量处理数据时，利用分布式任务调度系统，主任务节点通过数据库分片将全量数据划分多份，并将数据索引下发给各子任务节点，由子任务进行数据拉取，使数据拉取与处理不受数据库的物理分区与通道限制，大大提升性能，目前6亿全量数据处理仅需40min。
任务分发策略
主要解决：
- 分布式任务分发，分布式完成全量任务
- 操作幂等，操作可以重复，但不影响最终结果
- 全量增量彼此隔离，不影响在线服务
6 数据分析模块设计
据分场景大量涉及正逆排序、按某指标过滤的频繁查询，若对每次数分请求都做一次完整数据查询，对数据库会造成较大压力。
所以，将请求的分析条件分为：
- 维度分析：根据不同维度，需运行不同查询逻辑。通过一个Distributor将分析请求路由到不同的processor执行
- 筛选排序：这些条件不影响查询逻辑，只会在查询结果排序或过滤，对此，优先从缓存获取，并在内存排序过滤，以提升分析性能
7 效果
目前平台已推广至行业运营、搜索、首页推荐等场景，取得阶段性效果：
- 为行业运营提供8000+叶子类目属性维度的数据分析，助力运营决策结构化选项在公司主发中的透出，帮忙其为公司结构化大盘贡献8成类目覆盖，一半核心cpv覆盖
- 为搜索、推荐等场景提供快捷的查询手段，帮助开发、算法同学实时定位线上问题，实现秒级延迟。大大提升badcase归因定位效率
8 展望
致力于打造成一个全面、灵活、准确的商品理解数据平台，接下来我们将主要针对以下方面继续优化：
