如何支持研发对CSDN个性化推荐系统重构

news2024/11/17 1:42:44

本文侧重在个性化推荐系统治理中的4种重要的工程保证：

大地图

首先我的同事介绍了在《CSDN个性化推荐系统的设计和演化》，介绍了许多在服务代码层面做的持续的重构工作。这部分工作基本上需要持续有耐心地将系统的每个部分都梳理、重构、迭代、上线。

从系统治理的角度来说，服务代码的直接重构是系统中的一个最重要的环节，但不是全部。这是因为这样的系统包含对多个部分的理解：

所以，从系统治理的角度，大概构架图这样的：
在这里插入图片描述
在系统治理的过程中，需要完整的梳理3个环节是如何工作的：

没有全链路信息，我们就是在盲人摸象，这是系统工程，需要严肃的工程和数据质量。

在整个系统治理期间，工程上的做法是：

从头到位维护一份持续更新的个推数据管道流向的文档
- 使用分层、表格梳理的方式梳理全链路的数据流向
  - 以数据流动和朔源为驱动
    - 服务研发、测试、数据研发联合持续更新

我们都知道，在工程上，维持开发/测试/正式三件套的完整分离的环境对于健康项目的迭代是非常重要的。但是我们也经常遇到一些系统由于历史的各种原因，并不完整的具有开发/测试/正式三件套环境。这给开发、测试和验证功能带来了很大的麻烦。

但是作为工程师，我们必须解决问题，有时候不能等着理想环境的出现（这是一个代价的问题）。因此，我们支持研发花时间构建在线上系统诊断工具。这个系统原有一些简单的线上接口调试信息获取能力。但是对于初期诊断那些疑难问题还是信息不够。这部分也是通常所的「可观测性」。

我的同事付出努力，构建了一套相对完备的易于使用的线上系统诊断 inspect 接口，这位后续的诸多问题定位解决带来了极大的便利。

其次，该推荐系统的策略配置一堆json定义的组合配置，代码中需要解析这些组合配置动态构建出策略树，本质上是一个有向无环图的数据结构。这里的问题是配置的和代码之间的映射，如果单靠看配置是很难定位和诊断问题的。旧的工程师也开发了一个可视化的工具来呈现这个有向无环图，但是

这个问题一度是研发中的瓶颈问题。这个和前一节是一样的：在系统治理中，如果没有好的工具支持对全局信息或者局部重要信息的快速定位，它就会成为解决问题的瓶颈。

于是，我们写了一个策略配置的解析工具，将线性的配置，解析成符合实际代码嵌套的管道紧凑json，将有向无环图的骨架快速展示出来，便于定位和诊断，包含多种中间格式的数据。实际上这是一种复合利用文本解决问题的Unix风格做法。

在这里插入图片描述
图示是一个小的策略配置例子，具体信息对于系统研发来说有着具体的含义，这样的组合链路，如果繁杂起来但是没有便利的展示，用以快速定位到源代码中具体的类和配置，会十分费劲。

这部分，我们的经验是：投资工具，使得系统问题诊断能快速而直接，从而让研发循环周期更小。

我们在系统治理过程中，遵循一些原则使得系统逐渐更加简单可依赖：

这部分的工作。我们数据层的研发同事会有专门的技术博客分析，TODO：

但是我们在这个过程中，坚持持续的梳理所有的数据计算任务：

这层工作，核心是要体现：数据驱动。

大的系统治理，有一个麻烦的地方在于如何保持迭代周期。在工程上，有一个重要的原则是：“保持发布是硬道理”。如果某个工作，想的太多，想要改造的步伐太大，常常会导致系统在工程上不收敛，这是绝大部分研发都会遇到的问题。

不过我们通过一些策略，比较合适的规避了这样的问题。大概有这些方式：

有了大地图，使得我们能比较清晰地判断：
- “这是一个适合在数据层解决的问题”
- “这是一个适合在策略层解决的问题”
- “这是一个适合在聚合层解决的问题”
- …
有了工具，使得我们能在DAG部分的配置快速定位问题
- “根据这个链路骨架，出问题的应该是这个环节”
- “根据这个链路骨架，可以在这层加入特性解决问题”
- “根据这个链路骨架，这两层做的事情是冲突的，应该合并到一起”
- …
有了数据层的梳理，使得我们可以快速确认
- “快速找到数据的源头，检查数据源头是否有问题，如果能通过源头解决，中间就不要动”
- “数据层可以做更多的事情，提供更完备信息后，策略层就可以去掉一大块原来很绕的逻辑…”
- …