企业级数据仓库构建(四):数据仓库项目实战

本贴最后更新于 1290 天前,其中的信息可能已经沧海桑田

总结

1)数仓概念总结

【1】数据仓库的输入数据源和输出系统分别是什么?

输入系统:埋点产生的用户行为数据、JavaEE 后台产生的业务数据
输出系统:报表系统、用户画像系统、推荐系统

2)项目需求及架构总结

【1】集群规模计算

在这里插入图片描述

【2】框架版本选型
  1. Apache:运维麻烦,组件间兼容性需要自己调研。(一般大厂使用,技术实力雄厚,
    有专业的运维人员)(建议使用)
  2. CDH:国内使用最多的版本,但 CM 不开源,但其实对中、小公司使用来说没有影
  3. HDP:开源,可以进行二次开发,但是没有 CDH 稳定,国内使用较少
【3】服务器选型

在这里插入图片描述

3)数据采集模块总结

【1】Linux&Shell 相关总结
  1. Linux 常用高级命令在这里插入图片描述
  2. Shell 常用工具
    awk、sed、cut、sort
【2】Hadoop 相关总结
  1. Hadoop 默认不支持 LZO 压缩,如果需要支持 LZO 压缩,需要添加 jar 包,并在 hadoop
    的 cores-site.xml 文件中添加相关压缩配置。需要掌握让 LZO 文件支持切片
  2. Hadoop 常用端口号,50070,8088,19888,8020
  3. Hadoop 配置文件以及简单的 Hadoop 集群搭建。8 个配置文件
  4. HDFS 读流程和写流程
  5. MapReduce 的 Shuffle 过程及 Hadoop 优化(包括:压缩、小文件、集群优化)
  6. Yarn 的 Job 提交流程
  7. Yarn 的默认调度器、调度器分类、以及他们之间的区别
  8. HDFS 存储多目录
  9. Hadoop 参数调优

10)项目经验之基准测试

【3】Zookeeper 相关总结
  1. 选举机制
    半数机制,安装奇数台
    10 台服务器几台:3 台
    20 台服务器几台:5 台
    100 台服务器几台:11 台
    不是越多越好,也不是越少越好。 如果多,通信时间长,效率低;如果太少,可靠性差
  2. 常用命令
    ls、get、create
【4】Flume 相关总结

1)Flume 组成,Put 事务,Take 事务
Source 到 Channel 是 Put 事务
Channel 到 Sink 是 Take 事务

Taildir Source:断点续传、多目录。Flume1.6 以前需要自己自定义 Source 记录每次读取
文件位置,实现断点续传

File Channel:数据存储在磁盘,宕机数据可以保存。但是传输速率慢。适合对数据传
输可靠性要求高的场景,比如,金融行业

Memory Channel:数据存储在内存中,宕机数据丢失。传输速率快。适合对数据传输可
靠性要求不高的场景,比如,普通的日志数据

Kafka Channel:减少了 Flume 的 Sink 阶段,提高了传输效率

2)Flume 拦截器
(1)拦截器注意事项
项目中自定义了:ETL 拦截器和区分类型拦截器。
采用两个拦截器的优缺点:优点,模块化开发和可移植性;缺点,性能会低一些

(2)自定义拦截器步骤
a)实现 Interceptor
b)重写四个方法

  • initialize 初始化
  • public Event intercept(Event event) 处理单个 Event
  • public List intercept(List events) 处理多个 Event,在这个
    方法中调用 Event intercept(Event event)
  • close 方法

c)静态内部类,实现 Interceptor.Builder

3)Flume Channel 选择器
在这里插入图片描述
4)Flume 监控器
Ganglia

5)Flume 采集数据会丢失吗?
不会,Channel 存储可以存储在 File 中,数据传输自身有事务

6)Flume 内存
开发中在 flume-env.sh 中设置 JVM heap 为 4G 或更高,部署在单独的服务器上(4 核 8
线程 16G 内存)

-Xmx 与-Xms 最好设置一致,减少内存抖动带来的性能影响,如果设置不一致容易导
致频繁 fullgc

-Xms 表示 JVM Heap(堆内存)最小尺寸,初始分配;-Xmx 表示 JVM Heap(堆内存)最
大允许的尺寸,按需分配。如果不设置一致,容易在初始化时,由于内存不够,频繁触发 fullgc

7)FileChannel 优化
通过配置 dataDirs 指向多个路径,每个路径对应不同的硬盘,增大 Flume 吞吐量
官方说明如下:

Comma separated list of directories for storing log files. Using
multiple directories on separate disks can improve file channel peformance
12

checkpointDir 和 backupCheckpointDir 也尽量配置在不同硬盘对应的目录中,保证
checkpoint 坏掉后,可以快速使用 backupCheckpointDir 恢复数据

8)Sink:HDFS Sink 小文件处理
(1)HDFS 存入大量小文件,有什么影响?

元数据层面:每个小文件都有一份元数据,其中包括文件路径,文件名,所有者,所属
组,权限,创建时间等,这些信息都保存在 Namenode 内存中。所以小文件过多,会占用
Namenode 服务器大量内存,影响 Namenode 性能和使用寿命

计算层面:默认情况下 MR 会对每个小文件启用一个 Map 任务计算,非常影响计算性
能。同时也影响磁盘寻址时间

(2)HDFS 小文件处理
官方默认的这三个参数配置写入 HDFS 后会产生小文件,hdfs.rollIntervalhdfs.rollSize
hdfs.rollCount
基于以上 hdfs.rollInterval=3600,hdfs.rollSize=134217728,hdfs.rollCount =0 几个参数综
合作用,效果如下:
(1)文件在达到 128M 时会滚动生成新文件
(2)文件创建超 3600 秒时会滚动生成新文件

【5】Kafka 相关总结

在这里插入图片描述
1)Kafka 压测
Kafka 官方自带压力测试脚本(kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh)。
Kafka 压测时,可以查看到哪个地方出现了瓶颈(CPU,内存,网络 IO)。一般都是网
络 IO 达到瓶颈

2)Kafka 的机器数量
Kafka 机器数量=2*(峰值生产速度*副本数/100)+1

3)Kafka 的日志保存时间
3 天

4)Kafka 的硬盘大小
每天的数据量*3 天

5)Kafka 监控
公司自己开发的监控器
开源的监控器:KafkaManager、KafkaMonitor

6)Kakfa 分区数
(1)创建一个只有 1 个分区的 topic
(2)测试这个 topic 的 producer 吞吐量和 consumer 吞吐量。
(3)假设他们的值分别是 Tp 和 Tc,单位可以是 MB/s。
(4)然后假设总的目标吞吐量是 Tt,那么分区数=Tt / min(Tp,Tc)
例如:producer 吞吐量=10m/s;consumer 吞吐量=50m/s,期望吞吐量 100m/s;
分区数=100 / 10 =10 分区
分区数一般设置为:3-10 个

7)副本数设定
一般我们设置成 2 个或 3 个,很多企业设置为 2 个

8)多少个 Topic
通常情况:多少个日志类型就多少个 Topic。也有对日志类型进行合并的

9)Kafka 丢不丢数据
Ack=0,producer 不等待 kafka broker 的 ack,一直生产数据
Ack=1,leader 数据落盘就发送 ack,producer 收到 ack 才继续生产数据
Ack=-1,ISR 中的所有副本数据罗盘才发送 ack,producer 收到 ack 才继续生产数据

10)Kafka 的 ISR 副本同步队列
ISR(In-Sync Replicas),副本同步队列。ISR 中包括 Leader 和 Follower。如果 Leader
进程挂掉,会在 ISR 队列中选择一个服务作为新的 Leader。有 replica.lag.max.messages(延
迟条数)和 replica.lag.time.max.ms(延迟时间)两个参数决定一台服务是否可以加入 ISR 副
本队列,在 0.10 版本移除了 replica.lag.max.messages 参数,防止服务频繁的进去队列。
任意一个维度超过阈值都会把 Follower 剔除出 ISR,存入 OSR(Outof-Sync Replicas)
列表,新加入的 Follower 也会先存放在 OSR 中

11)Kafka 分区分配
Range 和 RoundRobin

12)Kafka 中数据量计算
每天总数据量 100g,每天产生 1 亿条日志, 10000 万/24/60/60=1150 条/每秒钟
平均每秒钟:1150 条
低谷每秒钟:400 条
高峰每秒钟:1150 条*(2-20 倍)=2300 条-23000 条
每条日志大小:0.5k-2k(取 1k)
每秒多少数据量:2.0M-20MB

13) Kafka 挂掉
(1)Flume 记录
(2)日志有记录
(3)短期没事

14)Kafka 消息数据积压,Kafka 消费能力不足怎么处理?

(1)如果是 Kafka 消费能力不足,则可以考虑增加 Topic 的分区数,并且同时提升消
费组的消费者数量,消费者数=分区数。(两者缺一不可)

(2)如果是下游的数据处理不及时:提高每批次拉取的数量。批次拉取数据过少(拉
取数据/处理时间 < 生产速度),使处理的数据小于生产的数据,也会造成数据积压

15)Kafka 幂等性
Kafka0.11 版本引入了幂等性,幂等性配合 at least once 语义可以实现 exactly once 语义。
但只能保证单次会话的幂等。
16)Kafka 事务
Kafka0.11 版本引入 Kafka 的事务机制,其可以保证生产者发往多个分区的一批数据的
原子性。

原文:

【项目】数仓项目(四)

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...