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没来的及，就内存溢出了；
