如图7所示，资源发布者上传资源到该系统，并附带对应业务、版本号及md5。资源使用者只需要理解对应业务当前的版本号，版本管理系统会返回对应的资源文件。线上实际使用时，在线模块会定期轮训某业务对应数据版本文件的md5和本地文件md5是否一致，不一致则会拉取最新的文件，拉取完成后校验md5是否一致，最终实现更新。

在业务模型或检索库需要回退时，只需修改配置文件，重启服务即可。

图7 数据版本管理系统

2.4 docker化

目标检测、检索特征提取等是典型的图像深度学习任务，业界内有caffe、pytorch、tensorflow、tensorRT等多种深度学习框架，有的框架不能保证向上兼容。而我们负责炼丹的同学第一要务是追求效果指标，在尝试各种奇淫巧技时练出来的丹通常并不能和微信的线上环境很好的兼容。

简而言之，在重算法的工程系统中，不仅有业务代码的更新，还有工程环境的迭代。这非常适合使用docker来封装和迭代业务环境。通过docker化部署，我们可以更方便的引入更多开源组件来支撑业务，也可以让我们在一些框架选型上更加灵活。

就我们自己的业务场景而言，我们还可以利用微信深度学习任务平台(yard)的计算资源，这部分属于平台内部的公用资源，需要抢占式使用。yard也是docker化去执行任务。这为我们业务可以借助yard公用资源作为临时扩容worker节点做了很好的铺垫。

分布式计算

我们每天平均有1500w增量数据，全量为十亿级别的数据。单机必然无法满足处理的实效性，唯有分布式计算才能满足要求。

3.1 数据拆分

正如mapreduce，map阶段的工作我们需要对数据进行拆分。这里对拆分原则除了平均外，还考虑了拆分后到数据的运行时间。如果拆分太细GPU的运行效率会降低，拆分太粗会导致错误修复的时间成本变大。我们让每个拆分后的任务都尽量控制在1小时内完成，最终拆分的粒度为每个包10w左右。

3.2 数据并行计算

拆分后的数据进行并行计算相当于reduce阶段，这里的重点是如何将拆分后的数据分发到多台机进行计算。此外，我们还希望yard公用资源空闲时可以非常灵活的进行扩容接入，提高并发处理能力。

我们结合zookeeper的分布式锁特性，实现了一套可靠分布式任务队列。worker采用拉模式拉取队列的任务。这样的优点是伸缩性好，可以灵活的增加和减少yard的机器资源。如图8，当新worker接入后，从队列中拉到任务直接执行，可以实现秒级的扩容。

图8 伸缩性好

对于我们的场景，任务需要被可靠消费，这里的可靠包含来两层含义。

第一是避免任务被重复消费，我们借助zookeeper的保活锁，锁通过心跳保持活性。如图9中第1，2时刻，worker拿到队列里的任务抢锁成功才可执行；如果出现机器宕机，如图9第3时刻，锁会自动释放。

第二是完整消费，我们在task被完全消费结束后才删掉队列里的对应task，如时刻4的task2。时刻3由于机器宕机，task1并未被完整消费，因此依旧存在，后续可被继续消费。

图9 可靠消费

理论上讲，我们的消费模式属于至少一次消费(at least once)，极端情况下，如果worker执行完任务还没有回传状态时宕机，那任务仍处于未成功消费，仍可能被后续worker消费。这里需要保证任务的幂等性。

引入yard公用计算资源提升了我们的处理能力，但同时也给我们带来了一些小问题。例如，公用集群的机器配置比我们自己集群要好很多，为了使不同集群都能发挥最大的GPU性能，我们支持不同集群使用不同的全局参数配置。而且公用集群和文件系统不在同一个idc，导致网络IO时间过长，降低了GPU利用时间，我们在公用集群的同idc实现了一套文件预拉取系统，根据任务队列中存在的任务，提前同步待消费文件到同idc的文件缓存系统。

为了提高GPU利用率，我们还做了大量的工程优化，这里就不展开叙述了。基于分布式计算的框架，极大提升了我们的计算效率。拿计算效率最低的目标检测任务举例，目前我们集群的处理能力可达到5600w图/天，如果加上公用计算资源，可以达到1.2亿图/天 (集群12台P4双卡，公用集群yard-g7a集群平均10个双卡，深度学习框架使用的tensorRT)。

任务调度

虽然我们每天有1500w左右的原始图片，但最终符合录入检索库的商品仅有一半不到。因为为了确保检索数据的质量，我们会在多个维度做数据过滤。现在我们的图片从下载到建库一共会经历30+种中间任务，图10仅展示了主要的任务流程模型。

图10 任务流

4.1 任务系统

随着任务的增多，尤其是许多任务间存在着复杂的依赖关系，每个任务都不是一个独立的个体，每个任务的成败都将影响最终的结果。为了更好的管理每个任务的状态，梳理任务间的依赖，使得工程的复杂度不随任务变多而变大，我们自研了一套任务调度系统。

调度系统主要由以下几个部分组成：

· 文件系统：文件系统这里使用了微信自研分布式文件存储系统的WFS，我们所有中间数据和结果数据都存放在这里

· 存储系统：主要有任务存储和实例存储，与一般实例存储不同的是，为了分布式计算，我们在数据维度和类目维度做了拆分，一个实例包含一个或多个子实例

· 调度系统：主要负责收集、管理任务状态，检查任务依赖

· 触发器：定时轮训调度系统，找到满足执行条件的任务实例

· 任务队列：存储待执行的任务实例，由worker获取依次消费

图11 任务调度系统

容灾性上，调度系统相关的模块均是多机多园区部署，只要不是某个模块完全挂掉，整套任务调度都可以正常执行。

4.2 在线服务合并部署

对于每天的例行任务，实效性并不敏感，早几个小时或晚几个小时对业务影响不大。但GPU资源是是十分宝贵的，我们将部分GPU机器和在线GPU服务合并部署。结合在线流量屏蔽策略，实现高峰时期资源借给在线服务，低峰时期运行离线任务。

如图12所示，其为一台参与离线任务闲时调度的在线模块，我们拟定每天0点-7点的低峰时间为离线运行时间，7点-24点的高峰时间为在线模块服务时间。最大限度的利用了宝贵的机器资源。

图12 分时调度运行

数据质量

前面做的工作保证了我们以任务为粒度的工程可靠性，但任务的成功并不能保证业务数据是完整的，如数据丢失、代码逻辑有问题等。为了监控数据维度上的业务质量，我们基于ELK搭建了一套数据系统，主要用于收集重要的基础数据、业务数据、运行结果等。

5.1 数据可视化

我们曾在几次版本迭代过程中，发现数据出错，但发现时已经付出了极高的时间代价。因此我们希望在任意时刻都能观察离线系统的运作是否正常，数据的流转是否符合预期。出现问题后可以及时干预修正，降低错误成本。

我们对涉及数据流转的核心任务都做了数据结果上报，这样子我们可以通过数据漏斗发现是否出现问题。这个问题在全量数据重跑的时候尤其重要。图13展示了项目中核心任务的数据情况。

图13 数据漏斗可视化

上图看上去是每天任务级的数据监控，但实际上我们我们的设计是扩展到了每次任务级（这里定义为planid），既可以是每天，也可以是每次覆盖多天的重跑。我们按图14的字段上报业务的运行结果，前4个字段组成联合唯一索引，planid作为区分每次运行的逻辑字段。这样即使同一个任务在不同时期运行结果是不同的，我们也能区分每一次运行后，真实的数据结果。这个设计在保证每次大版本数据迭代时，对于把控数据整体运行质量十分重要也十分有效。

图14 上报字段

5.2 一致性检查

数据可视化方便了我们检查问题，但是还不利于我们发现问题。我们还需要在数据出问题时，能及时告警、迅速修复。这最最重要的就是数据一致性，这里的一致性主要是一些核心任务的数据漏斗，输入和输出应该是一致的。图15中展示了一些存在关联的任务，带颜色线段代表数据存在关联性。

为了满足各种维度的统计、校验，同时又能快速支持新任务的检查。我们封装了核心的统计和校验逻辑，配置化告警任务，确保层层流程运转后的结果准确无误。

图15 一致性检查

5.3 评测系统

我们在对我们的检索库做比较大的版本迭代，或是线上策略有比较大调整时，直接灰度上线再观察曲线有时并不能及时发现问题，存在很大的隐患。基于这种情况，我们开发了自动化测试系统。我们提前收集和整理了部分带标签的数据样本，每次更新都需要在测试环境自动化评测一次，如图16所示。我们在结合具体指标分析此次迭代是否可以安全上线。

图16 评测系统

5.4 数据淘汰

我们平均每天流入数据超过千万，数据膨胀的速度非常快，这给我们带来了极大的存储成本和迭代成本。但回顾业务本身，其实许多商品数据在随着时间的推进，将变成过期、死链、下架数据。最简单的做法就是使用窗口期来维护我们的数据，窗口外的数据自动淘汰，我们在faiss检索库选型时也是这样考虑的。

但是我们也想到，直接暴力的淘汰旧数据也会有个致命问题。对于我们的业务而言，什么数据对我们是重要的，常见的热门商品固然重要，但是相对冷门长尾商品同样重要，后者决定来商品库长尾的多样性。如果删掉某个商品，检索库可能就没有这个商品了，这是十分糟糕的。

因此我们在做数据淘汰的时候，需要考虑对有价值的长尾商品做保留。图17展示了我们数据淘汰的方式，通过这种方式，我们窗口期内的数据质量将变得越来越高，全量数据的增长也相对可控。

图17 窗口期为K的数据淘汰

总结

以上我们大致介绍了“扫一扫识物”的离线系统中的所涉及的一些关键点，部分模块仍在持续优化中。未来扫一扫识物将引入更多场景的识别，拓展更多维度的物品，追求“万物皆可扫”的目标。

注：此文章来源于微信AI；

微信在线客服

请提供详细的截图大图+文字说明您的问题
微信扫码查看帮助
扫码关注，获取各种排版小技巧，黑科技！