最近部门有个大表想对每天数据根据内部数据日期进行再划分分区（我们每天采集数据按day采集，但是数据里面包含了collectday字段想进行二次分区），数据量比较大月增大概10E量，全表在50E左右。
执行步骤：
1.起初别的同事负责，发现动态分区用着说数据量不对。自己也没细看感觉sql对也就没去仔细观察。
2.自己着手处理这件事，先考虑用spark进行分区处理，感觉读取速度快的话逻辑应该不复杂，就数据创建对应文件夹到hive下，生成批次的lzo文件，给文件加索引块，修复hive索引表，后来卡在sql重分区后数据着条处理很慢。（这里可能我自己问题，具体为什么那么慢还没找出问题）
3.由于事情太急促需要出报表，改用hive动态分区处理（考虑到spark处理量原不如hive大，这个表增长比较快，为了后期考虑hive也是个不错的选择）。
4.建立动态分区表（考虑两个动态分区：1.数据按天处理好划分，2.内部第二层collectday内部文件处理失败可以按照天重跑不会影响到别的天数，3.单层数据把分层数据混合到一起后续也会有麻烦，后续数据的建立最好不要影响到前面的设计）
5.建立二层hive分区表
CREATE EXTERNAL TABLE `terminal.exter_terminal_flowcollect_collectday`(
`sdkversion`string,
`imei1`string,
`imei2`string,
`brand`string,
`model`string,
`version`string,
`masterstatus`string,
`sendtime`string,
`createtime`string,
`appkey`string,
`ip`string,
`iccid1`string,
`iccid2`string,
`imsi1`string,
`imsi2`string,
`lac1`string,
`cellid1`string,
`lac2`string,
`cellid2`string,
`collectday`string,
`dayhour`string,
`nettype1`string,
`nettype2`string,
`totalfloww`string,
`totalflowd`string,
`totalflowd2`string,
`pubnetip`string,
`mac`string)
PARTITIONED BY(
`day` string,`collect_day` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES(
'field.delim'='|',
'serialization.format'='|')
STORED AS INPUTFORMAT
'com.hadoop.mapred.DeprecatedLzoTextInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
TBLPROPERTIES(
'transient_lastDdlTime'='1533115537')
动态分区入库
1.入库过程发现执行完入库操作一直失败
2.考虑分区中有非法数据
3.排查出有阿拉伯文一类非数字的字符串（考虑是因为这些数据无法建立表）
4. rlike (collectday,'[0x30,0x39]')采用正则方式过滤了非数字字符串
SET hive.exec.dynamic.partition=true;//设置动态分区
SET hive.exec.dynamic.partition.mode=nonstrict;//设置可以动态方式
SET hive.exec.max.dynamic.partitions=100000;//设置可分区数为十万，默认几千好像具体可查
SET hive.exec.max.dynamic.partitions.pernode=100000;//设置可分区数为十万,默认几千好像具体可查
SET mapreduce.output.fileoutputformat.compress.codec=com.hadoop.compression.lzo.LzopCodec; //设置压缩方式
SET hive.exec.compress.output=true; //设置压缩方式
SET mapreduce.output.fileoutputformat.compress=true; //设置压缩方式,记得建立表时候需要配置输出格式，不然会压缩失败（这个资料看到过，但是自己没去测试）
insert into table terminal.exter_terminal_flowcollect_20190630 partition (day='20190627',collect_day)
select
sdkversion,
imei1,
imei2,
brand,
model,
version,
masterstatus,
sendtime,
createtime,
appkey,
ip,
iccid1,
iccid2,
imsi1,
imsi2,
lac1,
cellid1,
lac2,
cellid2,
collectday,
dayhour,
nettype1,
nettype2,
totalfloww,
totalflowd,
totalflowd2,
pubnetip,
mac,
collectday as collect_day from terminal.exter_terminal_flowcollect where day = '20190627' and rlike (collectday,'[0x30,0x39]');
跑的过程遇到过两个问题
1.个人用户队列（我们服务器分主队列和个人用户队列）资源不足，导致跑不出来，需要切换到主队列资源充分才行
2.考虑加上 distribute by collectday此选项会把map相同key的选项归类到同一个map中，不会生成太多的小数据块，但是由于50E量太大，我在数据归类后导致内存不足（不想调整服务器参数，怕引起别的问题，索引就不加这个参数了，数据块多有问题后面再考虑看看能不能做个合并程序）
3.进行数据加索引（由于第二层目录下文件数达到六万个加索引成为一个很麻烦的事），于是进行索引文件hadoop-lzo-0.4.15-cdh5.4.0.jar 的一些用法研究
发现数据块加索引方式有三种
1.单机模式进行索引添加
好处：直接单机运行不走mapreduce，大大减少了起JOB的时间
坏处：我6万个文件索引生成的过程会引起很夸张的IO流量过程，造成CDH的的那台执行环境IO阻塞，从而影响大量的应用运行，于是废弃了这个办法
2.分布式进行索引添加，分布式索引添加分为两种
1.单对参数模式
可以对单个目录下所有LZO块进行索引添加，但是多个路径没办法添加。
2.多参数模式
可以利用里面传递路径参数args，传递进多个路径，对多个路径下的多个LZO文件进行索引的添加
（后期我利用shell脚本拼接了多个LZO文件存在的分区路径，进行传递到hadoop-lzo-0.4.15-cdh5.4.0.jar中，执行MR加索引。每个索引会一个map，一共6万个map过程，很慢但是不会影响环境）
总结：数据量大首先考虑MR，MR动态分区可以做根据字段建立分区，多个文件加索引过程可以拼接多个参数