未来，当我们构建金融大数据库时，真正构建出来是以云的方式提供服务，换句话说要选择一个基础的云。从IBM来讲是IBM SOFTLAYER，对大家来说是选择本地的，选择华为、浪潮、百度都可以，取决于IaaS这个层面怎么处理。接下来有若干的分析型中间件、存储等等，包括后来还有一大堆数据管理起来，要选择合适的存储方式，接下来再选择下面的东西。
这里涉及的东西很多，跟中间件和数据关系，虚机、虚拟化的环境等等都相关。要处理金融型的东西，比如证监会能够以消息的方式传给你，每5秒钟传来一组数据，这组数据包含过去5秒钟在上交所发生的交易的数量，谁下了多少单？或者大批次的怎么样的情况？收到了这个数据，如果没有合理的一套系统去把它存起来，假如丢了，可系统又不知道，在后续使用系统分析时就会有大问题。这笔数据看不到，在做一个重要决策的时候，这笔很可能是非常关键的。系统不仅仅得考虑随便拿一个数据放进去就可以，要考虑这个数据放上去是不是能够不丢，考虑在分布式环境下面有备份、有副本的时候，副本之间是完全一致的。再上面才是要构建的Systems of engagement，或者是Insight这些应用，当你建造这么大的数据库的时候，未来的应用要往哪方面走？
以上谈的是从数据角度谈未来的发展，讲洞察体系是未来的一个方向。之后是从云的角度来看，需要支持Systems of Insight，它的数据工作的模式和Systems of engagement并非完全一样，所以未来需要的方向是朝着更多地使用内存，更多地使用CPU发展。CPU很便宜，当数据量大的时候，可以用压缩，传统压缩以后，发现解压很困难、很痛苦。现在新的做法，把传统的数据全都压缩，压缩完了把它提到云里，在内存的集群里面进行解压，或者把它进行加密，加密后提到内存里进行解。因为CPU现在变得非常便宜，用CPU的代价替换掉存储的代价。
回过头来，为什么现在这么在意细节的这些点？说到底是构建的这个系统的投入产出是不是合理。如果投入产出不合理，很快就会垮台。这个里面到最后的结果，之所以有这么一个趋势存在，这些都会逐渐变得很经济实用，而且从使用者角度来讲，传统的交易提交后，银行保证说你只要提交这个钱不会丢，交易结束你不会在意它返还回来的东西。现在给你发一个微信，我期望你马上就能回复我，这个互动的趋势是非常频繁的，尤其当在全球化的范围之内，和美国、欧洲的人在开一个什么会的时候，实时交易的消息系统，希望看到马上能够起来，马上起来就得快。如果在这种情形下每个数据都要到硬盘上面读，哪怕到Flash上面读都是很慢的。这时大量使用内存是非常重要的。
Delivery。传统Delivery的方式，用一个平台开发应用，可以花一年时间开发这个应用，一年后上线。这个过程如果出了问题可以回头再修改新的版本，而且这个通常是找几台机器部署在机器里面，凡是有内网相连的都可以使用，里面会有用户控制等。但如果跟Facebook或百度比，会发现这样一种模式每过若干天可能就有一个新的小版本出来了，后台的人再做，小版本Delivery之后会做一些非常小的修改，这个修改可能把原来的东西弄坏了但没关系。传统上，做了一套系统得安装到机器上，现在都不需要了，APP是自动的，更新也是，非常简洁。在这种模式下，传统的方式如果天天去做，就会出现一些大问题。所以目前大家方向是说，Delivery的模式最好像百度这样的模式，有一个开发的环境和生存的环境基本是在同一个地方，这种模式，这种模式对大家来说也会同样存在。开发一个数据库，分析应用在上面构建，最开始是简单的查询，接下来要分析，再就是更深入的分析，再有更深入的应用在上面建造起来。开发人员工作的环境、生产环境是在哪里呢？它的更新的版本、更新的周期是在哪里？这个必须要考虑到，如果不考虑的话未来走这一步的时候会走不下去的。
Data Lake是一个新的概念。十年前就说海量数据了，从英文来讲没有海量数据这个词，对中国来说数据量大了这就是海量。
Data Lake是我们经常讲，外面有很多人也经常讲。但是他讲的时候，把所有东西都放在Hadoop里面。IBM讲的时候，你有很多东西是放在Hadoop里面，你有很多是放在选择关系数据库里面的，你有很多东西是放在你选择的Graph数据库里面，你还有一些东西是选择直接放在文件系统，放在Object Store里面。所以有很多不同的东西，不同的技术它适合处理存储、分析等等特定的类型的数据，不是所有的数据都可以用Hadoop搞定，这时就会面对一个情况，有很多不同的数据“库”，来之前我把这个“库”去掉了。数据库是非常固化的概念，里面有乱七八糟的东西，英文里面有相关的词汇，中文也有很多相关方面的词，只是行业里面目前还没有刻意的把它提取出来。有这么一些数据存储的地方，不同的技术实现的，当堆积在一起的时候，如果没有很好的机制管理起来，好比现在要构建的大数据库，一部分是交易数据，关于股票的，这里面一定会有股票的号码，交易的量等等，至少股票号码本身是哪一支股是在的，但是谁参与交易是不在这里面的，如果在里面也是脱敏过的。但是这些数据拿过来，你最好存放的地方是在关系型数据库里面，但是要放在Hadoop里面是不是可以的，是可以的，在上面可以构建新的查询数据，目标是要根据某个具体条件拿到某个股或者某一些股的具体信息，所以要有SQL查询会非常的好。但是在网上收了很多关于这家公司的URL，这些URL是不是也要放到，如果仅仅是URL本身放到关系数据库里面没有问题，但是如果这个URL里面的内容也把它扒过来，那这个时候扒过来的东西放到哪里？还放到关系数据库吗？假如里面有大量的文档、大量的图片，还放在关系数据库就不同意了，放在Hadoop里面是不是合适呢？也不一定完全合适，这时不得不考虑别的技术进来。换句话说，你是没有办法的，必须要很多很多数据的存储技术、管理技术合在一起。然后当合在一起后会发现，这些数据来源不一样，它们生成的方式不一样，时间段不一样、频度不一样。在这个过程中间，你会发现，要从交易数据库里面去找到相关的资料，得做很多思考才可能找到关键的地方进行差选，之后才能拿回来，对于一个分析数据大量手工在里面，效率低也易出错。于是不得不把这些数据之间的关联以某种形式把它们组织起来。数据湖很重要的是，能不能有一个数据的目录。这个目录是以这家公司为组织的目录，以交易量为组织的目录，以发生时间为组织的目录，以地点、形态，或者是以行业等等，所有这些组织的目录要有，这个组织的目录谁来构建？就是在构建数据湖的时候需要构建出来的。