三十岁以前的往事（十三）：持续进化

continue envolving …

• 工作
  • 建库标准化工作，存量库种汉语、bank 混合库、音乐迁移及业务需求支持。库种所涉及的业务细节这里不详细介绍了，主要想简要概述一下对新架构的一些理解
    • 数据引入：老架构中人工编码了大量的 trick 逻辑，分散在老引入和老计算系统模块中，不利于维护。在新架构中，将这部分逻辑从计算模块中拆分出来，通过配置来进行明确定义
      • 数据是从哪里来的：消息队列？列存储？RPC？
      • 原始数据的格式，pb？json？ulpack？
      • 数据类型，走 json schema 校验；架构 c++ 库统一注册和管理数据类型，从简单的 c++ 类型到复杂的自定义数据类型，自己实现序列化和反序列化接口，各模块通过 lib 的形式联编这个 c++ 库。
    • 数据计算：
      • 老计算系统模块中，如果想新增一个由业务算子产出的数据，流程大概是这样的：
        • 首先先在平台网页上注册算子名称、输入输出字段、算子所属代码库等算子基础信息。
        • 然后在平台网页上注册数据，需要填写产生这个数据的算子名称，也就是第一步注册的算子，以及这个算子输入的字段对应的数据，这些数据都需要在平台上注册过。
        • 最后，由一个编排脚本根据数据血缘关系生成计算系统的配置，包括计算拓扑和算子配置，由架构 rd 将配置同步到计算系统模块代码库，编译后上线。
      • 这种方式看似非常理想，一个平台可以管理所有的数据以及数据间的血缘关系，并可以根据这些信息自动生成计算系统的配置，但是在实际使用过程中，存在一些问题：
        • 由于缺乏亲民的文档说明，架构师对于数据管理的设计思想没法传递给一线架构 rd 以及业务 rd ，导致很多数据注册的不规范，生成的计算系统配置不符合预期，最终部署前往往需要人工调整，甚至出现过由于计算拓扑生成存在问题，部分数据生成失败，导致线上事故。
        • 如果有需求需要注册二十个数据，那么就需要在平台页面上操作二十次，且数据注册的流程较长，效率低下。尤其是去年部分库种从更老的系统往这个系统做迁移时，需要注册百二十个数据，当时只能找平台的同学开放平台 api 接口以及平台数据库表权限，通过脚本来完成批量数据注册。
      • 对于新架构来说，对于整体的建库通路来说，计算系统是一个黑盒，当前只用明确计算模块的输入和输出格式、字段、类型即可。中间的计算方式由计算系统自定义，灵活度较高。当前有两套新计算系统，一套完全适配老系统算子，支持 c++ 算子以及 python 算子，c++ 算子通过 so 加载，python 算子通过 pybind 加载，算子代码、配置和计算拓扑配置托管在库种独立的业务代码库，这套主要是用来承接老计算系统中包含业务算子较多的库种；另一套会将业务算子作为静态库联编至计算系统中，只支持 c++ 算子，所有库种的算子代码及配置托管在架构计算系统代码库中，计算拓扑根据数据血缘关系自动推导，一般新业务或者老计算系统中算子较少的业务会走这套系统。
    • 数据生效：
      • 老架构中，数据生效配置存在多种模式，包括：
        • 在架构模块中，业务编码配置生效方式。
        • 在架构代码库中，业务提交生效配置。
        • 在平台上，业务在网页上填写生效配置。
      • 对于建库架构来说，数据生效配置的分散不利于一个库种的数据生效有一个整体的视角，维护难度大。新架构中，均通过配置明确定义，某个数据生效到哪个容器中，正排？摘要？索引？消费队列？等。配置托管在一个独立的配置代码库中，生效方式由统一的建库模块完成。
    • 配置管理：
      • 从前面三个部分的配置可以看出，老架构中配置分散，管理困难，没有统一的规范和标准。在新架构中，所有建库配置均托管在独立的配置代码库中，架构师对于建库中涉及的各个方面进行了抽象，新架构下业务提交的配置本质上就是对数据的描述，主要包括数据引入（从哪里来）和数据生效（到哪里去） ，而建库中涉及的各个架构模块通过自己的脚本将这些配置转化为模块本身的配置，在业务合入配置后，由流水线触发各个架构模块的脚本执行，最终生成的各模块的配置也托管在代码库中的分支上。这些配置均采用 json 格式，每一个配置项均有对应的 json schema 定义，在提交配置时会进行 json schema 校验。在建库配置里，对于数据描述的配置由架构师把关，各模块的配置由各模块的 owner 负责。
      • 全部采用以 json 格式的纯文本化配置带来的优势，作为 rd，我对以下几点有明确的感知：
        • 在老库种往新架构迁移时，方便使用脚本批量生成数据配置，效率很高。
        • 可以使用 json diff 工具比较一次变更前后，最终生成的数据配置和各模块配置有哪些变更。
        • 通过阅读 json schema 即可知道一个配置的大概功能，无需维护额外的文档，并且由于 json schema 校验的存在，可以大大降低配置填错的风险。
      • 虽然架构师对于系统和数据的抽象已经很完善了，然而免不了还存在一些特殊的业务场景无法用当前的配置进行描述，只能在模块层面编写 trick 代码逻辑进行适配，不过和老系统比，数量少了很多。目前的主要工作还是以存量库种迁新架构为主，配置的机制，例如测试流水线以及预上线环境，建设的还不完善，例如在跑测试流水线时，存在因为数据未对齐而造成的非预期 diff ，不过随着去年一年迁移工作的收敛，机制优化的工作也会逐步提上日程。
  • 离线中间件模块，mongo 和 kafka，主要负责维护工作：
    • 对于 kafka ，影响最深的线上问题在另外的博文中也有介绍，就是 kafka controller 启动失败的问题以及业务频繁请求 kafka 导致其 gc 时间暴涨的问题，排查的过程还是挺有意思的（但是查了三四个小时）。
    • 对于 mongo，今年上半年给各集群把 iptable 白名单都加上了，结了安全漏洞工单，这个工单我从 22 年就开始延期了。后续业务必须通过一个 http restapi 来访问 mongo ，或者申请给服务或者物理机添加 iptable 来直连 mongo 。我额外在一个物理机上搭了一个 23 年没完工的 mongos proxy ，供业务临时连接 mongo 使用，它本质上就是一个实现了 mongo 的协议 tcp proxy ，在收到业务请求后，将其转发给对应的 mongos 服务。
  • 效率：
    • 开始尝试在工作中使用大模型的能力处理一些问题，例如给出需求描述让大模型来生成代码片段，效果非常不错。公司内部有平台集成了各大主流大模型的服务，每天的 token 很足，可以直接白嫖。
    • 使用滴答清单来托管工作和生活中的代办项，减轻大脑的记忆负担。对于一个项目，现在会在滴答清单里建一个独立的清单，拆分子任务注册到清单里，添加任务描述及目标，并配置 deadline 提醒。
• 生活
  • 运动：
    • 恢复了撸铁，工作日晚上会抽时间，周末会在下午
    • 身高体重：179cm / 76.5 kg
    • 杠铃卧推 80kg 6/6/5/4/4
    • 上斜哑铃卧推 30kg 6/6/5/4
    • 杠铃深蹲 95kg 4/4/4/4
    • 硬拉 120kg 6/5/4/4
    • 杠铃推举 55kg 6/6/5/4
    • 杠铃划船 90kg 6/6/6/5
    • 15kg 负重引体 6/6/6/5
  • 游戏：
    • 戒掉了星际酒馆，但还会看游戏直播和视频
    • kingdomrush5、thronefall、making lovers
  • 院线电影
    • 《沙丘2》、《异形：夺命舰》、《间谍过家家 代号白》
  • 学习：
    • 周末来公司看会书
    • 《乔布斯传》、《小米创业思考》、《清醒思考的艺术》、《沙丘》（二刷）、《设计数据密集型应用》
  • 常用设备：
    • 手机：iPhone 15 Pro（新增，替换 iPhone 11）
    • 电脑：MacBookPro M2 13寸（公司）、MacBookPro M3Max 16寸（个人）
    • 耳机：AirPods Pro 2
    • 笔记：Obisdian ，其它调研中，例如 logseq
    • 日程：滴答清单
    • 阅读：微信读书
    • 浏览器：Arc
    • AI 助手：GPT4、Claude3.5
  • 一些软件的年度总结
    • B 站 年度 UP 主：影视飓风
    • 网易云音乐 年度音乐人：ClariS
    • 招商银行 年度收入增加 15% ，存款增加 30%
• 总结
  • 对于数据处理系统如何管理数据有了一定的理解。熟悉了 c++ 代码的编写。
  • 身体力量有所增长。有一定的知识摄入。对于知识的管理方式有了一定的思考和优化。
• 未来
  • 在工作方面，熟悉业务、打好基础，前者是为了能更好地完成当前工作，后者是为了可以随时寻找新的工作机会。目前已经工作了 2.5 年了，新的一年暂时苟着，但是不排除换工作的打算，不过概率很低。
  • 在生活方面，坚持运动和读书，尝试新的模式，例如借助 AI 来学习新知识、通过新模式来记录和管理知识等。