金融大数据架构概述与应用

问题导读：
1、如何设计金融大数据架构？
2、IBM如何看待未来大数据趋势？
3、架构设计容易忽略的细节有哪些？



【导读】本文选自杨晓洋于2016年7月7日在清华大学经管学院伟伦楼所做的《金融大数据架构概述与应用》的演讲。他在介绍IBM眼中的几个大趋势的同时也讲了一些大数据基础架构的内容，从技术问题和实际需求出发，采用多个案例说明了构建金融大数据架构的具体细节和重点问题，以及处理大数据时候要做这些考虑的原因。



IBM分析事业部

IBM分析事业部是在过去一两年间逐步成型的，成立后分成了若干个小部门，如Analytics Platform、CLOUD DATA SERVICES。非关系型NoSQL的数据库中，Cloudant用的CouchDB就是CLOUD DATA SERVICES其中之一。

三种模式

过去几年，关于大公司企业的转型比较多，被新的一些业务模式冲击得很厉害，比如Social、mobile。也不讳言IBM目前也在转型中，可能未来会有一种新的模式支持上述第二种状况。软件的能力提交主要有软件制造商销售Perpetual License模式，或者软件制造商提供以云端服务的模式。这两个模式外很可能还会有第三种模式，就是由技术厂商提供技术，由使用者自己构造它的云的服务。目前大家就是处在用开源和自己写的状态上。



Watson。Watson本质上是一个巨大的类人的大脑。原则上构建了很多认知的能力，与人对话，有分析引擎，通过学习和一些技术手法，把不同领域里面构造的技术通过服务呈现出来。例如，Watson Doctor考过美国医生资质，理论上它拿到这个资质后是可以行医的。但IBM目前不会走这么远。另外一类，Watson有一个curator for financial data。在投资方需要对某些特定的领域进行个股研究的时候，需要收集各个股的相关资料，包括报表、年度报告、公开的新闻报道、分析师的分析报告等。这些收集起来的数据非常繁杂，大量是属于半结构化、非结构化的数据。它就是要把这些资料分门别类地理解，抽取关键信息，交给后台的分析引擎，分析引擎再做出一个决断。

再谈INSIGHT CLOUDSERVICES。Watson很具体化到某一个具体的行业里面，到了INSIGHT CLOUD SERVICES这个有可能是属于类似跨决行业，比如和Weather。去年IBM收购了The Weather Company。传统上，IBM是不碰数据的，给出的都是技术。给出数据库，数据放到库里面，跟IBM没有关系，也不去碰。现在IBM一定要去碰数据了，有些数据拿不到，就需要合作，比如Twitter，IBM要与它协同协作。统计显示，Weather这种数据每天的查询量非常大。像这一类的数据，它对各行各业的业务的影响都很大，IBM还会持续地去关注。

目前来看，IBM是朝着跟云合在一起，跟分析、认知合在一起的方向在发展，这是一个大的背景。

Awash是一个很特殊的词，这个世界被浸泡在数据里面。我们在用代码重新构造这个世界。如果把现在的程序员角色想得比较高大上一点的话，就相当于上帝指导下的一批重构世界的人。比如，我们原来面对面说话用耳朵就能够听了，现在用手机进行，手机中间构建的这个框架，是让传统当面做的事情可以远程做到，甚至手机可以理解人的对话，当成一个能够理解人的实体。实际一定程度上，我们是在重新构造这个世界——通过程序的方式、通过编程的方式、通过认知学习的方式构建世界。未来的走势在IBM看来是一个认知的过程，最终所有服务必须经过认知的技术来实现的。

IBM在过去三十年间看到的大趋势基本上都兑现了，有理由相信，现在看到的大趋势也会兑现。至于什么时候兑现，还需要时间来验证。

在未来的世界，数据就是矿藏。当然数据是原始的矿，相当于原油。如果原油不经过炼制，人类是没有办法使用的。现在每天有大量的数据，包括构建金融大数据库，每天的交易数据、互联网上的数据，社交媒体上的数据等。目前很难直观地找到这些数据的关联，必须要通过一些手段。我们就把这些手段类比成原油的炼制，用化学手段把它分离出有价值的东西，这样数据就可以驱动整个世界。

就这些所有的数据来看，用得比较多的这些数据，最重要的是数据增长快、非常巨大，种类繁多。就如刚才提到的Watson curator for finance data，虽然拿到的数据是别人做的，但最重要的应用的目标是分析。拿到一堆数据，重要的是怎样拿到里面的价值。挖这个价值的时候需要大量地使用分析引擎、分析工具。就像在一个湖里捞鱼，你要用很好的工具，是用炸药炸还是用网子捞？捞一些小鱼还是大鱼？这个过程中间必须要有针对性的处理。要点是说看到了这些数据，在一个大湖里面，要把有价值的东西取出来才能支撑你的业务。假如跟京东谈，最终的目标是它要使得你下单买东西，这是最主要的核心业务。它一切的分析工作都是围绕着，怎么让一个个体能够更方便、更快捷、更不过脑子地做决定买一个东西。我们知道买东西大部分都是冲动性购物对商家是最有利的，最终都是围绕这个目标进行的。这里对于分析的Insight，把数据之间的关联找到，这是一个大的趋势。

众所周知，数据并不像我们以为的那样整齐，找起来非常不方便。大家都以为谷歌查询的数量很大，实际上Weather每天的查询量更大。谷歌是一个大的搜索公司，未来可能会提供很多分析性相关的东西，把很多东西都放在里面，每天在全球查询量是3.5 billion，而Weather是15 billion。它除了查询天气预报以外，传统查天气是查北京市的，温度是多少，Weather里面有一些细节的东西，在北京朝阳区的小片里面那个大概的温度是多少，中国这边没有做到，但在美国做到了。这里要求对数据的分析功能，比起在谷歌那边要严格得多、分析要精细一些，所以在这里，支撑这15 billion的查询后面有分析引擎，目前我们正在把这个分析引擎往开放的框架中引。

数据生成数据的量是非常大的，包括做一次网购。你是用数据生成了一堆数据，看到那些所有的产品是数据，看到数据决定要买，它就再生成进一步的数据，然后这些数据再往后逐渐放大，真正要做分析的时候，这个数据已经到1000倍了。所以在讨论金融大数据时，不要只看到拿到的某一部分数据。这些只是其中最初级的原始部分，真正需要的是到最后的结果。我们考虑构建的是从1到1000倍增长的数据来看未来的数据的服务，所以当构建的时候，要想到的是现有数据库的1000倍以上，在分析过程中还会产生新的数据，可能对进一步分析有很大的价值。

中间分析的结果很重要。IBM最近在跟很多国内大数据相关的一些产业，比如交通。交通常用的有几类数据，一个是手机信令。对交通来说，这些人在城市里的移动，从哪个点到哪个点，意味着他们的居住地、工作地。这一类人在一个城市大家都从A到B，从C到D，互相交叉，对城市交通产生很大的需求，好的城市交通规划应该是平衡的，首先你要知道这个平不平衡，你得了解这个人到底在哪里，于是手机信令成为一个很好的点。拿到手机信令以后，它不是很准确，存在误差。这种情况下要描述一个人一天的轨迹，其实是模糊的状态。描述这个轨迹下来以后才能进行分析，描述完这个轨迹，首先是对这些轨迹的数据，分析结果的数据要存起来，以便于下一步分析使用。随后描述这个人的轨迹、停留时间，再通过各种分析的手法，区别每个地点的类型和这个人的职业等信息。这些数据要存起来。把原始数据通过扩散关联的方式找出后面，后面分析结果还要再进一步的考虑。

传统上，数据通常是数据源到结果，目前大家用的比较多的是这种。人们更关注把数据放在哪儿，查询找到它是什么，这是基本的模式。像万得那样的服务，目前基本就是查询，重要的是它使查询变得简洁，做一些预分析，谁和谁的关系是怎样的，把预分析做死，把它固化在其系统里面，固化在其系统里面，就形成关联的固化关系，这个信息被存储起来，所以在万得的系统里使用、查找就很方便。找到它，尤其是它关于整个跟金融相关的元数据模型的时候是非常好的。但据说万得的元数据模型是从Bloomberg学习来的，中文化并加入中国特色，给投资人提供很好的界面。据说目前90%的市场都是万得的，这个领域以万得为例来讲，虽然它的创新并不大，但可以把这里的东西做得很精细适用。

Systems of engagement。传统认为，信息系统本质上是交易系统。把数据提交给后台的数据库，数据库进行交易处理，永久性存储起来，用可备份的方式使得这个数据不会丢失，这笔数据的交易就完成了。数据系统关心的是数据被永久存储且不会消失，这部分叫Systems of Record。Record是记录，是交易型的、记录型的。

社交媒体、移动、云服务不断发展，比较有代表性的就是微信和银行。微信不仅是提交一个数据存储，而是它有很多关系的产生，人和人之间、数据和人之间、人和系统之间、系统和系统之间都产生大量的数据，这些数据的存储、管理、后台的支撑、经常性的变化，它可能对交易的完整性不那么在意。相对来说，发一条微信丢了再发一条，可是在银行存一笔钱，银行说丢了，大家肯定不干。银行对数据交易的完整性要求非常之高。这个就是产生了Systems of engagement。

Systems of engagement接下来是分析洞察。当你有各种System Insight，就是分析洞察，像构建的数据库，当有大量的交易信息，股票交易信息和大量的社交媒体信息，这就属于System Engagement。这两类信息融在一起，找出之间的关联，发现隐藏的关系，这个时候就到了System Insight。这是IBM和若干公司都非常一致的看法，这是一个基本的概念。这是传统到现在到未来的变革。未来变革大量使用的就是分析引擎。

未来，当我们构建金融大数据库时，真正构建出来是以云的方式提供服务，换句话说要选择一个基础的云。从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里面是不是合适呢？也不一定完全合适，这时不得不考虑别的技术进来。换句话说，你是没有办法的，必须要很多很多数据的存储技术、管理技术合在一起。然后当合在一起后会发现，这些数据来源不一样，它们生成的方式不一样，时间段不一样、频度不一样。在这个过程中间，你会发现，要从交易数据库里面去找到相关的资料，得做很多思考才可能找到关键的地方进行差选，之后才能拿回来，对于一个分析数据大量手工在里面，效率低也易出错。于是不得不把这些数据之间的关联以某种形式把它们组织起来。数据湖很重要的是，能不能有一个数据的目录。这个目录是以这家公司为组织的目录，以交易量为组织的目录，以发生时间为组织的目录，以地点、形态，或者是以行业等等，所有这些组织的目录要有，这个组织的目录谁来构建？就是在构建数据湖的时候需要构建出来的。

换句话说，要构建未来的东西不再是一个库，可能是一个湖。湖里必须要有方式，鱼在哪里、水草在哪里，要不然的话这就是一个数据沼泽，虽然数据都在里面，但是捞很痛苦，捞一把有虾、有鱼、有泥巴、有水草，还要再进行过滤分析。所以，Data Lake是我们必须要面对的。

分析，是层层递进的。从分析到报表，到指引，做预测、做决策，再到指导你的行动。认知的过程，建构在Data Lake的基础上，再做一些基本的分析，可能会做一些预测的分析，这个过程中间还有自学习的机制，从数据的生成大数据的被分析，到数据用来做预测、做推断，到数据用来做决定，再到数据自我学习，这是完整的循环。

这样描述的过程，会使人觉得这听起来像是“人”的过程。从冯诺依曼体系产生到现在，大家追求的就是怎么让机器做得像人，但比人做得更快，AlphaGo就是比人做得更快，它的心理不受时间限制，人还会受到限制。

从系统角度来讲，就具体的某些单向指标来说，以暴力方式构建的系统已经远远超过人了，但整体上还比不过人，尤其是感知、学习、预测、适应、模式识别等等。在语意之间能够来回翻转，这个层面还远远赶不上。目前的方向是朝着认知，朝向构建人脑的模式。人可能走100步它要走10亿步。

再往下更复杂的，在构建一种关系的时候。股票、公司和投资方，和它的下家行业，以及它的竞争对手等，这么复杂的一个关系，如果不构建出来，这样的金融大数据的服务肯定只能提供一个查询，不超过万得。接下来，认知公司进来以后你就会OUT了。要把这个关系建立起来，因为这些关系是很动态的，常常在我们回溯的时候是找不到，因为按照行和列描述数据的方式无法做到。Graph Database可能是一个很好的模式，Graph Database可以描述清楚大量复杂的关系。

举个例子，某些数据中的一条，大家看这么几个数据，每天的扫描影像个数120个Million，是中国的某一个客户，这个数量相当于Facebook一天的数据量，它的照片量，我们认为只有像Facebook这样的或者百度这样的才有大数据，其实企业里面很多都有。不用管它怎么产生的。把它放到峰值上去，会发现它每秒钟是10万个影像，10万个影像不仅仅是10万个交易。每个影像它有若干的描述性的数据，每个影像还有相关的东西结合在一起。这10万个影像对后台来说有数据库存起来，交易是10倍的。换句话说每秒钟是100万，这个数据是非常大的。Facebook现在的峰值更大一些，当时也就是10万到50万的样子，现在可能能做到100万。

换句话说，我们看到在金融领域的大数据，如果放到峰值的角度来考虑，一定是非常庞大的数据。为什么要考虑峰值？传统分析的时候就会听到说一天多少数据。治水跟治数据是有很相通的地方，最近武汉的大水，武汉大水过来武汉市三年前有一个投资计划投了130亿，说能够处理15个东湖水的量，如果当初我来审核这个项目的时候，我会问这15个东湖水的数量是一天过来？还是一个月过来？还是在十分钟过来？这是不一样的，在数据层面，现在金融服务器上来了，全国的散户都来找你了，1亿散户投资人要来找你，你能够处理吗？你怎么处理？这相当于说15个东湖的水在十秒钟之内经过武汉，你能够处理吗？这是非常简单的我们需要面对的数据的问题。你有这样的数据在那儿的时候，每秒钟10万，相当于100万的数据每秒钟要处理的时候，底下的平台通过什么方式建造？买IBM主机没问题，任意扩展。但是这个成本付不起。如果用最便宜的机器，最便宜的机器一台肯定处理不了，就得是非常庞杂的集群，这个集群是分布式的，每台机器都有可能失败，雅虎每天的硬盘都有数千个坏掉，硬盘要坏掉数据只有一份肯定死了，怎么处理底下的东西，归根到最后，最终的总量，这个数据要存15年，最终总量就是100多个PB。以前讲PB是非常大的数了，Hadoop讲说我们能够做PB的数据那是大数据了，可是你看看像这样一个机构，它可以达到几百个PB，如果存15年它的总量能够到达1.3个Trillion，这是万亿级的数据。最近几年我们跟客户沟通，把他的数据用峰值的方式进行分析以后，我们发现，包括它的总量，所以你构建一个系统，有很多具体的细节需要去不断地考虑，也有一些现成的技术处理这个事情，但是首先得对所面对的这个数据要有深入、充分的了解，你一定得知道峰值是什么情况，两头的峰值，数据进来的峰值以及数据出去的峰值，数据进来的峰值就是说你的数据源从哪里过来，它每秒钟大概在什么时候达到峰值，有可能最大的峰值是什么？数据出去是说你的使用者在你这儿查询，在你这儿做分析，它大概的使用情况是什么？所以这两头你都要搞的清楚，数据总量准备存多久，存15年以上，你的硬盘寿命只有3年，之后你的硬盘是不停的换，还是量不断增加，硬盘不停的换，还是会把一些冷数据放到特殊的地方去，类似这些问题你都在这个过程中间要进行考虑。

这里有一个数据，这是10%的增量，这是按照15%的增量，都到了万亿级别，所以我们当时在考虑解决这个问题的时候，可能跟你们在考虑解决你们问题的时候类似。这是其中一类的数据量，另外还有的数据量，就是到网上大量爬一些数据，跟某些特定用户关系的一些数据爬回来，还有大量的报表等等，它是一个金融机构，也要爬回来，所以这样的话就意味着，我们当时面对这些数据的类型跟你们今天面对的数据类型非常接近，这是为什么拿这个例子来讲的原因。

这是我们当时用来处理设计的目标，这里面有几个点想提醒一下。

一、数据规模。未来整个数据库最终会有多大规模。这个规模设计的目标是到几十万亿条规模设计的。100以上的PB，我们心目中的目标是按照EB这个级别来设计的，可以设想一下，如果一个节点10个硬盘，1个硬盘按照在2TB，可以看到这里要有多少个节点，如果再乘以3，或者再乘以1.75，就可以算出来。这是每一个物理的节点上面会有多少个数据，这是每一个系统里面对这些数据进行索引有多少个元数据。

二、带宽规模。在峰值的时候需要多大的带宽。

三、性能。每秒钟100K，10万到100多万的级别，同时它的响应必须在10个毫秒以内。这个地方是说，支撑的共识用户数几百万人，现在像腾讯都是几十个Million，已经是非常高的人数了。

四、高可用、弹性扩展、长期存储。一个数据能够在底下存多久，所以这个是我们当时对刚才那个需求的一个总结。

五、容错。这个系统必须是容错的。性价比要足够的低，如果成本太高了是没人用的。

刚才谈到，如果用低端的机器降低了成本，但错误率提升，错误可能发生在硬盘、机器、网络、机器和机器的交互上面。容错是必须面对的一个重要方面。用低成本的设备必须是容错的，无论是使用现存的云服务还是自己做，这一点都逃不掉。

No SPOF，讲容错是说一个数据进来，不管哪个环节出了问题，系统都能够自动地恢复，恢复是有度的，如果我存了三份，分别把三份存在不同的盘、不同的机器节点上面，在三个不同的机器分布在不同盘上面，同时出错的概率是非常低的，这里面很重要的节点，当我这个系统，如果我把一个提交给你在系统的每一个层次里面任何一层上面都不能只有一个单点来应对，在第一版的Hadoop上面就是一个单点，它的NameNode就是一个单点，二版的把它改变了Active/Passive，也会有一些问题，这个是说我这个节点死了，马上再启动另外一个节点，这中间对于规模比较大的，频度比较高的应用，这个中间启动切换的1秒钟或者0.5秒钟就有大量的数据传上来，就可能丢失了。

Facebook曾经做过一个，把HBase做成Active/Active，它专门有一支团队做这个事情，两边同时在写，对底下的存储层来说必须要处理，这两边同时写和原来系统里面写是什么关系，是不是需要注意到分布式过程中间的数据是不是能保持一致？这个是非常复杂的。

这几个数据大家一定要看。一次寻盘要10个毫秒，换句话说，如果数据在盘上，当你的请求是要来查这个数据的时候，假如一次读盘能把这个数据找到至少需要10个毫秒，这是什么意思呢？10毫秒×100就是1秒，假如这个盘上有你要的数据，每秒钟能够支撑的寻盘就只有100个，假如你的共识的并发是在每秒钟10万的话，数据分布在N个盘里面才能支持每秒钟10万。设想一下，在这种情形下，如果所有的东西都在盘里面是不是很困难，或者目前的盘是不是做不到。这个10毫秒还是说这个盘是空的，随着盘的数据存的越来越多，每次到盘上去读的，找到数据的可能性就越低。换句话说，有的时候高达10次读盘找不到你的数据，可能要多15次、20次，为什么呢？现在数据量都是几个T的，管理这个数据的文件系统会把其中一部分缓存起来，不会全部缓存起来，没有缓存起来就到盘上读，读的是倾向于某个地方存这个数据的地方，相关的质证是在10个地方，才能找到数据。这些基本的东西在你们考虑的时候一定要考虑进去。

考虑数据从备份到M/S、MM、2PC、Paxos，是说数据的一致性。也是谷歌的例子，这是经验性别东西在里面。一致性交易。这个一致性在Backups就是Weak，在Backups里面没有交易，比如你要做M/S里面，你只能做到Eventual Consistency，这是什么意思呢？最终一致性。最初的问题来源是同时往三个地方写了三份数据，这个三份数据之间是不是一致的我们不知道，需要通过一些特殊的方式来保证。往往这种情况下，构建新的数据时，传统要等三个一致的时候才能回过去说数据完整的写好了。现在可以是两个一致，或者是一个写进去，就可以知道数据写进去不会丢了，等到那两个再返还回来时再确定它是一致的。还有若干的细节，包括分布式的讨论。

这里很重要的问题，两阶段的提交肯定是强意志的，不管是M/S还是MM都是Eventual的，这里就会出现一个问题，像经典的购物车的问题，它就有可能出现数据丢失、数据不一致的情况出现。很多做传统数据库的专家，他们去挑战Amazon的老大，它们是最早做Eventual，在学术界提出Eventual最终一致性，就去挑战这个，最终一致性到最后的结果就是最终不一致。当然大家可以互相争论，这里确实有一些学术问题值得讨论，包括微软把一堆分布式数据专家请到微软研究院。但是你看他做出来的Azure效率高，性能也没它好，尽管没听说它数据丢失，但整体上来说并不见得比Amazon做得更好。理论上可能很成功，实际操作过程上不一定会做得很好。大家有机会可以把这个东西记住，有很多有价值的东西。我们设计了一套系统基本上是在Paxos这个领域。

底下有很多细节的东西不说了。比如说Peer-to-peer，这是在Cluster里要设计三个并列点的时候，从个人的角度来讲，不希望是Master/Slave模式——它支持的是Eventual。在处理这个数据里面的时候，我们希望是既有Eventual，同时也有强一致性。所以在这里，我们就采用了Peer-to-peer的模式，而没有采用Master/Slave模式。

Meta-data，这个挑战更大，是结构化的数据。结构化数据最好的方式是放在关系数据库里面，这是最简洁，非常成熟，很稳定等等，但是关系数据库不能很好地Scale Out，它在分布式的环境下面做得不太好，它要么就是效率非常的低，要么就是只有单独的一台机器，所以这里面有很多矛盾，我们采用特殊的方法对它处理。我们刚才提到每秒钟100万个影像，每个影像是有元数据描述的，意味着每秒存100万影像的同时必须每秒存100万条元数据存到我的数据库里面，目前没有已知的数据库可以cost-effectively处理这个事。

你那里面分出来，可能能分出三类数据。一类是放到关系型数据库里面。一类是对象类的数据，包括你的图片、网页、文本、PDF文件等等。还有一类就是，你把这个里面的数据和这个里面文本的部分提取出来变成索引的，就是现在大家比较熟悉的，跟搜索引擎相关的一些东西。这三类数据，你们未来建构里面肯定都会碰到，所有我们碰到的挑战你们也可能会碰到，取决于看你底下选择什么样子的平台来实现。对象这边，我们采用的是Openstack Swift，来做Object Store，但是光用这个还不够，我们还对小文件进行了特殊的优化，你们可能也会碰到同样的事情，你可能不需要去管Swift底下做了什么，或者你用Amazon、华为的对象服务器都可以，你要求它给你的指标都可以了，不做研究，也没有必要走到下面。

小文件的Optimizer，这是一个技术，我们物理盘构建的结构，当年IBM做硬件盘的时候用了很多成熟的技术，有很多创新在里面，过去很多年我们还在这个硬盘上生活着，我们现在构造的大多数数据都在这硬盘上面，随着数据量越来越大它有一个限制，只有一个读头，这个读头每秒钟最多能处理100个读或者是写，这是它基本的限制，由于数据量增加限制越来越多性能就直线下降，要解决的问题是用特殊的方式做成平的，这样你的盘在三年生命周期当中是保持一致的，我们做的这样一个东西。

当要用关系数据做这件事情的时候，金融的数据，尤其是股票交易的数据过来，一定要保证它参照的，换句话说它必须是Atomic，不能让它变成Eventual，Base在这个数据上面是不合适的。那些其他的数据是可以用Base来做的，但是在这个底层存储上必须要做到Atomic，这种情况底下要保证至少存三份，才能保证足够的冗余来处理这件事。这边可能也要用到Object Store，这是我们当时做的东西。

这是Facebook的例子，Facebook来用HBase做Messaging，然后它发现单机是不行的，一旦单点失败了Facebook用户和用户之间、用户和系统之间的交互就会失效，于是做成了双机版，双活的版，到目前我还没有听说进到Hadoop里面去，它底下的对象是Haystack，Haystack有一篇很著名的论文，你们可以读一下，里面做了很多优化。

谷歌的Spanner。谷歌是很有意思的一家公司，已经金蝉脱壳了，换了一个名字。它在数据的层面，十几年前它跟大家说SQL死了，大家应该用NoSQL，于是一大批人跟着它走，三年前它说SQL还是很有用的，于是大家就不知道怎么办了，十年前跟着你跑，跑了半天又绕回来，不是在忽悠我们吧？本质上SQL还是有用的，它做的F1&Spanner本质上就是实现全球的SQL，它把它叫第一个全球化的SQL，这个稍许夸大了一点，从使用上来讲是第一个使用的，别的有一些内部的秘密没有公开。它里面很重要的一个东西，它的数据是通过Paxos来维护它的高一致性的，Paxos是很著名的算法，大家有机会可以专门讨论。它的Paxos是在全球的大数据中应用，我们知道，数据一致性里面，分数据管理里面很重要的难题，根本上我们是用一个时间，以这个时间纬度作为数据到来的先后顺序决定数据的一致性，换句话说，当你有N个数据分析的时候，每个数据时钟有些微差异的时候，当你达到毫秒级、微秒级、纳秒级的时候，你的时钟和时钟之间的同步就变得异常重要，精度也变得异常重要，谷歌做这个的时候，每个数据中心上面要支一根天线接到GPS卫星，用GPS卫星时间来衡量先后，这是分布式问题的一个本质。谷歌未来会走成什么样子，这个不清楚，目前它们内部在使用这个事情。

数据湖里面有很多，这后面有很多数据“库”，中间有原始数据，有一个目录，这边有很多数据和IT之间的交互，这边有很多读的交互，底下还有很多数据治理，数据治理是说你的数据进来什么人可以以什么方式把数据存进来？什么方式把数据提走？以什么方式使用这些数据？尤其金融数据很敏感，你们构建这个的时候必须要考虑。

其他跟数据进来，数据怎么清理，还有分析的工具有关，这是架构在数据之上的，这个概念知道以后，用什么样的数据和技术，大家可以来考虑。

这个是在架构数据库中间，中间要用大量Cloud或者Hybrid Cloud方式提供服务，使用者可以自服务的，构建一些UI功能让他在界面上自己编辑，就可以编辑出很多应用出来。从描述性分析到诊断性分析到预测性分析，再到指导性分析。指导性分析它的意思有点开药方一样，我已经知道你得什么病了，告诉你该吃药了。这一类分析是我已经80%、90%的确定。这个走势是这样的，于是你作为关注这个走势的这些人应该做这些事情。

最后一个是自学习，最终你构建的金融大数据中心里面，是在若干个方面提供服务的，如果仅仅是玩票，可以在某些领域玩得深一点就可以了，这个没有问题。

这是未来可能发生的，Data Lake和Hybrid Cloud。有的人构建了一个企业内部的数据湖，有的人构建云中的数据湖。从使用者角度来讲，既需要云中的，也需要某些企业内部的。这两者之间对于后台管理来说是一个蛮大的挑战。数据的拥有人不一样，数据和数据之间的标准，交互的标准、描述的标准都不一样，互相之间怎么协调，是一个很大的挑战。从IBM角度来讲，我们是站在这两个后面来看怎么支撑未来的服务。

现在所有的东西基本都变成开源了，开源以后商家怎么挣钱成为一个很大的问题。比方说我们原来卖软件license的，现在不太好卖了，或者未来越来越卖不动。我卖服务，假如我是IBM，做了一堆服务，放到IBM的云里面，举个例子，中国的银行就不会把它的数据放到IBM的云里面，美国银行可能会，这样IBM未来的商业模式在哪里？这也是我们正在探讨的一些方向。

这个数据本身，大量的Self-Service是被数据分析师需要的。那些投资人对大家来说是数据分析师，用大家的数据是指导它进行投资。分析师需要一些工具，要把这些工具做得简单方便，自己配置就能用了，你也可以说，你使用我，找一个数据分析师，专业的，帮你天天做，这个可以，有可能是一个人，有可能是个小的机器人，你们朝这个方向做，建议可以做个小的机器人助手，可以做自学习、分析。从投资角度来讲，这个分析越全面投资越准确。数据分析人有一个很大的悖论，很特定的观点，数据看得越多、越全面，就越能够把握住相关的规律。从我们的角度来讲，到最后的结果，社交媒体里面的数据，相关的新闻报道、正式媒体里面的数据，相关的监管机构的数据、交易数据等，对大家来说都是非常重要的。

IBM有个Watson Explorer，本质来说从功能上现了大家做的数据集，但不是针对金融做的。不同的数据源，不同的数据分析报表，有大量不同的结构化、非结构化的数据，通过自服务的形式提供出去，这是IBM自己做到的一些东西，但不是特定针对金融行业做的。

来源：杨晓洋