基于MongoDB的大规模高频金融交易数据处理

巨建华：基于MongoDB的大规模高频金融交易数据处理发表于2011-11-2612:00|4760次阅读|来源CSDN|0条评论|作者CSDNmongodb应用服务器数据分析数据挖掘金融摘要：巨建华认为高频金融交易数据的主要特点是实时性和大规模，目前沪深两市每天4个小时的交易时间会产生3亿条以上逐笔成交数据，随着时间的积累数据规模非常可观，与一般日志数据不同的是这些数据在金融工程领域有较高的分析价值，金融投资研究机构需要经常对历史和实时数据进行挖掘创新，以创造...时至今日，“Bigdata”（大数据）时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。恰逢此时，为了让更多的人了解和使用分析大数据，CSDN独家承办的大数据技术大会于今日在北京中旅大厦召开。本次大会汇集Hadoop、NoSQL、数据分析与挖掘、数据仓库、商业智能以及开源云计算架构等诸多热点话题。包括百度、淘宝、新浪等业界知名专家与参会者齐聚一堂，共同探讨大数据浪潮下的行业应对法则以及大数据时代的抉择。ymall.com技术总监巨建华巨建华认为高频金融交易数据的主要特点是实时性和大规模，目前沪深两市每天4个小时的交易时间会产生3亿条以上逐笔成交数据，随着时间的积累数据规模非常可观，与一般日志数据不同的是这些数据在金融工程领域有较高的分析价值，金融投资研究机构需要经常对历史和实时数据进行挖掘创新，以创造和改进数量化交易模型，并将之应用在基于计算机模型的实时证券交易过程中，因此一般的数据库系统无法满足如此大规模和实时性，灵活性的要求。同时巨建华表示应用复杂性（包括高可用性、高性能，低延迟实时数据呈现、任意历史盘中实时数据挖掘和支持用户自定义脚本实现数据提取与运算）和数据规模（包括财务，金融+历史汇总交易数据、新闻资讯及研报以及每个交易日数据增量等）是数据存储方案面临的挑战。以下为文字实录非常荣幸今天能有机会站在这里跟大家分享一下，最近三年以来一直在做的一项工作，就是高频金融交易数据分析和处理。在这之前，跟刘工讲做的工作有点相似，我今天分享过程中不会讲我们如何去分析，如何去形成更好的模型来对数据做，拿着一些有用模型。如何高效对数据进行分析和处理存储，然后来解决大规模数据的挖掘问题。这是我今天主要给大家讲的，在开始之前大家会看到目前我从事主要是电子商务方面的工作，主要因为在前三年，主要是在做证券方面交易处理。可能在座如果是有做像这方面同仁，我们可能会认识。在开始之前，因为这个行业比较特殊，在我们之前CSDN有CTO俱乐部，我们在做相应活动的时候，实际上我们遇到的同事非常少。也就是说，这个领域如果我要向大家介绍如何使用MongoDB解决这个领域问题的时候，我需要给大家做一些关于这个行业背景的介绍。首先第一个证券，或者金融这个行业数据类型是非常复杂的，而且这个数据对于结构化，有些数据结构化是非常差的，大多数都是一些PDF，甚至是一些文本文档。但是有一部分数据结构还是非常强的，就是交易数据，也就是我们证券成交数据。大家炒股的时候都在用金融终端看我们股票数据变化等等情况，如果如果有一些高起点客户会用技术指标，来进行数据分析。在做数据分析的时候会接触，我们数据里面有资金持仓项目，有机构评级报告，还有新闻咨询，交易龙虎榜。如果我们平时接触少大家感觉不会很熟悉，所谓基金持仓，我们所有基金公司对市场上的股票持有情况，也就是说，每一个每个咨询公司手上拿着什么样股票进行发布，这样数据连续20多年沉淀下来，数据沉淀非常强。研究报告主要是机构，我们大家都知道很多分析师，每过一段时间就会编制一些研究报告，对每一支股票进行分析，这主要是文本类型的，主要以文本来展现。另外由于用户习惯不同，我们股票在变化过程当中，不同用户都采用不同周期K线数据来看盘，比如分钟，月，周年进行统计，形成所谓日K线数据，就是统计出来在某一个时间段第一个价格，也就是开盘价，最高价格，以及最低，收盘价，包括成交量，成交额等等。这样的数据之所以会形成这样统计的原因，一个是用户习惯，第二这个差异数据量实在太庞大了，如果我们不提前做统计的话，在形成这样大量交易，我们想在盘中持续拿到这样统计数据，系统都会很吃力，特别是在我们之前数据库系统，以及分布式运算方式没有根本性改变的时候，最佳解决方案当时也就是预先把这些数据统计出来，如果说我们突然想之前，我们假设没有提供33分钟的数据，我们想对历史数据进行回归，这是一个非常庞大，这个时间会非常长。也就是说，如果我们计算，甚至说这样认为是不可完成的，在我们没有引入更好计算机制和存储机制之前，也是这个行业一直以来面临的问题。关于盘口和成交明细不多说了，都是非常多数据。之前数据实际应用中会不会通过终端展现出来，我们可以看到证券简单截图，我们看到前面各种类型通过相应软件UI来展现，左侧分析图是通过分众线实现，当前买一卖一，包括后面买实卖实等等。这些数据按照目前上交所更新频率，基本上可以保持每3秒钟有一个数据更新，都有新增变更。每天我们大约有20条左右的数据变更，这样变更之前由于没有能力去分析，最终都被通过统计的形式，只是取得一部分，比如我们刚才说的汇总值，大部分数据都丢掉。实际上这种数据都以整个金融模型分析，包括怎么通过股票数据盈利都是非常有用的，在国外也有大量对冲基金在做这些事情，发现庞大数据发现某种交易规律，最终发现盈利，这是其中一个应用场景。第二就是我们刚才谈到如何通过这些数据进行自动，机器自动交易。当然机器自动交易优势大家都可以知道，首先第一个分析数据非常快，我们人脑根本不可能对那么多股票数据，A股有140多支股票，如果在美国股市是有1万多支股票，这么大股票交易过程中如果没有相应的机器来代替人脑做一些事情，根本就没有太多精力能抓住那么多交易机会。另外我们人在做判断的时候，很受形式的影响。如果大家有炒股精力，当你股票涨一点，跌一点，或者涨停，爹跌停的时候大脑不受你操作，机器就可以避免。即使我们机器能够做这样自动交易的事情，也可以想像，如果每天用21条逐笔成交数字，我们一年两年下来之后这个数据量非常庞大，这样一个庞大数据，不是说我们只是通过机器就能搞定，实际上是一个非常大的工程型问题，从数据如何去存储，到这些数据如何建模，计算，到最后形成结果之后如何应用这些数据，那都是非常庞大的工程。所以说，在这里我们首先需要解决，这么大数据，我怎么能够有能力把他非常好的存储起来，根据我的业务需求能够非常快速的把这个数据拿出来使用，而不是说我要使用这个数据的时候，我需要非常长的时间，甚至我根本就拿不出这个数据出来。我们知道具体的应用场景之后，接下来我们来看一下目前行业内主要采用的这种数据存储方案，以及他们的一些优缺点。这个应该是在04年以前大多数公司采用的这种，对证券行情数据处理的方式。我们都可以看到，基本上从交易所过来的数据，从交易所网关过来的数据全部通过自定义文件系统写到文件里面去。前端会通过另外一个进程，这个进程为相应客户端提供服务，为了能够保证性能做法，同样数据被写到无数台机器上，重复写到N多台机器上。我们在座有做金融数据公司都很熟悉这个模型，把所有交易数据按照相应的统计方法，统计完之后把统计结果直接写到文件系统里，每天数据会形成一个文件，到收盘之后在归档到最大文件里。最后我们就只提供，一个我们提供历史的统计结果，把非常大的21条数据整合到可能只有2千条，3千条数据给用户进行显示。第二对于详细数据我们处理方式，原来处理方式，我可能只提供一周数据，你如果想看更详细，对不起看不了，因为我们系统，整个系统不支持这样的操作。在这样一个模型下，他的缺点，我们可以知道，因为数据量非常庞大也比较复杂，就能导致这个程序开发起来非常低效。而且为了追求效率，这样系统都会用C++来开发，这个时候整个开发周期会非常长，开发完成之后，当你面对几十种数据类型文件定义不同结构去操作的时候，你会发现想要产生一点变更，某一天想增加一个新的数据类型，这个代码内容会非常恐怖。虽然说我没有很好管理方案，我们会做一些好的测试框架，从开发到测试周期也是很长的。实际应用过程中我们会发现不同，实际上有一个职业叫金融工程师，金融工程师他的工作主要是结合计算机和数学这样的专业，包括金融这样专业来提出一些新的模型，对数据进行挖掘。如果我们直接进入这样专职，当然这个在国内目前还不是很多，可能很多研究所都已经不少，假如我们仅仅提供这么一个系统来支撑的，我们想出一个模型进行测试的时候，根本没有办法支持，你在多工程师都没有办法完成程序编写，包括中间还涉及到测试一整套过程。即使这样一个比较差的架构，实际上现在大多数公司，包括你们用的很多股票软件还是在前面这种方式，因为比较成熟，也比较稳定。第二，这些软件已经很久，不管你看界面，后台逻辑很久不用变化。因为对普通用户来说，可能已经比较足够了，对于高端用户还是很缺的。第二解决方案，我们现在知道上交所跟国内公司在采用Timesten解决方案，比关系系型数据库能够快10倍，这是一个Oracle类型数据库解决方案，软件和硬件成本会非常贵，因为他只支持通过Repllcation，没有办法解决横向扩展问题。当我数据量增长的时候，我必须要做两个处理，第一个是我可能内存没有那么大存那么多数据，我只能把过期历史数据还要存到，持久化相应数据库里去，或者其他存储结构力。如果一旦放到关于云数据库之后，问题就来了，每天数十条问题处理起来非常，10年，20年，甚至再过30，50年之后这些数据怎么处理，最终又变成一个看起来我们都有存储，实际上就没有办法可用的数据。在这种情况下，当然我们还要去做很多复杂的开发，我需要去写代码来实现，把Memary相应数据库，相应结构，同时也要去解决一些，因为使用，当然我在提这个的时候，实际上已经有一些解决方案能够把数据库同时写到硬盘上。我相信Oracle的这项技术，了解的人都非常少，我们很难找到真正熟悉使用这个技术的人。我觉得这个方案也不是特别好，我需要自己写程序来实现，写非常复杂的逻辑就为了程序扩展，我觉得这个也不太好用。因此，在了解这个之后，我们就知道，实际上目前我们的架构面临的挑战一个是应用的复杂性，也就是说这个复杂到，他首先需要一定高可用。因为当你客户全部在拿着你的终端，或者你的产品炒股，或者在看数据的时候，如果你中间出现中断，性能比较低下情况，很快你就会丢掉所有客户。同时，如果是在一个投资公司里边使用这个产品，出现商用不可用，或者效率低的情况，直接影响到可能就是投资收入。如果一个咨询公司拿着这样一个系统操作，我们都知道他们手上钱是非常多的，随便是小点事故就可能导致大量损失。第二，由于目前金融工程，我们说的发展，我们会发现不同的金融工程师经常会提出一些需求，对任意历史和数据进行挖掘，这个挖掘需求出来之后，我们都知道不管你用什么，可能你一个读取会把很多硬件资源全部站掉，导致其他服务受影响，如果有大量用户在做挖掘，不管我们系统怎么拆分其实都是很困难的。另外关于数据规模，刚才也提到，数据规模里面关于财务数据和金融一些历史数据，他们规模不是很大，毕竟中国股市时间还不是太长，现在算起来也就40多个G，新闻咨询与研报是文本数据，怎么来存。但是存在数据库里也有公司这么做，现在实际上真正我们所谓高品质数据，高频交易数据，指的就是目前上交所和信交所所推出来，能够真实把每一笔交易完全发送过来。前我们拿到都是一个每5秒一次的快照，自从06年上交所Level-2推出来之后，我们就能拿到完整交易名类，每天增长容量有1.5-2G之间，这个还在不断增长。所以，我们面临问题如何能够很好，先不说怎么挖掘这些数据，如何快速存储这些数据，快速提取诗句，为挖掘做准备。在这个过程中我们做了很多方案，甚至我们也考虑自己来编写相应的系统来实现，通过最终考察和我们对整个项目评估之后，我们选择了以MongoDB作为高频数据存储。具体我们为什么会选择的原因？这个项目大家都可以从这个过程中知道，我们最关注的是性能。当我们看到当时是1.4版本的MongoDB漂亮的B