汽车网站建设费用,js怎么做网站,网站微信支付怎么做,wordpress页面模板插件说明
记一次用算力机分布式完成任务的坑。
内容
1 背景
很早的时候#xff0c;做了一个实体识别模型。这个模型可以识别常见的PER、ORG、LOC和TIME几种类型实体。
后来#xff0c;因为主要只用来做PER、ORG的识别#xff0c;于是我根据业务数据#xff0c;重新训练了模…说明
记一次用算力机分布式完成任务的坑。
内容
1 背景
很早的时候做了一个实体识别模型。这个模型可以识别常见的PER、ORG、LOC和TIME几种类型实体。
后来因为主要只用来做PER、ORG的识别于是我根据业务数据重新训练了模型。
再后来因为在输入和输出端存在问题于是我做了函数链的封装。输入的问题例如字符串存在非utf8字符输出的问题例如主体识别会多一个字或者过短的实体。总之函数链封装之后看起来是一个整体。能适应当时业务的问题。
然后因为业务上的需求需要最快速度处理完900万篇文档。
顺带的我把数据存了clickhouse计算平均长度是3k。
2 过程
2.1 nginx反向代理
一开始采用在本地部署nginx反向代理然后租用算力机启动多个服务来进行分摊。这样只要填写租用算力机的IP:端口就可以横向拓展算力了。
实操时一方面要不断修改nginx的配置重启会浪费很多手工。另外发现由于租用机的网络会有抖动总体来说带宽大但不稳而当前设计每次处理耗时较长一旦出错时间就全部浪费了。
2.2 租用机本地服务任务
租用了算力机然后把本地文件同步过去。然后在租用的机器上启动3个服务然后通过脚本均匀分配任务执行。最后将结果回传写入。
过程中的第一个坑是文件传送。文件整体大小是25G, 按UCS的方式切分数据只有一个block(0.0.0), 其下有874个brick。在规划上是启动3台机器每台机器3个服务共9条线进行处理。在拷贝时本来是可以通过命令只传送每台机器对应的数据的但是一时间没有调好命令。时间又比较急所以用了笨办法将25G传到每台机器。然后就花了很多手工时间也花了1个多小时传送数据。
# 命令语句例子
123rsync -rvltz -e ssh -p 46717 --progress /home/data4T/news_data_1800w_batch2/left roots9vyc6vwjag1.com:/root/andy/回传结果rsync -rvltz -e ssh -p 46717 --progress roots9vyc6vwjag1.com:/root/andy/right/ /home/data4T/news_data_1800w_batch2/right/第二个坑就是启动服务修改服务文件然后写worker, player这种方式去手动的规划任务了。一方面真的浪费很多手工时间另一方面也浪费了很多处理时间。原来的设计就是server模式的这种方式更适合应对持续性的需求这次任务属于一次性的其实应该采取worker模式。从显存上看server模式会一直维持显存且可能不断增大所以只能开3个进程。如果是worker模式那么资源随用随放我认为开5个worker都没有问题所以模式的选择错误又浪费了计算时间。
2.3 其他
还有一些坑。
原来的服务把出具处理和实体识别包在一起了极大降低了显卡资源利用率。以后应当把资源耗用集中度也作为耦合设计的一个原则(原来只是考虑逻辑复杂性。
使用文件的方式不可取。一方面是涉及到的手工操作太多各种文件同步命令非常浪费时间。最近正好部署了clickhouse非常适合用于大文件的存取这也对应了UCS设计中的brick操作设计可以落地了。
使用数据库可以规范数据格式。本次在读取pkl文件的时候碰到ModuleNotFoundError: No module named pandas.core.indexes.numeric错误。大概是因为租用机的pandas、pickle版本的问题。所以后来不得不在本地进行数据的集成又浪费了很多手工操作。
最后在准备收集数据批量提交时我稍微修改了一下模式没有再回收文件到本地而是存到了clickhouse。然后再按照brick从clickhouse中读取分块存到postgres。
在存储数据的时候我倒是又想到了一个问题就是重复主键。如何避免主键的重复插入
一种通用的方式是批量的使用主键查询然后只插入差集。这些在WMongo都实现了只是新的库还需要重新适配开发一下
本次的解决方案是用meta记录brick按照brick进行批量的增删。
总结
如果再来一次我会把文件传到一个算力机然后建一个clickhouse,数据全部写进去。然后将任务写到队列中按照brick作为基本单位。然后租用更多的算力机每个算力机上启动n个worker。worker工作时到队列中获取brick然后根据brick从clickhouse中取数。处理完成后数据写到结果表。写表前根据brick判断是否可以插入。
这样的话估计手工的时间只需要2个小时整体跑数时间应该短于6小时。
其他
1 可能会因为连接不稳而导致处理中断。–不合适把租用机作为稳定的后端服务业源2 不要只考虑server模式也要考虑worker模式。 e.g. streamlit -- 前端 tornado -- api, clickhouse,rabbitmq -- worker3 大量传输数据还是很费时的传输25个G可能会要1个小时4 耦合设计资源集中度、逻辑复杂性5 使用数据库非常节约手工操作的时间6 使用clickhouse的整体感觉还不错7 不要小气在执行任务的时候不妨再租一个算力机做中转(带宽大)8 可能需要使用anaconda搭建虚拟环境(不是所有算力机都允许启动镜像
