分享

大数据项目之电商数仓(总结)(五):用户行为数据采集

问题导读:
1、数据仓库的输入数据源和输出系统分别是什么?
2、HDFS存入大量小文件,有什么影响?
3、Kafka消息数据积压,Kafka消费能力不足怎么处理?

上一篇:大数据项目之电商数仓(用户行为数据采集)(四)

第5章 总结

5.1 数仓概念总结

1)数据仓库的输入数据源和输出系统分别是什么?
输入系统:埋点产生的用户行为数据、JavaEE后台产生的业务数据。
输出系统:报表系统、用户画像系统、推荐系统

5.2 项目需求及架构总结

5.2.1 集群规模计算

1.png

5.2.2 框架版本选型

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

5.2.3 服务器选型

服务器使用物理机还是云主机?
1)机器成本考虑:
(1)物理机:以128G内存,20核物理CPU,40线程,8THDD和2TSSD硬盘,单台报价4W出头,需考虑托管服务器费用。一般物理机寿命5年左右
(2)云主机,以阿里云为例,差不多相同配置,每年5W
2)运维成本考虑:
(1)物理机:需要有专业的运维人员
(2)云主机:很多运维工作都由阿里云已经完成,运维相对较轻松

5.3 数据采集模块总结

5.3.1 Linux&Shell相关总结

1)Linux常用命令


2.png

2)Shell常用工具
awk、sed、cut、sort

5.3.2 Hadoop相关总结

1)Hadoop默认不支持LZO压缩,如果需要支持LZO压缩,需要添加jar包,并在hadoop的cores-site.xml文件中添加相关压缩配置。(建表时候安装)
2)Hadoop常用端口号
3)Hadoop配置文件以及简单的Hadoop集群搭建
4)HDFS读流程和写流程
5)MapReduce的Shuffle过程及Hadoop优化(包括:压缩、小文件、集群优化)
6)Yarn的Job提交流程
7)Yarn的默认调度器、调度器分类、以及他们之间的区别
8)HDFS存储多目录
9)Hadoop参数调优

5.3.3 Zookeeper相关总结

1)选举机制
    半数机制
2)常用命令
    ls、get、create

5.3.4 Flume相关总结

1)Flume组成,Put事务,Take事务
    Taildir Source:断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置,实现断点续传。
    File Channel:数据存储在磁盘,宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景,比如,金融行业。
    Memory Channel:数据存储在内存中,宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景,比如,普通的日志数据。
    Kafka Channel:减少了Flume的Sink阶段,提高了传输效率。
    Source到Channel是Put事务
    Channel到Sink是Take事务
2)Flume拦截器
    (1)拦截器注意事项
        项目中自定义了:ETL拦截器和区分类型拦截器。
采用两个拦截器的优缺点:优点,模块化开发和可移植性;缺点,性能会低一些
    (2)自定义拦截器步骤
           a)实现 Interceptor
           b)重写四个方法
  • initialize 初始化
  • public Event intercept(Event event) 处理单个Event
  • public List<Event> intercept(List<Event> events) 处理多个Event,在这个方法中调用Event intercept(Event event)
  • close 方法
           c)静态内部类,实现Interceptor.Builder
3)Flume Channel选择器

3.png

4)Flume 监控器
Ganglia
5)Flume采集数据会丢失吗?
不会,Channel存储可以存储在File中,数据传输自身有事务。
6)Flume内存
开发中在flume-env.sh中设置JVM heap为4G或更高,部署在单独的服务器上(4核8线程16G内存)
-Xmx与-Xms最好设置一致,减少内存抖动带来的性能影响,如果设置不一致容易导致频繁full gc。
7)FileChannel优化
通过配置dataDirs指向多个路径,每个路径对应不同的硬盘,增大Flume吞吐量。
官方说明如下:

  1. Comma separated list of directories for storing log files. Using multiple directories on separate disks can improve file channel peformance
复制代码

checkpointDir和backupCheckpointDir也尽量配置在不同硬盘对应的目录中,保证checkpoint坏掉后,可以快速使用backupCheckpointDir恢复数据
8)Sink:HDFS Sink小文件处理
(1)HDFS存入大量小文件,有什么影响?
元数据层面:每个小文件都有一份元数据,其中包括文件路径,文件名,所有者,所属组,权限,创建时间等,这些信息都保存在Namenode内存中。所以小文件过多,会占用Namenode服务器大量内存,影响Namenode性能和使用寿命
计算层面:默认情况下MR会对每个小文件启用一个Map任务计算,非常影响计算性能。同时也影响磁盘寻址时间。
(2)HDFS小文件处理
官方默认的这三个参数配置写入HDFS后会产生小文件,hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
基于以上hdfs.rollInterval=3600,hdfs.rollSize=134217728,hdfs.rollCount =0几个参数综合作用,效果如下:
      (1)文件在达到128M时会滚动生成新文件
      (2)文件创建超3600秒时会滚动生成新文件
举例:在2018-01-01 05:23的时侯sink接收到数据,那会产生如下tmp文件:

5.3.5 Kafka相关总结

4.png

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的日志保存时间
7天
4)Kafka的硬盘大小
每天的数据量*7天
5)Kafka监控
公司自己开发的监控器;
开源的监控器:KafkaManager、KafkaMonitor
6)Kakfa分区数。
分区数并不是越多越好,一般分区数不要超过集群机器数量。分区数越多占用内存越大(ISR等),一个节点集中的分区也就越多,当它宕机的时候,对系统的影响也就越大。
分区数一般设置为: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
每秒多少数据量:2.3M-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的事务机制,其可以保证生产者发往多个分区的一批数据的原子性。





最新经典文章,欢迎关注公众号


本帖被以下淘专辑推荐:

没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条