标签：指南 hive 导入 内存 parquet kudu impala

• 一开始需要全量导入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://blog.csdn.net/u013411339/article/details/115343647

标签：指南,hive,导入,内存,parquet,kudu,impala
来源： https://www.cnblogs.com/gentlescholar/p/15107927.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。