大家可以看到，大部分的Hadoop用户都在用这个技术来做数据仓库，我们后面讲一下为什么是这种场景。数据仓库是一个比较全的概念，通常不是指一类技术，是所有数据的组合，会是所有数据的集散地，企业会把所有的数据放在数据仓库里面对外提供服务。过去这么多年数据库面临一些挑战，数据增加比较快，传统的数据库已经不能处理，效率提升得比较慢，我们碰到一个很大的客户，是一个著名的厂商，这是一个显著的瓶颈。原来的关键数据库只处理结构化处理，现在需要一些新的技术处理半结构化、非结构化的数据。随着数据仓库越来越多，用户也越来越多，通常用户有上百个数据源，上面支撑几十个业务部门，甚至是几十个分支机构，一个银行可能有30几家分行，这些分支机构访问数据的时候都通过这个数据仓库，对数据的隔离、访问资源的管理就变成了一个迫切要解决的问题。
传统数据仓库是T+1的，在当天分析前一天的数据，但是更多的企业希望能够对数据进行实时分析，希望能够做到T+0，这一块也是对数据仓库构成的一个挑战。这一块就是有一些国外的咨询机构和公司提出的，希望能够做实时的数据处理。刚才我们看到有一个概念是几年前提出来的逻辑数据仓库，能够处理多种数据源，做数据管理。还有一个特点也是现在大家在使用新技术的时候一个驱动力，原来是对于过去历史的统计。今天大家发现，以前做数据模型，比如说像银行里的十大主题模型，或者八大主题模型，他们有几千张表，中间的表可能有上万张，关系相对来说是固定的。一旦你的业务发生变化，你可能要对整个层面做修改。今天大家希望有一个自助的方法，能够用机器学习的方法发现数据的管理，而不是发现统计的结果，甚至是统计报告对于他们不够。所以这一块现在有的提出来一个设计模式，就是我不需要知道这些数据它们之间的关联关系，我是通过机器学习的方法，机器自动来学习发现他们的规律。这实际上也对应了大数据的4V，数据量、数据变化、数据实时性以及数据挖掘，刚好是4V。其实在数据仓库里面，其实也是沿着这个方向演变出来的四个不同的设计模式。
在解决数量大的问题上面大家已经形成了共识，需要用分布式的方法，用横向的方式。从早期的单机到90年代的并行数据库，是把数据库的引擎并行化了，把计算并行化了，但是存储仍然是集中化的，集中化的存储仍然是一个瓶颈。后来把计算分离了，但是计算的引擎不具有可扩展性，容错性比较差。到了Hadoop的时候，大家发现可以有一种因的模式，同时对数据和计算进行分布式计算，对于数据进行分布式存储，同时兼顾扩展性和容错性。这一块基本上大家发现，这个计算模式是处理大规模数据的一个最佳模式，这个扩展性和容错性都有很大的问题。所以很多的Hadoop引擎都回归到这个计算模式上来。我们在SQL这一块做的比较突出，能够跑完整个过程。现在我们最新发布的4.0版本性能又比这个有两倍的提升，所以现在除了100TB的用三台机器，其他的都可以用两台机器完成。
分布式计算是解决了性能的问题，那么怎么解决数据源的问题，怎么解决这个问题，我们提出了逻辑数据仓库的概念。逻辑数据仓库要满足三个特性，首先需要有一个集中化的存储，把所有的数据全部集中起来，而不是分散在不同的地方。另外需要有一个数据联邦的概念，能够跨多种数据源，能够有统一的接口。通过统一的SQL层，或者是一个界面能够来访问到所有的数据源，中间有结构化数据，还有非结构化数据。另外必然是需要一个分布式计算，同时上面有多租户管理，还有原数据管理，整个形成了一个逻辑数据仓库的概念。逻辑数据仓库其中一个非常重要的特性就是要做数据联邦，能够访问多种不同的数据源。这一块我们有一个比较好的产品，可以跨多种数据源进行交叉。
在逻辑数据仓库当中需要用资源管理，要实现两层，数据保护通过不同的访问规则来控制对数据的不同访问，其次我们需要对资源进行一个比较好的隔离。这一块我们现在也采用了一些尝试，我们现在发布了一个产品是TOS，我们的调动引擎是完全自己开发的。另外一个题外话，我们在明年的产品当中有自己的存储引擎，所以在未来的一段时间之内，大家看不到Hadoop的影子了，我们已经几乎把这个东西全部实现了。