大数据仓库技术
2024-03-18 15:59:19 0 举报AI智能生成
大数据仓库 hadoop hive shell kafka zookeeper flume
作者其他创作
大纲/内容
数仓
采集通道
前端埋点产生日志行为数据logfile
flume
kafka
flume/java
hdfs
后台产生的业务数据mysq
sqoop/datax/kettle
hdfs
数仓建模
hdfs
hive、spark
数据分析
即时查询 kylin、prosto
可视化
superset
输出
报表系统、用户画像、推荐系统
权限管理
元数据管理：atlas
数据质量
shell griffin
hive
组成
元数据
多人开发 mysql
客户端
4个器 编译器、解析器、优化器、执行器
sql变换
mapreduce
hdfs
与mysql区别
hive
大数据
数据量大快
海量数据查询
mysql
小数据
数据量小块
小数据量查询
内部表和外部表
内部表
删除数据：元数据、原始数据
外部表
删除数据：元数据
企业中，临时使用创建内部表，绝大多数外部表
4个by
order by
全局排序 (数据倾斜)
很少使用
sort by
排序
depart by
分区
企业一般分区+排序
class by
sort by+depart by
系统函数
date_add
date_sub
next_day
last_day
get_json_object
自定义函数
自定义UDF函数
1进1出 一行
定义类，继承UDF，重写evaluate方法
自定义UDTF函数
多进多出 一进多出
定义类继承G..UDTF，重写里面3个方法初始化（定义名称、校验返回值类型）、close process
打包+上传HDFS=》在hive客户端创建
窗口函数
rank
over
topn
优化
mapjoin 默认打开，不要关闭
行列过滤 join where=》where join
分区
小文件
kafka
基本信息
producer
brokder
consumer
zookeeper
broker
id
comsumer
offset
没有producer
安装多少台
2*（生产者峰值生产速率*副本/100）+1=3
压测：生产者峰值生产速率、消费者峰值消费速率
副本
2-3个
默认一个 一般2
副本多：可靠性高，性能降低
数据量
100万日活 100条 1k 每天一亿条
一亿条/(24h*3600s)=1150条/s
1m/s
7-12点 20m/s-50m/s
数据保存多久
7-3天
磁盘空间
100g*2个副本*3天/0.7
分区
提高并发度
先设置一个
生产者峰值生产速率tp、消费者峰值消费速率tc
期望的吞吐量t
期望的吞吐量t 100m/s 分区数=t/min（tp，tc）
100/20= 5个分区
分区分配策略
range 默认
统一发生数据倾斜
roundrobin
采用hash方式打散，再采用轮询的方式执行
isr
解决leader挂了谁当老大
延迟时间
旧版本：采用延迟时间、延迟条数
新版本：采用延迟时间
topic合适
满足下一级所有消费者
挂了
短期flume channel缓冲数据
长期：日志服务器保留30天日志
丢了
ack
0 发过来数据，不需要应答
可靠性最差，传输性能最好
1 发过来数据，leader应答
可靠性一般，传输性一般
-1 发过来数据，leader和follower共同应答
……
重复了
事务、幂等性+ack=-1
幂等性
单分区单会话内数据不重复
关闭就重启
利用id判断重复
效率低
事务
同步，效率低
下一级处理
积压了
增加分区，增加消费者对应cpu核数
1个cpu两个线程，消费两个分区
增加消费者batchsize
日志是1k，1000条/s
提高消费速度
优化
日志保存3天
两个副本
增加通信延迟
减少重传
内存
默认1G，不要超过6G
高效读写
是集群、分区
顺序读写600m/s 随机速写100m/s
零拷贝
内存到内核，内核到内存
传输了一条2m日志文件
卡顿现象
调整最大字节数
过期数据清理
删除或者压缩
数据是否有序
单分区有序，多分区分区与分区间无序
shell
ps -ef
top
查看进程
natstat
查看端口号
df -h
查看磁盘空间
4个工具
awk
sort
sed
cut
hadoop
入门
端口号
9870
hdfs
50070
8088
yarn
19888
查看任务情况
9000、8020、9820
外部访问
9000、8020
配置文件
core-site.xml
hdfs-site.xml
yarn-site.xml
mapred-site.xml
workers
slaves
hdfs
读写流程
小文件
危害
namenode受不了
一个文件块150字节
128g/150bytes=128 *1024m*1024kb*1024bytes=9亿
一个文件块->一个maptask 1g内存
解决
CombineTextinputformat
减少maptask
har归档
类似文件压缩
jvm重用
配置文件
副本
3
块大小
1.x 64m
2.x 3.x 128m
本地 32m
企业开发 128m、256m
块大小根据传输速率设置
mapreduce
shuffle
map方法之后，reduce方法之前混洗的过程
map
getpartition 标记数据是哪一个分区的
环形缓冲区 100m 80% 溢写
归并
写入磁盘
拉取到内存，不够持久化到磁盘
归并
reduce
reduce之后压缩：
永久保存，压缩越小
下一个map输入：数据量小：快 spappy/lzo 数据量大：切片 bzip2/lzop
分组
默认拉取5个 优化性能高10-20个
优化增加内存
优化：压缩，减少磁盘io
快 spappy/lzo
默认一次拉取10个，可优化20个
优化 200m 90%，影响溢写文件个数
排序：快排
对key的索引排序
按照字典顺序排
溢写文件
对溢写文件提前combiner 不影响最终结果
优化：自定义分区
map之前压缩
数据量小：快 spappy/lzo
数据量大：切片 bzip2/lzop
排序
map 快排、归并
reduce 归并、分组
内存参数
nodemanager
默认8g->100g
单任务默认内存8G 分布式
128M数据->1G内存
maptask 1G
128M数据->1G内存
reducetask 1G
128M数据->1G内存
yarn
工作机制
client
resourcemanager
接受appid请求并返回集群路径
向路径提交
xml
配置文件 参数
jar
代码
切片
决定maptask数量
resourcemanager
申请 appmaster task
task管理
nodemanager container 空闲就来领取task 成为appmaster
从路径获取文件
切片决定maptask数量
向resourcemanager申请maptask
nodemanager container 空闲就来领取task 由appmaster开启maptask 完成之后持久化到磁盘等待reduce
开启reducetask
调度器
fifo
先进先出
单队列，串行，几乎不用
容量调度器
底层是fifo
支持多队列，可以借用其他队列资源
先进入的任务优先执行
默认1个队列，按照分析引擎创建队列（spark、flink、hive），按照业务分：登录、注册、购物车
公平调度器
支持多队列，可以借用其他队列资源
公平享有队列资源，谁的缺额多，分配资源多
apache 默认容量调度
并发度要求比较高，选择公平，中大型
并发度低，服务器性能差，选择容量
zookeeper
选举机制
半数机制
安装台数
10-3
20-5
50-7
100-7
台数越多，增加可靠性，效率低
flume
组成
source、channel、sink、put、take
taildirsource
断点续传、多目录
1.7实现
自定义实现source
offset持久化到磁盘
taildirsource挂了
不会丢数据、有可能有重复数据
自身
采用事务方式、效率低
下一级处理
hive、dwd、sparkstream，groupby，开窗取窗口第一条
不支持递归遍历文件夹
不支持
自定义
递归+读取数据
channel
file channel
基于磁盘，可靠性高，性能低
memory channel
基于内存，可靠性低，性能高
kafka channel
数据存储在kafka里面，磁盘，可靠性高
优于memory，直接进入kafka
下一级kafka选择memory
下一级不是 可靠选file、性能选memory
hdfs sink
小文件
大小128m、时间1-2小时，event格式禁止0
拦截器
etl拦截器
提前过滤
时间戳拦截器
获取日志里面的数据时间，根据这个时间创建hdsf目录
自定义拦截器
定义类实现interceptor接口，重写里面4个方法初始化、关闭、单event、多event，builder
可以不用，到下一步再处理
选择器
replicating 默认
把数据发往下一级所有通道
muliplexing
把数据选择性发往指定通道
监控器
监控put/take事务尝试提交的次数远远的大于最终提交成功的次数说明flume异常。
自身：增加内存
找兄弟：增加服务器
优化
file channel 能配置多目录就配置多目录
三个器
拦截器、选择器、监控器
挂了怎么办
channel
memory
100个
file
100w个
taildir source
不会丢失，可能重复
0 条评论
下一页
为你推荐
查看更多
