impala + kudu一些优化心得

用了几次impala + kudu做大数据实时计算场景,一路踏坑过来,这里分享踏坑经验
  • 一开始需要全量导入kudu,这时候我们先用sqoop把关系数据库数据导入临时表,再用impala从临时表导入kudu目标表

由于sqoop从关系型数据直接以parquet格式导入hive会有问题,这里默认hive的表都是text格式;每次导完到临时表,需要做invalidate metadata 表操作,不然后面直接导入kudu的时候会查不到数据

  • 除了查询,建议所有impala操作都在impala-shell而不在hue上面执行
  • impala并发写入kudu的时候,数据量比较大的时候

这时候kudu配置参数 –memory_limit_hard_bytes能大点就大点,因为kudu写入首先保存再内存里面,到一定阀值才溢写到磁盘,这个是直接最能提高写的方法;

当然不是所有机器都有那么多资源,可以把–maintenance_manager_num_threads 这个参数稍微调大,需要调试,提高数据从内存写入磁盘的效率

  • impala查询kudu

首先所有表做完全量的etl操作,必须得执行compute stats 表名,不然impala执行sql生成的计划执行数评估的内存不准确,容易评估错误导致实际执行不了

kudu表最好不要做任何压缩,保证原始扫描性能发挥最好;假如对查询性能要求比存储要求高的话;大部分企业对实时查询效率要求高,而且存储成本毕竟低;

kudu针对大表要做好分区,最好range和hash一起使用,前提是主键列包含能hash的id,但range分区一定要做好,经验告诉我一般是基于时间;

查询慢的sql,一般要拿出来;方便的话做下explain,看下kudu有没有过滤部分数据关键字kudu predicates;假如sql没问题,那在impala-shell执行这个sql,最后执行summray命令,重点查看单点峰值内存和时间比较大的点,对相关的表做优化,解决数据倾斜问题

  • kudu数据删除

大表不要delete,不要犹豫直接drop,在create吧;磁盘空间会释放的

  • 关于impala + kudu 和 impala + parquet

网上很多分析impala + kudu 要比 impala + parquet 优越很多;谁信谁XB;

首先两个解决的场景不一样,kudu一般解决实时,hive解决的是离线(通常是T + 1或者 T -1)

hive基于hdfs,hdfs已经提供一套较为完善的存储机制,底层数据和文件操作便利;安全性,可扩展性都比kudu强很多,最重要parquet + impala效率要比kudu高,数仓首选是它

kudu最大优势是能做类似关系型数据库一样的操作,insert, update, delete,这样热点的数据可以存储在kudu里面并随时做更新

  • 最后谈到的实时同步工具

同步工具我们这里使用streamsets,一个拖拉拽的工具,非常好用;但内存使用率高,通过jconsole我们发现,所有任务同时启动;JVM新生代的内容几乎都跑到老年代了,GC没来的及,就内存溢出了;后面单独拿几台服务器出来做这个ETL工具,jvm配置G1垃圾回收器

    原文作者:阿甘骑士
    原文地址: https://www.jianshu.com/p/a49e68c0015b
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞