-
一开始需要全量导入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垃圾回收器