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