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、待续。。。