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