- 博客(761)
- 资源 (16)
- 收藏
- 关注
原创 Andy系列文章序
说明博文写的面比较杂,这里做一个汇总梳理1 Python实现决策树更确切的说是「Python实现树族算法系列」。使用Python实现CART决策树,并基于此实现GBDT,Random Forest , XGBoost等模型开始页面:Python实现决策树(系列文章1)–从最简单的算法开始2 Python 函数字典系列这里指的是一种自定义的函数方法。将函数都作为某个字典可以引用的键值,然后可以使用参数化的方法调用链条比较长的函数。未来这部分会打包,以包装其他普通函数的方式来充实里面的函数。
2020-06-07 22:39:33 796 1
原创 Python 全栈系列258 线程并发与协程并发
1 协程用于worker级别,务求在单核上达到最高的IO并行2 线程用于player级别,确保多核并发worker3 除了主要的等待,开头和结尾可能还是有CPU开销。(至少json序列化也是常见的)
2024-07-07 23:11:45 879 1
原创 Python 算法交易实验76 QTV200日常推进
最近实在太忙, 没太有空推进这个项目,我想还是尽量抽一点点时间推进具体的工程,然后更多的还是用碎片化的时间从整体上对qtv200进行设计完善。
2024-07-07 11:05:02 476
原创 Python 算法交易实验75 QTV200后续想法梳理
在第一步获取数据源,然后进入Mongo(第一个数据节点)开始,QTV200的数据流体系就开始动了。后续用多少时间完成不太好确定,短则数周,长则数月。毕竟有过第一版实验的基础,应该还是可以做到的。下面就是天马行空,简单的想想,梳理一下,后续会更清楚写。
2024-06-30 14:54:43 781
原创 Python 算法交易实验74 QTV200第二步(改): 数据清洗并写入Mongo
之前第二步是打算进入Clickhouse的,实测下来有一些bug可以看到有一些分钟数据重复了。
2024-06-29 18:59:41 765
原创 Python 算法交易实验73 QTV200第二步: 数据清洗并写入ClickHouse
先检查一下昨天启动的worker是否正常工作,然后做一些简单的清洗,存入clickhouse。
2024-06-27 23:05:38 558
原创 Python 算法交易实验72 QTV200第一步: 获取原始数据并存入队列
最近的数据流往前进了一步,我觉得基本可以开始同步的推进QTV200了。规划了整体的数据流,现在开始第一步。
2024-06-23 22:44:58 943
原创 Python 全栈系列256 异步任务与队列消息控制(填坑)
每个创新都会伴随着一系列的改变。在使用celery进行异步任务后,产生的一个问题恰好也是因为异步产生的。
2024-06-22 12:01:04 704
原创 Python 全栈系列250 数据流实践
总算把这部分搞完了,实在有点长。总体上,实现了较为便捷的搭建方式,即使是新主机上也可以很快的部署配置。1 我会基于此,构造一个随时可启动的Stream,方便后续的逻辑接入2 对于某一项具体的工程,肯定是先构造数据流模型,然后使用这部分工具完成默认的连接。Stream2Stream通常可以用于跨主机间的数据共享,而 Stream2ClickHouse肯定是比较重要的一种数据持久化。之后还需要补充一些,例如Stream2Mongo,或者反过来,Mongo2Stream。
2024-06-12 00:09:05 1181
原创 Python 算法交易实验71 QTV200数据流设计
结构作为工程的基础,应该在最初的时候进行合理设计。这一次版本迭代,我希望最终实现的效果,除了在财务方法可以达到预期,在工程方面应该可以支持长期的维护、演进。
2024-06-10 09:23:24 907
原创 Python 全栈系列249 IO并发:异步、线程与协程
很久没有关注这方面的问题了,平时大部分时候还是做批量操作。在这种情况下(CPU密集),异步、协程这些意义就不大了,甚至可能进一步拖慢处理时间。但是在IO这一块的零碎处理是比较重要的,可以更快,且更省资源。很早的时候,曾经在执行规则引擎之前要分布的从mysql取数,结果处理时间特别慢;后来改用了asyncio和aiomysql,速度大幅提升,这给我了很深的印象:什么资源都没加,速度就是快了。后来我主要还是集中在批次处理数据下,每次都是万条的密集操作,这时候主要就用数据库本身的功能;
2024-06-05 21:48:12 651
原创 Python - 深度学习系列38 重塑实体识别5-预测并行化改造
一个在理论上证明可以显著提升效率的点在于,模型进行实体识别时先切分了短句,然后按短句进行了去重:相同短句的实体结果一定是相同的。实验中,200条新闻产生了约5万个短句,去重后只剩下约3.5万。所以即使在这一步也是有提升的。当然,这种方式同样也可以被用于pipeline。还有就是在处理填充时,并不按照最大长度统一填充。而是按照句子长度的统计特性分为了短、中、长三种方式。从统计上看,约70%的短句长度是在20个字符以内的,真正超过50个字符的短句(中间无分隔符),即使从语法上来看也是比较奇怪的。
2024-06-04 10:21:14 630
原创 建模杂谈系列244 TimeTraveller
所有的基于时间处理和运行的程序将以同样的节奏同步和执行TT(TimeTraveller)是一个新的设计,它最初会服务与量化过程的大量任务管理:分散开发、协同运行。但是很显然,TT的功能将远不止于此,它将服务大量的,基于时间游走特性的各种任务。
2024-06-02 21:01:15 925
原创 Python 算法交易实验70 简单回顾
感觉停滞了一段时间,本来qtv200应该在去年12月就迭代好了。从总体上,我对于qtv的想象是没有太大变化的,如果模糊的形容,qtv应该是运行在一个强化学习框架之下,会根据实际情况自动调整策略;qtv的模型是在是一个非常大的空间内,不断进行自动建模和优化的,类似遗传算法那;qtv的手工模式提供非常友好的前端、通知等交互方式;qtv会有一个规则引擎,执行自动交易;qtv可以接受无限扩展算力,高速的执行海量运算,其中有一种应该是采用显卡进行大规模LR并行建模;qtv会采用贝叶斯体系的算法;
2024-06-01 20:57:13 1152
原创 Python - 深度学习系列36 重塑实体识别3
从应用的角度,对实体识别的全流程进行进一步的明确。从全流程的角度上看,需要对数据做一些规范,并允许在不同的阶段插进来进行修改和迭代。
2024-05-29 11:16:50 1054
原创 Python - 深度学习系列35 重塑实体识别2
上一篇介绍了如何进行训练,这篇讨论如何应用。详细review了之后,发现其实早先的服务还是略有欠缺的。
2024-05-22 15:20:17 1211
原创 Python 运筹优化16 MDP解读
继续,MDP, 马尔科夫决策过程。我发现chat4o上线后有所变化(即使是原来的3.5),感觉逻辑更有条理和清晰,回复也更详细了。
2024-05-22 10:59:53 248
原创 Python - 深度学习系列34 重塑实体识别
transformers 演变出了两个主要分支BERT(Encoder Only)和GPT(Decoder Only),中间分支的概念相对淡一些。本次的目的在与梳理和重建实体识别模型,来取得更好的效果。
2024-05-21 14:18:41 860
原创 Python 运筹优化14 RegularizedLR解读
继续保持对RL学习的推进状态。上一部分主要是关于MAB的,只考虑了单步策略。另外就是从决策的角度上,比较简单,没有做细分。而CMAB(Contextual MAB)会考虑上下文信息。对我来说,MAB更像是一个简单规则,而CMAB则是一个复杂规则(由模型作出一个综合评估)。
2024-05-20 11:36:59 369
原创 Python 全栈系列240 数据流转任务调度
本次的数据流转任务基本上完成了,以数据流同步为例,验证了流转的有效性,并能确保在系统重启后,迅速恢复所有任务。1 重新搭建了flask-celery2 封装了对接flask-apscheduler的对象3 通过MongoEngine实现ORM操作4 使用状态机和规则来控制任务对象的状态改变总体上还是有些繁琐的,但总算完成了。之后就可以根据这套系统来完成大量的数据流转工作,接下来会基于此,先完成基本的S2S WorkMode。
2024-05-19 13:57:41 878
原创 Python 全栈系列246 任务调度对象WFlaskAPS
之前已经完全跑通了任务调度,实现了S2S的流转。由于request请求用起来比较别扭,所以创建一个对象来进行便捷操作。
2024-05-14 00:35:07 841
原创 Python 运筹优化12 eps greedy 解读
主要的精华部分在这一段,有点像拒绝采样。eps就是选择的不确定性,通过这个来进行随机游走。
2024-05-13 13:29:31 385
原创 Python 全栈系列245 nginx 前端web页面透传
过去的几年,我已经构造了很多组件,从图的角度来看,完成了很多点。这些点的单点测试看起来都不错,但是因为没有连起来,所以无法体现系统价值。好比发动机的马力虽然大,但是没有传动轴,那就没法用起来。所以今年,虽然我还是会继续增加一些新的点,或者对某些点进行迭代,但是更重要的是将已有的点,连起来,完成系统功能。
2024-05-13 00:02:21 379 2
原创 Python - 深度学习系列33 - ollama_langchain_ppt生成
1 可以参考langchain,进行增强。langchain本身还有agent的能力,继续融合后,是有可能完全不一样的。例如当你提到一个论点,agent可以自动查询实时数据,找到论据来support.2 ppt生成(及读取)。之前比较少用python操作ppt,现在看来,读和简单写应该是没问题的。
2024-05-12 11:32:37 635
原创 Python 全栈系列244 nginx upstream 负载均衡 踩坑日记
最初我认为负载均衡默认就带了健康检测的功能,nginx应该可以识别那些反向代理的服务器,那些有问题,然后避开它。实际上1.19版是没有的,没有这个模块时,负载均衡总是一视同仁的去调用那些已经挂掉的服务。只要有一个服务挂了,整个体验就是卡卡的。简单来说,就是要装一个check_module插件。传统办法好像要自己下载,然后重新编译啥的,看起来就很麻烦。然后我就想取个巧,但发现这个还要碰运气。
2024-05-12 10:59:26 425
原创 Python 全栈系列243 S2S flask_celery
按现有的几个架构部件,构建数据流。这个可以作为缓冲队列和简单任务队列,速度非常快,至少是万条/秒的速度。这个作为任务队列,消息也主要是元数据。读速比较慢,但有一些特性,然后自带前端,作为任务队列比较合适。M = Mongo。这个作为数据主库还是比较合适的。具有丰富的数据操作模式,同时性能也不错。这个特别适合作为任务数据库。因为列式存储的特性,其吞吐性能,简单统计功能甚至逼近了程序处理的速度。例如,存储10万条数据,大约也就3秒;统计900万数据某个字段的长度,时间也不到5秒。
2024-05-11 14:06:42 1033 2
原创 Python 全栈系列242 踩坑记录:租用算力机完成任务
如果再来一次,我会把文件传到一个算力机,然后建一个clickhouse,数据全部写进去。然后将任务写到队列中,按照brick作为基本单位。然后租用更多的算力机,每个算力机上启动n个worker。worker工作时到队列中获取brick,然后根据brick从clickhouse中取数。处理完成后,数据写到结果表。写表前根据brick判断,是否可以插入。这样的话,估计手工的时间只需要2个小时,整体跑数时间应该短于6小时。1 可能会因为连接不稳,而导致处理中断。–不合适把租用机作为稳定的后端服务业源。
2024-05-10 11:38:46 989
原创 Python 全栈系列241 GFGo Lite迭代
将复杂的规则(判定)作为一个函数调用。每个函数都要支持列表(多个元素)的并行处理。踩过的一个小坑:GlobalFunc使用了一个公网机的Redis做ROM,而GFGoLite使用m7本地的redis,导致了逻辑上看起来更新了,但是实际未更新。
2024-05-05 13:52:55 659 2
原创 Python一些可能用的到的函数系列126 UCS函数
嗯,想想发现,其实标准的时间格式,本来就做了层级的顺序编号。如2024-01-01 11:11:11,无非是要把2024,01,01,11提取出来即可。根据起止时间,可以获得两个时间对应的起始月。因此,只要生成从起始月(1号)开始的所有天,然后再根据小时就可以生成所有的brick_name。最常见的是mysql的自增ID,因为这种范式比较好,所以我在Mongo(主库)里也实现了一个机制,可以自动进行编号。一个大月有744个brick,一年不到9000, 十年不到9万,感觉上这个切分还是可以的。
2024-05-02 23:41:23 325 1
原创 Python 全栈系列239 使用消息队列完成分布式任务
1 RabbitMQ 和 RabbitAgent的建立。这使得其他机器可以不必要使用端口,非常适合超高计算传输比的任务。2 将原始数据通过rabbit agent 发布到任务队列3 将chatglm2-6b部署到算力租用机:测试了主流的三家autodl, anygpu和仙宫云,都是ok的4 在各算力机上启动worker进行处理5 将结果获取,然后存在本地的mongo没能成功完成的实践是在仙宫云使用nginx做负载均衡,简化worker的请求。结论:用llm来做任务成本还是比较高的。
2024-04-12 16:35:15 1098
原创 Python - 深度学习系列32 - glm2接口部署实践
前阵子,已经对glm2的接口部署做了镜像化。为啥不用glm3: 因为出现中英文混杂情况的概率较高。
2024-04-11 14:38:41 801
1 python的三种类方法
2021-01-10
DataManipulation-0.1.12.1-py3-none-any.whl
2020-07-11
DataManipulation-0.1.7-py3-none-any.whl
2020-05-30
netflix_titles.csv
2020-05-29
DataManipulation-0.1.6-py3-none-any.whl
2020-05-24
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人