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