impala + kudu大数据实组件使用优化

• 全量数据导入kudu时，这时候我们先用sqoop把关系数据库数据导入临时表，再用impala从临时表导入kudu目标表

　　　　由于sqoop从关系型数据直接以parquet格式导入hive会有问题，这里默认hive的表都是text格式；
　　　　每次导完到临时表，需要做invalidate metadata 表操作，不然后面直接导入kudu的时候会查不到数据;
　　　　初始化好数据得执行compute stats 表名，不然impala执行sql生成的计划执行数评估的内存不准确，容易评估错误导致实际执行不了;

• 除了查询，建议所有impala操作都在impala-shell而不在hue上面执行

• impala并发写入kudu的时候，数据量比较大的时候

　　　　这时候kudu配置参数 --memory_limit_hard_bytes能大点就大点，因为kudu写入首先保存再内存里面，到一定阀值才溢写到磁盘，这个是直接最能提高写的方法；
　　　　可以把--maintenance_manager_num_threads 这个参数稍微调大，需要调试，提高数据从内存写入磁盘的效率;

• impala查询kudu

　　　　kudu表最好不要做任何压缩，保证原始扫描性能发挥最好；假如对查询性能要求比存储要求高的话；大部分企业对实时查询效率要求高，而且存储成本毕竟低；
　　　　kudu针对大表要做好分区，最好range和hash一起使用，前提是主键列包含能hash的id，但range分区一定要做好,可以使用时间做分区；

　　　　查询慢的sql，一般要拿出来,方便的话做下explain，看下kudu有没有过滤部分数据关键字kudu predicates；

　　　　假如sql没问题，那在impala-shell执行这个sql，最后执行summray命令，重点查看单点峰值内存和时间比较大的点，对相关的表做优化，解决数据倾斜问题。

• kudu数据删除

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

• 关于impala和 hive

　　　　kudu一般解决实时：

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

　　　　hive解决的是离线（通常是T + 1或者 T -1）：

　　　　　　hive基于hdfs，hdfs已经提供一套较为完善的存储机制，底层数据和文件操作便利；

　　　　　　安全性，可扩展性都比kudu强很多，最重要parquet + impala效率要比kudu高，数仓首选是它；

• 实时同步工具

　　　　同步工具可以使用streamsets，一个方便的拖拉拽的工具:

　　　　　　但内存使用率高，通过jconsole我们发现，所有任务同时启动；
　　　　　　JVM新生代的内容几乎都跑到老年代了，GC没来的及，就内存溢出了；