波动率监控页面1.0

基于网页的期权波动率监控应用断断续续搞了2个月多，今天终于完成了初版重构，架构应该不会再变了，剩下的就是添加偏度维度的展示和策略相关的统计指标。
回头发现Dash已经发布1.0版本了，嗯，这个应用也打个1.0的tag好了。
这里简单记录下开发里的问题。

1
摸爬滚打的开发进程

应用要展示的数据和图形其实早就定好了，但是涉及到的dash库、web服务、数据维护等知识很多都是现学现做。再加上交易需求涉及到的开发进度调整、数据源局限性、古董级的硬件配置，磕磕碰碰搞了这么久。
非计算机、软件工程科班出身，程序开发非常直接的需求导向、面向过程，步骤比较简单，所以也没走什么弯路——

明确需求所需的数据和衍生数据；
定义数据库结构、确定数据源、写本地化转录程序和接口；
写衍生数据计算代码；
先直排式的UI布局，保证可视化和可用，UI优化以后再弄；
优化：历史波动率复盘和日内跟踪的分离，及涉及到的tab或multipages的技术；
服务器部署-web页面的测试；
数据存储位置及维护（客户网页端、服务端，及带来的效率问题）。

2
隐含波动率的计算
IV的计算效率是期权的研究、交易绕不过去的槛儿。刚开始偷懒直接用第三方mibian库，发现太慢了，如果只是历史日数据级别的，慢慢算还好；但日内分钟级别的跟踪，首次启动时要把开盘始的所有合约分钟级的IV都算一遍，拖个几分钟就算不可用了。
于是看看源代码，mibian居然用二分法算IV、要求的精度高、最多迭代次数大，果断弃坑；转而用了最简单的Newton算法、调低精度到0.01%、假如边界条件，一般速度快了3倍，特殊情况100x、1000x的优化（深度实值、虚值、临近到期等）。如果用拟牛顿、随机梯度下降算法估计更快，但懒得复习了。

这里再展开说说IV计算和可视化时的异常情况——

深度实值、虚值、临近到期等，会导致IV为0或者异常大，这时候最好先通过价格直接判断是否接近边界条件，否则优化算法会一直找下去，最优解找出来也没啥意义；
部分极大的IV会导致IV图严重扭曲失真，得考虑y轴上界或者直接异常值处理掉；
50ETF出现分红、期权合约调整后，会出现行权价很近、甚至相约的合约，有时候这些合约IV差异很大，如果不提出调整后的合约，图形也会很难看。

3
日内数据更新问题
Web应用开发一个比较重要的问题就是数据的更新、存储和共享机制：既要保证数据在各个组建之间能共享、页面访问最快，又要全局数据复用、页面状态和操作独立等，其实是个麻烦事。
Dash加入了一些数据共享的机制，但是波动率应用需要每分钟取一次，如果数据放在页面html里面，没开一个客户端都会调用数据提取函数，流量肯定爆掉；如果都用全局，会导致客户页面操作互相干扰。
最后浪费点内存，保留需要的基础数据和衍生数据的最小集合，放到全局。用单独的线程维护更新；页面html都从全局数据取、也只保留自己展示需要的数据。

4
历史与实时的分离
实际使用下来发现历史复盘其实一般在交易时间外用用，确定当日策略、参数等，交易时间内基本只看实时展示（分钟频率的更新也算作实时吧）；所以看了看Tabs和链接MultiPages两种分离形式，后来还是觉得Tab切换要直观点，就用了这种方式，其实代码结构没差多少。

最后，三维的波动率曲面图看着炫、没卵用，表面直观、其实很难看出结构，还不如分组的散点图，页面渲染也显著慢于二维图，实时页面还是拿掉好了。

这次开发过程中也发现了一些小而美的三方库，没东西写时拿来灌水好了。