所有栏目 | 云社区 美国云服务器[国内云主机商]
你的位置:首页 > 云社区 » 正文

数据的存储方法有哪些?

发布时间:2020-04-15 16:48:53

资讯分类:存储  方法  数据  数据  在线  脱机
数据的存储方法有哪些?

在线存储 (Online storage):有时也称为二级存储。

这种存储方式提供最好的数据获取便利性,大磁盘阵列是其中最典型的代表之一。这种存储方式的好处是读写非常方便迅捷,缺点是相对较贵并且容易因为误操作或者防病毒软件的误删除而使数据受到损害。近线存储 (Near-line storage):有时也称为三级存储。比起在线存储,近线存储提供的数据获取便利性相对差一些,但是价格要便宜些。自动磁带库是其中的一个典型代表。近线存储由于相对读取速度相对较慢,主要用于归档较不常用的数据。脱机存储 (Offline storage):这种存储方式指的是每次在读写数据时,必须人为的将存储介质放入存储系统。脱机存储用于永久或长期保存数据,而又不需要介质当前在线或连接到存储系统上。脱机存储的介质通常可以方便携带或转运,如磁带和移动硬盘。异站保护 (Off-site vault):为了防止灾难或其他可能影响到整个站点的问题,许多人选择将重要的数据发送到其他站点来作为灾难恢复计划的一部分。这种存储方式保证即使站内数据丢失,其他站点仍有数据副本。异站保护可防止由自然灾害、人为错误或系统崩溃造成的数据丢失。

数据的存储方法有哪些?

回答这个问题的关键是,“回测和研究会用到这些数据,有一定的查询需求”。

如果只是存储50T的数据,有很多种方法:(1)用二进制文件分日期分股票存储,(2)使用sql server,pg这样支持分区表的事务型数据库,(3)使用hive这样的离线数据仓库,(4)用Greenplum这样的开源或商业MPP数据仓库,(5)kdb+和DolphinDB这样的专业时序数据库。

选择一种合适的存储方法是为了更好的读取和利用这些数据。一般需要考虑以下几个方面的问题:

数据开发和建模是不是方便

如果只是简单按照日期和股票代码来查询tick data,基本上所有方法都可以用。(2)和(3)速度会比较慢。(1)需要自己来编程。

如果需要数据过滤,聚合(譬如按时间精度聚合),多表连接,(4)和(5)是最方便的,性能也不错。

如果需要更为专业的时间序列数据处理和建模,譬如rollup,sliding functions,window function,window join, asof join,pivot等,选(5),用其他系统都不是很方便。

另外说一下,kdb+的学习曲线比较陡峭。

是否需要用到分布式计算

虽然总的数据量很大,但是每次计算的数据量都不大,问题就会简单很多,基本上5种方法都可以使用。但是如果需要建模的数据量很大,涉及很多天,很多股票,用到的维度又很多,譬如在几十亿行数据上对几十个上百个变量跑回归,或者说分区字段和group字段不一致的时候做聚合分析,都会涉及到分布式计算,Greenplum和DolphinDB支持的比较好,支持库内计算,不需要移动数据,速度很快。其它的存储方法可以考虑写一个跟通用计算引擎spark的适配器,然后用spark来实现分布式SQL和分布式机器学习,但性能上会不库内计算差不少。

开发和建模过程中是否容易引入bug和错误

如果自己要写很多代码,不仅时间成本很高,而且极易引入错误。null数据的处理,多线程的处理,多个数据源的连接都很容易引入bug。

如果涉及到分布式计算,或者需要多次迭代,数据本身有可能是动态变化的,数据的一致性也要注意。一般数据仓库本身提供的库内计算,能提供快照级别的隔离,保证计算过程总用到的所有数据是一致的。Greenplum和DolphinDB都支持快照级别隔离。Spark不能工作在动态数据上。

运行效率如何

回测和研究虽然对实时性要求不高,但运行效率还是很重要的。因为研究的成功率很低,尝试了几百个想法后,才可能有一个能成功。每个idea测试的时候,你可能需要尝试很多个参数组合。所以,如果运行效率不高,非常影响研究效率。(5)中的kdb+和DolphinDB无疑是所有方案中效率最高的。

如果是机构商用,你的竞争对手用什么

很多交易策略,尤其是套利类的策略scale可能不是很好,用的人很多了,价格和价值就趋于均衡,机会就没了。所以你要赶在你的对手之前。


根据你的需求,简单总结一下,如果没有太多的预算,建议使用Greenplum + Spark,但是两者都是通用的数据仓库和计算引擎,天然缺少时序数据和金融的基因,有些场景用起来不是很方便,一些本来很好的idea,可能因为实现太麻烦就放弃了。如果有足够的预算,建议使用专业的时序数据库DolphinDB或kdb+。顺便说一下,kdb+对分布式的支持很弱,面对40~50T的数据,你可能要搞一台非常暴力的服务器才能解决。

留言与评论(共有 0 条评论)
   
验证码:
Top