google 三驾马车
gfs :对应hadoop的hdfs
bigtable :对应的是hbase,性能比bigtable差
mapreduce
之后google又公布了
percolator:增量查询,对增加的数据进行分析。使分布式增量索引更新成为文本检索领域的新标准
Pregel:图计算,spark.graphx . 开辟了图数据计算的新方向
mredel:impala,Pb级快速查询
drill :
shark:
impala简介
比hive查询速度提高近40倍。
cloudera公司推出的。对hdfs,hbase数据的高性能,低延迟的sql查询
基于hive使用内存计算
pb级大数据实时查询分析引擎。
hive挂掉,impala也会挂掉。
官方推荐128G,
www.impala.io/index.html
presto是facebook的,多用户查询时间就长了。
image-20210303131543742
特点-优点
image-20210303131701437
无需转换为mapreduce,直接读hdfs数据
c++编写,LLVM统一编译运行,速度快。针对服务器硬件有一定优化
支持列式存储
支持jdbc/odbc远程访问
基于内存计算,PB数据可以实时查询
兼容hivesql
有数据仓库特性,对hive数据可实时分析
支持data local, 每台服务器上都要装impala,可以直接从自身的datanode来读取。
劣势
对内存依赖大。
依赖于hive
对于一个数据库来说,如果分区超过一万,性能下降严重
如果必须大于1万,则新建数据
可以定期删除数据。
稳定性不如hive
Impala实例
image-20210303132726597
真正的计算是在impala daemon中计算的。
优化:内存经常不够用。 最大的内存放在汇总的机器上。
不要做太大规模的查询统计。
StateDeamon
一台机器,收集集群中各impalad进程的资源,健康,同步信息
对query进行调度
不太重要, 不启动或启动失败也没问题。
Catalog Daemon
一台机器
接收StateDaemon的请求,分发表的元数据信息到各impala中
hive中如果建一张表,想在impala中查看,需要先把表同步到impala中才可以
Impala Daemon
实例n台-impalad
接收client,hue,jdbc请求,query执行并返回给中心协调节点
子节点上的守护进程,负责向statestore汇报,保持通信
配置
state store 工作线程数:4 配置越多效率越高。
impala daemon内存限制:256M, 生产环境一般是128G
Cgroup 内存软限制:-1, 其它机器如果资源低,可以挪用
Cgroup 内存硬限制:-1
架构
image-20210303140032650
impala deamon一般是多少个datanode就配置多少个impalad
一般都是从自身的datanode节点数据查。
catalog, statestore 一般部署在同一台服务器上。
query planer:对sql进行解析
Query Coordinator:做任务的协调
query executor:真正的查询
impala shell
-h 帮助
-v 查询版本
-V 启用详细输出
--quiet 关闭详细输出
-p 显示执行计划
-i hostname 指定连接主机,默认端口21000
-r 刷新所有元数据
只在第一次和hive整合的时候 ,使用
-q query 从命令行执行查询
-d default_db 指数数据库。
-B 去格式化输出
-f query_file 执行查询文件,以分号分隔
-o filename 结果输出到指定文件
-c 查询执行失败时继续执行
-refresh <tablename> 增量刷新元数据库。
explain <sql> 显示查询执行计划
shell<shell> 不退出impala-shell 执行linux命令
profile 查询最近一次查询的底层信息
存储和分区
parquet :官方推荐的。
压缩:snappy,gzip,currently,snappy by default
推荐snappy,(gzip虽然夸张高,但影响效率)
snappy: 在压缩比和解压缩上实现了很好的平衡。
impala VS hiveql
聚合函数仅支持:AVG,COUNT,MAX,MIN,SUM
impala不支持多distinct 查询
不支持HDF,UDAF函数
重点掌握
shell , 存储分区,sql, 性能优化。 架构图
还不快抢沙发