3.完成ODS层数据采集操作

本文详细介绍了在Hive中处理数据导入,包括选择行式存储与列式存储的优缺点、压缩方案如Snappy和ZLIB的适用场景,以及在ODS层使用外部表的情况。同时,讨论了全量覆盖、仅新增、新增及更新同步这三种数据同步策略,并给出了相应的Shell脚本示例,强调了自动化和按日期分区的重要性。
摘要由CSDN通过智能技术生成

将原始数据导入mysql

1 选中mysql 运行脚本

 

2 验证结果

数据存储格式和压缩方案 

存储格式

分类

1.行式存储(textFile)

缺点:可读性较好  执行 select  * 效率比较高

缺点:耗费磁盘资源  执行 select 字段 效率比较低

2.列式存储(orc)

优点:节省磁盘空间. 执行 select 字段 效率比较高

缺点:执行 select * 效率比较低 , 可读性不是特别好

orc的本质

ORC是兼具行式存储优势又具有列式存储优势, 数据按行分块, 每块中按列存储数据, 同时在每个块内部, 对数据构建索引, 提升查询的效率。

总结

在hive建表中, 一般采用那种存储格式呢?

在hive中,  一般我们的选择都是ORC存储格式, 
除非需求对接的数据源是普通文本文件数据, 此时会让对接此文件的表构建为textFile,其余的层次结构的表依然使用ORC。

压缩方案

压缩有什么用? 
答:能够在有限的空间下, 存储更多的数据
分类
ZIP(GZIP),  SNAPPY, LZO,ZLIB ....等
snappy:读写效率特别高, 压缩率不是最高(只比 zlib低), 他注重读写效率.
zlib: 默认的  读写效率不高, 但是 压缩率高, 相同的内容 压缩后更小.
本项目采用哪种方案?
在 ODS层, 一般会使用zlib:压缩率高  读写慢  读一次
在其他层次中, 一般采用snappy:压缩率比zlib稍微高一些  读写效率高  频繁读写
说明
1.如果读取次数较少, 写入了较大, 优先保证压缩比   --- zlib(gzip)  比如说 ODS层
2.如果读取次数比较高, 优先保障解压缩性能   -- snappy  比如说 DW层相关的表
3.如果不清楚, 建议使用snappy, 或者如果空间足够, 统一采用snappy也没有问题

创建表的时候, 选择内部表, 还是外部表?

判断标准: 对表数据是否有管理的权限
1.有权限删除数据, 那么我们可以构建内部表, 当然也可以构建外部表
2.如果没有权限删除数据, 只能构建外部表
内部表转换为外部表:
alter table 表名 set tblproperties('EXTERNAL'='FALSE');
    通过true和false 来修改是否为内部表还是外部表

结论:一般来说, 在数仓中,  除了ODS层可能会出现外部表以外, 其余的层次结构, 大多数还是内部表.

创建表的时候, 是否需要构建分区表呢?

一般情况下, 都是分区表(分区的字段大多数的都是以时间为主)

解决hive中文注释乱码 重点重点重点

准备工作

drop database if exists db_1 cascade;

create database if not exists db_1;

create table db_1.tb_user(
    id int comment '编号',
    username string comment '用户名',
    password string comment '密码'
);

desc db_1.tb_user;

现象

原因:编码 和 解码 不一致导致的中文乱码

解决 

在mysql中执行

use hive;
alter table COLUMNS_V2 modify column COMMENT varchar(256) character set utf8;
alter table TABLE_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;
alter table PARTITION_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8 ;
alter table PARTITION_KEYS modify column PKEY_COMMENT varchar(4000) character set utf8;
alter table INDEX_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;

再次测试

数据同步方式

全量覆盖同步方式

应用场景:表数据变更的频次并不多,不需要记录其历史数据 而且整个表数据量相对较少

操作方式

1.每次同步数据, 都是要先将原有的数仓中表数据全部删除, 然后重新从业务端导入即可

2.建表的时候, 不需要构建分区表

仅新增同步方式

应用场景:业务端数据只会有新增的操作, 不会有变更的时候, 数据量比较多

操作方式

1.在数仓中建表的时候, 需要构建分区表, 分区字段和同步数据的周期是一致的, 
比如说: 每天都需要同步数据, 分区字段 需要按天  如果每月同步一次, 分区字段按照月.

2.每次进行同步的时候, 将对应周期下的新增数据放置到对应日期分区下

新增及更新同步方式

应用场景:1.每天都需要同步数据, 分区字段 需要按天;  如果每月同步一次, 分区字段按照月

2.业务端表数据既有更新操作, 又有新增操作

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值