2021年第四季度工作总结

thoughts
目录

第四季度的变化比想象中大很多，三个月过去我依然在适应新的环境，工作上面的进展很少。 在第三季度工作总结中我写了一堆牢骚，再来一次显然就不合适了。 新的一年在新的单位应该吸取教训，展望未来。就拿这篇总结当做对未来工作的思考吧。

计划完成情况

立 Flag 就是用来被打脸的，参见果壳儿网一篇文章《你的flag为什么总是倒？因为你把它说出来了！》。 第四季度的计划目标几乎都没有完成，可见我制定计划的水平实在堪忧，我在这三个月不知道都在忙些什么。

  • 青年基金项目
    • ❌ 完善产品制作示例，完成效率对比
    • ❌ CMA-PI 正确使用 Dask 集群
    • ❌ 技术文档
  • 技术总结
    • ✔️ 对过去五年工作进行总结和提炼
    • ✔️ 高工评审
  • 业务系统升级
    • ✔️ MESO 5.1 升级
  • 数据准备工具库 reki
    • ❌ CMADaaS 接口库 nuwe-cmadaas-python
    • ❌ 更多数据处理函数
    • 🚧 编写文档，❌ CMA-PI 示例
    • ❌ CMA-PI 测试 (✔️ PC 测试)
    • ✔️ 应用：尝试实现一种 ML 算法 (除 MOML 外)
  • 绘图脚本工具库 sokort
    • ✔️ Python 绘图脚本
    • ⏰ 加工流水线
  • 绘图包 meda
    • 🚧 业务系统图形
    • ❌ API 接口
  • 数据检查工具 nwpc-data-client
    • ❌ GO 模板
  • 工作流项目 takler
    • ❌ 重启

工作

职称评审

从 11 月 3 日接到通知开始准备申报材料，到 11 月 19 日提交材料，再到 12 月 3 日完成答辩，整个十一月 1 个月的时间都在准备高工评审相关材料。

总结文字材料请浏览文章《个人技术工作总结》。

一两周时间做的 PPT 在预答辩时才发现问题多多：

  • 没有突出亮点和创新点
  • 重点不突出，内容太多，讲得太快
  • 成效需要用明确的数字来表示，不能只用“效果提高”之类笼统表述
  • 样式太简单，不够美观

用 3 天时间对 PPT 进行全面修改，删掉没时间介绍的内容，挑选 5 项工作内容作为代表性成果，选取 4 项工作内容放入其他工作中一句带过，剩余部分全部删掉。

经过本次职称评审，发现我当前的工作存在不少原则性问题。 业务工作数量多、重复性强，在职称评审答辩的有限时间内，不可能将所有工作都介绍一遍，专家也不可能在短时间内就能了解所有工作。 我之前涉及（且半途而废）的技术方向太多，形成的成果太少，很多工作讲出来可能只起到负面效果。

关于职称评审的一些感想：

整合工作，将工作聚焦在一个完整的主线上，不要频繁切换工作方向。 大量分散的小工作项如同支线任务一样，无法得到有说服力的工作成果，在职称评审中连出场的机会都没有。 这并不是说不开展小型研发工作，不进行探索性研究，而是说要关注工作的延续性，让工作处于一个主要故事的范围内，尽可能将成果集成到主线任务中，积极主动将成果业务化，并在各类文件中留名。 对于我所从事的数值预报业务系统建设和运维岗位，一定要把握构建业务系统流程的优势，在提高稳定性、灵活性和时效性的指导方针下，抛弃稳定就是一切的观念，积极将新方法新技术新工具引入到业务流程中。 即使是尚在开发中的项目，也应该果断应用在业务系统中。 不要害怕出错，没有什么程序能一开始就是完美的。 只要持续更新，出现 BUG 时立即响应，也就无所谓了。

创新性工作，不要简单重复做同样的工作。 职称评审不看重数量，而注重质量，注重成效。 重复性工作做得再多，也只能算是一个工作成果，如果只是工作内容的简单重复，尤其是他人已经进行相同的工作，那就更没有上场的机会。 除非在重复工作之中寻找通用性的科学问题，并采用某种创新性方法或技术加以解决。 比如大家都在使用 NCL 绘制图片，都在使用 ecFlow 创建业务系统，如果想要在评审中体现这这类工作，那必须考虑这项工作与他人相比有什么创新性。 可以使用新的工具（或技术）来完成相同的工作，即重复造轮子；也可以从重复性工作中构建通用框架，即二次封装；再或者将工作重点放在其它更有挑战性更好讲故事的工作中。

业务向研发的转化，要将工作融入单位愿景，即数值模式研发工作。 业务工作面临的一大难题在于业务系统与研发实验的割裂，面向业务系统开发的技术难以应用到研发实验中，很难直接对模式研发工作起到支撑作用。 而研发支撑远比优化业务系统流程更接近单位的愿景，更容易被专家所了解。 因此一定要注重业务向研发的转化，推动业务系统中的技术方法在模式研发中得到应用。 不能再将业务和研发当成两个不相关的任务，而是将它们放在一个大框架中思考，确保所有工作必须都同时能用在实时业务系统和模式研发实验中。

以上仅是我的个人想法，职称评审与单位的指导方针密切相关，不排除未来想法有所改变。

业务系统

MESO 5.1 升级

11 月 CMA-MESO 业务系统正式升级为 5.1 版本，测试工作已在第三季度完成。 本次升级完成对区域数值预报模式产品进行整合，包括：

  • 停止 CMA-MESO 10KM 模式运行
  • 使用 CMA-MESO 3KM 图片产品代替 CMA-MESO 10KM 图片
  • 使用 CMA-TYM 数据产品代替 CMA-MESO 10KM 下发数据产品

经过调整后的 CMA-TYM 系统将全集 GRIB 2 文件发送给 CTS，由 CTS 抽取要素场形成 CMA-CAST 数据并下发。 这是我们第一个将核心下发产品制作拆分出去的业务系统，后续我们会继续进行类似的改造：

在 HPC 中只维护全集 GRIB 2 产品制作流程，将派生产品迁移到气象大数据云平台或由 CTS 负责制作。

对于上述方案，目前可以确定的优势有：

  • 简化 HPC 系统流程，保持 HPC 业务系统流程稳定，减少运维工作量
  • 符合业务系统融入气象大数据云平台的总体趋势
  • 拆分出去的产品流程更容易使用与运行模式积分流程不同的技术方案进行改造，更利于开展工程项目相关工作
  • 云平台上的业务系统方便引入第三方公司进行维护

值得讨论的劣势有：

  • 大数据云平台已有成熟的组件，无法重复开展底层基础设施技术开发工作
  • 产品制作从 HPC 迁出后，缺少一项可以在 HPC 上开展研发的重要领域：高效产品后处理技术

在系统升级工作过程中，越来越意识到当前产品后处理业务系统流程存在的各项问题：

  • 各系统相互独立，缺乏组件复用。比如绘制相同的区域图片产品总共维护了三套系统，包括绘图脚本、运行流程和运行脚本
  • 新增或删除产品不够方便，无法动态修改局部流程，需要重新调整后处理系统的整体流程，修改包括制作、上传等多个脚本
  • 2020年已将 CMA-MESO 系统的数据产品和图片产品制作拆分成两个系统，经过一年多的实践发现只是增加了维护工作量，而没有发挥应有的作用

后续应该持续优化产品后处理系统的运行流程，研究如何能更方便生成产品，尝试对现有流程进行重构，或者实验使用其他方式构建产品制作流程。

北京局备份

第四季度继续开展 CMA-GFS 模式在北京局备份运行工作。 完成 CMA-PI 远程连接北京局 HPC 上 ecFlow 服务的测试，并调整作业调度系统相关脚本，完成 CMA-GFS 后处理系统的迁移。

做工作需要探究精神，遇到困难不能退缩，必须迎难而上，绝大部分困难都只是暂时的。 北京局 HPC 上 ecFlow 的 modulefile 名称是 ecflow/5.6.0，我在第三季度没找到 CMA-PI 上连接 ecFlow v5 版本的合适方法，将备份工作搁置一旁。 第四季度在底线思维指导和敦促下，继续寻找连接 v5 版本的方法，尝试各种不同编译版本的 ecFlow UI 客户端，均无法连通。 最终发现，仅需要执行一条命令 ecflow_client --version 就能发现 ecflow/5.6.0 里面装的其实是 4.11.1 版本。 之前以为的困难原来都是想象出来的，只要有严谨的科学态度，不难找到解决问题的方法。

在迁移过程中，明显发现当前产品后处理系统的运行流程缺乏可移植性，对流程的封装程度严重不足。 无论是删减产品，还是匹配新的队列调度系统，都需要进行破坏性修改。 如果业务系统只是在一台 HPC 上运行，破坏性修改没有问题，但如果业务系统需要在多种环境中运行，就需要对运行流程进一步整合和封装。

后续应该考虑设计通用的运行流程框架，编写可搭配可拆卸的组件，提高流程的可移植性。 不过，开展这项工作的前提是有明确的需求，并且能与部门的其他工作整合到一起，比如：

  • 在超算分中心上搭建异地备份系统
  • 研发试验和业务流程使用同一套运行流程
  • 向用户提供产品定制功能

如果对运行的需求仍然保持现状，那么重构流程的工作内容也会相应调整，避免过度优化带来额外的复杂度。

项目

青年基金课题

第四季度在课题方面既没有优化现有测试用例，也没有撰写技术文档，仅是意识到应该使用 MPI 编程实现已有的测试用例，尝试使用不同的技术来实现分布式计算。 在 12 月底，对 CMA-MESO 1KM 后处理中应用的 Dask 计算方案进行测试，减少数据交换操作，但效果不是很明显，需要进一步测试对比。 但第四季度依然没有解决 Dask MPI + Slurm 在结束集群时的报错信息，没有解决启动耗时过长的问题，尝试使用 pyinstaller 封装也失败了。

后续将继续研究基于 Dask 的分布式计算技术，对于已实现的测试用例进行多角度的效率对比。 同时深入阅读 Dask 文档，结合业务系统中的产品制作任务，总结技术要点，形成技术文档。 如有空闲时间，应该学习并行编程技术，提高个人技术能力，持续学习：

  • MPI
  • threads
  • OpenMP
  • CUDA
  • OpenCL
  • …

信息化系统工程项目

继续推进信息化系统工程项目项目，参与多个节点：

  • 合同签订
  • 项目启动会
  • 需求分析和概要设计评审

继续申请天擎账户，为工程开发做准备。

后续开发任务卡在三个地方：

  • 模式实时基础数据在天擎中推送的目录
  • 如何获取数据推送完成后的通知消息
  • 开发公司如何合理合规使用天擎账户

2022 年第一季度将联系各部门解决上述三个问题，春节前争取在天擎加工流水线上实际部署一个绘图算法并测试，在第一季度结束时完成一个完整流程的测试。

这项工作是数值预报业务系统融入气象大数据云平台的标志性任务，也是我入职以来参与的对业务系统运行流程进行的最大规模改动。 任务的运行方式将从 单一HPC调度 转变为 HPC + 云平台协同调度。

业务系统建设和维护会面临严峻的挑战：

  • 我们将面对全新的环境，原有 HPC 上的开发和维护经验能否应用到气象大数据云平台中
  • 我们需要监控两个平台中的业务系统，如何能最大限度减少维护工作量，是否可以将云平台中的系统外包运维

同样也是时代的机遇，新的平台会带来新的技术，也提供了变革的绝佳机会。

只有顺应历史潮流，积极应变，主动求变，才能与时代同行。

—— 习近平总书记在庆祝改革开放40周年大会上提出的这一重要论断

但对于这项工作还有一些问题有待进一步思考。

顺应潮流者与时代同行：气象大数据云平台到底是不是未来数值预报模式产品制作的唯一基础平台？ 未来的产品制作任务是否依然还会在 HPC 上运行，是否研究并行计算技术用于产品制作。 云平台当然是目前的潮流所在，我们必须在 2023 年之前完成业务系统融入工作。 但也应该关注国际同行在 HPC 上的发展方向，毕竟 HPC 上的开发工作是我们单位的基本盘，我们对 HPC 中不需要管理员账户权限的应用软件具有绝对控制权。

合作与竞争：在气象信息化领域里，如何在已有的标准、规范、平台、基础设施中寻找前进方向。 我一直对向气象大数据云平台靠拢持保留态度。 即使今天来看，融入气象大数据云平台已是大势所趋，我依然认为应该将天擎当成提供类似云服务商的基础设施组件提供方，我们开发的信息系统不应该与天擎深度绑定。 可以对天擎提供的各项服务进行二次封装，将天擎当成与 HPC 一样的计算基础设施，以便业务系统支持调度到多个平台中运行。 比如，使用云平台提供的数据库和数据模型实现模式数据管理，而不是直接使用其他单位搭建的模式数据库。 这其实就是如何在融入工作中体现个人贡献的问题。

个人贡献：如何体现个人创新性工作成果。 仅仅将产品制作任务放到加工流水线上运行，只能说是完成了工作职责。 即便使用 Docker 容器技术对任务进行封装，也远远算不上是创新性工作，因为这只是在加工流水线已提供的功能上进行的简单开发，而且大院里其他单位也都采用相同的技术路线。 需要跳出后处理任务迁移的视角，从数值预报业务系统的整个运行流程出发，思考融入工作如何能为提高预报产品质量和提升预报产品时效性做贡献。 再从整个中心的工作内容触发，思考融入工作如何能为模式研发、诊断评估、机器学习等研究工作提供技术支撑。

工程项目：如何定位工程项目？怎样利用工程项目才能帮助个人成长？ 这两个问题我一直没有合适的答案，我对于工程项目的管理也一言难尽。 从这两天西安一码通的后续新闻《西安市大数据资源管理局局长刘军履职不力被停职检查》来看，工程项目绝对不能做甩手掌柜，尤其是用于实时运行业务系统的项目，出问题是要担责的。 而我们常用的技术不能完全覆盖工程项目通常使用的技术路线（主要是 Java），所以厘清工程项目的定位很有必要：

  • 是否只需要提供项目需求和设计思路，具体实现由工程项目承建方来实现
  • 是否为自研技术和引进技术划出明确的界限，核心组件是否需要全部自研
  • 如何提高各个工程项目之间组件的复用率，减少重复建设，将多个项目的成果集成到少量的平台中

注：以上想法仅是我对天擎不够了解时的想法，不排除后续想法会改变。

工具

数据准备工具 reki

第四季度没有开发新功能，而是朝着标准开源项目而持续开发。完成任务包括：

功能测试可以当成 API 说明文档，可以用于保证每种调用方法都能符合要求。 成体系可以自动运行的测试用例远比修改外部测试代码并手动执行更有效率。 正是通过编写测试代码，发现工具库中部分 API 的 BUG 并加以修正。 根据功能测试可以进一步编写详细说明文档。

后续计划继续完成第四季度尚未实现的任务，包括开发 CMADaaS 检索工具库，编写 CMA-PI 上可运行的测试用例，按需求开发新功能，争取将该工具推广到单位的机器学习和诊断评估工作中。

绘图脚本封装工具 sokort

对 sokort 进行少量更新，完成任务包括：

  • 更新架构，支持 CMA-GFS 新增的 Python 绘图脚本
  • 添加新图形，包括 GFS 为 WMC 绘图，以及 MESO 3KM 的两张图片
  • 发布 pip 包，浏览 https://pypi.org/project/sokort/

至此，确定性预报模式后处理系统中的绝大部分简单绘图任务 (不使用中间数据) 已经整合到 sokort 中。 由于集合预报模式的特殊性，产品制作专业性较强，绘图任务较多涉及数据计算，我暂不打算将集合预报的绘图任务整合到该工具中，期待后续工程项目能解决整合问题。 我认为未来绘图脚本适合使用 Python 来实现，所以封装 NCL 脚本的 sokort 工具仅是过渡时期的产物，未来还是应该开发基于 Python 的绘图包。

后续计划依托信息化工程项目，将该工具 Docker 镜像部署到加工流水线上，对接天擎上的数值预报模式基础数据文件库。 同时将 WMC 相关的两个绘图系统切换为 sokort 实现。

绘图包 meda

第四季度没有开发 meda 库，仅在为年终总结准备图片素材时进行细节微调，修正了几个 BUG。

下一步计划尝试开发适合科研需求的 Python 绘图包，并计划从明年开始集众智开发适应业务需求的绘图工具，在未来 2 到 3 年时间内逐步替换业务系统中的 NCL 和 GrADS 绘图脚本。 争取让新的 Python 绘图包成为单位的标准组件，应用到其他项目，尤其是 Python 项目中。

其他工作

第四季度做了一些事务性工作，包括工作计划、数据分级、项目总结等，未来会参与更多事务性工作。

回顾全年，年初制定的一些计划没有落实到位，比如业务系统建设小组流于形式，运维技术交流停在一半，与我推动不积极有直接关系，需要加强在组织管理方面的能力。

思考

仅为一篇论文和一个报道撰写笔记：

《论文阅读：面向天气和气候数据的可扩展对象存储》

《视界：在EuroHPC ACROSS项目中推进高性能数据管理》

之前写的“论文阅读”和“视界”文章几乎都是全文翻译，按照《卡片笔记写作法》书中的说法，全文翻译没有用处，需要用自己的语言描述对文章的理解。 我写笔记太慢的一个原因正是对全文摘抄太耗时间，仅保留自己认为的最核心的部分即可。 后续会逐步改变记笔记的方法，提取核心内容，提高阅读效率，增加阅读广度，加强对科学问题的思考。

总结

perillaroc at GitHub 2021.Q4

第四季度主要了两项工作：

  • 11月参评副高级职称
  • 12月为 reki 库编写测试和在线文档
  • (10 月不知道在做什么)

第四季度耗时最长的工作就是职称申报。 职称改革导致延迟一年申报，多一年工作总会有一些优势，但我依然感觉压力巨大，尤其是预答辩时专家批评和建议让我深刻意识到当前工作方式存在严重问题。 尽管职称评审在淡化论文的重要性，但始终强调工作的创新性和对单位的贡献。 对于大量简单的重复性工作，如果没有提炼出科学问题，就谈不上创新和贡献。 频繁切换研究和开发方向也很难做出有代表性的成果。 技术总结则是能将小工作汇总成大成果的一个途径。 这些都是我后面应该注意的事情。

第四季度第二项工作就是为改名后的 reki 库编写测试代码和在线文档。 想要开发可以推广应用的工具库，必须提供详实的帮助文档和应用示例。 想要约束规范开发过程，则需要编写测试代码。 这两项工作都是费事费力的任务，但从长远发展来看，收益非常大，值得投入精力去做。

一个需要注意的地方体现在业务系统更新维护工作上。 我本应在第三季度就该解决 CMA-PI 连北京局 HPC 上 ecFlow 的问题，结果我在遇到难题时没有用心研究，没有从各个角度进行实际验证，导致该项工作停滞不前。 从 2021 年多次系统升级来看，我在更新业务系统时没有进行全面细致地检查，出现多次不应该出现的更新 BUG。 这就涉及对工作的态度问题。 无论我本人对运行维护工作有何种看法，但工作岗位的基本职责必须要严格遵守，作为技术人员也应该保持自己的职业精神和职业道德。 未来我应该时刻谨记工作职责，以严谨的态度对待每一项工作。

第四季度应该做而未完成的一项工作是对未来工作方向的思考。 不光要思考个人的前途，也要思考我们团队的奋斗目标。 应该借鉴各类规划指导文件，制定五年规划，确定发展的大方向，并绘制路线图。 这需要充分的调研，反复的思考，也需要决断的魄力，希望我在 2022 年第一季度能有个明确的方案。

下一步计划

核心任务

  • 青年基金课题
    • 应用：完善业务产品示例，对比运行效率 (四季度延后)
    • 文档：总结核心思想和关键技术，撰写技术文档 (四季度延后)
    • 实验：学习并行计算技术，使用 MPI (或 threads) 实现业务产品示例并与 Dask 版本对比
  • 模式要素库 (推动 + 参与：基于数据平台已有成果)
    • 调研：研究 cfgrib 索引存储，研究 FDB 索引文件
    • 元数据：设计键值对形式的 GRIB 2 元数据规范
    • 索引：针对本地 GRIB 2 数据文件的本地文件形式索引 (reki)
    • 接口：从索引文件中读取要素场的接口原型 (reki)

一般任务

  • 产品制作融入天擎 (参与，工程项目)
    • 数据：完成模式基础数据在天擎的准备工作
    • 算法：在加工流水线上部署并测试一个绘图算法 (sokort)
    • 流程：完成从数据检测到图片绘制的整体流程测试
  • 后处理系统流程
    • 脚本：优化 GFS、MESO、TYM 后处理的 ecFlow 运行脚本，统一脚本编码风格
    • 框架：尝试整合后处理系统流程，初步形成简单的通用框架，方便添加新产品

技术开发

  • 数据准备工具库 reki
    • 文档：编写详细说明文档，保证示例在 CMA-PI 和 PC 上均可用
    • 测试：完善测试用例，在 CMA-PI 上测试
    • 数据来源：完善 CMADaaS 数据检索库 nuwe-cmadaas-python，设计多重配置文件，实现常用检索功能
    • 数据加载：增加 GRIB 2 数据索引功能，与模式要素库结合
    • 数据处理：增加更多数据处理操作
  • 工作流软件 takler
    • 重启 takler 开发
    • 架构：使用 GOLANG 实现
    • 功能：简单顺序流程，无人工控制
  • 绘图封装工具库 sokort
    • 应用：替换 WMC 相关绘图系统运行脚本
    • 部署：创建 Singularity 镜像
  • 数据检查工具 nwpc-data-client
    • 新功能：支持 MODELVAR 并发检测拷贝，串行修改数据进度

其它任务

  • 绘图包 meda
    • 设计：设计绘图 API 接口，函数组 vs 一键式
    • 功能：支持中国分区域图片
    • 测试：绘制部分业务系统图形

祝福

没想到这篇文章写了 10 天才写完。

最后以毛主席的一首词鼓励自己，祝愿我在新的一年继续努力工作，为单位做出自己的贡献。

西风烈，长空雁叫霜晨月。霜晨月，马蹄声碎，喇叭声咽。

雄关漫道真如铁，而今迈步从头越。从头越，苍山如海，残阳如血。

—— 毛泽东《忆秦娥·娄山关》(1935)

参考

《2021年第三季度工作总结》