- 博客(816)
- 资源 (16)
- 收藏
- 关注
RSS订阅
原创 Andy系列文章序
说明博文写的面比较杂，这里做一个汇总梳理1 Python实现决策树更确切的说是「Python实现树族算法系列」。使用Python实现CART决策树，并基于此实现GBDT,Random Forest , XGBoost等模型开始页面：Python实现决策树（系列文章1）–从最简单的算法开始2 Python 函数字典系列这里指的是一种自定义的函数方法。将函数都作为某个字典可以引用的键值，然后可以使用参数化的方法调用链条比较长的函数。未来这部分会打包，以包装其他普通函数的方式来充实里面的函数。
2020-06-07 22:39:33
945
2
原创 【最后203篇系列】026 FastAPI+Celery(续)
使用相同的配置文件，是因为在服务向celery_app传递信息时，需要使用一致的消息队列（redis)。最后，还应当给到一个ORM(就叫FastCelery)，使得任务的操作非常简便。,大致把我对celery的研究历史梳理了一遍，然后按照最新的方法重新包了一次，明确了其定位，使用方法。想了一下，我觉得最重要的还是不要烂尾，所以先进行使用封装，定时任务搞了好几遍了，先不花时间。当然，因为webhook是我胡编的，后台应该有一个webhook失败的日志，但可以不理会。测试之前的微服务调用任务，也是没有问题的。
2025-04-01 23:09:48
606
原创 【最后203篇系列】025 FastAPI+Celery
我记得后来我有看了一些工具，airflow, prefect，发现这些工具似乎背后还是celery，那我问题就不在celery，而是我的认知可能有偏差。SSE看起来是Stream的方式，这个和大模型实时返回有点像，websocket主要是用了新的协议，是可以在连接中双向交互的，适合实时对话的场景。当服务开500并发，然后就出错了，正好单个任务的时间超过了之前设定的30s，重新改60s，问题解决。callback 和 webhook，我的理解是一样的东西，实现的机制不同。看来是线程之间切换的问题。
2025-03-30 00:02:04
643
原创 【最后203篇系列】023 MacMini的ollama服务
以deepseek-r1-14b为例，执行效率上，m4入门级芯片的算力大约为4060ti一半，比我预想的要差一些。mac 毕竟是一台完整的电脑 ，还能执行多种功能，能耗低，无需额外散热，没噪音，体积小。对大模型来说，关键是UMA，16G相对还是便宜的，再高就要贵很多。我问了豆包，最初它的回答正确了99%，可惜大小写搞错了。我估计它的资料是更早一些的，后来的ollama变了。在mac上用ollama跑大模型也是最方便的，安装一下软件，pull一下就好了。反正之后又摸索了好一会，大约半小时到一小时，整明白了。
2025-03-23 11:50:42
207
原创 【最后203篇系列】022 用Deepseek14b提取新闻事件
这算是之前一直想做的一件事，趁周末赶快做了。业务意义：现实中有大量的舆情，这对我们的决策会有比较重要的作用。
2025-03-22 23:42:03
832
原创 【最后203篇系列】021 Q201再计划
在找基准策略的过程也是挺戏剧的，只能说，对的东西往往都出奇的简单。基准策略的盈亏比已经显著超过了2，这是一个很有意义的数字，而且这是在一个相对比较大的统计数字下得到的，很可靠。说起来，我周末的记得开始处理一部分新闻数据了，至少先提取处罚类的数据，这两天发现还是挺有预测性的。未来的变化，是交给算法去做的，我只是定了一个基础框架而已。实际上，一个code的探索，应该有非常庞大的计算量，例如在任何时间开始回测，采取多种策略的pk。纵的部分是为了能够无差别处理大量的逻辑计算，横的部分是为了确保这些纵都是有意义的。
2025-03-21 23:33:15
467
原创 【最后203篇系列】020 rocksdb agent
我还真没想到一个专职的前端，加测试，以及其他一堆人，竟然不知道后端返回的markdown,在前端渲染成html展示后，如果字体太大，应该去改css这件事。最好的选择当然是redis，目前也是这么干的，还能直接设置一个ttl，很方便。然后我就像装一个环境来着，之前我以为rocksdb是像mysql那样，要专门起个服，后来发现是嵌入式的，类似sqlite的方式，只要pip就好了。总体上的效果还是让人满意的，每条大约是2ms-6ms的读写，有相当一部分会损耗在json序列化和反序列化上，但这也是必须的。
2025-03-21 00:00:06
532
原创 【最后203篇系列】016 Q201架构思考
Q200已经达到了我既定的目标，在最近的3个月，我需要进一步完善，达到可以试产的程度。在这个过程当中，许多知识和体会一直在变。qtv200到目前，虽然通过习惯(每晚运行离线策略和比对)方式维持了注意力的集中，但是仍然有一种睡一觉就容易忘掉的感觉。而今天在思考队列作用时，突然意识到，etl的流应该通过kafka来执行，只有通用的核心能力才需要做微服务。类似这样的灵感，然我觉得有必要在下一步实施之前重新约定整体的架构。在谈架构之前先看看业务上的要求和设计。
2025-03-15 23:40:12
1048
原创 【最后203篇系列】015 几种消息队列的思考
队列还是非常重要的中间件，可以帮助我们：提高处理效率、完成更复杂的处理流程最初，我觉得只要掌握一种消息队列就够了，现在想想挺好笑的。
2025-03-15 20:47:13
691
原创 【最后203篇系列】014 AI机器人-1
终于开张了，我觉得AI机器人是一件真正正确，具有商业价值的事。把AI机器人当成一笔生意，我如何做好这笔生意？一端是业务价值，另一端是技术支撑。如何构造高质量的内容和服务，如何确保技术的广度和深度？正好在做这件事，所以我想不太多谈技术，把核心的理念和故事串一串。为技术而技术是没有价值的，为商业价值而产品又是没有生命力的，怎么让商业背后自然衔接到技术，而技术又如何自然衍生出商业价值，这是最为关键的。
2025-03-12 22:13:07
375
原创 【最后203篇系列】011 Mongo异步代理开发回顾
出于我自身的使用特性，我较早就确定了以Mongo为主库，然后其他业务形态根据实际场景进行细分的框架。最初的时候做了一版同步版的Mongo Agent，用于代理数据库操作，后来发现在大量使用的时候数据库会承受很大压力，浪费CPU。这大概是与我最初是做数据分析、建模有关系的，在这种场景下的确是批量操作大量数据；而在应用的场景下，往往是大批量的小数据操作-- 这会占据太多数据库连接不释放，网络情况越糟，这种情况越严重。也就是说在分布式的场景下，Mongo Agent不适用，这是由于同步和异步的基本特性产生的。
2025-03-09 17:43:34
725
原创 【最后203篇系列】010 关于矩阵的一点思考
今天拿起一本矩阵的书又翻了翻，毕竟AI搞到最后还得是数学。我是感觉自己高数始终有点学的迷迷糊糊的，就打算这一年慢慢把矩阵部分扫一遍，毕竟这快肯定是实打实有用的。其他高级部分就等我发财之后再说了，哈哈。
2025-03-01 22:31:15
815
原创 【最后203篇系列】006 -使用ollama运行deepseek-r1前后端搭建
这块已经不算新内容了，年前搭完了后端（ollama)，本来想早点分享的，但是当时的openwebui有点不给力，有些地方不适配，然后配置项找不到。所以前端没搭好，也就不完整：只能通过命令行或者接口调用，可用性、体验感不强。今天看到别的文章推荐了chatbox，试了一下还是挺方便的，所以就顺带补完。
2025-02-03 20:56:35
398
原创 【最后203篇系列】004 -Smarklink
是一个非常有挑战性但也非常灵活的选择。通过 Tornado 的异步特性和强大的编程能力，你可以实现非常精细的控制，满足特定的业务需求。
2025-02-02 10:48:18
908
原创 【最后203篇系列】007 使用APS搭建本地定时任务
本次使用APS搭建本地定时任务的目的是为了简化实验性质的定时任务，通过在git项目下进行编辑任务脚本和执行任务清单，而运行容器本身会周期性的自动拉取代码，然后按照任务清单执行。执行过程采用多线程方式，任务的负载通常都不高。整体设计上，复杂和繁重的任务会包在微服务中，定时任务主要是向这些微服务发起触发动作。通常，微服务收到触发元信息后进行自动的任务/数据拉取处理，处理完毕后通过webhook将结果持久化，或进一步发起其他的触发动作。
2025-01-29 19:59:37
350
原创 【最后203篇系列】005 -QTV200 Online
借着春节休假，把这部分完工，然后2025年将正式的把量化研究的成果进行产品化输出。首先，我会将策略的执行从脚本挪到服务。做法是将策略的逻辑放在微服务里，作为一个接口，而由sniffer来触发策略执行。我想这样策略不会因为任务太多而搞丢或者搞乱。之前QTV100的代码，我已经不知道放在哪了，在运行，但是我都无法去维护。而无数个微服务，哪怕是老版的，我也可以很容易找出来。也就是从"拉"式转为"推"式。其次，使用数据库来支持策略的断点保存。
2025-01-29 16:31:24
1030
原创 【最后203篇系列】003 - 填坑DogPile
可以在set_value时指定超时时间，也可以在之后设置expire时间。然后还可以进行增量计数，这些都是redis最常用的功能。再也不用dogpile了，实在很坑。我已经懒得再去找为什么了，反正用的是set和get，我不知道为什么这样。找了很久，发现是Dogpile的问题：数据还在，但是结构变了。问题现象：一个程序获取拎一个服务的缓存时，数据格式报错。也不知道咋回事，怎么坑这么多。其实这样的工具我早就自己做了…只要再加一个命名工具就好。,再次获取缓存时结果是。
2024-12-25 22:48:32
257
原创 【最后203篇系列】001 - 2024回顾
所以在这个过程中，我的文章基本上完全是原创，也非常强调落地与工程化。在不断写作的过程中，我也得到了许多好处，教学相长的感觉。不过，万事都有个尽头，我给自己一个小目标：1000篇博客。在接下来的1~2年内，我会完成这个目标。内容，还是以我自己的体会、实践为主，如果有人觉得有用固然好，自己写写也挺享受的。
2024-12-23 22:28:16
786
原创 Python Tips6 基于数据库和钉钉机器人的通知
起因是我第一版quant程序的短信通知失效了。最初认为短信是比较即时且比较醒目的通知方式，现在看来完全不行。结论：不再采用短信方式，而是使用机器、邮件的方式通知。
2024-10-02 19:19:35
795
原创 Python 图算法系列29-大规模图关系建立-step1导入数据
将数据保存为csv形式，大致的格式如下。对于节点来说， ID和LABEL是必须的。ID可以简单理解为数据的主键，LABEL则是数据的表(Table)或集合(Collection)。对于边来说， STARD_ID、END_ID、TYPE构成了一条边，STARD_ID和END_ID是起点和终点，需要注意的是，
2024-09-23 18:33:15
766
原创 建模杂谈系列256 规则函数化改造
所以，将原来的修饰器改一改，将节点的依赖关系在启动修饰器的时候解释。函数可以在修饰器下临时定义，也可以引用已经编辑好的。现在已经具备了使用形式化参数(如。
2024-09-16 17:56:53
874
原创 Python 全栈系列271 微服务踩坑记
Tornado：更适合专注于长连接和实时通信的场景，原生支持这些特性。FastAPI：更适合快速构建高性能API，也可以支持长连接，但需要依赖底层的异步框架。
2024-09-14 00:29:53
1327
原创 Python 全栈系列269 使用ORM转移数据
继续实践ORM的使用现在看起来，选择ORM的确是更好的，它让代码看起来更清晰了，效率上也基本能够保持。
2024-09-13 00:05:18
574
原创 Python 全栈系列268 数据库浅析
数据是数据库的内容，数据库负责存储、管理和组织这些数据。数据库为数据的存储提供了结构化的环境，并使数据的访问、管理和处理变得更加高效和安全。通过数据库系统，用户可以有效地管理大量的数据，并从中提取有价值的信息，从而支持各种应用和决策过程。人与数据库的交互方式多种多样，主要通过图形化工具、SQL 查询、编程语言、REST API 和自动化脚本等方式进行。选择哪种方式取决于用户的需求、技能水平和使用的场景。SQL类数据库的好处是普及率高，使用较为简单。在处理结构化数据时效率比较高，使用起来也比较简单。
2024-09-09 18:02:52
2374
原创 Python 算法交易实验88 QTV200日常推进-关于继续前进的思考
自顶向下，自底向上过去的很多行为是自底向上的，现在则是自顶向下。过去的经验告诉我，final solution 会在这个过程中产生。两种方向的探索，会在中间的某一个部分融合，达到一个兼顾、平衡的体系。Go!Go!Go!
2024-09-08 00:03:04
1478
2
原创 Python 全栈系列267 telegraf、influxdb和grafana
Telegraf 是一个灵活且功能强大的数据收集代理，通过其丰富的插件系统，可以从各种数据源收集数据并发送到多种目标系统。它的轻量级和高性能使其成为监控、日志管理、物联网数据收集等场景中的理想选择。尤其是与 InfluxDB 结合使用时，它可以组成一个强大的时序数据收集和分析系统。Prometheus更适合实时监控和报警，尤其在云原生和微服务架构下的监控非常流行。InfluxDB则是一个通用的时序数据库，适合需要持久化、复杂分析、事件和日志处理的场景。
2024-09-05 23:40:10
1934
1
原创 建模杂谈系列252 规则的串行改并行
提到规则，还是需要看一眼RETE算法：Rete算法是一种用于高效处理基于规则的系统中的问题的算法，广泛应用于和。它的设计目的是在大量规则和数据的组合中快速找到满足特定规则条件的模式。
2024-09-05 17:22:11
375
原创 Python 算法交易实验87 QTV200日常推进-沪深300的交易量统计
讲到，就全市场的交易量来看，近3年也看不出很奇怪的地方；因此，交易量[支持度]不足而导致的策略失灵似乎也说不通。计算多个连续周期的变异系数（CV）可以帮助分析数据在不同时间段内的波动情况。假设你有一段时间序列数据，并希望按月、季度或其他周期计算CV。下面是步骤和一个简单的示例。
2024-09-04 23:47:02
855
原创 建模杂谈系列253 序列突变点的判定
1 这种模型可以推断看不见的事实2 matplotlib用好了也可以画出很好看的图注意：理论上，pymc是可以借用显卡计算的。只不过之前它的后端比较奇葩，现在可能失传了。然后我不太清楚的是现在怎么和显卡挂上，单靠cpu只能做一些小规模的计算。
2024-09-02 22:03:28
555
原创 Python 全栈系列266 Kafka服务的Docker搭建
在大量数据处理任务下的缓存与分发这个算是来自顾同学的助攻+1，我有点java绝缘体的体质，碰到和java相关的安装部署总会碰到点奇怪的问题，不过现在已经搞定了。测试也接近了kafka官方标称的性能。考虑到网络、消息的大小等因素，可以简单认为kafka的速度是10万/秒级的。
2024-09-01 23:30:57
866
原创 Python 算法交易实验86 QTV200日常推进-获取A股日交易额并统计
上一篇说到，交易量可能可以作为策略规则的支持度分析，但是(我现在还不想付费买数据)现成的接口似乎并没有这样的统计。获取某一只股票的日交易数据是相对简单的，市场上也就不到5000只的股票，总数据量应该也不会超过18M(5000*3000)。所以可以获取全市场的日数据，然后自己汇总。
2024-09-01 17:40:25
1730
原创 Python一些可能用的到的函数系列131 发送钉钉机器人消息
来自顾同学的助攻钉钉机器人可以用来发送一些重要的系统消息，例如磁盘将满等等。原本还可以有更强的功能，就是监听群里的消息，然后做出反应，不过这个好像要买企业版，贵的毫无意义。钉钉发消息有几种模式，一种是按关键字过滤的，还有一种是按签名发送的。这次顾同学帮我梳理了按签名发送的函数。
2024-09-01 11:44:19
468
原创 Python 算法交易实验85 QTV200日常推进-钳制指标与交易量
继续保持思考与尝试最近挺有意思的，碰到很多技术上的问题，其解决方案都类似“阴阳两仪”的概念。"阴阳两仪"是中国古代哲学中的一个重要概念，源自《易经》（又称《周易》）。它是对宇宙间最基本对立统一规律的概括，用以描述事物存在的两种基本状态或属性。阴阳最初是指日光的向背，向日为阳，背日为阴。后来，阴阳的概念被广泛应用于自然界和社会生活的各个方面，成为解释自然现象和社会现象的一种基本理论。阴阳两仪认为，宇宙间的一切事物都是由阴阳两种对立而又相互依存、相互转化的力量构成的。
2024-08-31 22:55:18
1428
1
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关注的人