你的位置:首页 > 数据库

[数据库]老钱说大数据


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方案手段来做。需要借助更昂贵的数据库,或者等待开源技术成熟。