苏州网站建设白石,ppt设计报价,网站建设 客户定位,企迪网说明 虽然说的是表#xff0c;实际上用的是Mongo集合 基于ADBS(APIFunc DataBase Service)可以构造一个供后续研究、生产长时间使用的数据基础#xff0c;这个基础包括了#xff1a;
1 队列服务。通过队列#xff0c;数据可以通过API实现零担和批量两种模式的快速存储。2 …说明 虽然说的是表实际上用的是Mongo集合 基于ADBS(APIFunc DataBase Service)可以构造一个供后续研究、生产长时间使用的数据基础这个基础包括了
1 队列服务。通过队列数据可以通过API实现零担和批量两种模式的快速存储。2 灵活ETL。通过AETL使用者可以实现高复杂性的操作但从设计和实现上又非常灵活这是一种基于图的分解和构建。3 监控与可视化。可以实时看到数据的流入和流转。
ADBS通过简单的设置就可以不断扩展。
内容
其实也是权衡了一下还是决定按照标准的步骤来推进量化而不是通过离线代码、松散的实验来推进。
最初在设计ADBS的时候除了功能性的考虑也加入了规范性的考虑。一旦操作可以按流程进行那么工作效率就会提升可靠性也会提高。
搭建量化研究、生产体系的过程应该也是和搞架构一样是一个结构性很强耗时也很长的过程所以最好按严谨的结构推进。至于核心的方法在一开始反而可以简单以跑通为目标。
架构中的算法(方法或者算法(方法)中的架构总是互相交杂缠绕在一起的。 本次的目的很简单就是确定入库原始数据的表字段结构。 本质上ADBS的数据库使用Mongo并不会对字段进行太多约束,这里的表字段结构仅仅是从逻辑上约束。
这种约束是具有意义的后续会有一系列的处理程序如果能够对输入有所预期那么在处理时也会比较容易设计。正如APIFunc中的设计经验从样例数据开始设计总是方便、可靠的而这里的表字段也是这个大项目的样例数据表头。
Step1 DataETL 原始数据与基本衍生
Step1: In
序号字段名解释1rec_id是整个项目的主键由下面的若干字段联合而成 ( market , code , data_slot)2data_slotint, 数据时隙是以分钟为单位的计时法是记录数据的时间3data_dtstr, 数据时间是 YYYY-MM-DD HH:MM:SS 格式的字符时间起到校验作用4codestr, 证券代码应该是唯一的5marketstr, 市场与code联合形成绝对唯一的代码6openfloat, 开盘价7closefloat,收盘价8highfloat, 高点9lowfloat, 低点10volint, 成交量11amtfloat, 成交金额12tradesint, 成交笔数13float_capitalint, 流通值
第一步入库后ADBS允许执行ETL在这个时候允许做通用的特征项这个特征项是与回顾周期相关的。
初始阶段我打算手工指定若干个周期。
1 短期 60120 240一个交易日2 中期60012002400十个交易日3 长期600012000 24000一百个交易日
Step1: Out
这些周期会形成一波新的变量以下用T指代某个周期原始的变量会同步被转存
序号字段名解释1open_TT的开盘价2high_TT的最高价3low_TT的最低价4close_TT的收盘价5vol_TT的成交量6amt_TT的成交金额7trades_TT的交易笔数8vol_T_meanT的平均(每时隙)成交量9amt_T_meanT的平均成交金额10trades_TT的平均成交笔数
Step2 Signals 信号生成 这个比较有意思出现了第二个ADBS。 Step2.In Step1.Out
通常来说AETL允许对平面化的数据进行足够复杂的操作但是但需要的操作是深度式的时候就需要进行级联了。
在设计ADBS时为了确保复用性、稳定性所以约定了每个ADBS只管一个step。第一个step中已经完成了原始数据以及若干周期的简单衍生。
在这个step中主要根据上一个step中生成的基本变量生成交易信号。
这里探讨一个小问题有没有可能在step1中同时完成交易信号
理论上可能但是真要这么做会非常麻烦甚至会因为新的尝试而破坏旧的运行中的东西。在上一步中已经根据过去若干个周期进行了统计。在很多传统的新号计算方法里会对若干周期的统计值再进行若干周期统计。从阶数上来说是 T2T^2T2 从计算的顺序来说肯定也是计算两次。
对具体的计算指标我回头再翻翻书正好没带在身边。
序号字段名解释1SOME_buy_T_t使用T周期对 t周期进行计算生成的买入信号2SOME_sell_T_t使用T周期对 t周期进行计算生成的卖出信号
后续生成买入信号可能会有很多很多组从周期上来说分为短期、长期等从原理来说分为回归、周期以及动量。
Step2.Out 输出买卖的信号
到这一步故事显然还没有结束。
Step3 Decision 交易信号与指令
Step3.In Step2.Out 注意交易信号与原始的价格无关(Step1.Out)
生成买入信号并不能允许直接交易仅从决策角度看就需要进行纵向和横向的参考。
例如信号经常会出现毛刺噪声如果仅仅一次买入信号就买入的话很容出错所以会从纵向上进行持续观察我称之为冷静时间。
除此之外从宏观角度我们还需要知道长周期趋势。这样的目的是为了避免在低概区交易以及避免系统风险断崖式、持续下跌。
除了纵向还要考虑横向的其他维度
未来肯定是多种方法的信号并存的所以除了自身维度的信号判断之外也可以考虑一种投票机制来辅助作出交易决策。
决策作出之后在真实的交易之前还有一些小的步骤需要完成就是交易指令。可以简单理解为加滑点进行买卖交易的策略这个可以暂时略过。
不同的策略可能会基于同样的信号操作所以要增加策略名来区别。策略名也可以按三级命名来操作。
Step3.Out 输出买卖的决定以及交易信号
Step4 Trade 交易的撮合与记录 基于上一刻的决定和这一刻的数据进行操作 这里的输入有两个
Step4.In Step1.Out ~ 标的的时隙数据( open, close, high, low) Step3.Out ~ 在上个时隙作出交易决策 (target_price, amt, buy/sell)
我们总是先做好决定然后再采取行动无论这个先后差距长或者短总是如此。量化不过是用更精细更准确的方法来千百次的替代我们完成这个过程。
如果Step3中没有Open的决策(Open Orders)那么这一步就可以直接略过。反之如果有决策没有被实现那么Step4就会看在当前时隙是否可以完成。
这里假设了Step3中已经发出了自动化交易请求实际上目前对于个人投资者用接口直接交易还是不太方便但我们可以假定如此。
当target_price处于high和low之间时交易被完成否则就轮空。
轮空状态下会有一些对应的处理方法。例如大量Open Orders是否要发起告警或者是要调低目标价。
从整体上来看Step4或者产生1/n个close order或者什么也不做。
Step4.Out(if any) 输出完结订单
这样结束了吗显然还不…
Step5 Watch 观察序列变化及干预 Always Watch Back Step5.In Step4.Out
Dalio在《原则》里有提到桥水的量化模型当上线之后人就不干预了直到触碰规则。所以量化是一种 Run… Until …的模式。
我们会让策略上线一定是有我们的期望这既包括了好的期望也包括了坏的准备。如同正态分布我们不认为策略会超过3个西格玛。
因此我们需要持续的观察来确保一切尽在掌握。
Step5会在每个时间点进行回看主要从几方面比较
1 最大回撤是否超标2 最大正收益是否超标是的我觉得这个也要看3 交易周期4 资金敞口5 超额收益
Step5.Out 收益曲线、回撤曲线等
这部分的结果会输出到我portal的dash board里。
Ending
总的说起来这是一个由5个ADBS构成的处理流。我觉得这样才比较好解释为啥之前总是半途而废强行用简单的处理办法去容纳复杂问题就好比用一个杯子去装一壶水。分治其实是唯一的办法分治核心在于结构。
以下是工作流的基本框架 还有许多未尽部分例如策略的中途叠加、多模型协同、生成式估计、自动优化等这些在“1”完成了之后会逐步的进行迭代。
本次完成了“0”的突破-转变算0.1吧。
