hive实践采坑日志|持续更新版本

2018-01-22 —(hive学习的采坑日志)

技术学习的过程中,真的是要不断的练习,再练习,然后懵逼的发现报错了,然后毫无头绪的找问题,折腾了半天,终于发现被一个空格、逗号、大小写,或者是一些微小的细节卡住了一天,特别想要抓狂的感觉,那就对了,然后你就记住了这个错误,接下来知识真的就变成你自己的了。

牛逼的程序媛的标配,就是有自己动手搭建blog,不因公司倒闭而丢失,这个是高阳老师给你们说的。我现在没有,所以暂时就用记录每天采坑的囧样吧,庆幸的是爬出来了,纵然弄的满脸灰尘,那又怎样,哈哈。

1、今天刚到公司,被同事提醒指标未出数,奇怪了,调度正常怎么就报错了呢?各种猜想有没有可能是集群的问题,而不是自己代码的问题,得到同事的肯定答复,经过判断肯定不是!于是抓紧找自己代码的问题,经过一个多小时的折腾,得出的结论如下。

impala在访问hive的分区表时:(数据筛选的时候,一定要注意,重要的事情说100遍)

分区字段与普通表字段功能上的区别:

select  字段名称 from 表名 where  分区字段 = ‘具体的分区值’ 。

程序错误的原因:程序表的字段设计 : 字段1 与 分区字段 的值完全一致,所以在where语句进行条件筛选的时候,筛选条件是:字段1,而非分区字段。在进行指标编码: K04 数据筛选的时候,由于未进行分区条件的过滤,导致程序在分区K03中查找K04的数据。

一定要注意:虽然设计时分区字段与表字段的内容一致,但是分区字段 与 表字段的功能完全不一致,如果要筛选某一个分区内的数据,where 条件中一定要限制 :“ 分区字段名” = “分区字段值”



2018-01-24 — (采坑日志之补全维度)

坑总是要踩的,要不怎么成长?最近开发了一个有关于负载均衡的指标,到处的犯错,为了避免自己忘记,我打算把整个犯错,采坑的点全部的记录下来,以便后期可以回顾与复习,避免再次采坑。

1、补全维度的产生的bug,导致K06 早上9点的数据为0时,前端未出数。

2、产品类型CODE写入对于为空的类型,未做处理,导致前端存在异常

3、外场操作到达货量的指标名称,写为了“外场操作出发货量”的名称,写入的名称存在问题

4、K03(外场操作出发货量)与K04(外场操作到达货量) 指标的PRO_TOTAL_K03 以及PRO_TOTAL_K04 ,写入数据存在重复的问题。

5、K04明细数据处理时,未考虑清楚补全维度的问题。

6、K03 、K04、K06的汇总数据在处理时,未考试到补全维度的问题,导致数据的异常。

7、所有的指标有相同的部分,进行代码复制、粘贴的时候,存在细节处理差异的问题,未能考虑到。

8、执行生产JSON文件时,①出现了插入4条重复数据的异常操作,因为自己的mysql的时间查询语句写的存在问题。②出现了JSON文件,对于配置文件多次复制,导致了JSON文件本身执行报错的问题。

9、hive建表的字段的长度,比mysql的建表的长度大,导致写入数据出现了out of range的异常情况

10、建表时的分区字段与表中的其中一个字段一致,在进行数据筛选的时候,where 条件应该以分区字段进行数据筛选,自己主观的认为:字段内容一致,用哪个字段进行条件过滤都一样,导致多表操作时的异常。(咨询:刘振兴,兴哥帮助排查找到。)选择正常字段: 全表各个文件扫描。选择分区字段:仅在该分区字段中进行数据扫描。

11、在impala的表在进行关联的操作时,注意一定要对于表进行时间区间的筛选,否则会出现内存溢出的报错问题。

12、impala的另外一则内存溢出的问题,是由于多个查询语句的多次UNION ALL操作导致,需要将这种的实现方式,更改为 Insert overwrite + Insert into的实现方式,这种的处理方式,解决了内存溢出的报错问题的同时,解决了集群上创建多个无意义的表的问题。(浪费太多的集群的资源。)

13、hive代码开发的过程中,需要开发人员对于代码的处理要尽可能的谨慎与仔细,可是自己处理时,在面对代码量比较大的时候,还是有很多细节的错误,这个估计与设计的程序架构本身存储一定的关系,同时自己的仔细的程度还不够,需要提升。备注:开发的过程中,还是要整理出来,很多的开发的规范,开发的标准,否则后期集群的东西维护的成本愈大。

2018-01-25 更新版本:

上午来发现9点的数据,仍然展示的不正确,虽然有数据,可展示的数据还是上个点的数据的汇总。然后开始进行代码的调整。由于9点没有数据插入,所以上个8点的数据,未能为复写。所以K06的指标,明细数据和汇总的数据在处理的时候,都在where条件处加上了时间的限制。如果上个节点没有数据,那么当前的数据则展示为空的操作。



2018-01-31 — 实践过程中遇到的名词


1、集群中存在众多的小文件的问题

祥哥: 临时表的文件夹个数,需要关注一下,临时表的文件夹应该很小才对。

以下标红的是文件夹的个数文件的个数文件的大小

如果临时表存储的文件夹的个数比较多:处理的方式是使用归档的方式解决。

2、Google搜索关于表的归档的资料解释如下:

Hive的官方地址给出归档的详细的解释:https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Archiving

①归档的条件,只有内部表可以进行归档的操作,外部表不可以进行归档的操作。

②归档和解档是同时存在的,相互的可进行处理

3、新增的问题(如何确认一个表是否做了归档的操作)



2018-02-26 — 集群报错采坑日志

分区真的是一个非常非常重要的东西,集群运行的时间越长,分区的设计与限制就愈发的重要,否则程序直接报错,报错,然后一直报错。掉到坑里爬出来,才知道其重要性啊!!!

1、分区的设计与分区的限制

impala与hive表在设计时,通常的情况下会进行时间分区或者是组合分区的设计(时间与编码),程序开始运行的时候,是否对于分区进行限制,完全不影响程序运行的正确性。可随着分区表的数据长时间跑数的增加,如果不对与分区表的分区字段进行限制,就相当于在一个非常大的大表中进行全表扫描,直接会导致资源不足,报错情况的产生。

得出的结论如下:

A、impala、hive表在进行条件过滤时,一定要注意,限制时间区间,对于大表的数据量进行限制合理的时间限制(按照需求的要求进行限制),否则impala会直接导致超过内存限制的报错。hive直接会包return code 3的插入SQL异常。

B、设计了分区表的目标表,如果存有历史数据,一定要注意对于分区表的分区字段做限制,否则相当于全表的数据进行检索,大表随着跑数时间的增加,数据量则越大,直接会导致全表在集群上进行数据检索时,报错现象的产生。

2、创建表与表的覆盖

刚开始在集群上进行指标开发的时候,不是非常理解集群的设计原理。如果有一个表作为临时表的功能使用,不需要存储历史的数据,不需要每次,drop表,创建表,然后插入临时表的数据,只需要一次创建,然后Insert overwrite进行覆盖插入即可。

3、待续。。。



你可能感兴趣的:(hive实践采坑日志|持续更新版本)