1. 首先，咱们先不拿大数据说事，先分析一下OLAP及OLTP。
OLAP: 联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持。
OLTP: 联机事务处理(OLTP，On-line Transaction Processing)应用，它所存储的数据被称为操作数据或者业务数据。
所以从定位上来讲，OLAP的定位是用来做数据分析(类BI),OLTP适合做一些事务的类的数据管理如查询如订单数据的产生。
举个通俗的例子，一个小规模的电商网站，会有下单的流程，那么这个下单流程产生的订单会是在OLTP数据库中，而如果电商的CEO想看本个月的运营情况，如果订单统计，理论上是应该在OLAP数据库（或者仓库）。
所以从本质上来讲，OLAP是读为主而OLTP以写为主。
然后，我们在来做一个基本的分析，就是常见的分析方式：
- Ad-hoc query：即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。
- 固定字段分析：即用户的查询条件是固定的，我们可以按照定义好的字段进行报表提供，如周报、月报
- 关键字查询：如，用户的地址为 北京市朝阳区XXXXX，那么提供按照北京市XXX为关键字的检索查询
- 统计类查询：如生成一些箱图，热力图等
可以简单分析一下就是，在OLTP中，合理设计的情况下会存在1，3类查询，而在OLAP中会在1,2,3,4类查询。
2. 接下来，我们分析一下传统技术的问题：
大家知道，不管在牛逼的系统，都逃不开硬件的限制，如磁盘IO、内存、CPU（往往也是大家忽略的）、网络IO。一般SATA硬盘的读写速度是在50~75M之间，普通网络均为千兆交换机，即100M传输速度。
那我们在来分析一下，数据库的特性：（本文章不讨论数据库的具体实现）
- 数据库能进行较快查询的原因是因为索引（及缓存）的存在，不同数据库的索引实现结构会稍微不太一样。索引也需要维护。
再结合我们之前讲到的分析，大家可以认为数据库在查询上的性能其实还是比较容易实现优化（结合数据库缓存），但是大家需要注意的是，如果查询的时候同时存在聚合（group by，sum，count），那么压力就会落在IO上，比如排序（因为单机内存有限，必须通过硬盘来实现排序） 这个时候压力就会落到IO上（请回顾上文提到的性能），所以当我们需要返回的数据条数越大（尤其分页），那么数据库就会变的非常非常的慢。
- 很多人会用数据库来进行数据清洗，也是因为IO的问题，导致变慢
- 大家不能忽略：当数据不大时，也会出现分析很慢的问题，是因为CPU计算能力有限的问题。
所以综合我的分析，大家可以得出几个结论：
- 数据库的问题在计算资源的有限
- 本身也没有支持关键字查询的方式（搜索引擎）。
- 主要是在查询+统计的场景下，数据库会有问题，其实本质来讲Ad-hoc query 如果没有统计的话，咱们通过分库+hash的方式是可以做到非常快的。
3.目前开源大数据方案，是否Ready？
接下来，我通过工作中使用的一些技术给大家做一些分析，希望大家能对这个东西的解决方案有一些了解
我们在几个方面做比较，架构、效率、成熟度、学习难度等。
Hadoop+Hive+Tez：
- 架构 ： Hive 目前是Hadoop上的数据仓库，底层的技术为Tez(DAG MapReduce)，采用Yarn 作为资源管理平台，提供类SQL 接口，HQL,采用数据库作为元数据管理工具。
- 成熟度：Hive目前已经被非常多的人来使用，所以整体比较成熟。
- 效率：Hive目前结合Orcfile+压缩整体还是比较快的，但是也没有达到一些ad-hoc query要求的3秒内返回
- 学习难度 ：HQL，Hadoop 入门的难度都不高，所以学习曲线比较简单。
总结如下：
- Hive 目前这个软件适合做OLAP数据仓库类分析、数据清洗等对实时性要求不高的场景
- Hive 不支持按照关键词查询，所以不能做搜索
- Hive 索引比较弱，达不到数据库的性能。
- Hive 不能满足3秒，5秒类似的快速返回的Ad-hoc query（即便将HDFS数据加入内存）
- 有Insert,update 等初级事务操作，所以可以认为未来可能可以做oltp。
Spark+Hadoop：
- 架构：Spark 技术中有一个比较好的技术就是-Spark SQL，这个技术可以实现使用SQL来操作Spark的RDD，当然Spark SQL最终也是要通过Spark的引擎，来使用所以最终会转换成Spark的MapReduce。
- 成熟度 ：目前仍是告诉发展。
- 效率： 整体比Hive率高，但是如果数据量非常大，没有特别好的效果。数据加入内存后查询（无统计）非常快。
- 学习曲线：需要学习Hadoop，Spark等，比较陡峭。
总结如下：
- 数据量不是特别大，完全装入内存，可以提供秒内的非统计类查询。
- 不能完全装入内存的统计分析，结果与hive+tez的组合不会差太多，也不会领先特别多。
- 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
- 没有索引，无法做精确的查找，都是暴利扫描。
Impala+Hadoop：
- 架构：Impala技术目前性能不错，抛弃了MapReduce设计，结合HDFS缓存可以做更好的性能提高
- 成熟度：比较成熟
- 效率：配合Parquet ,性能与Hive+Tez接近，因为不需要启动在一定程度分析比Hive快
- 学习曲线：学习SQL与Impala 本身，所以难度一般。
总结：
- Impala性能不错，但是在大数据排序上，需要限制返回的行数，大表间Join也是个问题。
- 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
- 没有索引，无法做精确的查找，都是暴利扫描。
所以综合看，目前开源的大数据SQL方案，没有一个是完美的，都是或多或少的缺陷，我们需要由搜索引擎+nosql+redis等方案配合，来完成很多的场景。
我们需要对性能有一个结论：要求5秒内的，基本不适合用这种大数据SQL方案手段来做。需要借助更昂贵的数据库，或者等待开源技术成熟。