目录
设计背景
问题点
中台目标
复用,赋能,降本增效
中台整体架构
Pass层技术选型
实时存储平台----------->KAFKA(未来pulsar也不错)
离线存储平台(Hadoop系列)
Hadoop选型
机架感知
硬件选型(PB级)
内存配置
资源计算
关键参数
存储平台常见故障
调度系统(Yarn)
管理平台
Ambari
Cloudera ManagerCloud
自研+开源组件
日志采集
调度平台
实时数据Sql查询平台
当企业发展到一定规模时候有了不同的业务线以及数据规模,因为业务的快速发展。这个时候一些数据问题就会出现。
1:数据脏乱差,各部门生产线数据重复冗余,还不可:复用用存在数据孤岛
2:数据开发部门的业务来自各部门各产品线,需求不明确,每天业务量繁复,日常工作可能成了sqlboy到处捞数据,而且在业务方面还没有业务部门了解的深入,有点缘木求鱼的意思。
这个时候数据中台也就应运而生。
1:面向业务,数据进行建模。
2:数据整合避免烟囱式开发解决数据孤岛问题。
3:赋能给各个业务部门,将能力下放将数据的使用权限赋予各个部门,减少数据开发部门繁琐的数据sql业务。
0.8版本标志着kafaka成熟
0.9版本提供了安全模块,偏移量也由zk转移到自己的topic进行管理了
0.10版本提供了流计算,生产者优化(提供了批次发送,默认16k发送一次),提供了机架感知
0.11版本生产者提供了幂等性和事物
1.x没啥特别优化
2.x优化stream,安全力度更细
所以0.11版本后都可以,版本太高也要考虑兼容性问题
tips:kafka因为内存是页存储,磁盘是顺序读写,因为顺序读写速度不亚于内存。所以kafka对于是内存还是磁盘需求不大
样例:假设平台每天接受一亿次实时请求,kafka如何hold住?
内存:假如一个集群有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: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,增加纠删码功能。可以减少副本,文件块里面存了一部分压缩元数据,另外一部分用于存储校验数据可以用于数据恢复。就可以减少副本存储数。当然也可以多副本和纠删码同时开启。但是缺乏数据本地性问题
cpu:推荐4路32核等,主频至少2-2.5GHz
内存:推荐64-256GB
磁盘:分为2组,系统盘和数据盘,系统盘2T*2,做raid1,数据盘2-10T左右(SSD,SAS)磁盘当然选择ssd性能更好,但是价格偏贵。每个数据盘在2-10T左右不宜太大,数据量太大读写慢,寻址慢。比如磁盘坏了或者导数据,磁盘数据量太大就很麻烦。
网卡:万兆网卡(光纤卡),很有钱十万兆网卡也可以。
电源:均配置冗余电源,有条件的可以具备发电能力。
NameNode
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:下线DataNode
在HDFS集群中,Namenode主机上存储了所有的元数据信息,如果此信息丢失,那么整个HDFS上面的数据将不可用,而如果Namenode服务器发生了故障无法启动,
解决的方法分为两种情况:
如果Namenode做了高可用服务,那么在主Namenode故障后,Namenode服务会自动切换到备用的 Namenode上,这个过程是自动的,无需手工介入。
如果你的Namenode没做高可用服务,那么还可以借助于SecondaryNameNode服务,在 SecondaryNameNode主机上找到元数据信息,然后直接在此节点启动Namenode服务即可,种方式可能会丢失部分数据,因为SecondaryNameNode实现的是Namenode的冷备份。 由此可知,对Namenode进行容灾备份至关重要,在生产环境下,建议通过standby Namenode实现Namenode的高可用热备份。
4:yarn被标记为不健康
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 、运行状况等,. 平台健不健康也不知道。这个时候就需要一个可视化管理平台。
业内常见方案
安装部署文档自取
链接:https://pan.baidu.com/s/1CRbKv5H4VdnPgvgJgQcbCg
提取码:18us
特点:
界面如图所示
CM和Ambari对比如下
集群的部署和管理可以基于Ambari二次开发(管理Apache,CDH,HDP都可以)。
监控告警解决方案(cm和Ambari自带的监控粒度不过详细,一般会选择其他监控方案):
Nagios是一个监视系统运行状态和网络信息的监视系统。Nagios能监视所指定的本地或远程主机以及服务,同时提供异常通知功能等
推荐方案:Ambari(管理)+Opeca/Prometheus(自带的界面也没Grafana好看)+Granfana
实时Kafka监控告警
常用组件
kafka monitor
kafka manager
Eagle
管理比较完善,自带监控告警,还带kafka sql
如果想将告警信息统一可以采用如下设计方案。图中监控页面是上述三种组件中的任意一种。
使用开源组件或者自己读取kafka offset的topic进行监控
工作中很多任务需要定时调度最粗暴和简单直接的解决方案就是crontab。当然在机器少,任务不多,定时任务之间关联少的情况下,crontab效率还是比较高和便捷的。 随着集群的增多 ,任务的增多。crontab就开始出现管理混乱的情况,这个时候一个调度平台就非常重要。
业内常见组件
Oozie:
Oozie是一个用于管理Apache Hadoop作业的工作流调度程序系统。对于通用流程调度而言,不是一个非常 好的候选者,因为XML定义对于定义轻 量级作业非常冗长和繁琐。 它还需要相当多的外设设置。 Azkaban是由Linkedin开源的一个批 量工作流任务调度器。用于在一个工 作流内以一个特定的顺序运行一组工 作和流程。 需要通过打zip进行任务调度,任务依赖支持不灵活。
离线数据可以使用hsql或者spaqlsql进行分析出具处理,这对于一些其他部门只需要学习一下sql就可以上手。但是实时需求就非常麻烦需要很多技术栈需要开发人员才能进行分析。
要是能对实时数据进行sql类型的分析那就很棒,工作效率也会变高,学习成本也变低了。目前有开源的工具可以进行二次开发进行使用。
这个开源组件并没有形成产品化,只是提供了工具jar包。使用方式如下。plugins为该组件jar包目录。
要想将该组件产品化,需要搭配web使用,需要设计一个web任务提交保存页面,后端进行解析提交脚本。流程大致如下。
任务诊断
在任务管理平台里面,可以使用任务诊断的功能提出改善意见。