对于目前来讲,对数据的处理主要集中在两个方面,一种是联机事务处理OLTP(on-line transaction processing),另一种是联机分析处理OLAP(On-Line Analytical Processing)。
OLTP:是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,典型的是银行ATM存取款,金融证券方面的实时更新等,这些操作都比较简单,主要是对数据库中的数据进行DML操作,操作主体一般是产品的用户,并且OLTP事务性非常高,一般都是高可用的在线系统,如上述的银行金融方面。
OLAP :有的时候也叫DSS决策支持系统,也就类似等同我们说的数据仓库,它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。通过分析DW中的数据来得出一些结论性的东西(比如报表),从各方面观察信息,也就是从不同的维度分析数据(站在维度的角度看待事实),因此OLAP也称多维分析。
两者的对比如下图所示。
属性对比 | OLTP (例如mysql) | OLAP (例如hive) |
---|---|---|
操作对象 | 数据库 | 数据仓库 |
读特性 | 每次查询只返回少量记录 | 对大量记录进行汇总 |
写特性 | 随机、低延时写入用户的输入 | 批量导入大量的数据 |
数据时效 | 当前最新的数据 | 当前历史的聚集的数据 |
操作粒度 | 记录级 | 多表join分析 |
使用场景 | 用户,Java EE项目 | 数据分析师,为企业决策提供支持 |
具体工作内容 | 简单的事务 | 复杂的查询 |
时间要求 | 具有实时性 | 分离线数仓和实时数仓 |
数据量 | GB | TB到PB |
数据操作 | 支持DDL,DML | 一般不支持更新和删除 |
主要功能 | 查询或改变现状 | 报表,统计预测 |
对于即席查询而言一般情况他一般是与OLAP做对比的,这里说明一下在数仓中我们一般都是对数据进行一个批处理(基本上对前一天数据处理)并且是有一个明确的分析指标的如下图所示
何为一个明确的分析指标,按照上述所说的从维度的角度看待实时(指的是度量值,这里为金额),我们可以是按照7个维度去度量金额,也即是下表所示的内容
维度 | 度量值 | 分析指标 |
---|---|---|
地区 | 金额 | 什么地区有多少下单金额 |
品类 | 金额 | … |
时间 | 金额 | … |
地区,品类 | 金额 | … |
地区,时间 | 金额 | 什么地区,什么时间销售了多少金额 |
品类,时间 | 金额 | … |
地区,品类,时间 | 金额 | 什么地区,什么品类,什么时间销售了所少金额 |
对于数仓的这种分析我么一般都是有固定的套路,比如说select area,time from table group by area,time.
这种查询也成为固化查询(指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率,这类需求的SQL基本有固定的模式
)
可能上述的固化查询你搞的好好的,这时候老板突然来了一个需求但是范围并不属于是上述的那种有固定模式的SQL,我们把这类需求称为即席查询(Ad hoc queries)
即席查询: 是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成返回响应的结果,例如返回用户自定义的统计报表。
即席查询的特点: 即席查询与固化查询最大的不同是普通的固化查询是定制开发的(即查询语句是预先写好的,不会临时变化),而即席查询是由用户自定义查询条件的。
对于即席查询和OLAP可以参考下图的关系图
对于即席查询和固化查询的总结:
即席查询与固化查询从SQL语句上来说,并没有本质的差别。它们之间的差别在于,固化查询在系统设计和实施时是已知的,所有可以在系统实施时通过建立索引、分区等技术来优化这些查询,使这些查询的效率很高。而即席查询是用户在使用时临时生产的,无法人工预先优化这些查询,需要数据库内部实时自动优化,所以即席查询也是评估数据仓库的一个重要指标。在一个数据仓库系统中,即席查询使用的越多,对数据仓库的要求就越高,对数据模型的对称性的要求也越高。
最后为什么不用hive做即席查询?
即席查询目的很明确,就是要快,所提即所得,即提出来这个需求立马要看到结果,数仓传统的hive做即席查询那肯定是不行的,MR跑完数据估计天都黑了,所以也迫使新的框架要研发出来,这里例举出市面上常用的几款即席查询的框架: Druid,Kylin,Presto,Impala,Spark SQL,ES,CK等
这几款框架的对比详见https://blog.csdn.net/likino666/article/details/103165292