大数据OLAP与OLTP分析

1. 首先，咱们先不拿大数据说事，先分析一下OLAP及OLTP。

    OLAP: 联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持。

    OLTP: 联机事务处理(OLTP，On-line Transaction Processing)应用，它所存储的数据被称为操作数据或者业务数据。

    所以从定位上来讲，OLAP的定位是用来做数据分析(类BI),OLTP适合做一些事务的类的数据管理如查询如订单数据的产生。

 

    举个通俗的例子，一个小规模的电商网站，会有下单的流程，那么这个下单流程产生的订单会是在OLTP数据库中，而如果电商的CEO想看本个月的运营情况，如果订单统计，理论上是应该在OLAP数据库（或者仓库）。

   所以从本质上来讲，OLAP是读为主而OLTP以写为主。

    

   然后，我们在来做一个基本的分析，就是常见的分析方式：

1. Ad-hoc query：即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。
2. 固定字段分析：即用户的查询条件是固定的，我们可以按照定义好的字段进行报表提供，如周报、月报
3. 关键字查询：如，用户的地址为 北京市朝阳区XXXXX，那么提供按照北京市XXX为关键字的检索查询
4. 统计类查询：如生成一些箱图，热力图等

   可以简单分析一下就是，在OLTP中，合理设计的情况下会存在1，3类查询，而在OLAP中会在1,2,3,4类查询。

   

2. 接下来，我们分析一下传统技术的问题：

      大家知道，不管在牛逼的系统，都逃不开硬件的限制，如磁盘IO、内存、CPU（往往也是大家忽略的）、网络IO。一般SATA硬盘的读写速度是在50~75M之间，普通网络均为千兆交换机，即100M传输速度。

     

      那我们在来分析一下，数据库的特性：（本文章不讨论数据库的具体实现）

 

1. 数据库能进行较快查询的原因是因为索引（及缓存）的存在，不同数据库的索引实现结构会稍微不太一样。索引也需要维护。          

   再结合我们之前讲到的分析，大家可以认为数据库在查询上的性能其实还是比较容易实现优化（结合数据库缓存），但是大家需要注意的是，如果查询的时候同时存在聚合（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 入门的难度都不高，所以学习曲线比较简单。

   总结如下：

 

1. Hive 目前这个软件适合做OLAP数据仓库类分析、数据清洗等对实时性要求不高的场景
2. Hive 不支持按照关键词查询，所以不能做搜索
3. Hive 索引比较弱，达不到数据库的性能。
4. Hive 不能满足3秒，5秒类似的快速返回的Ad-hoc query（即便将HDFS数据加入内存）
5. 有Insert,update 等初级事务操作，所以可以认为未来可能可以做oltp。

 Spark+Hadoop：

• 架构：Spark 技术中有一个比较好的技术就是-Spark SQL，这个技术可以实现使用SQL来操作Spark的RDD，当然Spark SQL最终也是要通过Spark的引擎，来使用所以最终会转换成Spark的MapReduce。

• 成熟度 ：目前仍是告诉发展。
• 效率： 整体比Hive率高，但是如果数据量非常大，没有特别好的效果。数据加入内存后查询（无统计）非常快。
• 学习曲线：需要学习Hadoop，Spark等，比较陡峭。

    总结如下：

 

1. 数据量不是特别大，完全装入内存，可以提供秒内的非统计类查询。  
2. 不能完全装入内存的统计分析，结果与hive+tez的组合不会差太多，也不会领先特别多。
3. 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
4. 没有索引，无法做精确的查找，都是暴利扫描。

 Impala+Hadoop：

• 架构：Impala技术目前性能不错，抛弃了MapReduce设计，结合HDFS缓存可以做更好的性能提高
• 成熟度：比较成熟
• 效率：配合Parquet ,性能与Hive+Tez接近，因为不需要启动在一定程度分析比Hive快
• 学习曲线：学习SQL与Impala 本身，所以难度一般。

   总结：

 

• Impala性能不错，但是在大数据排序上，需要限制返回的行数，大表间Join也是个问题。
• 适合一定的Ad-hoc query场景与Olap 场景，不能做oltp
• 没有索引，无法做精确的查找，都是暴利扫描。

     所以综合看，目前开源的大数据SQL方案，没有一个是完美的，都是或多或少的缺陷，我们需要由搜索引擎+nosql+redis等方案配合，来完成很多的场景。

 

     我们需要对性能有一个结论：要求5秒内的，基本不适合用这种大数据SQL方案手段来做。需要借助更昂贵的数据库，或者等待开源技术成熟。

 

http://tulingss.iteye.com/blog/2238396