收藏

大数据组件扫盲

2019-12-17  本文已影响0人  将军红

1.presto

Presto是一个低延迟高并发的内存计算引擎，相比Hive，执行效率要高很多。
Presto是常驻任务，接受请求立即执行，全内存并行计算；hive需要用yarn做资源调度，接受查询需要先申请资源，启动进程，并且采用mapreduce计算模型，中间结果会经过磁盘。

一个查询分解为多个stage 每个 stage拆分多个task，每个task处理一个or多个split ，一个task被分解为一个或多个Driver

数据规模PB 不是把PB数据放到内存，只是在计算中拿出一部分放在内存、计算、抛出、再拿
不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的
如果一个presto查询查过30分钟，那就kill吧，说明不适合 也违背了presto的实时初衷.
catalog：相当于MySQL的一个实例，
schema：相当于MySQL的database

软件架构 master-slave架构

架构图

coordinator
中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理
coordinator进行是presto集群的master进程

worker
执行任务的节点

connector
presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器
具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的
提取数据 负责实际执行查询计划

discovery service
将coordinator和worker结合在一起服务；
worker节点启动后向discovery service服务注册
coordinator通过discovery service获取注册的worker节点

优点 presto优缺点
presto执行sql图

低延迟原理

基于内存的并行计算

流水式计算作业

本地化计算

Presto在选择Source任务计算节点的时候，对于每一个Split，按下面的策略选择一些minCandidates
优先选择与Split同一个Host的Worker节点
如果节点不够优先选择与Split同一个Rack的Worker节点
如果节点还不够随机选择其他Rack的节点

动态编译执行计划

GC控制

容错

1、如果某个worker挂了，discovery service 会通知coordinator
2、对于query是没有容错的，一旦worker挂了，query就执行失败了，与其在这里容错不如直接执行
3、coordinator 和discovery service 的单点故障问题还没有解决

2.Hive

产生背景（解决的问题）
产生背景有以下几个方面：
1：MapReduce编程的不便性
2：HDFS上的文件缺少Schema（字段名，字段类型等）

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

Hive 没有专门的数据格式。 Hive 可以很好的工作在 Thrift 之上，控制分隔符，也允许用户指定数据格式

Hive直接执行HQL语句有以下三种方式：
1：直接命令行执行SQL语句：hive -e "select from table…
2：执行HQL文件中的语句：hive -f temp.hql
3：打开调试模式：hive --hiveconf

Hive在查询100Gb级别的数据时，消耗时间已经是分钟级了

hive优缺点

3.Spark

是一个基于内存的分布式计算框架。他的执行效率比MapReduce提高了很多！

总结
1：在数据源的级联查询时，用Presto写SQL语句进行查询；
2：在进行简单的数据查询时，可以用HQL进行建表，查询，关联等；
3：当数据量较大时，可用SparkSQL进行建表，查询，关联等；

Impala

KI参考链接

impala是建立在Hadoop生态圈的交互式SQL解析引擎，Impala的SQL语法与Hive高度兼容，并且提供标准的ODBC和JDBC接口。Impala本身不提供数据的存储服务，其底层数据可来自HDFS、Kudu、Hbase甚至亚马逊S3。
Impala定位类似Hive，不过Impala更关注即席查询SQL的快速解析，对于执行时间过长的SQL，仍旧是Hive更合适。对于GroupBy等SQL查询，Impala进行的是内存计算，因而Impala对机器配置要求较高，官方建议内存128G以上，此类问题Hive底层对应的是传统的MapReduce计算框架，虽然执行效率低，但是稳定性好，对机器配置要求也低。
其底层数据可来自HDFS、Kudu、Hbase甚至亚马逊S3

Impala VS Hive:
Impala本身并不是Hive的完全替代品，对于一些大吞吐量长时间执行的请求，Hive仍然是最稳定最佳的选择，哪怕是SparkSQL，其稳定性也无法跟Hive媲美。
稳定性方面Impala不如Hive，但是在执行效率方面，Impala毫无疑问可以秒杀Hive。Impala采用内存计算模型，对于分布式Shuffle，可以尽可能的利用现代计算机的内存和CPU资源。同时，Impala也有预处理和分析技术，表数据插入之后可以用COMPUTE STATS指令来让Impala对行列数据深度分析。

Impala不会对表数据Cache，Impala仅仅会Cache一些表结构等元数据。虽然在实际情况下，同样的query第二次跑可能会更快，但这不是Impala的Cache，这是Linux系统或者底层存储的Cache。

Impala的优势

上一篇下一篇

猜你喜欢

热点阅读