项目完成小结 - Django3.x版本 - 开发部署小结 (2)
前言
好久没更新博客了，最近依然是在做之前博客说的这个项目：项目完成 - 基于Django3.x版本 - 开发部署小结
这项目因为前期工作出了问题，需求没确定好，导致了现在要做很多麻烦的工作，搞得大家都身心疲惫。唉，只能说技术团队，有里一个靠谱有能力的领导是非常重要的。
进入正题
本文继续记录Django项目开发的一些经验。
本次的项目依然基于我定制的「DjangoStarter」项目模板来开发，该项目模板（脚手架）整合了一些常用的第三方库以及配置，内置代码生成器，只要专注业务逻辑实现即可。
数据批量导入
上篇文章说到我写了脚本导入大量数据的时候很慢，然后有网友评论可以使用bulk_create，所以在第二期的新增需求中，我处理完数据就使用bulk_create来导入，速度确实有了可观的提升，应该是能达到原生SQL的性能。
先把Model的实例全都添加到列表里面，然后再批量导入，就很快了。
写了个伪代码例子
result = data_proc()
data = []
for item in result:
print(f"处理：{item['name']}")
data.append(ModelObj(name=item['name']))
print('正在批量导入')
ModelObj.objects.bulk_create(data)
print('完成')
还有除了这个批量新增的API，DjangoORM还支持批量更新，bulk_update，用法同这个批量新增。
数据处理
上次需求很急的情况下，拿到了几百M的Excel数据之后，我直接用Python的openpyxl库来预处理成JSON格式，然后再一条条导入数据库
而且这些数据还涉及到多个表，这就导致了数据处理和导入速度异常缓慢
当时是DB manager直接把Excel导入到数据库临时表处理的，但是后面发现SQL处理的数据，清洗过后还是出了很多错误
所以后面来的新一批数据，我选择自己来搞，SQL还是不太适合做这些数据清洗~
直接用openpyxl来处理Excel也太外行了，Python做数据分析有很多工具，都可以利用起来，比如pandas。
这次新需求给的Excel很恶心，里面一堆合并的单元格，虽然是好看，但要导入数据库很麻烦啊！
不过还好pandas的数据处理功能足够强大，可以应付这种情况，然后为了整个数据处理的过程更直观，我安排上了jupyter，pycharm现在已经集成了，体验比网页版的好一点，不过实际使用的时候发现有一些bug，有些影响体验。
数据例子如下
第一列序号是没用的，不管，然后看到这里面姓名的人和家庭成员直接应该是一对多的关系，为了好看合并了单元格，这样处理的时候就很恶心了，合并后的单元格，pandas读取进来只有第一行是有数据的。
不过我们可以用pandas的数据补全功能来处理。
简单的处理单元格合并的代码参考：
import pandas as pd
xlsx1 = pd.ExcelFile('文件名.xlsx')
# 参数0代表第一个工作表，header=0代表第一行作为表头，uescols表示读取的列范围，我们不要第一列那个序号
df = pd.read_excel(xlsx1, 0, header=0, usecols='B:G')
df['姓名'].fillna(method='pad', inplace=True)
df['性别'].fillna(method='pad', inplace=True)
df['出生年月'].fillna(method='pad', inplace=True)
df['联系人'].fillna(method='pad', inplace=True)
df['联系电话'].fillna(method='pad', inplace=True)
代码里有注释，用fillna填充缺失的字段即可
然后再把DateFrame转换成比较容易处理的JSON格式（其实在Python里是dict）
json_str = df.to_json(orient='records')
parsed = json.loads(json_str)
这样出来就是键值对的数据了
PS：好像可以直接遍历df来获取数据，转JSON好像绕了一圈，不过当时比较急没有研究
参考资料
-
使用Pandas读取结构不良 Excel 的2个方法：https://www.shouxicto.com/article/1642.html
-
PANDAS合并单元格的表格读取后处理：http://zhangqijun.com/2733-2/
admin后台优化
定制化的项目其实Django Admin后台用得也不多了，不过作为报表看看数据或者进行简单的筛选操作还是足够的。
本项目的admin界面基于simpleUI库定制
从上一篇文章可以看到我对admin后台的主页进行了重写替换，效果如下
这个界面是用Bootstrap和AdminLTE实现的，AdminLTE这个组件库确实不错，在Bootstrap的基础上增加了几个很好看的组件，很有用~
然后图标用的font-awesome，图表用的是chart.js，都属于是看看文档就会用的组件，官网文档地址我都整理在下面了，自取~
有一点要注意的是，在SimpleUI里，自定义的主页是以iframe的形式实现的！而SimpleUI本身是Vue+ElementUI，所以想要在主页里跳转到admin本身的其他页面是很难实现的！这点要了解，我暂时没想到什么好的办法，要不下次试试别的admin主题好了~
参考资料
- AdminLTE：https://adminlte.io/docs/3.2/components/boxes.html
- FontAwesome：http://www.fontawesome.com.cn/faicons/
- Chart.js：https://www.chartjs.org/docs/latest/
- Django进阶(1): admin后台高级玩法(多图)
- Django实战: 手把手教你配置Django SimpleUI打造美丽后台(多图)：https://zhuanlan.zhihu.com/p/372185998
继续说Django的聚合查询
上一篇文章有提到聚合查询，但是没有细说，本文主要介绍这几个：
- aggregate
- annotate
- values
- values_list
根据我目前的理解，aggregate和annotate的第一个区别是，前者返回dict，后者返回queryset，可以继续执行其他查询操作。
aggregate
然后就是使用场景的区别，aggregate一般用于整体数据的统计，比如说
统计用户的男女数量
from django.db.models import Count
result1 = User.objects.filter(gender='男').aggregate(male_count=Count('pk', distinct=True))
result2 = User.objects.filter(gender='女').aggregate(female_count=Count('pk', distinct=True))
PS：其实这里的
Count函数里，可以不加distinct参数的，毕竟主键(pk)应该是不会重复的
这样返回的数据是
# result1
{
"male_count": 100
}
# result2
{
"female_count": 100
}
应该很容易理解
annotate
annotate的话，一般是搭配values这种分组操作使用，例子：
from django.db.models import Count
result1 = User.objects.values('gender').annotate(count=Count('pk'))
返回结果
[
{
"gender": "男",
"count": 100
},
{
"gender": "女",
"count": 100
}
]
简而言之，就是在values分组之后，annotate对数据进行聚合运算之后把自定义的字段插入每一组内~ 有点拗口，反正看上面的代码就好理解了。
values / values_list
最后是values和values_list，作用差不多，都是提取数据表里某一列的信息，(这俩都跟分组有关)
比如说我们的用户表长这样
| id | name | gender | country |
|---|---|---|---|
| 1 | 人1 | 男 | 中国 |
| 2 | 人2 | 女 | 越南 |
| 3 | 人3 | 男 | 新加坡 |
| 4 | 人4 | 女 | 马来西亚 |
| 5 | 人5 | 男 | 中国 |
| 6 | 人6 | 男 | 中国 |
我们可以用这段代码提取所有国家
User.objects.values("country")
# 或者
User.objects.values_list("country")
前者根据指定的字段分组后返回包含字典的Queryset
<QuerySet [{'country': '中国'}, {'country': '越南'}, {'country': '新加坡'}, {'country': '马来西亚'}, {'country': '中国'}, {'country': '中国'}]>
后者返回的是包含元组的Queryset
<QuerySet [('中国',), ('越南',), ('新加坡',), ('马来西亚',), ('中国',), ('中国',)]>
然后values_list还能加一个flat=True参数，直接返回包含数组的Queryset
<QuerySet ['中国', '越南', '新加坡', '马来西亚', '中国', '中国']>
这就可以很直观的看出来这俩函数的作用了。
然后结合上面的annotate再说一下，假如我们要计算每个国家有多少人，可以用这个代码
User.objects.values("country").annotate(people_count=Count('pk'))
结果大概是这样
[
{
"country": "中国",
"people_count": 3
},
{
"country": "越南",
"people_count": 1
},
{
"country": "新加坡",
"people_count": 3
},
{
"country": "马来西亚",
"people_count": 3
}
]
搞定~
聚合查询这方面还有很多场景例子，本文只说了个大概，后续有时间再写篇新博客来细说一下~
参考资料
- Python 教程之如何在 Django 中实现分组查询：https://chinese.freecodecamp.org/news/introduction-to-django-group/
- aggregate和annotate的区别：https://www.cnblogs.com/Young-shi/p/15174328.html
- values / values_list：https://www.jianshu.com/p/e92ab45075d5
- django_filter的values / values_list：https://blog.csdn.net/weixin_40475396/article/details/79529256
使用docker部署MySQL数据库
虽然之前看到有人说MySQL不适合用docker来部署，不过docker实在方便，优点掩盖了缺点，所以本项目还是继续使用docker。
继续用docker-compose来编排容器。
首先如果在本地启动一个测试用的MySQL，可以找个空目录，单独创建一个docker-compose.yml文件，配置内容在下面，然后运行docker-compose up。
下面的配置里我做了volumes映射，MySQL数据库的文件会保存在本地这个目录下的mysql-data文件夹里
version: "3"
services:
mysql:
image: daocloud.io/mysql
restart: always
volumes:
- ./mysql-data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=mysql-admin
- MYSQL_USER=test
- MYSQL_PASS=yourpassword
ports:
- "3306:3306"
使用ports开启端口，方便我们使用Navicat等工具连接数据库操作。
下面是整合在web项目中的配置（简化的配置，详细配置可以看我的DjangoStarter项目模板）
version: "3"
services:
mysql:
image: daocloud.io/mysql
restart: always
volumes:
- ./mysql-data:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=mysql-admin
# 注意这里使用expose而不是ports里，这是暴露端口给其他容器使用，但docker外部就无法访问了
expose:
- 3306
web:
restart: always # 除正常工作外，容器会在任何时候重启，比如遭遇 bug、进程崩溃、docker 重启等情况。
build: .
command: uwsgi uwsgi.ini
volumes:
- .:/code
ports:
- "80:8000"
# 在依赖这里指定mysql容器，然后才能连接到数据库
depends_on:
- mysql
关键的配置我写了注释，很好懂。
参考资料
- Docker-compose封装mysql并初始化数据以及redis：https://www.cnblogs.com/xiao987334176/p/12669080.html
- 你必须知道的Docker数据卷(Volume)：https://www.cnblogs.com/edisonchou/p/docker_volumes_introduction.html
关于缓存问题
上一篇文章有提到缓存的用法，Redis搭配Django原生的缓存装饰器cache_page是没啥问题的，但用第三方的drf-extensions里的cache_response装饰器的时候，就有个问题，不能针对不同的query params请求参数缓存响应
比如说下面这两个地址，虽然是指向同一个接口，但参数不同，按理说应该返回不同的数据。
但加上cache_response装饰器之后，无论传什么参数都返回同一个结果，目前我还没搞清楚是我哪里写错了还是这个库的bug~
性能优化
老生常谈…
上篇文章也说了一点，不过没有具体。都说DjangoORM性能差，其实瓶颈还是在数据库IO这块，在耗时最长的IO操作面前，那点性能劣势其实也不算什么了（特别是我们这种toB的系统，没有高并发的需求）
经过profile性能分析，瓶颈基本都在哪些统计类的接口，这类接口的特征就是要关联多个表查询，经常一个接口内需要多次请求数据库，所以优化思路就很明确了，减少数据库请求次数。
两种思路
- 一种是一次性把数据全部取出到内存，然后用pandas这类数据分析库来做聚合处理；
- 一种是做先做预计算，然后保存中间结果，下次请求接口的时候直接去读取中间结果，把中间结果拿来做聚合
最终我选择使用第二种方式，并且选择把中间结果存在MongoDB数据库里
小结
本项目到这里只是出了一个阶段性的成果，还是未完结，从这个项目中也发现了很多问题，团队的、自身的，都有。
团队的话，我们这的领导属于是不太了解技术那种，然后抗压能力比较差，平时任务不紧急的时候就不怎么干扰我们的进度，在项目比较急的情况下就乱套了，瞎指挥、乱提需求、乱干扰进度，总之就是添乱拖后腿…
当然最大的问题还是出在政企部门，前期在和客户的沟通中出了很大的问题，当然这可能和国企的架构混乱也有关系，甚至在协议方面也出了大问题，根本没有把需求写清楚，导致了交付后客户无限制地增加需求。
实际上一个政企项目涉及到太多非技术因素了，其实这本不是咱技术人员需要关心的，但现实就是这样，唉。
