媒介
Q200已经达到了我既定的目的，在最近的3个月，我需要进一步完善，达到可以试产的程度。
在这个过程当中，很多知识和体会一直在变。
qtv200到目前，虽然通过习惯(每晚运行离线计谋和比对)方式维持了留意力的集中，但是仍旧有一种睡一觉就容易忘掉的感觉。而本日在思索队列作用时，突然意识到，etl的流应该通过kafka来执行，只有通用的焦点本领才需要做微服务。
类似这样的灵感，然我以为有必要在下一步实施之前重新约定整体的架构。
在谈架构之前先看看业务上的要求和计划。
1 利润目的：每月3%
3月算是q200开始实测的第一个月，因为行情原因，借了东风，感觉大概率达到了。最大的意义是在于还清了历史标题，进入重置状态了。而q200自己的基准计谋，只剩下小金额测试，效果比力理想，但没法进行更好的测算。
例如在测试盘中，2月份30单，目前均匀浮盈4.6%。但是标题是，目的寻求的是整体，而我们很难保证每一分钱都恰好投进去了，以是这里要打折扣；别的，每个测试单未必能精准跟踪，以是这里又有差距。
当然，最重要的票据假如是打开状态的，那么不可以或许保证，都是敞口。
以是假设这个已经作为一种产品可被生产和贩卖的话，我们肯定需要考虑其稳固性，也要评估期望。就像生产芯片那样。
现在先不谈详细的数值，但是很显然，有一个标题是需要考虑的：怎样盘算当前的希望？
假如说，目的是3%，然后目前还在open的订单盘算是floating profit ，浮动的；而已经close的订单则是fixed profit固定的。应该有类似的公式：
y' = a * x + b
此中a是折扣率，因为浮动的风险很高；而b是已经完结的部分，是固定的。以是在确保目的完成时，应该有一个计谋是要控制a。
技能上，需要可以或许客观的统计这个，然后猜测、跟踪这部分的变革，同时作出反馈。这将影响到全局的仓位控制。
2 办法辅助
因为是手动下单，以是肯定会存在跟踪误差。
以是系统应该从事前、事中和过后给到辅助。
- 1 事前。由于信号具有滞后性，以是应当允许事先的，大概whatif 类型的分析，主动的将“大概发生”告诉用户。
- 2 事中。当信号已经确定，这时会需要根据实时数据资助用户跟踪信号，甚至根据历史经验猜测是否有更好的买点在短期会出现。
- 3 过后。当信号确定竣事，此时需要清盘。是立刻清盘，还是允许等一等，需要系统告知用户。当然，大多数时候应当立刻清盘。
技能上,需要有实时的数据获取和消息通知（如邮件、app等）；每个事件都具有完全的生命周期，整个过程应该比基准计谋的时间范围更宽一些。
3 计谋框架
基准计谋之以是为基准计谋，就是因为不完善，以是肯定需要开发衍生计谋框架。
假如完全按照基准计谋，那么很难达到利润目的，而且有大概因为长时间的负利润而失去信心。
虽然总体上已经是明显盈利了，但是假如 要承受若干个月的损失，我估计大部分人都会放弃：基准计谋是无法直接使用的。
那么怎么进行进一步加强？直观上削平波峰，然后摊到后面若干月上。
按照类似游戏的方式，可以做出一些有趣的计划，此处不睁开，然后会有一些离散的举动出现：
- 1 试探性买入
- 2 守旧的止盈
- 3 激进的止盈
- 4 伺机抄底
- 5 反复收割
对于这些衍生擦略，应当有一个可执行框架，初期仅考虑严酷按照规则执行，未来将由算法自行探索。
技能上，需要对每一个主题有专门的存储，统计，来记载在各组参数下的效果，以及总体情况。
以上三部分，构成q200第一阶段业务上的根本要求。
接下来，分析技能上的要素
技能要素
一些离散的功能点：
- 1 要获取分钟级别的行情数据和舆情数据。 这个底子的功能性验证ok，来日诰日我就可以开始获取分钟级别的舆情数据，虽然不多，但应该够了。
- 2 要存储数据。这个也没标题吗，这次特地准备了时间序列数据库。
- 3 要盘算信号。最近一直在离线盘算校验，明白了调整点，之后可以确保在线盘算与离线盘算一致。
- 4 要通知。短信不靠谱，app的通知已经准备好，邮件的通路没标题，但是展示方式我想用css轻微加强一下。
- 5 要能辅助分析。这个还没想好，想象中应该把这些要素可以抽取在一起，然后在页面上展示。数据抽取没标题，要怎么展示，特别是怎样进行超链跳转大概要想想。
- 6 可以或许方便的吞吐对象缓存。这个没标题，我甚至用mongo做了这事。redis我怕掉了，懒得同步。
- 7 回测盘算。这个已经做了一版，虽然慢了点。后续大概需要使用numba来加速，格式要改改。
- 8 表格盘算和统计。这个可以用clickhouse，不怕大量数据，可以实时统计。
为什么要谈架构？
这些离散的功能点任意写写已经很多了，假如要全部落实细节会更多。然后到末了肯定又是失去控制，然后就没法维护和迭代了。我不想这样稀里糊涂的搞，然后做q300。
要考虑到，有些单点功能黑白常复杂的，然后当你全力解决玩一个标题，又发现全局布局是含糊的… 服从会很低。
这次我想，至少能做到个部分功能是有构造，适度耦合的。
celery 执行， kafka流转
- 1 任务执行。一部分是IO任务，这个将交给apscheduler_celery框架。一部分是盘算任务，暂时用传统方法，6月之后我会用类似rlib这种。
- apscheduler_celery的所有任务均为微服务任务，区别只有参数
- apscheduler_celery的异步任务结果都类似callback，会写入kafka
- 任务的执行都是固定的，按1秒，31秒两个时间点执行
- 队列按照主体，如数据获取的定名为 xxx_market_minute, xxx_market_daily, xxx_news_minute, xxx_news_daily
- 假如是处置惩罚，可以称为 xxx_etl_minute…
- 效果：我可以随时加上一个新的code，然后就会主动被分配执行。
line protocal 协议，mongo 存储
- 2 时间序列。最终所有的可决议数据都将存储时间序列数据库。假如说数据的获取是起点，那么事件就是终点
- 1 新闻事件
- 2 行情事件
- 3 计谋事件
- 4 目的事件
- 3 前端可视。暂时还是采取比力守旧的做法，flask + bootstrap + js。
- 1 总体交易数据
- 2 订单详情数据
- 3 辅助决议数据
mongo + clickhouse
- 4 数据存储。mongo存储原始数据，clickhouse存储分析的表数据。
几个焦点的元数据：
- 1 celery在每个心跳执行的任务。会有一张表格，记载哪些任务是需要周期执行的，可以增、删、改。这个是一切的源头。
- 2 监控数据。包罗了各队列的长度，在时序数据库中对数据的条数统计。这个可以推到kafka，然后送到clickhouse。
- 3 KPI数据。包罗运行中的计谋，竣事的计谋，整体的目的效果，颠簸等。这个应该会在clickhouse.(不需要kafka)
特别重要的对象：
- 1 通知对象。这个对象会挂在每个计谋下面，按照规则进行事前、事中和过后的全跟踪。其举动通过kafka发送，日志恒久化在mongo中，主数据也在mongo中。
- 5 微服务。将一些重要且复杂的处置惩罚步骤封装为微服务。
- 1 获取数据封装为微服务。我需要的数据不多，频次也很低，但最好还是通过微服务哀求。
- 2 回测作为微服务。这部分容易丢掉，且要恒久维护，以是发布为微服务。
- 3 基准计谋的信号生成。同上。
这样，可以想象，假如我一次性做好之后，又去忙了很多别的东西，当我要迅速切入进行维护时：
- 1 我会找到celery的任务元数据，我知道我对那些标的执行了后续的盘算
- 2 我会看到一个队列清单，知道他们在毗连那些处置惩罚，有没有超时
- 3 我会看到监控分析，知道数据是否都按时，无遗漏的拿到了
- 4 我会看计谋整体效果，确保计谋是与目的一致的
- 5 我可以看计谋之间的差别，进行分析
当我有新的想法时，我应该采用一个新的定名，按照类似的步骤做好前期的获取和处置惩罚，然后，我应该在时间序列中找到这个事件。这样就形成了一个以时间为轴的通用管理方式：我新的任务只是在时间维度上不断拓宽。当然，对应地，事件背后的数据无论是数值、文本还是向量，可以在对应的元数据中展示。以是在需要的时候，可以在一个时候把所有的的特征数据全部对齐，产生聚集效应。
Next: 把异步任务框架和kafka毗连搞好。并开始产生事件。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
