大数据中台架构以及建设全流程一(Paas层设计)

目录

设计背景

        问题点

中台目标

           复用,赋能,降本增效

 中台整体架构

Pass层技术选型

        实时存储平台----------->KAFKA(未来pulsar也不错)

        离线存储平台(Hadoop系列)

              Hadoop选型

  机架感知             

  硬件选型(PB级)

内存配置   

 资源计算

关键参数

存储平台常见故障

调度系统(Yarn)

管理平台

                Ambari

                 Cloudera ManagerCloud

自研+开源组件 

日志采集 

调度平台

实时数据Sql查询平台



设计背景

        当企业发展到一定规模时候有了不同的业务线以及数据规模,因为业务的快速发展。这个时候一些数据问题就会出现。

        问题点

                1:数据脏乱差,各部门生产线数据重复冗余,还不可:复用用存在数据孤岛

                2:数据开发部门的业务来自各部门各产品线,需求不明确,每天业务量繁复,日常工作可能成了sqlboy到处捞数据,而且在业务方面还没有业务部门了解的深入,有点缘木求鱼的意思。

        这个时候数据中台也就应运而生。

中台目标

           复用,赋能,降本增效

                1:面向业务,数据进行建模。

                2:数据整合避免烟囱式开发解决数据孤岛问题。

                3:赋能给各个业务部门,将能力下放将数据的使用权限赋予各个部门,减少数据开发部门繁琐的数据sql业务。       

 中台整体架构

大数据中台架构以及建设全流程一(Paas层设计)_第1张图片

Pass层技术选型

        实时存储平台----------->KAFKA(未来pulsar也不错)

                0.8版本标志着kafaka成熟

                0.9版本提供了安全模块,偏移量也由zk转移到自己的topic进行管理了

                0.10版本提供了流计算,生产者优化(提供了批次发送,默认16k发送一次),提供了机架感知

                  0.11版本生产者提供了幂等性和事物

                   1.x没啥特别优化

                    2.x优化stream,安全力度更细

        所以0.11版本后都可以,版本太高也要考虑兼容性问题

                tips:kafka因为内存是页存储,磁盘是顺序读写,因为顺序读写速度不亚于内存。所以kafka对于是内存还是磁盘需求不大

样例:假设平台每天接受一亿次实时请求,kafka如何hold住?

        每天集群需要承载1亿数据请求,一天24小时,对于网站,晚上12点到凌晨8点这8个小时几乎没多少数据。使用 二八法 则估计,也就是80%的数据(8千万)会在其余16个小时涌入,而且8亿的80%的数据(6.4千万)会在这16个小时的20%时间 (3小时)涌入。
        qps = 64000000/(3*60*60)= 6000,则高峰期每秒并发6000
        每天1亿数据,每个请求10 kb ,也就是1T的数据。如果保存3副本,1 *3=3T,
假设kafka默认保留最近7天的数据。故需要 3 * 7 =21T tips (默认时间可以根据资源需求降低)
        一个集群高峰期肯定还有很多其他业务要处理,所以高峰期的qps要控制在集群能承受的百分之30左右,所以集群能承受的总的qps在2w左右。一般来说一台物理机能承受的qps在4w左右。再加上消费者请求3三台左右就比较理想,而且kafka一般都是集群的3台起步。所以很合适。
        磁盘:三台物理机需要存储21T数据,则每台7块磁盘,每个磁盘1T就可以了。tips(最好配置上kafka 的log.dir避免数据全部写到一个磁盘导致性能变差。且linux对磁盘目录数有个数限制,太多会导致有空间但是写不进去)
        kafka磁盘类型选择: SSD固态硬盘or普通SAS机械硬盘?
        SSD就是固态硬盘,比机械硬盘要快,SSD的快主要是快在磁盘随机读写 Kafka是顺序写的,机械硬盘顺序写的性能机会跟内存读写的性能是差不多的。所以对于Kafka集群使用机械硬盘就可以了。
QPS计算公式=
大数据中台架构以及建设全流程一(Paas层设计)_第2张图片
64qps0000000÷(3*60*60)=6万,故高峰期集群需要要抗住每秒6万的并发

         内存:假如一个集群有3个topic,这3个topic的partition的数据在os cache里效果当然是最好的。3个topic,一个topic有假如30个partition。那么 总共会有90个partition。每个partition的Log文件大小是1G,我们有 3个副本,也就是说要把90个topic的partition数据都驻留在内存里需 要270G的内存。我们现在有3台服务器,所以平均下来每天服务器需 要90G的内存,但是其实partition的数据我们没必要所有的都要驻留 在内存里面,10-20%的数据在内存就非常好了,90G * 0.2 = 18G就 可以了。所以64g内存的服务 器也非常够用了。

        cpu:主要是看Kafka进程里会有多少个线程,线程主要是依托多核CPU来执行的,如果线程特别多,但是 CPU核很少,就会导致CPU负载很高,会导致整体工作线程执行的效率不太高。 来Kafka内部有100多个线程,4个cpu core,一般来说几十个线程,在高峰期CPU几乎都快打满了。8个cpu ,能够比较宽裕的 支撑几十个线程繁忙的工作。所以Kafka的服务器一般是建议16核,基本上可以hold住一两百线程的工作。当然如果可以给到32 cpu 那就更加的宽裕。

        网卡:

        1亿写请求,6000/s的吞吐量,3T的数据,3台物理机
        硬盘:7(SAS) * 1T,7200转
        内存:64GB,JVM分配6G,剩余的给os cache
        CPU:16核/32核
        网络:万兆网卡更佳
        核心配置:
        日志保留策略配置优化
        建议减少日志保留时间,通过log.retention.hours来实现,例如设置 log.retention.hours=72, 根据实际需求调整,默认是七天
        段文件大小优化
        段文件配置1GB,有利于快速回收磁盘空间,重启kafka加载也会加快,相反,如果文件过小,则文件数量比较多,kafka启动 时是单线程扫描目录(log.dir)下所有数据文件),文件较多时性能会稍微降低。可通过如下选项配置段文件大小: log.segment.bytes=1073741824
        log数据文件刷盘策略优化
        为了大幅度提高producer写入吞吐量,需要定期批量写文件 优化建议为:每当producer写入10000条消息时,刷数据到磁盘。可通过如下选项配置:
log.flush.interval.messages=10000
每间隔1秒钟时间,刷数据到磁盘。可通过如下选项配置:
log.flush.interval.ms=1000
        提升并发处理能力
        num.io.threads =8,num.network.threads =3(均为默认值,自己根据实际情况调整)

        离线存储平台(Hadoop系列)

              Hadoop选型

                1:Apache社区版本

                        a:开源,免费

                        b:更新快,新特性多

                        c: Bug多,需考虑各组件兼容性    

                2:Cloudera

                        a:分开源,免费版本。目前都要收费了

                        b:稳定,不需要考虑兼容性问题

                        c:有clouderaManager管理工具可视化界面很友好

                        d: 版本因为稳定,更新慢。新特性尝鲜少。且收费(!这点估计很多都不会选择)

                   3:Hortonworks

                        a:万全开源免费

                        b:稳定,不需要考虑兼容性问题

                        c:有集群管理工具可视化界面很友好

                        d: 流行度不高

                TIPS:   

                1.x 稳定版本

                2.0支持高可用,支持联邦

                2.7x流行度广比较稳定,建议2.7.5以后

                3.x HA支持多个namenode,增加纠删码功能。可以减少副本,文件块里面存了一部分压缩元数据,另外一部分用于存储校验数据可以用于数据恢复。就可以减少副本存储数。当然也可以多副本和纠删码同时开启。但是缺乏数据本地性问题

  机架感知             

        机架感知就是自动了解hadoop集群中每个机器节点所属的机架,某个datanode节点是属于哪个机柜并非是智能感知的,而是需要hadoop的管理者人为的告知hadoop哪台机器属于哪个机柜,这样在hadoop的Namenode启动初始化时,会将这些机器与机柜的对应信息保存在内存中,用来作为HDFS写数据块操作分配Datanode列表时(比如3个 block对应三台datanode)选择DataNode的策略,比如,要写三个数据块到对应的三台datanode,那么通过机架感知策略,可以尽量将三个副本分布到不同的机柜上。这个需要运维配合设置。

  硬件选型(PB级)

        cpu:推荐4路32核等,主频至少2-2.5GHz

        内存:推荐64-256GB

        磁盘:分为2组,系统盘和数据盘,系统盘2T*2,做raid1,数据盘2-10T左右(SSD,SAS)磁盘当然选择ssd性能更好,但是价格偏贵。每个数据盘在2-10T左右不宜太大,数据量太大读写慢,寻址慢。比如磁盘坏了或者导数据,磁盘数据量太大就很麻烦。

        网卡:万兆网卡(光纤卡),很有钱十万兆网卡也可以。

        电源:均配置冗余电源,有条件的可以具备发电能力。

内存配置   

        NameNode

      将Namenode运行在一台独立的服务器上,要设置Namenode堆内存大小,可通过在hadoop配置文件hadoop-env.sh中添加
如下内容实现:
export HADOOP_HEAPSIZE_MAX=
export HADOOP_HEAPSIZE_MIN=
tips:建议Namenode堆内存大小设置为物理内存的80%,且堆内存上限和下限设置为一样大,以免jvm动态调整。因为nd需要加载很多元数据,所以内存设置的比较大。(比如128g的服务器,设置nd的的内存为100g可以hold住1000台且为20*1T硬盘的集群)
        DataNode    
        同样修改hadoop配置文件hadoop-env.sh,添加如下内容:
export HDFS_DATANODE_HEAPSIZE=4096
export HDFS_DATANODE_OPTS="-Xms${HDFS_DATANODE_HEAPSIZE}m -Xmx${HDFS_DATANODE_HEAPSIZE}m"
建议Datanode堆内存大小设置为4GB以上。 4-8G即可 ,将更多内存留给YARN

 资源计算

在搭建集群时候需考虑未来一到两年的资源消耗来搭建集群。举个例子如下
1. 每天1T, 副本数为3 ,一年需要的存储资源:1 * 3 * 365 = 1095T
2. 数据需要 进行加工 (建模):1095T* 3 = 3285T
3. 数据增速是 每年50% ,3285T* (
1.5)= 4928T
4. 磁盘只能存到 80% ,故需要3942T的存储空间
5. 压缩比,按50%估算,故需要存储1972T
机器配置:32cpu core, 128G内存,11 * 7T
故:1972/77 = 26 服务器
Tips:评估资源时候一定要预留充足,以及充分的扩展接口

关键参数

dfs.replication
此参数用来设置文件副本数,通常设为3,不推荐修改。这个参数可用来保障HDFS数据安全,副本数越多,越浪费 磁盘存储空间,但数据安全性越高。tips:高版本可搭配纠删码使用。
dfs.block.size
此参数用来设置HDFS中数据块的大小,默认为128M,所以,存储到HDFS的数据最好都大于128M或者是128的整
数倍,这是最理想的情况,对于数据量较大的集群,可设为256MB或者512MB。数据块设置太小,会增加NameNode的压力。数据块设置过大会增加定位数据的时间。
dfs.datanode.data.dir
这个参数是设置HDFS数据块的存储路径,配置的值应当是分布在各个独立磁盘上的目录,这样可以充分利用节点的IO读写能力,提高HDFS读写性能。
dfs.datanode.max.transfer.threads
这个值是配置datanode可同时处理的最大文件数量,推荐将这个值调大,最大值可以配置为65535
hdfs-site.xml样例如下







	
	
		dfs.nameservices
		nxhadoop
	
	
	
		dfs.ha.namenodes.zzhadoop
		nn1,nn2
	
	
	
	    dfs.namenode.rpc-address.zzhadoop.nn1
            hadoop01:8020
	
	
	
	    dfs.namenode.http-address.zzhadoop.nn1
	    hadoop01:50070
	
	
        
            dfs.namenode.servicerpc-address.zzhadoop.nn1
            hadoop01:53310
        
	
	
		dfs.namenode.rpc-address.zzhadoop.nn2
		hadoop02:8020
	
	
	
		dfs.namenode.http-address.zzhadoop.nn2
		hadoop02:50070
	
        
            dfs.namenode.servicerpc-address.zzhadoop.nn2
            hadoop02:53310
        
	
		dfs.namenode.shared.edits.dir
		qjournal://hadoop03:8485;hadoop04:8485;hadoop05:8485/zzhadoop-joural
	
	
	
		dfs.journalnode.edits.dir
		/opt/zdp/hadoop/journal
	
	
	
		dfs.ha.automatic-failover.enabled
		true
	
	
	
		dfs.client.failover.proxy.provider.zzhadoop
		org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
	
	
	
		dfs.ha.fencing.methods
		sshfence(zdp:22)
	
    
        dfs.ha.fencing.ssh.connect-timeout
        1000
    
	
	
		dfs.ha.fencing.ssh.private-key-files
		/home/zdp/.ssh/id_rsa
	
	
		dfs.replication
		2
	
	
		dfs.namenode.name.dir
		file:/opt/zdp/hadoop/hdfs/dfs.namenode.name.dir
	

	
		dfs.datanode.data.dir
		file:///data0/hdfs/dfs.data,file:///data1/hdfs/dfs.data,file:///data2/hdfs/dfs.data,file:///data3/hdfs/dfs.data,file:///data4/hdfs/dfs.data,file:///data5/hdfs/dfs.data,file:///data6/hdfs/dfs.data,file:///data7/hdfs/dfs.data,file:///data8/hdfs/dfs.data,file:///data9/hdfs/dfs.data,file:///data10/hdfs/dfs.data,file:///data11/hdfs/dfs.data
	
	
		dfs.webhdfs.enabled
		true
	
    
        dfs.namenode.handler.count
        100
    
    
        dfs.datanode.max.xcievers
        4096
    

    
	dfs.datanode.balance.bandwidthPerSec
	31457280
    

      
        dfs.datanode.fsdataset.volume.choosing.policy  
  	org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy  
      
	
		dfs.datanode.failed.volumes.tolerated
		2
	
	
		dfs.client.file-block-storage-locations.timeout.millis
		6000
	
	
		dfs.datanode.hdfs-blocks-metadata.enabled
		true
	
	
		dfs.blocksize
		268435456
	
	
		dfs.datanode.du.reserved
		107374182400
	

    
    
        dfs.permissions.enabled
        true
    
    
        dfs.permissions.superusergroup
        zdp
    
    
        fs.permissions.umask-mode
        022
    
    
        dfs.namenode.acls.enabled
        true
    
    
    

    
      dfs.datanode.max.transfer.threads 
      8192
    
    
      dfs.namenode.fs-limits.max-component-length
      0
    


core-site.xml样例如下








	
		fs.defaultFS
		hdfs://hadoop
	
	
		ha.zookeeper.quorum
		hadoop03:2181,hadoop04:2181,hadoop05:2181/hadoop
	
	
		hadoop.tmp.dir
		/opt/zdp/hadoop/hadoop_tmp/tmp
		A base for other temporarydirectories.
	
	
		io.file.buffer.size
		131072
	
	
            fs.trash.interval
            1440
        
	
		io.compression.codecs
		org.apache.hadoop.io.compress.GzipCodec,
			org.apache.hadoop.io.compress.DefaultCodec,
			com.hadoop.compression.lzo.LzoCodec,
			com.hadoop.compression.lzo.LzopCodec,
			org.apache.hadoop.io.compress.BZip2Codec
		
	
    
        io.compression.codec.lzo.class
        com.hadoop.compression.lzo.LzoCodec
    

    
        ipc.server.read.threadpool.size
        3
        
        	Reader thread num, rpc中reader线程个数
        
    

    
    	net.topology.script.file.name
    	/opt/soft/zdp/hadoop-2.7.5/etc/hadoop/rack_awareness.py
    
    
        net.topology.script.number.args
   	100
    

   
 
    
      hadoop.proxyuser.zdp.hosts
      *
    
    
      hadoop.proxyuser.zdp.groups
      *
    
 
   
   
       hadoop.security.authorization
       true
   

        操作系统调优:
        
        1、调整操作系统打开文件描述符的上限
        通过命令“ ulimit -a”可以看到所有系统资源参数,这里面需要重点设置的是“open files”和“max user processes”,其它可以酌情设置。
要永久设置资源参数,主要是通过下面几个文件来实现:
/etc/security/limits.conf
/etc/security/limits.d/90-nproc.conf(centos6.x)
/etc/security/limits.d/20-nproc.conf(centos7.x)
        2、修改net.core.somaxconn参数
        此内核参数对应的具体文件路径为/proc/sys/net/core/somaxconn,它用来设置socket监听(
listen)的 backlog上限。
什么是backlog呢?backlog就是socket的监听队列,当一个请求(request)尚未被处理或建立时,他会 进入backlog。而socket server可以一次性处理backlog中的所有请求,处理后的请求不再位于监听队列 中。如何server处理请求较慢,以至于监听队列被填满时,新来的请求会被拒绝。所以必须增大这个值,
此 参数默认值为128。 作为网络参数的基础优化,建议修改为如下值:
echo 4096 >/proc/sys/net/core/somaxconn
        
        3、调整操作系统使用swap的比例
        swap本意是作为物理内存的扩展来使用的,但是在内存充足的今天,使用swap的场景越来越少,主要是使用swap会极大降低应用性能,在hadoop中,如果数据交换到swap,会导致操作超时,非常影响hadoop的读写以及数据分析性能。
        可以通过系统内核参数/proc/sys/vm/swappiness来调整使用swap的比例。swappiness=0的时候表 示最大限度使用物理内存,然后才是swap空间,swappiness=100的时候表示积极的使用swap分 区,并且把内存上的数据及时的搬运到swap空间里面。
linux的基本默认设置为60,表示你的物理内存在使用到100-60=40%的时候,就开始出现有交换分
区的使用。此值在一些对内存需求高的服务器上,需要设置的足够小,比如hadoop、redis、hbase 机器上,应该设置0-10之间,表示最大限度使用物理内存.。
        4、禁用THP(Transparent Huge Pages)功能
        THP的本意是为提升内存的性能,但是在hadoop环境中发现,此功能会带来CPU占用率增大,影响hadoop性能,因此建议
将其关闭

存储平台常见故障

1:下线DataNode

(1)、修改hdfs-site.xml文件
找到namenode节点配置文件/etc/hadoop/conf/hdfs-site.xml文件如下选项:
dfs.hosts.exclude
/etc/hadoop/conf/hosts-exclude
(2)、修改hosts-exclude文件
在hosts-exclude中添加需要下线的datanode主机名,执行如下操作:
vi /etc/hadoop/conf/hosts-exclude
192.16.213.77
(3)、刷新配置
在namenode上以hadoop用户执行下面命令,刷新hadoop配置:
[hadoop@namenodemaster ~]$hdfs dfsadmin -refreshNodes
(4)、检查是否完成下线
通过执行如下命令检查下线是否完成:
[hadoop@cdh5master ~]$hdfs dfsadmin -report
也可以通过查看NameNode的50070端口访问web界面,查看HDFS状态,需要重点关注退役的节点数以及复制的块数和进度
2:磁盘故障
        如果某个datanode节点的磁盘出现故障,将会出现此节点不能写入操作而导致datanode进程退出,针对这个 问题,首先在故障节点上查看/etc/hadoop/conf/hdfs-site.xml文件中对应的dfs.datanode.data.dir参数设 置,去掉故障磁盘对应的目录挂载点。
        然后,在故障节点查看/etc/hadoop/conf/yarn-site.xml文件中对应的yarn.nodemanager.local-dirs参数设 置,去掉故障磁盘对应的目录挂载点。最后,重启此节点的datanode服务和nodemanager服务即可。磁盘修复好了以后,重新添加回去(可以通过脚本自动监控新增磁盘)。
3:NameNode故障

        在HDFS集群中,Namenode主机上存储了所有的元数据信息,如果此信息丢失,那么整个HDFS上面的数据将不可用,而如果Namenode服务器发生了故障无法启动,

解决的方法分为两种情况:

        如果Namenode做了高可用服务,那么在主Namenode故障后,Namenode服务会自动切换到备用的 Namenode上,这个过程是自动的,无需手工介入。

        如果你的Namenode没做高可用服务,那么还可以借助于SecondaryNameNode服务,在 SecondaryNameNode主机上找到元数据信息,然后直接在此节点启动Namenode服务即可,种方式可能会丢失部分数据,因为SecondaryNameNode实现的是Namenode的冷备份。 由此可知,对Namenode进行容灾备份至关重要,在生产环境下,建议通过standby Namenode实现Namenode的高可用热备份。

4:yarn被标记为不健康

        当节点被标记为不健康后,此节点相会被剔出了yarn集群,不会再有任务提交到此节点.
yarn配置中,参数yarn.nodemanager.local-dirs,它用来存储NodeManager应用程序运行的中间结果,另一个参数yarn.nodemanager.log-dirs,它指定了NodeManager的日志文件存放目录列表。这两个参数都可以配置多个目录,多个目录之间使用逗号分隔。
本地目录健康检测主要涉及到以下几个参数:
yarn.nodemanager.disk-health-checker.min-healthy-disks
表示正常目录数目相对于总目录总数的比例,低于这个值则认为此节点处于不正常状态,默认值为0.25。
例如指定了十二个目录(磁盘),这意味着它们中至少有3(
12的1/4)个目录必须处于正常状态才能使
NodeManager在该节点上启动新容器。
yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage
此参数默认值为90,表示yarn.nodemanager.local-dirs配置项下的路径或者yarn.nodemanager.log-dirs配置项下的路径的磁盘使用率达到了90%以上,则将此台机器上的nodemanager标志为unhealthy,这个值可以设置为0 到100之间
5:磁盘存储不均
        
在HDFS集群中,涉及到增删磁盘时候就回到指数局部均衡。以新增磁盘为例。
有新数据会写入这个硬盘,而之前的老数据不会自动将数据平衡过来,如此下去,更换的硬盘越多,节点之 间、每个节点的各个磁盘之间的数据将越来越不平衡。
可以使用hadoop提供的Balancer程序得HDFS集群达到一个平衡的状态,执行命令
如下:
[hadoop@namenodemaster sbin]$ $HADOOP_HOME/bin/start-balancer.sh –t 5%
或者执行如下命令:
[hadoop@namenodemaster sbin]$ hdfs balancer -threshold 5
这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果节点与节点之间磁盘使用率偏 差小于5%,那么我们就认为HDFS集群已经达到了平衡的状态。
6:集群新增DataNode
(1)、新节点部署hadoop环境
        新增节点在系统安装完成后,要进行一系列的操作,比如系统基本优化设置,hadoop环境的部署和安装等等,这 些基础工作需要事先完成。
(2)、修改hdfs-site.xml文件
在namenode上查看/etc/hadoop/conf/hdfs-site.xml文件,找到如下内容:
dfs.hosts
/etc/hadoop/conf/hosts
(3)、修改hosts文件
namenode 上修改/etc/hadoop/conf/hosts文件,添加新增的节点主机名,操作如下:
vi /etc/hadoop/conf/hosts hadoop001 最后,将配置同步到所有datanode节点的机器上。
(4)、使配置生效
新增节点后,要让namenode识别新的节点,需要在namenode上刷新配置,执行如下操作:
[hadoop@namenodemaster ~]$hdfs dfsadmin -refreshNodes
(5)、在新节点启动dn服务
在namenode上完成配置后,最后还需要在新增节点上启动datanode服务,执行如下操作:
[hadoop@ hadoop001 ~]$ hdfs --daemon start datanode
这样,一个新的节点就增加到集群中了,hadoop的这种机制可以在不影响现有集群运行的状态下,任意新增或者删除 某个节点。
7:missing blocks
        这个问题也经常发生,并且会有数据丢失,因为一旦HDFS集群出现missing blocks错误,那意味着有元数据丢失或者损坏,要恢复的难度很大,或者基本无法恢复,针对这种情况,解决的办法就是先执行如下命令:
[hadoop@namenodemaster sbin]$ hdfs fsck /blocks-path/
此命令会检查HDFS下所有块状态,并给出那些文件出现了块丢失或损坏,最后执行如下命令删除这些文件 即可:
[hadoop@namenodemaster sbin]$ hdfs fsck -fs hdfs://bigdata/logs/mv.log -delete
上面是删除HDFS上mv.log这个文件,因此此文件元数据丢失,无法恢复,所以只能删除。
8:KafkaBroker OOM
        Kafka的默认启动内存较小,Kafka的生产端首先将数据发送到broker的内存存储,随机通过主机的OS层的数据刷盘机制将数据持久化,因此Kafka需要一定大小的内存空间,在生产环境一般建议将启动内存调整,官方建议内存在4-8G左右大小;
修改${KAFKA_HOME}/bin/kafka-server-start.sh脚本
9: broker运行日志大量topic不存在报错,导致节点不可用
若broker的运行日志大量刷topic不存在的WARN,并导致节点不可用;表明该集群存在topic被删除,但有发端 仍使用该topic发送数据,此时需要检查broker上的2个配置项:
delete.topic.enable=true
auto.create.topics.enable=false(默认是true,发送时候没有topic默认创建)
10:kafka topic动态扩分区
        流程见:https://blog.csdn.net/forrest_ou/article/details/79141391
        目前Kafka只支持增加分区数而不支持减少分区数。比如我们再将主题topic-config的分区数修改为1,就会报出InvalidPartitionException的异常,详解如下
(27条消息) 为什么Kafka中的分区数只能增加不能减少_rede-CSDN博客

调度系统(Yarn)

大数据中台架构以及建设全流程一(Paas层设计)_第3张图片

ResourceManager
负责集群资源的统一管理和调度
NodeManager
每个节点只有一个,负责资源的管理和
使用
ApplicationMaster
每个应用程序只有一个,负责应用程序的
管理和任务调度
Container
对任务运行环境的抽象
优点
        1:多类型资源调度,支持cpu,内存调度
        2:多种调度器,FIFO(先到先得),Fair(公平调度),Capacity(权重调度)

 yarn-site.xml参考配置如下



	
	
		yarn.resourcemanager.ha.enabled
		true
	
	
		yarn.resourcemanager.cluster-id
		rm
	
	
		yarn.resourcemanager.ha.rm-ids
		rm1,rm2
	
	  
		yarn.resourcemanager.hostname.rm1  
		hadoop1  
	  
	  
		yarn.resourcemanager.hostname.rm2  
		hadoop2  
	  
	
	
		yarn.resourcemanager.resource-tracker.address.rm1
		hadoop1:8031
	
	
		yarn.resourcemanager.scheduler.address.rm1
		hadoop1:8030
	
	
		yarn.resourcemanager.address.rm1
		hadoop1:8032
	
	
		yarn.resourcemanager.admin.address.rm1
		hadoop1:8033
	
	
		yarn.resourcemanager.webapp.address.rm1
		hadoop1:8088
	
	
	
		yarn.resourcemanager.resource-tracker.address.rm2
		hadoop2:8031
	
	
		yarn.resourcemanager.scheduler.address.rm2
		hadoop2:8030
	
	
		yarn.resourcemanager.address.rm2
		hadoop2:8032
	
	
		yarn.resourcemanager.admin.address.rm2
		hadoop2:8033
	
	
		yarn.resourcemanager.webapp.address.rm2
		hadoop2:8088
	
	
		yarn.resourcemanager.recovery.enabled
		true
	
	
		yarn.resourcemanager.store.class
		org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
	
        
    	    yarn.resourcemanager.zk-state-store.parent-path
    	    /rmstore
        
	
		yarn.resourcemanager.zk-address
		hadoop011:2181,hadoop012:2181,hadoop013:2181/zzhadoop
	
	
		yarn.resourcemanager.ha.automatic-failover.enabled
		true
	
	
		yarn.resourcemanager.ha.automatic-failover.embedded
		true
	
	
		yarn.client.failover-proxy-provider
		org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider
	
	
		yarn.log-aggregation-enable
		true
	
	
		Classpath for typical applications.
		yarn.application.classpath
		
			$HADOOP_HOME/etc/hadoop/,
			$HADOOP_HOME/share/hadoop/common/*,$HADOOP_HOME/share/hadoop/common/lib/*,
			$HADOOP_HOME/share/hadoop/hdfs/*,$HADOOP_HOME/share/hadoop/hdfs/lib/*,
			$HADOOP_HOME/share/hadoop/mapreduce/*,$HADOOP_HOME/share/hadoop/mapreduce/lib/*,
			$HADOOP_HOME/share/hadoop/yarn/*,$HADOOP_HOME/share/hadoop/yarn/lib/*,
			$HADOOP_HOME/share/hadoop/tools/lib/*
		
	
	
		yarn.nodemanager.aux-services
		mapreduce_shuffle,spark_shuffle
	
	
		yarn.nodemanager.aux-services.mapreduce.shuffle.class
		org.apache.hadoop.mapred.ShuffleHandler
	

    
        yarn.nodemanager.aux-services.spark_shuffle.class
        org.apache.spark.network.yarn.YarnShuffleService
    

	
	
		yarn.nodemanager.local-dirs
		file:///data0/yarn/nm-local-dir,file:///data1/yarn/nm-local-dir,file:///data2/yarn/nm-local-dir,file:///data3/yarn/nm-local-dir,file:///data4/yarn/nm-local-dir,file:///data5/yarn/nm-local-dir,file:///data6/yarn/nm-local-dir,file:///data7/yarn/nm-local-dir,file:///data8/yarn/nm-local-dir,file:///data9/yarn/nm-local-dir,file:///data10/yarn/nm-local-dir,file:///data11/yarn/nm-local-dir
		
			An application's localized file directory will be found in: ${yarn.nodemanager.local-dirs}/usercache/${user}/appcache/application_${appid}.
		
	
	
	
		yarn.nodemanager.log-dirs
		file:///data0/yarn/userlogs,file:///data1/yarn/userlogs,file:///data2/yarn/userlogs,file:///data3/yarn/userlogs,file:///data4/yarn/userlogs,file:///data5/yarn/userlogs,file:///data6/yarn/userlogs,file:///data7/yarn/userlogs,file:///data8/yarn/userlogs,file:///data9/yarn/userlogs,file:///data10/yarn/userlogs,file:///data11/yarn/userlogs
		
			Where to store container logs. Each container directory will contain the files stderr, stdin, and syslog generated by that container.
		
	
    
        yarn.nodemanager.log.retain-seconds
        10800
        
    
	
	
		Where to aggregate logs
		yarn.nodemanager.remote-app-log-dir
		/yarn/apps/logs
	
	
	
		yarn.app.mapreduce.am.staging-dir
		/yarn/staging
	
    
    
        yarn.log.server.url
        http://nxhadoop011:19888/jobhistory/logs
    

	
		yarn.resourcemanager.am.max-retries
		3
	
	
		yarn.resourcemanager.am.max-attempts
		3
	
	
		How long to wait until a node manager is considered dead.
		yarn.nm.liveness-monitor.expiry-interval-ms
		120000
	
	
		yarn.app.mapreduce.am.scheduler.connection.wait.interval-ms
		5000
	
	
		yarn.am.liveness-monitor.expiry-interval-ms
		120000
	
	
		yarn.resourcemanager.rm.container-allocation.expiry-interval-ms
		120000
	
	
		Amount of physical memory, in MB, that can be allocated for containers.
		yarn.nodemanager.resource.memory-mb
		102400
	
	
		Number of CPU cores that can be allocated for containers.
		yarn.nodemanager.resource.cpu-vcores
		32
	

	
		yarn.resourcemanager.scheduler.class
		org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler
	
	
		yarn.scheduler.fair.allocation.file
		/opt/soft/zdp/hadoop/etc/hadoop/fair-scheduler.xml
	
	
		yarn.scheduler.fair.user-as-default-queue
		false
	
	
		yarn.scheduler.fair.preemption
		false
	
	
		yarn.scheduler.fair.sizebasedweight
		false
	
	
		yarn.scheduler.fair.assignmultiple
		true
	
	
		yarn.scheduler.fair.max.assign
		3
	
	
		yarn.scheduler.fair.allow-undeclared-pools
		false
	
	
		yarn.scheduler.fair.continuous-scheduling-enabled
		true
	


	
		yarn.scheduler.maximum-allocation-vcores
		10
	
	
		yarn.scheduler.minimum-allocation-mb
		512
	

        
            yarn.scheduler.maximum-allocation-mb
            32768
            
            Maximum limit of memory to allocate to each container request at the Resource Manager.    
            In MBs.
            According to my configuration,yarn.scheduler.maximum-allocation-mb > yarn.nodemanager.resource.memory-mb
            
        

	
		yarn.nodemanager.pmem-check-enabled
		true
	
	
		yarn.nodemanager.vmem-check-enabled
		true
	
	
		yarn.nodemanager.vmem-pmem-ratio
		100
	

	

	
		rpc.engine.org.apache.hadoop.mapred.JobSubmissionProtocol
		org.apache.hadoop.ipc.ProtobufRpcEngine
	
	
		yarn.ipc.rpc.class
		org.apache.hadoop.yarn.ipc.HadoopYarnProtoRPC
	
	
		yarn.client.nodemanager-connect.max-wait-ms
		20000
	
	
		yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage
		97.0
	


        
            yarn.nodemanager.address
            ${yarn.nodemanager.hostname}:65033
        

            
    		yarn.resourcemanager.connect.retry-interval.ms  
    		2000  
             


管理平台

        各个组件之间没有统一的 metric 可视化界面,比如说 hdfs 总共占用的磁盘空间、 IO 、运行状况等,. 平台健不健康也不知道。这个时候就需要一个可视化管理平台。

        业内常见方案

                Ambari

                    安装部署文档自取

                链接:https://pan.baidu.com/s/1CRbKv5H4VdnPgvgJgQcbCg 
                提取码:18us

                特点:

                1. Apache Ambari是一种基于Web的工具,支持Apache Hadoop集群的创建、管理和监控。
                2. Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop和Hcatalog等的集中管理
                3. Ambari使用Ganglia收集度量指标,用Nagios支持系统报警,当需要引起管理员的关注时(比如,节点停机或磁盘剩余空间 不足等问题),系统将向其发送邮件。
                4. 主要开发语言Python,开源
                提供Hadoop集群
                1) Ambari提供了跨任意数量的主机安装Hadoop服务的分步向导。
                2)Ambari处理群集的Hadoop服务配置。
                管理Hadoop集群
                1) Ambari提供集中管理,用于在整个集群中启动,停止和重新配置Hadoop服务。
                监控Hadoop集群
                1)Ambari提供了一个仪表板,用于监控Hadoop集群的运行状况和状态。
                2)Ambari利用Ambari指标系统进行指标收集。
                3)Ambari利用Ambari Alert Framework进行系统警报,并在需要您注意时通知您(例如,节点出现故障,剩余磁盘空间不足 等)

界面如图所示 

大数据中台架构以及建设全流程一(Paas层设计)_第4张图片

                 Cloudera ManagerCloud

                 Cloudera Manager(简称CM)是Cloudera公司开发的一款大数据集群安装部署利器,这款利器具有集群自动化安装、中心化管理、集群 监控、报警等功能。
                特点:
                
                1.管理:对集群进行管理,如添加、删除节点等操作。
                2.监控:监控集群的健康情况,对设置的各种指标和系统运行情况进行全面监控。
                3.诊断:对集群出现的问题进行诊断,对出现的问题给出建议解决方案。
                4.集成:对hadoop的多组件进行整合。
                5.比Ambari管理粒度更细
                缺点:收费
                安装文档自取:
                链接:https://pan.baidu.com/s/1olezueF2NZxvwHGVw9dFhA 
                提取码:wjfd
界面展示如下
大数据中台架构以及建设全流程一(Paas层设计)_第5张图片

CM和Ambari对比如下

大数据中台架构以及建设全流程一(Paas层设计)_第6张图片

自研+开源组件 

集群的部署和管理可以基于Ambari二次开发(管理Apache,CDH,HDP都可以)。

监控告警解决方案(cm和Ambari自带的监控粒度不过详细,一般会选择其他监控方案):

方案一:ganglia+nagios
Ganglia是UC Berkeley发起的一个开源集群监视项目,设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad 以及一个Web前端。主要是用来监控系统性能,如:cpu 、mem、硬盘利用率, I/O负载、网络流量情况等,通过曲线很容 易见到每个节点的工作状态。
用户群:适用于大型服务器集群用户。
ganglia
(1)优点:
1. 适合监控系统性能,通过曲线很容易见到每个节点的工作状态
2. 可以自定义监控项,监控展示有表格和图像两种,支持手机版
3. 部署方便,通过不同的分层管理上万台机器,无需逐个添加配置,有利于后期的大规模扩张。
4. Ganglia的强大在于:ganglia服务端能够通过一台客户端收集到同一个网段的所有客户端的数据,ganglia集群服务端能够通过一台服务端 收集到它下属的所有客户端数据。这个体系设计表示一台服务器能够通过不同的分层能够管理上万台机器。这个功能是其他mrtg,nagios,cacti 所不能比拟。
5.Ganglia相比zabbix的优势在于客户端收集agent(gmond)所带来的系统开销非常低,不会影响相关服务的性能。
(2)缺点:
1. 没有报警机制,出现问题不能够及时报警。所以需要搭配其他报警组件使用
效果图如图所示
大数据中台架构以及建设全流程一(Paas层设计)_第7张图片
  Nagios

 Nagios是一个监视系统运行状态和网络信息的监视系统。Nagios能监视所指定的本地或远程主机以及服务,同时提供异常通知功能等

方案二:open falcon/Zabbix(两个都带监控告警,任选其一)
OpenFalcon
OpenFalcon是由小米的运维团队开源的一款企业级、高可用、可扩展的开源监控解决方案,,在众多开源爱好者的支持
下,功能越来越丰富,文档更加的完善,OpenFalcon 已经成为国内最流行的监控系统之一。小米、美团、金山云、快
网、宜信、七牛、又拍云、赶集、滴滴、金山办公、爱奇艺、一点资讯、快牙、开心网、借贷宝、百度、迅雷等公司使用.
zabbix(没有openfacon好用)
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参
数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
方案三:Prometheus+grafana 
Prometheus
监控组件,但是展示比较丑一般搭配frafana使用。普罗米修斯对大数据组件支持很好
grafana 
Grafana是一款用Go语言开发的开源数据可视化工具,可以做数据监控和数据统计,带有告警功能。目前使用 grafana的公司有很多,如paypal、ebay、intel等
效果图如下所示
大数据中台架构以及建设全流程一(Paas层设计)_第8张图片
上诉集中监控组件对比如下
大数据中台架构以及建设全流程一(Paas层设计)_第9张图片

推荐方案:Ambari(管理)+Opeca/Prometheus(自带的界面也没Grafana好看)+Granfana

实时Kafka监控告警

常用组件

kafka monitor

大数据中台架构以及建设全流程一(Paas层设计)_第10张图片

 kafka manager

大数据中台架构以及建设全流程一(Paas层设计)_第11张图片

Eagle

管理比较完善,自带监控告警,还带kafka sql

大数据中台架构以及建设全流程一(Paas层设计)_第12张图片

 如果想将告警信息统一可以采用如下设计方案。图中监控页面是上述三种组件中的任意一种。

大数据中台架构以及建设全流程一(Paas层设计)_第13张图片

使用开源组件或者自己读取kafka offset的topic进行监控

日志采集 

完整的大数据平台,包括以下的几个过程:数据采集 –> 数据存储 –> 数据处理–> 数据展现
业务日志采集
Flume 是 Apache旗下的一款开源、 高可靠、高扩展、 容易管理、支持客 户扩展的数据采集系统
Logstash 是一个应 用程序日志、事件的 传输、处理、管理和 搜索的平台。你可以 用它来统一对应用程 序日志进行收集管 理,提供 Web 接口 用于查询和统计。
对比:logstash一般是elk使用,适合数据量中等,flume更适合hadoop生态海量数据
数据库日志采集
Canal是阿里巴巴旗下的一款开源 项目,纯Java开发。基于数据库增量 日志解析,提供增量数据订阅&消费, 目前主要支持MySQL(也支持 MariaDB)
数据库批量采集
Sqoop是一款开源的工 具,主要用于在 Hadoop(Hive)与传统的 数据库(MySQL、 postgresql...)间进行数据 的传递,反之成立。
DataX 是阿里巴巴集团内被广泛使用的离线数据同步工 具/平台,实现包括 MySQL、Oracle、 SqlServer、Postgre、 HDFS、Hive、HBase等各 种异构数据源之间高效的数据同步功能。

案例:用户行为日志 

大数据中台架构以及建设全流程一(Paas层设计)_第14张图片
案例:业务数据采集
大数据中台架构以及建设全流程一(Paas层设计)_第15张图片
案例3:上述采集的数据入库基础数据平台

 大数据中台架构以及建设全流程一(Paas层设计)_第16张图片

 全流程整体架构如下大数据中台架构以及建设全流程一(Paas层设计)_第17张图片

调度平台

        工作中很多任务需要定时调度最粗暴和简单直接的解决方案就是crontab。当然在机器少,任务不多,定时任务之间关联少的情况下,crontab效率还是比较高和便捷的。  随着集群的增多 ,任务的增多。crontab就开始出现管理混乱的情况,这个时候一个调度平台就非常重要。

业内常见组件

Oozie

         Oozie是一个用于管理Apache Hadoop作业的工作流调度程序系统。对于通用流程调度而言,不是一个非常 好的候选者,因为XML定义对于定义轻 量级作业非常冗长和繁琐。 它还需要相当多的外设设置。 Azkaban是由Linkedin开源的一个批 量工作流任务调度器。用于在一个工 作流内以一个特定的顺序运行一组工 作和流程。 需要通过打zip进行任务调度,任务依赖支持不灵活。

Azkaban
Azkaban是由Linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。需要通过打zip进行任务调度,任务依赖支持不灵活。
DolphinScheduler
Apache DolphinScheduler是一个分 布式去中心化,易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系,使调度系统在数据处理流程中开箱即用。

实时数据Sql查询平台

        离线数据可以使用hsql或者spaqlsql进行分析出具处理,这对于一些其他部门只需要学习一下sql就可以上手。但是实时需求就非常麻烦需要很多技术栈需要开发人员才能进行分析。

        要是能对实时数据进行sql类型的分析那就很棒,工作效率也会变高,学习成本也变低了。目前有开源的工具可以进行二次开发进行使用。

https://github.com/DTStack/flinkStreamSQL
基于开源的flink,对其实时sql进行扩展;主要实现了流与维表的join,支持原生flink SQL所有的语法

大数据中台架构以及建设全流程一(Paas层设计)_第18张图片

 这个开源组件并没有形成产品化,只是提供了工具jar包。使用方式如下。plugins为该组件jar包目录。

大数据中台架构以及建设全流程一(Paas层设计)_第19张图片

 要想将该组件产品化,需要搭配web使用,需要设计一个web任务提交保存页面,后端进行解析提交脚本。流程大致如下。

大数据中台架构以及建设全流程一(Paas层设计)_第20张图片

任务诊断

大数据中台架构以及建设全流程一(Paas层设计)_第21张图片

在任务管理平台里面,可以使用任务诊断的功能提出改善意见。

大多数Hadoop优化工具,不管是开源还是商业的,都被 设计用来采集系统资源指标和监控集群资源信息。他们大 多数专注于简化Hadoop集群的部署和管理。很少有工具 来帮助用户优化Hadoop作业流的。少数的几个可用工具 要么扩展性差,要么不支持快速发展的Hadoop框架。 Dr. Elephant能很好支持Hadoop生态框架以及后续的新 框架,同时对Spark的支持也很友好。你同时也可以通过 插件的方式配置各种你喜欢的启发式算法。旨在帮助Hadoop和Spark的用户了解他们的内部工作流, 并帮助 他们轻松优化他们的作业。

 大数据中台架构以及建设全流程一(Paas层设计)_第22张图片

                                                                                                                                                                         

你可能感兴趣的:(spark,数仓,scala,spark,hadoop)