2022年算法工作总结

文章目录

• 1. 批处理的效率的提升
• 2. 不要手动分析数据
• 3. redis 不适合存储非常大的数据量
• 4. hive 查询效率
• 5. 内存不足问题
• 6. 端到端的测试、报警
• 7. 学习
• 8. 感谢

总结下2022年工作中的收获

1. 批处理的效率的提升

这是常识，但是还是踩过这些雷

• 一个NLP分类项目中，GPU在推理的时候没有采用批量输入，效率很低，需要批量输入，同时注意同一个批次内句子的最大长度不要太长，不然占用GPU存储会比较高
• ES写入时，没有使用 bulk 批量接口，速度太慢，需要使用 批量接口（缩短写入时间），同时配合 生成器作为输入（减少内存占用）

2. 不要手动分析数据

分析用户特征和留存的关系时，使用了 dtale 这个包来手动分析，这个包可视化还挺好的，但是我面对的是很多种组合分析，手动点鼠标要累死我啊

后面果断放弃，使用 pandas groupby 分组 + agg 聚合 + 聚合函数，写代码一劳永逸，省时省力

3. redis 不适合存储非常大的数据量

做一个demo项目展示，我不懂前端，用的最原始的 html 模板 + jinjia渲染模板 + FastAPI框架，用户请求时，根据表单输入去 redis 里 get 数据

demo 打开了大家的思路，大家说想要看更多的时间段的数据，redis 存储不下了，消耗的内存非常大，咨询大数据的同事也说，这是不可行的，内存很贵的，推荐我使用 ES 存储，ES可以弹性伸缩，存储是放在磁盘里的，磁盘存储很便宜

4. hive 查询效率

• 查询条件中避免 in (里面一大堆具体的数值)，sql 可能有长度限制，查询效率也低，不过 in 本身的效率就低，也要减少使用
• 多表 join 之前，先对单个表把需要的字段和数据单位用 where 限制住，尤其是有分区的表，把分区 指定好，减少数据的规模，查询效率会高一些。不然hive查询非常慢，还说不定告诉你 hive 节点内存不足，查询失败
• 尽量使用 group by 去重，而不是 distinct
• hive 查询失败了要有重试机制

5. 内存不足问题

• 数据去重时，内存不足，程序崩溃，采用某个去重数字字段的后几位分桶，分别在桶内去重（分治）
• 处理业务问题的时候，直接一股脑的都一起处理了，内存爆了，思考下业务段之间有没有互相的逻辑上的交叉，没有的话，分治处理（分年份、分年级处理）
• 完成任务后有一个快照线程未被手动销毁，造成内存泄漏

6. 端到端的测试、报警

• 选数据源时，如果有多个表AB可以选，有没有别的表可以验证数据正确性，抽样数据看看AB哪个更准
• 端到端的测试，上游产生了多少数据，经过我们的处理后，生成了多少新的数据以及数据是否正确，中间有各种环节的错误数据被丢弃，监控这样的数据比例，发送消息到工作群

7. 学习

今年学习（抄书）不多，陆续抄了些 pyqt、react、python高性能方面的、Rasa、Es 方面的知识，单就书而言，都没有完整系统的学完，也没有实践经验

深度学习方面跟进的不多，仅限于看看公众号的文章，不深入，也没有实践代码

8. 感谢

• 感谢家人的支持和理解，程序员下班比较晚，平时陪伴时间比较少，努力分配好工作和生活的时间
• 感谢军哥对我的指导，面对工作上的压力时，告诉我方法和路径，感谢邹老师在技术上给我的支持