Python:实时流数据

Question

我试图通过Python捕获实时流式金融时间数据.我想最初将信息存储在数据库中,然后在以后进一步开发一个程序,根据这些数据分析和做出交易决策.能够随后在网站或Jupyter笔记本中以某种图形格式显示所述数据将是很好的.

作为一个起点,我想我会使用GDAX或Gemini的比特币数据.如果可行,我想捕获刻度数据和潜在的附加订单信息.

在进行一些研究时,我对这些选项感到有点不知所措,并且可以在如何构建项目以及哪些库最合适方面使用一些指导.

我查看了每个服务的API以及一些Github项目的相应文档,我仍然不确定从哪里开始.任何建议,建议或推荐阅读将不胜感激.

Answer 1

任何建议,建议或推荐阅读？

如果我可以在几十年的实际建筑和设计推理的实践经验后增加几美分:

始终保持现实和诚实:

           0.5 ns - CPU L1 dCACHE reference
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1K bytes with Zippy PROCESS
      20,000   ns - Send 2K bytes over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|

• 决定,你实际有多大"实时",这是最大的区别 - 如果你在技术上必须实施过程控制回路,由于其稳定性标准,在1 kHz RTT-End下的阈值-to-End(事件发起+传输+本地采集+本地处理+反馈环路<< 1 [ms]),10 kHz(<< 100 [us]).了解这种"意图"可以帮助您确定适当和可行的技术,这些技术可以(或者主要是不能)实现所述目标.选择不充分的技术是业余爱好者常见的(也是昂贵的)错误(但也经常被专业软件公司重复).

• 在了解了RTT-E2E阈值的实际值之后,在进一步采取任何步骤之前进行检查,如果API提供商确实允许您在技术和商业意义上提供如此频繁的更新.如果没有,您必须找到另一个数据馈送提供商.如果您的实时系统无法从充分采样(快速)的馈电源馈送,控制环路将无法在稳定范围内工作 - 这很糟糕 - 就像您试图观察一样糟糕从高清视频流中,你的电视不会出现每一个,只有每一张37~46张图片.您将无法观看这个"子采样波动的东西"(当然,如果您的本地DVB-T解码器根本不会放弃显示任何内容,由于DVB-T流协议违规的残酷规模,即使只有几个CRC位在Reed/Solomon-冗余容错转码未能正确通过时,方格的伪像也是令人讨厌的.但与稳定且无差错的1:1 FullHD流相比,这绝对没有什么好处.

• 既具有RTT-E2E阈值的实际值,又具有匹配的API供应商,开始设计技术步骤(而不是实现它们的技术)您如何计划帮助掩盖现实世界的实时延迟 - 从API提供者参考访问点到处理引擎输入的传输的实际时间成本[us](+所有相关的加密/解密方案,无论是SSL隧道还是VPN或其他).不知道这一点,你所有进一步的决定都会有缺陷.

• 已经测量了实际的ISO/OSI-L9下行延迟,是时间的两倍[us],以便也保留合理的时间来覆盖上游延迟(不需要具有完全相同的延迟源) ,但数量级将接近).

如果您的初始设计RTT-E2E目标数字具有上述1kHz的控制回路阈值和max( DownStream ) + max( UpStream )实验观察到的延迟上限,则根据提供商的实际生产API网关进行实时测量(那个,已经检查过符合1kHz至少1个24/7-占空比期间控制环路阈值),现在计算有多少时间是留给你开始任何种类的本地处理的-即有多少[us]实际上仍是本地加工,使得您的1kHz控制环路不能满足其稳定性阈值.

如果您的净本地处理时间预算已经变为负数,那么您就知道您的工作不会带来任何好处.这不可以.拉停.

如果你的净本地处理时间预算仍然留下了相当多的[我们] - 这是你的实际过程设计目标,开始设计这样的计算步骤和措施,以便始终安全地适应.

任何人在不知道这个主要设计限制的情况下开始编码要么是天真的,要么是不负责任的,是一个"正义教学"的院士或者是一个喜欢失败并且不介意一次又一次地对着已知的墙壁进行攻击的人.一个系统的专业设计师现在专注于开始所有精心的设计工作,反对收集的硬性事实和证据支持设计目标(并且永远不会花费一秒钟在任务上而不知道这些主要的约束条件,只有爱丽丝在仙境可以抽象出来 - 不知道你想去哪里,任何道路都会带你到那里 - 这是一个很好的童话故事,但不是真实世界的实验,是吗？)

• 现在,检查一个阈值,一个GIL被释放的频率(in [us]) - 如果它在你剩余的净本地处理时间预算中不适合很多次,你可能会直接忘记使用python,那么简单(和关于多线程处理的异议并没有让你在Python领域变得更好:

"......在Python中,GIL意味着即使你有多个线程同时在计算上同时发送,这些线程中只有一个实际上会在任何给定的时刻运行,因为所有其他线程都将被阻塞,等待获取全局解释器锁.这意味着多线程Python程序实际上比单线程版本慢,而不是更快,因为一次只运行一个线程 - 加上强制每个线程等待会产生的会计开销每隔几毫秒就可以获得,然后放弃GIL(循环式)...."

即使所有的崇拜者专家发布无限量的免费的充电-件意见,这和那个包是这样一个伟大的工具.当然,许多软件包确实是很好的工具,但遗憾的是,在某些主要的稳定性阈值水平下,几乎从来没有任何更严格的实时应用程序域.是的,我很高兴设计和操作python/scikit-learn GLAN分布式快速AI/ML预测系统,但我非常确定能够适应<< 1 [ms]并且80 ~ 90 [us]本地RTT-E2E 的阈值完全在我的控制之内 -循环的稳定周长)

人们可能在工具中花费任意数量的爱 - 编码,专业人员永远不会有理由开始正确使用,因为已知的主要能力无法匹配并满足控制环稳定性阈值,因此最好采取适当的谨慎措施在实时系统架构的可行性/审查阶段,不要重复其中一些或类似的天真致命决策错误.